🤝 👈🏿 😝 Kubernet dalam semangat pembajakan: jalur kami ke layanan microser dan template yang siap pakai untuk implementasi 🏇🏿 👨🏽‍💻 🏐

Hai, saya Yuri Buylov, saya berkembang di CarPrice, dan juga menerapkan praktik DevOps, layanan mikro, dan Kubernet. Saya ingin berbicara tentang Kubernetes dalam semangat pembajakan - bukan hanya tentang mengelola kapal besar yang indah di layar, tetapi juga tentang armada kapal penangkap ikan kecil yang tak sedap dipandang, terkadang berkarat, tetapi sangat cepat, gesit, dan berbahaya.

Ini akan menarik bagi mereka yang mengembangkan atau mentransfer infrastruktur ke layanan Microsoft, mengimplementasikan DevOps di atas Kubernetes dan pergi ke cloud asli dalam segala hal. Saya akan memberi tahu Anda tentang jalur kami, di akhir artikel saya akan membagikan landasan kami untuk lingkungan layanan-mikro - Saya akan memberikan tautan ke templat yang akan nyaman bagi pengembang dan penguji.

Artikel ini didasarkan pada presentasi video di Konferensi @Kubernetes oleh Mail.ru Cloud SolutionsJika Anda tidak ingin membaca, Anda bisa melihatnya .

Bagaimana kami hidup sebelum Kubernet: server dev, bare metal, dan Ansible

Kami hidup dan hidup dalam mode perubahan dan eksperimen yang konstan: tes AV, menguji berbagai hipotesis. Kami meluncurkan layanan baru, maka, jika sesuatu tidak berfungsi, kami hentikan itu.

Suatu ketika kami memiliki monolit di PHP, yang membawa banyak rasa sakit dan penderitaan. Untuk memberikan waktu-ke-pasar yang dapat diterima, kami pergi dengan cara yang khas - kami mulai melihat monolit ini untuk layanan-layanan mikro. Hasilnya, ternyata sebuah monolit besar berubah menjadi banyak monolit kecil. Ini normal, ini adalah kasus untuk semua orang yang menghadapi tugas serupa.

Kemudian kami mulai mencoba teknologi lain, khususnya, Golang muncul di perusahaan kami, yang kemudian menjadi bahasa pengembangan utama. Ada beberapa pertanyaan: bagaimana mengembangkan, menguji, dan menggunakan semua ini? Jawabannya jelas - Anda memerlukan server dev. Setiap pengembang harus memiliki server dev, di mana ia dapat terhubung untuk menulis kode berkualitas tinggi dan berkinerja tinggi di sana.

Akibatnya, orang-orang menulis server dev. Hasilnya adalah antarmuka web yang mengontrol pembuatan docker di server. Ada juga sebuah wadah dengan Source Code, yang dipasang di docker-compose. Pengembang dapat terhubung melalui SSH dan program. Penguji juga bekerja di sana, semuanya bekerja dengan sempurna.

Tetapi dengan meningkatnya jumlah layanan, menjadi tidak mungkin untuk bekerja. Momen datang ketika itu perlu untuk menyebarkan sesuatu, bukan untuk membongkar wadah. Kami mengambil logam telanjang, menggulung Docker di sana. Kemudian mereka mengambil Ansible, menulis beberapa peran. Setiap peran adalah layanan di mana buruh pelabuhan bersusun, yang “datang” ke salah satu mobil.

Jadi kami tinggal: di nginx kami mendaftar di hulu dengan tangan kami, mereka mengatakan ke pelabuhan mana kami harus pergi, di mana layanan ini tinggal. Bahkan ada file yaml di mana semua port terdaftar sehingga aplikasi tidak akan bersaing untuk mereka.

Bagaimana kami sampai di Kubernetes dan membangun infrastruktur di atasnya

Jelas, seseorang tidak bisa hidup seperti itu, orkestrasi diperlukan. Kami memahami ini pada 2017-2018, maka tidak jelas ke mana mendapatkan orkestra ini. Kubernetes baru saja dimulai, ada HashiCorp Nomad, Rancher, OpenShift. Kami mencoba Nomad, itu tidak buruk, tetapi kami tidak ingin menulis ulang docker-compose ke konfigurasi Nomad.

Tentang Kubernetes, kami segera menyadari bahwa kolega asing mencoba melakukannya, mereka tidak selalu berhasil. Dan kami tidak memiliki admin berjanggut yang bisa menjadikan kami sebuah cluster. Mereka mulai berpikir bagaimana menerapkannya. Bahkan saat itu Kubernetes, misalnya, ada di Amazon, tetapi kami ingat kuncinya, setelah itu mereka bergerak dengan cepat. Oleh karena itu, opsi ini segera dibuang, semua lalu lintas lebih mahal di sana.

