Halo semua! 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 menyajikan transkrip laporan saya.

Topik saya didedikasikan untuk pengalaman perusahaan kami dalam menerapkan sistem dan layanan ke lingkungan yang berbeda. Dimulai dari zaman prasejarah, ketika kami menerapkan semua sistem ke server virtual biasa, diakhiri dengan transisi bertahap dari Nomad ke penerapan di Kubernetes. Saya akan memberi tahu Anda mengapa kami melakukannya dan masalah apa yang kami hadapi dalam prosesnya.

Menyebarkan aplikasi ke VM

Mari kita mulai dengan fakta bahwa 3 tahun yang lalu semua sistem dan layanan perusahaan dikerahkan ke server virtual biasa. Secara teknis, ini diatur sedemikian rupa sehingga semua kode untuk sistem kami disimpan dan dirakit menggunakan alat perakitan otomatis, menggunakan jenkins. Menggunakan Ansible, ini diluncurkan dari sistem kontrol versi kami ke server virtual. Selain itu, setiap sistem yang dimiliki perusahaan kami dikerahkan ke setidaknya 2 server: salah satunya di kepala, yang kedua di bagian ekor. Kedua sistem ini benar-benar identik satu sama lain dalam semua pengaturan, daya, konfigurasi, dll. Satu-satunya perbedaan di antara keduanya adalah head menerima lalu lintas pengguna, sedangkan tail tidak pernah menerima lalu lintas pengguna.

Untuk apa itu?

Saat kami menerapkan rilis baru aplikasi kami, kami ingin memastikan peluncuran yang lancar, tanpa konsekuensi nyata bagi pengguna. Hal ini dicapai karena fakta bahwa rilis terkompilasi berikutnya menggunakan Ansible diluncurkan secara bertahap. Di sana, orang-orang yang terlibat dalam penerapan dapat memeriksa dan memastikan semuanya baik-baik saja: semua metrik, bagian, dan aplikasi berfungsi; skrip yang diperlukan diluncurkan. Baru setelah mereka yakin semuanya baik-baik saja, lalu lintas dialihkan. Itu mulai masuk ke server yang sebelumnya berekor. Dan yang sebelumnya menjadi kepala tetap tanpa lalu lintas pengguna, sementara masih memiliki versi aplikasi kita sebelumnya di dalamnya.

Jadi itu mulus bagi pengguna. Karena saklarnya bersifat seketika, karena ini hanyalah saklar penyeimbang. Anda dapat dengan mudah memutar kembali ke versi sebelumnya hanya dengan mengganti penyeimbang kembali. Kami juga dapat memverifikasi bahwa aplikasi tersebut mampu berproduksi bahkan sebelum menerima lalu lintas pengguna, dan hal ini cukup memudahkan.

Keuntungan apa yang kita lihat dari semua ini?

1. Pertama-tama, itu sudah cukup itu hanya berhasil. Semua orang memahami cara kerja skema penerapan seperti itu, karena kebanyakan orang pernah menerapkannya ke server virtual biasa.
2. Ini cukup andal, karena teknologi penerapannya sederhana, telah diuji oleh ribuan perusahaan. Jutaan server dikerahkan dengan cara ini. Sulit untuk memecahkan sesuatu.
3. Dan akhirnya kita bisa mendapatkannya penyebaran atom. Penerapan yang terjadi secara bersamaan bagi pengguna, tanpa adanya tahap peralihan yang nyata antara versi lama dan versi baru.

Namun kami juga melihat beberapa kekurangan dalam semua ini:

