Hai semua! Nama saya Pavel Agaletsky. Saya bekerja sebagai ketua pasukan dalam pasukan yang membangunkan sistem penghantaran Lamoda. Pada tahun 2018, saya bercakap di persidangan HighLoad++, dan hari ini saya ingin membentangkan transkrip laporan saya.

Topik saya didedikasikan untuk pengalaman syarikat kami dalam menggunakan sistem dan perkhidmatan ke persekitaran yang berbeza. Bermula dari zaman prasejarah kami, apabila kami menggunakan semua sistem ke pelayan maya biasa, berakhir dengan peralihan beransur-ansur daripada Nomad kepada penggunaan dalam Kubernetes. Saya akan memberitahu anda mengapa kami melakukannya dan masalah yang kami hadapi dalam proses itu.

Menggunakan aplikasi ke VM

Mari kita mulakan dengan fakta bahawa 3 tahun yang lalu semua sistem dan perkhidmatan syarikat telah digunakan pada pelayan maya biasa. Secara teknikal, ia disusun sedemikian rupa sehingga semua kod untuk sistem kami disimpan dan dipasang menggunakan alat pemasangan automatik, menggunakan jenkins. Menggunakan Ansible, ia telah dilancarkan daripada sistem kawalan versi kami ke pelayan maya. Selain itu, setiap sistem yang dimiliki oleh syarikat kami telah digunakan untuk sekurang-kurangnya 2 pelayan: satu daripadanya di kepala, yang kedua di ekor. Kedua-dua sistem ini benar-benar sama antara satu sama lain dalam semua tetapan, kuasa, konfigurasi, dll. Satu-satunya perbezaan di antara mereka ialah kepala menerima trafik pengguna, manakala ekor tidak pernah menerima trafik pengguna.

Mengapa ini dilakukan?

Apabila kami menggunakan keluaran baharu aplikasi kami, kami ingin memastikan pelancaran yang lancar, iaitu, tanpa akibat yang ketara kepada pengguna. Ini dicapai kerana kenyataan bahawa keluaran yang disusun seterusnya menggunakan Ansible telah dilancarkan ke ekor. Di sana, orang yang terlibat dalam penempatan boleh menyemak dan memastikan semuanya baik: semua metrik, bahagian dan aplikasi berfungsi; skrip yang diperlukan dilancarkan. Hanya selepas mereka yakin bahawa semuanya ok, lalu lintas telah ditukar. Ia mula pergi ke pelayan yang sebelum ini adalah ekor. Dan yang sebelum ini menjadi ketua kekal tanpa trafik pengguna, sementara masih mempunyai versi sebelumnya aplikasi kami padanya.

Jadi ia adalah lancar untuk pengguna. Kerana pensuisan adalah serta-merta, kerana ia hanya menukar pengimbang. Anda boleh melancarkan kembali ke versi sebelumnya dengan mudah dengan hanya menukar pengimbang kembali. Kami juga boleh mengesahkan bahawa aplikasi itu mampu menghasilkan walaupun sebelum ia menerima trafik pengguna, yang agak mudah.

Apakah kelebihan yang kita lihat dalam semua ini?

1. Pertama sekali, cukuplah ia hanya berfungsi. Semua orang memahami cara skema penempatan sedemikian berfungsi, kerana kebanyakan orang pernah menggunakan pelayan maya biasa.
2. Ini sudah cukup boleh dipercayai, memandangkan teknologi penggunaan adalah mudah, diuji oleh beribu-ribu syarikat. Berjuta-juta pelayan digunakan dengan cara ini. Sukar untuk memecahkan sesuatu.
3. Dan akhirnya kami dapat penyebaran atom. Penerapan yang berlaku serentak untuk pengguna, tanpa tahap peralihan yang ketara antara versi lama dan versi baharu.

Tetapi kami juga melihat beberapa kelemahan dalam semua ini:

1. Sebagai tambahan kepada persekitaran pengeluaran, persekitaran pembangunan, terdapat persekitaran lain. Contohnya, qa dan prapengeluaran. Pada masa itu kami mempunyai banyak pelayan dan kira-kira 60 perkhidmatan. Atas sebab ini ia adalah perlu untuk setiap perkhidmatan, kekalkan versi terkini untuknya mesin maya. Selain itu, jika anda ingin mengemas kini perpustakaan atau memasang kebergantungan baharu, anda perlu melakukan ini dalam semua persekitaran. Anda juga perlu menyegerakkan masa apabila anda akan menggunakan versi baharu aplikasi anda yang seterusnya dengan masa apabila devops melaksanakan tetapan persekitaran yang diperlukan. Dalam kes ini, mudah untuk masuk ke dalam situasi di mana persekitaran kita akan agak berbeza dalam semua persekitaran sekaligus. Sebagai contoh, dalam persekitaran QA akan terdapat beberapa versi perpustakaan, dan dalam persekitaran pengeluaran akan ada yang berbeza, yang akan membawa kepada masalah.
2. Kesukaran mengemas kini kebergantungan permohonan anda. Ia bukan bergantung pada anda, tetapi pada pasukan lain. Iaitu, dari pasukan devops yang menyelenggara pelayan. Anda mesti memberi mereka tugas yang sesuai dan penerangan tentang perkara yang anda mahu lakukan.
3. Pada masa itu, kami juga ingin membahagikan monolit besar besar yang kami miliki kepada perkhidmatan kecil yang berasingan, kerana kami faham bahawa akan ada lebih banyak daripada mereka. Pada masa itu, kami sudah mempunyai lebih daripada 100 daripadanya. Bagi setiap perkhidmatan baharu, adalah perlu untuk mencipta mesin maya baharu yang berasingan, yang juga perlu diselenggara dan digunakan. Di samping itu, anda tidak memerlukan satu kereta, tetapi sekurang-kurangnya dua. Ditambah kepada semua ini ialah persekitaran QA. Ini menyebabkan masalah dan menyukarkan anda untuk membina dan menjalankan sistem baharu. proses yang kompleks, mahal dan panjang.

Oleh itu, kami memutuskan bahawa adalah lebih mudah untuk beralih daripada menggunakan mesin maya biasa kepada menggunakan aplikasi kami dalam bekas docker. Jika anda mempunyai docker, anda memerlukan sistem yang boleh menjalankan aplikasi dalam kelompok, kerana anda tidak boleh hanya menaikkan bekas. Biasanya anda ingin menjejaki berapa banyak bekas yang diangkat supaya ia diangkat secara automatik. Atas sebab ini, kami perlu memilih sistem kawalan.

Kami berfikir untuk masa yang lama tentang mana yang boleh kami ambil. Hakikatnya ialah pada masa itu timbunan penggunaan pada pelayan maya biasa ini agak ketinggalan zaman, kerana mereka tidak mempunyai versi sistem pengendalian terkini. Pada satu ketika, terdapat juga FreeBSD, yang tidak begitu mudah untuk disokong. Kami faham bahawa kami perlu berhijrah ke pelabuhan secepat mungkin. Devops kami melihat pengalaman sedia ada mereka dengan penyelesaian yang berbeza dan memilih sistem seperti Nomad.

Tukar kepada Nomad

Nomad ialah produk HashiCorp. Mereka juga terkenal dengan penyelesaian mereka yang lain:

"Konsul" ialah alat untuk penemuan perkhidmatan.

"Terraform" - sistem untuk mengurus pelayan yang membolehkan anda mengkonfigurasinya melalui konfigurasi, yang dipanggil infrastruktur-sebagai-kod.

"Kelana" membolehkan anda menggunakan mesin maya secara tempatan atau dalam awan melalui fail konfigurasi tertentu.

Nomad pada masa itu kelihatan seperti penyelesaian yang agak mudah yang boleh ditukar dengan cepat tanpa mengubah keseluruhan infrastruktur. Di samping itu, ia agak mudah untuk dipelajari. Itulah sebabnya kami memilihnya sebagai sistem penapisan untuk bekas kami.

Apakah yang anda perlukan untuk menggunakan sistem anda ke Nomad?

1. Pertama sekali anda perlukan imej buruh pelabuhan permohonan anda. Anda perlu membinanya dan meletakkannya dalam repositori imej docker. Dalam kes kami, ini adalah artifaktori - sistem yang membolehkan anda menolak pelbagai artifak pelbagai jenis ke dalamnya. Ia boleh menyimpan arkib, imej docker, pakej PHP komposer, pakej NPM, dan sebagainya.
2. Juga diperlukan fail konfigurasi, yang akan memberitahu Nomad apa, di mana dan dalam kuantiti yang anda mahu gunakan.

