Registry & Image Produksi
yang Aman

Tag yang jelas supaya deploy terlacak dan rollback mudah

Image yang sudah dibangun tidak ada gunanya kalau tidak bisa kamu temukan lagi dengan pasti versi mana yang sedang berjalan di production.

Tag adalah alamat manusiawi untuk sebuah image. Tanpa disiplin penamaan, kamu akan terjebak pertanyaan klasik saat insiden: “yang lagi jalan di production itu build yang mana?” Jawaban yang baik bukan “yang terbaru”, tapi sebuah identitas yang bisa ditelusuri sampai ke commit Git tertentu. Registry adalah tempat image itu disimpan dan dibagikan, persis seperti registry npm menyimpan paket, hanya saja yang kita simpan adalah artefak runtime yang sudah jadi, bukan sumber.

Jebakan tag latest

latest hanyalah label biasa yang menunjuk ke image terakhir yang kamu tag dengan nama itu. Ia tidak berarti “versi paling baru” secara semantik dan tidak deterministik: dua server yang menjalankan docker pull skincare-api:latest pada waktu berbeda bisa mendapat biner yang berbeda. Saat terjadi bug, kamu kehilangan kemampuan rollback karena tidak tahu versi sebelumnya bernama apa.

Tiga lapis penamaan

Praktik yang sehat: satu image fisik diberi beberapa tag sekaligus saat build, sehingga satu artefak bisa dirujuk lewat versi semver yang ramah manusia maupun SHA yang presisi.

TerminalSalin
# satu build, beberapa tag menunjuk image fisik yang sama
docker build \
  -t skincare-api:dev \
  -t skincare-api:$(git rev-parse --short HEAD) \
  .

# beri ulang tag image yang sudah ada untuk tujuan registry
docker tag skincare-api:$(git rev-parse --short HEAD) \
  ghcr.io/owner/skincare-api:$(git rev-parse --short HEAD)

Registry: tempat image tinggal

Ada beberapa registry umum, semuanya bicara protokol yang sama sehingga alur login, build, tag, push, pull identik; yang berbeda hanya nama host dan cara autentikasinya.

TerminalSalin
# login ke ghcr.io (token via stdin, jangan tempel di argumen)
echo "$GHCR_TOKEN" | docker login ghcr.io -u owner --password-stdin

# push tag SHA yang sudah diberi prefix host registry
docker push ghcr.io/owner/skincare-api:$(git rev-parse --short HEAD)

# di sisi lain (CI/staging/prod) tarik versi yang sama persis
docker pull ghcr.io/owner/skincare-api:9f3a1c2

Build once, run anywhere

Inti dari registry adalah memisahkan kapan image dibangun dari kapan ia dijalankan. Image dibangun sekali di CI, lalu artefak yang sama persis ditarik oleh staging dan production. Tidak ada lagi “build ulang di server” yang berisiko menghasilkan biner berbeda karena perbedaan lingkungan.

flowchart LR
  CI["CI: docker build + push"] --> REG["Registry<br/>ghcr.io/owner/skincare-api:9f3a1c2"]
  REG --> STG["Staging<br/>docker pull :9f3a1c2"]
  REG --> PRD["Production<br/>docker pull :9f3a1c2"]

Satu artefak, banyak target. Staging dan production menarik tag SHA yang sama, sehingga apa yang diuji adalah apa yang dirilis.

Image sudah bisa dibagikan dengan identitas yang jelas. Tapi sebelum di-push ke produksi, image itu harus dikeraskan dulu.

Non-root, base minimal, dev vs prod, migration terkontrol

Image production yang baik membawa sesedikit mungkin: satu biner, tanpa shell, tanpa secret, dan berjalan sebagai user biasa.

Setiap hal yang ada di dalam image adalah permukaan serang. Shell, package manager, compiler, dan tool debug semuanya berguna saat mengembangkan, tapi di production mereka hanya menambah cara bagi penyerang untuk bergerak setelah masuk. Prinsipnya sederhana: image production harus kecil, berjalan non-root, dan tidak menyimpan kredensial di dalam layer. Banyak dari ini sudah kita capai di Chapter 2 lewat multi-stage dan distroless; di sini kita rapikan dan tegaskan jadi disiplin produksi.

