Ada banyak templat pembuatan wadah. Wadah hanyalah versi yang dapat dieksekusi dari gambarnya sendiri. Oleh karena itu, cara membangun wadah terkait erat dengan bagaimana wadah itu dimulai.
Beberapa gambar kontainer berfungsi dengan baik tanpa hak istimewa, yang lain membutuhkan hak root. Selain itu, gambar / wadah yang sama dapat menggabungkan beberapa pola konstruksi dan skenario penggunaan sekaligus.
Di bawah ini kami akan mempertimbangkan kasus penggunaan wadah yang paling umum.
(Untuk pengantar terminologi wadah, lihat
bagian satu )
Skenario Penggunaan Kontainer
Wadah aplikasi
Wadah aplikasi adalah jenis wadah yang paling umum. Pengembang dan pemilik aplikasi menanganinya, dan mereka sendiri mengandung kode sumber, ditambah hal-hal seperti MySQL, Apache, MongoDB, dan Node.js.
Ekosistem besar wadah aplikasi sedang dibentuk. Proyek seperti Koleksi Perangkat Lunak menyediakan gambar wadah aplikasi yang aman dan didukung untuk Red Hat Enterprise Linux. Pada saat yang sama, anggota komunitas Red Hat sedang mengembangkan dan mendukung wadah aplikasi inovatif.
Di Red Hat, kami percaya bahwa wadah aplikasi biasanya tidak memerlukan hak khusus. Namun, ketika membangun lingkungan produksi wadah, ada kebutuhan untuk wadah lain.
Wadah Sistem Operasi
Wadah dari sistem operasi adalah wadah yang jauh lebih menyerupai OS virtual penuh. Kontainer seperti itu juga menggunakan kernel host, tetapi menjalankan sistem init penuh, yang memungkinkan mereka untuk dengan mudah menjalankan beberapa proses. Contoh wadah sistem operasi adalah LXC dan LXD.
Wadah dari sistem operasi dapat, pada prinsipnya, ditiru dengan menggunakan buruh pelabuhan / wadah OCI, asalkan Anda dapat menjalankan sistem di dalamnya sehingga pengguna akhir dapat menginstal perangkat lunak di dalam wadah tersebut dengan cara yang biasa dan menganggapnya sebagai OS virtual penuh.
yum install mysql systemctl enable mysql
Ini sangat menyederhanakan containerisasi aplikasi yang ada. Red Hat bekerja keras untuk menyederhanakan wadah sistem operasi dengan memungkinkan systemd berjalan di dalam wadah dan menggunakan daemon mesin. Meskipun banyak pelanggan belum siap untuk arsitektur microservice, transisi ke model pengiriman perangkat lunak berdasarkan gambar kontainer masih bisa memberi mereka banyak keuntungan.
Wadah hewan peliharaan
Meskipun Red Hat sangat merekomendasikan, mempromosikan, dan mendukung penggunaan
templat berbasis cloud ketika mengembangkan aplikasi baru, kami sangat menyadari bahwa tidak semua aplikasi yang ada akan ditulis ulang dengan cara ini. Secara khusus, karena banyak dari mereka sangat unik dan tak dapat ditiru sehingga, dibandingkan dengan aplikasi standar, mereka terlihat seperti hewan peliharaan (
Hewan peliharaan ) melawan kawanan sapi. Untuk aplikasi seperti itu,
wadah Pet khusus dirancang.
Pet container menggabungkan portabilitas dan kenyamanan infrastruktur container yang dibangun berdasarkan server registry, gambar container dan host container dengan fleksibilitas lingkungan TI tradisional, diimplementasikan di dalam container terpisah. Idenya di sini adalah untuk menyederhanakan kontainerisasi aplikasi yang ada karena
kemampuan yang sama
untuk menggunakan systemd di dalam wadah untuk menggunakan alat otomatisasi yang ada, instalasi perangkat lunak dan alat-alat lain untuk dengan mudah membuat gambar siap wadah untuk diluncurkan.
Wadah Super Privilege
Ketika membangun infrastruktur kontainer berdasarkan host kontainer khusus seperti Red Hat Enterprise Linux Atomic Host, administrator sistem masih harus mengelola. Dan
Super Privileged Containers (SPCs) terbukti sangat berguna dalam lingkungan terdistribusi seperti itu, baik itu Kubernetes, OpenShift, atau bahkan kontainer yang berdiri sendiri. SPC bahkan dapat memuat modul kernel khusus, seperti systemtap.
Dalam infrastruktur yang dibuat untuk menjalankan kontainer, administrator cenderung membutuhkan wadah SPC untuk melakukan tugas-tugas seperti pemantauan, pencadangan, dll. Penting untuk dipahami bahwa karena wadah SPC biasanya jauh lebih terhubung ke inti host, administrator harus Berikan perhatian khusus pada masalah keandalan dan standardisasi ketika memilih sistem operasi host, terutama di lingkungan yang luas dan terdistribusi yang membuat pemecahan masalah menjadi sulit. Selain itu, administrator perlu memastikan bahwa ruang pengguna di dalam SPC kompatibel dengan inti host.
Alat dan perangkat lunak sistem
Distribusi Linux selalu menyediakan perangkat lunak sistem kepada pengguna, seperti Rsyslogd, SSSD, sadc, dll. Secara tradisional, perangkat lunak ini dipasang dalam bentuk paket RPM atau DEB, tetapi dengan munculnya format kemasan wadah, menjadi lebih mudah dan lebih mudah untuk menginstal menggunakan gambar wadah. Secara khusus, Red Hat menawarkan hal-hal seperti wadah siap pakai seperti alat virtualisasi Red Hat, rsyslog, sssd, dan sadc.
Arsitektur wadah
Sebagai pengiriman perangkat lunak kemas mendapatkan momentum, pola desain wadah baru muncul. Di bagian ini kita akan berbicara tentang beberapa di antaranya.
Cara wadah disimpan ke disk (dengan kata lain, format gambar) dapat sangat memengaruhi cara dimulainya. Sebagai contoh, sebuah wadah yang dirancang untuk menjalankan sssd harus memiliki hak istimewa setiap kali dimulai, jika tidak maka ia tidak akan dapat melakukan tugasnya. Di bawah ini, kami secara singkat mempertimbangkan pola utama yang saat ini sedang menjalani tahap pembentukan aktif.
Gambar aplikasi
Ini dengan gambar-gambar ini yang menangani pengguna akhir. Skenario untuk menggunakan gambar tersebut berkisar dari DBMS dan server web hingga aplikasi individual dan bus layanan. Gambar-gambar ini dapat dibuat baik secara internal oleh organisasi atau disediakan oleh vendor perangkat lunak. Oleh karena itu, pengguna akhir sering kali berhubungan dengan isi wadah otonom tersebut dengan hati-hati dan cermat. Selain itu, meskipun ini adalah pilihan termudah untuk pengguna akhir wadah, gambar yang berdiri sendiri jauh lebih sulit untuk dirancang, dibuat, dan ditambal.
Gambar dasar
Gambar dasar adalah salah satu jenis gambar yang paling sederhana. Namun, orang dapat menunjukkan istilah ini dengan berbagai hal, misalnya, rakitan perusahaan standar atau bahkan gambar aplikasi. Meskipun, sebenarnya, ini bukan gambar dasar, tetapi menengah.
Jadi cukup jelaskan bahwa gambar dasar adalah gambar yang tidak memiliki lapisan induk. Gambar dasar biasanya berisi salinan OS yang bersih, serta alat yang diperlukan untuk menginstal paket perangkat lunak atau memperbarui gambar nanti (yum, rpm, apt-get, dnf, microdnf). Gambar dasar dapat dikumpulkan secara manual oleh pengguna akhir, tetapi dalam praktiknya mereka biasanya dibuat dan dirilis oleh komunitas pengembangan (mis. Debian, Fedora atau CentOS) atau vendor perangkat lunak (mis. Red Hat). Asal usul gambar dasar sangat penting untuk keamanan. Kesimpulannya, tujuan utama dan satu-satunya gambar dasar adalah untuk memberikan dasar atas dasar di mana Anda dapat membuat gambar anak Anda. Saat menggunakan dockerfile, pemilihan gambar dasar yang mendasarinya dilakukan secara eksplisit:
FROM registry.access.redhat.com/rhel7-atomic
Gambar pembangun
Ini adalah jenis gambar khusus berdasarkan gambar anak wadah aplikasi yang kemudian dibuat. Gambar pembuat termasuk semua kecuali kode sumber yang ditulis oleh pengembang, yaitu pustaka OS, runtime bahasa, middleware, dan alat
sumber-ke-gambar .
Saat startup, gambar pembangun menarik kode sumber aplikasi yang ditulis oleh pengembang dan menciptakan citra anak dari wadah aplikasi yang siap diluncurkan, yang kemudian dapat dijalankan dalam lingkungan pengembangan atau produksi.
Katakanlah pengembang telah menulis kode PHP untuk aplikasi dan ingin menjalankannya dalam wadah. Untuk melakukan ini, mereka cukup mengambil gambar builder dari PHP dan meneruskannya URL di situs web GitHub, tempat kode mereka disimpan. Akibatnya, pengembang mendapatkan gambar wadah aplikasi yang siap diluncurkan yang berisi Red Hat Enterprise Linux, PHP dari Koleksi Perangkat Lunak, dan, tentu saja, kode sumber PHP untuk aplikasi tersebut.
Gambar pembangun adalah cara yang kuat, mudah, dan cepat untuk mengubah kode sumber menjadi wadah yang dibangun berdasarkan komponen tepercaya.
Komponen kemas
Wadah terutama dimaksudkan untuk digunakan sebagai komponen sistem perangkat lunak yang lebih besar, dan bukan sebagai unit mandiri. Dan ada dua alasan utama untuk ini.
Pertama, arsitektur layanan mikro meningkatkan kebebasan memilih komponen, dan juga mengarah pada peningkatan jumlah komponen dari mana aplikasi dan sistem perangkat lunak disusun. Komponen kemas membantu menyebarkan sistem tersebut lebih cepat dan lebih mudah. Sebagai contoh, gambar kontainer memudahkan untuk memecahkan masalah koeksistensi versi berbeda dari komponen yang sama. Dan alat penentu aplikasi seperti
penyebaran yaml / json di Kubernetes / OpenShift,
broker layanan terbuka ,
OpenShift Templates dan
Helm Charts menyediakan penciptaan deskripsi aplikasi tingkat tinggi.
Kedua, jauh dari selalu semua bagian dari sistem perangkat lunak dapat dengan mudah ditampung. Oleh karena itu, masuk akal untuk melakukan kontainerisasi hanya untuk komponen individual yang paling cocok untuk ini atau yang paling menjanjikan dalam hal hasil. Dalam aplikasi multiservice, satu bagian dari layanan dapat digunakan sebagai wadah, dan yang lainnya menggunakan metode tradisional, seperti RPM atau skrip instalasi, lihat wadah hewan peliharaan. Selain itu, beberapa komponen mungkin sulit untuk ditampung, karena mereka dibagi menjadi beberapa komponen, atau terikat pada beberapa perangkat keras khusus, atau menggunakan panggilan API kernel tingkat rendah, dll. Oleh karena itu, dalam sistem perangkat lunak besar, kemungkinan besar akan ada bagian yang bisa kemas dan bagian yang tidak bisa kemas. Komponen kemas adalah apa yang bisa kemas dan sudah kemas. Komponen kemas dirancang untuk dijalankan sebagai bagian dari aplikasi spesifik, dan bukan dengan sendirinya. Penting untuk dipahami bahwa mereka tidak dimaksudkan untuk operasi otonom, karena mereka berguna hanya sebagai bagian dari sistem perangkat lunak yang lebih besar dan dalam isolasi dari itu praktis tidak berguna.
Misalnya, di OpenShift Enterprise 3.0, sebagian besar kode utama dikerahkan menggunakan RPM, tetapi setelah diinstal, administrator menggunakan router dan registri sebagai wadah. OpenShift 3.1 memperkenalkan opsi penyebaran kemas untuk master, node, openvswitch, dan lain-lain, dan setelah diinstal, administrator juga dapat menggunakan elasticsearch, fluentd, dan kibana sebagai wadah.
Meskipun penginstal OpenShift masih membuat perubahan pada sistem file server, semua komponen perangkat lunak utama sekarang dapat diinstal menggunakan gambar kontainer. Oleh karena itu, komponen-komponen kemas ini, misalnya, sebuah instance dari gambar etcd yang disematkan di OpenShift, tidak boleh - dan tidak akan - digunakan untuk menyimpan kode sumber aplikasi yang bekerja dengan pelanggan Anda, hanya karena komponen-komponen kemas ini dimaksudkan untuk dijalankan sebagai bagian Platform Kontainer OpenShift.
Dalam versi baru OpenShift, tren menuju kontainerisasi komponen hanya meningkat, dan pengembang perangkat lunak lainnya semakin menggunakan pendekatan ini.
Gambar penyebar
Gambar deployer adalah jenis wadah khusus yang, ketika diluncurkan, menyebarkan atau mengelola wadah lain. Deployer memungkinkan Anda untuk menerapkan skema penempatan yang rumit, misalnya, meluncurkan wadah dalam urutan tertentu atau melakukan beberapa tindakan pada awal pertama, seperti membuat skema data atau mengisi awal basis data.
Misalnya, di OpenShift, templat “image / container type” digunakan untuk menggunakan log dan metrik. Menyebarkan komponen-komponen ini menggunakan gambar-gambar penyebaran memungkinkan para insinyur OpenShift untuk mengontrol urutan berbagai komponen berjalan dan memverifikasi bahwa mereka bekerja dengan benar.
Gambar menengah
Gambar perantara adalah gambar apa pun dari wadah yang bergantung pada gambar dasar. Kumpulan kernel, middleware, dan runtimes bahasa biasanya diimplementasikan sebagai lapisan tambahan di atas gambar dasar dan kemudian ditentukan dalam arahan FROM dengan gambar dasar ini. Gambar perantara biasanya tidak digunakan sendiri, tetapi sebagai blok bangunan dalam menciptakan gambar yang otonom.
Lapisan gambar yang berbeda, biasanya, terlibat dalam kelompok spesialis yang berbeda. Misalnya, administrator sistem bertanggung jawab atas lapisan rakitan kernel, dan pengembang untuk lapisan middleware. Pada saat yang sama, lapisan dasar yang disiapkan oleh satu tim bertindak sebagai citra perantara bagi mereka yang bertanggung jawab atas lapisan pada tingkat yang lebih tinggi. Meskipun kadang-kadang gambar menengah seperti itu dapat digunakan secara mandiri, terutama saat pengujian.
Gambar Serba Guna (Intermodal)
Gambar wadah multiguna adalah gambar dengan arsitektur hybrid. Misalnya, banyak gambar di Red Hat Software Collections dapat digunakan dalam dua cara. Pertama, sebagai wadah aplikasi reguler dengan Ruby penuh pada Rails dan server Apache. Kedua, Anda dapat menggunakannya sebagai gambar pembangun untuk Platform OpenShift Container dan membuat gambar anak berdasarkan mereka yang mengandung Ruby on Rails, Apache, dan kode aplikasi yang Anda berikan ke
sumber untuk proses
gambar ketika membangun gambar anak seperti itu.
Perhatikan bahwa gambar multiguna semakin populer karena memungkinkan Anda menyelesaikan dua tugas yang berbeda secara mendasar menggunakan gambar yang sama.
Wadah sistem
Saat menggunakan perangkat lunak sistem dalam bentuk wadah, yang terakhir sering membutuhkan hak pengguna super. Untuk menyederhanakan opsi penyebaran ini dan memastikan bahwa wadah seperti itu diluncurkan sebelum runtime wadah dan sistem orkestrasi diluncurkan, Red Hat telah mengembangkan templat khusus yang disebut
wadah sistem . Kontainer ini diluncurkan selama proses boot OS menggunakan systemd dan perintah atom, yang membuatnya independen dari runtime atau sistem orkestrasi container. Hari ini, Red Hat menawarkan wadah sistem untuk rsyslog, kokpit, dll, dan flanneld dan akan memperluas daftar ini di masa depan.
Wadah sistem sangat menyederhanakan penambahan selektif layanan ini ke Red Hat Enterprise Linux dan Atomic Host.
Kesimpulan
Kontainer tampaknya menjadi hal yang agak sederhana bagi konsumen akhir, tetapi banyak pertanyaan muncul ketika membangun lingkungan produksi wadah. Untuk membahas arsitektur dan metode membangun lingkungan seperti itu, diperlukan terminologi yang seragam untuk semua peserta. Semakin Anda mempelajari desain dan konstruksi lingkungan seperti itu, semakin banyak jebakan yang muncul. Akhirnya, kami hanya mengingat beberapa dari mereka.
Orang-orang sering tidak melihat perbedaan antara istilah "container image" dan "repository", terutama ketika mereka digunakan dalam perintah buruh pelabuhan. Tetapi jika Anda dapat menggunakan perintah tanpa memahami perbedaan, maka ketika bekerja pada arsitektur lingkungan kontainer, Anda harus memahami dengan jelas bahwa repositori benar-benar struktur data utama.
Cukup mudah untuk salah memahami perbedaan antara ruang nama, repositori, lapisan gambar, dan tag. Masing-masing memiliki tujuan dalam arsitektur wadah. Dan meskipun pemasok dan pengguna menggunakannya untuk berbagai tujuan, mereka hanyalah alat.
Tujuan artikel ini adalah untuk membantu Anda memahami terminologi sehingga Anda dapat membuat arsitektur yang lebih maju. Misalnya, bayangkan Anda baru saja ditugaskan untuk mengembangkan infrastruktur yang harus membatasi ketersediaan ruang nama, repositori, dan terlebih lagi, tag dan layer tergantung pada peran dan aturan bisnis. Dan yang terakhir - ingat bahwa cara wadah disusun sebagian besar menentukan bagaimana mulainya (orkestrasi, hak istimewa, dll.).