Forem: Booranasak Kanthong

Kong Cluster

Booranasak Kanthong — Sun, 14 Sep 2025 15:51:20 +0000

🚦 Kong Cluster 101 (Beginner-friendly)

What is a “Kong Cluster”?

In practice, a Kong Cluster just means you run multiple Kong gateway nodes side-by-side so traffic can:

spread across nodes (load balancing for throughput), and
keep flowing even if one node dies (high availability/failover).

In your setup:

kong-1 and kong-2 are two gateway nodes.
They share the same Postgres database (your kong-ce-database) so they read/write the same configuration.
HAProxy (haproxy service) sits in front to split incoming requests across kong-1 and kong-2.

Enterprise note (for later): Kong Enterprise supports a “hybrid” CP/DP model. For OSS/CE, clustering typically means “multiple data planes behind a load balancer using the same DB,” which is exactly what we’re doing here.

Why put a Load Balancer in front of Kong?

A load balancer (LB) like HAProxy:

Distributes requests across nodes (round-robin by default).
Health checks each node and stops sending traffic to unhealthy nodes (automatic failover).
Gives you one stable endpoint to point apps at (no app-side juggling of multiple Kong hosts).

Your compose already includes HAProxy. We’ll finish it with a tiny config (your version).

🧩 Use your `docker-compose.yml` (what you already have)

You’ve done 90% of the heavy lifting. Here’s what’s in place:

Postgres 13 for Kong (DB mode)
One-time migrations
Two Kong nodes (different admin/proxy ports)
HAProxy (front door)
Mongo + Konga (nice UI)
(Optional) Kong Dashboard

We’ll add:

a HAProxy config file (yours, including X-Served-By + admin LB),
two tiny upstream services to demonstrate failover (httpbin), and
a Kong upstream with active health checks.

1) HAProxy: load-balance Kong nodes (your config)

Create ./haproxy/haproxy.cfg next to your compose file:

global
  maxconn 4096

defaults
  # keep tcp as a safe default; we'll override per section
  mode tcp
  timeout connect 5s
  timeout client  30s
  timeout server  30s

# ===== Proxy LB (9200) — must be HTTP to inject headers =====
frontend fe_proxy
  bind *:9200
  mode http
  option forwardfor                     # add X-Forwarded-For for client IP
  default_backend be_kong

backend be_kong
  mode http
  balance roundrobin
  http-response add-header X-Served-By %[srv_name]   # <-- shows kong1/kong2
  server kong1 kong-1:8000 check inter 2000 rise 3 fall 2
  server kong2 kong-2:18000 check inter 2000 rise 3 fall 2

# ===== Admin LB (9201) — leave as HTTP, no need to add headers here =====
frontend fe_admin
  bind *:9201
  mode http
  default_backend be_admin

backend be_admin
  mode http
  option httpchk GET /
  balance roundrobin
  server kong1 kong-1:8001 check inter 2000 rise 3 fall 2
  server kong2 kong-2:18001 check inter 2000 rise 3 fall 2

Exposes http://localhost:9200 (proxy LB) and http://localhost:9201 (admin LB).
The proxy LB injects X-Served-By so you can see which Kong node handled the request.

2) Full `docker-compose.yml` (merged + test apps)

Save this as your compose file (it’s your original, plus: HAProxy port 9201 and two httpbin services).

# Shared Kong DB config (CE/OSS)
x-kong-config: &kong-env
  KONG_DATABASE: postgres
  KONG_PG_HOST: kong-ce-database
  KONG_PG_DATABASE: kong
  KONG_PG_USER: kong
  KONG_PG_PASSWORD: kong

services:
  # ------------------------------
  # Postgres 13 for Kong (CE/OSS)
  # ------------------------------
  kong-ce-database:
    image: postgres:13
    container_name: kong-ce-database
    environment:
      POSTGRES_USER: kong
      POSTGRES_DB: kong
      POSTGRES_PASSWORD: kong
    volumes:
      - kong_db_data:/var/lib/postgresql/data
    networks: [kong-ce-net]
    ports:
      - "5432:5432"    # optional: expose for local access
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U kong -d kong"]
      interval: 10s
      timeout: 5s
      retries: 20
    restart: unless-stopped

  # ------------------------------
  # One-time Kong migrations
  # ------------------------------
  kong-migrations:
    image: kong:3.9.1
    container_name: kong-migrations
    depends_on:
      kong-ce-database:
        condition: service_healthy
    environment:
      <<: *kong-env
    entrypoint: >
      /bin/sh -lc
      "kong migrations bootstrap -v || (kong migrations up -v && kong migrations finish -v)"
    networks: [kong-ce-net]
    restart: "no"

  # ------------------------------
  # Kong Gateway node #1
  # ------------------------------
  kong-1:
    image: kong:3.9.1
    container_name: kong-1
    depends_on:
      kong-ce-database:
        condition: service_healthy
      kong-migrations:
        condition: service_completed_successfully
    environment:
      <<: *kong-env
      KONG_ADMIN_LISTEN: "0.0.0.0:8001,0.0.0.0:8444 ssl"
    ports:
      - "8000:8000"   # proxy
      - "8443:8443"   # proxy ssl
      - "8001:8001"   # admin
      - "8444:8444"   # admin ssl
    healthcheck:
      test: ["CMD", "kong", "health"]
    networks: [kong-ce-net]
    restart: unless-stopped

  # ------------------------------
  # Kong Gateway node #2 (different internal ports)
  # ------------------------------
  kong-2:
    image: kong:3.9.1
    container_name: kong-2
    depends_on:
      kong-ce-database:
        condition: service_healthy
      kong-migrations:
        condition: service_completed_successfully
    environment:
      <<: *kong-env
      KONG_ADMIN_LISTEN: "0.0.0.0:18001,0.0.0.0:18444 ssl"
      KONG_PROXY_LISTEN: "0.0.0.0:18000,0.0.0.0:18443 ssl"
    ports:
      - "8002:18000"  # proxy (host)
      - "18443:18443" # proxy ssl (host)
      - "18001:18001" # admin (host)
      - "18444:18444" # admin ssl (host)
    healthcheck:
      test: ["CMD", "kong", "health"]
    networks: [kong-ce-net]
    restart: unless-stopped

  # ------------------------------
  # HAProxy to load-balance kong-1 / kong-2
  # ------------------------------
  haproxy:
    image: haproxy:2.9
    container_name: kong-haproxy
    networks: [kong-ce-net]
    depends_on:
      kong-1:
        condition: service_started
      kong-2:
        condition: service_started
    ports:
      - "9200:9200"   # proxy LB
      - "9201:9201"   # admin LB
    volumes:
      - ./haproxy/haproxy.cfg:/usr/local/etc/haproxy/haproxy.cfg:ro
    command: ["/usr/local/sbin/haproxy","-f","/usr/local/etc/haproxy/haproxy.cfg","-db"]
    restart: unless-stopped

  # ------------------------------
  # MongoDB 4.4 for Konga
  # ------------------------------
  mongo:
    image: mongo:4.4
    container_name: mongo
    volumes:
      - mongo_data:/data/db
    networks: [kong-ce-net]
    ports:
      - "27017:27017"   # optional
    healthcheck:
      test: ["CMD", "mongo", "--eval", "db.runCommand({ ping: 1 })"]
      interval: 10s
      timeout: 5s
      retries: 20
    restart: unless-stopped

  # ------------------------------
  # Konga DB prepare (Mongo)
  # ------------------------------
  konga-prepare:
    image: pantsel/konga:latest
    container_name: konga-prepare
    depends_on:
      mongo:
        condition: service_healthy
    command: -c prepare -a mongo -u mongodb://mongo:27017/konga
    networks: [kong-ce-net]
    restart: "no"

  # ------------------------------
  # Konga (Admin UI) on Mongo
  # ------------------------------
  konga:
    image: pantsel/konga:latest
    container_name: konga
    depends_on:
      mongo:
        condition: service_healthy
      konga-prepare:
        condition: service_completed_successfully
    environment:
      DB_ADAPTER: mongo
      DB_HOST: mongo
      DB_PORT: 27017
      DB_DATABASE: konga
      NODE_ENV: production
    ports:
      - "1337:1337"
    networks: [kong-ce-net]
    restart: unless-stopped

  # ------------------------------
  # KongDash (optional)
  # ------------------------------
  kongdash:
    image: pgbi/kong-dashboard:v2
    container_name: kongdash
    command: ["start", "--kong-url", "http://kong-1:8001"]
    depends_on:
      kong-1:
        condition: service_started
    ports:
      - "8085:8080"
    networks: [kong-ce-net]
    restart: unless-stopped

  # ------------------------------
  # Test upstream apps for failover
  # ------------------------------
  httpbin1:
    image: mccutchen/go-httpbin:v2.15.0
    container_name: httpbin1
    networks: [kong-ce-net]
    restart: unless-stopped

  httpbin2:
    image: mccutchen/go-httpbin:v2.15.0
    container_name: httpbin2
    networks: [kong-ce-net]
    restart: unless-stopped

volumes:
  kong_db_data: {}       # Postgres data for Kong
  mongo_data: {}         # Mongo data for Konga

networks:
  kong-ce-net:
    driver: bridge

Bring everything up:

docker compose up -d

3) Configure Kong (via Admin API) for upstream failover

We’ll create:

an Upstream (logical name) with
two Targets (httpbin1 & httpbin2), plus
active health checks so Kong can remove a bad target automatically,
a Service pointing to the upstream, and
a Route to expose it.

Run these against either Admin API (e.g. http://localhost:8001 for kong-1 or http://localhost:18001 for kong-2).

3.1 Upstream with health checks

curl -sS -X POST http://localhost:8001/upstreams \
  -H "Content-Type: application/json" \
  -d '{
    "name": "demo-upstream",
    "healthchecks": {
      "active": {
        "http_path": "/status/200",
        "timeout": 1,
        "healthy": { "interval": 5, "successes": 1 },
        "unhealthy": { "interval": 5, "http_failures": 1, "tcp_failures": 1, "timeouts": 1 }
      }
    }
  }'

In Konga -> UPSTREAMS

3.2 Register the two targets

curl -sS -X POST http://localhost:8001/upstreams/demo-upstream/targets \
  -H "Content-Type: application/json" \
  -d '{"target":"httpbin1:8080","weight":100}'

curl -sS -X POST http://localhost:8001/upstreams/demo-upstream/targets \
  -H "Content-Type: application/json" \
  -d '{"target":"httpbin2:8080","weight":100}'

In Konga -> UPSTREAMS -> Click at Detail

Then Click Targets

3.3 Create a Service using the upstream

curl -sS -X POST http://localhost:8001/services \
  -H "Content-Type: application/json" \
  -d '{"name":"demo-svc","host":"demo-upstream","port":8080,"protocol":"http"}'

In Konga -> Service

3.4 Expose it with a Route

curl -sS -X POST http://localhost:8001/services/demo-svc/routes \
  -H "Content-Type: application/json" \
  -d '{"name":"demo-route","paths":["/demo"]}'

In Konga -> Route

demo-route will set as a Route

Your app endpoint (through HAProxy → Kong) is:

http://localhost:9200/demo/get

Basic test:

curl -i http://localhost:9200/demo/get
# expect 200 + an X-Served-By header from HAProxy: kong1 or kong2

Set up Connection in Konga (UI)

1). Open http://localhost:1337 and create an admin user.

2). Add a Connection (point Konga at the admin LB):

In Konga -> CONNECTIONS -> Click button [+ NEW CONNECTION]

Enter the following detail

Name: Haproxy-LB
Kong Admin URL: http://localhost:9201
Username: Your Konga Username
Password: Your Konga Password

3). In Konga, you can build the same objects via UI:

Upstreams → Add Upstream (demo-upstream)
Targets → Add Target (httpbin1:8080, httpbin2:8080)
Services → Add Service (demo-svc, host: demo-upstream, port 8080)
Routes → Add Route (demo-route, paths: /demo)
Healthchecks: enable Active checks with path /status/200.

Either method (API or Konga) updates the shared Postgres DB, so both Kong nodes use the same config.

✅ How to PROVE failover works (two ways)

A) Gateway node failover (HAProxy removes bad Kong)

See which node served you:

curl -i http://localhost:9200/status | grep -i X-Served-By

Kill one Kong node:

docker stop kong-1
for i in {1..6}; do curl -sI http://localhost:9200/status | grep -i X-Served-By; done
# expect only kong2 now
docker start kong-1

By killing Kong-1, only Kong-2 remains running. All the load will then go to Kong-2 instead of Kong-1, which is down. I then restarted Kong-1, and this time the load was distributed between Kong-1 and Kong-2.

B) Upstream target failover (Kong removes bad target)

# both targets healthy?
curl -sS http://localhost:8001/upstreams/demo-upstream/health | jq .

# stop one target
docker stop httpbin1

# calls should still return 200 (served by httpbin2)
for i in {1..6}; do curl -s -o /dev/null -w "%{http_code}\n" http://localhost:9200/demo/get; done

# health should show httpbin1 UNHEALTHY
curl -sS http://localhost:8001/upstreams/demo-upstream/health | jq .

# recover
docker start httpbin1

First, I checked the upstream health status:
curl -sS http://localhost:8001/upstreams/demo-upstream/health | jq .

At this point, only httpbin2 was healthy and available.

Next, I sent 6 requests to the service:

for i in {1..6}; do curl -s -o /dev/null -w "%{http_code}\n" http://localhost:9200/demo/get; done

All requests were routed successfully to httpbin2, since httpbin1 was still down.

I then verified the upstream health again:

curl -sS http://localhost:8001/upstreams/demo-upstream/health | jq .

The results confirmed that only httpbin2 was handling traffic.

After that, I restarted httpbin1:
docker start httpbin1

Finally, I checked the upstream health one more time:
curl -sS http://localhost:8001/upstreams/demo-upstream/health | jq .

Now both httpbin1 and httpbin2 were healthy, so the load could be distributed across both instances again.

🧭 Troubleshooting quick hits

Konga can’t reach Admin API? Use the admin LB: http://localhost:9201.
HAProxy 503? Check haproxy logs and verify both admins & proxies:

  curl http://localhost:8001/status
  curl http://localhost:18001/status

DB is a single point of failure in this demo. For real HA, use a managed Postgres/cluster or explore DB-less with declarative config + an external config store.
Health checks too slow/fast? Tweak interval/thresholds in the Upstream healthchecks.active.

🧠 What you just built (recap)

A two-node Kong cluster (OSS) sharing one Postgres DB.
HAProxy in front for node-level load balancing and failover (proxy :9200, admin :9201 with X-Served-By).
A Kong Upstream with active health checks for service-level failover between two targets.
Konga as a friendly admin UI.

Building, Securing, and Deploying a Go App with GitLab CI/CD: README.md

Booranasak Kanthong — Tue, 05 Aug 2025 07:36:38 +0000

# Bank API

A simple in-memory bank account API built in Go.

- **Server listens on**: `:8008`  
- **Base URL**: `http://localhost:8008`

---

## Table of Contents

