Zero-Downtime Deployment Pipeline for Rust API: GitHub Actions, Docker Multi-Stage Builds, and Supervisor Daemon

Pukul 2 pagi di ruang server kantor, napas saya tertahan melihat grafik latensi melonjak tajam setelah command systemctl restart rust-api dieksekusi. Ada jeda 3 detik di mana API mengembalikan HTTP 502 Bad Gateway karena binary baru belum siap menerima koneksi, sementara ribuan client mobile masih menghantam reverse proxy Nginx. Saat itu, saya sadar bahwa mendeploy aplikasi berbasis compiled language seperti Rust membutuhkan pendekatan yang jauh lebih elegan ketimbang sekadar melempar binary baru ke atas VPS production. Pengalaman bertahun-tahun mengelola infrastruktur web mengajarkan kita satu hal mutlak: downtime sekecil apa pun adalah racun bagi bisnis.

Mari kita bedah secara mendalam bagaimana merancang pipeline Zero-Downtime Deployment untuk Rust API, memadukan ketangguhan GitHub Actions, efisiensi Docker multi-stage builds, keandalan Supervisor daemon, serta harmoni sempurna di balik reverse proxy Nginx.

[!IMPORTANT] Zero-downtime deployment pada single-node VPS bukan sekadar trik estetik, melainkan standar ketahanan sistem agar ketersediaan layanan mencapai angka 99.99% tanpa harus langsung melompat kompleksitasnya ke Kubernetes.

Berikut adalah matriks perbandingan performa dan efisiensi antara pendekatan deployment manual tradisional (Shell Script Langsung) melawan pendekatan modern otomatis (Docker Multi-Stage + Supervisor).

1. Pertarungan Filosofi: Dua Cara Pandang Berbeda dalam Memecahkan Masalah

Ketika berbicara tentang deployment backend berkecepatan tinggi, perdebatan abadi selalu muncul antara kubu yang mengandalkan eksekusi langsung binary di metal/VM dengan kubu kontainerisasi modern. Di satu sisi, menjalankan Rust binary secara langsung di bawah kontrol Supervisor daemon memberikan performa I/O nyaris tanpa overhead virtualisasi sama sekali. Di sisi lain, membungkusnya dalam Docker multi-stage build memastikan bahwa lingkungan build yang gemuk (berisi cargo, rustc, dan crates cache raksasa) tidak pernah mencemari lingkungan production yang bersih.

Masalah utamanya, bagaimana kita melakukan hot swapping atau rolling update pada single VPS tanpa memutus koneksi aktif yang sedang dilayani oleh axact atau actix-web? Jawabannya terletak pada orkestrasi yang cerdas antara GitHub Actions sebagai otak otomatisasi, Docker sebagai pengaman konsistensi runtime, dan Supervisor sebagai pengawas proses abadi yang memastikan aplikasi tidak pernah benar-benar mati sebelum penggantinya siap.

2. Ronde 1: Ergonomi Menulis Kode & Pengalaman Konfigurasi Sehari-hari

Langkah pertama yang paling krusial dalam membangun pipeline ini adalah memastikan ukuran image Docker sekecil mungkin. Rust terkenal dengan ukuran binary-nya yang membengkak jika tidak di-strip secara agresif. Kita menggunakan strategi multi-stage build: tahap pertama bertindak sebagai dapur pacu compiliation yang berat, sementara tahap kedua hanya mengambil hasil kompilasi binary final dan menempelkannya di atas base image Alpine Linux yang sangat ringan.

Berikut adalah implementasi Dockerfile multi-stage yang telah diuji di medan perang production untuk menekan ukuran image hingga di bawah 30 Megabytes:

# --- Stage 1: Build Stage --- 
FROM rust:1.75-alpine AS builder

# Install build dependencies yang dibutuhkan crates tertentu
RUN apk add --no-cache musl-dev pkgconfig openssl-dev

WORKDIR /app

# Salin file manifest terlebih dahulu untuk caching dependencies
COPY Cargo.toml Cargo.lock./

# Dummy build untuk cache dependencies (biar nggak download ulang saat kode berubah)
RUN mkdir src && echo "fn main() {}" > src/main.rs
RUN cargo build --release
RUN rm -rf src

# Salin source code asli
COPY src./src

# Kompilasi aplikasi Rust production-ready
RUN cargo build --release --locked

# --- Stage 2: Runtime Stage ---
FROM alpine:3.19

RUN apk add --no-cache ca-certificates libgcc libssl3

WORKDIR /app

# Salin binary hasil kompilasi dari builder stage
COPY --from=builder /app/target/release/rust-api /app/rust-api

# Berikan hak akses eksekusi
RUN chmod +x /app/rust-api

# Ekspose port aplikasi internal
EXPOSE 8080

CMD ["/app/rust-api"]

[!TIP] Pastikan Anda selalu menggunakan flag --locked saat menjalankan cargo build --release di dalam Docker untuk menjamin versi crates yang dikompilasi persis sama dengan Cargo.lock di repository Git Anda.

3. Ronde 2: Uji Ketahanan di Bawah Gempuran Beban Ekstrem