Dan kemudian Kubernetes muncul di platform Cloud Mail.ru sebagai layanan Mail.ru Cloud Containers. Kami telah memindahkan penyimpanan S3 kami di sana dari Amazon, kami memutuskan untuk mencoba K8 juga. Kami menyebarkan cluster di cloud, semuanya berfungsi.

Untuk pengujian, kami memutuskan untuk menggunakan beberapa layanan stateless di sana. Mengambil API untuk aplikasi seluler, yang digunakan - ini berfungsi. Mengirim 50% lalu lintas ke sana - berfungsi. Ya, sesuatu jatuh secara berkala, tetapi orang-orang memperbaikinya, semuanya baik-baik saja. Akibatnya, seluruh infrastruktur dipindahkan, sekarang dibangun di sekitar Kubernetes, terutama server dev dan stage.

Setiap pengembang memiliki Minikube sendiri di VMware, yang digunakannya. Kami meluncurkan proyek baru di Kubernetes di cloud MCS, kami juga menggunakan Managed MySQL, yang segera tiba dengan semua budak, replikasi, dan cadangan dalam S3.

Kami masih memiliki warisan pada bare metal, termasuk kluster buruh pelabuhan yang menjalankan Ansible, tetapi suatu hari nanti kami akan mengetahuinya.

Cara hidup dengan teknologi kebun binatang dan tidak menderita

Kebun binatang teknologi sekarang tidak menakutkan seperti, katakanlah, pada tahun 2011. Ini bahkan normal jika Anda dapat mengambil alat dan teknologi khusus dari berbagai tempat dan menggunakannya sesuka Anda. Misalnya, kami menggunakan Golang untuk beberapa hal, tetapi Data Scientist bekerja dengan Python, Anda tidak bisa memaksa mereka untuk menulis dalam GO atau PHP.

Secara umum, kami memiliki dua aturan:

buruh pelabuhan: harus ada wadah;
dapat diamati: wadah ini harus dapat diamati.

Untuk melanjutkan analogi dengan kebun binatang: ada sel, dan tidak begitu penting siapa yang duduk di sel-sel ini. Yang utama adalah air dan makanan tiba secara teratur, otomatis dan seragam, dan "produk vital" layanan, yaitu, kayu gelondongan, dikirim ke suatu tempat secara terpusat.

Agar dapat diamati, kami memiliki tumpukan standar: setiap aplikasi menulis log ke stdout, dari mana semuanya ditransfer secara terpusat ke EFK. Artinya, pengembang bisa datang dan melihat log di Kibana. Metrik aplikasi dijatuhkan di Prometheus, dasbor, dan lansiran sebagai standar di Grafana. Jaeger adalah kisah Opentracing yang menunjukkan siapa yang mengakses layanan mana jika kita tidak tahu atau tidak ingin menghadapinya dengan cara lain.

Cara mengembangkan dan menguji dengan semua ini

Katakanlah seorang pengembang baru datang kepada kita, dia melihat 100 layanan dan 100 repositori. Dia segera memiliki pertanyaan. Bagaimana cara menyebarkan 100 layanan ini, dan bagaimana mengkonfigurasi? Di mana basis datanya? Akun apa yang ada di sana? Dan ada banyak pertanyaan seperti itu. Karena itu, rilis pengembang baru membutuhkan waktu yang tidak pantas, ia bisa duduk selama seminggu dan mengatur semuanya.

Sebagai hasilnya, kami telah mengembangkan lingkungan pengembangan 1-Click. Setiap pengembang memiliki Minikube-nya sendiri dengan inti dan memori tak terbatas bersyarat, yang digunakan di cloud VMware. Ditambah database - itu berasal setiap hari dari produksi, dikaburkan, dikompresi dan diletakkan di ZFS. Ini adalah pengembangan pribadi admin kami. Kami telah terlibat dalam pemotongan biaya untuk waktu yang lama, kami perlu memberi semua pengembang basis dan pada saat yang sama tidak bangkrut.

Ada snapshot di ZFS, pengembang API dapat menggulung database secara langsung dari produksi dalam dua detik. Dengan autotest, cerita yang sama: kita mulai dengan API, dan semuanya berfungsi.

Seperti inilah aliran pengembangan saat ini:

Pengembang senang, DevOps, dan admin bahagia karena semua proses seragam, berulang, dan terpadu. Tetapi ada satu hal.

Sistem Lapisan Berlapis

Seperti yang dikatakan Linus Torvalds: “Bicara itu murah. Tunjukkan kodenya. " Jadi, kami menggunakan sistem lapisan multi-level. Ada lapisan sepele: dev, stage, prod, yang muncul di pikiran untuk semua orang yang akan membuat CI / CD.

Tetapi masih ada pengembang, mereka membutuhkan beberapa domain mereka, beberapa cerita khusus pengguna, jadi kami memiliki lapisan nilai pengguna. Tetapi ini tidak cukup - Anda masih perlu menguji. Misalkan kita membuat cabang, mungkin beberapa layanan, dan kita perlu meneruskan ini ke penguji sehingga berulang. Untuk ini, kami memiliki lapisan dengan nilai untuk tugas, yaitu nilai tugas.

