Bagaimana kami menerjemahkan situs web Republic ke Kubernetes

Materi-materi skandal, penting, dan sangat keren tidak dipublikasikan di media setiap hari, dan tidak ada editor yang berani memprediksi keberhasilan sebuah artikel dengan akurasi 100%. Maksimum yang dimiliki tim adalah pada level insting untuk mengatakan materi "kuat" atau "biasa". Itu saja. Kemudian mulailah keajaiban media yang tak terduga, berkat artikel yang dapat mencapai puncak hasil pencarian dengan lusinan tautan dari publikasi lain atau materi akan terlupakan. Dan hanya dalam kasus publikasi artikel keren, situs media secara berkala jatuh di bawah gelombang masuknya pengguna, yang secara sederhana kita sebut "habraeffect".

Musim panas ini, situs web publikasi Republik menjadi korban dari profesionalisme penulisnya sendiri: artikel tentang topik reformasi pensiun, pendidikan sekolah, dan nutrisi yang tepat secara total mengumpulkan audiensi beberapa juta pembaca. Publikasi masing-masing bahan yang disebutkan menyebabkan muatan yang begitu tinggi sehingga sampai jatuhnya situs web Republik, benar-benar ada "sedikit dari itu". Administrasi menyadari bahwa sesuatu harus diubah: perlu mengubah struktur proyek sedemikian rupa sehingga dapat bereaksi dengan penuh semangat terhadap perubahan dalam kondisi kerja (terutama beban eksternal), sementara tetap berfungsi penuh dan dapat diakses oleh pembaca bahkan pada saat lompatan yang sangat tajam yang hadir. Dan bonus besar akan menjadi intervensi manual minimal dari tim teknis Republik pada saat-saat seperti itu.

Berdasarkan hasil diskusi bersama dengan para ahli Republik mengenai berbagai opsi untuk penerapan Wishlist yang disuarakan, kami memutuskan untuk mentransfer situs web publikasi ke Kubernetes *. Tentang apa semua itu merugikan kita semua, dan akan menjadi kisah kita hari ini.

* Selama kepindahan, tidak ada satu pun spesialis teknis Republik yang terluka

Tampilannya secara umum

Semuanya dimulai, tentu saja, dengan negosiasi tentang bagaimana segala sesuatu akan terjadi "sekarang" dan "nanti". Sayangnya, paradigma modern di pasar TI menyiratkan bahwa begitu perusahaan pergi ke sisi untuk beberapa jenis solusi infrastruktur, mereka mengubahnya pada daftar harga layanan turnkey. Tampaknya pekerjaan itu adalah "turnkey" - apa yang bisa lebih bagus dan lebih bagus daripada direktur bersyarat atau pemilik bisnis? Saya membayar, dan kepala saya tidak terluka: perencanaan, pengembangan, dukungan - semua ada di sana, di sisi kontraktor, bisnis hanya dapat menghasilkan uang untuk membayar layanan yang menyenangkan.

Namun, transfer penuh infrastruktur TI tidak selalu sesuai untuk pelanggan dalam jangka panjang. Lebih tepat dari semua sudut pandang untuk bekerja sebagai satu tim besar, sehingga setelah proyek selesai, klien memahami bagaimana hidup dengan infrastruktur baru lebih lanjut, dan kolega di lantai toko tidak memiliki pertanyaan "oh, tapi apa yang Anda lakukan di sini?" setelah menandatangani sertifikat kelengkapan dan demonstrasi hasil. Orang-orang Republik memiliki pendapat yang sama. Akibatnya, selama dua bulan kami mendaratkan pendaratan empat orang ke klien, yang tidak hanya mewujudkan ide kami, tetapi juga secara teknis melatih spesialis di pihak Republik untuk pekerjaan lebih lanjut dan keberadaan dalam realitas Kubernetes.

Dan semua pihak mendapat manfaat dari ini: kami dengan cepat menyelesaikan pekerjaan, membuat spesialis kami siap untuk pencapaian baru dan mendapatkan Republik sebagai klien pada dukungan konsultasi dengan insinyur kami sendiri. Publikasi, di sisi lain, menerima infrastruktur baru yang disesuaikan dengan “habraeffects”, staf tetap spesialis teknisnya, dan kemampuan untuk mencari bantuan jika diperlukan.

Kami sedang mempersiapkan jembatan

