Aplikasi catatan yang selama ini dijalankan pada mesin kerja sendiri dapat dipindahkan ke platform awan dengan bekal yang sudah ada, yaitu image yang tersimpan di registry, gudang penyimpanan dan pendistribusian image. Topik ini menyingkat pola migrasi yang dipakai hampir semua platform container, mengelompokkan jenis platform yang tersedia, dan merangkum pertimbangan pemilihannya. Pembahasan sengaja berhenti pada tingkat peta, karena keputusan final menuntut perbandingan harga dan kebutuhan yang berbeda pada setiap organisasi.
Satu pola migrasi yang sama#
Semua platform container mengikuti pola yang sama, yaitu image diunggah ke registry, kemudian platform menarik image itu dan menjalankannya. Pembangunan image tetap terjadi di sisi pembangun, misalnya pada mesin lokal atau pipeline CI, alur kerja otomatis yang membangun dan menguji aplikasi, karena platform umumnya tidak menjalankan Dockerfile. Registry menjadi titik tukar tunggal, dan image yang sudah ada di sana langsung memenuhi syarat masuk ke platform mana pun.
# tidak-dijalankan: daemon Docker tidak tersedia di sandbox
# image yang sudah diunggah menjadi bahan migrasi ke platform mana pun
docker push budi/catatan:1.0.0Setelah image berada di registry, perbedaan antar platform hanya menyentuh siapa yang mengawasi container, seberapa besar kendali yang diberikan, dan berapa biayanya. Tidak ada penulisan ulang aplikasi dan tidak ada konversi format, karena manifest image, yaitu deskripsi image berformat JSON, sama untuk platform awan dan Docker lokal. Pola inilah yang membuat migrasi dari Docker lokal menjadi urusan memilih layanan, bukan membangun ulang aplikasi. Tim kecil pun dapat berpindah kategori seiring perubahan kebutuhan, karena pola yang sama berlaku pada semua kategori.
Empat kategori platform#
| Kategori | Bentuk layanan | Cocok untuk |
|---|---|---|
| Container instance | satu container atau tugas dijalankan tanpa kelola server | aplikasi kecil dan tugas terjadwal |
| Layanan berbasis image sederhana | image ditarik dari registry pada setiap commit baru dan dijalankan | aplikasi web yang cukup dilayani URL dan penskalaan otomatis |
| Kubernetes terkelola | cluster Kubernetes penuh dengan operasi yang diringankan penyedia | tim yang membutuhkan kendali penuh atas penjadwalan |
| Serverless container | container dijalankan per permintaan dan dibayar per eksekusi | beban tidak menentu atau yang jarang dipakai |
Container instance adalah bentuk yang paling dekat dengan docker run, tetapi mesin di belakangnya tidak pernah dilihat. Layanan berbasis image sederhana menambahkan satu siklus pada pola itu, yaitu setiap commit yang lolos memicu penarikan image baru. Keduanya paling cocok untuk aplikasi catatan berukuran kecil yang kebutuhannya sederhana. Kubernetes terkelola menyediakan cluster penuh sebagaimana dipetakan pada modul ini, dengan control plane yang diurus oleh penyedia sehingga operasinya lebih ringan daripada memasang sendiri.
Kategori serverless container, pembayaran per eksekusi dengan skala yang bisa turun ke nol, menutup daftar sebagai pilihan untuk beban yang jarang dipakai. Penyedia awan besar menyediakan kategori Kubernetes terkelola dengan nama dagang masing-masing, misalnya EKS pada AWS, GKE pada Google Cloud, dan AKS pada Azure, sementara kategori lainnya juga tersedia di hampir semua penyedia. Daftar ini bukan peringkat, melainkan peta pilihan yang masing-masing memuat kelebihan dan kekurangannya.
Pertimbangan pemilihan#
Tiga pertimbangan paling sering menentukan, yaitu kendali, biaya, dan keterikatan vendor. Semakin terkelola sebuah platform, semakin sedikit yang harus dijaga, tetapi semakin sedikit pula yang dapat diatur, sehingga kendali dan keringanan operasi bergerak berlawanan arah. Biaya mengikuti pola yang berbeda-beda, mulai dari server yang dibayar tetap selama berjalan sampai pembayaran per eksekusi yang murah untuk beban jarang namun mahal untuk beban tetap tinggi.
Vendor lock-in, ketergantungan pada layanan khusus milik satu penyedia, menutup daftar pertimbangan. Pengaturan yang ditulis dalam bentuk khusus satu platform perlu ditulis ulang saat pindah, sedangkan image berstandar OCI beserta definisi aplikasi dalam compose.yaml atau manifest Kubernetes tetap terbawa. Karena itu, pencegahannya sederhana, yaitu menahan diri untuk tidak meletakkan logika aplikasi di dalam fitur eksklusif platform.
Gerbang menuju Kubernetes#
Jalur Docker ini berakhir tepat di depan pintu Kubernetes. Konsep yang terkumpul sepanjang jalurnya, mulai dari image dan layer, registry, jaringan kustom, data persisten, Compose, hingga peta orkestrasi pada modul ini, adalah bekal langsung untuk membaca dokumentasi Kubernetes. Istilah yang ditemui di sana bukan bahasa baru, melainkan nama baru untuk pola yang sudah dipahami, misalnya pod, deployment, dan service yang dikenali pada modul ini.
Urutan pembahasan dokumentasi Kubernetes mengalir dari bekal tersebut. Konsep deklaratif yang diperkenalkan melalui manifest deployment menjadi kunci masuknya, karena hampir semua objek Kubernetes dinyatakan dalam bentuk yang sama. Dengan bekal image berstandar OCI, kebiasaan compose.yaml, dan peta istilah ini, langkah berikutnya merupakan kelanjutan yang wajar, bukan mulai dari nol.
Ringkasan#
- Platform container mengikuti pola migrasi yang sama, yaitu image diunggah ke registry, kemudian ditarik dan dijalankan platform.
- Empat kategori platform menyeimbangkan kendali dan keringanan operasi, yaitu container instance, layanan berbasis image sederhana, Kubernetes terkelola, dan serverless container.
- Kendali, biaya, dan keterikatan vendor adalah tiga pertimbangan utama, dan bentuk standar seperti image OCI menjaga pintu perpindahan tetap terbuka.
Referensi#
- Docker overview — Docker Docs — Mengulang peran registry sebagai titik tukar image antar lingkungan.
- Concepts — Kubernetes Docs — Titik masuk dokumentasi Kubernetes yang menjadi kelanjutan alami jalur ini.