1. Selain lingkungan produksi, lingkungan pengembangan, ada lingkungan lainnya. Misalnya, qa dan praproduksi. Saat itu kami memiliki banyak server dan sekitar 60 layanan. Untuk alasan ini, hal ini diperlukan untuk setiap layanan, pertahankan versi terbarunya mesin virtual. Selain itu, jika Anda ingin memperbarui perpustakaan atau menginstal dependensi baru, Anda perlu melakukan ini di semua lingkungan. Anda juga perlu menyinkronkan waktu saat Anda akan menerapkan versi baru aplikasi Anda berikutnya dengan waktu saat devops melakukan pengaturan lingkungan yang diperlukan. Dalam hal ini, mudah untuk masuk ke situasi di mana lingkungan kita akan berbeda di semua lingkungan sekaligus. Misalnya, di lingkungan QA akan ada beberapa versi perpustakaan, dan di lingkungan produksi akan ada versi berbeda, yang akan menimbulkan masalah.
2. Kesulitan memperbarui dependensi aplikasi Anda. Itu tidak bergantung pada Anda, tetapi pada tim lain. Yakni dari tim devops yang memelihara servernya. Anda harus memberi mereka tugas yang sesuai dan penjelasan tentang apa yang ingin Anda lakukan.
3. Pada saat itu, kami juga ingin membagi monolit besar yang kami miliki menjadi layanan-layanan kecil yang terpisah, karena kami memahami bahwa akan ada lebih banyak lagi. Saat itu, kami sudah memiliki lebih dari 100. Untuk setiap layanan baru, perlu dibuat mesin virtual baru yang terpisah, yang juga perlu dipelihara dan diterapkan. Selain itu, Anda tidak memerlukan satu mobil, tetapi setidaknya dua. Ditambah dengan semua ini adalah lingkungan QA. Hal ini menyebabkan masalah dan mempersulit Anda membangun dan menjalankan sistem baru. proses yang rumit, mahal dan panjang.

Oleh karena itu, kami memutuskan bahwa akan lebih mudah untuk beralih dari penerapan mesin virtual biasa ke penerapan aplikasi kami dalam wadah buruh pelabuhan. Jika Anda memiliki buruh pelabuhan, Anda memerlukan sistem yang dapat menjalankan aplikasi dalam sebuah cluster, karena Anda tidak bisa begitu saja membesarkan sebuah container. Biasanya Anda ingin melacak berapa banyak kontainer yang diangkat agar terangkat secara otomatis. Untuk alasan ini, kami perlu memilih sistem kontrol.

Kami sudah lama memikirkan mana yang bisa kami ambil. Faktanya adalah bahwa pada saat itu tumpukan penerapan pada server virtual biasa sudah agak ketinggalan jaman, karena mereka tidak memiliki sistem operasi versi terbaru. Pada titik tertentu, bahkan ada FreeBSD, yang dukungannya tidak terlalu nyaman. Kami memahami bahwa kami perlu bermigrasi ke buruh pelabuhan secepat mungkin. Pengembang kami melihat pengalaman mereka saat ini dengan solusi berbeda dan memilih sistem seperti Nomad.

Beralih ke Pengembara

Nomad adalah produk HashiCorp. Mereka juga dikenal dengan solusi lainnya:

"Konsul" adalah alat untuk penemuan layanan.

"Terraform" - sistem untuk mengelola server yang memungkinkan Anda mengonfigurasinya melalui konfigurasi, yang disebut infrastruktur sebagai kode.

"Gelandangan" memungkinkan Anda menyebarkan mesin virtual secara lokal atau di cloud melalui file konfigurasi tertentu.

Nomad pada saat itu tampak seperti solusi yang cukup sederhana yang dapat dengan cepat dialihkan tanpa mengubah seluruh infrastruktur. Selain itu, cara mempelajarinya pun cukup mudah. Itu sebabnya kami memilihnya sebagai sistem filtrasi untuk wadah kami.

Apa yang Anda perlukan untuk menerapkan sistem Anda ke Nomad?

