Paket dan manajer paket untuk k8s

Kita semua menggunakan beberapa jenis manajer paket, termasuk wanita pembersih Bibi Galya, yang memiliki iPhone di sakunya sekarang diperbarui. Tetapi tidak ada kesepakatan umum tentang fungsi manajer paket, dan rpm standar dan OS dpkg dan sistem bangun disebut manajer paket. Kami menawarkan untuk merefleksikan topik fungsi mereka - apa itu dan mengapa mereka dibutuhkan di dunia modern. Dan kemudian kita akan menggali ke arah Kubernetes dan dengan hati-hati mempertimbangkan Helm dalam hal fungsi-fungsi ini.


Kami akan memahami mengapa dalam diagram ini hanya fungsi template yang disorot dalam warna hijau, dan apa masalah dengan perakitan dan pengemasan, otomatisasi lingkungan, dan banyak lagi. Tapi jangan khawatir, artikel itu tidak berakhir dengan fakta bahwa semuanya buruk. Komunitas tidak bisa menerima ini dan menawarkan alat dan solusi alternatif - kami akan menanganinya.

Ivan Glushkov ( gli ) membantu kami dengan ini dengan laporannya tentang RIT ++, versi video dan teks dari presentasi terperinci dan terperinci di bawah ini.

Video tentang hal ini dan pidato DevOps lainnya di RIT ++ dipublikasikan dan terbuka untuk ditonton secara gratis di saluran youtube kami - cari jawaban atas pertanyaan Anda yang sedang dikerjakan.

Tentang pembicara: Ivan Glushkov telah mengembangkan perangkat lunak selama 15 tahun. Saya berhasil bekerja di MZ, di Echo pada platform untuk komentar, berpartisipasi dalam pengembangan kompiler untuk prosesor Elbrus di MCST. Dia saat ini terlibat dalam proyek infrastruktur di Postmates. Ivan adalah salah satu podcast DevZen terkemuka di mana mereka berbicara tentang konferensi kami: di sini adalah tentang RIT ++, dan di sini tentang HighLoad ++.

Manajer paket

Meskipun semua orang menggunakan beberapa jenis manajer paket, tidak ada kesepakatan tunggal tentang apa itu. Ada pemahaman bersama, dan masing-masing memiliki sendiri.

Mari kita ingat jenis manajer paket apa yang pertama kali terlintas dalam pikiran:

• Manajer paket standar dari semua sistem operasi: rpm, dpkg, portage , ...
• Manajer paket untuk berbagai bahasa pemrograman: kargo, komplotan rahasia, rebar3, mix , ...

Fungsi utamanya adalah untuk menjalankan perintah untuk menginstal paket, memperbarui paket, menghapus paket, dan mengelola dependensi. Dalam manajer paket di dalam bahasa pemrograman, hal-hal sedikit lebih rumit. Misalnya, ada perintah seperti "luncurkan paket" atau "buat rilis" (build / run / release). Ternyata ini sudah merupakan sistem build, meskipun kami juga menyebutnya manajer paket.


Semua ini hanya karena Anda tidak bisa mengambilnya dan ... biarkan pecinta Haskell memaafkan perbandingan ini. Anda dapat menjalankan file biner, tetapi Anda tidak dapat menjalankan program di Haskell atau C, pertama-tama Anda harus mempersiapkannya entah bagaimana. Dan persiapan ini agak rumit, dan pengguna ingin semuanya dilakukan secara otomatis.

Pengembangan

Orang yang bekerja dengan GNU libtool, yang dibuat untuk proyek besar yang terdiri dari sejumlah besar komponen, tidak menertawakan sirkus. Ini benar-benar sangat sulit, dan beberapa kasus pada prinsipnya tidak dapat diselesaikan, tetapi hanya dapat dielakkan.

