Step 2/3: Using Gitlab as Docker-Registry

In my previous posts (Introduction, Step 1), I described the main problem and we developed our own and first pipeline, which includes executing a test environment. Only if all tests passes, the commit will be accepted and the other stages will be executed afterwards.

If we take a look at our overview image, we developed now all the source code for the first second processes. The next step is to push our code (wrapped in a docker-container) to a registry.

gitlab_ci_ecs

 

Thereby, we take a look at our existing gitlab-ci file:

stages:
  - testing
  - build      # <-- part of this tutorial
  - release    # part of third part of the tutorial

testsuite_image:
  staging: testing
  image: node:6.9.1
  script:
   - npm install
   - DATABASE_URL=mongodb://mongo:27017/mydb npm test
  services:
   - mongo:3.2

The build and push to a registry process is now wrapped in the stage build. We want that our script is only executed for the master branch and do this in the build stage. The process is very simple:

  1. Login to docker registry (in our case: Gitlab Registry)
  2. Build our container and tag the resulting image (using the option -t) with the new registry URL (overwrite existing versions)
  3. Tag the container image also with the unique build ID to allow versioning
  4. Push both images to the gitlab registry

 

In practise, this can look like that:

stages:
  - testing
  - build      
  - release    # part of third part of the tutorial

build_image:
  stage: build   # build image only after test passed
  only: [master] # build and push images only for master branch commits
  image: docker:git # use simply git docker image
  services:
    - docker:dind
  script:
    - docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN registry.gitlab.com
    - docker build -t registry.gitlab.com/NAMESPACE/PROJECT .
    - docker tag registry.gitlab.com/NAMESPACE/PROJECT registry.gitlab.com/NAMESPACE/PROJECT:$CI_BUILD_REF
    - docker push registry.gitlab.com/NAMESPACE/PROJECT:$CI_BUILD_REF
    - docker push registry.gitlab.com/NAMESPACE/PROJECT

testsuite_image:
  staging: testing
  image: node:6.9.1
  script:
   - npm install
   - DATABASE_URL=mongodb://mongo:27017/mydb npm test
  services:
   - mongo:3.2

Our project PROJECT is saved in a namespace called NAMESPACE. In practise, such a namespace can be the name of your fancy project and the project name is a component of your project.
Example:
Namespace: my_fancy_webshop
Project: customer_api
In this case, we would replace the placeholders NAMESPACE and PROJECT with these values. But the registry url can also be retrieved by clicking on the tab “Registry” right next to the Pipelines tab in the navigation of a project. Example:

pipelines

Unfortunately, finding out the correct registry URL is always very uncomfortable. So we will automate this step by simply using a predefined variable of Gitlab:

$CI_PROJECT_PATH

This variable will return directly the namespace and the project name, concadinated by a separator. E.g. $CI_PROJECT_PATH=my_fancy_webshop/customer_api

So, we can update our gitlab yml file like the following:

stages:
  - testing
  - build      
  - release    # part of third part of the tutorial

build_image:
  stage: build   # build image only after test passed
  only: [master] # build and push images only for master branch commits
  image: docker:git # use simply git docker image
  services:
    - docker:dind
  script:
    - docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN registry.gitlab.com
    - docker build -t registry.gitlab.com/$CI_PROJECT_PATH .
    - docker tag registry.gitlab.com/$CI_PROJECT_PATH registry.gitlab.com/$CI_PROJECT_PATH:$CI_BUILD_REF
    - docker push registry.gitlab.com/$CI_PROJECT_PATH:$CI_BUILD_REF
    - docker push registry.gitlab.com/$CI_PROJECT_PATH

testsuite_image:
  staging: testing
  image: node:6.9.1
  script:
   - npm install
   - DATABASE_URL=mongodb://mongo:27017/mydb npm test
  services:
   - mongo:3.2

 

Now, you can receive your docker images from the following URL (with the predefined project name and namespace):

https://registry.gitlab.com/my_fancy_webshop/customer_api

 

The next step is to use this docker registry for our ECS instances. A possible workflow can be that if the master image is built successfully, the ECS instances can updated that a new release image exists.

Next chapter

 

* also other unique version tags can be used, for instance git tags or something else. All possible variables (like variable for the current branch) can be found here: https://docs.gitlab.com/ce/ci/variables/

Leave a Reply

Your email address will not be published. Required fields are marked *