Momen lain yang sedikit holivarny - kami tidak menggunakan Tiller, memilih Helm, tetapi kami menggunakannya sebagai mesin templat. Artinya, kami hanya menggunakan helm-template, ia memberikan file yaml pada output, yang dapat dikaitkan dengan Minikube atau cluster, dan tidak ada lagi yang diperlukan.

Bagaimana repositori K8s-helm bekerja

Seperti yang saya katakan, kami memiliki lapisan dev, prod dan stage yang jelas, ada file yaml dari setiap layanan, ketika kami melihat layanan baru, tambahkan file tersebut.

Selain itu ada dev.server ayah dengan yang paling menarik. Ada skrip bash yang membantu, misalnya, membuat pengguna baru: jangan membuat 100 layanan dengan tangan Anda dan jangan mengisi file yaml, tetapi cukup jalankan dalam satu perintah. Di sinilah semua file yaml ini dihasilkan.

Di folder yang sama ada tugas subfolder. Jika kita perlu membuat beberapa nilai spesifik untuk penerapan kita, kita cukup membuat folder dengan nomor tugas di dalamnya, komit cabang. Lalu kami memberi tahu penguji: "Cabang seperti itu terletak di repositori, ambil dan jalankan." Dia mulai, menarik perintah yang terletak di tempat sampah, dan semuanya bekerja - tidak perlu mengkonfigurasi dengan tangan. Keajaiban DevOps adalah infrastruktur sebagai kode.

Sebagai hasilnya, proses bermuara pada tiga tim:

Ketika pengembang baru tiba, mereka memberinya Minikube, folder arsip dengan sertifikat dan domain. Secara umum, ia hanya membutuhkan kubectl dan Helm. Dia mengkloning repositori ke dirinya sendiri, menunjukkan kubectl path ke config-nya, menjalankan perintah make_user dengan namanya. Dan untuk semua layanan, salinan dibuat untuknya. Selain itu, mereka tidak hanya dibuat - ada database yang diberikan kepadanya, pengembang menentukan kredensial untuk itu, dan semua kredensial ini pergi ke layanan lain.

Pengguna telah dibuat. Bagaimana saya bisa menggunakannya sekarang? Tidak ada yang rumit di sini - kami menjalankan deploy.sh dengan namanya, dan semuanya datang ke pengembang di namespace default di Minikube-nya, semuanya segera tersedia di domainnya.

Jika pengembang telah memprogram sesuatu, ia mengambil ID masalah dan memberikannya kepada penguji. Penguji menyalin cabang ini, meluncurkan penyebaran, dan lingkungan dengan fitur baru muncul di klusternya.

Perakitan helm K8s

Repositori itu sendiri dikompilasi dan dibangun ke dalam proses CI / CD. Tidak ada yang istimewa di sini - hanya kubectl dengan sertifikat dan Helm.

Dalam proyek tersebut, akan terlihat seperti ini:

Misalkan Anda dikerahkan, dan ada tahap ketika Anda perlu tahap pertama tahap, dan kemudian jalankan tes di sana menggunakan Jenkins. Dari repositori, Anda memiliki gambar yang dikompilasi dengan Helm. Kami menjalankan menyebarkan menjalankan namespace service_stage menjalankan perintah dan semuanya berjalan.

Kemudian datang CI, di sini .drone.yml, tetapi hal yang sama akan terjadi di GitLab atau di tempat lain.

Selanjutnya, Jenkins memulai, yang menjalankan tes di atas panggung. Jika semuanya baik-baik saja, maka itu memulai penyebaran yang hampir sama, tetapi sudah di prod. Artinya, mekanisme ini tidak hanya membuat hidup lebih mudah bagi pengembang dan penguji, tetapi juga digunakan untuk menghadirkan fitur ke produk.

Kami menyukai sumber terbuka, kami ingin berinvestasi dalam pengembangan DevOps, jadi kami membuat templat yang dapat Anda gunakan dan unggah ke github . Ada semua yang saya bicarakan: Anda dapat mengikuti, menonton, menguji, dan melamar. Ini akan bermanfaat bagi semua orang yang mengimplementasikan layanan microser, atau menderita kenyataan bahwa tim mengimplementasikan layanan microser, atau ingin membangun proses DevOps di sekitar ini.

Artikel terkait kami yang lain:

Pembicaraan ini pertama kali dilakukan di Konferensi @Kubernetes oleh Mail.ru Cloud Solutions. Tonton video pertunjukan lainnya dan daftar untuk pengumuman acara Telegram Around Kubernetes di Mail.ru Group .

Kubernet dalam semangat pembajakan: jalur kami ke layanan microser dan template yang siap pakai untuk implementasi