Dibandingkan dengan itu, manajer bahasa paket modern seperti kargo untuk Rust jauh lebih mudah - Anda menekan tombol dan semuanya berfungsi. Meskipun pada kenyataannya, di bawah tenda, sejumlah besar masalah diselesaikan. Selain itu, semua fungsi baru ini memerlukan sesuatu yang tambahan, khususnya, basis data. Meskipun dalam paket manajer itu sendiri dapat disebut apa pun yang Anda suka, saya menyebutnya basis data, karena data disimpan di sana: tentang paket yang diinstal, tentang versinya, repositori yang terhubung, versi dalam repositori ini. Semua ini harus disimpan di suatu tempat, jadi ada basis data internal.

Pengembangan dalam bahasa pemrograman ini, pengujian untuk bahasa pemrograman ini, diluncurkan - semua ini adalah built-in dan terletak di dalam, pekerjaan menjadi sangat nyaman . Sebagian besar bahasa modern telah mendukung pendekatan ini. Bahkan mereka yang tidak mendukung mulai mendukung, karena masyarakat menekan dan mengatakan bahwa di dunia modern tidak mungkin tanpa itu.

Tetapi solusi apa pun selalu tidak hanya memiliki kelebihan, tetapi juga kelemahan . Kelemahannya di sini adalah Anda membutuhkan pembungkus, utilitas tambahan, dan "basis data" bawaan.

Docker

Apakah Anda pikir Docker adalah manajer paket atau tidak?

Tidak peduli bagaimana, tetapi pada dasarnya ya. Saya tidak tahu utilitas yang lebih benar untuk benar-benar meletakkan aplikasi bersama dengan semua dependensi, dan membuatnya berfungsi dengan mengklik tombol. Apa ini jika bukan manajer paket? Ini adalah manajer paket yang hebat!

Maxim Lapshin telah mengatakan bahwa dengan Docker menjadi lebih mudah, dan memang begitu. Docker memiliki sistem built-in build, semua database, binding, utilitas ini.

Berapa harga semua manfaatnya? Mereka yang bekerja dengan Docker tidak banyak memikirkan aplikasi industri. Saya punya pengalaman seperti itu, dan harganya sebenarnya sangat tinggi:

• Jumlah informasi (ukuran gambar) yang harus disimpan dalam gambar Docker. Anda memerlukan semua dependensi, bagian dari utilitas, pustaka untuk dikemas di dalamnya, gambarnya besar dan Anda harus dapat bekerja dengannya.
• Jauh lebih rumit bahwa pergeseran paradigma sedang terjadi.

Misalnya, saya punya tugas untuk mentransfer satu program untuk menggunakan Docker. Program ini dikembangkan selama bertahun-tahun oleh sebuah tim. Saya datang, kami melakukan semua yang ditulis dalam buku: kami melukiskan kisah, peran, melihat apa yang dilakukan pengguna, rutinitas standar mereka.

Saya katakan:

- Docker dapat menyelesaikan semua masalah Anda. Perhatikan bagaimana ini dilakukan.

- Semuanya akan ada di tombol - hebat! Tapi kami ingin SSH melakukan di dalam wadah Kubernetes.

- Tunggu, tidak ada SSH di mana pun.

- Ya, ya, semuanya baik-baik saja ... Tetapi apakah SSH mungkin?

Untuk mengubah persepsi pengguna menjadi arah baru, dibutuhkan banyak waktu, dibutuhkan pekerjaan pendidikan dan banyak usaha.

Faktor harga lainnya adalah bahwa Docker-registry adalah repositori eksternal untuk gambar, itu perlu diinstal dan dikendalikan entah bagaimana. Ini memiliki masalah sendiri, pengumpul sampah dan sebagainya, dan itu sering bisa jatuh jika Anda tidak mengikutinya, tetapi ini semua diselesaikan.

Kubernetes