"Hancurkan - bukan membangun." Pepatah ini berlaku untuk apa saja. Tentu saja, solusi paling sederhana tampaknya menjadi penyanderaan yang disebutkan sebelumnya dari infrastruktur klien dan merantai dia, klien untuk dirinya sendiri, atau overclocking staf yang ada dan persyaratan untuk mempekerjakan seorang guru dalam teknologi baru. Kami pergi yang ketiga, bukan cara yang paling populer hari ini, dan mulai dengan pelatihan insinyur Republik.

Pada awalnya, kami melihat tentang solusi semacam itu untuk memastikan operasi situs:


Artinya, Republik hanya memiliki dua server besi - utama dan cadangan, cadangan. Yang paling penting bagi kami adalah untuk mencapai perubahan paradigma dalam pemikiran spesialis teknis klien, karena sebelumnya mereka berurusan dengan sekelompok NGINX, PHP-fpm dan PostgreSQL yang sangat sederhana. Sekarang mereka dihadapkan dengan arsitektur kontainer Kubernet yang scalable. Jadi pertama-tama, kami mengalihkan pengembangan Republik lokal ke lingkungan menulis-buruh pelabuhan. Dan ini hanya langkah pertama.

Sebelum pendaratan kami, pengembang Republic menjaga lingkungan kerja lokal mereka di mesin virtual yang dikonfigurasi melalui Vagrant, atau bekerja secara langsung dengan server dev melalui sftp. Berdasarkan gambar dasar umum dari sebuah mesin virtual, setiap pengembang “mengonfigurasi” mesinnya “untuk dirinya sendiri”, yang memunculkan serangkaian konfigurasi yang berbeda. Sebagai hasil dari pendekatan ini, dimasukkannya orang-orang baru dalam tim secara eksponensial meningkatkan waktu mereka memasuki proyek.

Dalam realitas baru, kami menawarkan kepada tim struktur yang lebih transparan dari lingkungan kerja. Ini secara deskriptif menggambarkan perangkat lunak apa dan versi apa yang diperlukan untuk proyek, urutan koneksi dan interaksi antara layanan (aplikasi). Deskripsi ini diunggah ke repositori git yang terpisah sehingga dapat dikelola secara terpusat.

Semua aplikasi yang diperlukan mulai berjalan dalam wadah buruh pelabuhan yang terpisah - dan ini adalah situs php biasa dengan nginx, banyak statika, layanan untuk bekerja dengan gambar (ukuran, optimasi, dll.), Dan ... layanan terpisah untuk soket web yang ditulis dalam D Semua file konfigurasi (nginx-conf, php-conf ...) juga menjadi bagian dari basis kode proyek.

Karenanya, lingkungan lokal sepenuhnya "diciptakan kembali", sepenuhnya identik dengan infrastruktur server saat ini. Dengan demikian, waktu yang diperlukan untuk mempertahankan lingkungan yang sama baik pada mesin lokal pengembang dan pada prod berkurang. Yang, pada gilirannya, sangat membantu untuk menghindari masalah yang sama sekali tidak perlu yang disebabkan oleh konfigurasi lokal yang ditulis sendiri dari setiap pengembang.

Akibatnya, layanan berikut dimunculkan dalam lingkungan penyusun buruh pelabuhan:

• web untuk aplikasi php-fpm;
• nginx;
• impproxy dan cairosvg (layanan untuk bekerja dengan gambar);
• postgres
• redis;
• pencarian elastis;
• trumpet (layanan yang sama untuk soket web pada D).

Dari sudut pandang pengembang, pekerjaan dengan basis kode tetap tidak berubah - itu dipasang di layanan yang diperlukan dari direktori terpisah (repositori dasar dengan kode situs) ke dalam layanan yang diperlukan: direktori publik di layanan nginx, semua kode aplikasi php dalam layanan php-fpm. Dari direktori terpisah (yang berisi semua konfigurasi lingkungan penulisan), file konfigurasi yang sesuai dipasang di layanan nginx dan php-fpm. Direktori dengan postgres data, elasticsearch dan redis juga dipasang pada mesin lokal pengembang, sehingga jika semua kontainer harus dibangun kembali / dihapus, data dalam layanan ini tidak akan hilang.

