Kontainer masih berarti "Docker" bagi banyak orang. Docker mempopulerkan penggunaan container modern dalam pengembangan dan penerapan perangkat lunak. Saat ini, teknologi lain juga ada. Beginilah cara Containerd, Docker, dan Kubernetes saling berhubungan.
Awalnya
Saat dirilis pada tahun 2013, Docker adalah proyek mandiri dengan semua yang Anda butuhkan untuk membangun dan menjalankan container. Kekurangannya adalah cara mudah untuk mengatur penerapan container di cloud.
Pada akhir tahun 2013, sekelompok Googler telah menangani masalah ini dengan prototipe yang akan menjadi Kubernetes. Kubernetes dimaksudkan untuk menyederhanakan pengoperasian beban kerja dalam container di seluruh armada alat berat yang besar.
Kembali pada hari-hari awal, Kubernetes terkait erat dengan Docker. Itu menggunakan Docker secara langsung untuk berinteraksi dengan container, meskipun hanya membutuhkan subset fungsi – bagian yang bertanggung jawab untuk menjalankan container sebenarnya.
UI yang berpusat pada pengembang Docker menghalangi Kubernetes. Itu harus melewati aspek proyek yang ramah manusia menggunakan alat khusus, Dockershim. Masalah ini diperparah oleh arah yang berbeda di mana Docker dan Kubernetes menuju. Docker meluncurkan Swarm, alternatif Kubernetesnya sendiri, menawarkan orkestrasi sebagai “mode” Docker bawaan.
Bangkitnya Kontainer
Saat Kubernetes tumbuh dan lebih banyak alat pihak ketiga muncul di sekitar Docker, batasan arsitekturnya menjadi jelas. Pada saat yang sama, Open Container Initiative (OCI) mulai menstandardisasi format container dan runtime. Hal ini menghasilkan spesifikasi OCI yang mendefinisikan wadah yang dapat digunakan oleh beberapa runtime, di mana Docker adalah contohnya.
Docker kemudian mengekstrak runtime container-nya ke dalam proyek baru, containerd. Ini termasuk fungsionalitas Docker untuk mengeksekusi container, menangani penyimpanan tingkat rendah, dan mengelola transfer gambar. Containerd didonasikan ke Cloud Native Computing Foundation (CNCF) untuk memberikan komunitas container dasar untuk membuat solusi container baru.
Munculnya containerd memudahkan proyek seperti Kubernetes untuk mengakses elemen “Docker” tingkat rendah yang mereka butuhkan. Alih-alih benar-benar menggunakan Docker, mereka sekarang memiliki antarmuka yang lebih mudah diakses ke runtime container. Standarisasi teknologi container OCI berarti runtime lain juga dapat digunakan.
Memahami Peran Containerd
Untuk memahami containerd sepenuhnya, perlu melihat sifat container. Wadah benar-benar abstraksi dari berbagai fitur kernel Linux. Untuk menjalankan container, Anda perlu menggunakan syscalls untuk menyiapkan lingkungan container. Langkah-langkahnya berbeda-beda menurut platform dan distribusi.
Containerd turun untuk mengabstraksi kabel tingkat rendah ini. Ini dimaksudkan sebagai "lapisan klien" yang kemudian dibangun oleh perangkat lunak penampung. Ini mungkin perangkat lunak berorientasi pengembang, seperti Docker, atau alat pengembang berorientasi cloud seperti Kubernetes.
Sebelumnya, pengembangan Kubernetes dibiarkan dengan dua opsi buruk:terus menulis shim di sekitar antarmuka Docker yang besar dan kuat, atau mulai berinteraksi dengan fitur kernel Linux secara langsung. Dengan mengeluarkan containerd dari Docker, alternatif ketiga tersedia:gunakan containerd sebagai lapisan abstraksi sistem, tanpa melibatkan Docker.
Berikut ringkasan bagaimana ketiga teknologi tersebut digabungkan:
- Pekerja Buruh – Perangkat lunak berorientasi pengembang dengan antarmuka tingkat tinggi yang memungkinkan Anda dengan mudah membangun dan menjalankan kontainer dari terminal Anda. Sekarang menggunakan containerd sebagai runtime containernya.
- Wadah – Sebuah abstraksi fitur kernel yang menyediakan antarmuka kontainer tingkat yang relatif tinggi. Proyek perangkat lunak lain dapat menggunakan ini untuk menjalankan container dan mengelola gambar container.
- Kubernetes – Orkestra kontainer yang bekerja dengan beberapa runtime kontainer, termasuk containerd. Kubernetes berfokus pada penerapan container secara agregat di satu atau lebih “node” fisik. Secara historis, Kubernetes terikat dengan Docker.
Containerd hanyalah satu backend container. Container lain yang mengimplementasikan spesifikasi Open Containers Runtime termasuk runC dan CRI-O. Runtime ini juga dapat digunakan dengan Docker dan Kubernetes; masing-masing memiliki perbedaannya sendiri.
OCI
OCI adalah badan yang bertanggung jawab untuk menentukan standar kontainer. Pekerjaannya telah berperan dalam memfasilitasi interoperabilitas antara teknologi komponen yang berbeda.
Spesifikasi gambar OCI menentukan seperti apa tampilan container. Spesifikasi runtime menetapkan antarmuka untuk menjalankan container. Proyek seperti containerd kemudian mengimplementasikan spesifikasi ini.
Yang penting, salah satu prioritas OCI adalah untuk mendukung pengalaman penggunaan container yang dipopulerkan oleh Docker. Gambarnya harus dapat dieksekusi pada platform target tanpa argumen yang ditentukan pengguna (mis. docker run hello-world:latest ). Oleh karena itu, gambar OCI harus berisi metadata yang memadai untuk mengaktifkan konfigurasi otomatis ini.
Anda juga dapat melihat referensi ke Container Runtime Interface (CRI). Ini adalah abstraksi khusus Kubernetes atas spesifikasi OCI. CRI dibangun berdasarkan spesifikasi OCI untuk mengaktifkan dukungan runtime container yang dapat dipertukarkan dalam Kubernetes.
Bagaimana Dengan Gambar Docker Saya?
Gambar yang Anda buat dengan Docker sama sekali bukan "gambar Docker". Karena Docker sekarang menggunakan runtime containerd, gambar Anda dibuat dalam format Open Container Initiative (OCI) standar.
Anda tidak perlu khawatir tentang ketidakcocokan antara gambar Docker Anda dan lingkungan tempat mereka digunakan. Gambar yang Anda buat dengan Docker masih dapat digunakan menggunakan Kubernetes. Ini karena Kubernetes juga mendukung gambar OCI, melalui penggunaan containerd (dan runtime yang sesuai standar lainnya). Terserah runtime untuk menangani penarikan dan pengoperasian gambar, bukan antarmuka tingkat tinggi yang disediakan oleh alat seperti Docker dan Kubernetes.
Kubernetes dan Docker
Kubernetes menghentikan runtime Docker pada akhir 2020. Ini akan dihapus dalam rilis mendatang, saat ini dijadwalkan untuk akhir 2021. Setelah itu, Kubernetes tidak akan lagi menawarkan runtime Docker mendukung. Runtime alternatif yang kompatibel dengan spesifikasi OCI, seperti containerd, perlu digunakan sebagai gantinya.
Pengumuman ini memicu kekhawatiran tentang implikasinya bagi pengembang. Perubahan seharusnya tidak memengaruhi sebagian besar alur kerja yang ada. Seperti yang telah kita lihat, Docker menghasilkan gambar yang sesuai dengan OCI yang dapat dijalankan oleh runtime yang sesuai dengan OCI. Gambar apa pun yang Anda buat dengan docker build akan tetap bekerja di dalam Kubernetes, bahkan setelah runtime Docker dihapus.
Dua teknologi berbeda sedang dipertimbangkan – Docker antarmuka baris perintah digunakan untuk membuat dan menjalankan container, dan runtime Do Docker yang dicakup oleh antarmuka baris perintah.
Semuanya Terlalu Membingungkan!
Hanya dalam beberapa tahun, container telah mengubah jumlah developer yang bekerja. Ekspansi di ekosistem sekitarnya telah menjadi produk sampingan alami dari pergeseran ini. Containers === Docker mentalitas terbukti terlalu menyesakkan karena mencegah alat seperti Kubernetes menunjukkan potensi penuhnya.
Langkah menuju standardisasi telah menghasilkan sejumlah besar istilah, alat, dan teknologi baru. Meskipun demikian, tidak ada yang benar-benar berubah untuk developer, baik Anda berinteraksi dengan Docker CLI di mesin Anda atau cluster Kubernetes di cloud.
Setiap antarmuka tingkat tinggi yang dihadapi pengguna (seperti Docker dan Kubernetes) kini mendapat manfaat dari pilihan runtime container tingkat rendah yang dapat dipertukarkan (seperti containerd dan runC). Hal ini memungkinkan tingkat fleksibilitas yang lebih besar dan memungkinkan teknologi baru berbasis container membangun dirinya sendiri dengan cara yang selaras dengan standar.