1. [Endpoints](#endpoints)  
2. [Mock Data](#mock-data)  
3. [Getting Started](#getting-started)  
4. [Running the Server](#running-the-server)  
5. [Running Tests & Coverage](#running-tests--coverage)  

---

## Endpoints

### 1. Welcome Root

- **Path**: `/`  
- **Method**: `GET`  
- **Description**: Returns a friendly welcome message.

```

bash
curl http://localhost:8008/

2. List All Accounts

Path: /accounts
Method: GET
Description: Returns a JSON array of all accounts (ID, Name, Balance).


bash
curl http://localhost:8008/accounts

3. Create a New Account

Path: /accounts
Method: POST
Description: Opens a new account with zero (or seeded) balance.
Body: JSON with a Name field.


bash
curl -X POST http://localhost:8008/accounts \
     -H "Content-Type: application/json" \
     -d '{"Name":"Zara"}'

4. Get Single Account

Path: /accounts/{id}
Method: GET
Description: Fetches the account with the given id.


bash
curl http://localhost:8008/accounts/1

5. Deposit into Account

Path: /accounts/{id}/deposit
Method: POST
Description: Adds funds to the specified account.
Body: JSON with an Amount field (must be > 0).


bash
curl -X POST http://localhost:8008/accounts/1/deposit \
     -H "Content-Type: application/json" \
     -d '{"Amount":100}'

6. Withdraw from Account

Path: /accounts/{id}/withdraw
Method: POST
Description: Subtracts funds from the specified account (must have sufficient balance).
Body: JSON with an Amount field (must be > 0 and ≤ current balance).


bash
curl -X POST http://localhost:8008/accounts/1/withdraw \
     -H "Content-Type: application/json" \
     -d '{"Amount":50}'

Mock Data

On startup, the in-memory store is seeded with 10 mock accounts:

ID	Name	Balance
1	Alice	1000
2	Bob	2000
3	Carol	3000
4	Dave	4000
5	Eve	5000
6	Frank	6000
7	Grace	7000
8	Heidi	8000
9	Ivan	9000
10	Judy	10000

Getting Started

Clone the repository and cd into it:


bash
   git clone <repo-url>
   cd bank-api

Build (optional):


bash
   go build ./cmd/server

Running the Server

Start the HTTP server on port 8008:


bash
go run ./cmd/server/main.go

Visit http://localhost:8008/ in your browser or use the curl commands above.

Running Tests & Coverage

Run all tests verbosely and display coverage:


bash
go test -v -cover ./...

License

MIT © Booranasak Kanthong

Building, Securing, and Deploying a Go App with GitLab CI/CD EP 5.2: Docker Hub Image Scanning with Trivy in GitLab CI/CD

Booranasak Kanthong — Tue, 05 Aug 2025 06:56:27 +0000

Introduction

Welcome back! Last time, you learned how to build and push your Docker image to Google Artifact Registry (GAR) using GitLab CI/CD. But before we ship our app to production, let’s make sure our Docker image is safe by scanning it for vulnerabilities using a tool called Trivy.

In this episode, you’ll learn:

What Trivy is and why you need image scanning
How to add Trivy to your GitLab CI/CD pipeline
How to read and act on your scan results

1. What is Trivy and Why Scan Your Images?

Trivy is an easy-to-use, open-source tool that scans Docker images for security vulnerabilities.
Just like you wouldn’t install software from an unknown source, you shouldn’t run containers with hidden risks.

Why scan?

Containers often include software from many sources
Vulnerabilities can sneak into your images even if your code is safe
Scanning helps you find and fix risks before they hit production

2. How Trivy Fits in Your Pipeline

Here’s how your pipeline flow looks now:

[GitLab Pipeline]
      |
      v
[Build Docker Image]
      |
      v
[Push Image to GAR]
      |
      v
[Scan Image with Trivy]
      |
      v
[Ready for Deploy!]

3. Adding Trivy to Your .gitlab-ci.yml

Here’s a simple Trivy job based on your previous setup:

image_scan:
  stage: sca_image
  image:
    name: aquasec/trivy:latest
    entrypoint: [""]
  script:
    - echo "Scanning Docker image for vulnerabilities..."
    - trivy image $IMAGE_TAG_DOCKERHUB
  allow_failure: true
  dependencies:
    - push_container_to_registry

What’s happening here?

Installs Docker and Trivy
Authenticates with Google Cloud so the image can be pulled
Runs Trivy to scan your image in GAR
Saves the results as trivy-report.txt
The job is allowed to fail (allow_failure: true) so a vulnerability won’t block your learning or experimenting

4. Merge scripts together

It will look like this

image: docker:latest

services:
  - docker:dind

variables:
  DOCKER_HOST: tcp://docker:2375/
  DOCKER_TLS_CERTDIR: ""
  GO_VERSION: "1.24.3"
  SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar"
  IMAGE_USERNAME_DOCKERHUB: "mirrorheart"
  IMAGE_NAME_DOCKERHUB: "booranasak-bank-api-golang"
  IMAGE_VERSION_TAG: "1.0.0"
  IMAGE_TAG_DOCKERHUB: "$IMAGE_USERNAME_DOCKERHUB/$IMAGE_NAME_DOCKERHUB:$IMAGE_VERSION_TAG"  
  IMAGE_TAR: todo-api.tar
  GIT_DEPTH: "0"

stages:
  - lint
  - test
  - sast
  - build
  - push
  - sca_image

.go-job-template: &go-job-template
  image: debian:bullseye
  before_script:
    - apt update && apt install -y curl git tar gzip
    - curl -LO https://go.dev/dl/go${GO_VERSION}.linux-amd64.tar.gz
    - rm -rf /usr/local/go && tar -C /usr/local -xzf go${GO_VERSION}.linux-amd64.tar.gz
    - export PATH="/usr/local/go/bin:$PATH"
    - go version

lint_golint:
  stage: lint
  <<: *go-job-template
  script:
    - export PATH="/usr/local/go/bin:$PATH"
    - go install golang.org/x/lint/golint@latest
    - export PATH="$PATH:$(go env GOPATH)/bin"
    - echo "Linting files:"
    - find . -name '*.go'
    - golint ./... | tee lint-report.txt
    - echo "--- Lint report preview ---"
    - cat lint-report.txt || echo "lint-report.txt is empty"
  allow_failure: true
  artifacts:
    name: "golint-report"
    paths:
      - lint-report.txt
    expire_in: 1 week

unit_test_and_coverage:
  stage: test
  <<: *go-job-template
  script:
    - export PATH="/usr/local/go/bin:$PATH"
    - go mod tidy
    - go test -v -cover ./...
    - go test -v -coverprofile=coverage.out ./...
  artifacts:
    paths:
      - coverage.out
    expire_in: 1 hour

sonarqube-check:
  stage: sast
  image:
    name: sonarsource/sonar-scanner-cli:11
    entrypoint: [""]
  dependencies:
    - unit_test_and_coverage
  script: 
    - sonar-scanner -Dsonar.host.url="${SONAR_HOST_URL}" -Dsonar.go.coverage.reportPaths=coverage.out -Dsonar.exclusions=**/*_test.go
  allow_failure: true
  rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
    - if: $CI_COMMIT_BRANCH == 'master'
    - if: $CI_COMMIT_BRANCH == 'main'
    - if: $CI_COMMIT_BRANCH == 'develop'

sonarqube-vulnerability-report:
  stage: sast
  image:
    name: sonarsource/sonar-scanner-cli:11
    entrypoint: [""]
  script:
    - 'curl -u "${SONAR_TOKEN}:" "${SONAR_HOST_URL}/api/issues/gitlab_sast_export?projectKey=booranasak-bank-golang-sast&branch=${CI_COMMIT_BRANCH}&pullRequest=${CI_MERGE_REQUEST_IID}" -o gl-sast-sonar-report.json'
  allow_failure: true
  rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
    - if: $CI_COMMIT_BRANCH == 'master'
    - if: $CI_COMMIT_BRANCH == 'main'
    - if: $CI_COMMIT_BRANCH == 'develop'
  artifacts:
    expire_in: 1 day
    reports:
      sast: gl-sast-sonar-report.json

build_container:
  stage: build
  image: docker:latest
  script:
    - echo "$DOCKER_PASSWORD" | docker login -u "$DOCKER_USERNAME" --password-stdin
    - docker build -t $IMAGE_TAG_DOCKERHUB .
    - docker save $IMAGE_TAG_DOCKERHUB -o $IMAGE_TAR
  artifacts:
    name: "docker-image-tar"
    paths:
      - $IMAGE_TAR
    expire_in: 1 hour

push_container_to_registry:
  stage: push
  image: docker:latest
  script:
    - echo "$DOCKER_PASSWORD" | docker login -u "$DOCKER_USERNAME" --password-stdin
    - docker load -i $IMAGE_TAR
    - docker push $IMAGE_TAG_DOCKERHUB
  dependencies:
    - build_container

image_scan:
  stage: sca_image
  image:
    name: aquasec/trivy:latest
    entrypoint: [""]
  script:
    - echo "Scanning Docker image for vulnerabilities..."
    - trivy image $IMAGE_TAG_DOCKERHUB
  allow_failure: true
  dependencies:
    - push_container_to_registry

5. Viewing and Understanding Your Trivy Scan Results

Go to your pipeline in GitLab.

Click at your recent run pipeline

Click on the image_scan job.

*You can view the Trivy report directly from the output logs, or configure your pipeline to save the Trivy report as an artifact. This allows you to download or preview the trivy-report.txt artifact.

Output logs(this from other pipeline)

What do the results mean?

Trivy will list all detected vulnerabilities, their severity, and where they were found (like OS packages or app dependencies).
Focus on “HIGH” or “CRITICAL” vulnerabilities—those should be fixed first.
If the Status is fixed, you’re already protected and don’t need to take action.
But if the status is affected, will_not_fix, or fix_deferred, you should pay close attention—these vulnerabilities are not yet resolved and may still put your project at risk. Review them carefully and patch or mitigate as soon as possible.

In our Code and Image that being use there are no vulnerabilities

6. What If I Find Vulnerabilities?

Read the Trivy output carefully—it tells you which package (and version) is affected.
Many issues can be fixed by updating your Dockerfile or base image.
Sometimes, vulnerabilities are in dependencies you don’t use directly. Research if an update or patch is available.
If you’re not sure, search the CVE ID online for advice.

7. Tips and Best Practices

Scan every new build: Don’t skip scanning for speed; automate it!
Keep Trivy updated: Vulnerabilities are found all the time.
Don’t ignore “HIGH”/“CRITICAL” issues: If you must, at least understand the risk.
Automate alerting: Advanced: send scan failures to Slack, email, etc.

8. What’s Next?

Awesome! Your pipeline now checks for vulnerabilities in every image.
Next, we’ll move on to deploying your image and running live API security scans with OWASP ZAP—so your app is not only safe inside, but also from the outside.

Summary

Added Trivy to your pipeline for automatic container security checks
Learned how to read and act on Trivy results
Set your project up for safer, more professional deployments

Ready for the next step? See you in Episode 6 for deploy and API security scanning with ZAP!

Building, Securing, and Deploying a Go App with GitLab CI/CD EP 4.2: Build and Push Docker Image to Docker Hub

Booranasak Kanthong — Tue, 05 Aug 2025 06:05:34 +0000

Introduction

Welcome back to our CI/CD journey! Last time, you learned how to scan your Go code for bugs and vulnerabilities with SonarQube. In this episode, we’ll take your project to the next level by packaging your app as a Docker image and pushing it to Docker Hub.

By the end, you’ll know how to:

Build a Docker image of your Go app in your GitLab pipeline
Authenticate your pipeline with Docker Hub
Push your image to Docker Hub for safe storage and sharing

1. What is a Docker Image and Why Use a Registry?

A Docker image is like a recipe that describes how to run your app.
It bundles your code, dependencies, and configuration so your app runs the same everywhere.

But once you build an image, you need a place to store it. That’s where a container registry like Docker Hub comes in!
A registry lets you store, share, and deploy images—just like GitHub lets you store and share code.

Docker Image to Registry Flow

[GitLab Pipeline Triggered]
           |
           v
[Docker Build Job: Build App Image]
           |
           v
[Save Docker Image as .tar File]
           |
           v
[Push Job: Authenticate with Docker Hub]
           |
           v
[Load Docker Image from .tar File]
           |
           v
[Push Docker Image to Docker Hub]
           |
           v
[Image Available in Docker Hub]

2. Setting Up Docker Hub

To push images to Docker Hub, you need:

A Docker Hub account
A repository created in Docker Hub under your username or organization

A. Create a Docker Hub Repository

1.) Go to https://hub.docker.com
2.) Sign in and click Create Repository

3.) Choose visibility (Public or Private), and name it something like booranasak-bank-api-golang

4.) Note the image name format:

   docker.io/YOUR_DOCKERHUB_USERNAME/booranasak-bank-api-golang:1.0.0

3. Building Your Docker Image in GitLab CI/CD

Here’s the job for your .gitlab-ci.yml:

variables:
  IMAGE_NAME_DOCKERHUB: "booranasak-bank-api-golang"
  IMAGE_VERSION_TAG: "1.0.0"
  IMAGE_TAG_DOCKERHUB: "docker.io/YOUR_DOCKERHUB_USERNAME/$IMAGE_NAME_DOCKERHUB:$IMAGE_VERSION_TAG"
  IMAGE_TAR: todo-api.tar

build_image:
  stage: build
  image: docker:latest
  script:
    - docker build -t $IMAGE_TAG_DOCKERHUB .
    - docker save $IMAGE_TAG_DOCKERHUB -o $IMAGE_TAR
  artifacts:
    name: "docker-image-tar"
    paths:
      - $IMAGE_TAR
    expire_in: 1 hour

4. Authenticating GitLab CI/CD with Docker Hub

You’ll use GitLab CI/CD variables to store your Docker Hub credentials.

A. Add Docker Hub Credentials to GitLab

Go to your GitLab project → Settings → CI/CD → Variables
Add the following CI/CD variables:

DOCKER_USERNAME: your Docker Hub username

* `DOCKER_PASSWORD`: your Docker Hub password or personal access token

5. Pushing the Image to Docker Hub

Here’s the job for pushing:

push_image_to_registry:
  stage: push
  image: docker:latest
  dependencies:
    - build_image
  before_script:
    - docker login -u "$DOCKER_USER" --password-stdin
  script:
    - docker load -i $IMAGE_TAR
    - docker push $IMAGE_TAG_DOCKERHUB

6. Merge Scripts Together

Here’s how your complete .gitlab-ci.yml looks after replacing GAR with Docker Hub:

image: docker:latest

services:
  - docker:dind

variables:
  DOCKER_HOST: tcp://docker:2375/
  DOCKER_TLS_CERTDIR: ""
  GO_VERSION: "1.24.3"
  SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar"
  IMAGE_USERNAME_DOCKERHUB: "mirrorheart"
  IMAGE_NAME_DOCKERHUB: "booranasak-bank-api-golang"
  IMAGE_VERSION_TAG: "1.0.0"
  IMAGE_TAG_DOCKERHUB: "$IMAGE_USERNAME_DOCKERHUB/$IMAGE_NAME_DOCKERHUB:$IMAGE_VERSION_TAG"  
  IMAGE_TAR: todo-api.tar
  GIT_DEPTH: "0"

stages:
  - lint
  - test
  - sast
  - build
  - push
  - sca_image
  - deploy
  - zap_scan

.go-job-template: &go-job-template
  image: debian:bullseye
  before_script:
    - apt update && apt install -y curl git tar gzip
    - curl -LO https://go.dev/dl/go${GO_VERSION}.linux-amd64.tar.gz
    - rm -rf /usr/local/go && tar -C /usr/local -xzf go${GO_VERSION}.linux-amd64.tar.gz
    - export PATH="/usr/local/go/bin:$PATH"
    - go version

lint_golint:
  stage: lint
  <<: *go-job-template
  script:
    - export PATH="/usr/local/go/bin:$PATH"
    - go install golang.org/x/lint/golint@latest
    - export PATH="$PATH:$(go env GOPATH)/bin"
    - echo "Linting files:"
    - find . -name '*.go'
    - golint ./... | tee lint-report.txt
    - echo "--- Lint report preview ---"
    - cat lint-report.txt || echo "lint-report.txt is empty"
  allow_failure: true
  artifacts:
    name: "golint-report"
    paths:
      - lint-report.txt
    expire_in: 1 week

unit_test_and_coverage:
  stage: test
  <<: *go-job-template
  script:
    - export PATH="/usr/local/go/bin:$PATH"
    - go mod tidy
    - go test -v -cover ./...
    - go test -v -coverprofile=coverage.out ./...
  artifacts:
    paths:
      - coverage.out
    expire_in: 1 hour

sonarqube-check:
  stage: sast
  image:
    name: sonarsource/sonar-scanner-cli:11
    entrypoint: [""]
  dependencies:
    - unit_test_and_coverage
  script: 
    - sonar-scanner -Dsonar.host.url="${SONAR_HOST_URL}" -Dsonar.go.coverage.reportPaths=coverage.out -Dsonar.exclusions=**/*_test.go
  allow_failure: true
  rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
    - if: $CI_COMMIT_BRANCH == 'master'
    - if: $CI_COMMIT_BRANCH == 'main'
    - if: $CI_COMMIT_BRANCH == 'develop'

sonarqube-vulnerability-report:
  stage: sast
  image:
    name: sonarsource/sonar-scanner-cli:11
    entrypoint: [""]
  script:
    - 'curl -u "${SONAR_TOKEN}:" "${SONAR_HOST_URL}/api/issues/gitlab_sast_export?projectKey=booranasak-bank-golang-sast&branch=${CI_COMMIT_BRANCH}&pullRequest=${CI_MERGE_REQUEST_IID}" -o gl-sast-sonar-report.json'
  allow_failure: true
  rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
    - if: $CI_COMMIT_BRANCH == 'master'
    - if: $CI_COMMIT_BRANCH == 'main'
    - if: $CI_COMMIT_BRANCH == 'develop'
  artifacts:
    expire_in: 1 day
    reports:
      sast: gl-sast-sonar-report.json

build_container:
  stage: build
  image: docker:latest
  script:
    - echo "$DOCKER_PASSWORD" | docker login -u "$DOCKER_USERNAME" --password-stdin
    - docker build -t $IMAGE_TAG_DOCKERHUB .
    - docker save $IMAGE_TAG_DOCKERHUB -o $IMAGE_TAR
  artifacts:
    name: "docker-image-tar"
    paths:
      - $IMAGE_TAR
    expire_in: 1 hour

push_container_to_registry:
  stage: push
  image: docker:latest
  script:
    - echo "$DOCKER_PASSWORD" | docker login -u "$DOCKER_USERNAME" --password-stdin
    - docker load -i $IMAGE_TAR
    - docker push $IMAGE_TAG_DOCKERHUB
  dependencies:
    - build_container

7. Checking Your Image in Docker Hub

Once your pipeline finishes:

Go to Docker Hub
Open your repository (e.g., booranasak-bank-api-golang)

You should see your image with the tag 1.0.0 listed

Test Pulling Your Image (Optional)

docker pull docker.io/YOUR_DOCKERHUB_USERNAME/booranasak-bank-api-golang:1.0.0

8. Troubleshooting Tips

Login errors? Check that DOCKER_USERNAME and DOCKER_PASSWORD are correctly set
Pipeline fails at Docker commands? Ensure Docker-in-Docker (docker:dind) is enabled
Image not visible? Double-check the tag and Docker Hub repo name

9. What’s Next?

Awesome work! Your Go app is now packaged in a Docker image and stored in Docker Hub—ready to be deployed anywhere.

In the next episode, we’ll add Trivy to your pipeline to automatically scan your image for vulnerabilities.

Summary

You built and pushed Docker images via GitLab CI/CD
You configured Docker Hub authentication
Your app is now containerized and stored in a public/private registry

Ready for EP 5.2? Stay tuned — we're adding Trivy to scan Docker Hub images for vulnerabilities!

Building, Securing, and Deploying a Go App with GitLab CI/CD EP 6: Deploy and Scan Your Go API with OWASP ZAP in GitLab CI/CD

Booranasak Kanthong — Mon, 04 Aug 2025 16:03:28 +0000

Introduction

Welcome to Episode 6 of our CI/CD journey!
So far, you’ve built a secure pipeline: building, testing, scanning, and pushing your app image automatically. In this episode, you’ll learn how to automate the deployment of your Docker image and use OWASP ZAP to scan your running API for vulnerabilities—just like professional DevOps teams do.

Recap: Up to now, you’ve built, tested, scanned, and pushed your app image.
What’s next: Deploying your app, then scanning your running API for security issues using OWASP ZAP.
Why it matters: Even a secure image can expose vulnerabilities once deployed—API scanning helps catch those.

1. Automated Deployment from GitLab CI/CD

A big step in DevOps is letting your pipeline deploy the latest app image for you—no more manual server logins!
We’ll use GitLab CI/CD to connect to a remote server via SSH and run our new Docker image.

Why Use SSH Keys?

SSH keys keep your connection secure without exposing passwords.
Store your keys as GitLab CI/CD variables (like SSH_PRIVATE_KEY), never hard-code secrets.

I’ve already covered this topic, so you can follow along using the link below.
Setup SSH Key Method

Example Deployment Job

deploy_to_production:
  stage: deploy
  image: google/cloud-sdk:latest
  before_script:
    - echo "Install Docker"
    - apt-get update && apt-get install -y docker.io curl ca-certificates tar gzip openssh-client
    - echo "Setting up Google Cloud authentication..."
    - echo "$GCP_SA_KEY" | base64 -d > $CI_PROJECT_DIR/gcp-key.json
    - gcloud auth activate-service-account --key-file=$CI_PROJECT_DIR/gcp-key.json
    - gcloud config set project escian
    - gcloud auth configure-docker asia-southeast1-docker.pkg.dev --quiet
    - eval $(ssh-agent -s)
    - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add -
    - mkdir -p ~/.ssh
    - chmod 700 ~/.ssh
    - echo "$SSH_KNOWN_HOSTS" >> ~/.ssh/known_hosts
    - chmod 644 ~/.ssh/known_hosts
    - ssh-keyscan $REMOTE_HOST >> ~/.ssh/known_hosts # Good for adding on the fly if not using a variable
    - ls -lrta ~/.ssh
    - cat ~/.ssh/known_hosts
    - id
  script:
    - ssh $REMOTE_USER@$REMOTE_HOST "docker run -d -p 8502:8002 $IMAGE_TAG_GOOGLE && docker ps | grep uvicorn | awk '{print \$1}' > CONTAINER_ID.txt &"

What this does:
Install Docker
Authenticates with Google Cloud so the image can be pulled
Sets up SSH, authenticates securely, and runs your Docker container on the remote host.

If you use Docker

deploy_to_production:
  stage: deploy
  image: alpine
  before_script:
    # Install openssh-client if not present in the image
    - apk add --no-cache openssh-client
    # Set up SSH agent
    - eval $(ssh-agent -s)
    # Add the private key from the CI/CD secret
    - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add -
    # Create the .ssh directory and add known hosts
    - mkdir -p ~/.ssh
    - chmod 700 ~/.ssh
    - echo "$SSH_KNOWN_HOSTS" >> ~/.ssh/known_hosts
    - chmod 644 ~/.ssh/known_hosts
    - ssh-keyscan $REMOTE_HOST >> ~/.ssh/known_hosts # Good for adding on the fly if not using a variable
    - ls -lrta ~/.ssh
    - cat ~/.ssh/known_hosts
    - id
  script:
    - ssh $REMOTE_USER@$REMOTE_HOST "docker run -d -p 8502:8002 mirrorheart/todo-api-golang && docker ps | grep uvicorn | awk '{print $1}' > CONTAINER_ID.txt &"

2. Health Checking Your API Before Scanning

You don’t want to scan your API until it’s actually running!
A health check waits for your deployed app to be up before moving forward.

Sample Health Check Script

for i in {1..10}; do
  if curl -sSf "$APP_URL_HEALTH" > /dev/null; then
    echo "Target is up."
    break
  else
    echo "Waiting for target... ($i/10)"
    sleep 5
  fi
  if [ $i -eq 10 ]; then
    echo "Target not reachable after 50 seconds."
    exit 1
  fi
done

This script pings your app up to 10 times, waiting up to 50 seconds before failing if it can't connect.

3. API Security Scanning with OWASP ZAP

What is OWASP ZAP?

OWASP ZAP (Zed Attack Proxy) is a free, open-source security tool for finding vulnerabilities in web applications and APIs.
It checks your running app for issues that code or image scans can’t find—like missing authentication, insecure endpoints, or sensitive data leaks.

Why Use It in CI/CD?

Scans the real, running API for real-world security problems
Catches issues before users (or attackers) find them

Add ZAP to Your Pipeline

zap_scan:
  stage: zap_scan
  image: zaproxy/zap-stable
  script:
    - echo "Checking if the target is reachable..."
    - # (paste the health check script here)
    - mkdir -p /zap/wrk
    - ln -s "$CI_PROJECT_DIR" /zap/wrk
    - echo "Starting ZAP baseline scan..."
    - zap-baseline.py -t "$APP_URL" -r zap-report.html -I
    - cp /zap/wrk/zap-report.html "$CI_PROJECT_DIR/" || true
  artifacts:
    paths:
      - zap-report.html
    expire_in: 7 days
  allow_failure: true

What this does: Waits for your API to be up, runs a baseline ZAP scan, and saves the full report as a downloadable artifact.

You will get file .ZIP (original name: artifact.zip)

I have renamed the file for better clarity.

Let's take a look at the report file

Quite long

4. Reading & Acting on ZAP Reports

Go to your pipeline in GitLab and click the zap_scan job.
Download and open zap-report.html to see results.

What to Look For

High or Medium risk findings: Fix these before deploying to users!
Auth or access control warnings: Make sure only the right people can access sensitive endpoints.
Informational/Low findings: Good to know, but not urgent.

Alert Detail

Risk Level: Low
Issue: Insufficient Site Isolation Against Spectre Vulnerability
Description: Your application does not set the Cross-Origin-Resource-Policy (CORP) header. This header is crucial for mitigating side-channel attacks like Spectre by controlling how resources are shared across origins.

Risk Level: Low
Issue: X-Content-Type-Options Header Missing
Description:Your application does not set the X-Content-Type-Options HTTP response header to nosniff. This header is critical for preventing MIME-sniffing by older browsers (like Internet Explorer and Chrome), which may otherwise interpret the response body as a different content type than declared — potentially allowing cross-site scripting (XSS) or other injection attacks on certain responses.

Informational
Risk Level: Informational
Issue: Storable and Cacheable Content
Description: The HTTP responses from your web server do not include explicit caching directives, which causes proxy or browser caches to apply heuristic expiration policies (e.g., 1 year by default). This can be a privacy risk, especially if:

The content is sensitive, personal, or user-specific.
Shared caches (e.g., corporate or school proxies) are involved.
Such responses may be retrieved by others without a direct request to the origin server, risking exposure of private data or even session hijacking.

5. (Optional) Stopping Your App

You might want to stop your demo or test container after scanning.

stop_to_production:
  stage: deploy
  image: alpine
  before_script:
    - apk add --no-cache openssh-client
    - eval $(ssh-agent -s)
    - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add -
    - mkdir -p ~/.ssh
    - chmod 700 ~/.ssh
    - echo "$SSH_KNOWN_HOSTS" >> ~/.ssh/known_hosts
    - chmod 644 ~/.ssh/known_hosts
    - ssh-keyscan $REMOTE_HOST >> ~/.ssh/known_hosts # Good for adding on the fly if not using a variable
    - ls -lrta ~/.ssh
    - cat ~/.ssh/known_hosts
    - id
  script:
    - ssh $REMOTE_USER@$REMOTE_HOST "cat CONTAINER_ID.txt | xargs docker stop"
  when: manual

Tip: Mark this job as manual so it only runs when you trigger it.

6. Merge scripts together

It will look like this

image: docker:latest

services:
  - docker:dind

variables:
  DOCKER_HOST: tcp://docker:2375/
  DOCKER_TLS_CERTDIR: ""
  GO_VERSION: "1.24.3"
  SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar"
  IMAGE_NAME_GOOGLE: "booranasak-bank-api-golang"
  IMAGE_VERSION_TAG: "1.0.0"
  IMAGE_TAG_GOOGLE: "asia-southeast1-docker.pkg.dev/escian/booranasak-artifact-registry-docker/$IMAGE_NAME_GOOGLE:$IMAGE_VERSION_TAG"  
  IMAGE_TAR: todo-api.tar
  GIT_DEPTH: "0"
  REMOTE_USER: booranasak42545
  REMOTE_HOST: 35.209.94.73
  REMOTE_APP_DIR: /home/booranasak42545/deploy_repo
  APP_URL: http://35.209.94.73:8502
  APP_URL_HEALTH: http://35.209.94.73:8502

stages:
  - lint
  - test
  - sast
  - build
  - push
  - sca_image
  - deploy
  - zap_scan

.go-job-template: &go-job-template
  image: debian:bullseye
  before_script:
    - apt update && apt install -y curl git tar gzip
    - curl -LO https://go.dev/dl/go${GO_VERSION}.linux-amd64.tar.gz
    - rm -rf /usr/local/go && tar -C /usr/local -xzf go${GO_VERSION}.linux-amd64.tar.gz
    - export PATH="/usr/local/go/bin:$PATH"
    - go version

lint_golint:
  stage: lint
  <<: *go-job-template
  script:
    - export PATH="/usr/local/go/bin:$PATH"
    - go install golang.org/x/lint/golint@latest
    - export PATH="$PATH:$(go env GOPATH)/bin"
    - echo "Linting files:"
    - find . -name '*.go'
    - golint ./... | tee lint-report.txt
    - echo "--- Lint report preview ---"
    - cat lint-report.txt || echo "lint-report.txt is empty"
  allow_failure: true
  artifacts:
    name: "golint-report"
    paths:
      - lint-report.txt
    expire_in: 1 week

unit_test_and_coverage:
  stage: test
  <<: *go-job-template
  script:
    - export PATH="/usr/local/go/bin:$PATH"
    - go mod tidy
    - go test -v -cover ./...
    - go test -v -coverprofile=coverage.out ./...
  artifacts:
    paths:
      - coverage.out
    expire_in: 1 hour

sonarqube-check:
  stage: sast
  image:
    name: sonarsource/sonar-scanner-cli:11
    entrypoint: [""]
  dependencies:
    - unit_test_and_coverage
  script: 
    - sonar-scanner -Dsonar.host.url="${SONAR_HOST_URL}" -Dsonar.go.coverage.reportPaths=coverage.out -Dsonar.exclusions=**/*_test.go
  allow_failure: true
  rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
    - if: $CI_COMMIT_BRANCH == 'master'
    - if: $CI_COMMIT_BRANCH == 'main'
    - if: $CI_COMMIT_BRANCH == 'develop'

sonarqube-vulnerability-report:
  stage: sast
  image:
    name: sonarsource/sonar-scanner-cli:11
    entrypoint: [""]
  script:
    - 'curl -u "${SONAR_TOKEN}:" "${SONAR_HOST_URL}/api/issues/gitlab_sast_export?projectKey=booranasak-golang-sast&branch=${CI_COMMIT_BRANCH}&pullRequest=${CI_MERGE_REQUEST_IID}" -o gl-sast-sonar-report.json'
  allow_failure: true
  rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
    - if: $CI_COMMIT_BRANCH == 'master'
    - if: $CI_COMMIT_BRANCH == 'main'
    - if: $CI_COMMIT_BRANCH == 'develop'
  artifacts:
    expire_in: 1 day
    reports:
      sast: gl-sast-sonar-report.json

build_image:
  stage: build
  image: docker:latest
  script:
    - docker build -t $IMAGE_TAG_GOOGLE .
    - docker save $IMAGE_TAG_GOOGLE -o $IMAGE_TAR
  artifacts:
    name: "docker-image-tar"
    paths:
      - $IMAGE_TAR
    expire_in: 1 hour

push_image_to_registry:
  stage: push
  image: google/cloud-sdk:latest
  dependencies:
    - build_image
  before_script:
    - echo "Install Docker"
    - apt-get update && apt-get install -y docker.io
    - echo "Setting up Google Cloud authentication..."
    - echo "$GCP_SA_KEY" | base64 -d > $CI_PROJECT_DIR/gcp-key.json
    - gcloud auth activate-service-account --key-file=$CI_PROJECT_DIR/gcp-key.json
    - gcloud config set project escian
    - gcloud auth configure-docker asia-southeast1-docker.pkg.dev --quiet
  script:
    - docker load -i $IMAGE_TAR
    - docker push $IMAGE_TAG_GOOGLE

image_scan:
  stage: sca_image
  image: google/cloud-sdk:latest
  variables: 
    TRIVY_VERSION: "0.54.1"
  before_script:
    - echo "Install Docker"
    - apt-get update && apt-get install -y docker.io curl ca-certificates tar gzip
    - echo "Setting up Google Cloud authentication..."
    - echo "$GCP_SA_KEY" | base64 -d > $CI_PROJECT_DIR/gcp-key.json
    - gcloud auth activate-service-account --key-file=$CI_PROJECT_DIR/gcp-key.json
    - gcloud config set project escian
    - gcloud auth configure-docker asia-southeast1-docker.pkg.dev --quiet
    - curl -fsSL https://github.com/aquasecurity/trivy/releases/download/v${TRIVY_VERSION}/trivy_${TRIVY_VERSION}_Linux-64bit.tar.gz | tar -xz -C /usr/local/bin trivy
    - trivy --version
  script:
    - echo "Scanning Docker image for vulnerabilities..."
    - trivy image $IMAGE_TAG_GOOGLE
  allow_failure: true

deploy_to_production:
  stage: deploy
  image: google/cloud-sdk:latest
  before_script:
    - echo "Install Docker"
    - apt-get update && apt-get install -y docker.io curl ca-certificates tar gzip openssh-client
    - echo "Setting up Google Cloud authentication..."
    - echo "$GCP_SA_KEY" | base64 -d > $CI_PROJECT_DIR/gcp-key.json
    - gcloud auth activate-service-account --key-file=$CI_PROJECT_DIR/gcp-key.json
    - gcloud config set project escian
    - gcloud auth configure-docker asia-southeast1-docker.pkg.dev --quiet
    - eval $(ssh-agent -s)
    - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add -
    - mkdir -p ~/.ssh
    - chmod 700 ~/.ssh
    - echo "$SSH_KNOWN_HOSTS" >> ~/.ssh/known_hosts
    - chmod 644 ~/.ssh/known_hosts
    - ssh-keyscan $REMOTE_HOST >> ~/.ssh/known_hosts # Good for adding on the fly if not using a variable
    - ls -lrta ~/.ssh
    - cat ~/.ssh/known_hosts
    - id
  script:
    - ssh $REMOTE_USER@$REMOTE_HOST "docker run -d -p 8502:8002 $IMAGE_TAG_GOOGLE && docker ps | grep uvicorn | awk '{print \$1}' > CONTAINER_ID.txt &"

stop_to_production:
  stage: deploy
  image: alpine
  before_script:
    - apk add --no-cache openssh-client
    - eval $(ssh-agent -s)
    - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add -
    - mkdir -p ~/.ssh
    - chmod 700 ~/.ssh
    - echo "$SSH_KNOWN_HOSTS" >> ~/.ssh/known_hosts
    - chmod 644 ~/.ssh/known_hosts
    - ssh-keyscan $REMOTE_HOST >> ~/.ssh/known_hosts # Good for adding on the fly if not using a variable
    - ls -lrta ~/.ssh
    - cat ~/.ssh/known_hosts
    - id
  script:
    - ssh $REMOTE_USER@$REMOTE_HOST "cat CONTAINER_ID.txt | xargs docker stop"
  when: manual

zap_scan:
  stage: zap_scan
  image: zaproxy/zap-stable
  script:
    - echo "Checking if the target is reachable..."
    - |
      for i in {1..10}; do
        if curl -sSf "$APP_URL_HEALTH" > /dev/null; then
          echo "Target is up."
          break
        else
          echo "Waiting for target... ($i/10)"
          sleep 5
        fi
        if [ $i -eq 10 ]; then
          echo "Target not reachable after 50 seconds."
          exit 1
        fi
      done
    - mkdir -p /zap/wrk
    - ln -s "$CI_PROJECT_DIR" /zap/wrk
    - echo "Starting ZAP baseline scan..."
    - zap-baseline.py -t "$APP_URL" -r zap-report.html -I
    - cp /zap/wrk/zap-report.html "$CI_PROJECT_DIR/" || true
  artifacts:
    paths:
      - zap-report.html
    expire_in: 7 days
  allow_failure: true

7. Wrap Up and What’s Next

Congrats—you’ve now automated deployment and API scanning for your Go app using GitLab CI/CD and OWASP ZAP!
This means every change you make gets checked for code bugs, image vulnerabilities, and live API security—all before users ever see it.

What else can you automate?

Slack/email notifications for new vulnerabilities
Deploying to cloud platforms like GCP or AWS

Thank you for following along!
Be sure to check out the earlier episodes and stay tuned for the next one.

Building, Securing, and Deploying a Go App with GitLab CI/CD EP 5.1: Container Image Scanning(GAR) with Trivy in GitLab CI/CD

Booranasak Kanthong — Mon, 04 Aug 2025 09:50:11 +0000

Introduction

In this episode, you’ll learn:

What Trivy is and why you need image scanning
How to add Trivy to your GitLab CI/CD pipeline
How to read and act on your scan results

1. What is Trivy and Why Scan Your Images?

Why scan?

Containers often include software from many sources
Vulnerabilities can sneak into your images even if your code is safe
Scanning helps you find and fix risks before they hit production

2. How Trivy Fits in Your Pipeline

Here’s how your pipeline flow looks now:

[GitLab Pipeline]
      |
      v
[Build Docker Image]
      |
      v
[Push Image to GAR]
      |
      v
[Scan Image with Trivy]
      |
      v
[Ready for Deploy!]

3. Adding Trivy to Your .gitlab-ci.yml

Here’s a simple Trivy job based on your previous setup:

image_scan:
  stage: sca_image
  image: google/cloud-sdk:latest
  variables: 
    TRIVY_VERSION: "0.54.1"
  before_script:
    - echo "Install Docker"
    - apt-get update && apt-get install -y docker.io curl ca-certificates tar gzip
    - echo "Setting up Google Cloud authentication..."
    - echo "$GCP_SA_KEY" | base64 -d > $CI_PROJECT_DIR/gcp-key.json
    - gcloud auth activate-service-account --key-file=$CI_PROJECT_DIR/gcp-key.json
    - gcloud config set project YOUR_PROJECT_ID
    - gcloud auth configure-docker asia-southeast1-docker.pkg.dev --quiet
    - curl -fsSL https://github.com/aquasecurity/trivy/releases/download/v${TRIVY_VERSION}/trivy_${TRIVY_VERSION}_Linux-64bit.tar.gz | tar -xz -C /usr/local/bin trivy
    - trivy --version
  script:
    - echo "Scanning Docker image for vulnerabilities..."
    - trivy image $IMAGE_TAG_GOOGLE | tee trivy-report.txt
  allow_failure: true
  artifacts:
    name: "trivy-report"
    paths:
      - trivy-report.txt
    expire_in: 1 week

What’s happening here?

Installs Docker and Trivy
Authenticates with Google Cloud so the image can be pulled
Runs Trivy to scan your image in GAR
Saves the results as trivy-report.txt
The job is allowed to fail (allow_failure: true) so a vulnerability won’t block your learning or experimenting

4. Merge scripts together

It will look like this

image: docker:latest

services:
  - docker:dind

variables:
  DOCKER_HOST: tcp://docker:2375/
  DOCKER_TLS_CERTDIR: ""
  GO_VERSION: "1.24.3"
  SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar"
  IMAGE_NAME_GOOGLE: "booranasak-bank-api-golang"
  IMAGE_VERSION_TAG: "1.0.0"
  IMAGE_TAG_GOOGLE: "asia-southeast1-docker.pkg.dev/escian/booranasak-artifact-registry-docker/$IMAGE_NAME_GOOGLE:$IMAGE_VERSION_TAG"  
  IMAGE_TAR: todo-api.tar
  GIT_DEPTH: "0"

stages:
  - lint
  - test
  - sast
  - build
  - push
  - sca_image

.go-job-template: &go-job-template
  image: debian:bullseye
  before_script:
    - apt update && apt install -y curl git tar gzip
    - curl -LO https://go.dev/dl/go${GO_VERSION}.linux-amd64.tar.gz
    - rm -rf /usr/local/go && tar -C /usr/local -xzf go${GO_VERSION}.linux-amd64.tar.gz
    - export PATH="/usr/local/go/bin:$PATH"
    - go version

lint_golint:
  stage: lint
  <<: *go-job-template
  script:
    - export PATH="/usr/local/go/bin:$PATH"
    - go install golang.org/x/lint/golint@latest
    - export PATH="$PATH:$(go env GOPATH)/bin"
    - echo "Linting files:"
    - find . -name '*.go'
    - golint ./... | tee lint-report.txt
    - echo "--- Lint report preview ---"
    - cat lint-report.txt || echo "lint-report.txt is empty"
  allow_failure: true
  artifacts:
    name: "golint-report"
    paths:
      - lint-report.txt
    expire_in: 1 week

unit_test_and_coverage:
  stage: test
  <<: *go-job-template
  script:
    - export PATH="/usr/local/go/bin:$PATH"
    - go mod tidy
    - go test -v -cover ./...
    - go test -v -coverprofile=coverage.out ./...
  artifacts:
    paths:
      - coverage.out
    expire_in: 1 hour

sonarqube-check:
  stage: sast
  image:
    name: sonarsource/sonar-scanner-cli:11
    entrypoint: [""]
  dependencies:
    - unit_test_and_coverage
  script: 
    - sonar-scanner -Dsonar.host.url="${SONAR_HOST_URL}" -Dsonar.go.coverage.reportPaths=coverage.out -Dsonar.exclusions=**/*_test.go
  allow_failure: true
  rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
    - if: $CI_COMMIT_BRANCH == 'master'
    - if: $CI_COMMIT_BRANCH == 'main'
    - if: $CI_COMMIT_BRANCH == 'develop'

sonarqube-vulnerability-report:
  stage: sast
  image:
    name: sonarsource/sonar-scanner-cli:11
    entrypoint: [""]
  script:
    - 'curl -u "${SONAR_TOKEN}:" "${SONAR_HOST_URL}/api/issues/gitlab_sast_export?projectKey=booranasak-golang-sast&branch=${CI_COMMIT_BRANCH}&pullRequest=${CI_MERGE_REQUEST_IID}" -o gl-sast-sonar-report.json'
  allow_failure: true
  rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
    - if: $CI_COMMIT_BRANCH == 'master'
    - if: $CI_COMMIT_BRANCH == 'main'
    - if: $CI_COMMIT_BRANCH == 'develop'
  artifacts:
    expire_in: 1 day
    reports:
      sast: gl-sast-sonar-report.json

build_image:
  stage: build
  image: docker:latest
  script:
    - docker build -t $IMAGE_TAG_GOOGLE .
    - docker save $IMAGE_TAG_GOOGLE -o $IMAGE_TAR
  artifacts:
    name: "docker-image-tar"
    paths:
      - $IMAGE_TAR
    expire_in: 1 hour

push_image_to_registry:
  stage: push
  image: google/cloud-sdk:latest
  dependencies:
    - build_image
  before_script:
    - echo "Install Docker"
    - apt-get update && apt-get install -y docker.io
    - echo "Setting up Google Cloud authentication..."
    - echo "$GCP_SA_KEY" | base64 -d > $CI_PROJECT_DIR/gcp-key.json
    - gcloud auth activate-service-account --key-file=$CI_PROJECT_DIR/gcp-key.json
    - gcloud config set project escian
    - gcloud auth configure-docker asia-southeast1-docker.pkg.dev --quiet
  script:
    - docker load -i $IMAGE_TAR
    - docker push $IMAGE_TAG_GOOGLE

image_scan:
  stage: sca_image
  image: google/cloud-sdk:latest
  variables: 
    TRIVY_VERSION: "0.54.1"
  before_script:
    - echo "Install Docker"
    - apt-get update && apt-get install -y docker.io curl ca-certificates tar gzip
    - echo "Setting up Google Cloud authentication..."
    - echo "$GCP_SA_KEY" | base64 -d > $CI_PROJECT_DIR/gcp-key.json
    - gcloud auth activate-service-account --key-file=$CI_PROJECT_DIR/gcp-key.json
    - gcloud config set project escian
    - gcloud auth configure-docker asia-southeast1-docker.pkg.dev --quiet
    - curl -fsSL https://github.com/aquasecurity/trivy/releases/download/v${TRIVY_VERSION}/trivy_${TRIVY_VERSION}_Linux-64bit.tar.gz | tar -xz -C /usr/local/bin trivy
    - trivy --version
  script:
    - echo "Scanning Docker image for vulnerabilities..."
    - trivy image $IMAGE_TAG_GOOGLE
  allow_failure: true

5. Viewing and Understanding Your Trivy Scan Results

Go to your pipeline in GitLab.

Click at your recent run pipeline

Click on the image_scan job.

*You can view the Trivy report directly from the output logs, or configure your pipeline to save the Trivy report as an artifact. This allows you to download or preview the trivy-report.txt artifact.

Output logs(this from other pipeline)

What do the results mean?

Trivy will list all detected vulnerabilities, their severity, and where they were found (like OS packages or app dependencies).
Focus on “HIGH” or “CRITICAL” vulnerabilities—those should be fixed first.
If the Status is fixed, you’re already protected and don’t need to take action.
But if the status is affected, will_not_fix, or fix_deferred, you should pay close attention—these vulnerabilities are not yet resolved and may still put your project at risk. Review them carefully and patch or mitigate as soon as possible.

In our Code and Image that being use there are no vulnerabilities

6. What If I Find Vulnerabilities?

Read the Trivy output carefully—it tells you which package (and version) is affected.
Many issues can be fixed by updating your Dockerfile or base image.
Sometimes, vulnerabilities are in dependencies you don’t use directly. Research if an update or patch is available.
If you’re not sure, search the CVE ID online for advice.

7. Tips and Best Practices

Scan every new build: Don’t skip scanning for speed; automate it!
Keep Trivy updated: Vulnerabilities are found all the time.
Don’t ignore “HIGH”/“CRITICAL” issues: If you must, at least understand the risk.
Automate alerting: Advanced: send scan failures to Slack, email, etc.

8. What’s Next?

Summary

Added Trivy to your pipeline for automatic container security checks
Learned how to read and act on Trivy results
Set your project up for safer, more professional deployments

Ready for the next step? See you in Episode 6 for deploy and API security scanning with ZAP!

Building, Securing, and Deploying a Go App with GitLab CI/CD EP 4.1: Build and Push Docker Image to GAR

Booranasak Kanthong — Mon, 04 Aug 2025 09:34:49 +0000

Introduction

By the end, you’ll know how to:

Build a Docker image of your Go app in your GitLab pipeline
Authenticate your pipeline with Google Cloud
Push your image to GAR for safe storage and sharing

1. What is a Docker Image and Why Use a Registry?

A Docker image is like a recipe that describes how to run your app.
It bundles your code, dependencies, and configuration so your app runs the same everywhere.

But once you build an image, you need a place to store it. That’s where a container registry like Google Artifact Registry (GAR) comes in!
A registry lets you store, share, and deploy images—just like how GitHub lets you store and share code.

Docker Image to Registry Flow

[GitLab Pipeline Triggered]
           |
           v
[Docker Build Job: Build App Image]
           |
           v
[Save Docker Image as .tar File]
           |
           v
[Push Job: Authenticate with Google Cloud]
           |
           v
[Load Docker Image from .tar File]
           |
           v
[Push Docker Image to Google Artifact Registry]
           |
           v
[Image Available in Google Artifact Registry]

2. Setting Up Google Artifact Registry (GAR)

To push images to GAR, you need:

A Google Cloud account
A Docker repository set up in Artifact Registry

A. Enable Artifact Registry

1.) Go to the Google Cloud Console.
2.) Make sure your project is selected.
3.) Enable the Artifact Registry API (search for it in “APIs & Services”).

B. Create a Docker Repository

1.) In the Cloud Console sidebar, find Artifact Registry.

You can search from Search Bar

2.) Click Repositories → CREATE REPOSITORY.

3.) Choose type: Docker.
4.) Pick a region (e.g., asia-southeast1).
5.) Give it a name, like booranasak-artifact-registry-docker.

C. Note Your Repository URL

It will look something like:

asia-southeast1-docker.pkg.dev/YOUR_PROJECT/YOUR_REPO/YOUR_IMAGE:TAG

3. Building Your Docker Image in GitLab CI/CD

You can automate Docker image builds using GitLab pipelines with Docker-in-Docker.

Here’s the job from your .gitlab-ci.yml:

variables:
  IMAGE_NAME_GOOGLE: "booranasak-bank-api-golang"
  IMAGE_VERSION_TAG: "1.0.0"
  IMAGE_TAG_GOOGLE: "asia-southeast1-docker.pkg.dev/escian/booranasak-artifact-registry-docker/$IMAGE_NAME_GOOGLE:$IMAGE_VERSION_TAG"  
  IMAGE_TAR: todo-api.tar

build_image:
  stage: build
  image: docker:latest
  script:
    - docker build -t $IMAGE_TAG_GOOGLE .
    - docker save $IMAGE_TAG_GOOGLE -o $IMAGE_TAR
  artifacts:
    name: "docker-image-tar"
    paths:
      - $IMAGE_TAR
    expire_in: 1 hour

What’s happening here?

docker build: Builds your image and tags it for GAR
docker save: Packages the image as a .tar file so you can use it in the next stage

4. Authenticating GitLab CI/CD with Google Cloud

To push images to GAR, your pipeline needs permission.
You do this with a Google Service Account and a GitLab CI/CD variable.

A. Create a Service Account and Key

1.) In Google Cloud, go to IAM & Admin → Service Accounts.
2.) Click Create Service Account.
3.) Give it Artifact Registry permissions (roles/artifactregistry.writer).
4.) Create and download a JSON key.

B. Add Service Account Key to GitLab

1.) In GitLab, go to your project → Settings → CI/CD → Variables.
2.) Add a variable named GCP_SA_KEY.
3.) Paste your JSON key as the value. (In my case, I convert it to base64 and save it. when I need to use it, I decode it from base64.)

5. Pushing the Image to GAR

Here’s the next job in your .gitlab-ci.yml:

push_image_to_registry:
  stage: push
  image: google/cloud-sdk:latest
  dependencies:
    - build_image
  before_script:
    - apt-get update && apt-get install -y docker.io
    - echo "$GCP_SA_KEY" | base64 -d > $CI_PROJECT_DIR/gcp-key.json
    - gcloud auth activate-service-account --key-file=$CI_PROJECT_DIR/gcp-key.json
    - gcloud config set project YOUR_PROJECT_ID
    - gcloud auth configure-docker asia-southeast1-docker.pkg.dev --quiet
  script:
    - docker load -i $IMAGE_TAR
    - docker push $IMAGE_TAG_GOOGLE

What’s happening here?

Installs Docker CLI (needed for pushing)
Sets up Google authentication using your service account key
Authenticates Docker to GAR
Loads the built image from the previous stage
Pushes the image to your GAR repository

(Insert screenshot: GitLab pipeline with push_image_to_registry job)

6. Merge scripts together

It will look like this

image: docker:latest

services:
  - docker:dind

variables:
  DOCKER_HOST: tcp://docker:2375/
  DOCKER_TLS_CERTDIR: ""
  GO_VERSION: "1.24.3"
  SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar"
  IMAGE_NAME_GOOGLE: "booranasak-bank-api-golang"
  IMAGE_VERSION_TAG: "1.0.0"
  IMAGE_TAG_GOOGLE: "asia-southeast1-docker.pkg.dev/escian/booranasak-artifact-registry-docker/$IMAGE_NAME_GOOGLE:$IMAGE_VERSION_TAG"  
  IMAGE_TAR: todo-api.tar
  GIT_DEPTH: "0"

stages:
  - lint
  - test
  - sast
  - build
  - push

.go-job-template: &go-job-template
  image: debian:bullseye
  before_script:
    - apt update && apt install -y curl git tar gzip
    - curl -LO https://go.dev/dl/go${GO_VERSION}.linux-amd64.tar.gz
    - rm -rf /usr/local/go && tar -C /usr/local -xzf go${GO_VERSION}.linux-amd64.tar.gz
    - export PATH="/usr/local/go/bin:$PATH"
    - go version

lint_golint:
  stage: lint
  <<: *go-job-template
  script:
    - export PATH="/usr/local/go/bin:$PATH"
    - go install golang.org/x/lint/golint@latest
    - export PATH="$PATH:$(go env GOPATH)/bin"
    - echo "Linting files:"
    - find . -name '*.go'
    - golint ./... | tee lint-report.txt
    - echo "--- Lint report preview ---"
    - cat lint-report.txt || echo "lint-report.txt is empty"
  allow_failure: true
  artifacts:
    name: "golint-report"
    paths:
      - lint-report.txt
    expire_in: 1 week

unit_test_and_coverage:
  stage: test
  <<: *go-job-template
  script:
    - export PATH="/usr/local/go/bin:$PATH"
    - go mod tidy
    - go test -v -cover ./...
    - go test -v -coverprofile=coverage.out ./...
  artifacts:
    paths:
      - coverage.out
    expire_in: 1 hour

sonarqube-check:
  stage: sast
  image:
    name: sonarsource/sonar-scanner-cli:11
    entrypoint: [""]
  dependencies:
    - unit_test_and_coverage
  script: 
    - sonar-scanner -Dsonar.host.url="${SONAR_HOST_URL}" -Dsonar.go.coverage.reportPaths=coverage.out -Dsonar.exclusions=**/*_test.go
  allow_failure: true
  rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
    - if: $CI_COMMIT_BRANCH == 'master'
    - if: $CI_COMMIT_BRANCH == 'main'
    - if: $CI_COMMIT_BRANCH == 'develop'

sonarqube-vulnerability-report:
  stage: sast
  image:
    name: sonarsource/sonar-scanner-cli:11
    entrypoint: [""]
  script:
    - 'curl -u "${SONAR_TOKEN}:" "${SONAR_HOST_URL}/api/issues/gitlab_sast_export?projectKey=booranasak-golang-sast&branch=${CI_COMMIT_BRANCH}&pullRequest=${CI_MERGE_REQUEST_IID}" -o gl-sast-sonar-report.json'
  allow_failure: true
  rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
    - if: $CI_COMMIT_BRANCH == 'master'
    - if: $CI_COMMIT_BRANCH == 'main'
    - if: $CI_COMMIT_BRANCH == 'develop'
  artifacts:
    expire_in: 1 day
    reports:
      sast: gl-sast-sonar-report.json

build_image:
  stage: build
  image: docker:latest
  script:
    - docker build -t $IMAGE_TAG_GOOGLE .
    - docker save $IMAGE_TAG_GOOGLE -o $IMAGE_TAR
  artifacts:
    name: "docker-image-tar"
    paths:
      - $IMAGE_TAR
    expire_in: 1 hour

push_image_to_registry:
  stage: push
  image: google/cloud-sdk:latest
  dependencies:
    - build_image
  before_script:
    - echo "Install Docker"
    - apt-get update && apt-get install -y docker.io
    - echo "Setting up Google Cloud authentication..."
    - echo "$GCP_SA_KEY" | base64 -d > $CI_PROJECT_DIR/gcp-key.json
    - gcloud auth activate-service-account --key-file=$CI_PROJECT_DIR/gcp-key.json
    - gcloud config set project escian
    - gcloud auth configure-docker asia-southeast1-docker.pkg.dev --quiet
  script:
    - docker load -i $IMAGE_TAR
    - docker push $IMAGE_TAG_GOOGLE

7. Checking Your Image in Google Cloud

Once your pipeline finishes:

Go to Artifact Registry in Google Cloud Console

Click your Docker repository

You should see your image (with its tag) listed!

Test Pulling Your Image (Optional)

On your local machine (with gcloud and Docker installed):

gcloud auth configure-docker asia-southeast1-docker.pkg.dev
docker pull asia-southeast1-docker.pkg.dev/YOUR_PROJECT/YOUR_REPO/YOUR_IMAGE:TAG

8. Troubleshooting Tips

Auth errors? Double-check your service account’s permissions and the GCP_SA_KEY variable.
Pipeline fails at Docker commands? Make sure Docker-in-Docker (docker:dind) is running and your job uses the correct image.
Image not visible in GAR? Double-check your image tags and repository URL.

9. What’s Next?

Awesome work! Your Go app is now packaged in a Docker image and stored in Google Artifact Registry—ready to be deployed anywhere.

But before we go live, let’s scan your image for vulnerabilities.
In the next episode, we’ll add Trivy to your pipeline to automatically check for security issues in your Docker image.

Summary

You learned how to build and push Docker images in GitLab CI/CD
You configured authentication for secure image uploads to GAR
Your app is ready for secure deployment and scanning!

Ready for EP 5.1? Stay tuned — we’re adding Trivy to scan images in Google Artifact Registry (GAR) for vulnerabilities!

Building, Securing, and Deploying a Go App with GitLab CI/CD EP 3: SonarQube

Booranasak Kanthong — Fri, 01 Aug 2025 10:59:27 +0000

Welcome back to EP 3 of my CI/CD Security Series!

In this episode, we’ll focus entirely on integrating SonarQube into your GitLab CI/CD pipeline. SonarQube is a powerful tool for automatically scanning your code for bugs, vulnerabilities, and code smells—right inside your pipeline.

If you missed EP 1 and 2, make sure to check it out for a full overview of the complete CI/CD security flow. Now, let’s get our hands dirty and bring SonarQube into the pipeline!

Getting Started with SonarQube

After you log in to SonarQube, you’ll land on this dashboard:

Start by clicking Create Project → Local Project.

Now, name your project as you like.

It’s a good idea to check your global settings here, too:

Integrating SonarQube with GitLab CI/CD

For this project, we’ll be using GitLab to build our CI/CD pipeline.

Click With GitLab CI to get started.

You’ll see a setup page like this:

You can follow these steps directly, but I’ll break them down for you for clarity.

Step 1: Add Environment Variables in GitLab

First, let’s add the necessary environment variables.

Head to your project in GitLab. On the sidebar, go to Settings (hover if you don’t see the label):

Then click CI/CD → Variables.

Now, click Add variable.

A sidebar will pop up:

For Key, use the value from SonarQube (e.g., SONAR_TOKEN).
For Value, go back to SonarQube and click Generate Token:

Choose your expiration date—although I usually set it to “No Expiration” for testing, I recommend setting an expiration for security reasons.

Copy your token and paste it into GitLab:

If you are working on branches other than main (for example, develop, feature, etc.), you also need to configure those branches as Protected branches.

Go to Settings → Repository:

Add a Protected Branch:

Type in your branch name:

Click Protect

Now, you’ll be able to use protected variables on these branches!

Step 2: Add SonarQube Config to Your Pipeline

Next, grab your project key from SonarQube and add it as a GitLab variable:

It should look like this:

Pick your programming language. I’m using Go for this demo:

If you don’t have a sonar-project.properties file, create one:

sonar.projectKey=booranasak-bank-golang-sast
sonar.qualitygate.wait=true

Step 3: Update Your .gitlab-ci.yml

Now, update your .gitlab-ci.yml with the following content.
(Make sure your rules include the branches you want SonarQube to run on!)

image: 
    name: sonarsource/sonar-scanner-cli:11
    entrypoint: [""]

variables:
  SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar"
  GIT_DEPTH: "0"

stages:
  - sonarqube-check
  - sonarqube-vulnerability-report

sonarqube-check:
  stage: sonarqube-check
  script: 
    - sonar-scanner -Dsonar.host.url="${SONAR_HOST_URL}"
  allow_failure: true
  rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
    - if: $CI_COMMIT_BRANCH == 'master'
    - if: $CI_COMMIT_BRANCH == 'main'
    - if: $CI_COMMIT_BRANCH == 'develop'

sonarqube-vulnerability-report:
  stage: sonarqube-vulnerability-report
  script:
    - 'curl -u "${SONAR_TOKEN}:" "${SONAR_HOST_URL}/api/issues/gitlab_sast_export?projectKey=booranasak-bank-golang-sast&branch=${CI_COMMIT_BRANCH}&pullRequest=${CI_MERGE_REQUEST_IID}" -o gl-sast-sonar-report.json'
  allow_failure: true
  rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
    - if: $CI_COMMIT_BRANCH == 'master'
    - if: $CI_COMMIT_BRANCH == 'main'
    - if: $CI_COMMIT_BRANCH == 'develop'
  artifacts:
    expire_in: 1 day
    reports:
      sast: gl-sast-sonar-report.json

Note:
By default, this pipeline only runs SonarQube on these branches:

master
main
develop Or on merge requests.

If you want to run SonarQube on another branch (like feature/sonarqube for testing), simply update the rules:

rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
    - if: $CI_COMMIT_BRANCH == 'master'
    - if: $CI_COMMIT_BRANCH == 'main'
    - if: $CI_COMMIT_BRANCH == 'develop'
    - if: $CI_COMMIT_BRANCH == 'feature/sonarqube'

That’s it! Just adjust your rules for any branches you want to include.

And now, your .gitlab-ci.yml should look something like this (I merge SonarQube into one stage but the job still separate for clarity and easier management):

sonarqube-check:
  stage: sast
  image:
    name: sonarsource/sonar-scanner-cli:11
    entrypoint: [""]
  dependencies:
    - unit_test_and_coverage
  script: 
    - sonar-scanner -Dsonar.host.url="${SONAR_HOST_URL}" -Dsonar.go.coverage.reportPaths=coverage.out -Dsonar.exclusions=**/*_test.go
  allow_failure: true
  rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
    - if: $CI_COMMIT_BRANCH == 'master'
    - if: $CI_COMMIT_BRANCH == 'main'
    - if: $CI_COMMIT_BRANCH == 'develop'

sonarqube-vulnerability-report:
  stage: sast
  image:
    name: sonarsource/sonar-scanner-cli:11
    entrypoint: [""]
  script:
    - 'curl -u "${SONAR_TOKEN}:" "${SONAR_HOST_URL}/api/issues/gitlab_sast_export?projectKey=booranasak-golang-sast&branch=${CI_COMMIT_BRANCH}&pullRequest=${CI_MERGE_REQUEST_IID}" -o gl-sast-sonar-report.json'
  allow_failure: true
  rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
    - if: $CI_COMMIT_BRANCH == 'master'
    - if: $CI_COMMIT_BRANCH == 'main'
    - if: $CI_COMMIT_BRANCH == 'develop'
  artifacts:
    expire_in: 1 day
    reports:
      sast: gl-sast-sonar-report.json

And when you merge everything together, It will look like this

image: docker:latest

services:
  - docker:dind

variables:
  DOCKER_HOST: tcp://docker:2375/
  DOCKER_TLS_CERTDIR: ""
  GO_VERSION: "1.24.3"
  SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar"
  GIT_DEPTH: "0"

stages:
  - lint
  - test
  - sast

.go-job-template: &go-job-template
  image: debian:bullseye
  before_script:
    - apt update && apt install -y curl git tar gzip
    - curl -LO https://go.dev/dl/go${GO_VERSION}.linux-amd64.tar.gz
    - rm -rf /usr/local/go && tar -C /usr/local -xzf go${GO_VERSION}.linux-amd64.tar.gz
    - export PATH="/usr/local/go/bin:$PATH"
    - go version

lint_golint:
  stage: lint
  <<: *go-job-template
  script:
    - export PATH="/usr/local/go/bin:$PATH"
    - go install golang.org/x/lint/golint@latest
    - export PATH="$PATH:$(go env GOPATH)/bin"
    - echo "Linting files:"
    - find . -name '*.go'
    - golint ./... | tee lint-report.txt
    - echo "--- Lint report preview ---"
    - cat lint-report.txt || echo "lint-report.txt is empty"
  allow_failure: true
  artifacts:
    name: "golint-report"
    paths:
      - lint-report.txt
    expire_in: 1 week

unit_test_and_coverage:
  stage: test
  <<: *go-job-template
  script:
    - export PATH="/usr/local/go/bin:$PATH"
    - go mod tidy
    - go test -v -cover ./...
    - go test -v -coverprofile=coverage.out ./...
  artifacts:
    paths:
      - coverage.out
    expire_in: 1 hour

sonarqube-check:
  stage: sast
  image:
    name: sonarsource/sonar-scanner-cli:11
    entrypoint: [""]
  dependencies:
    - unit_test_and_coverage
  script: 
    - sonar-scanner -Dsonar.host.url="${SONAR_HOST_URL}" -Dsonar.go.coverage.reportPaths=coverage.out -Dsonar.exclusions=**/*_test.go
  allow_failure: true
  rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
    - if: $CI_COMMIT_BRANCH == 'master'
    - if: $CI_COMMIT_BRANCH == 'main'
    - if: $CI_COMMIT_BRANCH == 'develop'

sonarqube-vulnerability-report:
  stage: sast
  image:
    name: sonarsource/sonar-scanner-cli:11
    entrypoint: [""]
  script:
    - 'curl -u "${SONAR_TOKEN}:" "${SONAR_HOST_URL}/api/issues/gitlab_sast_export?projectKey=booranasak-golang-sast&branch=${CI_COMMIT_BRANCH}&pullRequest=${CI_MERGE_REQUEST_IID}" -o gl-sast-sonar-report.json'
  allow_failure: true
  rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
    - if: $CI_COMMIT_BRANCH == 'master'
    - if: $CI_COMMIT_BRANCH == 'main'
    - if: $CI_COMMIT_BRANCH == 'develop'
  artifacts:
    expire_in: 1 day
    reports:
      sast: gl-sast-sonar-report.json

Pipeline Example

Sonarqube Example

Failed Example

First issue are code coverage below 80 percent

Second issue are Duplicated string literals

You can also view more detail

even explain why it was an issue

Even more!!!, Explain how to fix it

Simple, right? With these steps, you can integrate SonarQube into your GitLab CI/CD pipeline and customize it to fit your workflow.

Building, Securing, and Deploying a Go App with GitLab CI/CD EP 2: Linting, and Coverage Test in Your Go Pipeline

Booranasak Kanthong — Fri, 01 Aug 2025 10:48:06 +0000

Introduction

Welcome back! In the last episode, we learned what CI/CD is and how to set up a simple pipeline in GitLab using Docker-in-Docker. Now, let’s make things more interesting by adding real Go code to our project.

In this post, you’ll:

Create a new file and paste in the Go code below:
Set up a pipeline to lint (check) your code style automatically
Run tests with coverage and see how well your code is tested
Learn how to store and view these results in GitLab

By the end, you’ll have a working Go app in CI/CD with code quality checks—just like a real pro!

Step 1: Get the Example Go Project

So you can follow along with exactly what I’m doing, here’s the same code I use:

File Stucture

Create a new file and paste in the Go code below:

bank-api\cmd\server\main.go

package main

import (
    "bank-api/internal/handler"
    "log"
    "net/http"
)

func main() {
    h := handler.New()
    log.Println("✅ Bank API listening on :8508")
    log.Fatal(http.ListenAndServe(":8508", h.Router()))
}

bank-api\internal\handler\handler_test.go

package handler

import (
    "bytes"
    "encoding/json"
    "net/http"
    "net/http/httptest"
    "strconv"
    "testing"
)

// helper to open a new account and return its ID
func createAccount(t *testing.T, router http.Handler, name string) int64 {
    body := `{"name":"` + name + `"}`
    req := httptest.NewRequest(http.MethodPost, "/accounts", bytes.NewBufferString(body))
    req.Header.Set("Content-Type", "application/json")
    rec := httptest.NewRecorder()

    router.ServeHTTP(rec, req)
    if rec.Code != http.StatusCreated {
        t.Fatalf("open account: want 201 got %d", rec.Code)
    }

    var resp struct{ ID int64 }
    if err := json.NewDecoder(rec.Body).Decode(&resp); err != nil {
        t.Fatalf("decode id: %v", err)
    }
    return resp.ID
}

func TestGetAllAccounts(t *testing.T) {
    h := New()
    r := h.Router()

    // we seeded 10 mock accounts in NewMemory()
    req := httptest.NewRequest(http.MethodGet, "/accounts", nil)
    rec := httptest.NewRecorder()
    r.ServeHTTP(rec, req)

    if rec.Code != http.StatusOK {
        t.Fatalf("get all accounts: want 200 got %d", rec.Code)
    }

    var list []struct {
        ID      int64
        Name    string
        Balance float64
    }
    if err := json.NewDecoder(rec.Body).Decode(&list); err != nil {
        t.Fatalf("decode list: %v", err)
    }

    if len(list) != 10 {
        t.Errorf("expected 10 accounts, got %d", len(list))
    }

    // spot-check first seeded account
    if list[0].ID != 1 || list[0].Name != "Alice" {
        t.Errorf("first account = %+v; want ID=1, Name=Alice", list[0])
    }
}

func TestOpenGetDepositWithdrawFlow(t *testing.T) {
    h := New()
    r := h.Router()

    id := createAccount(t, r, "Alice")

    // deposit
    depBody := `{"amount":100}`
    req := httptest.NewRequest(http.MethodPost,
        "/accounts/"+strconv.FormatInt(id, 10)+"/deposit",
        bytes.NewBufferString(depBody),
    )
    req.Header.Set("Content-Type", "application/json")
    rec := httptest.NewRecorder()
    r.ServeHTTP(rec, req)

    // withdraw
    withBody := `{"amount":30}`
    req = httptest.NewRequest(http.MethodPost,
        "/accounts/"+strconv.FormatInt(id, 10)+"/withdraw",
        bytes.NewBufferString(withBody),
    )
    req.Header.Set("Content-Type", "application/json")
    rec = httptest.NewRecorder()
    r.ServeHTTP(rec, req)

    // get balance
    req = httptest.NewRequest(http.MethodGet,
        "/accounts/"+strconv.FormatInt(id, 10),
        nil,
    )
    rec = httptest.NewRecorder()
    r.ServeHTTP(rec, req)

    var acc struct{ Balance float64 }
    if err := json.NewDecoder(rec.Body).Decode(&acc); err != nil {
        t.Fatalf("decode account: %v", err)
    }
    if acc.Balance != 70 {
        t.Errorf("expected balance 70 got %f", acc.Balance)
    }
}

func TestDepositInvalidAmount(t *testing.T) {
    h := New()
    r := h.Router()
    id := createAccount(t, r, "Bob")

    neg := `{"amount":-5}`
    req := httptest.NewRequest(http.MethodPost,
        "/accounts/"+strconv.FormatInt(id, 10)+"/deposit",
        bytes.NewBufferString(neg),
    )
    req.Header.Set("Content-Type", "application/json")
    rec := httptest.NewRecorder()
    r.ServeHTTP(rec, req)
    if rec.Code != http.StatusBadRequest {
        t.Fatalf("neg deposit: want 400 got %d", rec.Code)
    }
}

func TestWithdrawInsufficientFunds(t *testing.T) {
    h := New()
    r := h.Router()
    id := createAccount(t, r, "Charlie")

    withBody := `{"amount":50}`
    req := httptest.NewRequest(http.MethodPost,
        "/accounts/"+strconv.FormatInt(id, 10)+"/withdraw",
        bytes.NewBufferString(withBody),
    )
    req.Header.Set("Content-Type", "application/json")
    rec := httptest.NewRecorder()
    r.ServeHTTP(rec, req)
    if rec.Code != http.StatusBadRequest {
        t.Fatalf("withdraw no money: want 400 got %d", rec.Code)
    }
}

func TestInvalidAccountID(t *testing.T) {
    h := New()
    r := h.Router()

    req := httptest.NewRequest(http.MethodGet, "/accounts/abc", nil)
    rec := httptest.NewRecorder()
    r.ServeHTTP(rec, req)
    if rec.Code != http.StatusBadRequest {
        t.Fatalf("invalid id: want 400 got %d", rec.Code)
    }
}

func TestMethodNotAllowed(t *testing.T) {
    h := New()
    r := h.Router()

    // PUT /accounts is not supported (only GET, POST)
    req := httptest.NewRequest(http.MethodPut, "/accounts", nil)
    rec := httptest.NewRecorder()
    r.ServeHTTP(rec, req)
    if rec.Code != http.StatusMethodNotAllowed {
        t.Fatalf("method not allowed: want 405 got %d", rec.Code)
    }
}

func TestInvalidJSONInOpenAccount(t *testing.T) {
    h := New()
    r := h.Router()

    req := httptest.NewRequest(http.MethodPost, "/accounts", bytes.NewBufferString("{"))
    req.Header.Set("Content-Type", "application/json")
    rec := httptest.NewRecorder()
    r.ServeHTTP(rec, req)
    if rec.Code != http.StatusBadRequest {
        t.Errorf("expected 400 for bad JSON, got %d", rec.Code)
    }
}

func TestInvalidJSONInDeposit(t *testing.T) {
    h := New()
    r := h.Router()
    id := createAccount(t, r, "BrokenDeposit")

    req := httptest.NewRequest(http.MethodPost,
        "/accounts/"+strconv.FormatInt(id, 10)+"/deposit",
        bytes.NewBufferString("{"),
    )
    req.Header.Set("Content-Type", "application/json")
    rec := httptest.NewRecorder()
    r.ServeHTTP(rec, req)
    if rec.Code != http.StatusBadRequest {
        t.Errorf("expected 400 for bad JSON, got %d", rec.Code)
    }
}

func TestInvalidSubRoute(t *testing.T) {
    h := New()
    r := h.Router()
    id := createAccount(t, r, "UnknownPath")

    req := httptest.NewRequest(http.MethodPost,
        "/accounts/"+strconv.FormatInt(id, 10)+"/unexpected",
        nil,
    )
    rec := httptest.NewRecorder()
    r.ServeHTTP(rec, req)
    if rec.Code != http.StatusNotFound {
        t.Errorf("expected 404 for unknown subroute, got %d", rec.Code)
    }
}

func TestReadRootAllowed(t *testing.T) {
    h := New()
    r := h.Router()

    req := httptest.NewRequest(http.MethodGet, "/", nil)
    rec := httptest.NewRecorder()
    r.ServeHTTP(rec, req)

    if rec.Code != http.StatusOK {
        t.Errorf("expected 200, got %d", rec.Code)
    }
    if body := rec.Body.String(); body != "👋 Welcome to the Bank API!" {
        t.Errorf("unexpected body: %s", body)
    }
}

func TestReadRootMethodNotAllowed(t *testing.T) {
    h := New()
    r := h.Router()

    req := httptest.NewRequest(http.MethodPost, "/", nil)
    rec := httptest.NewRecorder()
    r.ServeHTTP(rec, req)

    if rec.Code != http.StatusMethodNotAllowed {
        t.Errorf("expected 405, got %d", rec.Code)
    }
}

func TestOpenAccountWrongMethod(t *testing.T) {
    h := New()

    req := httptest.NewRequest(http.MethodGet, "/accounts", nil)
    rec := httptest.NewRecorder()

    // simulate direct call to openAccount handler method
    h.openAccount(rec, req)

    if rec.Code != http.StatusMethodNotAllowed {
        t.Errorf("expected 405, got %d", rec.Code)
    }
}

func TestAccountsMethodNotAllowed(t *testing.T) {
    h := New()
    r := h.Router()

    req := httptest.NewRequest(http.MethodPut, "/accounts", nil)
    rec := httptest.NewRecorder()
    r.ServeHTTP(rec, req)

    if rec.Code != http.StatusMethodNotAllowed {
        t.Errorf("expected 405, got %d", rec.Code)
    }
}

bank-api\internal\handler\handler.go

// internal/handler/handler.go
package handler

import (
    "bank-api/internal/repository"
    "bank-api/internal/service"
    "encoding/json"
    "net/http"
    "strconv"
    "strings"
)

const errMethodNotAllowed = "method not allowed"

type Handler struct{ bank *service.Bank }

// New returns Handler with in-memory backend and seeds 10 mock accounts.
func New() *Handler {
    mem := repository.NewMemory()
    b := service.NewBank(mem)

    names := []string{
        "Alice", "Bob", "Carol", "Dave", "Eve",
        "Frank", "Grace", "Heidi", "Ivan", "Judy",
    }
    for i, name := range names {
        acc := b.Open(name)
        _, _ = b.Deposit(acc.ID, float64((i+1)*1000))
    }

    return &Handler{bank: b}
}

// Router wires endpoints in an organized way.
func (h *Handler) Router() *http.ServeMux {
    mux := http.NewServeMux()
    mux.HandleFunc("/", h.readRoot)                // GET /
    mux.HandleFunc("/accounts", h.accounts)        // GET /accounts, POST /accounts
    mux.HandleFunc("/accounts/", h.accountActions) // GET /accounts/{id}, POST …/deposit, …/withdraw
    return mux
}

func (h *Handler) readRoot(w http.ResponseWriter, r *http.Request) {
    if r.Method != http.MethodGet {
        http.Error(w, errMethodNotAllowed, http.StatusMethodNotAllowed)
        return
    }
    w.Header().Set("Content-Type", "text/plain")
    w.WriteHeader(http.StatusOK)
    w.Write([]byte("👋 Welcome to the Bank API!"))
}

// accounts handles GET all and POST create on /accounts
func (h *Handler) accounts(w http.ResponseWriter, r *http.Request) {
    switch r.Method {
    case http.MethodGet:
        list, err := h.bank.All()
        if err != nil {
            http.Error(w, err.Error(), http.StatusInternalServerError)
            return
        }
        writeJSON(w, http.StatusOK, list)
    case http.MethodPost:
        h.openAccount(w, r)
    default:
        http.Error(w, errMethodNotAllowed, http.StatusMethodNotAllowed)
    }
}

func (h *Handler) openAccount(w http.ResponseWriter, r *http.Request) {
    if r.Method != http.MethodPost {
        http.Error(w, errMethodNotAllowed, http.StatusMethodNotAllowed)
        return
    }
    var req struct{ Name string }
    if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
        http.Error(w, err.Error(), http.StatusBadRequest)
        return
    }
    acc := h.bank.Open(req.Name)
    writeJSON(w, http.StatusCreated, acc)
}

func (h *Handler) accountActions(w http.ResponseWriter, r *http.Request) {
    parts := strings.Split(strings.TrimPrefix(r.URL.Path, "/accounts/"), "/")
    id, err := strconv.ParseInt(parts[0], 10, 64)
    if err != nil {
        http.Error(w, "invalid id", http.StatusBadRequest)
        return
    }

    switch {
    case r.Method == http.MethodGet && len(parts) == 1:
        acc, err := h.bank.Lookup(id)
        if err != nil {
            http.Error(w, err.Error(), http.StatusNotFound)
            return
        }
        writeJSON(w, http.StatusOK, acc)

    case r.Method == http.MethodPost && len(parts) == 2 && parts[1] == "deposit":
        var body struct{ Amount float64 }
        if err := json.NewDecoder(r.Body).Decode(&body); err != nil {
            http.Error(w, err.Error(), http.StatusBadRequest)
            return
        }
        acc, err := h.bank.Deposit(id, body.Amount)
        if err != nil {
            http.Error(w, err.Error(), http.StatusBadRequest)
            return
        }
        writeJSON(w, http.StatusOK, acc)

    case r.Method == http.MethodPost && len(parts) == 2 && parts[1] == "withdraw":
        var body struct{ Amount float64 }
        if err := json.NewDecoder(r.Body).Decode(&body); err != nil {
            http.Error(w, err.Error(), http.StatusBadRequest)
            return
        }
        acc, err := h.bank.Withdraw(id, body.Amount)
        if err != nil {
            http.Error(w, err.Error(), http.StatusBadRequest)
            return
        }
        writeJSON(w, http.StatusOK, acc)

    default:
        http.Error(w, "not found", http.StatusNotFound)
    }
}

func writeJSON(w http.ResponseWriter, code int, v any) {
    w.Header().Set("Content-Type", "application/json")
    w.WriteHeader(code)
    _ = json.NewEncoder(w).Encode(v)
}

bank-api\internal\model\account.go

package model

// Account represents a simple bank account.
type Account struct {
    ID      int64   `json:"id"`
    Name    string  `json:"name"`
    Balance float64 `json:"balance"`
}

bank-api\internal\repository\memory.go

// internal/repository/memory.go
package repository

import (
    "errors"
    "sort"
    "sync"

    "bank-api/internal/model"
)

var (
    ErrNotFound         = errors.New("account not found")
    ErrInvalidAmount    = errors.New("amount must be positive")
    ErrInsufficientFund = errors.New("insufficient funds")
)

// MemoryRepo is an in-memory store implementing basic CRUD for accounts.
type MemoryRepo struct {
    mu      sync.RWMutex
    nextID  int64
    records map[int64]*model.Account
}

// NewMemory returns a fresh, empty MemoryRepo.
func NewMemory() *MemoryRepo {
    return &MemoryRepo{
        records: make(map[int64]*model.Account),
        nextID:  1,
    }
}

// Create opens a new account with zero balance.
func (m *MemoryRepo) Create(name string) *model.Account {
    m.mu.Lock()
    defer m.mu.Unlock()
    acc := &model.Account{ID: m.nextID, Name: name}
    m.records[acc.ID] = acc
    m.nextID++
    return acc
}

// Get fetches account by id.
func (m *MemoryRepo) Get(id int64) (*model.Account, error) {
    m.mu.RLock()
    defer m.mu.RUnlock()
    acc, ok := m.records[id]
    if !ok {
        return nil, ErrNotFound
    }
    return acc, nil
}

// All returns all accounts, sorted by ascending ID.
func (m *MemoryRepo) All() ([]*model.Account, error) {
    m.mu.RLock()
    defer m.mu.RUnlock()
    list := make([]*model.Account, 0, len(m.records))
    for _, acc := range m.records {
        list = append(list, acc)
    }
    // sort by ID so callers always see [ID=1,2,3…]
    sort.Slice(list, func(i, j int) bool {
        return list[i].ID < list[j].ID
    })
    return list, nil
}

// Deposit increases balance.
func (m *MemoryRepo) Deposit(id int64, amt float64) (*model.Account, error) {
    if amt <= 0 {
        return nil, ErrInvalidAmount
    }
    m.mu.Lock()
    defer m.mu.Unlock()
    acc, ok := m.records[id]
    if !ok {
        return nil, ErrNotFound
    }
    acc.Balance += amt
    return acc, nil
}

// Withdraw decreases balance.
func (m *MemoryRepo) Withdraw(id int64, amt float64) (*model.Account, error) {
    if amt <= 0 {
        return nil, ErrInvalidAmount
    }
    m.mu.Lock()
    defer m.mu.Unlock()
    acc, ok := m.records[id]
    if !ok {
        return nil, ErrNotFound
    }
    if acc.Balance < amt {
        return nil, ErrInsufficientFund
    }
    acc.Balance -= amt
    return acc, nil
}

bank-api\internal\repository\repository_test.go

package repository

import (
    "testing"
)

// createTestRepo returns a new MemoryRepo with one account.
func createTestRepo() (*MemoryRepo, int64) {
    repo := NewMemory()
    acc := repo.Create("Test")
    return repo, acc.ID
}

func TestCreateAndGet(t *testing.T) {
    repo := NewMemory()
    acc := repo.Create("Alice")

    // Check Create()
    if acc.ID != 1 || acc.Name != "Alice" || acc.Balance != 0 {
        t.Errorf("unexpected account after Create(): %+v", acc)
    }

    // Check Get() returns the same pointer
    got, err := repo.Get(acc.ID)
    if err != nil {
        t.Fatalf("Get() failed: %v", err)
    }
    if got != acc {
        t.Error("Get() returned a different pointer than Create()")
    }
}

func TestGetNotFound(t *testing.T) {
    repo := NewMemory()
    _, err := repo.Get(999)
    if err != ErrNotFound {
        t.Errorf("Get(999): want ErrNotFound, got %v", err)
    }
}

func TestDepositSuccess(t *testing.T) {
    repo, id := createTestRepo()
    _, err := repo.Deposit(id, 50)
    if err != nil {
        t.Errorf("Deposit() error: %v", err)
    }
    got, _ := repo.Get(id)
    if got.Balance != 50 {
        t.Errorf("after Deposit, Balance = %f; want 50", got.Balance)
    }
}

func TestDepositNegative(t *testing.T) {
    repo, id := createTestRepo()
    _, err := repo.Deposit(id, -10)
    if err != ErrInvalidAmount {
        t.Errorf("Deposit(-10): want ErrInvalidAmount, got %v", err)
    }
}

func TestDepositNotFound(t *testing.T) {
    repo := NewMemory()
    _, err := repo.Deposit(999, 10)
    if err != ErrNotFound {
        t.Errorf("Deposit on missing ID: want ErrNotFound, got %v", err)
    }
}

func TestWithdrawSuccess(t *testing.T) {
    repo, id := createTestRepo()
    repo.Deposit(id, 100)
    _, err := repo.Withdraw(id, 30)
    if err != nil {
        t.Errorf("Withdraw() error: %v", err)
    }
    got, _ := repo.Get(id)
    if got.Balance != 70 {
        t.Errorf("after Withdraw, Balance = %f; want 70", got.Balance)
    }
}

func TestWithdrawNegative(t *testing.T) {
    repo, id := createTestRepo()
    _, err := repo.Withdraw(id, -5)
    if err != ErrInvalidAmount {
        t.Errorf("Withdraw(-5): want ErrInvalidAmount, got %v", err)
    }
}

func TestWithdrawNotFound(t *testing.T) {
    repo := NewMemory()
    _, err := repo.Withdraw(999, 10)
    if err != ErrNotFound {
        t.Errorf("Withdraw on missing ID: want ErrNotFound, got %v", err)
    }
}

func TestWithdrawInsufficientFund(t *testing.T) {
    repo, id := createTestRepo()
    repo.Deposit(id, 20)
    _, err := repo.Withdraw(id, 50)
    if err != ErrInsufficientFund {
        t.Errorf("Withdraw(50) with only 20 balance: want ErrInsufficientFund, got %v", err)
    }
}

// --- New tests for All() ---

func TestAllEmpty(t *testing.T) {
    repo := NewMemory()
    list, err := repo.All()
    if err != nil {
        t.Fatalf("All() on empty repo returned error: %v", err)
    }
    if len(list) != 0 {
        t.Errorf("All() on empty repo = %d accounts; want 0", len(list))
    }
}

func TestAllSortedByID(t *testing.T) {
    repo := NewMemory()

    // Create three accounts; IDs will be 1,2,3
    a := repo.Create("Zeta")
    b := repo.Create("Alpha")
    c := repo.Create("Omega")

    list, err := repo.All()
    if err != nil {
        t.Fatalf("All() returned error: %v", err)
    }
    if len(list) != 3 {
        t.Fatalf("All() = %d accounts; want 3", len(list))
    }

    // Expect ascending ID order: [1,2,3]
    for i, acc := range list {
        wantID := int64(i + 1)
        if acc.ID != wantID {
            t.Errorf("All()[%d].ID = %d; want %d", i, acc.ID, wantID)
        }
    }

    // Ensure pointers match the ones returned by Create
    if list[0] != a || list[1] != b || list[2] != c {
        t.Error("All() did not preserve account pointers in ID order")
    }
}

bank-api\internal\service\service.go

package service

import (
    "bank-api/internal/model"
    "bank-api/internal/repository"
)

// Bank provides high-level business operations.
type Bank struct {
    repo *repository.MemoryRepo
}

// NewBank creates a Bank with the supplied repo.
func NewBank(r *repository.MemoryRepo) *Bank { return &Bank{repo: r} }

// Open opens a new account.
func (b *Bank) Open(name string) *model.Account {
    return b.repo.Create(name)
}

// Lookup fetches account.
func (b *Bank) Lookup(id int64) (*model.Account, error) {
    return b.repo.Get(id)
}

// Deposit adds amount.
func (b *Bank) Deposit(id int64, amt float64) (*model.Account, error) {
    return b.repo.Deposit(id, amt)
}

// Withdraw subtracts amount.
func (b *Bank) Withdraw(id int64, amt float64) (*model.Account, error) {
    return b.repo.Withdraw(id, amt)
}

// All fetches all accounts.
func (b *Bank) All() ([]*model.Account, error) {
    return b.repo.All()
}

bank-api\internal\service\service_test.go

package service

import (
    "bank-api/internal/repository"
    "testing"
)

func newBank() *Bank {
    return NewBank(repository.NewMemory())
}

func TestDepositWithdrawFlow(t *testing.T) {
    b := newBank()
    acc := b.Open("Alice")

    if _, err := b.Deposit(acc.ID, 100); err != nil {
        t.Fatalf("deposit error: %v", err)
    }
    if _, err := b.Withdraw(acc.ID, 30); err != nil {
        t.Fatalf("withdraw error: %v", err)
    }
    got, _ := b.Lookup(acc.ID)
    if got.Balance != 70 {
        t.Errorf("expected balance 70 got %f", got.Balance)
    }
}

func TestInvalidAmount(t *testing.T) {
    b := newBank()
    acc := b.Open("Bob")
    if _, err := b.Deposit(acc.ID, -1); err == nil {
        t.Error("expected error on negative deposit")
    }
}

func TestInsufficientFund(t *testing.T) {
    b := newBank()
    acc := b.Open("Charlie")
    if _, err := b.Withdraw(acc.ID, 10); err == nil {
        t.Error("expected insufficient funds error")
    }
}

bank-api\go.mod

module bank-api

go 1.22

bank-api/.gitlab-ci.yml

image: docker:latest

services:
  - docker:dind

variables:
  DOCKER_HOST: tcp://docker:2375/
  DOCKER_TLS_CERTDIR: ""
  GO_VERSION: "1.24.3"
  GIT_DEPTH: "0"

.go-job-template: &go-job-template
  image: debian:bullseye
  before_script:
    - apt update && apt install -y curl git tar gzip
    - curl -LO https://go.dev/dl/go${GO_VERSION}.linux-amd64.tar.gz
    - rm -rf /usr/local/go && tar -C /usr/local -xzf go${GO_VERSION}.linux-amd64.tar.gz
    - export PATH="/usr/local/go/bin:$PATH"
    - go version

How it works:

Installs golint using Go’s install command directly in the pipeline.
Updates your system’s PATH so the golint binary can be used right away.
Searches for all .go files in your project (just for info).
Runs golint on your entire codebase and saves the output to lint-report.txt.
Shows a quick preview of the lint report in the job logs—even if the report is empty, you’ll get a message.
Marks the job as optional (allow_failure: true), so lint warnings won’t break your pipeline while you’re still getting set up.
Stores the lint report as an artifact, so you can view or download it from GitLab after the pipeline completes.

Viewing lint results:
After the pipeline runs, open the pipeline details, click on the lint job, and download or preview lint-report.txt to see your linting feedback.

Step 3: Automated Testing with Coverage

Why test with coverage?
Tests make sure your code works as expected. Coverage shows what percent of your code is tested.

Add a Test and Coverage Job

Add this job under the test stage in .gitlab-ci.yml:

unit_test_and_coverage:
  stage: test
  <<: *go-job-template
  script:
    - export PATH="/usr/local/go/bin:$PATH"
    - go mod tidy
    - go test -v -cover ./...
    - go test -v -coverprofile=coverage.out ./...
  artifacts:
    paths:
      - coverage.out
    expire_in: 1 hour

README.md
README.md

How it works:

Runs all your unit tests with detailed output, so you can see exactly what’s happening.
Calculates your test coverage and prints it right in the pipeline logs.
Generates a coverage.out file, which is saved as an artifact—handy for later steps like code quality checks or security scans.

Where to find it:

After the pipeline finishes, click into the test job to check the logs and download coverage.out if you want a closer look.

How Artifacts are Shared

GitLab artifacts let you share files between jobs. For example, the coverage.out file will be used by SAST tools in the next episode.

Lint job produces lint-report.txt
Test job produces coverage.out
Both are available for download and use in later jobs

Tips & Best Practices

allow_failure: true lets you try linting without breaking the pipeline if there are issues. This is great for beginners or teams just getting started.
Always review lint and test results! Fixing issues early saves lots of pain later.
Keep your pipeline simple at first—add complexity as you go.

And when you merge everything together, It will look like this

image: docker:latest

services:
  - docker:dind

variables:
  DOCKER_HOST: tcp://docker:2375/
  DOCKER_TLS_CERTDIR: ""
  GO_VERSION: "1.24.3"
  GIT_DEPTH: "0"

stages:
  - lint
  - test
  - sast

.go-job-template: &go-job-template
  image: debian:bullseye
  before_script:
    - apt update && apt install -y curl git tar gzip
    - curl -LO https://go.dev/dl/go${GO_VERSION}.linux-amd64.tar.gz
    - rm -rf /usr/local/go && tar -C /usr/local -xzf go${GO_VERSION}.linux-amd64.tar.gz
    - export PATH="/usr/local/go/bin:$PATH"
    - go version

lint_golint:
  stage: lint
  <<: *go-job-template
  script:
    - export PATH="/usr/local/go/bin:$PATH"
    - go install golang.org/x/lint/golint@latest
    - export PATH="$PATH:$(go env GOPATH)/bin"
    - echo "Linting files:"
    - find . -name '*.go'
    - golint ./... | tee lint-report.txt
    - echo "--- Lint report preview ---"
    - cat lint-report.txt || echo "lint-report.txt is empty"
  allow_failure: true
  artifacts:
    name: "golint-report"
    paths:
      - lint-report.txt
    expire_in: 1 week

unit_test_and_coverage:
  stage: test
  <<: *go-job-template
  script:
    - export PATH="/usr/local/go/bin:$PATH"
    - go mod tidy
    - go test -v -cover ./...
    - go test -v -coverprofile=coverage.out ./...
  artifacts:
    paths:
      - coverage.out
    expire_in: 1 hour

Pipeline Example

Here’s what your pipeline might look like after adding these jobs:

Preview: Next Episode

Awesome! You now have a Go project with real code, automatic style checks, and testing with coverage—all running in GitLab CI/CD.

In the next episode, we’ll:

Add SonarQube to check your code for bugs and security issues
Use your coverage reports to get even better insights

Stay tuned, and happy coding!

Building, Securing, and Deploying a Go App with GitLab CI/CD EP 1: Getting Started with GitLab CI/CD and Docker-in-Docker

Booranasak Kanthong — Fri, 01 Aug 2025 09:23:22 +0000

Introduction

Welcome to the first episode of our CI/CD journey!
In this guide, I’ll help you understand how to automate your software development using GitLab CI/CD. We’ll also talk about a key concept called Docker-in-Docker—but don’t worry, I’ll break everything down in simple steps.

By the end of this post, you’ll know:

What GitLab CI/CD is and why it’s useful
What a pipeline is (and why we need one)
How Docker and Docker-in-Docker help us build and test code in CI/CD

Ready? Let’s dive in!

1. What is GitLab CI/CD?

CI/CD stands for Continuous Integration and Continuous Deployment.
It’s a way to automate all those repetitive tasks that happen after you push code—like checking for errors, running tests, and even deploying your app.

GitLab CI/CD is a feature of GitLab (a platform for hosting your code), which lets you build these automation “pipelines” right alongside your code.

Why use it?

Saves time: No more manual testing or deployment
Catches bugs early: Automated checks run every time you push code
Works for every project: From small scripts to big apps

2. What is a Pipeline?

A pipeline is just a series of steps (called “jobs”) that run automatically every time you push code.
Each job does one thing—like checking your code style, running tests, or building your app.

Think of a pipeline like a factory assembly line:

First, your code is checked for errors
Next, it’s tested
Then, it’s built and sent where it needs to go

Here’s what a simple pipeline might look like:

Lint: Check your code style
Test: Run your tests
Build: Make your app ready to run
Deploy: Send your app to a server

In GitLab, you control your pipeline with a special file called .gitlab-ci.yml.

3. What is Docker and Docker-in-Docker?

Docker is a tool that lets you package your app and everything it needs to run (like code, settings, libraries) into a “container.”
Containers are like lightweight, portable computers for your app—they make sure it runs the same way everywhere.

Docker-in-Docker (DinD)
Usually, Docker runs on your computer or server. But in CI/CD, you often need to use Docker inside another Docker container—this is called Docker-in-Docker.

Why do we use it in CI/CD?

So the pipeline can build, test, and run containers automatically—without needing a full server for each job
It keeps your builds isolated and clean

Visual Example:
Imagine a Russian nesting doll—one Docker container (the CI job) runs another Docker container (your app or build).

Breakdown of the Image

Big Blue Creature (CI Job):
Represents a CI (Continuous Integration) job or runner. In most CI/CD platforms (like GitLab CI, GitHub Actions, Jenkins, etc.), jobs are executed in containers or virtual machines.
Small Docker Whale Inside:
Inside the CI job, you see the familiar Docker whale. This shows that the CI job itself is running a Docker daemon inside the CI environment.
Containers/Blocks Inside the Whale:
These represent your app or build containers, which are being created and managed inside this inner Docker daemon.

Note:
Docker-in-Docker is super useful, but it does have some security considerations. For beginner projects, it’s usually just fine!

4. Setting Up Your GitLab Project

Let’s get started step by step:

A. Create a New Project

4.1.1) Go to GitLab and log in (sign up if you don’t have an account).

4.1.2) Click the **“New project” button.**

4.1.3) Select how you want to create your project

4.1.4) Name your project and choose your settings (public or private).

B. Push Your Local Project to GitLab

Now that your project is created, let’s upload your code from your computer to GitLab.

4.2.1) Open your terminal and navigate to your project folder

   cd path/to/your/project

4.2.2) Initialize a Git repository (if you haven’t already):

   git init

4.2.3) Add the GitLab repository as a remote:
Replace YOUR-USERNAME and YOUR-PROJECT with your actual GitLab info.

   git remote add origin https://gitlab.com/YOUR-USERNAME/YOUR-PROJECT.git

4.2.4) Change branch master to main

   git branch -M main

Optional If your Auto generate Gitlab repo have readme.md you can pull it down and have it modifies before push it back as well

git pull origin YOUR-PROJECT-BRANCH

For example

git pull origin develop

4.2.5) Add, commit, and push your code:

   git add .
   git commit -m "Initial commit"
   git push -u origin master

That’s it! Your code is now on GitLab, and you’re ready to start using CI/CD.

C. Explore the Interface

The sidebar lets you see your code, pipelines, CI/CD, and more.

Under “Build”, you’ll see pipelines and jobs as you build them.

5. Your First `.gitlab-ci.yml` File

This file tells GitLab how to run your pipeline.
Let’s start with a basic version that just runs Docker commands (using Docker-in-Docker):

image: docker:latest

services:
  - docker:dind

stages:
  - build

build_image:
  stage: build
  script:
    - echo "Hello from inside Docker-in-Docker!"
    - docker version
    - docker info

image: docker:latest: Use Docker in the pipeline.
services: - docker:dind: Start the Docker-in-Docker service so we can use Docker commands.
stages: - build: We’ll just have a build stage for now.
The job build_image just prints out Docker info to show it works.

How to use:

Copy and paste this into a file called .gitlab-ci.yml in the root of your project.
Commit and push your code.
Go to your project’s CI/CD → Pipelines page and watch your first pipeline run!

6. What’s Next?

Now you’ve created your first pipeline and learned what Docker-in-Docker is all about!

In the next episode, we’ll:

Set up Go on the pipeline
Add linting to automatically check your code style
Store and view lint reports

Stay tuned—and congrats on starting your CI/CD journey!

Pulling Docker Images from Google Artifact Registry (GAR) in GitLab CI/CD

Booranasak Kanthong — Fri, 25 Jul 2025 03:12:46 +0000

Step 1: Activate a Google Cloud Service Account for Secure CI/CD on Linux

When working with cloud-native CI/CD pipelines or Dockerized workloads on Google Cloud Platform (GCP), you often need a service account to authenticate your scripts or tools like gcloud, Docker, or Terraform. In this post, we’ll walk through how to activate a service account using a JSON key file on a Linux machine — the foundational step to enabling automated, authenticated access to GCP resources.

This guide is particularly useful if:

You're running a self-hosted GitLab Runner
You want to pull private images from Google Artifact Registry
You need secure access to GCP from a server or VM

Step 1: Prerequisites
Before starting, make sure you have:

A Linux machine (e.g., GCP VM, local server)
gcloud CLI installed (see official docs if not)
A service account JSON key file, e.g.:

escian-bb074f590610.json

Your key name will be different from mine.

Place this file somewhere secure — for example:

/etc/gitlab-runner/escian-bb074f590610.json

Don't put this on tmp folder because It gets wiped on reboot or by system cleanup jobs

Step 2: Activate the Service Account

Use the following command to activate your service account:

gcloud auth activate-service-account --key-file=/etc/gitlab-runner/escian-bb074f590610.json

If successful, you'll see:

Activated service account credentials for: [your-service-account@your-project.iam.gserviceaccount.com]

Your key file name will likely be different from mine. Adjust the path as needed.

How to Check Which User GitLab Runner Uses

ps -o user:20,pid,cmd -C gitlab-runner

If you see something like this:

USER                 PID CMD
root                 435 /usr/bin/gitlab-runner run ...

Then GitLab Runner is running as root, and you must activate and configure Docker as root.

To Auth as root, do this:

sudo su -
gcloud auth activate-service-account --key-file=/etc/gitlab-runner/your-key.json
gcloud auth configure-docker asia-southeast1-docker.pkg.dev

This writes credentials to /root/.docker/config.json, where the runner (running as root) can access them.

In shot, Runner and Auth User Must Match

GitLab Runner uses the Docker config of the user it runs as. So you must activate the service account and run gcloud auth configure-docker as that same user.

Otherwise, your CI jobs will fail to pull private images — even though your manual tests "worked fine" under a different user.

GAR Cloud on GCP VM

Booranasak Kanthong — Tue, 22 Jul 2025 11:14:22 +0000

summary of the commands and steps I executed - until I have successfully pulled Docker images from Google Artifact Registry (GAR):

Final Outcome

You successfully pulled:

asia-southeast1-docker.pkg.dev/escian/todoapp/hello-app:1.0
asia-southeast1-docker.pkg.dev/escian/booranasak-artifact-registry-docker/fastapi-app:v1

📜 Step-by-Step Command Summary

🔸 1. Initial Setup Attempts

Tried interactive login (but canceled):

  gcloud auth login
  gcloud init

🔸 2. Created and Prepared Service Account

Saved service account credentials to escian-bb074f590610.json
Confirmed it’s the correct service account for GAR access:

  "client_email": "escian-devops-artifact@escian.iam.gserviceaccount.com"

🔸 3. Activated the Service Account

gcloud auth activate-service-account --key-file=escian-bb074f590610.json

✅ This set the service account as the active credential.

🔸 4. Set GCP Project (Partial Success)

gcloud config set project escian

⚠️ Warned that Cloud Resource Manager API was disabled (can ignore for image pull).

🔸 5. Configured Docker to Authenticate with GAR

gcloud auth configure-docker asia-southeast1-docker.pkg.dev --quiet

✅ This added the necessary section to ~/.docker/config.json:

{
  "credHelpers": {
    "asia-southeast1-docker.pkg.dev": "gcloud"
  }
}

🔸 6. Verified Docker Credential Helper

docker-credential-gcloud list

🟡 Note: asia-southeast1-docker.pkg.dev is NOT shown here – but that's expected because docker-credential-gcloud doesn’t show Artifact Registry entries.

🔸 7. First Pull Attempts (Failed)

You ran:

docker pull asia-southeast1-docker.pkg.dev/escian/booranasak-artifact-registry-docker/fastapi-app:v1

❌ Failed with: Unauthenticated request — this was before proper configuration.

🔸 8. Final Successful Pulls

Once everything was configured:

docker pull asia-southeast1-docker.pkg.dev/escian/todoapp/hello-app:1.0
docker pull asia-southeast1-docker.pkg.dev/escian/booranasak-artifact-registry-docker/fastapi-app:v1

✅ Both images pulled successfully!

🧠 Lessons Learned / Tips

gcloud auth configure-docker + gcloud auth activate-service-account is enough if the service account has permission.
No need for docker login manually if Docker reads from ~/.docker/config.json via credHelpers.
docker-credential-gcloud list doesn’t reflect Artifact Registry — don't rely on it for GAR validation.
If all fails, use:

  gcloud auth print-access-token | docker login -u oauth2accesstoken --password-stdin https://asia-southeast1-docker.pkg.dev

Forem: Booranasak Kanthong

Kong Cluster

🚦 Kong Cluster 101 (Beginner-friendly)

What is a “Kong Cluster”?

Why put a Load Balancer in front of Kong?

🧩 Use your docker-compose.yml (what you already have)

1) HAProxy: load-balance Kong nodes (your config)

2) Full docker-compose.yml (merged + test apps)

3) Configure Kong (via Admin API) for upstream failover

3.1 Upstream with health checks

3.2 Register the two targets

3.3 Create a Service using the upstream

3.4 Expose it with a Route

Set up Connection in Konga (UI)

✅ How to PROVE failover works (two ways)

A) Gateway node failover (HAProxy removes bad Kong)

B) Upstream target failover (Kong removes bad target)

Now both httpbin1 and httpbin2 were healthy, so the load could be distributed across both instances again.

🧭 Troubleshooting quick hits

🧠 What you just built (recap)

Building, Securing, and Deploying a Go App with GitLab CI/CD: README.md

2. List All Accounts

3. Create a New Account

4. Get Single Account

5. Deposit into Account

6. Withdraw from Account

Mock Data

Getting Started

Running the Server

Running Tests & Coverage

License

Building, Securing, and Deploying a Go App with GitLab CI/CD EP 5.2: Docker Hub Image Scanning with Trivy in GitLab CI/CD

Introduction

1. What is Trivy and Why Scan Your Images?

2. How Trivy Fits in Your Pipeline

3. Adding Trivy to Your .gitlab-ci.yml

4. Merge scripts together

5. Viewing and Understanding Your Trivy Scan Results

Output logs(this from other pipeline)

6. What If I Find Vulnerabilities?

7. Tips and Best Practices

8. What’s Next?

Summary

Building, Securing, and Deploying a Go App with GitLab CI/CD EP 4.2: Build and Push Docker Image to Docker Hub

Introduction

1. What is a Docker Image and Why Use a Registry?

Docker Image to Registry Flow

2. Setting Up Docker Hub

A. Create a Docker Hub Repository

3. Building Your Docker Image in GitLab CI/CD

4. Authenticating GitLab CI/CD with Docker Hub

A. Add Docker Hub Credentials to GitLab

* DOCKER_PASSWORD: your Docker Hub password or personal access token

5. Pushing the Image to Docker Hub

6. Merge Scripts Together

7. Checking Your Image in Docker Hub

Test Pulling Your Image (Optional)

8. Troubleshooting Tips

9. What’s Next?

Summary

Building, Securing, and Deploying a Go App with GitLab CI/CD EP 6: Deploy and Scan Your Go API with OWASP ZAP in GitLab CI/CD

Introduction

1. Automated Deployment from GitLab CI/CD

Why Use SSH Keys?

Example Deployment Job

If you use Docker

2. Health Checking Your API Before Scanning

Sample Health Check Script

3. API Security Scanning with OWASP ZAP

What is OWASP ZAP?

Why Use It in CI/CD?

Add ZAP to Your Pipeline

4. Reading & Acting on ZAP Reports

What to Look For

Alert Detail

5. (Optional) Stopping Your App

6. Merge scripts together

7. Wrap Up and What’s Next

Building, Securing, and Deploying a Go App with GitLab CI/CD EP 5.1: Container Image Scanning(GAR) with Trivy in GitLab CI/CD

Introduction

🧩 Use your `docker-compose.yml` (what you already have)

2) Full `docker-compose.yml` (merged + test apps)

* `DOCKER_PASSWORD`: your Docker Hub password or personal access token

5. Your First `.gitlab-ci.yml` File