Untuk bekerja dengan log aplikasi - juga di lingkungan menulis-buruh pelabuhan - layanan tumpukan ELK dinaikkan. Sebelumnya, sebagian log aplikasi ditulis dalam standar / var / log / ..., log aplikasi dan eksekusi php ditulis dalam Sentry, dan opsi penyimpanan log "desentralisasi" ini sangat tidak nyaman untuk digunakan. Sekarang, aplikasi dan layanan telah dikonfigurasi dan disempurnakan untuk berinteraksi dengan tumpukan ELK. Menggunakan log menjadi lebih mudah, pengembang sekarang memiliki antarmuka yang nyaman untuk mencari dan memfilter log. Di masa depan (sudah ada di dalam kubus) - Anda dapat menonton log dari versi spesifik aplikasi (misalnya, kronzhoba diluncurkan sehari sebelum kemarin).

Selanjutnya, tim Republik memulai periode adaptasi singkat. Tim perlu memahami dan belajar bagaimana bekerja dalam paradigma pembangunan baru, di mana hal-hal berikut harus dipertimbangkan:

1. Aplikasi menjadi stateless, dan mereka dapat kehilangan data setiap saat, jadi bekerja dengan database, sesi, file statis harus dibuat secara berbeda. Sesi PHP harus disimpan secara terpusat dan dibagikan di antara semua instance aplikasi. Mungkin terus menjadi file, tetapi redis lebih sering diambil untuk tujuan ini karena kemudahan manajemen yang lebih besar. Kontainer untuk database harus "me-mount" sebuah datadir, atau database harus dijalankan di luar infrastruktur kontainer.
2. Penyimpanan file sekitar 50-60 GB gambar tidak boleh "di dalam aplikasi web." Untuk tujuan tersebut, perlu menggunakan beberapa penyimpanan eksternal, sistem cdn, dll.
3. Semua aplikasi (database, server aplikasi ...) sekarang terpisah "layanan", dan interaksi di antara mereka harus dikonfigurasi relatif terhadap namespace baru.

Setelah tim pengembangan Republik terbiasa dengan inovasi, kami mulai mentransfer infrastruktur penjualan publikasi ke Kubernetes.

Dan inilah Kubernet

Berdasarkan dibangun untuk lingkungan pembuatan komposisi buruh pelabuhan lokal, kami mulai menerjemahkan proyek menjadi "kubus". Semua layanan di mana proyek dibangun secara lokal, kami "dikemas ke dalam wadah": kami mengorganisir prosedur linier dan dapat dipahami untuk membangun aplikasi, menyimpan konfigurasi, menyusun statika. Dari sudut pandang pengembangan, mereka menghapus parameter konfigurasi yang kami butuhkan ke dalam variabel lingkungan, mulai menyimpan sesi bukan dalam file, tetapi dalam lobak. Kami mengangkat lingkungan pengujian, tempat kami menggunakan versi situs yang bisa diterapkan.

Karena ini adalah proyek monolitik pertama, jelas bahwa ada hubungan yang keras antara versi frontend dan backend, dan kedua komponen ini dikerahkan pada saat yang sama. Oleh karena itu, kami memutuskan untuk membuat pod aplikasi web sedemikian rupa sehingga dua kontainer akan berputar dalam satu pod: php-fpm dan nginx.

Kami juga membuat penskalaan otomatis sehingga aplikasi web diskalakan hingga maksimum 12 di puncak lalu lintas, menetapkan tes liness / readiness tertentu, karena aplikasi memerlukan setidaknya 2 menit untuk berjalan (karena Anda perlu menghangatkan cache, menghasilkan konfigurasi ...)

Segera, tentu saja, ada semua jenis beting dan nuansa. Sebagai contoh: statika yang dikompilasi diperlukan untuk server web yang mendistribusikannya dan server aplikasi pada fpm, yang di suatu tempat dengan cepat menghasilkan beberapa jenis gambar, di suatu tempat svg memberikan langsung ke kode. Kami menyadari bahwa agar tidak bangun dua kali, kami perlu membuat wadah penampung menengah dan mengemas wadah akhir melalui multi-tahap. Untuk melakukan ini, kami membuat beberapa wadah perantara, di mana masing-masing dependensinya ditarik secara terpisah, kemudian statika (css dan js) dikumpulkan secara terpisah, dan kemudian menjadi dua wadah - dalam nginx dan dalam fpm - mereka disalin dari wadah pembangun menengah.

Kita mulai