Apabila kita bercakap tentang Nomad, ia menggunakan bahasa HCL sebagai format fail maklumatnya, yang bermaksud Bahasa Konfigurasi HashiCorp. Ini ialah superset Yaml yang membolehkan anda menerangkan perkhidmatan anda dalam istilah Nomad.

Ia membolehkan anda menyatakan bilangan bekas yang anda mahu gunakan, daripada imej mana untuk menghantar pelbagai parameter kepada mereka semasa penggunaan. Oleh itu, anda menyuapkan fail ini kepada Nomad, dan ia melancarkan bekas ke dalam pengeluaran mengikutnya.

Dalam kes kami, kami menyedari bahawa hanya menulis fail HCL yang benar-benar serupa untuk setiap perkhidmatan tidak akan menjadi sangat mudah, kerana terdapat banyak perkhidmatan dan kadangkala anda ingin mengemas kininya. Ia berlaku bahawa satu perkhidmatan digunakan bukan dalam satu contoh, tetapi dalam pelbagai yang berbeza. Sebagai contoh, salah satu sistem yang kami ada dalam pengeluaran mempunyai lebih daripada 100 contoh dalam pengeluaran. Ia dijalankan daripada imej yang sama, tetapi berbeza dalam tetapan konfigurasi dan fail konfigurasi.

Oleh itu, kami memutuskan bahawa adalah mudah untuk kami menyimpan semua fail konfigurasi kami untuk digunakan dalam satu repositori biasa. Dengan cara ini ia kelihatan: ia mudah diselenggara dan kita dapat melihat sistem yang kita ada. Jika perlu, ia juga mudah untuk mengemas kini atau mengubah sesuatu. Menambah sistem baharu juga tidak sukar - anda hanya perlu mencipta fail konfigurasi di dalam direktori baharu. Di dalamnya terdapat fail berikut: service.hcl, yang mengandungi perihalan perkhidmatan kami, dan beberapa fail env yang membenarkan perkhidmatan ini, yang digunakan dalam pengeluaran, dikonfigurasikan.

Walau bagaimanapun, sesetengah sistem kami digunakan dalam pengeluaran bukan dalam satu salinan, tetapi dalam beberapa sekali gus. Oleh itu, kami memutuskan bahawa lebih mudah untuk kami menyimpan bukan konfigurasi dalam bentuk tulennya, tetapi bentuk templatnya. Dan kami memilih jinja 2. Dalam format ini, kami menyimpan kedua-dua konfigurasi perkhidmatan itu sendiri dan fail env yang diperlukan untuknya.

Di samping itu, kami telah meletakkan dalam repositori skrip penggunaan biasa untuk semua projek, yang membolehkan anda melancarkan dan menggunakan perkhidmatan anda ke dalam pengeluaran, ke dalam persekitaran yang dikehendaki, ke dalam sasaran yang dikehendaki. Dalam kes apabila kami menukar konfigurasi HCL kami menjadi templat, maka fail HCL, yang sebelum ini adalah konfigurasi Nomad biasa, dalam kes ini mula kelihatan sedikit berbeza.

Iaitu, kami menggantikan beberapa pembolehubah lokasi konfigurasi dengan pembolehubah yang disisipkan yang diambil daripada fail env atau sumber lain. Di samping itu, kami mendapat peluang untuk mengumpul fail HCL secara dinamik, iaitu, kami boleh menggunakan bukan sahaja sisipan pembolehubah biasa. Memandangkan jinja menyokong gelung dan syarat, anda juga boleh membuat fail konfigurasi di sana, yang berubah bergantung pada tempat anda menggunakan aplikasi anda.

Sebagai contoh, anda ingin menggunakan perkhidmatan anda ke pra-pengeluaran dan pengeluaran. Katakan bahawa dalam pra-pengeluaran anda tidak mahu menjalankan skrip cron, tetapi hanya mahu melihat perkhidmatan pada domain yang berasingan untuk memastikan ia berfungsi. Bagi sesiapa sahaja yang menggunakan perkhidmatan, prosesnya kelihatan sangat mudah dan telus. Apa yang anda perlu lakukan ialah melaksanakan fail deploy.sh, tentukan perkhidmatan yang anda mahu gunakan dan sasaran yang mana. Sebagai contoh, anda ingin menggunakan sistem tertentu ke Rusia, Belarus atau Kazakhstan. Untuk melakukan ini, cuma tukar salah satu parameter, dan anda akan mempunyai fail konfigurasi yang betul.

