Saya mengusulkan untuk berkenalan dengan decoding laporan Denis Yakovlev "Otomasi infrastruktur. Mengapa kita melakukan ini?"
Laporan 2016 itu sendiri. Laporan itu didekripsi khusus untuk mereka yang membuat mesin virtual dengan tangan mereka.
Laporkan bagaimana kami di 2GIS terotomatisasi bekerja dengan infrastruktur.
“Kamu harus berlari secepatnya hanya untuk tetap di tempatnya, tetapi untuk mendapatkan suatu tempat, kamu harus berlari setidaknya dua kali lebih cepat” (Alice in Wonderland).
Apa arti ungkapan ini bagi kita? Dalam lingkungan yang sangat kompetitif, perusahaan harus berusaha untuk mengirimkan produk mereka kepada pengguna secepat mungkin. Penurunan parameter waktu ke pasar adalah tugas multi-level. Untuk mengatasinya, Anda perlu mengubah proses dan alat pengembangan. Landasan penting untuk seluruh proses pembangunan adalah infrastruktur. Semakin besar infrastruktur, semakin banyak masalah dengan itu, kasus penggunaan, dll. Jika semua operasi dengan itu tidak otomatis, maka jumlah masalah bertambah. Salah satunya adalah waktu yang dihabiskan pengembang untuk masalah infrastruktur alih-alih menulis logika bisnis.
Mari kita bicarakan:
- Masalah infrastruktur apa yang dihadapi tim;
- Bagaimana proses pengembangan dan pengujian menderita dari ini;
- Bagaimana kami menerapkan OpenStack;
- Apa skenario kami untuk menggunakan OpenStack;
- Bagaimana otomatisasi menerima dorongan tambahan dalam pengembangan dan produk internal baru mulai muncul;
- Aspek apa yang tersisa tidak otomatis.
Tentang diri saya Perusahaan 2GIS. Saya telah bekerja di perusahaan selama dua tahun.
Tim Infrastruktur dan Operasi. Kami terutama mendukung infrastruktur internal departemen Web. Baru-baru ini, tim produk internal lainnya telah bergabung dengan kami. Kami juga bertanggung jawab atas pengoperasian produk web perusahaan dalam produksi. Dan kami juga meneliti dan mengembangkan alat-alat baru untuk membuat hidup kita lebih mudah dan untuk meningkatkan kehidupan pengembang tercinta kita. Hanya ada 9 dari kita.
Pertama kita memahami infrastrukturnya. Kenapa kita membicarakannya? Apa ini Kapan kita mulai membicarakannya?
Dari saat-saat pertama bekerja pada produk dan beberapa proyek, kami memiliki pertanyaan - di mana kami akan menyebarkan? di mana memeriksa hasilnya? di mana untuk menguji dan sebagainya.
Segera jawaban pertama adalah secara lokal. Secara lokal karena sangat sederhana. Dikembangkan di laptopnya, diluncurkan, diperiksa - semuanya baik-baik saja. Anda duduk berpikir - mengapa memeriksa selain laptop Anda? Semuanya bekerja untukku.
Dan jika kita memiliki satu sistem operasi pada laptop, dan yang lainnya berputar dalam produksi? Atau haruskah produk kami mendukung beberapa sistem operasi?
Kasing tidak dicakup. Yaitu, sistem operasi yang berbeda.
Jika kami memiliki kesempatan dan kami membuat keputusan dengan tekad kuat - kami memiliki Linux di mana-mana. Misalnya, beberapa Ubuntu. Sisanya semua dari si jahat. Tampaknya bagi kita bahwa kita telah menyelesaikan semua masalah kita.
Tetapi hanya mencocokkan sistem operasi saja tidak cukup. Kami membutuhkan paket dari versi tertentu.
kami pikir bagaimana mengatasi masalah ini. Dan ingat - kami memiliki isolasi. Barang yang sangat tinggi. Alhamdulillah ada begitu banyak produk di pasaran. Kami mengambil virtualbox. Buat mesin virtual. Kami menggulung produk kami. Kami membuat snapshot. Kami punya lingkungan.
Kami sedang berkembang. Produk kami semakin sulit. Ini bukan lagi hanya aplikasi basis data php. Aplikasi telah berkembang menjadi sistem terdistribusi. Kami memiliki produk lain yang muncul.
Perusahaan sedang berkembang. Dan kami memiliki kasus penggunaan baru. Semua produk ini ingin diintegrasikan, untuk dapat bekerja bersama. Kami memiliki fitur yang melewati beberapa produk. Kami terus-menerus diminta untuk menunjukkan apa yang telah Anda kembangkan. Mari kita melihatnya di suatu tempat. Kami tidak memiliki sumber daya lagi untuk pengujian manual. Kami ingat bahwa ada integrasi berkelanjutan, protes otomatis. Untuk melakukan ini, Anda memerlukan perangkat lunak tambahan. Kami lingkungan lokal, bahkan dengan semua isolasi, tidak lagi cukup. Di sinilah infrastruktur masuk Kami membutuhkan tempat di mana kami dapat menggunakan produk kami dan menunjukkan hasilnya kepada seseorang. Kita harus entah bagaimana mengelola semua ini dan itu harus nyaman.
Mari kita lihat 2GIS perusahaan kami.
Ini adalah panduan dan peta. Anda dapat melihat peta kota, mencari organisasi.
Kami memiliki: produk web, seluler, aplikasi desktop. Ada sekitar tiga puluh lima tim berbeda dengan ukuran berbeda.
Masalah apa yang kita miliki dengan infrastruktur? Pada akhir 2013, kami menggunakan proxmox. Ini adalah sistem manajemen virtualisasi. Dengan menggunakannya, Anda dapat membuat mesin virtual KVM atau wadah OpenVZ. Tetapi semua ini dilakukan dengan tangan melalui antarmuka. Untuk berfungsi penuh, Anda masih perlu masuk ke mesin virtual dan mengkonfigurasi jaringan, dns.
Oleh karena itu, untuk beberapa waktu, aliran perkembangan kami terlihat sebagai berikut. Sebagai pengembang, saya mencari admin tiket. Admin, ketika mereka punya waktu, membuat mesin virtual. Mereka memberikan alamat IP, login, kata sandi. Tetapi jika saya perlu menggunakan kembali mesin virtual ini, maka saya pergi lagi ke admin yang sudah melihat saya dengan curiga. Mereka mengatakan - seorang pria sebanyak mungkin?
Tidak ada pemisahan proyek. Ada satu set mesin virtual di beberapa server, di mana admin menciptakan semuanya dengan tangan mereka. Ada kemungkinan besar kesalahan manusia. Anda dapat membingungkan alamat IP atau menghapus mesin virtual yang salah. Kasus yang sangat, sangat banyak. Dan tanggung jawab untuk mesin virtual tidak dapat dipahami. Pengembang tidak memikul tanggung jawab, admin juga tidak mandi uap. Tidak jelas bahwa orang lain membutuhkan mesin virtual atau semua orang sudah lama melupakannya dan tidak mengetahuinya.
Plus ada API yang lemah. Pengaya dibayar atau diper.
Tapi selain masalah, kami punya hal lain yang berguna. Kami punya besi sendiri, tempat semua ini berputar. Administrator sistem kami adalah orang yang hebat, mereka tahu cara memasak besi ini, merawatnya, dan membelinya dengan benar. Dan mereka memiliki pengalaman dengan virtualisasi.
Kami mulai berpikir: solusi apa yang cocok untuk kami? Seperti apa infrastruktur kita agar tidak mengganggu proses pembangunan, tetapi lebih membantu?
Kami mendapat daftar persyaratan sebagai hasil dari penelitian ini:
Pemanfaatan besi secara efektif. Kami tidak ingin memiliki mesin virtual yatim. Kami tidak ingin hanya menghangatkan udara di pusat data.
Kami ingin memiliki sumber daya tim sehingga tim bertanggung jawab atas sumber daya yang digunakannya. Dan dia memperhatikan mereka.
Kami ingin solusinya modular, pilih hanya layanan yang kami butuhkan. Dan jika perlu, dengan pengembangan lebih lanjut, dapat berkembang.
Solusinya harus mudah diselesaikan. Jika persyaratan baru muncul, kami dapat memperbaiki solusi untuk kebutuhan spesifik kami.
Kami tidak hanya membutuhkan antarmuka pengguna, kami membutuhkan API untuk menulis binding kami dan mengelola infrastruktur.
Kami ingin mengisolasi tim, dan terutama tim uji beban. Saya ingin dia tidak mengganggu sisanya sama sekali.
Apa pilihan kita?
Kami melihat cloud publik: AWS dan banyak lagi. Opsi ini menarik karena mereka menangani hampir semua masalah yang berkaitan dengan infrastruktur. Dimungkinkan untuk mengambil dan membayar banyak uang kepada perusahaan-perusahaan terkenal ini, tetapi kami dihambat oleh situasi yang menjijikkan dengan dolar (atau sanksi). Saya tidak benar-benar ingin mendapatkan kunci vendor. Opsi ketiga, di mana kita melihat apa yang kita miliki di pasar open source? Solusi apa yang ditawarkan? Kami memiliki perangkat keras kami sendiri, masih harus memilih sesuatu dari banyak aplikasi open source ini.
Jadi, pada akhirnya, penelitian dan eksperimen kami mengarahkan kami ke perangkat lunak yang disebut OpenStack. Softinke tentu saja kedengarannya terlalu kasar.
OpenStack adalah perangkat lunak lengkap, pada kenyataannya, itu adalah seperangkat layanan untuk membangun cloud publik atau pribadi. OpenStack adalah solusi open source. Semua layanan ditulis dengan python. Setiap layanan bertanggung jawab atas tugasnya, memiliki API sendiri.
Dan sepertinya ini. Ingat gambar ini. Maka kita akan kembali padanya. Ada layanan umum (umum). Ada layanan untuk tujuan itu: Menghitung, Jaringan, Penyimpanan. Dan aplikasi atau pengguna kami bekerja dengan layanan ini.
Solusi open source. Rilis ini berlangsung setengah tahun. Rilis ini mencakup komponen dasar. Setiap rilis menyertakan komponen baru yang awalnya muncul dari dalam inkubator ini. Mereka menghabiskan waktu di sana, memperbaiki bug di sana, menstabilkan dan sebagainya. Dan pada titik tertentu, komunitas memutuskan bahwa komponen ini harus dimasukkan dalam komponen dasar dari rilis berikutnya. Ada juga berbagai surat, rapat, konferensi. Konferensi terbesar adalah OpenStack Summit. Diadakan setiap tahun. Dan pada OpenStack Summit terakhir ada sekitar empat atau lima ribu peserta. Peristiwa besar. Banyak laporan.
Banyak orang berkontribusi pada keputusan ini. Di sini saya hanya memberikan daftar atasan seperti itu. Daftar ini cukup untuk memahami seberapa serius proyek itu dan perusahaan mana serta berapa banyak sumber daya yang mereka investasikan di dalamnya.
Bagaimana kami memecahkan masalah infrastruktur kami.
- Salah satu komponen OpenStack adalah scheduler, yang memilih host di mana mesin virtual akan dibuat.
- Tim sekarang memiliki sumber daya sendiri. Ini adalah jumlah CPU, memori, dan lainnya. Kami menyingkirkan skenario ini untuk membuat tiket virtual (aplikasi).
- OpenStack adalah seperangkat layanan yang ada. Kami hanya mengambil perlengkapan dasar yang menyediakan kebutuhan kami.
- Karena OpenStack adalah open-source, dimungkinkan untuk memodifikasinya.
- Setiap layanan memiliki API. Ada membangun python. Artinya, cukup sederhana untuk berinteraksi dengan setiap layanan dan menulis ikatan Anda sendiri.
- Isolasi. Kami dapat mengisolasi tim untuk kami di proyek, di zona agregasi, di jaringan dan sebagainya.
Pengembang tim menerima infrastruktur sebagai layanan. Seperti apa bentuknya.
Ada dua konsep stack dan templat. Stack adalah seperangkat sumber daya cloud: mesin virtual, jaringan, catatan dns dan banyak lagi. Templat adalah deskripsi tumpukan ini. Dalam hal OpenStack, ini adalah file YAML biasa. Ini bagian dari file. Dikatakan bahwa ada entitas seperti server dengan tipe internal OS Nova server. Untuk operasi normal, Anda memerlukan alamat IP dan catatan dns. Di sini, parameter nama diterima sebagai input, rasa adalah deskripsi sumber daya yang dibutuhkan server ini. Sistem operasi gambar. key_name - kunci publik mana yang harus diletakkan ketika menggunakan server. Kami memiliki semua templat ini di repositori masing-masing yang ada di git. Setiap orang memiliki akses. Semua orang dapat mengirim permintaan tarik.
Dan penciptaan Stack adalah sebagai berikut. Heat adalah komponen OpenStack yang bertanggung jawab untuk orkestrasi. Kami mengatakan ini dalam konteks ini. Ini adalah utilitas luar biasa yang kami pasang untuk kami. Kami mengucapkan terimakasih, buat kami tumpukan dengan nama itu, di sini adalah deskripsi sumber daya yang kami butuhkan untuk membuat tumpukan ini. Dan inilah input yang dibutuhkan template kita, yang menggambarkan stack kita. Kami memuatnya dalam panas. Dia berdesir di sana untuk sementara waktu, menciptakan semua sumber daya yang diperlukan untuk kita dalam dirinya sendiri. Dan juga kita dalam template ini di sini kita dapat menentukan output. Ketika panas menciptakan Stack, ia dapat menampilkan informasi: alamat ip, akses, dan sisanya yang kami minta. Selanjutnya kami sudah dapat menerapkan informasi ini untuk otomatisasi lebih lanjut.
Agar Anda tidak berpikir bahwa OpenStack sederhana dan murah, saya akan memberi tahu Anda untuk apa hardware OpenStack bekerja. Panel kontrol berputar pada 3 infra-node. Ini adalah server besi dengan sumber daya seperti itu. Ini adalah konfigurasi yang disarankan untuk failover.
Kami juga memiliki dua node jaringan KVM yang melayani jaringan kami.
Sumber daya tim kami berputar pada 8 node komputasi. Mereka dibagi menjadi 3 zona agregasi. Satu node komputasi dialokasikan per zona untuk pengujian beban. Di sana, server dibuat hanya dari tim pengujian beban. Agar tidak mengganggu sisanya. Kami memiliki zona agregasi untuk proyek otomasi pengujian GUI internal kami. Dia memiliki persyaratan tertentu. Itu terletak di zona agregasi terpisah. Seluruh lingkungan pengembangan, server, lingkungan pengujian kami berputar di zona agregasi besar ketiga. Dibutuhkan kita 6 node komputasi untuk itu.
Kami memutar sekitar 350 mesin virtual untuk semua tim.
Apa yang kami pahami ketika kami sudah melangkah. Untuk menggunakan dan mendukung perangkat lunak ini, Anda memerlukan tim. Tim tergantung pada sumber daya Anda.
Tim harus memiliki kompetensi tertentu.
Pertama-tama, secara alami Ansible. Penyebaran OpenStack ditulis dalam Ansible. Ada proyek OpenStack-Ansible . Jika Anda ingin menambahkan OpenStack-Ansible ke kebutuhan Anda, maka orang-orang yang akan melakukan ini harus memiliki Ansible.
Pengalaman Virtualisasi. Anda harus bisa memasak virtualisasi, Anda harus menyetel. Pahami cara kerjanya.
Jaringan yang sama.
Hal yang sama berlaku untuk layanan backend yang digunakan OpenStack untuk pekerjaannya. Basis data ini adalah MySQL Galera dan RabbitMQ sebagai antrian.
Memahami cara kerja DNS. Cara mengkonfigurasinya.
OpenStack ditulis dengan python. Anda harus dapat membaca kode. Idealnya, Anda harus bisa menambal. Cari perbaikan komunitas. Mampu debut kode. Ini semua sangat membantu. Jika sebuah tim memiliki pendekatan seperti itu, tahu cara menggunakan pendekatan seperti Infrastruktur sebagai kode, seperti yang mungkin, misalnya, semua perubahan disimpan dalam kode, maka mereka tidak akan memiliki masalah yang muncul ketika mengonfigurasi tangan.
Integrasi berkelanjutan. Suite layanan OpenStack mencakup layanan seperti prahara . Di dalamnya, semua tes ditulis pada semua komponen. Jika kita mengubah konfigurasi, jalankan diploma terpisah di instalasi All-In-One dan jalankan prahara - kita melihat apakah ada yang salah dengan kita. CI dikonfigurasi dan tim harus memahami ini dan harus dapat mengkonfigurasi semua ini.
Karena semuanya terlihat sederhana dan menarik diberikan.
Tetapi ketika Anda mulai menggali lebih dalam, Anda mengerti bahwa sebenarnya semuanya tampak seperti ini. Ini mungkin mengejutkan bagi seseorang.
Pengenalan OpenStack bukan hanya solusi teknis. Selain itu, Anda harus dapat menjual, untuk dapat menjelaskan kepada tim paradigma baru tentang bagaimana mereka sekarang bekerja, apa manfaatnya. Cara bekerja dengannya untuk mendapat untung. Kami menulis banyak dokumentasi. Dokumentasi berupa mulai cepat (mulai cepat), langkah pertama (langkah pertama). Artinya, apa yang perlu dilakukan untuk mempercepat hidup Anda dan tidak menghabiskan banyak waktu untuk hal itu.
Kami melakukan TechTalk, kami berbicara, membuat topik, menunjukkan, berbicara, sekarang lihat sekarang Anda bisa mendapatkan produk Anda sebagai berikut. secara harfiah di sini kita menulis templat, kami meluncurkannya. Semuanya cukup sederhana. Sekarang Anda tidak perlu pergi ke admin dan meminta mereka untuk sesuatu di sana.
Dalam kasus-kasus sulit seperti itu ketika proyek ini kompleks, ada banyak kasus, kami datang ke tim, bekerja langsung dengan tim. Artinya, mereka entah bagaimana mencoba membantu mereka dalam otomatisasi proses. Atur semua tim. Luka beberapa bug. Mereka mengerti bahwa kami tidak mengonfigurasi sesuatu yang salah di sana. Secara umum, kerja keras dengan tim.
Kami menerima penyebaran produk dengan cepat. Sebelumnya, untuk menerima produk, perlu melakukan banyak tindakan manual, berinteraksi dengan banyak orang. Sekarang kita mendapatkan penciptaan Envinronment (Lingkungan, server) dengan tombol. Dan jika penerapan ditulis dan berfungsi untuk proyek tersebut, kami dapat menggunakan tombol atau Lingkungan Baru (Lingkungan, server) dengan produk terpasang.
Kurangnya infrastruktur normal merupakan penghalang bagi beberapa tim dalam hal menerapkan proses CI dalam tim. Kami memecahkan masalah infrastruktur, tim yang diangkat pada server CI, mengkonfigurasi pipa, mesin virtual dibuat dalam pipa. Secara umum, mereka memberikan dorongan untuk pengembangan proses ini.
Mereka juga membantu beberapa produk internal yang menggunakan infrastruktur untuk mengotomatisasi pengujian. VM Master adalah produk yang menguji online kami. Dia perlu meningkatkan banyak mesin virtual untuk mengakses situs dari browser yang berbeda, melalui beberapa langkah untuk memahami bahwa browser online kami berfungsi di semua browser yang dikenal. Artinya, mereka banyak membantunya.
Bonus yang bagus adalah mereka membongkar admin (sendiri). Karena pada titik tertentu, aktivitas membuat mesin virtual mulai memakan waktu. Dan semua orang mulai merasa gugup. Sekarang kami sedang melakukan hal-hal menarik, produk yang kompleks. Kami menyingkirkan tugas rutin.
Pertanyaan?
Pertanyaan: Berapa lama untuk menggunakan OpenStack?
Jawab: Pertanyaannya rumit karena kami memiliki proses yang dapat mengakomodasi serial komedi. Dia memiliki ambang masuk yang tinggi. Kami memahami seluruh infrastruktur kami, mencari solusi - butuh tiga bulan. Kemudian dalam sebulan kami meluncurkan instalasi pertama di suatu tempat. Kami menambahkan beberapa proyek di sana. Mereka tinggal di sana. Kemudian faktor manusia terjadi - mereka menembak kepala instalasi ini. Kami menyadari bahwa kurangnya toleransi kesalahan adalah buruk. Lalu kami menunggu setrika.
Pertanyaan: Apakah Anda menggunakan dukungan berbayar?
Jawab: tidak, kami tidak menggunakannya.
Pertanyaan: Apa versi OpenStack yang Anda gunakan?
Jawaban: Versi OpenStack disebut kata. Pertama adalah Juno, lalu kami upgrade ke Liberty.
Pertanyaan: Apakah mesin virtual dibuat dalam pipeline Integrasi berkelanjutan?
Jawaban: Bangunan di Jenkins dapat menyebabkan Panas dan membuat mesin virtual.
Pertanyaan: Apakah Anda mengalami masalah dengan berbagi sumber daya? Secara kasar, 2 mesin virtual berada di server fisik yang sama. Salah satunya mulai memuat disk, misalnya, database. Jika dihadapkan, bagaimana Anda memutuskan?
Jawaban: Kami tidak mengalami masalah dengan berbagi sumber daya. Produk masing-masing tidak banyak mengganggu. Kami meletakkan skripnya. Jika Anda perlu menjalankan skenario berat, jalankan uji beban, maka Anda harus pergi ke tim pengujian beban dan menjalankan pengujian beban.
: - ?
: OpenStack . . . .
: . . OpenStack ?
: . OpenStack . .
: OpenStack?
: . proxmox. OpenStack.
: DevOps?
: DevOps , . , , .
PS 2019 OpenStack heat Terraform .