Akhirnya kami sampai di Kubernetes. Ini adalah sistem manajemen aplikasi OpenSource keren yang secara aktif didukung oleh komunitas. Meskipun awalnya meninggalkan satu perusahaan, Kubernetes sekarang memiliki komunitas yang besar, dan tidak mungkin untuk mengikutinya, praktis tidak ada alternatif.

Menariknya, semua simpul Kubernetes bekerja di Kubernetes sendiri melalui wadah, dan semua aplikasi eksternal bekerja melalui wadah - semuanya bekerja melalui wadah ! Ini adalah plus dan minus.

Kubernetes memiliki banyak fungsi dan properti yang berguna: distribusi, toleransi kesalahan, kemampuan untuk bekerja dengan berbagai layanan cloud, dan orientasi ke arah arsitektur layanan-mikro. Semua ini menarik dan keren, tetapi bagaimana cara menginstal aplikasi di Kubernetes?

Bagaimana cara menginstal aplikasi?

Instal gambar Docker di registri Docker.

Di belakang kalimat ini terletak jurang yang dalam. Anda bayangkan - Anda memiliki aplikasi yang ditulis, misalnya, di Ruby, dan Anda harus meletakkan gambar Docker di registri Docker. Ini berarti Anda harus:

• Mempersiapkan gambar Docker
• memahami bagaimana perkembangannya, pada versi apa itu didasarkan;
• dapat mengujinya;
• kumpulkan, isi Docker-registry, yang Anda, omong-omong, instal sebelumnya.

Sebenarnya, ini adalah rasa sakit yang sangat besar dalam satu baris.

Plus, Anda masih perlu menjelaskan manifes aplikasi dalam hal (sumber daya) k8s. Opsi termudah:

• jelaskan penyebaran + pod, layanan + masuknya (mungkin);
• jalankan kubectl terapkan perintah -f resources.yaml, dan transfer semua sumber daya ke perintah ini.

Gandhi menggosok-gosokkan tangannya pada slide - sepertinya aku menemukan manajer paket di Kubernetes. Tapi kubectl bukan manajer paket. Dia hanya mengatakan bahwa saya ingin melihat keadaan akhir dari sistem. Ini bukan menginstal paket, tidak bekerja dengan dependensi, bukan membangun - itu hanya "Saya ingin melihat keadaan akhir ini."

Helm

Akhirnya kami sampai di Helm. Helm adalah utilitas serba guna. Sekarang kita akan mempertimbangkan bidang pengembangan Helm apa dan bekerja dengannya.

Mesin Templat

Pertama, Helm adalah mesin templat. Kami membahas sumber daya apa yang perlu disiapkan, dan masalahnya adalah menulis dalam istilah Kubernetes (dan tidak hanya dalam yaml). Yang paling menarik adalah ini adalah file statis untuk aplikasi spesifik Anda di lingkungan khusus ini.

Namun, jika Anda bekerja dengan beberapa lingkungan dan Anda tidak hanya memiliki Produksi, tetapi juga Pementasan, Pengujian, Pengembangan, dan lingkungan yang berbeda untuk tim yang berbeda, Anda perlu memiliki beberapa manifes serupa. Misalnya, karena di salah satu dari mereka ada beberapa server, dan Anda perlu memiliki sejumlah besar replika, dan yang lain - hanya satu replika. Tidak ada database, akses ke RDS, dan Anda perlu menginstal PostgreSQL di dalamnya. Dan di sini kita memiliki versi lama, dan kita perlu menulis ulang semuanya sedikit.

Semua perbedaan ini mengarah pada kenyataan bahwa Anda harus membawa manifes Anda untuk Kubernetes, menyalinnya di mana-mana dan memperbaikinya di mana-mana: di sini ganti satu digit, di sini ada hal lain. Ini menjadi sangat tidak nyaman.

Solusinya sederhana - Anda harus memasukkan template . Artinya, Anda membentuk manifes, menentukan variabel di dalamnya, dan kemudian mengirimkan variabel yang ditentukan secara eksternal sebagai file. Template menciptakan manifes akhir. Ternyata menggunakan kembali manifes yang sama untuk semua lingkungan, yang jauh lebih nyaman.

