Halo, Habr! Nama saya Dmitry, saya seorang pengembang di ISPsystem. Baru-baru ini, kami merilis pengujian beta versi baru dari panel kontrol mesin virtual. Hari ini saya akan memberi tahu Anda bagaimana kami memutuskan apa yang akan diambil dari produk lama, dan apa yang lebih baik untuk ditolak. Saya akan membahas masalah yang paling penting bagi kami: perpustakaan untuk bekerja dengan libvirt, dukungan untuk berbagai sistem operasi selama instalasi produk, transisi dari monolit ke layanan mikro, dan penyebaran mesin virtual.
Artikel ini tentang
VMmanager . Ini adalah sistem untuk mengelola, menyebarkan dan memonitor mesin virtual berdasarkan virtualisasi KVM dan OVZ. Generasi kelima keluar pada 2012. Sejak itu, antarmuka sangat ketinggalan jaman, dan arsitektur terpusat telah mencegah pengembangan produk. Saatnya membuat versi baru.
Kisah pertama. Kami menggunakan pekerjaan peri rumah
Bekerja dengan libvirt: pertimbangkan opsi, pilih perpustakaan
Sebagai alat untuk mengelola virtualisasi KVM, produk kami menggunakan libvirt. Pada 2012, perpustakaan yang ditulis dalam C dipilih untuk bekerja dengannya, jadi lebih nyaman bagi tim pengembangan itu. Akibatnya - sejumlah besar kode ditulis dalam C ++, memanggil C-library, yang mengimplementasikan kerja langsung dengan libvirt.
Dan sekarang, di ambang proyek baru, kita melihat ke belakang dan memeriksa produk kita, menimbang apakah layak mengambil solusi / teknologi tertentu; apa yang telah membuktikan dirinya dan apa yang perlu diingat dan tidak pernah diulang.
Kami duduk dan melakukan retrospeksi bertahun-tahun bekerja pada versi produk sebelumnya. Kami bersabar, mengambil stiker dan menulis tiga jenis kertas:
- Apa yang berhasil dalam produk? Apa yang dipuji pengguna? Apa yang belum pernah mendengar keluhan? Apa yang kamu sukai dari dirimu?
- Apa yang gagal? Apa masalahnya secara konstan? Apa yang menghambat pekerjaan itu, dan mengapa mereka memulai cabang baru?
- Apa yang bisa diubah? Apa yang diminta pengguna? Apa yang ingin diubah oleh anggota tim?
Kelompok orang yang dengan bersemangat merusak kertas harus mencakup mereka yang telah melakukan kontak dekat dengan produk selama berabad-abad, dan mereka yang dapat memiliki pandangan baru pada produk tersebut. Jangan lupa Permintaan Fitur dan manajer produk. Stiker yang sudah jadi ditempelkan pada papan, mereka pasti akan membantu kita.
Kembali ke cerita. Kami memeriksa sepotong kode di mana standar C ++ 98 secara damai hidup berdampingan dengan panggilan C-library. Kita ingat bahwa tahun 2018 adalah tahun dan memutuskan untuk meninggalkannya sendirian. Tetapi bagaimana cara mengulang fungsi bekerja dengan mesin virtual (VM), membuat kode lebih kompak dan nyaman untuk bekerja?
Kami mempelajari masalah ini, memahami bahwa apa pun solusi dan dalam bahasa apa yang kami pilih, itu akan menjadi penutup C-library. Sebagai opsi yang menarik, perlu diperhatikan
perpustakaan di Go dari DigitalOcean , ia menggunakan protokol RPC untuk berkomunikasi dengan libvirt secara langsung, tetapi ia memiliki kekurangannya. Kami menetap di
perpustakaan Python .
Hasilnya, kami mendapatkan kecepatan menulis kode, kemudahan penggunaan, dan membaca. Perlu menjelaskan kata-kata indah ini.
- Kecepatan . Sekarang kita dapat dengan cepat membuat prototipe bagian tertentu dari pekerjaan dengan domain langsung dari konsol pada server debug, tanpa membangun kembali aplikasi utama.
- Kesederhanaan . Alih-alih memanggil banyak metode C ++ di penangan tertentu, kami memiliki panggilan skrip Python dengan melewati parameter.
- Debugging juga secepat dan tidak menyakitkan mungkin. Menurut pendapat saya, dalam jangka panjang ini bisa membawa pengalaman pengguna yang menarik. Bayangkan, administrator sistem, tidak senang bahwa mesin virtualnya menunggu untuk dimatikan sebelum dihancurkan, pergi dan mendefinisikan ulang skrip untuk metode host_stop.
Bisakah saya juga menulis panel untuk Anda?
Sebagai hasilnya, kami mendapat alat sederhana dan nyaman untuk bekerja dengan mesin virtual di tingkat server.
Kisah kedua. Produk yang dikemas dengan baik tidak membutuhkan belaian tambahan
Distribusi produk: kami menolak dari banyak paket dan kami beralih ke Docker
VMmanager 5 didistribusikan sebagai satu set paket linux. CentOS 6/7 dan, sampai saat ini, Debian 7. didukung. Apa artinya ini? Ini berarti lebih banyak membangun server untuk CI / CD, lebih banyak pengujian, lebih banyak perhatian pada kode. Kita harus ingat bahwa ketika dalam repositori resmi CentOS 7 qemu versi 1.5.3, dalam CentOS 6 itu adalah 0.12.1. Pada saat yang sama, pengguna dapat menggunakan repositori di mana versi paket ini jauh lebih tinggi. Ini berarti bahwa Anda perlu mendukung versi api yang berbeda ketika bekerja dengan VM, khususnya, selama migrasi. Kita harus ingat perbedaan antara inisialisasi (init, systemd), memperhitungkan perbedaan dalam nama paket dan utilitas. Utilitas yang bekerja pada CentOS tidak akan berfungsi pada Debian, atau versinya dalam repositori resmi sangat bervariasi. Untuk setiap dorongan, Anda perlu mengumpulkan paket untuk semua versi, dan disarankan untuk tidak lupa mengujinya juga.
Semua ini dalam produk baru tidak cocok untuk kita. Agar tidak mendukung logika yang berbeda, kami meninggalkan beberapa sistem dan hanya menyisakan CentOS 7. Apakah masalah teratasi? Tidak juga.
Kami juga tidak ingin memeriksa versi sistem operasi sebelum instalasi, apakah utilitas yang diperlukan tersedia, aturan apa yang diinstal di SELinux, dan kami tidak ingin mengkonfigurasi ulang daftar firewall dan repositori. Saya ingin sekali - dan itu saja, dengan mengklik untuk
menghancurkan setiap detik untuk menyebarkan seluruh lingkungan dan produk itu sendiri. Dikatakan - selesai, proyek ini dibungkus dalam wadah buruh pelabuhan.
Sekarang cukup untuk melakukan:
Panel menyala dan berjalan.
Tentu saja, saya melebih-lebihkan, pengguna harus menginstal Docker untuk dirinya sendiri, dan kami memiliki lebih dari satu kontainer, dan saat ini VMmanager berjalan dalam mode swarm sebagai layanan SaaS. Tentang apa yang kami temui ketika memilih Docker, dan bagaimana mengatasinya, Anda dapat menulis artikel terpisah.
Faktanya adalah betapa pentingnya untuk menyederhanakan pengembangan, dan yang paling penting, penyebaran produk Anda, instal.sh yang pernah menempati
2097 baris .
Sebagai hasilnya:
- Lingkungan pemasangan produk yang homogen menyederhanakan kode program dan mengurangi biaya perakitan dan pengujian.
- Mendistribusikan aplikasi sebagai wadah buruh pelabuhan membuat penyebaran mudah dan dapat diprediksi.
Cerita ketiga. Hubungan pertama dengan layanan mikro
Arsitektur: kita meninggalkan monolit demi layanan-layanan microser, atau tidak
Versi kelima dari produk ini adalah sistem monolitik besar dengan standar C ++ yang ketinggalan zaman. Akibatnya, implementasi teknologi baru yang bermasalah dan sulitnya refactoring kode lama, penskalaan horisontal yang buruk. Di cabang baru, mereka memutuskan untuk menggunakan pendekatan microservice sebagai salah satu cara untuk menghindari masalah tersebut.
Layanan mikro adalah tren modern yang memiliki kelebihan dan kekurangan. Saya akan mencoba untuk mempresentasikan visi saya tentang kekuatan arsitektur ini dan berbicara tentang menyelesaikan masalah yang ditimbulkannya pada proyek. Perlu dicatat bahwa ini akan menjadi tampilan pertama pada arsitektur microservice dalam praktiknya dari sisi pengembang biasa. Aspek-aspek yang mungkin tidak akan saya sebutkan tercakup dalam
artikel ulasan yang bagus .
Sisi positif
Layanan kecil memberi banyak peluang.Selain kenyamanan penulisan, pengujian dan debugging, layanan microser memperkenalkan bahasa pemrograman baru ke proyek. Ketika proyek Anda adalah monolit, sulit untuk membayangkan bahwa suatu hari Anda akan mencoba untuk menulis ulang sebagian dari itu dalam bahasa lain yang menarik minat Anda. Dalam arsitektur microservice - silakan. Selain bahasa pemrograman, Anda juga dapat mencoba teknologi baru, dengan satu-satunya peringatan bahwa semua ini akan dibenarkan untuk bisnis. Sebagai contoh, kami menulis beberapa layanan microsoft di Golang, sambil menghemat waktu yang cukup lama.
Penskalaan timKita dapat membagi banyak orang yang dulu berkomitmen pada satu repositori dan mencoba menjaga struktur monolith di kepala mereka menjadi beberapa tim. Setiap tim akan terlibat dalam layanannya. Selain itu, masuknya orang baru ke dalam pekerjaan jauh lebih sederhana dan lebih cepat, karena konteks yang terbatas di mana ia akan bekerja. Di sisi lain, ada lebih sedikit orang-pengumpul pengetahuan dunia, yang selalu dapat ditemukan tentang aspek apa pun dari sistem besar. Mungkin pada saatnya saya akan mempertimbangkan kembali sikap saya sampai titik ini.
Degradasi independenSaya akan mengaitkan degradasi independen ke sisi positif dan negatif dari layanan microser, karena siapa yang membutuhkan aplikasi Anda jika, misalnya, terletak layanan otorisasi? Namun, ini masih sisi positif. Sebelumnya, mengumpulkan statistik dari beberapa ratus mesin virtual membuat monolith kami bekerja keras, pada saat beban puncak, menunggu permintaan pengguna meningkat meningkat secara signifikan. Layanan pengumpulan statistik terpisah dapat mengumpulkannya tanpa memengaruhi layanan lain, sementara itu masih dapat ditingkatkan dengan menambahkan perangkat keras baru atau dengan meningkatkan jumlah kolektor dari statistik yang sama. Dan kita bahkan dapat memilih server terpisah untuk Graphite, tempat layanan ini mencatat statistik. Dengan monolit, di mana ada satu basis, ini tidak mungkin.
Sisi negatif
Konteks permintaanSemua debug saya di monolith turun ke dua pertanyaan di konsol:
Selesai! Saya dapat melacak seluruh permintaan, mulai dari tanda terima hingga sistem hingga terjadi kesalahan.
Tapi bagaimana dengan sekarang, ketika permintaan berpindah dari microservice ke microservice, disertai dengan panggilan tambahan ke layanan tetangga dan catatan di berbagai database? Untuk melakukan ini, kami mengimplementasikan info permintaan, yang berisi pengidentifikasi permintaan dan informasi tentang pengguna atau layanan yang menghasilkannya. Jadi menjadi lebih mudah untuk melacak seluruh rantai peristiwa, tetapi keinginan datang untuk menulis layanan agregasi log, karena kita, setelah semua, memiliki arsitektur layanan mikro. Anda juga dapat melihat ke Elasticsearch, masalah ini terbuka dan akan segera diatasi.
Ketidakkonsistenan dataData dalam layanan mikro didesentralisasi, tidak ada database tunggal di mana semua informasi disimpan. Merenungkan artikel ini, saya membahas interaksi utama antara layanan-layanan mikro dalam pikiran saya - di mana kami bisa mendapatkan duplikat, di mana kami menggunakan transaksi internetwork - dan saya menyadari bahwa kami memecahkan masalah ketidakkonsistenan dengan monolith.
Kami benar-benar membangun sebuah monolith dengan satu basis utama, membungkus sebagian besar tindakan transaksional di dalamnya. Dan di sekitar monolith, semua layanan mikro dikumpulkan yang tidak memengaruhi konsistensi data utama. Pengecualian adalah sekelompok otorisasi layanan + monolith. Masalahnya dalam hal ini adalah bahwa basis data aplikasi dasar tidak mengandung pengguna seperti itu, peran mereka dan parameter tambahan, semua ini ada dalam layanan otorisasi.
Pengguna sistem dapat bekerja dengan mesin virtual dalam monolit, sementara di layanan otorisasi haknya dapat berubah, atau ia akan sepenuhnya diblokir. Sistem harus menanggapi ini tepat waktu. Dalam situasi ini, konsistensi data dicapai dengan memeriksa parameter pengguna sebelum menjalankan permintaan apa pun.
Adapun microservices yang tersisa, ketidakmampuan untuk mendaftar di layanan statistik tidak mempengaruhi operasi mesin virtual, dan tindakan ini selalu dapat diulang. Kami sedang melakukan layanan pengumpulan statistik. Tetapi layanan domain define (membuat mesin virtual menggunakan libvirt) tidak akan pernah melihat cahaya, karena siapa yang membutuhkan mesin kosong tanpa keberadaan sebenarnya.
Kisah keempat. Segar adalah musuh orang baik
Penyebaran VM: Menginstal dari Gambar alih-alih Menginstal melalui Jaringan
Dalam versi kelima produk, penyebaran mesin virtual membutuhkan waktu yang cukup lama dengan standar nyata. Alasan untuk ini adalah menginstal sistem operasi melalui jaringan.
Untuk Centos, Fedora, RedHat adalah
metode kickstart :
1. Buat file kickstart.
2. Tentukan tautan ke file respons di parameter kernel linux inst.ks = <tautan ke file kickstart>.
3. Jalankan instalasi kickstart.
File kickstart cukup fleksibel, di dalamnya Anda dapat menggambarkan semua langkah instalasi, mulai dari metode dan pengaturan zona waktu, diakhiri dengan partisi disk dan pengaturan jaringan. Parameter url di templat kami menunjukkan bahwa instalasi berasal dari server jarak jauh.
Untuk Debian dan Ubuntu, metode
preseed :
Ini mirip dengan yang sebelumnya, metode ini juga dibangun di sekitar file konfigurasi dan isinya. Di dalamnya, kami juga mengkonfigurasi instalasi melalui jaringan.
Instalasi untuk FreeBSD serupa, tetapi alih-alih file kickstart, ada skrip shell dari produksi kami sendiri.
Aspek positif dari pendekatan
Opsi instalasi ini memungkinkan Anda untuk menggunakan satu templat di dua produk kami: VMmanager dan
DCImanager (manajemen server khusus).
Penyebaran mesin virtual cukup fleksibel, administrator panel dapat dengan mudah menyalin templat sistem operasi dan mengubah file konfigurasi sesuai keinginannya.
Semua pengguna selalu memiliki versi terbaru dari sistem operasi jika mereka diperbarui secara tepat waktu pada server jarak jauh.
Sisi negatif
Seperti yang telah ditunjukkan oleh praktik, fleksibilitas instalasi tidak diperlukan oleh pengguna VMmanager: dibandingkan dengan server khusus, beberapa orang khawatir tentang pengaturan file kickstart tertentu untuk mesin virtual. Tetapi menunggu instalasi OS benar-benar merupakan kemewahan yang tidak dapat diterima. Sisi lain dari relevansi sistem operasi adalah bagian dari penginstal ada di jaringan, dan bagian lokal untuk
initrd . Dan versinya harus cocok.
Ini adalah masalah yang bisa dipecahkan. Anda dapat membuat kumpulan mesin yang diinstal dan membuat repositori Anda sendiri untuk sistem operasi, tetapi ini memerlukan biaya tambahan.
Bagaimana mengatasi masalah ini tanpa membuat repositori dan kumpulan? Kami memilih file gambar sistem operasi. Sekarang proses instalasi terlihat seperti ini:
1. Menyalin gambar OS ke disk mesin virtual.
2. Tambah bagian utama gambar dengan ukuran ruang kosong setelah penyalinan.
3. Pengaturan dasar (pengaturan kata sandi, zona waktu, dll.).
Semua yang baru sudah lama terlupakan. Kami menggunakan gambar OS di VDSmanager-Linux, leluhur dari VMmanager.
Tetapi bagaimana dengan fleksibilitas instalasi? Praktek telah menunjukkan bahwa sebagian besar pengguna tidak tertarik pada pengaturan jaringan spesifik dan pemetaan disk pada mesin virtual.
Dan relevansi data? Itu dapat dicapai dengan kehadiran gambar dengan versi OS terbaru di repositori, dan pembaruan kecil dapat diinstal pada skrip konfigurasi awal. Dengan demikian, mesin virtual sudah akan dibuat dan dijalankan, dan pergi ke sana, Anda akan menemukan pembaruan yum bersyarat berjalan.
Sebagai imbalannya, kami mendapatkan mesin virtual siap pakai, yang penyebarannya hanya bergantung pada menyalin disk, meningkatkan partisi disk dan memulai sistem operasi. Implementasi pendekatan ini untuk bekerja dengan mesin memberi kita kesempatan untuk membuat gambar kita sendiri dan membaginya. Pengguna dapat menginstal bundel
LAMP atau lingkungan kompleks pada mesin virtual, kemudian membuat gambar dari mesin ini. Sekarang, orang lain tidak perlu membuang waktu untuk menginstal utilitas yang diperlukan.
Kami menerapkan konfigurasi dan modifikasi partisi menggunakan utilitas dari
suite libguestfs . Misalnya, mengubah kata sandi pada mesin linux berubah dari 40 baris kode, yang terdiri dari mount, chroot dan usermod, menjadi satu baris:
command = "/usr/bin/virt-customize --root-password password:{password} --domain '{domain_name}'".format(password=args.password, domain_name=args.domain_name)
Sebagai hasilnya, kami membuat mendapatkan mesin virtual jadi secepat mungkin. Perlu membuat pernyataan bahwa dengan pengaturan jaringan dan pemasangan skrip internal, waktu penyebaran sedikit meningkat. Kami memecahkan masalah ini dengan menampilkan langkah-langkah pemasangan di ujung depan, sehingga mengisi jeda yang terbentuk antara kreasi dan kesiapan lengkap mesin.
Kami juga mendapat pendekatan yang lebih fleksibel untuk menggunakan mesin virtual, berdasarkan pada mana nyaman untuk membuat gambar Anda sendiri dengan lingkungan yang diperlukan.
Apa yang berhasil Anda lakukan
Dalam versi keenam produk, kami mencoba memperhitungkan kelemahan utama yang kelima: kompleksitas interaksi pengguna dengan produk. Kami telah mengurangi waktu tunggu untuk tindakan utama. Bersama-sama dengan antarmuka yang tidak menghalangi, ini memungkinkan untuk bekerja dengan panel tanpa harus menunggu dengan paksa. Kontainer membuat proses instalasi produk lebih mudah dan nyaman. Penggunaan teknologi modern dan berbagai bahasa pemrograman telah menyederhanakan dukungan dan pemeliharaan untuk programmer dan spesialis dukungan teknis. Beralih ke layanan microser memungkinkan penambahan fitur baru dengan cepat dan dengan batasan kecil.
Sebagai kesimpulan, saya ingin mengatakan bahwa produk baru ini adalah kesempatan yang baik untuk mencoba pendekatan pengembangan lain, teknologi baru. Perlu diingat mengapa Anda melakukan ini, hal baru apa yang akan dibawanya kepada Anda dan pengguna Anda. Lakukan itu!
Kami mengundang komunitas Habr untuk melihat versi beta VMmanager 6 dan meninggalkan umpan balik Anda. Untuk melakukan ini, buka my.saasvm.com , masuk dan sambungkan server khusus (CentOS 7 x64, akses Internet, alamat IP publik).
Jika Anda tidak memiliki server, kirimkan kepada kami di help@ispsystem.com atau mengobrol di situs , kami akan menyediakan peralatan pengujian dari mitra kami, Selectel.
Baca lebih lanjut di berita di situs web ISPsystem .