Setelah image siap, tantangan berikutnya adalah bagaimana GitHub Actions mengeksekusi deployment ke VPS via SSH secara otomatis setiap kali ada git push ke branch main. Kita tidak ingin proses build membebani RAM VPS production, oleh karena itu GitHub Actions Runner bertindak sebagai pabrik pengolahan, sementara VPS hanya bertindak sebagai gudang penerima barang.

Berikut adalah file konfigurasi GitHub Actions workflow .github/workflows/deploy.yml yang menangani proses build, push image ke container registry (atau langsung transfer binary), dan trigger update di server:

name: Production CI/CD Pipeline

on:
  push:
    branches: [ "main" ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Code
        uses: actions/checkout@v4

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3

      - name: Login to Docker Hub
        uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_PASSWORD }}

      - name: Build and Push Docker Image
        uses: docker/build-push-action@v5
        with:
          context:.
          push: true
          tags: ${{ secrets.DOCKER_USERNAME }}/rust-api:latest
          cache-from: type=gha
          cache-to: type=gha,mode=max

      - name: Deploy to Production VPS via SSH
        uses: appleboy/ssh-action@v1.0.3
        with:
          host: ${{ secrets.VPS_HOST }}
          username: ${{ secrets.VPS_USER }}
          key: ${{ secrets.VPS_SSH_KEY }}
          script: |
            docker pull ${{ secrets.DOCKER_USERNAME }}/rust-api:latest
            sudo supervisorctl restart rust-api

4. Ronde 3: Konsumsi Sumber Daya Server & Efisiensi Biaya Nyata

Di sinilah Supervisor Daemon mengambil peran vital. Supervisor adalah pengawas proses sistem operasi berbasis Python yang memastikan program berjalan terus-menerus. Jika container atau binary mengalami crash karena kehabisan memori atau segmentation fault, Supervisor akan otomatis membangunkannya dalam hitungan milidetik.

Agar Supervisor dapat mengelola proses Docker atau binary Rust dengan mulus, kita membuat file konfigurasi di /etc/supervisor/conf.d/rust-api.conf:

[program:rust-api]
command=docker run --rm --name rust-api-container -p 127.0.0.1:8080:8080 mydockeruser/rust-api:latest
autostart=true
autorestart=true
stderr_logfile=/var/log/rust-api.err.log
stdout_logfile=/var/log/rust-api.out.log
user=root
environment=RUST_LOG="info",DATABASE_URL="postgres://user:pass@localhost/db"

Ketika perintah sudo supervisorctl restart rust-api dipicu oleh GitHub Actions, Supervisor akan dengan bersih menghentikan container lama dan memutar container baru. Namun, untuk benar-benar mencapai Zero-Downtime sejati tanpa jeda 502, kita perlu memadukannya dengan Nginx Reverse Proxy yang dikonfigurasi dengan proxy_next_upstream dan parameter timeout yang tepat.

Berikut adalah konfigurasi Nginx di /etc/nginx/sites-available/rust-api:

upstream rust_backend {
    server 127.0.0.1:8080;
    # Cadangan upstream atau jeda koneksi aktif jika diperlukan
    keepalive 32;
}

server {
    listen 80;
    server_name api.domain.com;

    location / {
        proxy_pass http://rust_backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Mencegah error 502/504 saat restart kilat
        proxy_next_upstream error timeout invalid_header http_502 http_503 http_504;
        proxy_connect_timeout 5s;
        proxy_read_timeout 60s;
    }
}

[!WARNING] Jangan pernah mengarahkan Nginx langsung ke port publik tanpa membatasi binding IP ke 127.0.0.1 (localhost). Ini untuk mencegah akses langsung dari luar tanpa melalui firewall dan reverse proxy SSL Anda.

5. Kapan Wajib Menggunakan Docker Multi-Stage dengan GitHub Actions

Arsitektur ini wajib Anda pilih jika tim Anda bekerja dalam lingkungan multi-developer dengan sistem operasi lokal yang beragam (macOS, Windows, Linux). Dengan menyerahkan urusan kompilasi Rust yang berat ke GitHub Actions Runner berspesifikasi tinggi, laptop developer Anda tidak akan kepanasan, dan konsistensi dependensi production dijamin 100% identik melalui container Alpine Linux.

6. Kapan Wajib Menggunakan Supervisor Daemon Standalone

Pendekatan murni Supervisor daemon tanpa Docker (menjalankan binary terkompilasi langsung di metal VPS) sangat ideal jika Anda mengelola VPS dengan sumber daya RAM sangat terbatas (misalnya VPS 512MB RAM di mana overhead mesin virtual Docker terasa boros). Supervisor memberikan kontrol tingkat rendah yang sangat responsif terhadap system signals (SIGTERM, SIGINT).

7. Keputusan Akhir: Rekomendasi Jujur untuk Tim Engineering

Memilih antara kesederhanaan eksekusi langsung atau ketahanan kontainerisasi adalah seni menyeimbangkan sumber daya dan kecepatan iterasi. Kombinasi GitHub Actions, Docker multi-stage, Supervisor, dan Nginx yang kita bahas hari ini adalah 'sweet spot' paling realistis untuk skala single-node VPS. Sistem ini teruji tahan banting, mudah diaudit, dan yang paling penting: membuat tidur Anda nyenyak tanpa kejutan notifikasi error 502 di tengah malam.