1. Pertama-tama, Anda perlu gambar buruh pelabuhan aplikasi Anda. Anda perlu membangunnya dan menempatkannya di repositori image buruh pelabuhan. Dalam kasus kami, ini adalah artefakori - sistem yang memungkinkan Anda memasukkan berbagai jenis artefak ke dalamnya. Itu dapat menyimpan arsip, gambar buruh pelabuhan, paket komposer PHP, paket NPM, dan sebagainya.
2. Juga dibutuhkan file konfigurasi, yang akan memberi tahu Nomad apa, di mana, dan dalam jumlah berapa yang ingin Anda terapkan.

Ketika kita berbicara tentang Nomad, ia menggunakan bahasa HCL sebagai format file informasinya, yang merupakan singkatan dari Bahasa Konfigurasi HashiCorp. Ini adalah superset dari Yaml yang memungkinkan Anda mendeskripsikan layanan Anda dalam istilah Nomad.

Ini memungkinkan Anda mengatakan berapa banyak kontainer yang ingin Anda terapkan, dari gambar mana yang akan meneruskan berbagai parameter ke kontainer tersebut selama penerapan. Jadi, Anda memasukkan file ini ke Nomad, dan ia meluncurkan kontainer ke dalam produksi sesuai dengan file tersebut.

Dalam kasus kami, kami menyadari bahwa menulis file HCL yang benar-benar identik untuk setiap layanan tidak akan nyaman, karena ada banyak layanan dan terkadang Anda ingin memperbaruinya. Kebetulan satu layanan dikerahkan tidak dalam satu contoh, tetapi dalam berbagai layanan yang berbeda. Misalnya, salah satu sistem yang kami miliki dalam produksi memiliki lebih dari 100 instance dalam produksi. Mereka dijalankan 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 untuk penerapan dalam satu repositori umum. Dengan cara ini mereka terlihat: mudah dirawat dan kami dapat melihat sistem apa yang kami miliki. Jika perlu, mudah juga untuk memperbarui atau mengubah sesuatu. Menambahkan sistem baru juga tidak sulit - Anda hanya perlu membuat file konfigurasi di dalam direktori baru. Di dalamnya terdapat file berikut: 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 diterapkan dalam produksi bukan dalam satu salinan, tetapi dalam beberapa salinan sekaligus. Oleh karena itu, kami memutuskan bahwa akan lebih mudah bagi kami untuk menyimpan bukan konfigurasi dalam bentuk aslinya, tetapi dalam bentuk templatnya. Dan kami memilih jinja 2. Dalam format ini, kami menyimpan konfigurasi layanan itu sendiri dan file env yang diperlukan untuk itu.

Selain itu, kami telah menempatkan di repositori skrip penerapan yang umum untuk semua proyek, yang memungkinkan Anda meluncurkan dan menerapkan layanan Anda ke dalam produksi, ke lingkungan yang diinginkan, ke target yang diinginkan. Jika kita mengubah konfigurasi HCL menjadi template, maka file HCL, yang sebelumnya merupakan konfigurasi Nomad biasa, dalam hal ini mulai terlihat sedikit berbeda.

Artinya, kami mengganti beberapa variabel lokasi konfigurasi dengan variabel sisipan yang diambil dari file env atau sumber lain. Selain itu, kami mendapat kesempatan untuk mengumpulkan file HCL secara dinamis, yaitu kami tidak hanya dapat menggunakan penyisipan variabel biasa. Karena jinja mendukung loop dan kondisi, Anda juga dapat membuat file konfigurasi di sana, yang berubah tergantung di mana tepatnya Anda menyebarkan aplikasi Anda.

Misalnya, Anda ingin menerapkan layanan Anda ke praproduksi dan produksi. Katakanlah dalam pra-produksi Anda tidak ingin menjalankan skrip cron, tetapi hanya ingin melihat layanan di domain terpisah untuk memastikan layanan tersebut berfungsi. Bagi siapa pun yang menerapkan layanan ini, prosesnya terlihat sangat sederhana dan transparan. Yang perlu Anda lakukan hanyalah menjalankan file deploy.sh, tentukan layanan mana yang ingin Anda terapkan dan ke target mana. Misalnya, Anda ingin menerapkan sistem tertentu ke Rusia, Belarusia, atau Kazakhstan. Untuk melakukan ini, cukup ubah salah satu parameter, dan Anda akan mendapatkan file konfigurasi yang benar.

