Pertemuan administrator sistem Sysadminka sedang berlangsung di Chelyabinsk, dan pada pertemuan terakhir saya memberikan laporan tentang solusi kami untuk menjalankan aplikasi pada 1C-Bitrix di Kubernetes.
Bitrix, Kubernetes, Ceph - campuran yang hebat?
Saya akan memberi tahu Anda bagaimana kami menyusun solusi yang berhasil dari semua ini.
Mari kita pergi!
Pertemuan tersebut berlangsung pada 18 April di Chelyabinsk. Anda dapat membaca tentang pertemuan kami di dan lihat .
Jika Anda ingin datang kepada kami dengan laporan atau sebagai pendengar - selamat datang, tulis surat ke kami [email dilindungi] dan di Telegram t.me/vadimisakanov.
Laporan saya
Solusi "Bitrix di Kubernetes, versi Southbridge 1.0"
Saya akan membicarakan solusi kami dalam format “for dummies in Kubernetes”, seperti yang dilakukan pada pertemuan tersebut. Namun saya berasumsi Anda mengetahui kata Bitrix, Docker, Kubernetes, Ceph setidaknya pada level artikel di Wikipedia.
Apa saja yang sudah jadi tentang Bitrix di Kubernetes?
Hanya ada sedikit informasi di seluruh Internet tentang pengoperasian aplikasi Bitrix di Kubernetes.
Saya hanya menemukan materi ini:
Laporan oleh Alexander Serbul, 1C-Bitrix, dan Anton Tuzlukov dari Qsoft:
Saya sarankan mendengarkannya.
Mengembangkan solusi Anda sendiri dari pengguna .
Menemukan lebih banyak .
Aaand... sebenarnya, itu saja.
Saya memperingatkan Anda, kami belum memeriksa kualitas solusi pada tautan di atas :)
Ngomong-ngomong, saat menyiapkan solusi, saya ngobrol dengan Alexander Serbul, lalu laporannya belum muncul, jadi di slide saya ada item “Bitrix tidak menggunakan Kubernetes.”
Namun sudah banyak image Docker yang siap pakai untuk menjalankan Bitrix di Docker:
Apakah ini cukup untuk menciptakan solusi lengkap untuk Bitrix di Kubernetes?
TIDAK. Ada banyak sekali masalah yang perlu diselesaikan.
Apa masalah Bitrix di Kubernetes?
Pertama, image siap pakai dari Dockerhub tidak cocok untuk Kubernetes
Jika kita ingin membangun arsitektur layanan mikro (dan di Kubernetes biasanya kita melakukannya), kita perlu memisahkan aplikasi Kubernetes ke dalam container dan meminta setiap container menjalankan satu fungsi kecil (dan melakukannya dengan baik). Kenapa hanya satu? Singkatnya, semakin sederhana semakin dapat diandalkan.
Untuk lebih jelasnya silahkan simak artikel dan video ini, silahkan:
Gambar Docker di Dockerhub sebagian besar dibuat berdasarkan prinsip all-in-one, jadi kami masih harus membuat sepeda sendiri dan bahkan membuat gambar dari awal.
Yang kedua adalah kode situs diedit dari panel admin
Kami membuat bagian baru di situs - kode telah diperbarui (direktori dengan nama bagian baru telah ditambahkan).
Jika Anda mengubah properti komponen dari panel admin, kodenya akan berubah.
Kubernetes “secara default” tidak dapat bekerja dengan ini; container harus tidak memiliki kewarganegaraan.
Alasan: Setiap kontainer (pod) di cluster hanya memproses sebagian lalu lintas. Jika Anda mengubah kode hanya dalam satu wadah (pod), maka kode tersebut akan berbeda di pod yang berbeda, situs akan bekerja secara berbeda, dan versi situs yang berbeda akan ditampilkan kepada pengguna yang berbeda. Anda tidak bisa hidup seperti itu.
Ketiga, Anda perlu menyelesaikan masalah penerapan
Jika kita memiliki monolit dan satu server "klasik", semuanya cukup sederhana: kita menerapkan basis kode baru, memigrasikan database, mengalihkan lalu lintas ke versi kode yang baru. Peralihan terjadi secara instan.
Jika kita memiliki situs di Kubernetes, dipotong menjadi layanan mikro, ada banyak container dengan kode - oh. Anda perlu mengumpulkan container dengan kode versi baru, meluncurkannya alih-alih yang lama, memigrasikan database dengan benar, dan idealnya melakukan hal ini tanpa diketahui oleh pengunjung. Untungnya, Kubernetes membantu kami dalam hal ini, mendukung berbagai jenis penerapan.
Keempat - Anda perlu menyelesaikan masalah penyimpanan statika
Jika situs Anda “hanya” berukuran 10 gigabyte dan Anda menerapkannya seluruhnya dalam container, Anda akan mendapatkan container 10 gigabyte yang memerlukan waktu lama untuk diterapkan.
Anda perlu menyimpan bagian "terberat" dari situs di luar wadah, dan muncul pertanyaan tentang bagaimana melakukannya dengan benar
Apa yang hilang dari solusi kami?
Keseluruhan kode Bitrix tidak terbagi menjadi microfunctions/microservices (sehingga registrasinya terpisah, modul toko onlinenya terpisah, dll). Kami menyimpan seluruh basis kode di setiap wadah.
Kami juga tidak menyimpan database di Kubernetes (saya masih mengimplementasikan solusi dengan database di Kubernetes untuk lingkungan pengembangan, tetapi tidak untuk produksi).
Administrator situs masih dapat mengetahui bahwa situs tersebut berjalan di Kubernetes. Fungsi “pemeriksaan sistem” tidak berfungsi dengan benar, untuk mengedit kode situs dari panel admin, Anda harus mengklik tombol “Saya ingin mengedit kode” terlebih dahulu.
Masalah telah teridentifikasi, kebutuhan untuk mengimplementasikan layanan mikro telah ditentukan, tujuannya jelas - untuk mendapatkan sistem yang berfungsi untuk menjalankan aplikasi pada Bitrix di Kubernetes, sambil mempertahankan kemampuan Bitrix dan keunggulan Kubernetes. Mari kita mulai implementasinya.
Arsitektur
Ada banyak pod yang “berfungsi” dengan server web (pekerja).
Satu di bawah dengan tugas cron (hanya diperlukan satu).
Satu peningkatan untuk mengedit kode situs dari panel admin (juga hanya diperlukan satu).
Kami memecahkan pertanyaan:
- Di mana menyimpan sesi?
- Di mana menyimpan cache?
- Di mana menyimpan statika, bukan menempatkan gigabyte statika di banyak wadah?
- Bagaimana cara kerja basis data?
gambar buruh pelabuhan
Kita mulai dengan membuat image Docker.
Opsi yang ideal adalah kita memiliki satu image universal, yang atas dasar itu kita mendapatkan pod pekerja, pod dengan Crontask, dan pod pemutakhiran.
.
Ini mencakup nginx, Apache/php-fpm (dapat dipilih saat build), msmtp untuk mengirim email, dan cron.
Saat merakit gambar, seluruh basis kode situs disalin ke direktori /app (dengan pengecualian bagian-bagian yang akan kita pindahkan ke penyimpanan bersama yang terpisah).
Layanan mikro, layanan
pod pekerja:
- Wadah dengan nginx + wadah apache/php-fpm + msmtp
- Tidak berhasil memindahkan msmtp ke layanan mikro terpisah, Bitrix mulai marah karena tidak dapat mengirim email secara langsung
- Setiap kontainer memiliki basis kode yang lengkap.
- Larangan mengubah kode dalam container.
cron di bawah:
- wadah dengan apache, php, cron
- basis kode lengkap disertakan
- larangan mengubah kode dalam wadah
tingkatkan di bawah:
- wadah nginx + wadah Apache/php-fpm + msmtp
- Tidak ada larangan mengubah kode di container
penyimpanan sesi
Penyimpanan cache Bitrix
Hal penting lainnya: kami menyimpan kata sandi untuk menghubungkan ke segala hal, mulai dari database hingga email, dalam rahasia kubernetes. Kami mendapat bonus: kata sandi hanya dapat dilihat oleh mereka yang kami beri akses ke rahasianya, dan tidak oleh semua orang yang memiliki akses ke basis kode proyek.
Penyimpanan untuk statika
Anda dapat menggunakan apa saja: ceph, nfs (tetapi kami tidak menyarankan nfs untuk produksi), penyimpanan jaringan dari penyedia cloud, dll.
Penyimpanan harus dihubungkan dalam wadah ke direktori /upload/ situs dan direktori lain dengan konten statis.
Basis data
Untuk mempermudah, kami merekomendasikan untuk memindahkan database ke luar Kubernetes. Basis di Kubernetes adalah tugas kompleks yang terpisah; ini akan membuat skema menjadi lebih kompleks.
Penyimpanan sesi
Kami menggunakan memcache :)
Ini menangani penyimpanan sesi dengan baik, dikelompokkan, dan didukung “secara asli” sebagai session.save_path di php. Sistem seperti itu telah diuji berkali-kali dalam arsitektur monolitik klasik, saat kami membangun cluster dengan server web dalam jumlah besar. Untuk penerapan kami menggunakan helm.
$ helm install stable/memcached --name sessionphp.ini - di sini gambar berisi pengaturan untuk menyimpan sesi di memcached
Kami menggunakan Variabel Lingkungan untuk meneruskan data tentang host dengan memcached .
Hal ini memungkinkan Anda untuk menggunakan kode yang sama di lingkungan dev, stage, test, prod (nama host memcached di dalamnya akan berbeda, jadi kita perlu meneruskan nama host unik untuk sesi ke setiap lingkungan).
Penyimpanan cache Bitrix
Kita memerlukan penyimpanan yang toleran terhadap kesalahan sehingga semua pod dapat menulis dan membaca.
Kami juga menggunakan memcached.
Solusi ini direkomendasikan oleh Bitrix sendiri.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php - di sini di Bitrix ditentukan di mana cache disimpan
Kami juga menggunakan Variabel Lingkungan.
Krontaski
Ada beberapa pendekatan berbeda untuk menjalankan Crontasks di Kubernetes.
- penerapan terpisah dengan pod untuk menjalankan Crontasks
- cronjob untuk menjalankan crontask (jika ini adalah aplikasi web - dengan wget , atau kubectl exec di dalam salah satu pod pekerja, dll.)
- dan sebagainya
Anda dapat berdebat tentang mana yang paling benar, tetapi dalam kasus ini kami memilih opsi “penerapan terpisah dengan pod untuk Crontasks”
Bagaimana hal itu dilakukan:
- tambahkan tugas cron melalui ConfigMap atau melalui file config/addcron
- dalam satu contoh kami meluncurkan wadah yang identik dengan pod pekerja + mengizinkan pelaksanaan tugas mahkota di dalamnya
- basis kode yang sama digunakan, berkat penyatuan, perakitan kontainer menjadi sederhana
Apa manfaat yang kita dapatkan:
- kami telah menjalankan Crontask di lingkungan yang identik dengan lingkungan pengembang (buruh pelabuhan)
- Crontask tidak perlu “ditulis ulang” untuk Kubernetes, mereka bekerja dalam bentuk dan basis kode yang sama seperti sebelumnya
- tugas cron dapat ditambahkan oleh semua anggota tim yang memiliki hak komit pada cabang produksi, bukan hanya admin
Modul Southbridge K8SDeploy dan pengeditan kode dari panel admin
Kami berbicara tentang peningkatan di bawah?
Bagaimana mengarahkan lalu lintas ke sana?
Hore, kami menulis modul untuk ini di PHP :) Ini adalah modul klasik kecil untuk Bitrix. Ini belum tersedia untuk umum, tapi kami berencana untuk membukanya.
Modul diinstal seperti modul biasa di Bitrix:
Dan tampilannya seperti ini:
Ini memungkinkan Anda untuk mengatur cookie yang mengidentifikasi administrator situs dan memungkinkan Kubernetes mengirimkan lalu lintas ke pod pemutakhiran.
Ketika perubahan selesai, Anda perlu mengklik git push, perubahan kode akan dikirim ke git, kemudian sistem akan membuat image dengan versi kode baru dan “meluncurkannya” ke seluruh cluster, menggantikan pod lama .
Ya, ini sedikit sulit, tetapi pada saat yang sama kami mempertahankan arsitektur layanan mikro dan tidak menghilangkan kesempatan favorit pengguna Bitrix untuk memperbaiki kode dari panel admin. Pada akhirnya, ini adalah sebuah opsi; Anda dapat menyelesaikan masalah pengeditan kode dengan cara yang berbeda.
Bagan helm
Untuk membangun aplikasi di Kubernetes, kami biasanya menggunakan manajer paket Helm.
Untuk solusi Bitrix kami di Kubernetes, Sergey Bondarev, administrator sistem terkemuka kami, menulis bagan Helm khusus.
Ia membangun pod pekerja, ugrade, cron, mengonfigurasi ingress, layanan, dan mentransfer variabel dari rahasia Kubernetes ke pod.
Kami menyimpan kode di Gitlab, dan kami juga menjalankan build Helm dari Gitlab.
Singkatnya, tampilannya seperti ini
$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=productionHelm juga memungkinkan Anda melakukan rollback yang “mulus” jika tiba-tiba terjadi kesalahan selama penerapan. Sangat menyenangkan ketika Anda tidak panik “memperbaiki kode melalui ftp karena prodnya jatuh,” tetapi Kubernetes melakukannya secara otomatis, dan tanpa downtime.
Menyebarkan
Ya, kami adalah penggemar Gitlab & Gitlab CI, kami menggunakannya :)
Saat melakukan komitmen di Gitlab ke repositori proyek, Gitlab meluncurkan pipeline yang menerapkan versi lingkungan baru.
Tahapan:
- build (membangun image Docker baru)
- tes (pengujian)
- membersihkan (menghapus lingkungan pengujian)
- push (kami mengirimkannya ke registri Docker)
- deploy (kami menyebarkan aplikasi ke Kubernetes melalui Helm).
Hore sudah siap, yuk kita implementasikan!
Nah, atau ajukan pertanyaan jika ada.
Jadi apa yang kami lakukan
Dari sudut pandang teknis:
- Bitrix yang melakukan buruh pelabuhan;
- “memotong” Bitrix ke dalam wadah, yang masing-masing menjalankan fungsi minimum;
- mencapai kondisi kontainer tanpa kewarganegaraan;
- memecahkan masalah dengan memperbarui Bitrix di Kubernetes;
- semua fungsi Bitrix terus berfungsi (hampir semuanya);
- Kami mengerjakan penerapan ke Kubernetes dan melakukan rollback antar versi.
Dari sudut pandang bisnis:
- toleransi kesalahan;
- Alat Kubernetes (integrasi yang mudah dengan Gitlab CI, penerapan yang lancar, dll);
- kata sandi rahasia (hanya dapat dilihat oleh mereka yang secara langsung diberikan akses terhadap kata sandi tersebut);
- Akan lebih mudah untuk membuat lingkungan tambahan (untuk pengembangan, pengujian, dll.) dalam satu infrastruktur.
Sumber: www.habr.com