Raklane faviconRaklane
MasukMulai deploy

Men-deploy Aplikasi

Menghubungkan repo Git atau arsip, memicu deploy, replica, batas resource, rolling deploy, dan rollback.

Halaman ini membahas semua hal yang terlibat dalam menjalankan kode Anda di Raklane, dari deploy pertama dan seterusnya.

Memilih source

Setiap App mengambil kodenya dari tepat satu tempat pada satu waktu, yang dikonfigurasi di tab Source milik App:

  • Repositori Git — URL repositori dan ref (branch, tag, atau commit) yang akan di-build. Mendukung URL GitHub, GitLab, dan Bitbucket. Repo publik tidak butuh apa-apa lagi; repo privat butuh access token — lihat Secret → Repositori privat.
  • Unggah arsip — tidak punya repo Git? Kompres project Anda menjadi zip atau tar dan unggah langsung.

Mengubah source (branch baru, repo lain, arsip baru) tidak men-deploy ulang apa pun dengan sendirinya — hanya mengubah apa yang akan di-build pada deploy berikutnya.

Memilih tempat aplikasi berjalan

Setiap App berjalan di PAYG cluster, Dedicated cluster, atau server BYOC milik Anda. Anda memilihnya saat membuat App, dan bisa mengubahnya dari Settings → Deployment location — lihat Tempat Aplikasi Berjalan. Setiap deploy menuju lokasi App saat ini.

Memicu deploy

Klik Deploy di dashboard App. Ini akan:

  1. Mencatat Release baru dan langsung kembali — deploy bersifat asinkron, jadi dashboard menampilkan perubahan status Release dari waktu ke waktu alih-alih membuat Anda menunggu.
  2. Mem-build container image dari source saat ini (lewat Cloud Native Buildpacks — tidak perlu Dockerfile untuk sebagian besar bahasa/framework umum).
  3. Menyalakan replica container baru dari image tersebut dan menunggu sampai lolos health check.
  4. Setelah semua replica baru sehat, trafik dipindahkan ke sana.

Pantau prosesnya di halaman Status App — lihat Log & Status.

Jika Anda mengklik Deploy lagi saat deploy masih berjalan, tidak akan ada antrean deploy kedua — klik itu digabungkan ke release yang sedang di-build/diperiksa kesehatannya.

Tanpa downtime secara bawaan

Deploy tidak menghentikan aplikasi yang sedang berjalan lebih dulu. Replica baru menyala dan diperiksa kesehatannya berdampingan dengan yang lama, yang tetap melayani trafik sepanjang waktu. Trafik baru dipindahkan setelah setiap replica baru dipastikan sehat — jadi deploy yang buruk tidak pernah membuat aplikasi Anda offline. Jika replica baru gagal health check, deploy dibatalkan sebelum perpindahan: release lama tetap berjalan tanpa tersentuh, dan Release baru ditandai failed.

Bake window sebagai jaring pengaman

Bahkan setelah trafik dipindahkan, Raklane tetap menyalakan Release sebelumnya selama rentang singkat alih-alih langsung menghentikannya (status Release baru akan terlihat baking selama waktu ini). Jika terjadi masalah yang tidak tertangkap oleh health check awal, Raklane otomatis rollback ke Release sebelumnya tanpa tindakan apa pun dari Anda — Release yang gagal ditandai rolled_back. Jika tidak ada masalah, rentang waktu itu berakhir sendiri, Release berubah menjadi active, dan yang lama akhirnya dihentikan.

Jika Anda ingin memaksa rollback itu segera tanpa menunggu rentang waktunya habis, batalkan deploy (lihat di bawah).

Membatalkan deploy

Selama deploy masih dalam tahap build atau menunggu health check, Anda bisa membatalkannya — ini benar-benar menghentikan proses build/health check yang sedang berjalan, bukan sekadar menyembunyikannya di dashboard, dan membiarkan apa pun yang berjalan sebelumnya tetap utuh.

Jika Anda membatalkan selama bake window di atas, itu akan memaksa rollback langsung ke Release sebelumnya tanpa menunggu rentang waktunya habis.

Replica

Secara bawaan, App berjalan dengan satu replica (satu instance container). Untuk menjalankan lebih banyak — demi redundansi atau menangani trafik lebih besar — atur jumlah replica saat deploy. Jika Anda tidak mengaturnya saat deploy ulang, Raklane mempertahankan jumlah yang dipakai Release sebelumnya.

Batas resource

Anda bisa mengatur request dan limit CPU, memori, dan storage per replica:

  • Request adalah yang dicadangkan Raklane untuk aplikasi Anda saat memutuskan apakah deploy muat di compute yang tersedia. Jika tidak diatur, nilai bawaan sistem yang kecil akan dipakai.
  • Limit adalah batas atas yang tegas: penggunaan CPU di atasnya akan di-throttle, penggunaan memori di atasnya membuat container dihentikan (out-of-memory), dan storage dibatasi oleh container runtime. Biarkan kosong jika tidak ingin ada batas.

Tidak yakin harus mengisi berapa? Deploy dengan limit yang longgar, lalu lihat tab Metrics aplikasi: tab itu menampilkan penggunaan nyata dibandingkan limit Anda dan menyarankan kapan perlu menaikkan atau menurunkan ukuran.

Jika request melebihi yang tersedia saat ini, deploy ditolak sejak awal (bahkan sebelum build dimulai) alih-alih dibiarkan gagal di tengah jalan. Di compute terkelola Raklane, Raklane bisa saja menyalakan server tambahan untuk Anda — deploy kemudian menampilkan waiting_for_server sampai server siap. Di server BYOC, kapasitasnya adalah apa pun yang dimiliki server Anda.

Mengubah replica atau resource tanpa deploy ulang

Anda tidak perlu memicu deploy penuh hanya untuk menaikkan skala atau mengubah ukuran aplikasi — dari halaman Resources App, Anda bisa langsung mengubah jumlah replica dan/atau CPU/memori. Raklane menerapkannya di latar belakang (biasanya dalam hitungan detik) tanpa mem-build apa pun atau me-restart container yang sedang berjalan: menambah replica hanya menyalakan yang kurang, mengurangi hanya menghentikan kelebihan yang paling baru, dan perubahan resource saja memperbarui setiap replica yang dipertahankan di tempat. Mengubah limit storage adalah satu-satunya pengecualian — selalu memerlukan penggantian replica, karena tidak bisa diubah pada container yang sedang berjalan.

Health check

Raklane memastikan replica baru benar-benar siap sebelum memindahkan trafik. Secara bawaan ini berupa pemeriksaan HTTP ke port aplikasi, dengan jeda singkat sebelum pemeriksaan pertama dan batas waktu untuk setiap percobaan — Anda bisa menggantinya ke pemeriksaan TCP biasa jika aplikasi tidak menyediakan endpoint HTTP, atau menyesuaikan batas waktu dan jeda awal jika aplikasi butuh waktu lebih lama untuk menyala.

Deploy ulang

Deploy lagi — setelah perubahan kode, perubahan konfigurasi, atau sekadar restart — bekerja dengan cara yang sama persis: klik Deploy. Raklane mem-build ulang dari source yang sedang dikonfigurasi dan merilis Release baru dengan proses tanpa downtime yang sama seperti di atas.

Situs statis

Jika tipe App Anda Static (dipilih saat dibuat dan tidak bisa diubah setelahnya), deploy melewati langkah build sepenuhnya — direktori source Anda disajikan apa adanya. Pengaturan port container dan health check tidak berlaku; situs statis selalu disajikan dengan cara yang sama.

Lihat juga