Apabila perkhidmatan Nomad sudah digunakan ke kluster anda, ia kelihatan seperti ini.

Pertama, anda memerlukan sejenis pengimbang di luar, yang akan menerima semua trafik pengguna. Ia akan bekerjasama dengan Konsul dan mengetahui daripadanya di mana, pada nod apa, pada alamat IP mana perkhidmatan tertentu terletak yang sepadan dengan nama domain tertentu. Perkhidmatan di Konsul datang dari Nomad sendiri. Oleh kerana ini adalah produk dari syarikat yang sama, ia agak berkaitan antara satu sama lain. Kita boleh mengatakan bahawa Nomad di luar kotak boleh mendaftarkan semua perkhidmatan yang dilancarkan di dalamnya di dalam Konsul.

Setelah pengimbang beban bahagian hadapan anda mengetahui perkhidmatan yang hendak dihantar trafik, ia memajukannya ke bekas yang sesuai atau berbilang bekas yang sepadan dengan aplikasi anda. Sememangnya, ia juga perlu untuk memikirkan keselamatan. Walaupun semua perkhidmatan berjalan pada mesin maya yang sama dalam bekas, ini biasanya memerlukan menghalang akses percuma daripada mana-mana perkhidmatan kepada mana-mana perkhidmatan lain. Kami mencapai ini melalui segmentasi. Setiap perkhidmatan telah dilancarkan dalam rangkaian mayanya sendiri, di mana peraturan penghalaan dan peraturan untuk membenarkan/menolak akses kepada sistem dan perkhidmatan lain telah ditetapkan. Mereka boleh terletak di dalam gugusan ini dan di luarnya. Contohnya, jika anda ingin menghalang perkhidmatan daripada menyambung ke pangkalan data tertentu, ini boleh dilakukan melalui pembahagian peringkat rangkaian. Iaitu, walaupun secara tidak sengaja, anda tidak boleh menyambung secara tidak sengaja dari persekitaran ujian ke pangkalan data pengeluaran anda.

Berapakah kos peralihan itu dari segi sumber manusia?

Peralihan keseluruhan syarikat kepada Nomad mengambil masa kira-kira 5-6 bulan. Kami bergerak berdasarkan perkhidmatan demi perkhidmatan, tetapi pada kadar yang agak pantas. Setiap pasukan perlu mencipta bekas mereka sendiri untuk perkhidmatan tersebut.

Kami telah menggunakan pendekatan sedemikian sehingga setiap pasukan bertanggungjawab untuk imej docker sistem mereka secara bebas. DevOps menyediakan infrastruktur umum yang diperlukan untuk penggunaan, iaitu sokongan untuk kluster itu sendiri, sokongan untuk sistem CI dan sebagainya. Dan pada masa itu, kami mempunyai lebih daripada 60 sistem dipindahkan ke Nomad, yang berjumlah kira-kira 2 ribu kontena.

Devops bertanggungjawab untuk infrastruktur umum semua yang berkaitan dengan penempatan dan pelayan. Dan setiap pasukan pembangunan, seterusnya, bertanggungjawab untuk melaksanakan kontena untuk sistem khususnya, kerana pasukan itu yang mengetahui perkara yang biasanya diperlukan dalam bekas tertentu.

Sebab untuk meninggalkan Nomad

Apakah kelebihan yang kami perolehi dengan beralih kepada penggunaan menggunakan Nomad dan docker, antara lain?

