Halo semuanya! Nama saya Pavel Agaletsky. Saya bekerja sebagai pemimpin tim dalam tim yang mengembangkan sistem pengiriman Lamoda. Pada tahun 2018, saya berbicara di konferensi HighLoad ++, dan hari ini saya ingin memperkenalkan transkrip laporan saya.

Topik saya didedikasikan untuk pengalaman perusahaan kami dalam menyebarkan sistem dan layanan ke lingkungan yang berbeda. Mulai dari zaman prasejarah kami, ketika kami mengerahkan semua sistem ke server virtual biasa, berakhir dengan transisi bertahap dari Nomad ke penyebaran ke Kubernetes. Saya akan memberi tahu Anda mengapa kami melakukan ini dan masalah apa yang kami miliki dalam proses.

Menyebarkan aplikasi di VM

Untuk memulainya, 3 tahun yang lalu semua sistem dan layanan perusahaan dikerahkan pada server virtual biasa. Secara teknis, itu diatur sehingga semua kode sistem kami berbaring dan dirakit menggunakan alat membangun otomatis menggunakan jenkins. Dengan Ansible, ia meluncurkan sistem kontrol versi kami ke server virtual. Selain itu, setiap sistem yang ada di perusahaan kami dikerahkan setidaknya pada 2 server: salah satunya - di kepala, yang kedua - di bagian belakang. Kedua sistem ini benar-benar identik satu sama lain dalam semua pengaturan, daya, konfigurasi, dan lainnya. Satu-satunya perbedaan di antara mereka adalah kepala menerima lalu lintas pengguna, sementara ekor tidak pernah menerima lalu lintas pengguna.

Mengapa ini dilakukan?

Ketika kami meluncurkan rilis baru aplikasi kami, kami ingin memberikan kemungkinan peluncuran tanpa batas, yaitu, tanpa konsekuensi nyata bagi pengguna. Ini dicapai karena fakta bahwa rilis berikutnya menggunakan Ansible diluncurkan pada ekor. Di sana, orang-orang yang terlibat dalam penyebaran dapat memeriksa dan memastikan bahwa semuanya baik-baik saja: semua metrik, bagian, dan aplikasi berfungsi; skrip yang diperlukan diluncurkan. Hanya setelah mereka yakin bahwa semuanya baik-baik saja, lalu lintas berubah. Dia mulai pergi ke server yang buntut sebelumnya. Dan yang sebelumnya adalah kepala, dibiarkan tanpa lalu lintas pengguna, sementara dengan versi sebelumnya dari aplikasi kami di atasnya.

Jadi, bagi pengguna itu mulus. Karena switching itu simultan, karena itu hanya switching balancer. Sangat mudah untuk memutar kembali ke versi sebelumnya hanya dengan mengganti penyeimbang kembali. Kami juga dapat memverifikasi kemampuan aplikasi untuk menghasilkan bahkan sebelum lalu lintas pengguna pergi ke sana, yang cukup nyaman.

Apa keuntungan yang kita lihat dalam semua ini?

1. Pertama-tama, ini bekerja cukup sederhana. Semua orang mengerti bagaimana skema penyebaran ini bekerja, karena kebanyakan orang pernah menggunakan server virtual biasa.
2. Ini cukup dapat diandalkan , karena teknologi penyebarannya sederhana, diuji oleh ribuan perusahaan. Jutaan server dikerahkan seperti itu. Sulit untuk memecahkan sesuatu.
3. Dan akhirnya, kami bisa mendapatkan penyebaran atom . Penyebaran yang terjadi pada pengguna secara bersamaan, tanpa tahap yang mencolok untuk beralih antara versi lama dan yang baru.

Namun dalam hal ini kami juga melihat beberapa kekurangan:

1. Selain lingkungan produksi, lingkungan pengembangan, ada lingkungan lain. Misalnya, qa dan praproduksi. Saat itu, kami memiliki banyak server dan sekitar 60 layanan. Untuk alasan ini, setiap layanan perlu mempertahankan versi mesin virtual yang relevan dengannya . Selain itu, jika Anda ingin memperbarui perpustakaan atau menginstal dependensi baru, Anda perlu melakukan ini di semua lingkungan. Itu juga perlu untuk menyinkronkan waktu ketika Anda akan menyebarkan versi baru berikutnya dari aplikasi Anda dengan waktu ketika para devok membuat pengaturan lingkungan yang diperlukan. Dalam hal ini, mudah untuk masuk ke situasi di mana lingkungan kita akan sedikit berbeda sekaligus di semua lingkungan berturut-turut. Misalnya, di lingkungan QA akan ada beberapa versi perpustakaan, dan dalam produksi - yang lain, yang akan menyebabkan masalah.
2. Kesulitan memperbarui dependensi aplikasi Anda. Itu tidak tergantung pada Anda, tetapi pada tim lain. Yaitu, dari perintah devops, yang mendukung server. Anda harus menetapkan tugas yang sesuai untuk mereka dan memberikan deskripsi tentang apa yang ingin Anda lakukan.
3. Pada saat itu, kami juga ingin membagi monolit besar besar yang kami miliki menjadi layanan-layanan kecil yang terpisah, karena kami memahami bahwa akan ada lebih banyak dan lebih banyak lagi. Pada saat itu, kami sudah memiliki lebih dari 100. Itu perlu bagi setiap layanan baru untuk membuat mesin virtual baru yang terpisah, yang juga perlu diservis dan digunakan. Selain itu, Anda tidak perlu satu mobil, tetapi setidaknya dua. Untuk ini, lingkungan QA masih ditambahkan. Ini menyebabkan masalah dan membuat membuat dan meluncurkan sistem baru lebih sulit, mahal dan memakan waktu untuk Anda.

Oleh karena itu, kami memutuskan bahwa akan lebih mudah untuk beralih dari penempatan mesin virtual biasa ke penerapan aplikasi kami dalam wadah buruh pelabuhan. Jika Anda memiliki buruh pelabuhan, Anda memerlukan sistem yang dapat menjalankan aplikasi di cluster, karena Anda tidak bisa hanya mengangkat kontainer. Biasanya Anda ingin melacak berapa banyak kontainer yang dinaikkan sehingga mereka naik secara otomatis. Untuk alasan ini, kami harus memilih sistem kontrol.

Kami sudah lama berpikir tentang mana yang bisa diambil. Faktanya adalah bahwa pada saat itu tumpukan penyebaran ke server virtual biasa agak ketinggalan jaman, karena tidak ada versi terbaru dari sistem operasi di sana. Pada titik tertentu, bahkan FreeBSD berdiri di sana, yang tidak nyaman untuk dipertahankan. Kami memahami bahwa Anda harus bermigrasi ke buruh pelabuhan secepat mungkin. Pengembang kami melihat pengalaman mereka yang ada dengan solusi yang berbeda dan memilih sistem seperti Nomad.

Beralih ke Nomad

Nomad adalah produk HashiCorp. Mereka juga dikenal karena keputusan mereka yang lain:



Konsul adalah alat untuk penemuan layanan.

Terraform adalah sistem manajemen server yang memungkinkan Anda untuk mengonfigurasinya melalui konfigurasi yang disebut infrastructure-as-a-code.

Vagrant memungkinkan Anda untuk menyebarkan mesin virtual secara lokal atau di cloud melalui file konfigurasi tertentu.

Pengembara pada waktu itu sepertinya solusi yang cukup sederhana yang dapat Anda gunakan dengan cepat tanpa mengubah seluruh infrastruktur. Selain itu, cukup mudah dikuasai. Karena itu, kami memilihnya sebagai sistem filter untuk wadah kami.

Apa yang diperlukan untuk sepenuhnya menerapkan sistem Anda ke Nomad?

1. Pertama-tama, Anda memerlukan gambar buruh pelabuhan dari aplikasi Anda. Anda perlu membuatnya dan menyimpannya di penyimpanan gambar buruh pelabuhan. Dalam kasus kami, ini adalah artifactory - sistem yang memungkinkan Anda untuk mendorong berbagai artefak dari berbagai jenis ke dalamnya. Itu dapat menyimpan arsip, gambar buruh pelabuhan, paket komposer PHP, paket NPM, dan sebagainya.
2. Anda juga memerlukan file konfigurasi yang memberi tahu Nomad apa, di mana, dan berapa banyak yang ingin Anda gunakan.

