Pertemuan pentadbir sistem Sysadminka sedang berlangsung di Chelyabinsk, dan pada yang terakhir saya memberikan laporan tentang penyelesaian kami untuk menjalankan aplikasi pada 1C-Bitrix di Kubernetes.
Bitrix, Kubernetes, Ceph - campuran yang hebat?
Saya akan memberitahu anda bagaimana kami mengumpulkan penyelesaian yang berkesan daripada semua ini.
Mari kita pergi!
Pertemuan itu berlangsung pada 18 April di Chelyabinsk. Anda boleh membaca tentang pertemuan kami di dan lihatlah .
Jika anda ingin datang kepada kami dengan laporan atau sebagai pendengar - dialu-alukan, tulis kepada [e-mel dilindungi] dan di Telegram t.me/vadimisakanov.
Laporan saya
Penyelesaian "Bitrix dalam Kubernetes, versi Southbridge 1.0"
Saya akan bercakap tentang penyelesaian kami dalam format "untuk boneka dalam Kubernetes", seperti yang dilakukan pada pertemuan itu. Tetapi saya menganggap bahawa anda tahu perkataan Bitrix, Docker, Kubernetes, Ceph sekurang-kurangnya pada peringkat artikel di Wikipedia.
Apakah yang sedia dibuat tentang Bitrix dalam Kubernetes?
Terdapat sedikit maklumat di seluruh Internet tentang pengendalian aplikasi Bitrix dalam Kubernetes.
Saya hanya menemui bahan-bahan ini:
Laporan oleh Alexander Serbul, 1C-Bitrix, dan Anton Tuzlukov dari Qsoft:
Saya mengesyorkan mendengarnya.
Membangunkan penyelesaian anda sendiri daripada pengguna .
Lebih banyak ditemui .
Aaand... sebenarnya, itu sahaja.
Saya memberi amaran kepada anda, kami belum menyemak kualiti penyelesaian dalam pautan di atas :)
Ngomong-ngomong, semasa menyediakan penyelesaian kami, saya bercakap dengan Alexander Serbul, maka laporannya belum muncul, jadi dalam slaid saya terdapat item "Bitrix tidak menggunakan Kubernetes."
Tetapi sudah ada banyak imej Docker siap sedia untuk menjalankan Bitrix di Docker:
Adakah ini cukup untuk mencipta penyelesaian lengkap untuk Bitrix dalam Kubernetes?
Tidak. Terdapat sejumlah besar masalah yang perlu diselesaikan.
Apakah masalah dengan Bitrix dalam Kubernetes?
Pertama, imej siap pakai daripada Dockerhub tidak sesuai untuk Kubernetes
Jika kita ingin membina seni bina perkhidmatan mikro (dan dalam Kubernetes yang biasa kita lakukan), kita perlu memisahkan aplikasi Kubernetes kita ke dalam bekas dan minta setiap bekas melaksanakan satu fungsi kecil (dan lakukannya dengan baik). Kenapa hanya satu? Pendek kata, lebih mudah lebih dipercayai.
Untuk lebih spesifik, tonton artikel dan video ini, sila:
Imej Docker dalam Dockerhub terutamanya dibina berdasarkan prinsip semua-dalam-satu, jadi kami masih perlu membuat basikal kami sendiri dan juga mencipta imej dari awal.
Kedua - kod tapak disunting dari panel pentadbir
Kami mencipta bahagian baharu di tapak - kod telah dikemas kini (direktori dengan nama bahagian baharu telah ditambahkan).
Jika anda menukar sifat komponen daripada panel pentadbir, kod itu berubah.
Kubernetes "secara lalai" tidak boleh berfungsi dengan ini; bekas mestilah tanpa negara.
Sebab: Setiap bekas (pod) dalam kluster hanya memproses sebahagian daripada trafik. Jika anda menukar kod dalam hanya satu bekas (pod), maka kod akan berbeza dalam pod yang berbeza, tapak akan berfungsi secara berbeza dan versi tapak yang berbeza akan ditunjukkan kepada pengguna yang berbeza. Awak tak boleh hidup macam tu.
Ketiga - anda perlu menyelesaikan masalah dengan penempatan
Jika kami mempunyai pelayan monolit dan satu "klasik", semuanya agak mudah: kami menggunakan pangkalan kod baharu, memindahkan pangkalan data, menukar trafik kepada versi baharu kod. Penukaran berlaku serta-merta.
Jika kita mempunyai tapak dalam Kubernetes, potong kepada perkhidmatan mikro, terdapat banyak bekas dengan kod - oh. Anda perlu mengumpul bekas dengan versi baharu kod, melancarkannya dan bukannya yang lama, memindahkan pangkalan data dengan betul dan sebaik-baiknya melakukan ini tanpa disedari oleh pelawat. Mujurlah, Kubernetes membantu kami dengan ini, menyokong sekumpulan besar jenis penggunaan yang berbeza.
Keempat - anda perlu menyelesaikan isu penyimpanan statik
Jika tapak anda "hanya" 10 gigabait dan anda menggunakan sepenuhnya dalam bekas, anda akan mendapat 10 kontena gigabait yang mengambil masa selama-lamanya untuk digunakan.
Anda perlu menyimpan bahagian "paling berat" tapak di luar bekas, dan persoalan timbul tentang cara melakukan ini dengan betul
Apa yang kurang daripada penyelesaian kami?
Keseluruhan kod Bitrix tidak dibahagikan kepada fungsi mikro/perkhidmatan mikro (supaya pendaftaran berasingan, modul kedai dalam talian adalah berasingan, dsb.). Kami menyimpan keseluruhan pangkalan kod dalam setiap bekas.
Kami juga tidak menyimpan pangkalan data dalam Kubernetes (saya masih melaksanakan penyelesaian dengan pangkalan data dalam Kubernetes untuk persekitaran pembangunan, tetapi bukan untuk pengeluaran).
Ia masih akan dapat dilihat oleh pentadbir tapak bahawa tapak tersebut berjalan pada Kubernetes. Fungsi "semakan sistem" tidak berfungsi dengan betul; untuk mengedit kod tapak daripada panel pentadbir, anda mesti mengklik butang "Saya mahu mengedit kod" terlebih dahulu.
Masalah telah dikenal pasti, keperluan untuk melaksanakan perkhidmatan mikro telah ditentukan, matlamatnya jelas - untuk mendapatkan sistem yang berfungsi untuk menjalankan aplikasi pada Bitrix dalam Kubernetes, memelihara kedua-dua keupayaan Bitrix dan kelebihan Kubernetes. Mari kita mulakan pelaksanaan.
seni bina
Terdapat banyak pod "berfungsi" dengan pelayan web (pekerja).
Satu di bawah dengan tugas cron (hanya satu diperlukan).
Satu peningkatan untuk mengedit kod tapak daripada panel pentadbir (juga hanya satu diperlukan).
Kami menyelesaikan soalan:
- Di mana untuk menyimpan sesi?
- Di mana untuk menyimpan cache?
- Di mana untuk menyimpan statik, bukan untuk meletakkan gigabait statik dalam sekumpulan bekas?
- Bagaimanakah pangkalan data akan berfungsi?
Imej Docker
Kita mulakan dengan membina imej Docker.
Pilihan yang ideal ialah kami mempunyai satu imej universal, berdasarkannya kami mendapat pod pekerja, pod dengan Crontasks dan pod naik taraf.
.
Ia termasuk nginx, apache/php-fpm (boleh dipilih semasa membina), msmtp untuk menghantar mel, dan cron.
Semasa memasang imej, keseluruhan pangkalan kod tapak disalin ke direktori /app (kecuali bahagian tersebut yang akan kami alihkan ke storan kongsi yang berasingan).
Perkhidmatan mikro, perkhidmatan
pod pekerja:
- Bekas dengan nginx + container apache/php-fpm + msmtp
- Tidak berjaya memindahkan msmtp ke dalam perkhidmatan mikro yang berasingan, Bitrix mula marah kerana ia tidak boleh menghantar mel secara langsung
- Setiap bekas mempunyai pangkalan kod yang lengkap.
- Larangan menukar kod dalam bekas.
cron di bawah:
- bekas dengan apache, php, cron
- asas kod lengkap disertakan
- larangan menukar kod dalam bekas
naik taraf di bawah:
- bekas nginx + bekas apache/php-fpm + msmtp
- Tiada larangan menukar kod dalam bekas
penyimpanan sesi
Storan cache bitrix
Satu lagi perkara penting: kami menyimpan kata laluan untuk menyambung ke segala-galanya, dari pangkalan data ke mel, dalam rahsia kubernetes. Kami mendapat bonus: kata laluan hanya kelihatan kepada mereka yang kami berikan akses kepada rahsia, dan bukan kepada semua orang yang mempunyai akses kepada pangkalan kod projek.
Storan untuk statik
Anda boleh menggunakan apa sahaja: ceph, nfs (tetapi kami tidak mengesyorkan nfs untuk pengeluaran), storan rangkaian daripada penyedia awan, dsb.
Storan perlu disambungkan dalam bekas ke direktori /upload/ tapak dan direktori lain dengan kandungan statik.
Pangkalan data
Untuk memudahkan, kami mengesyorkan agar pangkalan data dipindahkan ke luar Kubernetes. Pangkalan dalam Kubernetes adalah tugas kompleks yang berasingan; ia akan menjadikan skema susunan magnitud lebih kompleks.
Storan sesi
Kami menggunakan memcached :)
Ia mengendalikan storan sesi dengan baik, dikelompokkan dan disokong "secara asli" sebagai session.save_path dalam php. Sistem sedemikian telah diuji berkali-kali dalam seni bina monolitik klasik, apabila kami membina kelompok dengan sejumlah besar pelayan web. Untuk penempatan kami menggunakan helm.
$ helm install stable/memcached --name sessionphp.ini - di sini imej mengandungi tetapan untuk menyimpan sesi dalam memcached
Kami menggunakan Pembolehubah Persekitaran untuk menghantar data tentang hos dengan memcached .
Ini membolehkan anda menggunakan kod yang sama dalam persekitaran pembangun, peringkat, ujian, prod (nama hos memcach di dalamnya akan berbeza, jadi kami perlu menghantar nama hos unik untuk sesi kepada setiap persekitaran).
Storan cache bitrix
Kami memerlukan storan tahan kesalahan yang boleh ditulis dan dibaca oleh semua pod.
Kami juga menggunakan memcached.
Penyelesaian ini disyorkan oleh Bitrix sendiri.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php - di sini dalam Bitrix ia dinyatakan di mana cache disimpan
Kami juga menggunakan Pembolehubah Persekitaran.
Krontaski
Terdapat pendekatan yang berbeza untuk menjalankan Crontasks dalam Kubernetes.
- penempatan berasingan dengan pod untuk menjalankan Crontasks
- cronjob untuk melaksanakan crontask (jika ini adalah aplikasi web - dengan wget , atau kubectl exec di dalam salah satu pod pekerja, dsb.)
- dan lain-lain.
Anda boleh berhujah tentang yang paling betul, tetapi dalam kes ini kami memilih pilihan "penyerahan berasingan dengan pod untuk Crontasks"
Bagaimana ia dilakukan:
- tambah tugas cron melalui ConfigMap atau melalui fail config/addcron
- dalam satu keadaan kami melancarkan bekas yang sama dengan pod pekerja + membenarkan pelaksanaan tugas mahkota di dalamnya
- asas kod yang sama digunakan, terima kasih kepada penyatuan, pemasangan kontena adalah mudah
Apa kebaikan yang kita dapat:
- kami telah menjalankan Crontasks dalam persekitaran yang sama dengan persekitaran pembangun (docker)
- Crontask tidak perlu "ditulis semula" untuk Kubernetes, ia berfungsi dalam bentuk yang sama dan dalam pangkalan kod yang sama seperti sebelumnya
- tugas cron boleh ditambahkan oleh semua ahli pasukan dengan hak komit kepada cawangan pengeluaran, bukan hanya pentadbir
Modul Southbridge K8SDeploy dan penyuntingan kod daripada panel pentadbir
Kita bercakap tentang naik taraf di bawah?
Bagaimana untuk mengarahkan lalu lintas ke sana?
Hore, kami menulis modul untuk ini dalam PHP :) Ini adalah modul klasik kecil untuk Bitrix. Ia belum lagi tersedia secara umum, tetapi kami merancang untuk membukanya.
Modul dipasang seperti modul biasa dalam Bitrix:
Dan ia kelihatan seperti ini:
Ia membolehkan anda menetapkan kuki yang mengenal pasti pentadbir tapak dan membenarkan Kubernetes menghantar trafik ke pod naik taraf.
Apabila perubahan selesai, anda perlu mengklik git push, perubahan kod akan dihantar ke git, kemudian sistem akan membina imej dengan versi baharu kod dan "melancarkannya" merentasi kluster, menggantikan pod lama .
Ya, ia agak sukar, tetapi pada masa yang sama kami mengekalkan seni bina perkhidmatan mikro dan tidak mengambil peluang kegemaran pengguna Bitrix untuk membetulkan kod daripada panel pentadbir. Pada akhirnya, ini adalah pilihan; anda boleh menyelesaikan masalah mengedit kod dengan cara yang berbeza.
Carta helm
Untuk membina aplikasi pada Kubernetes, kami biasanya menggunakan pengurus pakej Helm.
Untuk penyelesaian Bitrix kami di Kubernetes, Sergey Bondarev, pentadbir sistem terkemuka kami, menulis carta Helm khas.
Ia membina pekerja, ugrade, cron pod, mengkonfigurasi kemasukan, perkhidmatan dan memindahkan pembolehubah daripada rahsia Kubernetes ke pod.
Kami menyimpan kod dalam Gitlab, dan kami juga menjalankan binaan Helm daripada Gitlab.
Pendek kata, ia kelihatan 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 membolehkan anda melakukan pengembalian "lancar" jika tiba-tiba berlaku masalah semasa penggunaan. Seronok apabila anda tidak panik "betulkan kod melalui ftp kerana prod jatuh," tetapi Kubernetes melakukannya secara automatik, dan tanpa masa henti.
Sebarkan
Ya, kami peminat Gitlab & Gitlab CI, kami menggunakannya :)
Apabila membuat komitmen dalam Gitlab ke repositori projek, Gitlab melancarkan saluran paip yang menggunakan versi baharu persekitaran.
Peringkat:
- bina (membina imej Docker baharu)
- ujian (ujian)
- membersihkan (mengeluarkan persekitaran ujian)
- push (kami menghantarnya ke pendaftaran Docker)
- gunakan (kami menggunakan aplikasi ke Kubernetes melalui Helm).
Hore, sudah siap, mari kita laksanakan!
Baik, atau tanya soalan jika ada.
Jadi apa yang kami buat
Dari sudut teknikal:
- Bitrix berlabuh;
- "potong" Bitrix ke dalam bekas, setiap satunya menjalankan fungsi minimum;
- mencapai keadaan bekas tanpa negara;
- menyelesaikan masalah dengan mengemas kini Bitrix dalam Kubernetes;
- semua fungsi Bitrix terus berfungsi (hampir semua);
- Kami mengusahakan penggunaan ke Kubernetes dan rollback antara versi.
Dari sudut perniagaan:
- toleransi kesalahan;
- Alat Kubernetes (integrasi mudah dengan Gitlab CI, penggunaan lancar, dll);
- kata laluan rahsia (hanya kelihatan kepada mereka yang diberi akses terus kepada kata laluan);
- Mudah untuk mencipta persekitaran tambahan (untuk pembangunan, ujian, dll.) dalam satu infrastruktur.
Sumber: www.habr.com