Misalnya, manifes untuk Helm.

• Bagian terpenting dalam Helm adalah Chart.yaml , yang menjelaskan jenis manifes apa, versi apa, cara kerjanya.
• templat hanyalah templat sumber daya Kubernet yang berisi beberapa jenis variabel di dalamnya. Variabel-variabel ini harus didefinisikan dalam file eksternal atau pada baris perintah, tetapi selalu eksternal.
• values.yaml adalah nama standar untuk file dengan variabel untuk template ini.

Perintah startup paling sederhana untuk menginstal grafik adalah menginstal helm ./wordpress (folder). Untuk mendefinisikan kembali beberapa parameter, kita mengatakan: "Saya ingin mendefinisikan kembali parameter ini secara tepat dan mengatur nilai ini dan itu."

Helm mengatasi tugas ini, jadi dalam diagram kami menandainya hijau.


Benar, kontra muncul:

• Verbositas . Sumber daya didefinisikan sepenuhnya dalam hal Kubernetes, konsep tingkat abstraksi tambahan tidak diperkenalkan: kami hanya menulis semua yang ingin kami tulis untuk Kubernetes dan mengganti variabel di sana.
• Jangan ulangi diri Anda sendiri - tidak berlaku. Seringkali perlu untuk mengulangi hal yang sama. Jika Anda memiliki dua layanan serupa dengan nama yang berbeda, Anda harus menyalin seluruh folder (paling sering mereka melakukan ini) dan mengubah file yang diperlukan.

Sebelum terjun ke arah Helm - manajer paket, yang saya ceritakan ini semua, mari kita lihat bagaimana Helm bekerja dengan dependensi.

Bekerja dengan dependensi

Helm sulit untuk bekerja dengan ketergantungan. Pertama, ada file requirement.yaml yang cocok dengan apa yang kita andalkan. Saat bekerja dengan persyaratan, ia melakukan persyaratan. Kunci - ini adalah kondisi saat ini (nugget) dari semua dependensi. Setelah itu, ia mengunduhnya ke folder bernama / chart.

Ada alat untuk mengelola: siapa, bagaimana, di mana menghubungkan - tag dan ketentuan , yang ditentukan di lingkungan mana, tergantung pada parameter eksternal apa, untuk menghubungkan atau tidak menghubungkan beberapa dependensi.

Katakanlah Anda memiliki PostgreSQL untuk lingkungan Pementasan (atau RDS untuk Produksi, atau NoSQL untuk pengujian). Dengan menginstal paket ini di Production, Anda tidak akan menginstal PostgreSQL, karena tidak diperlukan di sana - hanya menggunakan tag dan ketentuan.

Apa yang menarik di sini?

• Helm menggabungkan semua sumber daya dari semua dependensi dan aplikasi;
• sort -> instal / perbarui

Setelah kami mengunduh semua dependensi di / chart (dependensi ini mungkin, misalnya, 100), Helm mengambil dan menyalin semua sumber daya di dalamnya. Setelah dia memberikan template, dia mengumpulkan semua sumber daya di satu tempat dan mengurutkan dalam beberapa jenis pesanannya sendiri. Anda tidak dapat memengaruhi pesanan ini. Anda harus menentukan sendiri untuk apa paket Anda bergantung, dan jika paket tersebut memiliki dependensi transitif, maka Anda harus memasukkan semuanya dalam deskripsi dalam persyaratan.yaml. Ini harus diingat.

Manajer paket

Helm menginstal aplikasi dan dependensi, dan Anda dapat memberitahu Helm menginstal - dan itu akan menginstal paket. Jadi ini adalah manajer paket.

Pada saat yang sama, jika Anda memiliki repositori eksternal tempat Anda mengunggah paket, Anda dapat mengaksesnya bukan sebagai folder lokal, tetapi cukup mengatakan: "Dari repositori ini, ambil paket ini, instal dengan parameter ini dan itu."

