How to Automate Container Deployment with GitLab ci-cd

GitLab ci-cd processes over 400 million pipeline minutes monthly, serving more than 30 million developers on a unified DevOps platform. With source code management, ci-cd, container registry, and security scanning all integrated, GitLab enables efficient container deployment automation to Kubernetes. Kubo supports GitLab ci-cd integration, enabling enterprise-grade deployment pipelines. This article walks through the practical steps for container deployment automation with GitLab ci-cd.

Secure Cluster Connection with the GitLab Kubernetes Agent

Traditional Kubernetes integrations required exposing the cluster API server to the internet. The GitLab Kubernetes Agent establishes a secure connection from inside the cluster, dramatically improving security.

Agent Architecture

The GitLab Agent uses a pull-based architecture. The agent runs inside the cluster and establishes an outbound connection to the GitLab server. This eliminates the need to expose the Kubernetes API server externally.

Agent Setup Steps

Register the agent: Register an agent in your GitLab project and obtain a token
Install with Helm:

bash

helm repo add gitlab https://charts.gitlab.io
helm repo update
helm upgrade --install gitlab-agent gitlab/gitlab-agent \
  --namespace gitlab-agent --create-namespace \
  --set config.token=<agent-token> \
  --set config.kasAddress=wss://kas.gitlab.com

Agent configuration file (.gitlab/agents/<agent-name>/config.yaml):

yaml

ci_access:
  projects:
    - id: your-group-your-project
  groups:
    - id: your-group

Up to 500 projects or groups can be linked to a single agent.

Access Control Through Impersonation

According to the GitLab official documentation, ci-cd jobs inherit all permissions from the service account used to install the agent by default. In production environments, always configure Impersonation to apply least-privilege access per job.

yaml

ci_access:
  projects:
    - id: your-group-your-project
      default_namespace: production
      access_as:
        impersonate:
          username: gitlab-ci-deploy
          groups:
            - deployers

Captain.AI helps teams navigate complex access control configurations with AI-guided setup assistance.

Building Pipelines with .gitlab-ci.yml

GitLab ci-cd pipelines are defined in .gitlab-ci.yml. Let's examine a typical pipeline configuration for container deployment.

Basic Pipeline Configuration

yaml

stages:
  - build
  - test
  - scan
  - deploy-staging
  - deploy-production

variables:
  IMAGE_TAG: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  KUBE_CONTEXT: your-group/your-project:production-agent

build:
  stage: build
  image: docker:27
  services:
    - docker:27-dind
  script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker build -t $IMAGE_TAG .
    - docker push $IMAGE_TAG

test:
  stage: test
  image: $IMAGE_TAG
  script:
    - npm ci
    - npm test

container-scan:
  stage: scan
  image:
    name: aquasec/trivy:latest
    entrypoint: [""]
  script:
    - trivy image --exit-code 1 --severity HIGH,CRITICAL $IMAGE_TAG

deploy-staging:
  stage: deploy-staging
  image:
    name: bitnami/kubectl:latest
    entrypoint: [""]
  script:
    - kubectl config use-context $KUBE_CONTEXT
    - kubectl set image deployment-my-app app=$image_tag -n staging
    - kubectl rollout status deployment-my-app -n staging
  environment:
    name: staging

deploy-production:
  stage: deploy-production
  image:
    name: bitnami/kubectl:latest
    entrypoint: [""]
  script:
    - kubectl config use-context $KUBE_CONTEXT
    - kubectl set image deployment-my-app app=$image_tag -n production
    - kubectl rollout status deployment-my-app -n production
  environment:
    name: production
  when: manual
  only:
    - main

Leveraging the GitLab Container Registry

GitLab includes a built-in container registry, eliminating the need for additional registry services. Predefined variables like $CI_REGISTRY, $CI_REGISTRY_USER, and $CI_REGISTRY_PASSWORD enable seamless authentication.

Automatic Pipelines with Auto DevOps

GitLab Auto DevOps builds pipelines automatically by detecting your application's language and framework---without writing a single line in .gitlab-ci.yml.

Auto DevOps Stages

Stage	Function	Tool
Auto Build	Dockerfile or buildpack detection	Cloud Native Buildpacks
Auto Test	Language-specific test execution	Language-specific tools
Auto Code Quality	Code quality analysis	Code Climate
Auto SAST	Static security testing	GitLab SAST
Auto Container Scanning	Container vulnerability scanning	Trivy
Auto Deploy	Kubernetes deployment	Helm
Auto Monitoring	Runtime monitoring	Prometheus

Integration with the Kubernetes Agent

When using the Kubernetes Agent with Auto DevOps, specify the agent context via the KUBE_CONTEXT variable.

yaml

# Set in ci-cd Variables
KUBE_CONTEXT: your-group/your-project:staging-agent  # For staging
# A different agent can be specified for the production environment

In Kubo's managed environment, Auto DevOps settings come pre-optimized, letting you start automatic pipelines right after project creation.

Multi-Environment Deployment Strategies

Production-grade deployments require different configurations and approval flows per environment.

Environment-Scoped Variables

yaml

# GitLab ci-cd Variables (configured in UI)
# Environment: staging
REPLICAS: 1
DB_HOST: staging-db.internal

# Environment: production
REPLICAS: 3
DB_HOST: production-db.internal

Dynamic Environments with Review Apps

yaml

review:
  stage: deploy-staging
  script:
    - kubectl config use-context $KUBE_CONTEXT
    - helm upgrade --install review-$ci_commit_ref_slug .-chart \
        --namespace review \
        --set image.tag=$CI_COMMIT_SHA \
        --set ingress.host=$CI_COMMIT_REF_SLUG.review.example.com
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: https://$CI_COMMIT_REF_SLUG.review.example.com
    on_stop: stop-review
  only:
    - merge_requests

stop-review:
  stage: deploy-staging
  script:
    - kubectl config use-context $KUBE_CONTEXT
    - helm uninstall review-$CI_COMMIT_REF_SLUG --namespace review
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop
  when: manual

Each merge request gets its own dynamic review environment where reviewers can test the actual application. Cleanup happens automatically or manually after merging.

Pipeline Optimization and Cost Efficiency

Caching Strategy

yaml

build:
  stage: build
  cache:
    key: $CI_COMMIT_REF_SLUG
    paths:
      - node_modules/
      - .npm/
  script:
    - npm ci --cache .npm --prefer-offline
    - npm run build

Parallelization with DAG

yaml

stages:
  - build
  - test
  - deploy

lint:
  stage: test
  needs: []  # Runs without waiting for build
  script:
    - npm run lint

unit-test:
  stage: test
  needs: ["build"]
  script:
    - npm test

e2e-test:
  stage: test
  needs: ["build"]
  script:
    - npm run e2e

Build DAG pipelines with the needs keyword to eliminate unnecessary wait times.

GitLab Runner Scaling

Integration with Amazon EKS Auto Mode enables up to 90% cost reduction through optimized Spot Instance usage. Kubo includes similar runner optimization capabilities built in.

Conclusion: Get Started with GitLab ci-cd on Kubo

GitLab ci-cd provides powerful container deployment automation as a unified DevOps platform. With secure Kubernetes Agent connections, automatic Auto DevOps pipelines, dynamic Review App environments, and DAG-based parallelization, you can build enterprise-grade deployment flows.

Kubo natively supports GitLab ci-cd integration, from Agent configuration to multi-environment deployment. Captain.AI's AI assistant helps optimize your pipelines, boosting GitLab ci-cd productivity even further. Ready to automate your container deployments? Contact us today.