Ulasan: Red Hat melakukan Docker dengan cara yang sukar

Red Hat's Project Atomic adalah kaedah pendapat untuk menjalankan kontena Linux. Sistem operasi Atomic Host dilengkapi dengan Docker (container), Flannel (networking), OSTree (host management), Etcd (kedai nilai-kunci yang diedarkan), dan Kubernetes (orkestrasi) yang sudah dipasang. 

Kubernetes adalah salah satu daripada dua sistem orkestrasi kontena yang popular, yang lain adalah Docker Swarm. Anda boleh menyebutnya "kekuatan penuh", tetapi dengan itu timbul kerumitan dan perbelanjaan pentadbiran tambahan.

Kubernetes menyelaraskan penciptaan "pod" di pelbagai host Atom. Pod adalah kumpulan bekas Docker yang secara logik memisahkan perkhidmatan dalam aplikasi. Kontena dalam pod berkongsi alamat IP dan berkomunikasi melalui localhost.

Flannel menyediakan rangkaian overlay untuk host Atom, yang membolehkan setiap pod dalam kluster berkomunikasi dengan pod atau perkhidmatan lain dalam kluster. Rangkaian overlay ini digunakan untuk rangkaian kontena sahaja. Perkhidmatan proksi Kubernetes menyediakan akses ke ruang IP host.

Etcd digunakan untuk menyimpan konfigurasi untuk kedua Kubernetes dan Flannel di semua host dalam kluster.

Kluster kontena atom membuat andaian tertentu kerana Kubernetes. Pentadbir sebenarnya tidak mempunyai pilihan dengan Atomic: Sama ada menggunakan Kubernetes atau mencari OS kontena lain. 

Sekiranya anda memilih “design by convention” dan anda mahukan lebih banyak kebebasan dan fleksibiliti dalam hos kontena, anda mungkin mempertimbangkan RancherOS atau VMware Photon. Sekiranya matlamat utama anda adalah menjalankan banyak kontena di banyak hos, maka Atomic Host, Kubernetes, dan rakan mungkin hanya yang anda perlukan.  

Pentadbiran sistem Host Atom

Atomic Host menggunakan versi dockerperintahnya sendiri atomic, walaupun  dockerperintah sebenarnya tersedia di / bin / docker. Lokasinya di / bin mengisyaratkan beberapa pengerjaan semula yang dilakukan kepada RHEL / CentOS / Fedora untuk menjadikan Atomic OS dibuat khusus untuk kontena. Biasanya hanya binari sistem yang penting berada di / bin.

Anda menguruskan Atomic Host melalui dua subsistem. RPM-OSTree menangani penyebaran dan kemas kini sistem host, sementara Docker menangani penyediaan kontena untuk menjalankan perkhidmatan dan aplikasi. Kedua-dua subsistem ini dikendalikan oleh atomicarahan yang terletak di / usr / bin /.

RPM-OSTree menjadikan sistem fail Atom tidak berubah; iaitu, sistem fail hanya boleh dibaca kecuali untuk / var dan / dll. Direktori / var / lib / docker adalah tempat semua fail dan gambar berkaitan Docker disimpan, sementara / etc mempunyai semua fail konfigurasi. Seperti yang akan kita saksikan kemudian, ini menjadikan peningkatan dan downgrade hos lebih mudah dan selamat, syarat penting ketika menguruskan berpotensi ribuan host kontena dalam kelompok.

The atomicarahan bertujuan untuk menjadi pintu masuk tunggal kepada bekas subsistem-an arahan payung untuk semua perkara bekas termasuk operasi tuan rumah. Yang atomickelihatan perintah dan berasa lebih seperti dockerarahan, tetapi alamat masalah asas dikongsi oleh semua sistem operasi tuan rumah bekas: memulakan perkhidmatan sistem-tahap di dalam bekas pada masa boot, dengan cara yang boleh dipercayai dan telus, dengan menggunakan fail unit systemd.

Dalam Atomic, ini dilakukan dengan apa yang disebut wadah super istimewa, yang mempunyai kemampuan untuk melihat dan memanipulasi host itu sendiri. Jadi, walaupun atomickelihatan seperti perintah Docker standard, ia mengisi jurang antara Docker dan RPM-OSTree — mengkonfigurasi skrip pemasangan, menyiapkan perkhidmatan, memberikan hak yang tepat, dan sejenisnya — untuk memungkinkan penyebaran aplikasi berasaskan kontena yang dapat dipercayai. .

