This GitLab CI example needs a corresponding GitLab runner configuration - see https://github.com/jonashackt/gitlab-ci-stack#configure-a-docker-in-docker-enabled-gitlab-runner-with-the-docker-executor
See .gitlab-ci.yml:
# This .gitlab-ci.yml is an extension of the example provided in:
# https://github.com/jonashackt/restexamples/blob/master/.gitlab-ci.yml
# We use Docker in Docker here with a docker executor instead of the shell one
# --> Pinning the right Docker version for the service
image: docker:19.03.1
# Pinning the right Docker version for the service also
services:
- docker:19.03.1-dind
variables:
# see https://docs.gitlab.com/ee/ci/docker/using_docker_build.html#tls-enabled for Dind configuration
# DOCKER_HOST: tcp:https://docker:2375 --> this should only be configured when using Kubernetes runners
# When using dind, it's wise to use the overlayfs driver for
# improved performance.
DOCKER_DRIVER: overlay2
# Specify to Docker where to create the certificates, Docker will
# create them automatically on boot, and will create
# `/certs/client` that will be shared between the service and job
# container, thanks to volume mount from config.toml
DOCKER_TLS_CERTDIR: "/certs"
# see usage of Namespaces at https://docs.gitlab.com/ee/user/group/#namespaces
REGISTRY_GROUP_PROJECT: $CI_REGISTRY/root/gitlab-ci-dind-example
# One of the new trends in Continuous Integration/Deployment is to:
# (see https://docs.gitlab.com/ee/ci/docker/using_docker_build.html)
#
# 1. Create an application image
# 2. Run tests against the created image
# 3. Push image to a remote registry
# 4. Deploy to a server from the pushed image
stages:
- build
- test
- push
- deploy
# see how to login at https://docs.gitlab.com/ee/ci/docker/using_docker_build.html#using-the-gitlab-container-registry
before_script:
- docker login -u $CI_REGISTRY_USER -p $CI_JOB_TOKEN $CI_REGISTRY
build-image:
stage: build
# the tag 'dind' advices only GitLab runners using this tag to pick up that job
tags:
- dind
script:
- docker build . --tag $REGISTRY_GROUP_PROJECT/gitlab-ci-dind-example:latest
test-image:
stage: test
tags:
- dind
script:
- echo Insert fancy API test here!
push-image:
stage: push
tags:
- dind
script:
- docker push $REGISTRY_GROUP_PROJECT/gitlab-ci-dind-example:latest
deploy-2-dev:
stage: deploy
tags:
- dind
script:
- echo You should use Ansible here!
environment:
name: dev
url: https://dev.jonashackt.io
Possible optimisation: Making docker-in-docker builds faster with Docker layer caching: As the Docker Engine used with Docker-in-Docker will download the images every time the pipeline starts a build, it will slow down your builds. Here the --cache-from argument of the docker run command can help.
Big problem: The "new trends in Continuous Integration/Deployment" aren't applieable with Docker-in-Docker - those are:
# One of the new trends in Continuous Integration/Deployment is to:
# (see https://docs.gitlab.com/ee/ci/docker/using_docker_build.html)
#
# 1. Create an application image
# 2. Run tests against the created image
# 3. Push image to a remote registry
# 4. Deploy to a server from the pushed image
stages:
- build
- test
- push
- deploy
Since we do our docker build inside the build stage - and the Pipeline tries to push the resulting Docker image in the push stage - but images aren't shared or kept up over stages - we can't implement this desired workflow. For more info, have a look at the overview ASCII art here: https://github.com/jonashackt/gitlab-ci-stack#configure-a-docker-in-docker-enabled-gitlab-runner-with-the-docker-executor
One possible workaround is to skip the 4 phases and do just a build_push, then test and then deploy - which brings the drawback of "releasing" un-tested images to our registry:
stages:
- build_push
- test
- deploy
Start the app and go to http:https://localhost:8080/v2/api-docs to see all endpoints as JSON.
UI-Documentation you will find under http:https://localhost:8080/swagger-ui.html.