Ketika kita berbicara tentang Nomad, ia menggunakan bahasa HCL sebagai format file informasi, yang merupakan singkatan dari HashiCorp Configuration Language . Ini adalah superset dari Yaml yang memungkinkan Anda untuk menggambarkan layanan Anda dalam hal Nomad.



Hal ini memungkinkan Anda untuk mengatakan berapa banyak wadah yang ingin Anda gunakan, dari gambar mana untuk mentransfer berbagai parameter selama penyebaran. Dengan demikian, Anda memberi makan file Nomad ini, dan meluncurkan kontainer yang diproduksi sesuai dengannya.

Dalam kasus kami, kami menyadari bahwa hanya menulis file HLC yang persis sama dan identik untuk setiap layanan tidak akan nyaman, karena ada banyak layanan dan terkadang Anda ingin memperbaruinya. Itu terjadi bahwa satu layanan dikerahkan bukan dalam satu contoh, tetapi dalam yang paling berbeda. Sebagai contoh, salah satu sistem yang kami miliki dalam produksi memiliki lebih dari 100 contoh dalam produksi. Mereka diluncurkan dari gambar yang sama, tetapi berbeda dalam pengaturan konfigurasi dan file konfigurasi.

Oleh karena itu, kami memutuskan bahwa akan lebih mudah bagi kami untuk menyimpan semua file konfigurasi kami untuk penyebaran dalam satu repositori umum. Dengan demikian, mereka menjadi dapat diamati: mereka mudah dipelihara dan dimungkinkan untuk melihat sistem yang kita miliki. Jika perlu, juga mudah untuk memperbarui atau mengubah sesuatu. Menambahkan sistem baru juga tidak sulit - cukup masukkan file konfigurasi di dalam direktori baru. Di dalamnya ada file: service.hcl, yang berisi deskripsi layanan kami, dan beberapa file env yang memungkinkan layanan ini, yang digunakan dalam produksi, untuk dikonfigurasi.



Namun, beberapa sistem kami ditempatkan di prod tidak dalam satu salinan, tetapi dalam beberapa sekaligus. Oleh karena itu, kami memutuskan bahwa akan lebih mudah bagi kami untuk tidak menyimpan konfigurasi dalam bentuk murni, tetapi bentuk templat mereka. Dan sebagai bahasa template kami memilih jinja 2 . Dalam format ini, kami menyimpan konfigurasi layanan itu sendiri dan file env yang diperlukan untuk itu.

Selain itu, kami menempatkan dalam repositori penyebaran skrip umum untuk semua proyek, yang memungkinkan Anda untuk meluncurkan dan menggunakan layanan Anda dalam produksi, dalam lingkungan yang diinginkan, dalam target yang diinginkan. Dalam kasus ketika kami mengubah HCL-config kami menjadi templat, maka file HCL, yang sebelumnya merupakan konfigurasi Nomad biasa, dalam hal ini mulai terlihat sedikit berbeda.



Yaitu, kami mengganti beberapa variabel dalam file konfigurasi dengan sisipan variabel, yang diambil dari file env atau dari sumber lain. Selain itu, kami dapat mengumpulkan file HL secara dinamis, yaitu, kami tidak hanya dapat menggunakan penyisipan variabel biasa. Karena jinja mendukung loop dan ketentuan, Anda juga dapat membuat file konfigurasi di sana, yang bervariasi tergantung di mana tepatnya Anda menggunakan aplikasi Anda.

Misalnya, Anda ingin menggunakan layanan Anda dalam pra-produksi dan dalam produksi. Misalkan dalam pra-produksi Anda tidak ingin menjalankan skrip mahkota, Anda hanya ingin melihat layanan pada domain terpisah untuk memastikan bahwa itu berfungsi. Bagi siapa pun yang menggunakan layanan, prosesnya terlihat sangat sederhana dan transparan. Cukup menjalankan file deploy.sh, tentukan layanan mana yang ingin Anda gunakan dan target mana. Misalnya, Anda ingin menerapkan sistem tertentu ke Rusia, Belarus atau Kazakhstan. Untuk melakukan ini, cukup ubah salah satu parameter, dan Anda akan memiliki file konfigurasi yang benar.

