Saya ingin menceritakan sebuah kisah tentang bagaimana aplikasi itu diluncurkan di Openshift. Juga dalam permainan, kami mempertimbangkan utilitas untuk mengelola aplikasi di dalam OpenShift. Ini adalah transkrip kinerja di kubernetes SPB meetup # 3 ..
Tujuan
Biasanya, klien dikerahkan di server terpisah, tetapi di sini tugas datang, untuk menguji peluang untuk berjalan di openshift dan mengumpulkan penggaruk.
Pertama, Anda perlu berbicara tentang aplikasi kami. Sebuah proyek dengan sejarah yang kaya. Digunakan di organisasi besar dan mungkin Anda masing-masing secara tidak langsung berpotongan. Aplikasi ini mendukung banyak basis data, integrasi, dll., Dll.
Prasyarat
Aplikasi harus bekerja di lingkungan yang sangat berbeda. Akibatnya, dokumentasi instalasi kami sangat luas. Tetapi jika Anda memandang rendah Anda, maka tidak ada yang rumit:
- Terapkan skema basis data.
- Konfigurasikan server aplikasi.
- Pasang lisensi.
- Kustomisasi aplikasi dan integrasi dengan sistem eksternal.
Tetapi dunia ini kejam, kami memiliki sejumlah batasan:
- Aplikasi hanya dapat dibangun secara khusus di Jenkins, yang terlibat dalam penandatanganan. Dan hanya di sana.
- Tidak ada akses dari klien OpenShift ke lingkungan pengembangan.
- Untuk sejumlah alasan ideologis, tidak mungkin untuk menggunakan kembali gambar Docker yang ada untuk pengembangan.
- Kami memiliki playbook yang memungkinkan untuk menginstal dan mengkonfigurasi aplikasi di server.
Demo kontainer yang memungkinkan
Ansible container adalah perangkat lunak sumber terbuka yang bertujuan untuk mengotomatisasi perakitan, penyebaran, dan kontrol proses dari wadah. Seperti yang mungkin Anda tebak dari namanya. Ansible digunakan untuk membuat kontainer. Kami telah menulis peran yang mungkin untuk menginstal dan menggunakan aplikasi di atas server, jadi kami memutuskan untuk tidak menemukan kembali roda dan menggunakannya kembali. Tidak hanya itu akan menjadi alat yang sempurna, tetapi penggunaan kembali yang cepat dari peran yang ada adalah faktor yang menentukan untuk demo.
Pada umumnya, untuk melakukan demo, kami mengambil peran yang ada yang mengonfigurasi segalanya dan segalanya, dan membuat "wadah monolitik". Tidak ada masalah khusus dengan pengumpulan wadah, karena Openshift memiliki beberapa rekomendasi hebat , tetapi saya akan menyebutkan secara terpisah:
- Peran-peran perlu diselesaikan. kami menggunakan systemd.
- Secara default, untuk alasan keamanan, dilarang menggunakan syscall di openshift. Hasilnya, akan ada nuansa dengan chroot, sudo. Hai CVE-2019-5736 .
- Demikian pula, untuk alasan keamanan, wadah diluncurkan dari bawah pengguna dengan ID acak, ini juga merupakan perilaku khusus.
Gagasan utama pada saat ini adalah kami membuat demo dengan sangat cepat.
Demo beberapa kontainer
Kontainer demo memenuhi perannya dan kami menggergajinya menjadi komponen-komponen terpisah:
- Aplikasi kita.
- Basis data.
- Layanan eksternal, dll ...
Hal pertama yang Anda temui, bagaimana cara menginisialisasi database? Jelas bahwa kami menggunakan migrasi, tetapi kapan dan bagaimana menerapkannya? Di sini ada baiknya memberikan tautan ke artikel bagus yang menggambarkan perangkat POD: kehidupan PODs . Secara umum, ada beberapa pendekatan:
- Gunakan init-container
- Gunakan sistem orkestrasi yang akan menentukan urutan penyebaran layanan dan roll migrasi bila perlu.
Kami memutuskan untuk mengikuti jalur Init-container. Yaitu dalam POD aplikasi kita, sebelum dimulainya aplikasi kita, sebuah wadah mulai yang menggulung migrasi. Tetapi bagaimana cara mengkonfigurasi aplikasi itu sendiri dan integrasi eksternal?
Inisialisasi aplikasi
Seperti yang telah saya sebutkan, aplikasi kita dapat dan harus bekerja di lingkungan yang sangat berbeda, dengan basis data dan integrasi yang berbeda. Sekali lagi, pertanyaannya adalah bagaimana mengaturnya?
- Gunakan sistem orkestrasi yang menentukan urutan layanan dikerahkan dan menerapkan konfigurasi setelah aplikasi dimulai.
- Lewati variabel lingkungan ke wadah cara mengkonfigurasi.
- Gunakan kait mulai.
- Buat wadah terpisah yang berisi konfigurasi dan terapkan ke aplikasi. Migrasi yang hampir analog untuk database.
Kami memilih pendekatan terakhir, karena itu memungkinkan Anda untuk membuat konfigurasi direproduksi dan swasembada. Tetapi untuk beberapa alasan, kami awalnya membuat wadah ini dalam pengontrol replikasi terpisah dengan faktor 1.
Ok, baca dokumentasi lagi.
Pod (seperti dalam pod paus atau polong) adalah sekelompok satu atau lebih kontainer (seperti wadah Docker), dengan penyimpanan / jaringan bersama, dan spesifikasi untuk cara menjalankan kontainer.
POD adalah sekelompok wadah. Akibatnya, kapal selam kami terdiri dari 3 kontainer
- Wadah init untuk menginisialisasi PostgreSQL.
- Wadah dengan aplikasi.
- Wadah dengan konfigurasi aplikasi.
Toolkit
Kami mendapat diagram tentang bagaimana aplikasi yang digunakan terlihat. Sekarang saatnya untuk membahas alat-alat di alam, ada banyak yang sudah siap, saya akan mempertimbangkan beberapa daftar di bawah ini dan menarik kesimpulan subjektif.
Templat openshift
Templat openshift
Pro:
- Asli dan mereka memiliki dokumentasi yang bagus.
Cons:
- Mesin templat lain.
- File YAML panjang dan mengerikan.
- Jika Anda memiliki ketergantungan antara layanan dan urutan permulaannya, itu akan sulit.
Script dan template
Pro:
- Anda dapat menggunakan alat hebat dan semua kekuatan OOP.
Cons:
- Kruk yang mendukung. Dan tidak hanya untukmu.
Penyedia k8s Terraform
Pro:
- Anda tidak perlu khawatir tentang prioritas membuat elemen infrastruktur.
- Anda dapat menggunakan kembali kode infrastruktur sebagai modul.
- Anda dapat menambahkan logika inisialisasi aplikasi.
Cons:
- Tidak ada dukungan untuk Openshift, hanya k8.
- Kadang-kadang dok dan modul usang.
- Tula lain di tim Anda.
Wadah-mungkin
Wadah-mungkin
Pro:
- Buat CM, tanpa bash
- Anda dapat menggunakan kembali kode sebagai peran.
- Dalam kasus kami, satu alat untuk semuanya.
Cons:
- Gambar besar, karena masuk dalam satu lapisan.
- Terlihat ditinggalkan dan tidak didukung. Telah digantikan oleh penyok yang memungkinkan .
Modul k8 yang mungkin
Modul + k8s yang mungkin
Pro:
- Satu buku pedoman untuk menggambarkan semua infrastruktur proyek di dalam Openshift.
- Menggunakan kembali kode dalam bentuk peran.
- Anda dapat menambahkan logika inisialisasi aplikasi.
Cons:
- Tidak ada dukungan proxy.
- Anda mengurus penghapusan. Jika objek tidak lagi diperlukan, jelaskan penghapusannya.
- Anda sendiri menggambarkan urutan pembuatan elemen infrastruktur.
Bundel playbook yang memungkinkan
Utilitas Playbook Bundle (APB) Ansible menawarkan pendekatan: mari kemas peran yang memungkinkan untuk menempatkan aplikasi di dalam k8s / openshift ke dalam wadah dan berjalan di dalam k8s / openshift.
Pro:
- Saya membawa semuanya.
- Dapat diuji dan direproduksi.
- Integrasi dengan katalog Layanan (antarmuka web yang mudah digunakan untuk meluncurkan aplikasi).
Cons:
- Anda memerlukan hak level administrator.
- Dokumentasi terkadang meninggalkan banyak hal yang diinginkan.
Hasil
Saya tidak ingin menjadi pilihan terakhir, tetapi saya akan membagikan kesimpulan saya:
PS