We want to deploy a Rails application on Kubernetes.
We assume that the
assets:precompile task would be
run as part of the Docker image build process.
We want to run rake tasks such as
on the initial deployment,
db:migrate task on each later deployment.
We cannot run these tasks while building the Docker image as it would not be able to connect to the database at that moment.
So, how to run these tasks?
We assume that we have a Docker image
which contains the source code for our Rails application.
We also assume that we have included
in this Docker image
with the required configuration needed for connecting to the database.
We need to create a Kubernetes deployment template with the following content.
Let’s save this template file as
We can change the options and environment variables in above template as per our need. The environment variables specified here will be available to our Rails application.
To apply above template for the first time on Kubernetes, we will use the following command.
Later on, to apply the same template after modifications such as change in the Docker image name or change in the environment variables, we will use the following command.
After applying the deployment template, it will create a pod for our application on Kuberentes.
To see the pods, we use the following command.
Let’s say that our app is now running
in the pod named
To execute a rake task, for e.g.
db:migrate on this pod,
we can run the following command.
Similarly, we can execute
db:seed rake task as well.
If we already have an automated flow for deployments on Kubernetes, we can make use of this approach to programmatically or conditionally run any rake task as per the needs.
Why not to use Kubernetes Jobs to solve this?
We faced some issues while using Kubernetes Jobs to run migration and seed rake tasks.
If the rake task returns a non-zero exit code, the Kubernetes job keeps spawning pods until the task command returns a zero exit code.
To get around the issue mentioned above we needed to unnecessarily implement additional custom logic of checking job status and the status of all the spawned pods.
Capturing the command’s STDOUT or STDERR was difficult using Kubernetes job.
Some housekeeping was needed such as manually terminating the job if it wasn’t successful. If not done, it will fail to create a Kubernetes job with the same name, which is bound to occur when we perform later deployments.
Because of these issues, we choose not to rely on Kubernetes jobs to solve this problem.