Ketika layanan Nomad sudah digunakan di cluster Anda, sepertinya ini.



Pertama, Anda membutuhkan penyeimbang di luar yang akan mengambil semua lalu lintas pengguna ke dalamnya. Dia akan bekerja sama dengan Konsul dan mencari tahu darinya di mana, pada simpul mana, pada alamat IP apa ada layanan spesifik yang sesuai dengan nama domain tertentu. Layanan di Konsul berasal dari Nomad itu sendiri. Karena ini adalah produk dari perusahaan yang sama, mereka terhubung dengan baik. Kami dapat mengatakan bahwa Nomad di luar kotak dapat mendaftarkan semua layanan yang diluncurkan di dalamnya di dalam Konsul.

Setelah penyeimbang eksternal Anda mengetahui layanan mana yang diperlukan untuk mengirim lalu lintas, itu mengarahkannya ke wadah yang sesuai atau ke beberapa kontainer yang sesuai dengan aplikasi Anda. Secara alami, perlu juga memikirkan keamanan. Meskipun semua layanan berjalan pada mesin virtual yang sama dalam wadah, ini biasanya memerlukan larangan akses gratis dari layanan apa pun ke layanan lainnya. Kami mencapai ini melalui segmentasi. Setiap layanan diluncurkan di jaringan virtualnya sendiri, di mana aturan perutean dan aturan untuk mengizinkan / menolak akses ke sistem dan layanan lain ditentukan. Mereka bisa berada di dalam cluster ini dan di luarnya. Misalnya, jika Anda ingin mencegah layanan terhubung ke database tertentu, ini dapat dilakukan dengan segmentasi di tingkat jaringan. Artinya, meskipun tidak sengaja, Anda tidak dapat secara tidak sengaja terhubung dari lingkungan pengujian ke basis produksi Anda.

Berapa biaya transisi dalam hal sumber daya manusia?

Transisi seluruh perusahaan ke Nomad memakan waktu sekitar 5-6 bulan. Kami mengganti layanan-kurang, tetapi dengan kecepatan yang cukup cepat. Setiap tim harus membuat wadah sendiri untuk layanan.

Kami telah mengadopsi pendekatan sedemikian rupa sehingga masing-masing tim bertanggung jawab atas gambar buruh pelabuhan dari sistem mereka sendiri. Devops juga menyediakan infrastruktur umum yang diperlukan untuk penyebaran, yaitu dukungan untuk cluster itu sendiri, dukungan untuk sistem CI, dan sebagainya. Dan pada saat itu kami memiliki lebih dari 60 sistem yang dipindahkan ke Nomad, ternyata sekitar 2 ribu kontainer.

Devops bertanggung jawab atas infrastruktur keseluruhan dari segala sesuatu yang terhubung dengan penyebaran, dengan server. Dan masing-masing tim pengembangan, pada gilirannya, bertanggung jawab atas implementasi wadah untuk sistem spesifiknya, karena tim itulah yang mengetahui apa yang umumnya dibutuhkan dalam wadah tertentu.

Alasan untuk meninggalkan Nomad

Apa keuntungan yang kami dapatkan dengan beralih ke menggunakan Nomad dan buruh pelabuhan juga?

