Last time we set up the “CI” portion of our “CI / CD” pipeline. Today we’ll look at building out a Docker image of our application on GitLab. In a subsequent post we’ll use this image in a Kubernetes deployment. So let’s get at it!
If you’ve been following along you can continue with the code from part 1 (thou you’ll want to fix the
credo warning that was failing our pipeline at the end of that post) or you can clone the code.
Clone the Repo:
Note: if cloning, you’ll need to run
npm install after grabbing the code.
Create a branch
Now let’s create a branch for today’s work.
The first thing we need to do is create a release for our application along with a Dockerfile. Once we have all the pieces in place to build a release and docker image locally, we can move onto doing so on GitLab.
Creating the release and docker file
We will be leaning heavily on this excellent article (https://akoutmos.com/post/multipart-docker-and-elixir-1.9-releases/) by Alex Koutmos to guide us through the creation of a release and a docker image. I’d highly recommend you give it a read. It explains the process much better than I could, and since there is already a great resource explaining releases / docker images, I won’t go into an in depth discussion here.
Note: the Dockerfile we’ll be using differs somewhat from the one in the above linked article, as we need to build Phoenix not just Elixir.
Creating the release
Our first step is to create the release files and configuration.
Our release configuration makes use of a number of environment settings. This is so we can use different values for different environments, i.e. locally, staging, production.
releases.exs file in place, we can get rid of
prod.secret.exs as these items have all been included in
In order to build the production release we do need an empty
prod.exs file however, so we’ll add an empty file to replace the one we just removed.
Now let’s test the release by running it on our local machine.
First we’ll take care of our assets.
Next, we’ll build the release.
Now we can run the release. We’ll need to pass in the required environment settings (note: adjust the values to your local settings, i.e. your local Postgres user etc).
Fantastic, looks like the release is working.
Creating the Dockerfile
The first step is to create the file.
We’re utilizing a
start_commands.sh script as our entrypoint, so we need to create it.
start_commands script calls out to a release tasks module prior to starting the application. We’ll use the release tasks module to run our migrations. We can’t do so via
mix as we don’t have access to
mix tasks from within the release.
Let’s create the module now.
Pretty simple, all we are doing is running thru the migrations via
That should do it for our docker image. Let’s make sure the image builds and works locally before attempting to get it building on GitLab.
We’ve added new code to our application, so we need to rebuild the release.
Choose to over-write the existing release:
Now we can build the Docker image (you’ll need to have Docker Desktop installed locally).
Let’s test that the Docker image runs. In order to also test that the migration in our start up script works, let’s drop and re-create the database.
Now we’ll run the image.
The migrations are run and the application starts up!
That takes care of our Dockerfile… we’re now ready to integrate this into our GitLab pipeline.
Building the Docker image on GitLab
In order to get our image building on GitLab we need to add a new stage and local reference to the main
Now we’ll create the
A few key points regarding the above. We’re specifying the stage as
docker in the
stage section. Then we’re using the GitLab auto-build-image and the docker in docker service as the technique to build our docker image. In the
script section we are uploading the result of the build to the GitLab container registry. This is so it will be available down the line when we want to deploy the image. Also note the commented out
when: manual section. If you don’t want an image built on every check-in, setting this to manual accomplishes this (when set to manual you need to click the
build_docker job in the GitLab UI for it to run).
Before pushing to GitLab, let’s run
mix format so that we won’t hit any linting errors when we push.
Let’s also update our
coveralls configuration. We don’t have any tests for the
release_tasks.ex module we created, so we’ll add it to the list of files we’re ignoring.
With all that out of the way, let’s give things a go by pushing to GitLab.
If we view our GitLab pipeline, we’ll now see a new stage:
After a few minutes, our four jobs should show as complete:
Finally if we navigate to the GitLab container registry, we’ll see the docker image has been uploaded to the registry.
Pretty awesome! We now have a docker build included as part of our pipeline. Next time out we’ll get around to seeing how to go about doing some deployments!
Thanks for reading, hope you enjoyed the post!