87 lines
2.8 KiB
Markdown
87 lines
2.8 KiB
Markdown
|
---
|
|||
|
layout: post
|
|||
|
title: Testing Your Docker Images with GitLab CI
|
|||
|
tag:
|
|||
|
- continuous-integration
|
|||
|
- gitlab
|
|||
|
- docker
|
|||
|
- devops
|
|||
|
---
|
|||
|
|
|||
|
I have been using [GitLab](https://about.gitlab.com) for over four years. My
|
|||
|
[first commit](https://github.com/gitlabhq/gitlabhq/commit/0760ba3efb7566b9f56bb066f4b15ba8ea34e1e7)
|
|||
|
to the project came nearly three years ago. And although I was pretty
|
|||
|
disappointed when they began
|
|||
|
[releasing an enterprise edition](https://about.gitlab.com/2013/07/22/announcing-gitlab-enterprise-edition/),
|
|||
|
the community edition of the project remains impressive. More recently, GitLab
|
|||
|
has included a
|
|||
|
[continuous integration software](https://about.gitlab.com/gitlab-ci/) along
|
|||
|
with their code collaboration solution.
|
|||
|
|
|||
|
Recently, I have been using this to produce [Docker](https://www.docker.com/)
|
|||
|
images for my production environment. Although I had been using Docker for all
|
|||
|
of my build stages, I was never using the image I was producing for validation.
|
|||
|
Since I want to be as sure as I can that my production images are functioning, I
|
|||
|
decided to update my build to use the project Dockerfile to run tests.
|
|||
|
|
|||
|
I looked around and found a
|
|||
|
[few](http://sirile.github.io/2016/09/29/minimal-go-containers-with-docker-and-gitlab-ci.html)
|
|||
|
[articles](https://www.andrewmunsell.com/blog/ci-cd-with-docker-containers/) on
|
|||
|
using Docker with Gitlab CI. Unfortunately, they all outlined methods that
|
|||
|
[did not test the image](https://www.stefanwienert.de/blog/2015/11/07/gitlab-ci-with-docker-starting-guide/)
|
|||
|
directly or did so in a
|
|||
|
[complicated way](http://blog.lwolf.org/post/How-to-build-and-test-docker-images-in-gitlab-ci/).
|
|||
|
I thought I could do better.
|
|||
|
|
|||
|
We always want to use Docker for our builds, but running Docker inside of Docker
|
|||
|
is not recommended. To resolve this, we can mount the host system’s Docker
|
|||
|
socket inside the container when creating our test runner for building images.
|
|||
|
|
|||
|
```
|
|||
|
[[runners]]
|
|||
|
name = "docker-runner"
|
|||
|
url = "https://gitlab.example.com/ci"
|
|||
|
token = "YOUR_TOKEN"
|
|||
|
executor = "docker"
|
|||
|
[runners.docker]
|
|||
|
tls_verify = false
|
|||
|
image = "docker:latest"
|
|||
|
privileged = false
|
|||
|
disable_cache = false
|
|||
|
volumes = ["/var/run/docker.sock:/var/run/docker.sock"]
|
|||
|
```
|
|||
|
|
|||
|
Now that we are using the host Docker, we can leverage its image storage and
|
|||
|
caching for our build. We can also use that image in our other build tasks.
|
|||
|
|
|||
|
```
|
|||
|
stages:
|
|||
|
- prepare
|
|||
|
- test
|
|||
|
- deploy
|
|||
|
|
|||
|
build-test-container:
|
|||
|
stage: prepare
|
|||
|
script:
|
|||
|
- docker build -t your-image .
|
|||
|
tags:
|
|||
|
- your-docker-tag
|
|||
|
|
|||
|
spec:
|
|||
|
stage: test
|
|||
|
script:
|
|||
|
- bundle exec rake db:create db:migrate
|
|||
|
- bundle exec rspec
|
|||
|
image: your-image
|
|||
|
services:
|
|||
|
- postgres:latest
|
|||
|
|
|||
|
# ...
|
|||
|
```
|
|||
|
|
|||
|
The container built from our project Dockerfile is now being directly tested by
|
|||
|
our continuous integration. As you can see, we can also use any container links
|
|||
|
without writing extra code.
|
|||
|
|
|||
|
Clean and simple!
|