Building an Enterprise‑Ready Docker Platform: Harbor Registry, GitLab CI, and Prometheus Monitoring

Enterprises need more than a simple docker run; they must address image storage, automated release pipelines, and real‑time observability. The article explains why a private registry is essential and positions Harbor as the preferred solution because it avoids Docker Hub rate limits, satisfies security and compliance, provides built‑in vulnerability scanning, and offers fine‑grained RBAC.

Harbor installation

The author recommends a minimum of 2 CPU / 4 GB RAM (production 4 CPU / 8 GB) on CentOS 7 or Ubuntu 20.04, then downloads the offline installer (v2.11.0) and extracts it.

# wget https://github.com/goharbor/harbor/releases/download/v2.11.0/harbor-offline-installer-v2.11.0.tgz
# tar xvf harbor-offline-installer-v2.11.0.tgz
# cd harbor

After copying harbor.yml, the key fields are set: hostname, HTTP/HTTPS ports, certificate paths, admin password, and data volume. Enabling HTTPS avoids the need for --insecure-registry on clients.

# ./install.sh --with-trivy   # install with vulnerability scanner
# docker ps --filter name=harbor   # verify all Harbor containers are running

Once the web UI is reachable at https://harbor.yourcompany.com, developers can log in and create projects.

Client integration

Developers log in, tag images with the fully qualified Harbor address, and push them:

# docker login harbor.yourcompany.com
# docker tag nginx:latest harbor.yourcompany.com/library/nginx:latest
# docker push harbor.yourcompany.com/library/nginx:latest

The required tag format is harbor‑address/project/image:tag.

CI/CD pipeline with GitLab CI

The pipeline consists of three stages—Build, Test, Deploy. The .gitlab-ci.yml example defines variables for the registry and image name, builds and pushes the image, runs container‑based tests, and finally SSHes into the production host to pull and redeploy.

stages:
  - build
  - test
  - deploy
variables:
  REGISTRY: harbor.yourcompany.com
  IMAGE_NAME: $REGISTRY/$CI_PROJECT_PATH_SLUG
build_image:
  stage: build
  script:
    - docker build -t $IMAGE_NAME:$CI_COMMIT_SHORT_SHA .
    - docker push $IMAGE_NAME:$CI_COMMIT_SHORT_SHA
run_tests:
  stage: test
  script:
    - docker run --rm $IMAGE_NAME:$CI_COMMIT_SHORT_SHA pytest
deploy_prod:
  stage: deploy
  script:
    - ssh deploy@prod "docker pull $IMAGE_NAME:$CI_COMMIT_SHORT_SHA"
    - ssh deploy@prod "docker‑compose up -d --force-recreate"
  only:
    - main

Key recommendations include using the short commit SHA as the image tag (ensuring traceability and easy rollback), granting the GitLab Runner Docker privileges, and pre‑loading the runner’s SSH public key on the target host.

Monitoring and alerting stack

The author assembles Prometheus, Grafana, cAdvisor, and Alertmanager via docker‑compose. Each component’s role is clarified: cAdvisor scrapes container metrics, Prometheus stores them, Grafana visualises them, and Alertmanager routes alerts.

version: "3"
services:
  prometheus:
    image: prom/prometheus:latest
    ports: ["9090:9090"]
    volumes: ["./prometheus.yml:/etc/prometheus/prometheus.yml"]
  grafana:
    image: grafana/grafana:latest
    ports: ["3000:3000"]
  cadvisor:
    image: gcr.io/cadvisor/cadvisor:latest
    ports: ["8080:8080"]
    volumes:
      - /:/rootfs:ro
      - /var/run:/var/run:rw
  alertmanager:
    image: prom/alertmanager:latest
    ports: ["9093:9093"]

Prometheus is configured to scrape cAdvisor every 15 seconds and to discover Docker containers via the Unix socket.

global:
  scrape_interval: 15s
  evaluation_interval: 15s
scrape_configs:
  - job_name: "docker-host"
    static_configs:
      - targets: ["cadvisor:8080"]
  - job_name: "containers"
    docker_sd_configs:
      - host: "unix:///var/run/docker.sock"

Two alert rules are provided: HighCPUUsage (warning when CPU > 80 % for 5 minutes) and ContainerOOMKilled (critical when a container is OOM‑killed). Alerts can be sent to DingTalk, WeChat, email, or PagerDuty via Alertmanager webhooks.

Grafana dashboards

After adding Prometheus as a data source, the author suggests importing community dashboard ID 193 to view CPU, memory, restart count, and network traffic per container.

Production pitfalls

Plan Harbor storage (use NFS or S3) to avoid disk exhaustion.

Cache Docker layers in CI builds; place infrequently‑changed layers early in the Dockerfile and enable BuildKit.

Persist Prometheus data with a host‑mounted volume; otherwise data is lost on container restart.

Group alerts in Alertmanager to prevent alert storms from many containers on a single host.

Use minimal base images (e.g., alpine) and multi‑stage builds to shrink image size.

Conclusion

Combining Harbor for secure image storage, GitLab CI for automated build‑push‑deploy, and Prometheus‑Grafana‑Alertmanager for observability yields a production‑ready Docker platform. The article notes that this is only the first step; further topics such as service mesh, Kubernetes orchestration, and service discovery remain for future exploration.