Pipeline CI/CD untuk Aplikasi Container
Alur rilis otomatis dari push ke repository sampai aplikasi berjalan di server: test, build image Docker, publikasi ke registry, lalu deploy dengan health check dan jalur rollback.
- Peran
- Perancang dan pelaksana seluruh pipeline (proyek pribadi).
- Teknologi
- GitHub Actions
- Docker
- Docker Compose
- GHCR
- Nginx
- Bash
Konten contoh. Studi kasus ini adalah contoh format dari template. Ganti dengan detail proyek Anda yang sebenarnya, atau hapus sebelum dipublikasikan.
Konteks
Lab ini mensimulasikan aplikasi web kecil yang di-deploy ke satu VPS. Kondisi awalnya umum ditemui: deployment dilakukan manual lewat SSH, langkahnya hanya ada di ingatan, dan tidak ada cara cepat untuk kembali ke versi sebelumnya.
Masalah dan tujuan
Deployment manual rawan terlewat langkah, sulit diaudit, dan membuat rilis terasa berisiko sehingga cenderung ditunda.
- Setiap perubahan di branch utama diuji dan dibangun secara otomatis.
- Artefak rilis bersifat immutable dan dapat dilacak ke commit tertentu.
- Rollback dapat dilakukan tanpa membangun ulang aplikasi.
Batas pekerjaan
Termasuk
- Workflow CI untuk pull request dan branch utama.
- Dockerfile multi-stage dan konfigurasi Docker Compose.
- Skrip deploy, health check, dan prosedur rollback.
- Dokumentasi runbook singkat.
Di luar lingkup
- Orkestrasi multi-server atau Kubernetes.
- Pengelolaan database produksi dan migrasi skema.
Peran saya
Perancang dan pelaksana seluruh pipeline (proyek pribadi).
- Menyusun workflow CI untuk test dan build pada setiap pull request.
- Membuat Dockerfile multi-stage agar image produksi tetap ringkas.
- Menulis skrip deploy dengan health check dan rollback berbasis tag image.
Solusi
Pull request menjalankan lint dan test. Merge ke main memicu build image yang diberi tag SHA commit, lalu dipublikasikan ke GitHub Container Registry.
Job deploy terhubung ke server melalui SSH dengan kunci khusus deploy, menarik image bertag tersebut, dan menjalankan ulang service melalui Docker Compose.
Skrip health check memanggil endpoint aplikasi beberapa kali. Bila gagal, skrip mengembalikan tag image sebelumnya dan menandai job sebagai gagal.
Alasan keputusan teknis
Docker Compose, bukan Kubernetes
Untuk satu server dan satu aplikasi, Compose cukup dan jauh lebih sederhana dioperasikan. Kubernetes baru masuk akal ketika kebutuhan scaling dan jumlah service bertambah.
Tag image berdasarkan SHA commit
Tag seperti latest tidak menunjukkan versi yang sedang berjalan. Tag SHA membuat rollback dan penelusuran perubahan menjadi jelas.
Health check sebagai gerbang akhir
Container yang berjalan belum tentu aplikasinya sehat. Pemeriksaan endpoint memastikan rilis benar-benar melayani request.
Arsitektur dan alur implementasi
- 01git pushbranch main
- 02CIlint · test · build
- 03Registryimage bertag commit
- 04Deploycompose pull & up
- 05Health checkrollback bila gagal
Hasil
Rilis dapat diulang
Langkah deployment terdokumentasi sebagai kode di repository, sehingga setiap rilis menjalankan urutan yang sama.
Jalur rollback teruji
Prosedur rollback diuji di lab dengan sengaja merilis versi yang gagal health check.
Pelajaran yang diperoleh
- Rahasia deploy sebaiknya dibatasi per environment dan memakai kunci dengan hak akses minimum.
- Health check yang terlalu sederhana dapat memberikan rasa aman palsu; periksa dependensi penting aplikasi.