Ketika layanan Nomad sudah disebarkan ke cluster Anda, tampilannya seperti ini.

Pertama, Anda memerlukan semacam penyeimbang di luar, yang akan menerima semua lalu lintas pengguna. Ini akan bekerja sama dengan Konsul dan mencari tahu di mana, di node mana, di alamat IP apa layanan tertentu berada yang sesuai dengan nama domain tertentu. Pelayanan di Consul berasal dari Nomad sendiri. Karena ini adalah produk dari perusahaan yang sama, maka keduanya cukup terkait satu sama lain. Kita dapat mengatakan bahwa Nomad dapat mendaftarkan semua layanan yang diluncurkan di dalamnya di dalam Konsul.

Setelah penyeimbang beban front-end Anda mengetahui ke layanan mana lalu lintas akan dikirim, lalu lintas akan diteruskan ke kontainer yang sesuai atau beberapa kontainer yang cocok dengan aplikasi Anda. Tentu saja, keselamatan juga perlu dipikirkan. Meskipun semua layanan berjalan pada mesin virtual yang sama dalam container, hal ini biasanya memerlukan pencegahan akses bebas dari layanan apa pun ke layanan lainnya. Kami mencapai ini melalui segmentasi. Setiap layanan diluncurkan di jaringan virtualnya sendiri, yang menetapkan aturan perutean dan aturan untuk mengizinkan/menolak akses ke sistem dan layanan lain. Mereka dapat ditempatkan baik di dalam cluster ini maupun di luarnya. Misalnya, jika Anda ingin mencegah layanan tersambung ke database tertentu, hal ini dapat dilakukan melalui segmentasi tingkat jaringan. Artinya, bahkan secara tidak sengaja, Anda tidak dapat terhubung secara tidak sengaja dari lingkungan pengujian ke database produksi Anda.

Berapa besar kerugian yang ditimbulkan oleh transisi ini dalam hal sumber daya manusia?

Transisi seluruh perusahaan ke Nomad memakan waktu sekitar 5-6 bulan. Kami berpindah berdasarkan layanan demi layanan, tetapi dengan kecepatan yang cukup cepat. Setiap tim harus membuat wadahnya sendiri untuk layanan tersebut.

Kami telah mengadopsi pendekatan sedemikian rupa sehingga setiap tim bertanggung jawab atas image buruh pelabuhan di sistem mereka secara independen. Devops menyediakan infrastruktur umum yang diperlukan untuk penerapan, yaitu dukungan untuk cluster itu sendiri, dukungan untuk sistem CI, dan sebagainya. Dan saat itu, kami memiliki lebih dari 60 sistem yang dipindahkan ke Nomad, yang berjumlah sekitar 2 ribu kontainer.

Devops bertanggung jawab atas infrastruktur umum segala sesuatu yang berkaitan dengan penerapan dan server. Dan setiap tim pengembangan, pada gilirannya, bertanggung jawab untuk mengimplementasikan container untuk sistem spesifiknya, karena timlah yang mengetahui apa yang umumnya dibutuhkan dalam container tertentu.

Alasan meninggalkan Nomad

Keuntungan apa yang kami peroleh dengan beralih ke penerapan antara lain menggunakan Nomad dan buruh pelabuhan?