1. Kami diberikan syarat yang sama rata untuk semua persekitaran. Dalam pembangunan, persekitaran QA, pra-pengeluaran, pengeluaran, imej bekas yang sama digunakan, dengan kebergantungan yang sama. Oleh itu, anda hampir tidak mempunyai peluang bahawa apa yang akan berakhir dalam pengeluaran bukanlah apa yang anda uji secara tempatan atau dalam persekitaran ujian anda sebelum ini.
2. Kami juga mendapati bahawa ia sudah mencukupi mudah untuk menambah perkhidmatan baharu. Dari sudut penggunaan, mana-mana sistem baharu dilancarkan dengan sangat mudah. Hanya pergi ke repositori yang menyimpan konfigurasi, tambahkan konfigurasi lain untuk sistem anda di sana, dan anda sudah bersedia. Anda boleh menggunakan sistem anda ke pengeluaran tanpa sebarang usaha tambahan daripada devops.
3. semua fail konfigurasi dalam satu repositori biasa ternyata dalam semakan. Pada masa kami menggunakan sistem kami menggunakan pelayan maya, kami menggunakan Ansible, di mana konfigurasi berada dalam repositori yang sama. Walau bagaimanapun, bagi kebanyakan pembangun ini agak sukar untuk digunakan. Di sini jumlah konfigurasi dan kod yang anda perlu tambahkan untuk menggunakan perkhidmatan telah menjadi lebih kecil. Selain itu, sangat mudah untuk devops membetulkannya atau mengubahnya. Dalam kes peralihan, contohnya, kepada versi baharu Nomad, mereka boleh mengambil dan mengemas kini pukal semua fail pengendalian yang terletak di tempat yang sama.

Tetapi kami juga menghadapi beberapa kelemahan:

Ternyata kita tidak dapat mencapai penempatan yang lancar dalam kes Nomad. Apabila melancarkan bekas dalam keadaan yang berbeza, ia mungkin akan berjalan, dan Nomad menganggapnya sebagai bekas yang sedia untuk menerima trafik. Ini berlaku sebelum aplikasi di dalamnya berpeluang untuk dilancarkan. Atas sebab ini, sistem mula menghasilkan 500 ralat untuk jangka masa yang singkat, kerana trafik mula pergi ke kontena yang belum bersedia untuk menerimanya.

Kami menemui beberapa pepijat. Pepijat yang paling ketara ialah Nomad tidak mengendalikan kluster besar dengan baik jika anda mempunyai banyak sistem dan bekas. Apabila anda ingin mengeluarkan salah satu pelayan yang termasuk dalam kluster Nomad untuk penyelenggaraan, terdapat kebarangkalian yang agak tinggi bahawa kluster tidak akan berasa sangat baik dan akan runtuh. Sesetengah bekas mungkin, sebagai contoh, jatuh dan tidak naik - ini akan merugikan anda nanti jika semua sistem pengeluaran anda terletak dalam kelompok yang diuruskan oleh Nomad.

Jadi kami memutuskan untuk memikirkan ke mana kami harus pergi seterusnya. Pada ketika itu, kami menjadi lebih sedar tentang apa yang ingin kami capai. Iaitu: kami mahukan kebolehpercayaan, lebih banyak fungsi daripada yang disediakan Nomad, dan sistem yang lebih matang dan lebih stabil.

Dalam hal ini, pilihan kami jatuh pada Kubernetes sebagai platform paling popular untuk melancarkan kluster. Terutamanya memandangkan saiz dan bilangan bekas kami cukup besar. Untuk tujuan sedemikian, Kubernetes nampaknya merupakan sistem yang paling sesuai yang boleh kita lihat.

Peralihan kepada Kubernetes

Saya akan memberitahu anda sedikit tentang konsep asas Kubernetes dan bagaimana ia berbeza daripada Nomad.

Pertama sekali, konsep paling asas dalam Kubernetes ialah konsep pod. Pod ialah sekumpulan satu atau lebih bekas yang sentiasa berjalan bersama-sama. Dan mereka sentiasa berfungsi seolah-olah ketat pada satu mesin maya. Mereka boleh diakses antara satu sama lain melalui IP 127.0.0.1 pada port yang berbeza.

Mari kita anggap bahawa anda mempunyai aplikasi PHP yang terdiri daripada nginx dan php-fpm - skema klasik. Kemungkinan besar, anda akan mahu menyimpan kedua-dua bekas nginx dan php-fpm bersama-sama pada setiap masa. Kubernetes membolehkan anda mencapai ini dengan menggambarkannya sebagai satu pod biasa. Inilah yang kami tidak dapat dengan Nomad.

Konsep kedua ialah penempatan. Hakikatnya ialah pod itu sendiri adalah sesuatu yang tidak lama; ia bermula dan hilang. Adakah anda mahu mematikan semua bekas anda yang terdahulu dahulu, dan kemudian melancarkan versi baharu sekali gus, atau adakah anda mahu melancarkannya secara beransur-ansur? Ini ialah proses yang bertanggungjawab untuk konsep penggunaan. Ia menerangkan cara anda menggunakan pod anda, dalam kuantiti dan cara mengemas kininya.

