DocsAplikasi

Deploy & rollback

Apa yang terjadi saat tombol Deploy ditekan, cara membaca log, health check dan blue/green, serta kembali ke versi sebelumnya.

Pemicu: Tombol Deploy, webhook push, auto-update, Rollback
Berjalan di: Daemon Docker host (atau server remote)
Jaminan: Gagal build tidak menyentuh container lama

Alur satu deployment

01queueddeployment dibuat
02buildingclone + build image
03pushingpush ke registry
04startingcontainer baru, tunggu healthy
05successcontainer lama diganti

Setiap tahap bisa berakhir failed; deployment selalu berakhir di success atau failed, tidak pernah menggantung. Log tiap tahap mengalir ke tab Deploy secara realtime.

Deploy menolak (409) bila masih ada deployment aktif untuk aplikasi yang sama. Webhook yang datang saat itu dijawab busy dan tidak diantre.
Gagal di building atau pushing tidak menyentuh container yang sedang berjalan dan tidak mengubah status aplikasi.
Di server remote tahap pushing dilewati — image tetap di daemon server itu.

Mode deploy: container atau service

	container (default)	service (Swarm)
Yang dibuat	Satu container di host/server aplikasi	Service dengan N replika, task disebar scheduler
Pergantian versi	Blue/green atau replace	Rolling update oleh daemon (paralelisme, jeda, urutan)
Gagal	Container lama tetap melayani	Rollback otomatis ke spec sebelumnya setelah timeout
Stop / Start	Container di-stop/start	Skala ke 0 dan kembali ke jumlah replika
Metrik	Container itu	Jumlah task lokal saja

Mode service butuh Docker Swarm aktif. Mengubah mode, replika, penempatan, atau batas sumber daya dijalankan sebagai deployment config — tanpa build, dan antrean deployment yang sama tetap berlaku.

Update otomatis (aplikasi dari image)

Aplikasi yang sumbernya image (bukan repo Git) bisa memperbarui dirinya sendiri: watcher membandingkan digest manifest tag yang dipakai lewat API registry setiap 60 menit (bisa diatur per aplikasi), dan membuat deployment auto-update begitu digest berubah.

Baseline diambil dari digest yang tercatat saat pull terakhir — bukan dari tag, jadi latest pun terdeteksi.
Mendukung Docker Hub/GHCR (token flow) dan registry sendiri (basic auth lewat kredensial registry eksternal).
Tombol cek sekarang di halaman aplikasi memaksa pemeriksaan tanpa menunggu interval.

Log realtime

Log	Isi	Sumber
Log deployment	Output clone, build, push, start untuk satu deployment. Tersimpan permanen di riwayat.	Runner → Socket.IO /logs
Log container	stdout/stderr aplikasi yang sedang berjalan (follow).	docker logs --follow

Token Git dan password database yang ter-resolve disensor otomatis dari kedua log dan dari pesan error. Setiap container yang dibuat aoox memakai rotasi log (json-file dengan batas ukuran dan jumlah file), jadi log container tidak memenuhi disk.

Health check

Isi Health check path (mis. /health) di Pengaturan. Container dibuat dengan Docker HEALTHCHECK yang memanggil 127.0.0.1:<port container><path> tiap 3 detik, maksimal 30 kali (± 90 detik).

Endpoint yang cukup

GET /health → 200 OK
# tidak perlu body; yang penting status 2xx dan cepat

Prasyarat di image

Perintah health check mencoba wget → curl → node -e fetch → python3. Image yang tidak punya satu pun (mis. scratch, distroless) membuat deployment gagal dengan pesan yang menyebutkannya. Container yang kemudian menjadi unhealthy otomatis dilepas Traefik (404).

Blue/green

Aktif otomatis bila aplikasi punya domain, tanpa port host, dan bukan preview. Tujuannya: tidak ada request yang gagal selama pergantian versi.

Waktu	Container lama	Container -next	Keterangan
0 s	melayani	—	Deploy dimulai; image baru sudah di registry.
+1 s	melayani	starting	Container <app>-next dibuat dengan label Traefik yang sama.
+3–90 s	melayani	healthy	Traefik mulai merutekan ke keduanya setelah -next healthy.
+3 s	dihapus	melayani	Tunggu proxy settle, hapus yang lama.
selesai	—	→ <app>	-next di-rename ke nama asli. Deployment success.

Kondisi	Perilaku
Domain, tanpa port host, ada health check	Blue/green seperti di atas.
Ada port host	Replace biasa — dua container tidak bisa bind port yang sama. Health check tetap menentukan sukses/gagal.
Tanpa health check path	Replace biasa; deployment sukses begitu container start.
Gagal / timeout saat blue/green	-next dihapus, container lama tetap melayani, deployment failed.

Kedua container sementara memakai volume yang sama. Aplikasi yang mengunci file (mis. SQLite tanpa WAL) sebaiknya memakai port host atau tanpa health check agar replace biasa yang dipakai.

Rollback

Pilih deployment yang berstatus success
Di daftar deployment (tab Deploy), klik Rollback pada versi tujuan.
Deployment baru berjenis rollback dibuat
Tanpa build/push — image lama ditarik dari registry (atau yang masih ada di server remote) dan container diganti lewat jalur yang sama: health check, blue/green.

Rollback memakai image lama tapi env saat ini — cocok untuk memperbaiki env yang salah tanpa build ulang.
Tag image yang sudah dihapus di Registry tidak bisa jadi target rollback.

Stop & start

Tombol Stop/Start di tab Deploy menghentikan/menjalankan container tanpa build ulang. Notifikasi container-mati tidak dikirim untuk stop yang disengaja.

Perubahan apa memicu apa

Yang diubah	Efek	Perlu
Kode di repo	Image baru	Deploy (atau push + webhook)
Tag image berubah (sumber image)	Pull image baru	Otomatis bila Update otomatis aktif
Build args, Dockerfile path, cara build	Image baru	Deploy
Environment variables	Berlaku saat container dibuat	Deploy atau Rollback
Domain, mount, batas sumber daya (cabut)	Container dibuat ulang dari image saat ini	Otomatis, tanpa build
Mode deploy, replika, penempatan	Service diperbarui (rolling)	Deployment config, otomatis
Batas sumber daya (ubah nilai)	Diterapkan langsung	Tidak ada

Langkah berikutnya

Webhook auto-deployDeploy tiap push tanpa menekan tombol.Preview pull requestContainer sementara per PR.NotifikasiKabar deploy sukses/gagal ke Telegram, Slack, dll.MonitoringMetrik CPU/RAM container setelah deploy.

Ada yang keliru? Edit halaman ini di GitLab ↗

Pilih deployment yang berstatus success

Deployment baru berjenis rollback dibuat