Dockerfile yang diperketat

Tiga pengetatan penting: pin versi base image (jangan biarkan mengambang), pakai base runtime minimal, dan jalankan sebagai user non-root. Distroless cocok untuk biner Go statis karena hampir kosong, tidak punya shell sama sekali.

DockerfileSalin
# --- build ---
FROM golang:1.26 AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o /app ./cmd/server

# --- runtime ---
FROM gcr.io/distroless/static-debian12:nonroot
COPY --from=build /app /app
USER nonroot:nonroot
EXPOSE 8080
ENTRYPOINT ["/app"]

Dua image untuk dua dunia

Kesalahan umum adalah mengirim image development ke production. Image dev sengaja gemuk: ada hot reload, bind mount ke kode sumber, dan tool debug. Image production justru kebalikannya, sengaja kurus dan tertutup.

Memindai sebelum rilis

Jadikan pemindaian bagian dari pipeline, bukan ritual sesekali. Pindai image hasil build, dan jangan sertakan secret di dalam layer (suntikkan via environment atau secret manager saat runtime).

TerminalSalin
docker scout cves ghcr.io/owner/skincare-api:9f3a1c2
docker scout quickview ghcr.io/owner/skincare-api:9f3a1c2
trivy image ghcr.io/owner/skincare-api:9f3a1c2

Dua tool ini sering dipakai berdampingan, bukan saling menggantikan, karena cakupannya berbeda.

Mari rangkai langkah-langkahnya jadi satu alur rilis yang bisa kamu jalankan, baik lokal maupun di CI.

Migration terkontrol, bukan otomatis tiap startup

Godaan besar adalah menjalankan migrasi skema saat aplikasi boot. Itu berbahaya: bila kamu menjalankan tiga replika API, ketiganya akan berlomba menjalankan migrasi yang sama, dan satu migrasi gagal bisa menahan seluruh layanan naik. Migrasi sebaiknya menjadi langkah terpisah dan terkontrol, dijalankan satu kali sebelum API yang baru menerima trafik.

compose.yamlSalin
services:
  db:
    image: postgres:17
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 3s
      retries: 5
  migrate:
    image: migrate/migrate
    depends_on:
      db:
        condition: service_healthy
    volumes:
      - ./migrations:/m
    command: ["-path", "/m", "-database", "${DATABASE_URL}", "up"]
  api:
    build: .
    depends_on:
      migrate:
        condition: service_completed_successfully

Migrasi sebagai service one-off. Service migrate selesai dulu (exit 0), baru API naik, sehingga skema selalu siap sebelum trafik masuk.

Distribusi reproducible plus image produksi yang dikeraskan

Chapter ini membawa image dari laptop ke produksi: identitas yang terlacak lewat registry, lalu image yang dikeraskan, dipindai, dan dengan migrasi terkontrol.

Kita mulai dari tagging: latest mutable dan merusak rollback, jadi pin semver, SHA, dan referensikan digest untuk jaminan byte-identik. Registry memisahkan kapan image dibangun dari kapan dijalankan, build sekali di CI lalu artefak yang sama ditarik staging dan prod. Lalu pengerasan: image produksi kecil, non-root, dipisah dari image dev, dan dipindai dengan Docker Scout atau Trivy di pipeline, dengan disiplin “pin ke SHA” yang berlaku sampai ke action CI. Terakhir, migrasi adalah job one-off terkontrol, bukan efek samping startup.

Semua kepingan sudah di tangan: image yang baik, runtime yang terkonfigurasi, stack yang dirakit, dan distribusi yang aman. Chapter 6 menyatukannya dalam satu studi kasus skincare-api yang utuh, membongkar lima pitfall khas, lalu memetakan jalan dari image lokal ke CI/CD dan AWS.