1. Kita diberikan kondisi yang sama untuk semua lingkungan. Dalam pengembangan, lingkungan QA, pra-produksi, produksi, gambar kontainer yang sama digunakan, dengan ketergantungan yang sama. Oleh karena itu, Anda hampir tidak memiliki peluang bahwa apa yang akan dihasilkan dalam produksi bukanlah apa yang sebelumnya Anda uji secara lokal atau di lingkungan pengujian Anda.
2. Kami juga menemukan bahwa itu sudah cukup mudah untuk menambahkan layanan baru. Dari sudut pandang penerapan, setiap sistem baru diluncurkan dengan sangat sederhana. Buka saja repositori yang menyimpan konfigurasi, tambahkan konfigurasi lain untuk sistem Anda di sana, dan Anda sudah siap. Anda dapat menerapkan sistem Anda ke produksi tanpa upaya tambahan apa pun dari pengembang.
3. semua file konfigurasi dalam satu repositori umum ternyata sedang dalam peninjauan. Saat kami menerapkan sistem kami menggunakan server virtual, kami menggunakan Ansible, yang konfigurasinya berada di repositori yang sama. Namun, bagi sebagian besar pengembang, hal ini sedikit lebih sulit untuk dikerjakan. Di sini volume konfigurasi dan kode yang perlu Anda tambahkan untuk menerapkan layanan menjadi jauh lebih kecil. Selain itu, sangat mudah bagi pengembang untuk memperbaiki atau mengubahnya. Dalam hal transisi, misalnya, ke versi baru Nomad, mereka dapat mengambil dan memperbarui secara massal semua file operasi yang terletak di tempat yang sama.

Namun kami juga menemui beberapa kelemahan:

Ternyata kita tidak dapat mencapai penerapan yang mulus dalam kasus Pengembara. Saat meluncurkan kontainer dalam kondisi yang berbeda, kontainer tersebut bisa saja berjalan, dan Nomad menganggapnya sebagai kontainer yang siap menerima lalu lintas. Ini terjadi bahkan sebelum aplikasi di dalamnya sempat diluncurkan. Oleh karena itu, sistem mulai menghasilkan 500 kesalahan dalam waktu singkat, karena lalu lintas mulai menuju ke kontainer yang belum siap menerimanya.

Kami menemui beberapa oleh rawa-rawa. Bug yang paling signifikan adalah Nomad tidak menangani cluster besar dengan baik jika Anda memiliki banyak sistem dan container. Saat Anda ingin mengeluarkan salah satu server yang termasuk dalam cluster Nomad untuk pemeliharaan, ada kemungkinan yang cukup tinggi bahwa cluster tersebut tidak akan terasa enak dan akan berantakan. Beberapa kontainer mungkin, misalnya, jatuh dan tidak naik - ini akan sangat merugikan Anda nantinya jika semua sistem produksi Anda berlokasi di cluster yang dikelola oleh Nomad.

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

Dalam hal ini, pilihan kami jatuh pada Kubernetes sebagai platform paling populer untuk meluncurkan cluster. Apalagi mengingat ukuran dan jumlah container kami yang cukup besar. Untuk tujuan tersebut, Kubernetes tampaknya merupakan sistem yang paling cocok untuk kami pertimbangkan.

Transisi ke Kubernetes

Saya akan bercerita sedikit tentang konsep dasar Kubernetes dan perbedaannya dengan Nomad.

Pertama-tama, konsep paling dasar di Kubernetes adalah konsep pod. Polong adalah sekelompok satu atau lebih container yang selalu berjalan bersama. Dan mereka selalu bekerja seolah-olah hanya pada satu mesin virtual. Mereka dapat diakses 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 - skema klasik. Kemungkinan besar, Anda ingin menyimpan container nginx dan php-fpm secara bersamaan. Kubernetes memungkinkan Anda mencapai hal ini dengan mendeskripsikannya sebagai satu pod umum. Inilah yang tidak bisa kami dapatkan dengan Nomad.