Untuk bekerja dengan file dalam iterasi pertama, kami membuat direktori umum yang disinkronkan ke semua mesin yang berfungsi. Dengan kata "disinkronkan" maksud saya di sini persis apa yang dapat Anda pikirkan dengan horor di tempat pertama - rsync dalam lingkaran. Jelas keputusan yang buruk. Sebagai hasilnya, kami mendapatkan semua ruang disk di GlusterFS, mengatur kerja dengan gambar sehingga mereka selalu dapat diakses dari mesin apa pun dan tidak ada yang melambat. Untuk interaksi aplikasi kami dengan sistem penyimpanan (postgres, elasticsearch, redis), layanan externalName dibuat dalam k8s, sehingga, misalnya, jika ada pergantian mendesak ke database cadangan, perbarui parameter koneksi di satu tempat.

Semua pekerjaan dengan crones dibawa ke entitas k8s baru - cronjob, yang dapat berjalan sesuai dengan jadwal tertentu.

Hasilnya, kami mendapatkan arsitektur ini:


Diklik

Oh sulit

Ini adalah peluncuran versi pertama, karena seiring dengan restrukturisasi infrastruktur yang lengkap, situs ini masih menjalani desain ulang. Bagian dari situs ini dibangun dengan beberapa parameter - untuk statika dan yang lainnya, dan sebagian - dengan yang lain. Di sana perlu ... secara halus ... memutarbalikkan semua wadah bertingkat ini, menyalin data dari mereka dalam urutan yang berbeda, dll.

Kami juga harus menari dengan rebana di sekitar sistem CI \ CD untuk mengajarkan semua ini untuk menyebarkan dan mengontrol dari berbagai repositori dan dari lingkungan yang berbeda. Lagi pula, kontrol konstan atas versi aplikasi diperlukan agar Anda dapat memahami kapan suatu layanan atau layanan lain digunakan dan dengan versi aplikasi mana satu atau kesalahan lain dimulai. Untuk melakukan ini, kami menyiapkan sistem logging yang benar (serta budaya logging itu sendiri) dan menerapkan ELK. Kolega belajar mengatur penyeleksi tertentu, melihat cron mana yang menghasilkan kesalahan, bagaimana cron umumnya dieksekusi, karena dalam "cube" setelah cron-container dieksekusi, Anda tidak akan lagi masuk ke dalamnya.

Tetapi hal yang paling sulit bagi kami adalah mengerjakan ulang dan merevisi seluruh basis kode.

Biarkan saya mengingatkan Anda, Republik adalah proyek yang sekarang berusia 10 tahun. Itu dimulai dengan satu tim, yang lain sedang berkembang sekarang, dan sangat sulit untuk menyekop semua kode sumber untuk kemungkinan bug dan kesalahan. Tentu saja, pada saat ini, pesta pendaratan beranggotakan empat orang kami menghubungkan sumber daya dari seluruh tim: kami mengklik dan menguji seluruh situs dengan tes, bahkan di bagian yang belum dikunjungi orang sejak 2016.

Tidak gagal di mana pun

Pada hari Senin, dini hari, ketika orang-orang pergi ke surat massal dengan intisari, kami semua mendapat taruhan. Pelakunya ditemukan cukup cepat: cronjob mulai dan dengan panik mulai mengirim surat kepada semua orang yang ingin mendapatkan pilihan berita selama seminggu terakhir, melahap sumber daya seluruh cluster di sepanjang jalan. Kami tidak tahan dengan perilaku seperti itu, jadi kami dengan cepat menempatkan batasan ketat pada semua sumber daya: berapa banyak prosesor dan memori yang dapat dikonsumsi wadah dan sebagainya.

Bagaimana tim pengembang Republik mengatasinya

Kegiatan kami membawa banyak perubahan, dan kami memahami ini. Faktanya, kami tidak hanya menggambar ulang infrastruktur publikasi, alih-alih bundel “server cadangan utama” yang biasa, mengimplementasikan solusi wadah yang menghubungkan sumber daya tambahan sesuai kebutuhan, tetapi juga mengubah pendekatan untuk pengembangan lebih lanjut.

Setelah beberapa waktu, orang-orang mulai mengerti bahwa ini tidak langsung bekerja dengan kode, tetapi bekerja dengan aplikasi abstrak. Mengingat proses CI \ CD (dibangun di atas Jenkins), mereka mulai menulis tes, mereka mendapatkan lingkungan dev-stage-prod penuh di mana mereka dapat menguji versi baru dari aplikasi mereka secara real time, melihat di mana sesuatu jatuh, dan belajar untuk hidup di dunia ideal baru.

Apa yang didapat klien