1. Kami menyediakan kondisi yang sama untuk semua lingkungan. Dalam perusahaan pengembangan, QA-environment, pra-produksi, produksi, gambar wadah yang sama digunakan, dengan dependensi yang sama. Karenanya, Anda praktis tidak memiliki peluang bahwa produksi akan berubah menjadi berbeda dari apa yang sebelumnya Anda uji secara lokal atau pada lingkungan pengujian.
2. Kami juga menemukan bahwa cukup mudah untuk menambahkan layanan baru . Dari sudut pandang penyebaran, setiap sistem baru diluncurkan dengan sangat sederhana. Cukup pergi ke repositori yang menyimpan konfigurasi, tambahkan konfigurasi berikutnya untuk sistem Anda di sana, dan Anda siap. Anda dapat menggunakan sistem Anda dalam produksi tanpa upaya tambahan dari devops.
3. Semua file konfigurasi dalam satu repositori umum ternyata dipantau . Pada saat itu, ketika kami menyebarkan sistem kami menggunakan server virtual, kami menggunakan Ansible, di mana konfigurasi terletak di repositori yang sama. Namun, untuk sebagian besar pengembang itu sedikit lebih sulit untuk dikerjakan. Di sini volume konfigurasi dan kode yang perlu Anda tambahkan untuk menyebarkan layanan telah menjadi jauh lebih kecil. Plus untuk devops sangat mudah untuk memperbaikinya atau mengubahnya. Dalam kasus transisi, misalnya, pada versi baru Nomad, mereka dapat mengambil dan secara masif memperbarui semua file operasi yang terletak di tempat yang sama.

Namun kami juga menghadapi beberapa kekurangan:

Ternyata kami tidak dapat mencapai penyebaran yang mulus dalam kasus Nomad. Ketika menggulung kontainer dari kondisi yang berbeda, bisa jadi ternyata itu berjalan, dan Nomad menganggapnya sebagai wadah yang siap menerima lalu lintas. Ini terjadi bahkan sebelum aplikasi di dalamnya berhasil dijalankan. Karena alasan ini, sistem untuk waktu yang singkat mulai menghasilkan 500 kesalahan, karena lalu lintas mulai menuju ke wadah, yang belum siap menerimanya.

Kami menemukan beberapa bug . Bug yang paling signifikan adalah bahwa Nomad tidak menerima cluster besar dengan sangat baik jika Anda memiliki banyak sistem dan wadah. Ketika Anda ingin mengambil salah satu server yang termasuk dalam cluster Nomad ke dalam layanan, ada kemungkinan besar bahwa cluster tidak akan merasa sangat baik dan akan berantakan. Bagian dari kontainer mungkin, misalnya, jatuh dan tidak naik - ini selanjutnya akan sangat mahal bagi Anda jika semua sistem produksi Anda terletak di sebuah cluster yang dikelola oleh Nomad.

Karena itu, kami memutuskan untuk memikirkan ke mana harus pergi berikutnya. Pada saat itu, kami menjadi jauh lebih sadar akan apa yang ingin kami capai. Yaitu: kami menginginkan keandalan, sedikit lebih banyak fungsi daripada yang diberikan Nomad, dan sistem yang lebih matang dan lebih stabil.

Dalam hal ini, pilihan kami jatuh pada Kubernetes sebagai platform paling populer untuk meluncurkan cluster. Terutama asalkan ukuran dan jumlah kontainer kami cukup besar. Untuk tujuan seperti itu, Kubernetes tampaknya merupakan sistem yang paling cocok dari yang bisa kita lihat.

Pergi ke Kubernetes

Saya akan berbicara sedikit tentang konsep dasar Kubernet dan bagaimana mereka berbeda dari Nomad.



Pertama-tama, konsep paling mendasar di Kubernetes adalah konsep pod. Pod adalah sekelompok satu atau lebih kontainer yang selalu berjalan bersama. Dan mereka tampaknya selalu bekerja secara ketat pada mesin virtual yang sama. Mereka tersedia satu sama lain melalui IP 127.0.0.1 pada port yang berbeda.

Misalkan Anda memiliki aplikasi PHP yang terdiri dari nginx dan php-fpm - sirkuit klasik. Kemungkinan besar, Anda ingin agar wadah nginx dan php-fpm selalu bersama. Kubernet melakukan ini dengan menggambarkannya sebagai satu pod yang umum. Inilah tepatnya yang tidak bisa kita dapatkan dengan bantuan Nomad.

Konsep kedua adalah penyebaran . Faktanya adalah bahwa pod itu sendiri adalah hal yang fana, dimulai dan menghilang. Apakah Anda ingin membunuh semua kontainer Anda sebelumnya terlebih dahulu, dan kemudian meluncurkan versi baru sekaligus, atau apakah Anda ingin meluncurkannya secara bertahap - ini adalah konsep yang menjadi tanggung jawab penyebaran. Ini menjelaskan bagaimana Anda menggunakan pod Anda, berapa banyak dan bagaimana memperbaruinya.