Konsep kedua adalah penyebaran. Faktanya adalah bahwa pod itu sendiri adalah sesuatu yang fana; ia mulai dan menghilang. Apakah Anda ingin menghentikan semua container sebelumnya, lalu meluncurkan versi baru sekaligus, atau Anda ingin meluncurkannya secara bertahap? Ini adalah proses yang menjadi tanggung jawab konsep penerapan. Ini menjelaskan bagaimana Anda men-deploy pod Anda, berapa jumlahnya, dan bagaimana cara mengupdatenya.

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

Dan konsep dasar yang keempat adalah Jalan masuk. Ini adalah layanan yang berjalan pada cluster Kubernetes. Ini bertindak sebagai penyeimbang beban eksternal yang mengambil alih semua permintaan. Dengan menggunakan API Kubernetes, Ingress dapat menentukan ke mana permintaan ini harus dikirim. Selain itu, dia melakukannya dengan sangat fleksibel. Anda dapat mengatakan bahwa semua permintaan ke host ini dan URL ini dan itu dikirim ke layanan ini. Dan permintaan yang datang ke host ini dan ke URL lain dikirim ke layanan lain.

Hal paling keren dari sudut pandang seseorang yang mengembangkan aplikasi adalah Anda mampu mengelola semuanya sendiri. Dengan mengatur konfigurasi Ingress, Anda dapat mengirim semua lalu lintas yang datang ke API ini dan itu ke wadah terpisah yang ditulis, misalnya, di Go. Namun lalu lintas ini, yang datang ke domain yang sama, tetapi ke URL yang berbeda, harus dikirim ke wadah yang ditulis dalam PHP, yang memiliki banyak logika, tetapi tidak terlalu cepat.

Jika kita membandingkan semua konsep ini dengan Nomad, kita dapat mengatakan bahwa tiga konsep pertama semuanya adalah Layanan. Dan konsep terakhir tidak ada pada Nomad sendiri. Kami menggunakan penyeimbang eksternal: bisa berupa haproxy, nginx, nginx+, dan sebagainya. Dalam kasus kubus, Anda tidak perlu memperkenalkan konsep tambahan ini secara terpisah. Namun, jika Anda melihat Ingress secara internal, itu adalah nginx, haproxy, atau traefik, tetapi dibangun di dalam Kubernetes.

Semua konsep yang saya jelaskan sebenarnya adalah sumber daya yang ada di dalam cluster Kubernetes. Untuk mendeskripsikannya dalam kubus, format yaml digunakan, yang lebih mudah dibaca dan familiar dibandingkan file HCL dalam kasus Nomad. Namun secara struktural mereka menggambarkan hal yang sama dalam kasus, misalnya, pod. Mereka berkata - Saya ingin menyebarkan pod ini dan itu di sana, dengan gambar ini dan itu, dalam jumlah ini dan itu.

Selain itu, kami menyadari bahwa kami tidak ingin membuat masing-masing sumber daya secara manual: penerapan, layanan, Ingress, dll. Sebaliknya, kami ingin mendeskripsikan masing-masing sistem kami dalam istilah Kubernetes selama penerapan, sehingga kami tidak perlu membuat ulang semua dependensi sumber daya yang diperlukan secara manual dalam urutan yang benar. Helm dipilih sebagai sistem yang memungkinkan kami melakukan hal ini.

Konsep dasar di Helm

Helmnya adalah manajer paket untuk Kubernetes. Ini sangat mirip dengan cara kerja manajer paket dalam bahasa pemrograman. Mereka memungkinkan Anda untuk menyimpan layanan yang terdiri dari, misalnya, penerapan nginx, penerapan php-fpm, konfigurasi untuk Ingress, configmaps (ini adalah entitas yang memungkinkan Anda menyetel env dan parameter lain untuk sistem Anda) dalam bentuk seperti ini. disebut grafik. Pada saat yang sama Helm berjalan di atas Kubernetes. Artinya, ini bukan semacam sistem yang berdiri sendiri, tetapi hanyalah layanan lain yang diluncurkan di dalam kubus. Anda berinteraksi dengannya melalui API-nya melalui perintah konsol. Kenyamanan dan keindahannya adalah meskipun helm rusak atau Anda menghapusnya dari cluster, layanan Anda tidak akan hilang, karena helm pada dasarnya hanya berfungsi untuk memulai sistem. Kubernetes sendiri kemudian bertanggung jawab atas kinerja dan status layanan.