Ada repositori terbuka dengan banyak paket. Misalnya, Anda dapat menjalankan: helm install -f prod / values.yaml stable / wordpress

Dari repositori stabil, Anda akan mengambil wordpress dan menginstalnya sendiri. Anda dapat melakukan segalanya: mencari / meningkatkan / menghapus. Ternyata, sungguh, Helm adalah manajer paket.

Tetapi ada kontra: semua dependensi transitif harus dimasukkan di dalam. Ini adalah masalah besar ketika dependensi transitif adalah aplikasi independen dan Anda ingin bekerja dengannya secara terpisah untuk pengujian dan pengembangan.

Minus lainnya adalah konfigurasi ujung ke ujung . Ketika Anda memiliki database dan namanya perlu ditransfer ke semua paket, ini bisa, tetapi sulit dilakukan.



Lebih sering daripada tidak, Anda telah menginstal satu paket kecil dan berfungsi. Dunia ini kompleks: aplikasi tergantung pada aplikasi, yang pada gilirannya juga tergantung pada aplikasi - Anda perlu mengonfigurasinya dengan cerdik. Helm tidak tahu bagaimana mendukung ini, atau mendukungnya dengan masalah besar, dan kadang-kadang Anda harus banyak menari dengan rebana untuk membuatnya bekerja. Ini buruk, jadi "manajer paket" dalam diagram disorot dengan warna merah.

Perakitan dan pengemasan

"Anda tidak bisa mendapatkan dan menjalankan" aplikasi di Kubernetes. Anda perlu merakitnya, yaitu membuat gambar Docker, menulisnya ke registri Docker, dll. Meskipun seluruh definisi paket di Helm adalah. Kami menentukan paketnya, fungsi dan bidang apa yang harus ada, tanda tangan, dan otentikasi (sistem keamanan perusahaan Anda akan sangat senang). Oleh karena itu, di satu sisi, perakitan dan pengemasan tampaknya didukung, dan di sisi lain, bekerja dengan gambar Docker tidak dikonfigurasikan.

Helm tidak memungkinkan Anda menjalankan aplikasi tanpa gambar Docker. Pada saat yang sama, Helm tidak dikonfigurasikan untuk perakitan dan pengemasan, yaitu, pada kenyataannya, ia tidak tahu cara bekerja dengan gambar Docker.

Ini sama seperti jika, untuk membuat instalasi pemutakhiran untuk beberapa perpustakaan kecil, Anda akan dikirim ke folder yang jauh untuk menjalankan kompiler.

Karena itu, kami mengatakan bahwa Helm tidak tahu cara bekerja dengan gambar.

Pengembangan

Sakit kepala berikutnya adalah pengembangan. Dalam pengembangan, kami ingin mengubah kode kami dengan cepat dan mudah. Waktu telah berlalu ketika Anda membuat lubang pada kartu punch, dan hasilnya diperoleh setelah 5 hari. Semua orang terbiasa mengganti satu huruf dengan yang lain di editor, menekan kompilasi, dan program yang sudah dimodifikasi berfungsi.

Ternyata di sini bahwa ketika mengubah kode, banyak tindakan tambahan diperlukan: menyiapkan file Docker; Jalankan Docker sehingga itu membangun gambar; untuk mendorongnya ke suatu tempat; disebarkan ke kluster Kubernetes. Dan hanya dengan begitu Anda akan mendapatkan apa yang Anda inginkan di Production, dan Anda dapat memeriksa kodenya.

Masih ada ketidaknyamanan karena pembaruan pembaruan helm yang merusak . Anda melihat bagaimana semuanya bekerja, melalui eksekutif Kubectl Anda melihat di dalam wadah, semuanya baik-baik saja. Pada saat ini Anda memulai pembaruan, gambar baru diunduh, sumber daya baru diluncurkan, dan yang lama dihapus - Anda harus memulai semuanya dari awal.