Konsep ketiga adalah layanan . Layanan Anda sebenarnya adalah sistem Anda, yang menerima beberapa lalu lintas, dan kemudian mengarahkannya ke satu atau lebih pod yang sesuai dengan layanan Anda. Artinya, ini memungkinkan Anda untuk mengatakan bahwa semua lalu lintas masuk ke layanan dengan nama seperti itu harus dikirim ke pod tertentu. Dan pada saat yang sama, ini memberi Anda keseimbangan lalu lintas. Artinya, Anda dapat menjalankan dua pod aplikasi Anda, dan semua lalu lintas masuk akan seimbang antara pod yang terkait dengan layanan ini.

Dan konsep dasar keempat adalah Ingress . Ini adalah layanan yang berjalan di kluster Kubernetes. Ini bertindak sebagai penyeimbang beban eksternal, yang menerima semua permintaan. Karena API, Kubernetes Ingress dapat menentukan ke mana permintaan ini harus dikirim. Dan dia melakukannya dengan sangat fleksibel. Anda dapat mengatakan bahwa semua permintaan ke host ini dan URL tersebut dikirim ke layanan ini. Dan kami mengirim permintaan ini ke host ini dan ke URL lain ke layanan lain.

Hal paling keren dari sudut pandang orang yang mengembangkan aplikasi adalah bahwa Anda dapat mengatur semuanya sendiri. Setelah mengatur konfigurasi Ingress, Anda dapat mengirim semua lalu lintas yang datang ke API tersebut ke wadah terpisah yang terdaftar, misalnya, untuk Go. Tetapi lalu lintas ini datang ke domain yang sama, tetapi ke URL yang berbeda, harus dikirim ke wadah yang ditulis dalam PHP, di mana ada banyak logika, tetapi mereka tidak terlalu cepat.

Jika kita membandingkan semua konsep ini dengan Nomad, maka kita dapat mengatakan bahwa ketiga konsep pertama semuanya bersama-sama Layanan. Dan konsep terakhir dalam Nomad sendiri hilang. Kami menggunakan penyeimbang eksternal seperti itu: bisa berupa haproxy, nginx, nginx + dan sebagainya. Dalam kasus kubus, Anda tidak perlu memperkenalkan konsep tambahan ini secara terpisah. Namun, jika Anda melihat Ingress di dalam, maka itu adalah nginx, atau haproxy, atau traefik, tetapi seolah-olah dibangun ke dalam Kubernetes.

Semua konsep yang saya jelaskan pada dasarnya adalah sumber daya yang ada di dalam cluster Kubernetes. Untuk menggambarkan mereka dalam sebuah kubus, format yaml digunakan, yang lebih mudah dibaca dan akrab daripada file HCl dalam kasus Nomad. Tetapi secara struktural mereka menggambarkan dalam kasus, misalnya, pod hal yang sama. Mereka berkata - Saya ingin menyebarkan pod ini dan itu di sana-sini, dengan gambar ini dan itu, dalam jumlah ini dan itu.



Selain itu, kami menyadari bahwa kami tidak ingin membuat setiap sumber daya individu dengan tangan kami sendiri: penyebaran, layanan, Ingress, dan banyak lagi. Sebagai gantinya, kami ingin menggambarkan setiap sistem yang dikerahkan dalam hal Kubernet selama penyebaran, sehingga kami tidak perlu secara manual membuat ulang semua dependensi sumber daya yang diperlukan dalam urutan yang benar. Helm dipilih sebagai sistem yang memungkinkan kami melakukan ini.

Konsep Kunci di Helm

