Practical Guide to GitLab CI/CD for Microservice Projects

Background

As the company increasingly adopts GitLab for project management, the frequency of business releases has risen, demanding higher release efficiency. Since 2012, GitLab has integrated Continuous Integration (CI) and Continuous Delivery (CD) capabilities. This article shares practical experiences with these features.

Fundamentals

GitLab CI/CD provides a complete set of services for the software delivery workflow without requiring external tools.

Terminology

GitLab Pipeline

A pipeline represents a full build task that can include multiple steps such as installing dependencies, running tests, compiling code, and deploying to test or production servers. Pipelines can be triggered by any commit or Merge Request.

GitLab Stage

A stage is a build phase within a pipeline. Stages are defined in order and execute serially; a later stage starts only after the previous one succeeds. If any stage fails, the entire pipeline fails.

GitLab Job

A job is a unit of work executed within a stage. Jobs in the same stage run in parallel, and the stage succeeds only when all its jobs succeed.

.gitlab-ci.yml Configuration

The pipeline definition is written in a .gitlab-ci.yml file placed at the repository root. The file uses YAML syntax; see the official documentation for details.

GitLab Runner Installation

The runner executes the jobs defined in .gitlab-ci.yml . Install the runner from the official repository:

# For Debian/Ubuntu/Mint
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash

# For RHEL/CentOS/Fedora
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh | sudo bash

Install a specific version (e.g., 11.11.4):

# for DEB based systems
sudo apt-get install gitlab-runner=11.11.4

# for RPM based systems
sudo yum install gitlab-runner-11.11.4

Obtain the runner token from Settings → CI/CD → Runners → Collapse and register the runner with the GitLab instance.

Practical Implementation

Continuous Integration (CI)

The CI process compiles code, builds a Docker image, and pushes it to GitLab's built‑in container registry.

Docker Image Build

Example Dockerfile used for the system‑level image:

FROM debian:stretch

# Add software packages
ADD soft/ /data/soft/

# Install base utilities
RUN DEBIAN_FRONTEND=noninteractive apt-get update \
    && DEBIAN_FRONTEND=noninteractive apt-get install -y vim htop wget ...

# Install development tools
RUN DEBIAN_FRONTEND=noninteractive apt-get update \
    && apt-get install -y python python-pip gcc g++ ...

# Install Python 3.7
RUN cd /data/soft/ && tar xf /data/soft/Python-3.7.0.tgz && cd Python-3.7.0 \
    && ./configure --enable-optimizations --with-ssl-default-suites=openssl --enable-shared \
    && make && make install && cp libpython3.7m.so.1.0 /lib64/ && ldconfig && rm -rf /data/soft

# Entry point script
COPY entrypoint.sh /sbin/entrypoint.sh
ENTRYPOINT ["/bin/bash", "-x", "/sbin/entrypoint.sh"]

Push the built image:

build_push:
  only:
    refs:
      - tags
    variables:
      - $CI_COMMIT_REF_NAME =~ /^rel_[0-9].*$/
  tags:
    - docker
  stage: ex_build
  script:
    - docker login $DOCKER_REGISTRY
    - docker pull $BUILD_IMAGE   # ensure latest base image
    - docker build --no-cache -t $image .
    - docker tag $image $latest
    - docker push $image
    - docker push $latest
    - docker logout $DOCKER_REGISTRY
  when: manual
  allow_failure: false
  environment:
    name: build

Continuous Delivery (CD)

Deployment is performed by invoking a custom service that calls the Kubernetes API to release the new container image.

deployment_production:
  only:
    refs:
      - tags
    variables:
      - $CI_COMMIT_REF_NAME =~ /^exrel_[0-9].*$/
  tags:
    - docker
  stage: ex_deployment_production
  script:
    - deploy_service $CI_ENVIRONMENT_NAME "$image"
  when: manual
  environment:
    name: production

Release Process

Microservice releases are divided into two types: regular releases (re‑building containers) and hot‑update releases (updating content in etcd without rebuilding containers). Diagrams illustrate each workflow.

Results

Screenshots show the pipeline execution for both regular and hot‑update releases, demonstrating successful builds, pushes, and deployments.

References

https://about.gitlab.com/product/continuous-integration

https://docs.gitlab.com/ce/ci/introduction/index.html