Rasa sakit terbesar adalah gambar besar . Sebagian besar perusahaan tidak bekerja dengan aplikasi kecil. Seringkali, jika bukan supermonolith, maka setidaknya monolitik kecil. Seiring waktu, dering tahunan bertambah, basis kode bertambah, dan lambat laun aplikasi menjadi cukup besar. Saya telah berulang kali menemukan gambar Docker yang lebih besar dari 2 GB. Bayangkan sekarang bahwa Anda membuat perubahan dalam satu byte dalam program Anda, tekan tombol, dan gambar Docker dua gigabyte mulai berkumpul. Kemudian Anda menekan tombol berikutnya, dan transfer 2 GB ke server dimulai.

Docker memungkinkan Anda untuk bekerja dengan layer, mis. memeriksa apakah ada satu layer atau yang lain dan mengirimkan yang hilang. Tetapi dunia sedemikian rupa sehingga paling sering akan menjadi satu lapisan besar. Sementara 2 GB akan masuk ke server, sementara mereka akan pergi ke Kubernetes dengan Docker-registry, mereka akan diluncurkan dalam semua cara, sampai Anda akhirnya mulai - Anda dapat dengan aman minum teh.

Helm tidak menawarkan bantuan apa pun dengan gambar Docker besar. Saya percaya bahwa ini tidak boleh, tetapi pengembang Helm tahu lebih baik daripada semua pengguna, dan Steve Jobs tersenyum.



Blok dengan pengembangan juga berubah merah.

Otomasi Lingkungan

Arah terakhir - otomatisasi lingkungan - adalah area yang menarik. Sebelum dunia Docker (dan Kubernetes, sebagai model terkait), tidak ada cara untuk mengatakan: "Saya ingin menginstal aplikasi saya di server ini atau di server ini sehingga ada n replika, 50 dependensi, dan semuanya otomatis bekerja!" Seperti itu, bisa dikatakan, apa itu, tapi tidak!

Kubernetes menyediakan ini dan logis untuk menggunakannya entah bagaimana, misalnya, untuk mengatakan: "Saya menyebarkan lingkungan baru di sini dan saya ingin semua tim pengembangan yang menyiapkan aplikasi mereka hanya dapat mengklik tombol dan semua aplikasi ini akan diinstal secara otomatis di lingkungan baru" . Secara teoritis, Helm harus membantu dalam hal ini, sehingga konfigurasi dapat diambil dari sumber data eksternal - S3, GitHub - dari mana saja.

Dianjurkan bahwa ada tombol khusus di Helm "Apakah aku sudah baik akhirnya!" - dan itu akan segera menjadi baik. Kubernetes memungkinkan Anda untuk melakukan ini.

Ini sangat nyaman karena Kubernet dapat dijalankan di mana saja, dan ini bekerja melalui API. Dengan meluncurkan minikube secara lokal, baik di AWS atau di Google Cloud Engine, Anda mengeluarkan Kubernet langsung dan bekerja di mana-mana: tekan tombol dan semuanya baik-baik saja segera.

Tampaknya Helm secara alami memungkinkan Anda untuk melakukan ini. Karena kalau tidak, apa gunanya menciptakan Helm secara umum?

Tapi ternyata, tidak!


Tidak ada otomatisasi lingkungan.

Alternatif

Ketika ada aplikasi dari Kubernetes yang digunakan semua orang (sekarang sebenarnya adalah solusi nomor 1), tetapi Helm memiliki masalah yang dibahas di atas, masyarakat tidak bisa tidak menanggapi. Itu mulai menciptakan alat dan solusi alternatif.

Mesin templat

Tampaknya, sebagai mesin templat, Helm menyelesaikan semua masalah, tetapi komunitas masih menciptakan alternatif. Biarkan saya mengingatkan Anda masalah mesin template: verbosity dan penggunaan kembali kode.

