Mengapa Orkestrasi Ada

Docker mengelola siklus hidup container pada satu mesin dengan baik, tetapi aplikasi catatan yang dipakai pengguna sungguhan jarang berhenti di situ. Topik ini membahas mengapa kebutuhan di luar docker run muncul, yaitu penempatan container di banyak mesin, pemulihan otomatis ketika sesuatu gagal, penskalaan mengikuti beban, dan pembaruan versi tanpa menghentikan layanan. Setelah membacanya, batas Docker satu mesin dapat dirinci satu per satu, dan daftar tugas yang diambil alih sebuah sistem orkestrasi dapat disebutkan dengan istilah yang tepat.

Batas Docker pada satu mesin#

Container yang dijalankan dengan docker run hidup dan mati di bawah kendali satu host, komputer tempat Docker berjalan. Kebijakan restart seperti --restart always menangani container yang berhenti sendiri, misalnya karena proses aplikasinya gagal, tetapi kebijakan itu hanya bekerja selama hostnya hidup. Apabila mesin itu mati total, tidak ada mekanisme yang memindahkan container aplikasi catatan ke mesin lain, sehingga layanan pulih hanya setelah ada orang yang menyalakan ulang mesinnya. Sementara itu, pengguna yang sedang mengetik catatan hanya melihat halaman yang tidak merespons.

Batas berikutnya muncul ketika jumlah container perlu ditambah. Satu replika, yaitu salinan container yang berjalan secara paralel, berarti satu docker run lagi dengan pemetaan port yang berbeda dan satu baris baru pada load balancer, alat yang membagi permintaan masuk ke beberapa container. Semuanya ditulis tangan. Jaringan bridge Docker juga tidak melintasi mesin, sehingga container web di mesin pertama tidak dapat memanggil basis data di mesin kedua melalui nama. Pembaruan versi pun menuntut jeda, karena pola paling sederhana menghentikan container lama terlebih dahulu sebelum container baru dijalankan, dan selama jeda itu layanan tidak menerima permintaan.

Perintah-perintah berikut adalah rutinitas yang harus diulang pada setiap kejadian, mulai dari container yang gagal sampai versi baru yang harus dicoba.

# tidak-dijalankan: daemon Docker tidak tersedia di sandbox
# rutinitas manual yang diulang pada setiap kejadian
docker ps -a
docker restart web-1
docker run -d --name web-2 -p 8001:8000 budi/catatan:1.0.0

Tiga perintah masih dapat diikuti tanpa catatan apa pun. Rutinitas yang sama menjadi beban ketika harus diulang pada belasan container, beberapa versi image, dan lebih dari satu mesin, apalagi ketika kejadian itu datang pada waktu tidak ada operator yang menjaga terminal. Titik lelah inilah yang memicu kebutuhan akan sistem yang mengambil alih rutinitas tersebut.

Tugas yang dijawab orkestrasi#

Orchestration (orkestrasi) adalah pengelolaan container di banyak mesin oleh satu sistem yang menempatkan, memulihkan, menskalakan, dan memperbarui container secara otomatis. Istilah scheduling (penjadwalan) menyatakan keputusan host mana yang menjalankan container baru, sedangkan self-healing menyatakan kemampuan memulihkan keadaan tanpa perintah manusia. Sistem semacam ini tidak menggantikan Docker, melainkan mengatur banyak mesin yang masing-masing menjalankan Docker Engine. Tugas khasnya dirangkum pada tabel berikut.

Pada aplikasi catatan, penjadwalan menyebar replika web ke host yang berbeda sehingga kegagalan satu mesin tidak mematikan semuanya. Pemulihan mandiri membuat ulang container basis data yang gagal dan memasang kembali volume datanya. Rolling update, pembaruan yang menggantikan replika lama satu per satu, membuat versi baru image dapat dirilis pada siang hari tanpa jeda bagi pengguna.

Dua tugas terakhir mengulang pekerjaan yang pada satu mesin diselesaikan oleh jaringan kustom dan berkas compose.yaml. Service discovery memberi container web baru nama db yang tetap benar meskipun basis data berpindah host, sedangkan distribusi konfigurasi mengantarkan DATABASE_URL beserta secret ke replika mana pun yang baru dibuat. Seluruh tugas itu mengikuti satu prinsip, yaitu membandingkan keadaan yang diinginkan dengan keadaan nyata, lalu menutup selisihnya terus-menerus.

Skala yang mengubah perhitungan#

Satu atau dua host masih dapat dijaga dengan rutinitas manual, dan banyak aplikasi memang berhenti di situ. Perhitungan berubah ketika jumlah host mencapai lima, sepuluh, atau lebih, sementara setiap host menjalankan beberapa container aplikasi yang saling bergantung. Jumlah kombinasi kegagalan dan pembaruan tumbuh jauh lebih cepat daripada jumlah hostnya, sehingga pengawasan manual tidak lagi realistis. Mulai titik ini, orkestrasi menjadi kebutuhan operasional, bukan kemewahan teknis.

Diagram berikut memperlihatkan bentuk pengawasan otomatis itu pada aplikasi catatan.

Kotak biru di atas adalah control plane, kelompok proses yang menyimpan keadaan yang diinginkan dan terus membandingkannya dengan keadaan nyata di setiap host. Ketika satu host hilang, container miliknya dinyatakan hilang juga, dan control plane menempatkan penggantinya ke host lain yang masih hidup. Istilah control plane ini dipakai secara luas oleh berbagai orkestrator, termasuk Kubernetes.

Ringkasan#

• Docker satu mesin tidak menjawab kegagalan host, penambahan replika, jaringan lintas mesin, dan pembaruan dengan jeda, sehingga rutinitas manualnya membengkak seiring skala.
• Orkestrasi mengambil alih penjadwalan, pemulihan mandiri, penskalaan, service discovery, pembaruan bergulir, dan distribusi konfigurasi.
• Orkestrator bekerja dengan terus membandingkan keadaan yang diinginkan dan keadaan nyata melalui control plane, bukan dengan perintah per kejadian.

Referensi#

• Concepts — Kubernetes Docs — Ikhtisar konsep Kubernetes, termasuk definisi cluster, node, dan control plane.
• Docker overview — Docker Docs — Menegaskan lingkup Docker Engine satu mesin yang menjadi batas awal pembahasan ini.