Secara ringkasnya, yang  atomic perintah membolehkan anda memanipulasi infrastruktur asas tuan rumah (cgroups, ruang nama, SELinux, dll) untuk menjalankan aplikasi anda. Sebagai contoh, katakan anda membina aplikasi kontena Network Time Protocol (ntpd) yang memerlukan keupayaan SYS_TIME untuk mengubah waktu sistem host. Anda boleh mengkonfigurasinya dengan menambahkan metadata ke gambar kontena anda menggunakan arahan:

LABEL RUN /usr/bin/docker run -d —cap-add=SYS_TYPE ntpd

Kemudian apabila anda menjalankan wadah ( atomic run ntpd), sistem akan membaca metadata itu dan mengkonfigurasi kemampuan SYS_TIME dan sumber lain untuk wadah tersebut. 

Pemasangan dan konfigurasi Host Atom

Pemasangan adalah satu perjuangan, terutamanya kerana saya mendapati dokumentasi tidak teratur dan mengelirukan. Dokumen tersebut mempunyai pengetahuan yang tinggi mengenai ekosistem Red Hat yang tidak akan dimiliki oleh setiap pembaca. Selepas beberapa permulaan yang salah, saya akhirnya berjaya memasang dari ISO bare-metal. Sokongan untuk pemasangan mesin maya dengan apa-apa selain pengurus virt adalah menyakitkan. Atomic Host jelas tidak mesra Windows atau Mac dalam hal ini.

Bagi sesiapa yang biasa dengan pemasangan CentOS, prosedur bare-metal akan mudah. Satu-satunya perbezaan yang ketara adalah dalam susun atur cakera, dengan ruang yang dikhaskan secara automatik untuk Docker dan kontena, bersama dengan banyaknya pemasangan untuk SELinux, kumpulan, dll. Yang menyertai pemasangan OS kontena.

Menggunakan Kubernetes untuk menguruskan kontena di kluster jauh lebih rumit daripada menjalankan Docker pada satu hos, tetapi dengan kerumitan yang lebih besar muncul kebolehpercayaan dan kemampuan yang lebih besar. Dengan Kubernetes, anda juga mendapat keselesaan mengetahui sistem ini telah diuji pertempuran dalam persekitaran pengeluaran berskala besar (di Google).

Tidak ada cara mudah untuk menubuhkan master Kubernetes. Dokumentasi tersebar di pelbagai laman web projek, dan berkali-kali dokumen menukil ke laman web lain untuk mendapatkan perincian, jadi bersiaplah untuk menghabiskan banyak masa membaca, mengejar dokumen, dan bereksperimen. Jumlah keseluruhan usaha melibatkan pengubahsuaian sekitar selusin fail yang tersebar di beberapa direktori / dll. Sudah tentu muslihatnya adalah untuk mengetahui apakah pengubahsuaian tersebut. Kubernetes sebenarnya tidak dibuat untuk eksperimen biasa dengan bekas. Ini adalah barang pengeluaran tugas berat.

Setelah mengkonfigurasi master dengan Kubernetes, sijil, perkhidmatan, dan rangkaian overlay Flannel, kemudian pasang Flannel (flanneld), Kubernetes (kubelet), dan Etcd pada setiap nod, saya akhirnya menjalankan kluster kontena lima nod. Sayangnya ini menghabiskan sedikit memori, dan saya tidak dapat mencari cara untuk menguji menggunakan satu nod, seperti yang saya lakukan ketika menguji RancherOS dan VMware Photon.

Pada ketika ini, Kubernetes dapat digunakan untuk melancarkan dan menguruskan pod, kumpulan kontena yang merangkumi perkhidmatan dan aplikasi.

Penyimpanan dan rangkaian Host Atom

Seperti kebanyakan sistem operasi host kontena, Atomic Host mengambil pendekatan minimalis, dengan cukup ruang cakera yang disertakan untuk menjalankan host. Itu tidak meninggalkan banyak untuk banyak kontena Docker yang biasa dijalankan, jadi anda perlu melampirkan storan luaran ke host untuk itu.

Di Docker, gambar dan fail berkaitan biasanya disimpan di / var / lib / docker, dan pada kebanyakan sistem operasi standard, anda hanya perlu memasang peranti pada ketika itu di sistem fail untuk menambahkan penyimpanan. Walau bagaimanapun, Atomic menggunakan volume LVM (Pengurus Volume Linux) langsung melalui hujung belakang Device Mapper untuk menyimpan gambar dan metadata Docker: / dev / atomicos / docker-data dan / dev / atomicos / docker-meta. Ini bermakna anda perlu mempelajari sesuatu mengenai LVM dan isi padu untuk menambahkan ruang ke host Atom.

