Hari ini saya ingin berbicara tentang alat yang menerjemahkan prosedur untuk menyetujui dan menerbitkan mesin virtual menjadi swalayan penuh, menjaga logika kuota dan menambahkan kemampuan untuk memprediksi pemanfaatan sumber daya.
Sebagai mantan insinyur infrastruktur, saya tahu bagaimana menggunakan beberapa cloud pribadi atau publik dalam tim besar. Biasanya ada dua cara. Atau proses alokasi sumber daya terlalu birokratis - tim mulai menunggu mesin virtual selama seminggu dan menjaganya tetap "hidup" selama mungkin, hanya saja tidak mengulangi jalur ini. Atau kekacauan nyata terjadi, ketika tidak ada yang tahu tim mana dan berapa banyak sumber daya yang dikonsumsi dan ratusan dan ribuan dolar yang dihabiskan setiap bulan di AWS yang sama. Salah satu cara untuk menyederhanakan situasi ini adalah dengan memindahkan pengembang ke layanan mandiri di cloud menggunakan produk mitra kami - CloudMaster.
Apa masalahnya
Ketika sebuah perusahaan mempekerjakan ratusan pengembang dan DevOps, setiap tim memiliki proyek dan kebutuhannya sendiri untuk eksperimen, Anda tidak dapat mengandalkan tanggung jawab masing-masing individu untuk kapasitas yang dialokasikan oleh perusahaan. Untuk memahami besarnya masalah, berikut adalah statistik dari satu pelanggan CloudMaster yang menggunakan cloud publik dan virtualisasi mereka sendiri di OpenStack.
Dengan mengembangkan beberapa ratus project secara paralel, total resource AWS, Azure, dan GCP dikonsumsi oleh klien selama setengah juta dolar sebulan. Dan itu membuat dan menghapus sekitar 350 ribu mesin virtual per tahun.
Jika proses tersebut dibiarkan berjalan pada skala seperti itu, anarki yang nyata akan terjadi. Ratusan mesin virtual akan membeku jika tidak digunakan. Tanpa memahami siapa dan mengapa meluncurkan VM tertentu, akan sangat sulit untuk mengetahui apakah VM diperlukan dalam pekerjaan dan apakah akan diperlukan di masa mendatang. Ini memerlukan biaya yang tidak perlu untuk menyewa sumber daya cloud, dan pada dasarnya tidak mungkin untuk melakukan analisis apa pun tentang apa yang terjadi atau untuk memprediksi beban dalam kondisi ini.
Cara logis untuk menghindari ini adalah dengan meresepkan proses bisnis negosiasi sumber daya. Tentu saja, hal ini mempersulit jalur pengembang untuk mendapatkan mesin virtual: Anda perlu mengisi aplikasi, mengirimkannya ke orang yang bertanggung jawab. Namun, jika Anda mengumpulkan laporan dengan benar, pengelola akan mendapat gambaran lengkap: siapa, kapan dan kapasitas apa yang diminta. Dengan penundaan tertentu, ia bahkan akan dapat menganalisis kebutuhan tim dalam kapasitas virtual. Tapi ini juga bukan obat mujarab. Dengan volume permintaan yang memadai, tim dengan proyek mereka "menunggu" menunggu orang yang bertanggung jawab untuk melihat dan mengevaluasi aplikasi berikutnya. Dan semakin besar perusahaannya, semakin lama waktu tunggu ini.
Dalam kasus ini, semua mesin virtual yang dibuat tidak memiliki "tanggal kedaluwarsa", yaitu maka seseorang perlu mengontrol bahwa semua sumber daya yang dialokasikan dimatikan pada waktu yang ditentukan dan ini tidak mempengaruhi proyek.
Layanan mandiri melalui platform manajemen cloud (CMP)
Solusi kelas Cloud Management Platform membantu menertibkan beberapa cloud yang digunakan, pribadi atau publik. Saya ingin berbicara tentang alternatif Rusia dari mitra kami - platform CloudMaster, yang berfokus pada koneksi ke Azure, AWS, dan Google Cloud, serta wilayah pribadi di bawah vCloud Director, vSphere, dan OpenStack.
Dari sudut pandang pengembang, CloudMaster adalah portal layanan mandiri di mana, melalui satu antarmuka dan tanpa birokrasi (melalui UI di browser, aplikasi seluler, dan perintah konsol (skrip Python)), Anda bisa mendapatkan sumber daya di cloud perusahaan atau pusat data. Dan untuk infrastruktur, ini adalah lapisan abstraksi tambahan antara platform cloud dan pengguna akhir, yang mempertahankan pembagian sumber daya secara selektif, kebijakan keamanan, konfigurasi standar, dan alat lain yang diperlukan seperti image mesin dan template Terraform.
Sebagian besar CloudMaster berbasis Java dan didasarkan pada kerangka kerja Spring sisi server dan Dagger dalam aplikasi Android.
Secara arsitektural, CloudMaster disesuaikan untuk bekerja dengan tim besar dan volume pesan terkirim yang signifikan: RabbitMQ digunakan untuk memproses antrian, MonogoDB digunakan untuk penyimpanan data, dan Nginx digunakan untuk penyeimbangan.
Alat tersebut telah dikembangkan sejak 2012, dan sejak 2014 telah digunakan oleh pengembang perangkat lunak besar.
Logika CloudMaster
Dari perspektif pengembang, CloudMaster adalah toko serba ada untuk meluncurkan mesin virtual dengan cepat di semua awan dan wilayah yang tersedia. Alat ini memungkinkan Anda untuk tidak menunggu persetujuan, tetapi untuk mendapatkan sumber daya di sini dan saat ini.
Pendaftaran di portal cukup untuk mengakses “satu jendela” ini. Dan jika CloudMaster terintegrasi dengan AD perusahaan, peran karyawan di perusahaan dan dalam proyek akan dimuat ke alat ini, secara otomatis menentukan proyek dan sumber daya yang tersedia.
Jendela peluncuran mesin virtual
Jika Anda memiliki hak yang sesuai, satu perintah dapat meluncurkan hingga 10 mesin virtual dengan "bentuk" umum. Dalam istilah CloudMaster, ini adalah konfigurasi standar yang dipetakan ke penawaran resource khas dari setiap cloud (dan disesuaikan untuk tugas tersebut).
"Template" khas untuk cloud yang berbeda
Anda dapat membuat gambar dari mesin yang ada, menggunakan "infrastruktur sebagai kode" template siap pakai atau mengunggah milik Anda sendiri (Terraform dan CloudFormation).
Template
Dalam hal ini, VM dapat dibuat tanpa batas waktu atau berfungsi sesuai dengan jadwal yang ditentukan. Hal ini memberikan kebebasan tertentu dalam penggunaan sumber daya. Misalnya, sebuah perusahaan mungkin mengizinkan pengembang menggunakan cloud perusahaan untuk eksperimen dan perbandingan pribadi, tetapi hanya untuk satu hari. Omong-omong, klien dari platform ini melakukan pengembangan kustom. Semua mesin virtual yang dibuat dengan cara ini akan dihapus dengan sendirinya dalam jangka waktu tertentu.
Dari sudut pandang manajer, hal paling berguna tentang CloudMaster adalah menghitung setiap mesin virtual yang berjalan. Bagi mereka, ada bagian dengan informasi lengkap tentang VM di cloud / wilayah yang dipilih, termasuk yang dibuat sesuai dengan template tertentu, dengan penagihan dari penyedia cloud, metrik tentang konsumsi sumber daya oleh masing-masing project, di mana kapasitas yang tidak digunakan atau kurang dimanfaatkan dapat diidentifikasi.
Daftar sumber daya
Daftar mesin virtual
Selain menampilkan informasi di antarmuka, CloudMaster menghasilkan sekitar 60 jenis pemberitahuan, termasuk yang terkait dengan keuangan.
Pemberitahuan masuk
DAN teks dari salah satu pemberitahuan
Logika layanan ini sedemikian rupa sehingga setiap VM memiliki pemilik - orang yang membuat mesin virtual ini, atau orang yang menerima transfer fungsi ini. Pemilik menerima semua pemberitahuan tentang pemanfaatan sumber daya atau perubahan status VM, dan juga bertanggung jawab atas biayanya. Dalam hal ini, CloudMaster membantu menanamkan budaya mengontrol penggunaan kapasitas dan bertanggung jawab atas mesin zombie yang ditinggalkan.
Batasan dalam membuat VM baru diatur oleh hak akses dan kuota. Dan di sini dimungkinkan untuk menyesuaikan proses kerja apa pun, hingga penerimaan perwakilan klien ke cloud. Anda dapat menentukan kuota untuk tim dan menyediakan berbagai tindakan ketika mereka tercapai atau mendekati nilai ambang tertentu (katakanlah, 70% dari kuota).
Penagihan dari penyedia cloud
Jendela manajemen kuota
Untuk cloud pribadi (OpenStack dan VMware), CloudMaster mendukung semacam pertukaran - perkiraan biaya menjalankan mesin virtual, yang dengannya Anda dapat memilih skema pemanfaatan sumber daya yang lebih menguntungkan. Rekan kerja mengatakan bahwa di masa depan, fungsi seperti itu mungkin muncul untuk cloud publik.
Dalam sistem ini, peran insinyur infrastruktur paling dekat dengan saya, jadi saya tinggalkan untuk yang terakhir. Untuk DevOps, ini tentu saja merupakan alat baru, tetapi di sisi lain, dimungkinkan untuk mengontrol apa yang terjadi pada sumber daya cloud hanya dengan menggunakannya. Alat konfigurasi, pemantauan, dan pengembangan populer seperti Chef dan Ansible dapat diterapkan dengan lebih cepat dan lebih mudah.
Java SDK tersedia untuk administrator dan pengembang jika diperlukan.
Yang terpenting, CloudMaster, seperti CMP lainnya, memungkinkan Anda beralih dari alokasi sumber daya rutin manual ke tugas yang lebih menarik: mengembangkan otomatisasi berdasarkan infrastruktur sebagai kode, dll.
Menurut pengalaman saya, kemunculan alat semacam itu dibenarkan jika perusahaan menggunakan setidaknya lima puluh mesin virtual dan setidaknya ada lima belas pengguna aktif cloud yang berbeda. Di satu sisi, ini adalah komplikasi tertentu dari infrastruktur, tetapi di sisi lain, ini membawa awan heterogen, yang masing-masing memiliki alat manajemennya sendiri, ke penyebut bersama dengan jaminan bahwa ini tidak melanggar standar internal perusahaan. Pada saat yang sama, alat tersebut "menurunkan" tanggung jawab untuk pemanfaatan sumber daya dan perencanaan anggaran ke tingkat manajer proyek, yang secara ideologis lebih tepat.