Perwakilan yang baik di sini adalah Ksonnet. Ini menggunakan model data dan konsep yang berbeda secara fundamental, dan tidak bekerja dengan sumber daya Kubernetes, tetapi dengan definisi sendiri:
prototipe (params) -> komponen -> aplikasi -> lingkungan.


Ada bagian yang membentuk prototipe. Prototipe ini diparameterisasi oleh data eksternal, dan komponen muncul. Beberapa komponen membuat aplikasi yang dapat Anda jalankan. Ini berjalan di lingkungan yang berbeda. Ada beberapa tautan yang jelas ke sumber daya Kubernetes di sini, tetapi mungkin tidak ada analogi langsung.

Tujuan utama Ksonnet, tentu saja, untuk menggunakan kembali sumber daya . Mereka ingin memastikan bahwa setelah Anda menulis kode, Anda nanti dapat menggunakannya di mana saja, yang meningkatkan kecepatan pengembangan. Jika Anda membuat perpustakaan eksternal yang besar, orang-orang dapat terus memposting sumber daya mereka di sana, dan seluruh komunitas akan dapat menggunakannya kembali.

Secara teoritis, ini nyaman. Saya praktis tidak menggunakannya.

Manajer paket

, — , , . Ksonnet . Ksonnet Helm , , .. , , , .


, , , , . . , , , 0.1. , .


, — KubePack , .

Pengembangan

:

1. Helm;
   
2. Helm;
   
3. , ;
   
4. , .
   

1. Helm

— Draft . — , , . Draft — Heroku-style:

• (pack);
• , , Python «Hello, world!»;
• , Docker- ( );
• , , docker-registry, ;
• .

, , .

Helm, Draft Helm-, production ready, , Draft Helm-, . .

, Draft , Helm-. Draft — .

2. Helm

Helm Charts Kubernetes-, Helm Charts. :

• GitKube;
• Skaffold;
• Forge.

Helm, . , , command line interface, Chart , git push .

, docker build, docker push kubectl rollout. , Helm, . .

3.

— . — Metaparticle . , Python, Python , .

, , , sysconfig .. .

, , , - Kubernetes-.

: , ; , ; ..


, , , - , Python- Kubernetes-. ?

- , . . , , preinstall , - . Kubernetes-, Metaparticle, .

, , Kubernetes- . , , Metaparticle.



Metaparticle, Helm . , .

Telepresence/Ksync — . , , Helm-, . , - , - , , . , Production-, Production - .

Kubernetes , Docker, registry, Kubernetes. . , .

, , , Development . : , , , , — , , , Helm, , .

, .

4. Kubernetes Kubernetes

, Kubernetes Kubernetes. , Helm- , . , . , Docker-compose .

Docker-compose , , , , Docker, Kubernetes, Docker-compose, . , . , Docker. .

minikube , Docker-compose, . , , Docker-compose — 10 . , .


Docker-compose, , .

, — Helm, , , Helm - . CI/CD, , . — Helm, ? , , .

CI/CD, , docker', set-, , — .

CI/CD — , .

Ringkasan

5 Helm . , . , , . , , , .

Helm

, , Helm . , Helm , . , , , Helm.

, Road Map. Kuberneres Helm community , , Helm V3 .

Tiller, cli

, . Helm :

1. , (cmd ..).
   
2. Tiller — , Kubernetes.
   

Tiller , Command Line Interface. : « Chart» — Helm , , Tiller', : «, - ! , Kubernetes-» — .

Helm, Tiller , . , , , , Tiller' — namespace . Tiller namespace, , . , .

V3 Tiller .


? , , Command Line Interface, , Kubernetes. , Kubernetes , Tiller. kubectl cli .

Tiller . , Kubernetes Command Line Interface : , , , pre- post-. .

Lua- Chart

, — , lua- . Chart lua-, . . , . , , , .