Kami juga menyadari hal itu templateisasi, yang sebelumnya terpaksa kami lakukan sendiri dengan memasukkan jinja ke dalam konfigurasi kami, adalah salah satu fitur utama helm. Semua konfigurasi yang Anda buat untuk sistem Anda disimpan di helm dalam bentuk template, sedikit mirip dengan jinja, tetapi sebenarnya menggunakan template bahasa Go, di mana helm ditulis, seperti Kubernetes.

Helm menambahkan beberapa konsep lagi untuk kami.

Grafik - ini adalah deskripsi layanan Anda. Di pengelola paket lain, ini akan disebut paket, bundel, atau yang serupa. Di sini disebut grafik.

Nilai - Nilai adalah variabel yang ingin Anda gunakan untuk membuat konfigurasi dari templat.

Lepaskan. Setiap kali layanan yang disebarkan menggunakan helm menerima versi rilis tambahan. Helm mengingat konfigurasi layanan pada rilis sebelumnya, rilis sebelumnya, dan seterusnya. Oleh karena itu, jika Anda perlu melakukan rollback, jalankan saja perintah helm callback, arahkan ke versi rilis sebelumnya. Bahkan jika konfigurasi yang sesuai di repositori Anda tidak tersedia pada saat rollback, helm akan tetap mengingatnya dan akan mengembalikan sistem Anda ke keadaan pada rilis sebelumnya.

Jika kita menggunakan helm, konfigurasi reguler untuk Kubernetes juga berubah menjadi template yang memungkinkan untuk menggunakan variabel, fungsi, dan menerapkan pernyataan kondisional. Dengan cara ini Anda dapat mengumpulkan konfigurasi layanan Anda tergantung pada lingkungan.

Dalam praktiknya, kami memutuskan untuk melakukan sesuatu yang sedikit berbeda dibandingkan dengan Nomad. Jika di Nomad konfigurasi penerapan dan n-variabel yang diperlukan untuk menerapkan layanan kami disimpan dalam satu repositori, di sini kami memutuskan untuk membaginya menjadi dua repositori terpisah. Repositori “deploy” hanya menyimpan n-variabel yang diperlukan untuk penerapan, dan repositori “helm” menyimpan konfigurasi atau bagan.

Apa yang diberikan hal ini kepada kita?

Terlepas dari kenyataan bahwa kami tidak menyimpan data sensitif apa pun di file konfigurasi itu sendiri. Misalnya, kata sandi ke database. Mereka disimpan sebagai rahasia di Kubernetes, namun demikian, masih ada hal-hal tertentu di sana yang kami tidak ingin aksesnya kepada semua orang. Oleh karena itu, akses ke repositori “deploy” lebih terbatas, dan repositori “helm” hanya berisi deskripsi layanan. Oleh karena itu, dapat diakses dengan aman oleh lebih banyak orang.

Karena kami tidak hanya memiliki produksi, tetapi juga lingkungan lain, berkat pemisahan ini kami dapat menggunakan kembali diagram kemudi untuk menyebarkan layanan tidak hanya ke produksi, tetapi juga, misalnya, ke lingkungan QA. Bahkan untuk menyebarkannya secara lokal menggunakan Minikube - ini berguna untuk menjalankan Kubernetes secara lokal.

