Yes
Whatever ENV you specify when you finally do you docker run on the image … will take.
4 Likes
And doing those things at every boot of the container is reasonable?
Some people like this pattern, I do not, that is why rails introduces some super fancy locking around migrations to ensure they never run concurrently when a cluster of 20 app try to run migrations at the same time.
Some people just boot the same image and run the migrations in some out-of-band process.
3 Likes
But each container should still rake assets:precompile at least once?
Depends on how do you host those.
If you have a NFS share of some sort (like AWS EFS) or if you upload those to some object storage service that can only be done on bootstrap.
6 Likes
Thanks to everyone for all of the helpful replies. I have a few more questions about how to do this properly.
I’m trying to prepare a minimal app.yaml for bootstrapping that only contains information required for container build. Some of the information in there is clearly intended for container runtime—like the volume mounts and port mappings. But I’m not sure about the environment variables. I guess I’ll just try it, but are those environment variables used during container build (injected into the Dockerfile somehow) or just at container runtime? If it’s the latter I’ll just make sure they end up in the appropriate k8s configuration file.
Second, some people here have talked about pushing the image to a private container repository. Is that required? Put another way—does the build image contain any secret information that shouldn’t be published to a public repo like Docker Hub? (We don’t have a private container repository yet and I’d like to avoid setting one up.)
Finally, is there an app.yaml setting for controlling the name of the created container? More of just a fit and finish thing, but that would be nice 
.
Thanks in advance for the help! (Sorry for bumping an old thread. This is the first hit on Google when searching for how to install Discourse on Kubernetes.)
@Geoffrey_Challen You can create an image with the discourse repository and plugins, install the ruby gems and other dependencies and push it to a registry (like DockerHub). This repository would be agnostic to the environment and could be public (unless you include a private plugin or something of the sort). This base image could be used in staging and production environments and even in different projects (if they use the same plugins).
Steps like precompiling the assets, db migration and generating the ssl certificate should be executed in the target machine, though, to generate the final image.
I don’t know exactly how to include that in a k8s cluster tough. I went with the conservative approach and use it based on the official guide from the discourse team, just separating in 2 steps.
1 Like
This part I’m not sure I understand. Won’t these happen automatically inside the container as needed? I’m hoping I can just push this into our cloud and never need to gain shell access to the machine—similar to how I rarely (if ever) need to enter the Discourse Docker container.
You don’t need to enter the container explicitly. What I mean is that you can’t generate a precompiled image with them (generated in a CI pipeline, for example) and use it as is, because this must be executed in the target machine, where the database is located (this could be automated, but I haven’t done that in k8s, although I did it with Ansible).
2 Likes
Ah, OK. I’m using the all-in-one templates to include the database in the container. This is appropriate for our use case which involves supporting classes consisting of 10~1000 students—or at least the all-in-one has worked fine for my class in this configuration. So the database is inside the container.
But regardless, won’t Discourse run the database migrations or other setup steps when the container boots?
Are you sure the database is inside the container? Or is it the RDBMS (in this case, PostgreSQL)? The supported install uses the database outside the container (which is expected), mapping a volume inside to the outside (the host). Furthermore after a container rebuild, the container is recreated and you would lose all data.
If it really is inside the container I don’t know exactly how you would be able to upgrade based on the official install, because the launcher script seems to create and destroy the container several times when rebuilding (and run with --rm, which means that you would lose all your data, including the database, after the container stops).
I haven’t tried to change the way the rebuild is done, but assuming that you are able change it to run everything inside the container, without recreating it, then you should be able to push the container to a registry (make sure it’s private, because the secrets would be there). That said, I don’t recommend this approach for several reasons (some of them mentioned before).
The standard install includes nginx, rails, postgres, and redis inside the container. It uses external volumes for the postgres and redis data. It is not destroyed on a rebuild/upgrade.
1 Like
Yeah, just found weird that he said that the database is inside the container, unless he changed the way the standard install works, or mean postgres, not the database itself.
No - the migrations & asset compilation steps happen during the ./launcher bootstrap phase, after plugins have been resolved. After that’s done, the container can be restarted as much as necessary, or the web processes split across multiple machines, etc.
Imagineering, the setup should look something like this:
- official builds provide the discourse base image already.
- we will also need a container for discourse_docker that comes with its own Docker
- establish private registry inside the cluster
- establish a ConfigMap with the app.yml contents
- run a Job that executes
./launcher bootstrapusing the nested Docker on a VM-based Node (no docker socket access) and renames & pushes the resulting image to the private registry (with a timestamp-based label, notlatest) (local_discourseis not a good name here) and rolls the deployment to the new label- wow, that’s a lot of permissions on the upgrade job.
3 Likes
postgres runs inside the container. It saves data outside the container, but it runs inside the container if you use the standard set of install templates. Ditto with redis. I think the confusion is when I say “the database runs inside container” I’m talking about the database server, even if the database files live outside the container. (But database files don’t “run”, which is why I consider my phrasing clear—but clearly not clear enough .)
PS: actually it doesn’t necessarily even save data outside the container unless you configure Docker to bind mount that directory. I’ve been able to skip this during bootstrap, although it’s probably not a good idea, since at that point the database contents won’t survive container restarts.
1 Like
I think that this is making more sense to me now, particularly after reading the long linked conversation regarding docker-compose, the launcher script, etc.
Here’s what I’d like to be able to do:
- Run
./launcher bootstraplocally to create a “fat” Discourse image that includes all dependencies: postgres, redis, etc. - Deploy that image on Kubernetes
- Sometime later rerun
./launcher bootstrapto update the image and redeploy without destroying data (duh)
My understanding is that the fat Discourse image should not require any external service dependencies. However, for data to survive container upgrades the postgres database files need to live outside the container. That’s fine—I can create a k8s persistent volume for them.
Now here’s the only problem that I anticipate. Most of what happens during ./launcher bootstrap only touches files that live inside the container. For example, precompiling assets. That’s fine, since the results live inside the container and don’t need to survive upgrades.
The big exception here is the database migration. That step needs to have access to the database that will be used after bootstrapping is complete. So, to me, this seems like the major barrier to easily deploying fat Discourse images to the cloud.
I’ve noticed that @sam has mentioned multiple times that they redeploy Discourse for their customers using a workflow roughly similar to what I described above. But I suspect that the reason that this works is that their Discourse images are configured to use a database server (and probably Redis as well) that run on their cluster—which would make sense for supporting multiple deployments but is not quite what I want to do. This means that the bootstrapping process can modify the production database—or maybe just that the database migration step gets skipped entirely since database upgrades and migrations are handled externally. @sam: could you confirm?
Anyway, the upshot of this for me is that I need to find some way to run the database migrations when the container starts, not during ./launcher bootstrap. I guess at that point one way to do this would be:
- Build the fat Discourse container locally using
./launcher bootstrap, using a volume mount pointing at an empty local database, since that database is not going to be used later. This would get everything in the container right, just not finish the postgres work. - Find a way to run the database migration step on the actual production database—perhaps using an k8s init container?
- Replace the old Discourse image with the new one
You may be interested in a multi site configuration.
There’s two big problems you’re running into: Discourse isn’t ready for Kubernetes, so custom code is required. And you’re edging into what the Discourse team does to make money (hosting a large number of forums), so the level of support you’re getting will drop off.
My advice? Do a multisite configuration with static scheduling onto VMs, entirely outside your cluster. (Or a Service Type=ExternalName pointing to the VM to keep the same Ingress.)
6 Likes
OK… I managed to figure out one way of doing this. I’m not 100% happy with it, but it does work and may be appealing to others that are trying a simple single-container fat (includes postgres, redis, etc.) Discourse image deployment to Kubernetes.
My Approach
After examining the bootstrap process it became clear to me that unfortunately it mixes in two different kinds of operations—ones that only affect the underlying container, and others that poke out into the surrounding environment, mainly through the /shared volume mount where the postgres data files live. Rather than trying to tease these steps apart, it seems more sane to just run the bootstrapping steps in the environment where the container is actually going to be deployed.
Unfortunately, launcher bootstrap wants to create a container and use Docker. So running launcher inside another container (for example, in a container running on our cloud) means either tangling with a Docker-in-Docker setup (doable, but not considered best practices) or exposing the underlying Docker daemon. I’m not even sure that that second approach would work, since I think that it would interpret a volume mount against the node’s local filesystem, whereas in our scenario we want to volume mount /shared to a persistent Kubernetes volume. Maybe the Docker-in-Docker route would work, but then you’d also have a weird triple volume mount from inside the nested container into the outer container and from there to the persistent Kubernetes volume. That sounds… unwise.
However, essentially launcher bootstrap creates one large .yml file by processing the templates value in the app.yml and then passes that to the Discourse base image when finishes the bootstrap process. So if we can extract the configuration file we can generate the configuration on any machine and then we only need to figure out how to pass it to a container we start in the cloud.
So as an overview, here are the steps we are going to follow:
- Generate the bootstrap configuration using a modified
launcher - Pass that to a modified Discourse base image that will perform the bootstrapping (using
pups) and then start Discourse
Generating the Bootstrapping Configuration
Here’s the required change to launcher to support a dump command that writes the merged configuration to STDOUT:
run_dump() {
set_template_info
echo "$input"
}
(Note that this command is available in our fork of discourse_docker.)
So the first step is to use the new launcher dump command added above to create our bootstrap configuration:
# Substitute whatever your container configuration is called for app
./launcher dump app > bootstrap.yml
Initial Container Creation
Next we need a container that knows to run pups to bootstrap the container before booting via /sbin/boot. I used the following Dockerfile to make a tiny change to the base discourse image:
FROM discourse/base:2.0.20191219-2109
COPY scripts/bootstrap.sh /
CMD bash bootstrap.sh
Where scripts/bootstrap.sh contains:
cd /pups/ && /pups/bin/pups --stdin < /bootstrap/bootstrap.yml && /sbin/boot
I published this as geoffreychallen:discourse_base:2.0.20191219-2109. (Note that you could probably also accomplish the same thing by modifying the boot command of the base Discourse docker image, but I was having a hard time getting that to work with the shell redirection required to get pups to read the configuration file.)
Kubernetes Configuration
Now we need our Kubernetes configuration. Mine looks like this:
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: kotlin-forum-pvc
namespace: ikp
spec:
storageClassName: rook-ceph-block
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 64Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: kotlin-forum-deployment
namespace: ikp
spec:
replicas: 0
selector:
matchLabels:
app: kotlin-forum
template:
metadata:
labels:
app: kotlin-forum
spec:
volumes:
- name: kotlin-forum
persistentVolumeClaim:
claimName: kotlin-forum-pvc
- name: bootstrap
configMap:
name: kotlin-forum-bootstrap
containers:
- name: kotlin-forum
image: geoffreychallen/discourse_base:2.0.20191219-2109
imagePullPolicy: Always
volumeMounts:
- name: kotlin-forum
mountPath: /shared/
- name: bootstrap
mountPath: /bootstrap/
ports:
- containerPort: 80
env:
- name: TZ
value: "America/Chicago"
- name: LANG
value: en_US.UTF-8
- name: RAILS_ENV
value: production
- name: UNICORN_WORKERS
value: "3"
- name: UNICORN_SIDEKIQS
value: "1"
- name: RUBY_GLOBAL_METHOD_CACHE_SIZE
value: "131072"
- name: RUBY_GC_HEAP_GROWTH_MAX_SLOTS
value: "40000"
- name: RUBY_GC_HEAP_INIT_SLOTS
value: "400000"
- name: RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR
value: "1.5"
- name: DISCOURSE_DB_SOCKET
value: /var/run/postgresql
- name: DISCOURSE_DEFAULT_LOCALE
value: en
- name: DISCOURSE_HOSTNAME
value: kotlin-forum.cs.illinois.edu
- name: DISCOURSE_DEVELOPER_EMAILS
value: challen@illinois.edu
- name: DISCOURSE_SMTP_ADDRESS
value: outbound-relays.techservices.illinois.edu
- name: DISCOURSE_SMTP_PORT
value: "25"
---
apiVersion: v1
kind: Service
metadata:
name: kotlin-forum
namespace: ikp
spec:
type: NodePort
ports:
- name: http
port: 80
targetPort: 80
selector:
app: kotlin-forum
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
namespace: ikp
annotations:
nginx.ingress.kubernetes.io/ssl-redirect: "true"
name: kotlin-forum-ingress
spec:
rules:
- host: kotlin-forum.cs.illinois.edu
http:
paths:
- backend:
serviceName: kotlin-forum
servicePort: 80
Yours will look different. Note that I’m terminating HTTPS upstream, hence the modifications to the Ingress configuration. I also like to put everything in one file, delete pieces that don’t work as I iterate, and then let Kubernetes skip duplicates on the next kubectl create -f. Also note that I set replicas: 0 so that the deployment doesn’t start as soon as its configured. That’s because we have one bit of additional configuration to finish.
I copied the list of environment variables from what I saw being passed to the container by launcher start. I don’t know if all of these are necessary and others may be missing depending on your configuration. YMMV.
Note that we have two volume maps pointing into the container: the first is for postgres, configured as a persistent volume that will survive pod restarts. The second is a configuration mapping created like this:
kubectl create configmap kotlin-forum-bootstrap --from-file=bootstrap.yml=<path/to/bootstrap.yml>
Where kotlin-forum-bootstrap needs to match your Kubernetes configuration and path/to/bootstrap.yml is the path to the bootstrap.yml file we created using launcher dump above.
Once your configmap is in place, you should be able to scale your deployment to one replica and see Discourse booting and running the same bootstrap process that launcher bootstrap would have performed. That takes a few minutes. When that is done, your Discourse installation will boot.
Others Bits of Configuration
A few other notes that I ran on the way to getting this (at least for now) fully configured:
- Any upstream proxies must forward
X-Forwardedheaders, including bothX-Fowarded-For,X-Forwarded-Proto,X-Forwarded-Port. Not doing so will result in strange authentication errors when trying to use Google login and probably other login providers. - Your
nginxingress controller must be configured to pass headers by settinguse-forwarded-headersin the global config map. This took me a while to get right, since at least several times I edited the wrong configuration map, and then expected my ingress containers to restart when the configuration map changed. (They didn’t.)
Updating
To update the deployed installation, you regenerate the new bootstrap.yml file, update the config map, and then restart the container (easiest by scaling to 0 and then back to 1 replica).
This does incur a bit of downtime since the bootstrapping happens before the container is built. But this seems inevitable to me in cases where you need to update the configuration and/or change the base image. launcher rebuild is documented as stop; bootstrap; start, meaning that the bootstrap process will still cause downtime even if performed using the launcher script.
Comments
This fat container Discourse deployment pattern would be much easier to support if the launcher script would more cleanly separate (a) bootstrap steps that could be performed offline and only affect the files in the container and (b) bootstrap steps that modify or need access to the database or other state outside the container. The approach described above is a bit frustrating because you do see all kinds of JS uglification, asset minification, and other things that could be done with the previous deployment running… but they are just too mixed in with other things (like database migrations) that can’t be done without access to the database. I briefly thought about creating a container that would only perform the steps in templates/postgres.yml, but then noticed that database migrations were being done by the web template, and thought about plugins, and then just gave up .
With better separation redeployment for fat containers could work something like this:
- Build new fat container offline performing all steps internal to the container
- Publish that container
- When ready to upgrade, stop the previous container, start the new fat container, and let it finish any steps that need database access. Based on my experimentation those seem faster than some of the other bootstrap steps.
That would result in a bit less downtime. It’s probably not worth the effort for that reason alone, but I can imagine that this might also simplify more complex deployment scenarios involving shared databases or whatever.
6 Likes
That makes more sense. That’s what I did when separating in 2 steps the bootstrap stage. The 1st can run in an isolated environment (like a CI pipeline) generating a base image with the discourse repository, gems and plugins installed, and the 2nd step needs to run in the target machine (or at least have access to the production database) to do the db migration and generating the assets (this is done in the bootstrap process tough, not when starting the container).
Yes that would be awesome. I requested that already, but I don’t know if and when that will be done.
That would be difficult to implement completely on a separate environment because the assets precompile task needs access to the database (for things like custom css), but would be great if only what depends on the database could be made in a separate step (and all other assets, that don’t depend on the database, could be precompiled separately, but I don’t know how viable would be to implement it, technically).
That’s pretty much what I do on the kubernetes installs that I’ve done. I can’t imagine how or why to use k8s without separate data and web containers (or some other kind of external postgres and redis–the installs I’ve done for clients use GCP resources for that).
Also, there is an environment variable skip_post_migration_updates that you need to understand for true zero downtime upgrades. It’s described here.
8 Likes