Konsep ketiga ialah perkhidmatan. Perkhidmatan anda sebenarnya adalah sistem anda, yang menerima sedikit trafik dan kemudian memajukannya ke satu atau lebih pod yang sepadan dengan perkhidmatan anda. Iaitu, ia membolehkan anda untuk mengatakan bahawa semua trafik masuk ke perkhidmatan ini dan ini dengan nama ini dan itu mesti dihantar ke pod khusus ini. Dan pada masa yang sama ia memberikan anda pengimbangan trafik. Iaitu, anda boleh melancarkan dua pod aplikasi anda dan semua trafik masuk akan seimbang antara pod yang berkaitan dengan perkhidmatan ini.

Dan konsep asas keempat ialah Ingress. Ini ialah perkhidmatan yang berjalan pada gugusan Kubernetes. Ia bertindak sebagai pengimbang beban luaran yang mengambil alih semua permintaan. Menggunakan API Kubernetes, Ingress boleh menentukan tempat permintaan ini harus dihantar. Lebih-lebih lagi, dia melakukan ini dengan sangat fleksibel. Anda boleh mengatakan bahawa semua permintaan kepada hos ini dan URL sedemikian dan sedemikian dihantar ke perkhidmatan ini. Dan permintaan ini datang ke hos ini dan ke URL lain dihantar ke perkhidmatan lain.

Perkara yang paling hebat dari sudut pandangan seseorang yang membangunkan aplikasi ialah anda boleh menguruskan semuanya sendiri. Dengan menetapkan konfigurasi Ingress, anda boleh menghantar semua trafik yang datang ke API ini dan sedemikian untuk memisahkan bekas yang ditulis, contohnya, dalam Go. Tetapi trafik ini, yang datang ke domain yang sama, tetapi ke URL yang berbeza, harus dihantar ke bekas yang ditulis dalam PHP, di mana terdapat banyak logik, tetapi ia tidak begitu pantas.

Jika kita membandingkan semua konsep ini dengan Nomad, kita boleh mengatakan bahawa tiga konsep pertama semuanya bersama-sama Perkhidmatan. Dan konsep terakhir tiada dalam Nomad itu sendiri. Kami menggunakan pengimbang luaran kerana ia: ia boleh menjadi haproxy, nginx, nginx+ dan sebagainya. Dalam kes kubus, anda tidak perlu memperkenalkan konsep tambahan ini secara berasingan. Walau bagaimanapun, jika anda melihat Ingress secara dalaman, ia adalah sama ada nginx, haproxy atau traefik, tetapi semacam terbina dalam Kubernetes.

Semua konsep yang saya huraikan adalah, sebenarnya, sumber yang wujud dalam kelompok Kubernetes. Untuk menerangkannya dalam kubus, format yaml digunakan, yang lebih mudah dibaca dan biasa daripada fail HCL dalam kes Nomad. Tetapi secara struktur mereka menerangkan perkara yang sama dalam kes, sebagai contoh, pod. Mereka berkata - Saya mahu menggunakan pod itu dan itu di sana, dengan imej itu dan itu, dalam kuantiti itu dan itu.

Di samping itu, kami menyedari bahawa kami tidak mahu mencipta setiap sumber individu dengan tangan: penempatan, perkhidmatan, Ingress, dsb. Sebaliknya, kami ingin menerangkan setiap sistem kami dari segi Kubernetes semasa penggunaan, supaya kami tidak perlu mencipta semula semua kebergantungan sumber yang diperlukan dalam susunan yang betul secara manual. Helm dipilih sebagai sistem yang membolehkan kami melakukan ini.

Konsep asas dalam Helm