Helm adalah manajer paket untuk Kubernetes. Ini sangat mirip dengan bagaimana manajer paket bekerja dalam bahasa pemrograman. Mereka memungkinkan Anda untuk menyimpan layanan yang terdiri dari, misalnya, penempatan nginx, penerapan php-fpm, konfigurasi untuk Ingress, configmaps (ini adalah entitas yang memungkinkan Anda untuk mengatur env dan parameter lain untuk sistem Anda) dalam bentuk apa yang disebut grafik. Pada saat yang sama, Helm berjalan di atas Kubernetes . Artinya, ini bukan semacam sistem yang berdiri di samping, tetapi hanya layanan lain yang berjalan di dalam kubus. Anda berinteraksi dengannya melalui API-nya melalui perintah konsol. Kemudahan dan daya tariknya adalah bahwa meskipun helm rusak atau Anda lepaskan dari cluster, layanan Anda tidak akan hilang, karena helm pada dasarnya hanya berfungsi untuk memulai sistem. Kubernetes sendiri bertanggung jawab atas waktu aktif dan kondisi layanan.

Kami juga menyadari bahwa standardisasi , yang sebelumnya harus dilakukan secara independen melalui pengenalan jinja di konfigurasi kami, adalah salah satu fitur utama dari helm. Semua konfigurasi yang Anda buat untuk sistem Anda disimpan dalam helm dalam bentuk template yang mirip dengan jinja, tetapi, pada kenyataannya, menggunakan templat bahasa Go yang menggunakan helm, seperti Kubernetes.

Helm menambahkan beberapa konsep tambahan kepada kami.

Bagan adalah deskripsi layanan Anda. Manajer paket lain akan menyebutnya paket, bundel, atau sesuatu seperti itu. Ini disebut bagan di sini.

Nilai adalah variabel yang ingin Anda gunakan untuk membangun konfigurasi dari template.

Lepaskan. Setiap kali layanan yang dikerahkan menggunakan helm menerima versi tambahan dari rilis. Helm ingat apa konfigurasi layanan pada tahun sebelumnya, tahun sebelum rilis terakhir, dan sebagainya. Oleh karena itu, jika Anda perlu memutar kembali, jalankan saja perintah callback helm, yang menunjukkan versi rilis sebelumnya. Bahkan jika pada saat rollback konfigurasi yang sesuai di repositori Anda tidak tersedia, helm masih mengingat apa itu dan memutar kembali sistem Anda ke keadaan seperti pada rilis sebelumnya.

Dalam kasus ketika kita menggunakan helm, konfigurasi biasa untuk Kubernetes juga berubah menjadi templat, di mana dimungkinkan untuk menggunakan variabel, fungsi, menerapkan operator bersyarat. Dengan demikian, Anda dapat mengumpulkan konfigurasi layanan Anda tergantung pada lingkungan.



Dalam praktiknya, kami memutuskan untuk melakukan sedikit berbeda dari yang kami lakukan dalam kasus Nomad. Jika dalam Nomad dalam repositori yang sama konfigurasi untuk penyebaran dan n-variabel yang diperlukan untuk menyebarkan layanan kami disimpan, di sini kami memutuskan untuk membaginya menjadi dua repositori terpisah. Hanya n-variabel yang diperlukan untuk penyebaran disimpan di repositori deploy, dan konfigurasi atau grafik disimpan di repositori helm.



Apa yang memberi kita?

Terlepas dari kenyataan bahwa kami tidak menyimpan data yang benar-benar sensitif dalam file konfigurasi itu sendiri. Misalnya, kata sandi basis data. Mereka disimpan sebagai rahasia di Kubernetes, namun demikian, masih ada beberapa hal di sana yang kami tidak ingin memberikan akses kepada semua orang secara berturut-turut. Oleh karena itu, akses ke repositori deploy lebih terbatas, dan repositori helm hanya berisi deskripsi layanan. Karena alasan ini, dimungkinkan untuk memberikan akses ke lingkaran orang yang lebih besar dengan aman.

Karena kami tidak hanya memiliki produksi, tetapi juga lingkungan lain, berkat pemisahan ini, kami dapat menggunakan kembali bagan helm kami untuk menggunakan layanan tidak hanya dalam produksi, tetapi juga, misalnya, dalam lingkungan QA. Bahkan untuk menyebarkannya secara lokal menggunakan Minikube adalah hal seperti itu untuk menjalankan Kubernetes secara lokal.