Pertama-tama, Republik akhirnya mendapatkan proses penyebaran yang terkendali! Dulu: di Republik ada orang yang bertanggung jawab yang pergi ke server, memulai semuanya secara manual, kemudian mengumpulkan statika, memeriksa dengan tangannya bahwa tidak ada yang jatuh ... Sekarang proses penyebaran dibangun sehingga pengembang terlibat dalam pengembangan dan tidak membuang waktu untuk hal lain . Dan orang yang bertanggung jawab sekarang memiliki satu tugas - untuk memantau bagaimana rilis secara umum.

Setelah push ke cabang master terjadi, baik secara otomatis atau dengan penyebaran "tombol-push" (secara berkala, karena persyaratan bisnis tertentu, penyebaran otomatis dinonaktifkan), Jenkins memasuki keributan: perakitan proyek dimulai. Pertama, semua wadah buruh pelabuhan dirakit: dependensi (komposer, benang, npm) dipasang di wadah persiapan, yang memungkinkan Anda untuk mempercepat proses pembuatan jika daftar perpustakaan yang diperlukan tidak berubah selama penyebaran; kemudian wadah untuk php-fpm, nginx, layanan lain dikumpulkan, di mana, dengan analogi dengan lingkungan menulis buruh pelabuhan, hanya bagian-bagian penting dari basis kode yang disalin. Setelah itu, tes diluncurkan dan, jika berhasil lulus tes, ada dorongan gambar ke toko pribadi dan, pada kenyataannya, meluncurkan penyebaran di cuber.

Berkat transfer Republik ke k8s, kami mendapatkan arsitektur menggunakan sekelompok tiga mesin nyata yang dapat digunakan hingga dua belas salinan aplikasi web untuk "berputar" pada saat yang sama. Pada saat yang sama, sistem itu sendiri, berdasarkan pada beban saat ini, memutuskan berapa banyak salinan yang dibutuhkan saat ini. Kami mengambil Republic dari lotre “berfungsi - tidak berfungsi” dengan server primer dan cadangan statis dan membangun sistem yang fleksibel untuknya, siap untuk peningkatan beban longsoran di situs.

Pada saat ini, mungkin timbul pertanyaan, “kalian, kamu mengganti dua potong besi menjadi potongan yang sama, tetapi dengan virtualisasi, apa untungnya, apa kalian semua ada di sana?” Dan, tentu saja, itu akan masuk akal. Tetapi hanya sebagian saja. Hasilnya, kami tidak hanya mendapatkan perangkat keras dengan virtualisasi. Kami memiliki lingkungan kerja yang stabil, sama dalam hal makanan dan virgo. Lingkungan yang dikelola secara terpusat untuk semua peserta proyek. Kami punya mekanisme untuk merakit seluruh proyek dan meluncurkan rilis, sekali lagi, sama untuk semua orang. Kami mendapat sistem orkestrasi proyek yang nyaman. Segera setelah tim Republik memperhatikan bahwa mereka umumnya berhenti memiliki sumber daya yang cukup saat ini dan risiko beban sangat tinggi (atau ketika sudah terjadi dan semuanya telah beres), mereka hanya mengambil server lain, dalam 10 menit meluncurkan peran simpul gugus di atasnya, dan op-op semuanya indah dan bagus lagi. Struktur proyek sebelumnya sama sekali tidak menyarankan pendekatan seperti itu, tidak ada solusi lambat atau cepat untuk masalah seperti itu.

Kedua, penyebaran yang mulus telah muncul: pengunjung akan mendapatkan versi aplikasi yang lama, atau yang baru. Dan tidak seperti sebelumnya, ketika konten bisa baru, tetapi gaya sudah lama.
Akibatnya, bisnisnya puas: segala macam hal baru sekarang dapat dilakukan lebih cepat dan lebih sering.
Secara total, dari "tapi mari kita coba" untuk "selesai", mengerjakan proyek ini memakan waktu 2 bulan. Tim di pihak kami adalah pendaratan heroik dari empat orang + dukungan untuk "pangkalan" selama verifikasi kode dan tes.

Apa yang didapat pengguna

Dan pengunjung, pada prinsipnya, tidak melihat perubahan. Proses penyebaran pada strategi RollingUpdate dibangun "mulus." Meluncurkan versi baru situs dengan cara apa pun tidak akan menyakiti pengguna, versi baru situs, hingga tes lulus dan tes liness / readiness, tidak akan tersedia. Mereka hanya melihat bahwa situs tersebut berfungsi dan tidak akan jatuh setelah menerbitkan artikel keren. Secara umum, itulah yang dibutuhkan oleh setiap proyek.