Titik permulaan untuk pengurusan penyimpanan di Atomic adalah skrip persediaan, / etc / sysconfig / docker-storage-setup. Atomic Host mempunyai kolam simpanan untuk penyimpanan Docker (dan host), jadi silap mata di sini adalah menambahkan peranti baru ke dalam kolam ini. Anda akan melakukannya dengan menambahkan ke senarai peranti dalam fail, seperti ini:

DEVS="/dev/vdb /dev/vdc"

Kemudian anda menjalankan skrip pembantu, / usr / bin / docker-storage-setup. Sekiranya semuanya berjalan lancar, cakera anda telah ditambahkan ke kolam renang, dan tuan rumah Atom anda mempunyai ruang untuk Docker. Saya rasa LVM akan dikendalikan dalam pengeluaran dengan alat pentadbiran yang ada, atau seperti skrip Ansible / Salt / Chef / Puppet, jadi mungkin akan kelihatan lebih standard bagi pentadbir yang bekerja di persekitaran pusat data yang besar.

Project Atomic menggunakan Flannel untuk menyediakan rangkaian lapisan kontena melalui Etcd. Anda mengkonfigurasi ini dengan memasukkan fail konfigurasi JSON ke kedai nilai kunci Etcd, menggunakan alat seperti Curl. Untuk mengkonfigurasi subnet untuk kontena, kami mungkin membuat fail JSON yang kelihatan seperti ini:

   "Rangkaian": "172.16.0.0/12",

   "SubnetLen": 24,

   "Latar Belakang": {

      "Jenis": "vxlan"

   }

}

Dan untuk memasukkannya ke dalam master Etcd, kami memasukkannya ke kunci konfigurasi rangkaian:

curl -L //localhost:2379/v2/keys/atomic.io/config -XPUT --data-urlencode [email protected]

Walaupun agak membebankan, ia dapat dikendalikan. Saya suka melihat pembungkus untuk ini arahan konfigurasi yang menjadikannya lebih intuitif untuk pentadbir Unix, mungkin sesuatu seperti atomic ifconfig…, atomic route…dan lain-lain

Terdapat perbezaan lain di sini yang perlu dititikberatkan: konsep Kubernetes pod dan perkhidmatan. Pod adalah sekumpulan bekas yang digabungkan rapat. Semua kontena dalam pod berkongsi hos yang sama dan alamat IP yang sama, dan semuanya hidup bersama atau mati bersama. Anda menentukan berapa banyak contoh pod yang anda mahu jalankan, dan Kubernetes menjalankan pesanan. Sekiranya suatu contoh berhenti atau gagal, Kubernetes berputar yang lain agar sesuai dengan keadaan yang diinginkan.

Perkhidmatan Kubernetes adalah abstraksi yang menentukan kumpulan pod yang logik dan dasar untuk mengaksesnya. Ini memberikan perkhidmatan (mikro) satu, satu nama dan alamat yang stabil di seluruh kitaran hidup pod. Terdapat banyak lagi perkara ini, tetapi itu akan membantu anda memahami mengapa anda memerlukan komponen yang berasingan untuk menguruskan rangkaian. Di Atomic Host, komponen itu adalah Flannel.

Peningkatan dan penurunan Host Atom

Atomic Host menggunakan pengurus pakej yang disebut RPM-OSTree, yang menggabungkan ciri RPM tradisional dan OSTree. RPM-OSTree memberi kita kemampuan untuk bergerak maju dan mundur dengan andal, kerana prosesnya "atomik" (dalam arti pangkalan data kata). RPM-OSTree memberikan urus niaga yang boleh dipercayai untuk kemas kini, yang bermaksud tidak mungkin melanggar sistem operasi. Seperti arahan untuk kontena, peningkatan host dan rollback dihadapi oleh atomicsistem pengurusan:

atomic host upgrade

atomic host rollback

Perhatikan bahawa saya tidak menguji rollback, kerana saya tidak mempunyai apa-apa untuk kembali.

Red Hat Atomic Host sangat sesuai untuk organisasi dengan pelaburan besar dalam kemahiran dan infrastruktur Red Hat. Syarikat yang bermula dari sudut yang berbeza mungkin ingin mempertimbangkan pilihan lain. Kemasukan Kubernetes, dan sejarah Red Hat dalam persekitaran produksi yang besar, berarti Atomic Host hampir menjadi "drop-in" untuk menjalankan beban kerja dalam perusahaan. Tetapi saya tidak melihat pembangun memilihnya sebagai platform pilihan Docker mereka.