Di dalam setiap repositori, kami meninggalkan pemisahan ke direktori terpisah untuk setiap layanan. Yaitu, di dalam setiap direktori terdapat template yang terkait dengan bagan yang sesuai dan menggambarkan sumber daya yang perlu digunakan untuk meluncurkan sistem kami. Di repositori deploy, kami hanya meninggalkan enves. Dalam hal ini, kami tidak menggunakan templating dengan jinja, karena helm itu sendiri memberikan templating di luar kotak - ini adalah salah satu fungsi utamanya.

Kami meninggalkan skrip penyebaran, deploy.sh, yang menyederhanakan dan menstandarkan peluncuran untuk penyebaran menggunakan helm. Jadi, bagi siapa saja yang ingin menggunakan, antarmuka penyebaran terlihat persis sama seperti dalam penyebaran melalui Nomad. Deploy.sh yang sama, nama layanan Anda, dan tempat Anda ingin menyebarkannya. Ini menyebabkan helm mulai masuk ke dalam. Dia, pada gilirannya, mengumpulkan konfigurasi dari template, menggantikan nilai-file yang diperlukan di dalamnya, kemudian menyebarkan, menempatkannya ke dalam Kubernetes.

Kesimpulan

Layanan Kubernetes terlihat lebih kompleks daripada Nomad.



Di sinilah lalu lintas keluar datang ke Ingress. Ini hanya pengontrol depan, yang menerima semua permintaan dan kemudian mengirimkannya ke layanan yang sesuai dengan data permintaan. Ini mendefinisikan mereka berdasarkan konfigurasi, yang merupakan bagian dari deskripsi aplikasi Anda di helm dan yang ditetapkan pengembang secara independen. Layanan mengirim permintaan ke podnya, yaitu, wadah khusus, menyeimbangkan lalu lintas masuk di antara semua kontainer yang termasuk dalam layanan ini. Yah, tentu saja, jangan lupa bahwa kita tidak boleh pergi ke mana pun dari keamanan di tingkat jaringan. Oleh karena itu, kluster Kubernetes mengoperasikan segmentasi, yang didasarkan pada penandaan. Semua layanan memiliki tag tertentu, di mana hak akses layanan ke sumber daya eksternal / internal tertentu dilampirkan di dalam atau di luar cluster.

Ketika menyelesaikan transisi, kami melihat bahwa Kubernetes memiliki semua fitur Nomad, yang kami gunakan sebelumnya, dan juga menambahkan banyak hal baru. Itu dapat diperluas melalui plugin, dan pada kenyataannya melalui tipe sumber daya kustom. Artinya, Anda memiliki kesempatan tidak hanya untuk menggunakan sesuatu yang masuk ke Kubernetes di luar kotak, tetapi untuk membuat sumber daya dan layanan Anda sendiri yang akan membaca sumber daya Anda. Ini memberikan opsi tambahan untuk memperluas sistem Anda tanpa perlu menginstal ulang Kubernetes dan tanpa perlu perubahan.

Contohnya adalah Prometheus, yang berjalan di dalam kluster Kubernet kami. Agar dia mulai mengumpulkan metrik dari layanan tertentu, kita perlu menambahkan jenis sumber daya tambahan, yang disebut monitor layanan, ke deskripsi layanan. Prometheus, karena dapat dibaca, diluncurkan di Kubernetes, jenis sumber daya khusus, secara otomatis mulai mengumpulkan metrik dari sistem baru. Cukup nyaman.

Penempatan pertama yang kami lakukan di Kubernetes adalah pada bulan Maret 2018. Dan selama ini kami tidak pernah mengalami masalah dengannya. Ini bekerja cukup stabil tanpa bug yang signifikan. Selain itu, kami dapat mengembangkannya lebih lanjut. Saat ini, kami memiliki cukup banyak peluang yang dimiliki, dan kami sangat menyukai langkah pengembangan Kubernetes. Saat ini, lebih dari 3.000 kontainer berada di Kubernetes. Cluster mengambil beberapa Node. Pada saat yang sama, dilayani, stabil dan sangat terkontrol.