Administrator sistem Sysadminka bertemu di Chelyabinsk, dan pada akhirnya saya membuat laporan tentang solusi kami untuk bekerja aplikasi pada 1C-Bitrix di Kubernetes.
Bitrix, Kubernetes, Ceph - campuran yang hebat?
Saya akan memberi tahu Anda bagaimana kami menyusun solusi yang berfungsi dari semua ini.
Ayo pergi!
Mitap diadakan pada 18 April di Chelyabinsk. Anda dapat membaca tentang mitaps kami di Timepad dan menonton di YouTube .
Jika Anda ingin datang kepada kami dengan laporan atau sebagai pendengar - untuk Wellcome, menulis ke vadim.isakanov@gmail.com dan Telegram t.me/vadimisakanov.
Laporan saya
Slide
Bitrix dalam Solusi Kubernetes Southbridge 1.0
Saya akan berbicara tentang solusi kami dalam format "untuk boneka di Kubernetes", seperti yang dilakukan pada pertemuan tersebut. Tapi saya kira kata Bitrix, Docker, Kubernetes, Ceph diketahui oleh Anda setidaknya di tingkat artikel Wikipedia.
Apa yang Anda miliki tentang Bitrix di Kubernetes?
Di seluruh Internet hanya ada sedikit informasi tentang pengoperasian aplikasi pada Bitrix di Kubernetes.
Saya hanya menemukan bahan-bahan seperti itu:
Laporan oleh Alexander Serbul, 1C-Bitrix, dan Anton Tuzlukov dari Qsoft:
Saya sarankan mendengarkannya.
Pengembangan solusi sendiri dari serkyron pengguna di Habré .
Saya juga menemukan solusi seperti itu .
Aku ... sebenarnya.
Saya memperingatkan Anda, kami tidak memeriksa kualitas solusi menggunakan tautan di atas :-)
Ngomong-ngomong, ketika menyiapkan solusi kami, saya berbicara dengan Alexander Serbul, maka laporannya belum, jadi di slide saya ada item “Bitrix tidak menggunakan Kubernetes”.
Tetapi sudah ada banyak gambar Docker yang siap pakai untuk Bitrix agar berfungsi di Docker: https://hub.docker.com/search?q=bitrix&type=image
Apakah ini cukup untuk membuat solusi Bitrix lengkap di Kubernetes?
Tidak. Ada sejumlah besar masalah yang perlu ditangani.
Apa masalah dengan Bitrix di Kubernetes?
Pertama - gambar siap pakai Dockerhub tidak cocok untuk Kubernetes
Jika kita ingin membangun arsitektur microservice (dan di Kubernet biasanya kita inginkan), aplikasi di Kubernet perlu dibagi ke dalam wadah dan memastikan bahwa setiap wadah melakukan satu fungsi kecil (dan melakukannya dengan baik). Kenapa hanya satu? Singkatnya - semakin sederhana, semakin dapat diandalkan.
Jika lebih otentik, lihat artikel dan video ini, silakan: https://habr.com/en/company/southbridge/blog/426637/
Gambar Docker di Dockerhub terutama dibangun berdasarkan prinsip "all in one", jadi kami masih harus membuat sepeda kami sendiri dan bahkan membuat gambar dari awal.
Kedua - kode situs diedit dari panel admin
Kami membuat bagian baru di situs - kode diperbarui (direktori dengan nama bagian baru ditambahkan).
Mengubah properti komponen dari panel admin - kode telah berubah.
Kubernet "secara default" tidak tahu cara bekerja dengan ini, kontainer harus stateless.
Alasan: setiap kontainer (sub) di cluster hanya memproses sebagian dari lalu lintas. Jika Anda mengubah kode hanya dalam satu wadah (bawah), maka di pod yang berbeda kodenya akan berbeda, situs akan bekerja secara berbeda, versi situs yang berbeda akan ditampilkan kepada pengguna yang berbeda. Anda tidak bisa hidup seperti itu.
Ketiga - Anda harus menyelesaikan masalah penyebaran
Jika kita memiliki server monolith dan satu "klasik", semuanya sangat sederhana: kita menggunakan basis kode baru, memigrasi basis data, mengalihkan lalu lintas ke versi kode yang baru. Perpindahan terjadi secara instan.
Jika kita memiliki situs web di Kubernetes, itu digergaji ke dalam layanan microser, ada banyak wadah dengan kode. Anda perlu mengumpulkan kontainer dengan versi kode yang baru, meluncurkannya alih-alih yang lama, menjalankan migrasi basis data dengan benar, dan idealnya melakukan hal ini tanpa terlihat kepada pengunjung. Untungnya, Kubernetes membantu kami dalam hal ini, mendukung seluruh cloud dari berbagai jenis penyebaran.
Keempat - Anda harus menyelesaikan masalah penyimpanan statis
Jika situs Anda memiliki berat "hanya" 10 gigabyte dan Anda menerapkannya sepenuhnya dalam wadah, Anda akan mendapatkan kontainer dengan berat 10 gigabytes, yang akan digunakan selamanya.
Anda perlu menyimpan bagian-bagian yang paling “berat” dari situs di luar kontainer, dan muncul pertanyaan bagaimana melakukannya dengan benar
Apa yang tidak ada dalam keputusan kami
Cukup seluruh kode Bitrix untuk fungsi mikro / layanan mikro tidak dipotong (sehingga pendaftaran terpisah, modul toko online terpisah, dll.). Kami menyimpan seluruh basis kode di setiap wadah secara keseluruhan.
Kami juga tidak menyimpan basis di Kubernetes (namun saya mengimplementasikan solusi dengan basis di Kubernetes untuk lingkungan pengembang, tetapi tidak untuk produksi).
Administrator situs akan tetap memperhatikan bahwa situs tersebut berfungsi di Kubernetes. Fungsi "pemeriksaan sistem" tidak berfungsi dengan benar, untuk mengedit kode situs dari panel admin, Anda harus terlebih dahulu mengklik tombol "Saya ingin mengedit kode".
Kami memutuskan masalah, kami memutuskan kebutuhan untuk mengimplementasikan microservice, tujuannya jelas - untuk mendapatkan sistem kerja untuk bekerja pada aplikasi Bitrix di Kubernetes, menjaga kemampuan Bitrix dan keunggulan Kubernetes. Kami mulai implementasi.
Arsitektur
Banyak perapian "bekerja" dengan server web (pekerja).
Satu di bawah dengan mahkota mahkota (hanya satu).
Satu peningkatan untuk mengedit kode situs dari panel admin (hanya satu yang juga diperlukan).
Kami memecahkan masalah:
- Tempat menyimpan sesi?
- Di mana menyimpan cache?
- Di mana menyimpan statika, bukan untuk menempatkan gigabyte statika di tumpukan kontainer?
- Bagaimana cara kerja basis data?
Gambar buruh pelabuhan
Kami mulai dengan membangun gambar Docker.
Pilihan yang ideal adalah bahwa kita memiliki satu gambar universal, atas dasar itu kita mendapatkan pod pekerja, dan pod dengan tanda kurung, dan memutakhirkan pod.
Kami membuat gambar seperti itu .
Ini termasuk nginx, apache / php-fpm (dapat dipilih selama perakitan), msmtp untuk mengirim surat, dan cron.
Saat merakit gambar, basis kode lengkap situs disalin ke direktori / app (dengan pengecualian bagian-bagian yang akan kami tempatkan di penyimpanan bersama yang terpisah).
Layanan mikro, layanan
perapian pekerja:
- Wadah dengan nginx + apache / php-fpm + wadah msmtp
- msmtp tidak bekerja dalam microservice terpisah, Bitrix mulai membenci bahwa ia tidak dapat mengirim email secara langsung
- Setiap wadah memiliki basis kode yang lengkap.
- Larangan mengubah kode dalam wadah.
cron di bawah:
- wadah dengan apache, php, cron
- basis kode lengkap disertakan
- larangan mengubah kode dalam wadah
tingkatkan di bawah:
- wadah dengan nginx + apache / php-fpm + wadah msmtp
- tidak ada larangan mengubah kode dalam wadah
penyimpanan sesi
Penyimpanan Cache Bitrix
Lebih penting: kami menyimpan kata sandi untuk terhubung ke segala sesuatu mulai dari basis data hingga surat dalam rahasia kubernet. Kami mendapat bonus, kata sandi hanya dapat dilihat oleh orang-orang yang kami beri akses ke rahasia, dan tidak untuk semua orang yang memiliki akses ke basis kode proyek.
Penyimpanan Statis
Anda dapat menggunakan apa saja: ceph, nfs (tetapi nfs tidak direkomendasikan untuk produksi), penyimpanan jaringan dari penyedia "cloud", dll.
Penyimpanan perlu dihubungkan dalam wadah ke / upload / direktori situs dan direktori lain dengan statis.
Basis data
Untuk kesederhanaan, sebaiknya pindahkan pangkalan di luar Kubernetes. Basis di Kubernetes adalah tugas kompleks yang terpisah, itu akan membuat sirkuit lebih rumit.
Penyimpanan Sesi
Kami menggunakan memcached :)
Itu pekerjaan yang baik menyimpan sesi, cluster, dan secara native didukung sebagai session.save_path di php. Sistem seperti itu sudah sering dilakukan dalam arsitektur monolitik klasik, ketika kami membangun cluster dengan sejumlah besar server web. Untuk penyebaran kami menggunakan helm.
$ helm install stable/memcached --name session
php.ini - di sini di pengaturan gambar diatur untuk menyimpan sesi dalam memcached
Kami menggunakan Variabel Lingkungan untuk mentransfer data host dengan memcached https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/ .
Ini memungkinkan Anda untuk menggunakan kode yang sama di lingkungan dev, stage, test, prod (nama-nama host memcached di dalamnya akan berbeda, jadi kami perlu mentransfer nama host unik untuk sesi ke masing-masing lingkungan).
Penyimpanan Cache Bitrix
Kami membutuhkan penyimpanan yang aman dari kegagalan di mana semua perapian dapat menulis dan dari mana kami dapat membaca.
Kami juga menggunakan memcached.
Solusi ini direkomendasikan oleh Bitrix sendiri.
$ helm install stable/memcached --name cache
bitrix / .settings_extra.php - di sini di Bitrix sudah diatur di mana kita menyimpan cache
Kami juga menggunakan Variabel Lingkungan.
Krontaski
Ada berbagai pendekatan untuk melakukan crontab di Kubernetes.
- pisahkan penempatan dengan perapian
- cronjob untuk melakukan crontask (jika itu adalah aplikasi web - dengan wget https: // $ host $ cronjobname , atau exec kubectl di dalam salah satu perapian pekerja, dll.)
- dll.
Anda dapat berdebat tentang yang paling benar, tetapi dalam hal ini kami memilih opsi "penyebaran terpisah dengan pod untuk crontask"
Bagaimana cara melakukannya:
- tambahkan mahkota melalui ConfigMap atau melalui config / addcron
- dalam satu contoh, jalankan wadah yang identik dengan sub + pekerja yang memungkinkan eksekusi tugas mahkota di dalamnya
- basis kode yang sama digunakan, berkat penyatuan, perakitan kontainer sederhana
Apa yang baik yang kita dapatkan:
- kami telah bekerja crontaski di lingkungan yang identik dengan lingkungan pengembangan (buruh pelabuhan)
- Krontaski tidak perlu “ditulis ulang” untuk Kubernetes, mereka bekerja dalam bentuk yang sama dan dalam basis kode yang sama seperti sebelumnya
- anggota mahkota dapat menambahkan semua anggota tim dengan hak komit ke cabang produksi, dan bukan hanya admin
Modul Southbridge K8SDeploy dan kode pengeditan dari panel admin
Kami berbicara tentang peningkatan di bawah?
Dan bagaimana mengarahkan lalu lintas ke sana?
Hore, kami menulis modul untuk ini di php :) Ini adalah modul klasik kecil untuk Bitrix. Itu belum tersedia untuk umum, tetapi kami berencana untuk membukanya.
Modul ini diinstal sebagai modul reguler di Bitrix:
Dan terlihat seperti ini:
Ini memungkinkan Anda untuk mengatur cookie yang mengidentifikasi administrator situs dan memungkinkan Kubernetes untuk mengirim lalu lintas untuk ditingkatkan di bawah.
Ketika perubahan selesai, Anda perlu mengklik git push, perubahan kode akan dikirim ke git, maka sistem akan mengumpulkan gambar dengan versi kode yang baru dan "menggulung" melintasi cluster, menggantikan pod lama.
Ya, ini sedikit penopang, tetapi pada saat yang sama, kami mempertahankan arsitektur layanan mikro dan tidak mengambil kesempatan favorit dari pengguna Bitrix untuk memperbaiki kode dari panel admin. Pada akhirnya, ini adalah opsi, Anda dapat memecahkan masalah mengedit kode dengan cara yang berbeda.
Grafik helm
Untuk membangun aplikasi di Kubernetes, kami biasanya menggunakan manajer paket Helm.
Untuk solusi Bitrix kami di Kubernetes, Sergey Bondarev, administrator sistem utama kami, menulis bagan Helm khusus.
Itu membangun pekerja, ugrade, perapian cron, mengkonfigurasi ingresses, layanan, transfer variabel dari rahasia Kubernetes ke perapian.
Kami menyimpan kode di Gitlab, dan kami juga menjalankan perakitan Helm dari Gitlab.
Singkatnya, ini terlihat seperti ini
$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=production
Helm juga memungkinkan Anda melakukan rollback "mulus", jika terjadi kesalahan selama pemasangan. Sangat menyenangkan ketika Anda tidak panik "memperbaiki kode untuk ftp, karena prod telah jatuh", dan Kubernetes melakukannya secara otomatis, tanpa downtime.
Sebarkan
Ya, kami adalah penggemar Gitlab & Gitlab CI, gunakan itu :)
Ketika melakukan ke Gitlab di repositori proyek, Gitlab meluncurkan pipa yang akan menggunakan versi lingkungan yang baru.
Tahapan:
- build (bangun gambar Docker baru)
- tes (tes)
- bersihkan (lepaskan lingkungan uji)
- push (kirim ke register Docker)
- deploy (kami menyebarkan aplikasi di Kubernetes via Helm).
Hore, kami siap memperkenalkannya!
Nah, atau ajukan pertanyaan, jika ada.
Jadi apa yang sudah kita lakukan
Dari sudut pandang teknis:
- Bitrix buruh pelabuhan;
- "Potong" Bitrix ke dalam wadah, yang masing-masing menjalankan fungsi minimum;
- mencapai status kewarganegaraan kontainer;
- memecahkan masalah dengan memperbarui Bitrix di Kubernetes;
- semua fungsi Bitrix terus bekerja (hampir semua);
- penyebaran yang berhasil di Kubernetes dan rollback antar versi.
Dari perspektif bisnis:
- toleransi kesalahan;
- Alat Kubernetes (integrasi mudah dengan Gitlab CI, penyebaran tanpa batas, dll);
- kata sandi rahasia (hanya dapat dilihat oleh mereka yang secara langsung diberikan akses ke kata sandi);
- lebih mudah untuk membuat lingkungan tambahan (untuk pengembangan, pengujian, dll.) di dalam satu infrastruktur.