Helm adalah pengurus pakej untuk Kubernetes. Ia sangat serupa dengan cara pengurus pakej dalam bahasa pengaturcaraan berfungsi. Mereka membenarkan anda menyimpan perkhidmatan yang terdiri daripada, contohnya, nginx penyebaran, php-fpm, konfigurasi untuk Ingress, configmaps (ini adalah entiti yang membolehkan anda menetapkan env dan parameter lain untuk sistem anda) dalam bentuk so- dipanggil carta. Pada masa yang sama Helm berjalan di atas Kubernetes. Iaitu, ini bukan sejenis sistem yang diketepikan, tetapi hanya perkhidmatan lain yang dilancarkan di dalam kiub. Anda berinteraksi dengannya melalui APInya melalui arahan konsol. Kemudahan dan keindahannya ialah walaupun helm rosak atau anda mengeluarkannya daripada kluster, perkhidmatan anda tidak akan hilang, kerana helm pada dasarnya hanya berfungsi untuk memulakan sistem. Kubernetes sendiri kemudiannya bertanggungjawab ke atas prestasi dan keadaan perkhidmatan.

Kami juga menyedarinya templat, yang sebelum ini kami terpaksa lakukan sendiri dengan memperkenalkan jinja ke dalam konfigurasi kami, adalah salah satu ciri utama helm. Semua konfigurasi yang anda buat untuk sistem anda disimpan dalam helm dalam bentuk templat, sedikit serupa dengan jinja, tetapi, sebenarnya, menggunakan templat bahasa Go, di mana helm ditulis, seperti Kubernetes.

Helm menambah beberapa lagi konsep untuk kami.

Carta - ini ialah perihalan perkhidmatan anda. Dalam pengurus pakej lain ia akan dipanggil pakej, berkas atau sesuatu yang serupa. Di sini ia dipanggil carta.

Nilai-nilai ialah pembolehubah yang anda mahu gunakan untuk membina konfigurasi anda daripada templat.

Lepaskan. Setiap kali perkhidmatan yang digunakan menggunakan helm menerima versi tambahan keluaran. Helm masih ingat apakah konfigurasi perkhidmatan dalam keluaran sebelumnya, keluaran sebelum itu, dan sebagainya. Oleh itu, jika anda perlu membuat undur, jalankan sahaja arahan panggil balik teraju, tunjukkannya ke versi keluaran sebelumnya. Walaupun konfigurasi yang sepadan dalam repositori anda tidak tersedia pada masa rollback, helm masih akan mengingati apa itu dan akan melancarkan semula sistem anda kepada keadaan ia berada dalam keluaran sebelumnya.

Dalam kes apabila kami menggunakan helm, konfigurasi biasa untuk Kubernetes juga bertukar menjadi templat yang membolehkan anda menggunakan pembolehubah, fungsi dan menggunakan pernyataan bersyarat. Dengan cara ini anda boleh mengumpul konfigurasi perkhidmatan anda bergantung pada persekitaran.

Dalam amalan, kami memutuskan untuk melakukan perkara yang sedikit berbeza daripada yang kami lakukan dengan Nomad. Jika dalam Nomad kedua-dua konfigurasi penggunaan dan n-pembolehubah yang diperlukan untuk menggunakan perkhidmatan kami disimpan dalam satu repositori, di sini kami memutuskan untuk membahagikannya kepada dua repositori berasingan. Repositori "deploy" hanya menyimpan pembolehubah-n yang diperlukan untuk penempatan, dan repositori "helm" menyimpan konfigurasi atau carta.

Apa yang diberikan ini kepada kita?

Walaupun pada hakikatnya kami tidak menyimpan sebarang data yang sangat sensitif dalam fail konfigurasi itu sendiri. Sebagai contoh, kata laluan kepada pangkalan data. Ia disimpan sebagai rahsia dalam Kubernetes, tetapi bagaimanapun, masih terdapat perkara tertentu di sana yang kami tidak mahu memberikan akses kepada semua orang. Oleh itu, akses kepada repositori "deploy" adalah lebih terhad, dan repositori "helm" hanya mengandungi perihalan perkhidmatan. Atas sebab ini, ia boleh diakses dengan selamat oleh lebih ramai orang.

Memandangkan kami bukan sahaja mempunyai pengeluaran, tetapi juga persekitaran lain, terima kasih kepada pemisahan ini, kami boleh menggunakan semula carta teraju kami untuk menggunakan perkhidmatan bukan sahaja kepada pengeluaran, tetapi juga, sebagai contoh, kepada persekitaran QA. Malah untuk menggunakan mereka secara tempatan menggunakan Minikube - ini adalah perkara untuk menjalankan Kubernetes secara tempatan.

