Halo, Rekan ArtonLabs. Kali ini kami bercerita tentang bagian pekerjaan yang dulu paling kami hindari: men-deploy aplikasi ke server.
Kami cukup sering men-deploy aplikasi Django untuk klien. Sebelum memakai VinzaPanel, urutannya selalu sama: buat virtualenv, pasang dependensi, tulis unit systemd, atur reverse proxy, urus sertifikat, lalu berdoa tidak ada salah ketik di nginx.conf. Pekerjaan setengah jam yang kadang molor jadi setengah hari, biasanya karena satu hal kecil seperti garis miring yang kurang di direktif alias.
Sekarang sebagian besar langkah itu dikerjakan panel. Dan bukan hanya untuk Python. Berikut alurnya untuk masing-masing stack, ditambah beberapa pelajaran yang kami dapat di jalan.
Django, Flask, FastAPI
Urutannya begini. Anda membuat website dengan runtime Python. Kode aplikasi diambil dari Git lewat plugin Git Manager, atau diunggah lewat file manager. Lalu di halaman deploy, plugin Python Deploy meminta dua hal utama: jalur aplikasi dan modul WSGI atau ASGI-nya, misalnya config.wsgi:application. Sisanya dikerjakan panel. Dependensi dipasang dari requirements.txt ke virtualenv yang dikelola panel, aplikasi dijalankan dengan Gunicorn (atau worker Uvicorn untuk FastAPI), unit systemd ditulis dengan nama yang mengikuti domain, lalu Nginx atau Apache disambungkan sebagai reverse proxy lengkap dengan alias berkas statis dan media. Jumlah worker dan port bisa diatur dari UI. Log aplikasi dibaca dari panel juga, dan aplikasi otomatis hidup lagi setelah server di-reboot.
Aplikasi riset yang kami kelola untuk sebuah kampus dipasang persis dengan cara ini. Bagian nginx dan unit systemd-nya dibuatkan panel; yang kami siapkan sendiri hanya berkas .env aplikasinya. Kalau kode diperbarui, tombol deploy ulang memasang dependensi baru dan me-restart layanan.
Tiga pelajaran dari deploy sungguhan
Pertama, kunci versi dependensi Anda. Satu aplikasi kami pernah berperilaku aneh karena requirements.txt-nya hanya menyebut batas bawah versi, sehingga pip menarik pandas versi mayor terbaru yang mengubah satuan waktu bawaannya. Panelnya tidak salah; berkas dependensinya yang longgar. Sejak itu kami selalu memakai berkas lock dengan versi persis untuk produksi.
Kedua, perhatikan berkas apa yang ikut dikumpulkan sebagai berkas statis. Berkas cadangan bernama .bak yang tertinggal di folder static akan ikut disajikan ke publik oleh collectstatic. Periksa sebelum deploy.
Ketiga, kalau aplikasi Anda menyimpan keadaan di memori proses, jalankan satu worker saja, atau pindahkan keadaannya ke database. Dua worker Gunicorn berarti dua proses yang tidak saling tahu. Panel mengizinkan Anda mengatur jumlah worker, dan itu keputusan Anda, bukan panel.
Node.js dan Go
Node.js Deploy menjalankan npm ci dan npm run build, lalu menjaga aplikasi tetap hidup lewat systemd. WebSocket dan SSL sudah langsung siap, jadi aplikasi real-time tidak perlu konfigurasi upgrade header secara manual. Go Deploy mengurus binary Go yang sudah dikompilasi dengan alur yang sama: unggah atau tarik dari Git, tentukan binary dan port, dan panel membuatkan layanan serta proxy-nya. Enaknya, polanya seragam. Tim yang memelihara tiga bahasa tidak perlu menghafal tiga cara deploy.
Docker
Untuk aplikasi yang dikemas sebagai kontainer, Docker Manager mengelola kontainer, image, volume, jaringan, dan stack Compose dari UI. Anda bisa membuat ulang kontainer dengan konfigurasi baru, membaca lognya, dan membuka terminal ke dalam kontainer langsung dari browser. Port kontainer dipetakan ke domain Anda dengan SSL, sehingga dari luar ia tampak seperti website biasa. Untuk aplikasi yang memang dirancang berjalan di Docker, misalnya yang membawa database dan cache-nya sendiri dalam satu berkas Compose, ini jalur yang paling sedikit gesekannya.
Push, lalu selesai
Git Manager menyediakan clone, pull, dan deploy key per website. Deploy key ini kunci SSH yang dibuat panel untuk satu repositori, jadi Anda tidak perlu menaruh kunci pribadi di server. Dengan webhook push-to-deploy, setiap git push ke cabang produksi memicu pembaruan di server. Biasanya ini perlu layanan CI terpisah; di sini cukup dari panel. Satu saran: pasang webhook hanya untuk cabang yang memang Anda anggap siap produksi, dan biarkan cabang pengembangan tidak tersambung.
Semua di satu server, tanpa saling ganggu
Django, Node.js, Go, dan PHP bisa hidup berdampingan, masing-masing dengan pengguna sistem sendiri. Satu file manager menelusuri berkas semuanya dengan kepemilikan dan izin yang terlihat jelas. Aplikasi yang sedang tidak dipakai bisa dinonaktifkan tanpa dihapus; layanannya berhenti, datanya tetap utuh, dan ia bisa dihidupkan lagi kapan saja. Kalau sebuah website dihapus, panel menghentikan dan membersihkan layanan systemd-nya lebih dulu sebelum menyentuh apa pun yang lain, jadi tidak ada proses yatim yang terus berjalan untuk situs yang sudah tidak ada.
Yang sering ditanyakan
Apakah saya tetap bisa masuk lewat SSH dan mengubah sesuatu sendiri? Bisa. Panel menulis unit systemd dan konfigurasi proxy, tetapi tidak melarang Anda menyuntingnya. Hanya saja, suntingan pada berkas yang dikelola panel bisa tertimpa saat deploy ulang; untuk perubahan permanen, pakai berkas tambahan per situs atau drop-in systemd.
Bagaimana dengan variabel lingkungan? Praktik kami: berkas .env di folder aplikasi dengan izin yang ketat, dimuat oleh aplikasi itu sendiri. Jangan menaruh rahasia di dalam kode yang masuk ke Git.
Apakah migrasi database dijalankan otomatis? Tidak secara bawaan, dan menurut kami itu keputusan yang tepat. Migrasi mengubah data; lebih baik dijalankan dengan sadar dari terminal web setelah Anda membaca apa yang akan diubahnya.
Alur yang kami pakai saat memperbarui aplikasi
Tarik kode terbaru lewat Git Manager atau biarkan webhook yang melakukannya. Deploy ulang dari panel supaya dependensi baru terpasang. Buka terminal web, jalankan migrasi database dan collectstatic sebagai pengguna situs. Baca log aplikasi dari panel selama beberapa menit pertama. Kalau ada yang tidak beres, git checkout ke commit sebelumnya dan deploy ulang; seluruh urutan ini memakan waktu kurang dari lima menit dan tidak menyentuh konfigurasi server sama sekali. Untuk aplikasi yang penting, lakukan dulu di alamat pratinjau atau di node uji sebelum ke produksi.
Kalau Anda selama ini menghindari VPS karena takut mengurus nginx dan systemd, ini saat yang baik untuk mencoba lagi. Alur deploy-nya dijelaskan di vinzapanel.com, dan paket Free sudah cukup untuk aplikasi pertama Anda. Deploy Python dan Node.js tersedia mulai paket Starter.
Sampai jumpa di artikel berikutnya, Rekan ArtonLabs. Cerita deploy Anda sendiri, yang lancar maupun yang tidak, selalu kami tunggu.