Lua , , , - , , .

, , . , . Kubernetes, - , , , , . Mari kita lihat apa yang terjadi.

Release- + secret

, , Release- , Release . , Release-, , , CRD, , .

namespace

Release- namespace, , - Tiller' namespace — , .

CRD: controller

, CRD-controller Helm , push-. .

, .


, Helm . , , , . , , . Helm — - Kubernetes. - , , .

, CI/CD , . Slack, kami memiliki bot yang melaporkan ketika bangunan baru lulus master, dan semua tes berhasil. Anda memberi tahu dia: "Saya ingin menginstal ini di Pementasan" - dan dia menginstal, Anda berkata: "Saya ingin menjalankan tes di sana!" - dan dia mulai. Cukup nyaman.

Untuk pengembangan, gunakan Docker-compose atau Telepresence.

Beberapa versi dari satu layanan

Pada akhirnya, kita akan menganalisis situasi ketika ada dua aplikasi A dan B, yang bergantung pada C, tetapi C dari versi yang berbeda. Perlu mengatasi masalah ini:

• untuk pengembangan, karena sebenarnya kita harus mengembangkan hal yang sama, tetapi dua versi berbeda;
• untuk rilis;
• untuk konflik nama, karena di semua manajer paket standar, menginstal dua paket versi yang berbeda dapat menyebabkan masalah.

Bahkan, Kubernetes memutuskan segalanya untuk kami - Anda hanya perlu menggunakannya dengan benar.



Saya akan menyarankan membuat 4 Bagan dalam hal Helm, 3 repositori (untuk repositori C, ini hanya akan menjadi dua cabang yang berbeda). Apa yang paling menarik, semua instalasi untuk v1 dan untuk v2 harus berisi informasi di dalamnya sendiri tentang versi atau untuk layanan apa itu dibuat. Satu solusi pada slide, lampiran C; nama rilis menunjukkan bahwa ini adalah versi v1 untuk layanan A; nama layanan juga berisi versi. Ini adalah contoh paling sederhana, Anda dapat melakukannya dengan sangat berbeda. Tetapi yang paling penting adalah bahwa nama-nama itu unik.

Yang kedua adalah dependensi transitif, dan di sini lebih rumit.


Misalnya, Anda sedang mengembangkan rantai layanan dan ingin menguji A. Untuk ini, Anda harus mentransfer semua dependensi yang A bergantung, termasuk transitif, ke definisi Helm dari paket Anda. Tetapi pada saat yang sama, Anda ingin mengembangkan B dan juga mengujinya - cara melakukan ini tidak jelas, karena Anda perlu memasukkan semua dependensi transitif di dalamnya juga.

Oleh karena itu, saya menyarankan Anda untuk tidak menambahkan semua dependensi di dalam setiap paket, tetapi untuk membuatnya independen dan mengelola apa yang berjalan dari luar. Ini merepotkan, tetapi lebih rendah dari dua kejahatan.

Tautan yang bermanfaat

• Konsep

• GitKube

• Helm

• Ksonnet

• Stiker telegram: satu , dua

• Sig-Aplikasi

• KubePack

• Metapartikel

• Skaffold

• Helm v3

• Susunan Docker

• Ksync

• Telepresence

• Drone

• Menempa

Profil pembicara Ivan Glushkov di GitHub , di twitter , di Habr .

Berita bagus

Di saluran youtube kami , kami membuka video semua laporan tentang DevOps dari festival RIT ++ . Ini adalah daftar putar terpisah, tetapi dalam daftar lengkap video ada banyak hal berguna dari konferensi lain.

Lebih baik lagi, berlangganan saluran dan buletin , karena di tahun mendatang kita akan melihat banyak devops : pada bulan Mei, kerangka kerja RIT ++; di musim semi, musim panas dan musim gugur sebagai bagian dari HighLoad ++, dan DevOpsConf Rusia musim gugur yang terpisah.