Di dalam setiap repositori, kami meninggalkan bahagian ke dalam direktori berasingan untuk setiap perkhidmatan. Iaitu, di dalam setiap direktori terdapat templat yang berkaitan dengan carta yang sepadan dan menerangkan sumber yang perlu digunakan untuk melancarkan sistem kami. Kami hanya meninggalkan envs dalam repositori "deploy". Dalam kes ini, kami tidak menggunakan templat menggunakan jinja, kerana helm sendiri menyediakan templat di luar kotak - ini adalah salah satu fungsi utamanya.

Kami meninggalkan skrip penggunaan - deploy.sh, yang memudahkan dan menyeragamkan pelancaran untuk penggunaan menggunakan helm. Jadi, bagi sesiapa sahaja yang ingin menggunakan, antara muka penggunaan kelihatan sama seperti semasa menggunakan Nomad. deploy.sh yang sama, nama perkhidmatan anda dan tempat yang anda mahu gunakan. Ini menyebabkan pucuk pimpinan bermula secara dalaman. Ia, seterusnya, mengumpul konfigurasi daripada templat, memasukkan fail nilai yang diperlukan ke dalamnya, kemudian menggunakannya, melancarkannya ke dalam Kubernetes.

Penemuan

Perkhidmatan Kubernetes nampaknya lebih kompleks daripada Nomad.

Di sini trafik keluar datang ke Ingress. Ini hanyalah pengawal hadapan, yang mengambil alih semua permintaan dan seterusnya menghantarnya ke perkhidmatan yang sepadan dengan data permintaan. Ia menentukannya berdasarkan konfigurasi yang merupakan sebahagian daripada perihalan aplikasi anda yang menerajui dan pembangun yang menetapkan sendiri. Perkhidmatan menghantar permintaan kepada podnya, iaitu, bekas khusus, mengimbangi trafik masuk antara semua bekas yang dimiliki oleh perkhidmatan ini. Dan, sudah tentu, kita tidak boleh lupa bahawa kita tidak sepatutnya pergi ke mana-mana dari keselamatan di peringkat rangkaian. Oleh itu, pembahagian berfungsi dalam gugusan Kubernetes, yang berdasarkan penandaan. Semua perkhidmatan mempunyai teg tertentu yang mana hak akses perkhidmatan kepada sumber luaran/dalaman tertentu di dalam atau di luar kluster dikaitkan.

Semasa kami membuat peralihan, kami melihat bahawa Kubernetes mempunyai semua keupayaan Nomad, yang telah kami gunakan sebelum ini, dan juga menambah banyak perkara baharu. Ia boleh dikembangkan melalui pemalam, dan sebenarnya melalui jenis sumber tersuai. Maksudnya, anda mempunyai peluang bukan sahaja untuk menggunakan sesuatu yang disertakan dengan Kubernetes di luar kotak, tetapi untuk mencipta sumber dan perkhidmatan anda sendiri yang akan membaca sumber anda. Ini memberi anda pilihan tambahan untuk mengembangkan sistem anda tanpa perlu memasang semula Kubernetes dan tanpa memerlukan pengubahsuaian.

Contoh penggunaan sedemikian ialah Prometheus, yang berjalan di dalam kelompok Kubernetes kami. Untuk membolehkannya mula mengumpul metrik daripada perkhidmatan tertentu, kami perlu menambah jenis sumber tambahan, yang dipanggil monitor perkhidmatan, pada perihalan perkhidmatan. Prometheus, disebabkan fakta bahawa ia boleh membaca jenis sumber tersuai apabila dilancarkan dalam Kubernetes, secara automatik mula mengumpul metrik daripada sistem baharu. Ia agak mudah.

Penggunaan pertama yang kami buat ke Kubernetes adalah pada Mac 2018. Dan selama ini kami tidak pernah mengalami sebarang masalah dengannya. Ia berfungsi agak stabil tanpa pepijat yang ketara. Di samping itu, kita boleh mengembangkannya lagi. Hari ini kami mempunyai cukup keupayaan yang dimilikinya, dan kami sangat menyukai kepantasan pembangunan Kubernetes. Pada masa ini, lebih daripada 3000 kontena berada di Kubernetes. Kelompok ini menduduki beberapa Nod. Pada masa yang sama, ia boleh diservis, stabil dan sangat terkawal.

Sumber: www.habr.com