Di dalam setiap repositori, kami meninggalkan pembagian ke dalam direktori terpisah untuk setiap layanan. Artinya, di dalam setiap direktori terdapat templat yang terkait dengan bagan terkait dan menjelaskan sumber daya yang perlu digunakan untuk menjalankan sistem kami. Kami hanya menyisakan envs di repositori “deploy”. Dalam hal ini, kami tidak menggunakan templating menggunakan jinja, karena helm sendiri menyediakan templating di luar kotak - ini adalah salah satu fungsi utamanya.

Kami meninggalkan skrip penerapan - deploy.sh, yang menyederhanakan dan menstandarkan peluncuran penerapan menggunakan helm. Jadi, bagi siapa saja yang ingin menerapkan, antarmuka penerapan terlihat persis sama seperti saat menerapkan melalui Nomad. deploy.sh yang sama, nama layanan Anda, dan di mana Anda ingin menerapkannya. Hal ini menyebabkan helm memulai secara internal. Ia, pada gilirannya, mengumpulkan konfigurasi dari templat, memasukkan file nilai yang diperlukan ke dalamnya, lalu menyebarkannya, meluncurkannya ke Kubernetes.

Temuan

Layanan Kubernetes tampaknya lebih kompleks daripada Nomad.

Di sini lalu lintas keluar datang ke Ingress. Ini hanyalah pengontrol depan, yang mengambil alih semua permintaan dan kemudian mengirimkannya ke layanan yang sesuai dengan data permintaan. Ini menentukannya berdasarkan konfigurasi yang merupakan bagian dari deskripsi aplikasi Anda di helm dan yang ditetapkan sendiri oleh pengembang. Layanan mengirimkan permintaan ke podnya, yaitu kontainer tertentu, menyeimbangkan lalu lintas masuk antara semua kontainer milik layanan ini. Dan, tentu saja, kita tidak boleh lupa bahwa kita tidak boleh mengabaikan keamanan di tingkat jaringan. Oleh karena itu, segmentasi berfungsi di cluster Kubernetes, yang didasarkan pada penandaan. Semua layanan memiliki tag tertentu yang terkait dengan hak akses layanan terhadap sumber daya eksternal/internal tertentu di dalam atau di luar klaster.

Saat kami melakukan transisi, kami melihat bahwa Kubernetes memiliki semua kemampuan Nomad yang telah kami gunakan sebelumnya, dan juga menambahkan banyak hal baru. Itu dapat diperluas melalui plugin, dan bahkan melalui jenis sumber daya khusus. Artinya, Anda memiliki kesempatan tidak hanya untuk menggunakan sesuatu yang langsung disertakan dengan Kubernetes, tetapi juga untuk membuat sumber daya dan layanan Anda sendiri yang akan membaca sumber daya Anda. Ini memberi Anda opsi tambahan untuk memperluas sistem Anda tanpa harus menginstal ulang Kubernetes dan tanpa memerlukan modifikasi.

Contoh penggunaannya adalah Prometheus, yang berjalan di dalam cluster Kubernetes kami. Agar dapat mulai mengumpulkan metrik dari layanan tertentu, kita perlu menambahkan jenis sumber daya tambahan, yang disebut monitor layanan, ke deskripsi layanan. Prometheus, karena dapat membaca jenis sumber daya khusus saat diluncurkan di Kubernetes, secara otomatis mulai mengumpulkan metrik dari sistem baru. Ini cukup nyaman.

Penerapan pertama yang kami lakukan pada Kubernetes dilakukan pada bulan Maret 2018. Dan selama ini kami tidak pernah mengalami masalah apapun dengannya. Ia bekerja cukup stabil tanpa bug yang signifikan. Selain itu, kita bisa memperluasnya lebih jauh. Saat ini kami sudah memiliki cukup banyak kemampuan yang dimilikinya, dan kami sangat menyukai laju perkembangan Kubernetes. Saat ini, lebih dari 3000 container berada di Kubernetes. Cluster ini menempati beberapa Node. Pada saat yang sama, ia dapat diservis, stabil, dan sangat dapat dikontrol.

Sumber: www.habr.com