Ansible adalah sistem yang menyelesaikan berbagai tugas otomasi, termasuk konfigurasi, cadangan, dan proyek penyebaran. Sangat menyenangkan untuk menggunakan sistem untuk menulis skrip otomatisasi dari lingkungan yang sederhana ke proyek besar. Dalam skrip, playbook memainkan peran penting dan playbook terstruktur memainkan peran.
Ansible bukan pil ajaib , dan hanya membantu pada awalnya. Ketika sebuah proyek tumbuh, menjadi sulit untuk mempertahankan sejumlah peran yang diperluas. Mekanisme pengiriman yang berkelanjutan untuk peran membantu menyelesaikan masalah.
Hanya tentang ini, decoding dari laporan
Alexander Kharkevich di
DevOps Conf Russia . Dalam laporan: pengembangan peran yang dimungkinkan melalui CI, mekanisme untuk mengembangkan peran publik dan peran publik dengan uji coba di infrastruktur swasta. Dan tidak ada kesimpulan dalam laporan itu.
Tentang pembicara : Alexander Kharkevich (
kharkevich ) insinyur sistem senior di
EPAM Systems .
Mari kita mulai dengan ikhtisar singkat.
Tentang Ansible
Ansible adalah sistem manajemen konfigurasi. Itu ditulis dalam Python, templated oleh Junja, dan YAML digunakan sebagai DSL. Dikelola melalui Ansible Tower - WebUI untuk mengelola dan memantau kinerja sistem.
Ansible muncul pada 2012, setelah 3 tahun Red Hat membeli seluruh proyek, dan dua tahun kemudian memperkenalkan AWX - Project Open Source versi Ansible Tower.
Instalasi
Untuk menggunakan Ansible, Anda perlu melakukan dua hal sederhana.
Pada tahap pertama, kompilasi file inventaris jika ada infrastruktur statis.
Yang kedua adalah menulis Playbook yang akan membawa sistem ke keadaan yang diharapkan.
Seringkali kita memiliki keinginan yang tak tertahankan untuk menulis otomatisasi, yang dapat digunakan kembali. Otomasi adalah keinginan yang baik, dan orang-orang dari Ansible datang dengan konsep keren - peran.
Peran
Ini adalah entitas terstruktur yang akan membawa sistem ke kondisi yang diharapkan dengan kemampuan untuk menggunakan kembali otomatisasi.
Sebagai contoh, kita dapat menulis peran untuk Oracle Java: mengambil Playbook, meletakkan peran, dan menerapkannya ke sistem target. Output akan menginstal Java.
Bagaimana kami membayangkan bekerja dengan peran
Karena Ansible memiliki hal yang luar biasa sebagai peran, kami berpikir bahwa sekarang kami akan mengambil dan menulis banyak, banyak peran untuk semua kesempatan, bermain-main dan menggunakan kembali untuk mengurangi jumlah pekerjaan.
Kami pikir kami akan menulis peran yang indah dan cerdas ...
Tetapi hidup ternyata lebih rumit.
Ternyata, sebenarnya
Ketika lebih dari satu orang bekerja untuk menulis peran atau meningkatkannya, maka semua orang menulis di satu tempat dan kejutan yang tidak menyenangkan muncul: peran tersebut berperilaku berbeda dari apa yang dimaksudkan oleh penulis aslinya.
Itu baik ketika diterapkan sampai akhir, tetapi ini tidak selalu terjadi. Kadang-kadang peran berhasil dilakukan, tetapi pada sistem target ini tidak mempengaruhi sama sekali seperti yang diinginkan.
Akibatnya, konstruksi yang mengerikan muncul, upaya untuk mentransfer bash ke Ansible dan mengirimkan semua ini di bawah saus manajemen konfigurasi. Kami menemui fenomena ini dan sedih.
Berpikir, kami menemukan bahwa dalam manajemen konfigurasi kami ada beberapa jenis kode, yang berarti bahwa praktik yang berlaku untuk manajemen kode dalam System Development Life Cycle juga berlaku di Ansible.
- Kumpulkan praktik terbaik.
- Terapkan analisis statis, lint.
- Untuk menguji.
- Untuk melakukan overclock, untuk masuk ke manajemen rilis.
Kami memutuskan untuk menerapkan praktik di rumah dan segera pergi mencari alat yang sesuai.
Alat-alatnya
Dari sudut pandang sistem kontrol versi dan integrasi berkelanjutan, ada puluhan solusi yang tersedia, dan kebun binatang pengujian bercabang.
Dari sudut pandang manajemen rilis di Ansible tidak ada begitu banyak solusi: untuk menandai di Git, atau untuk menandai di Git dan mengunggah ke Galaxy.
Ada banyak pendekatan untuk alat pengujian, masing-masing menggunakan apa yang mereka suka. Solusi populer menggunakan KitchenCI, InSpec, Serverspec.
Jiwa kami tidak berbohong untuk mengambil Ansible ditulis dalam Python, dan mencampur alat dari dunia Ruby ke dalamnya. Oleh karena itu, setelah membuang semua yang bukan asli dari dunia Python, kami mendapatkan gambar berikut.
Kami menggunakan:
- Untuk manajemen konfigurasi - GitHub dan GitLab. GitLab menonton langsung di GitHub. Mengapa demikian, saya akan katakan nanti.
- Untuk CI, kami mengambil Travis untuk bagian publik dan GitLab Runner untuk bagian pribadi.
- Menguji Molekul.
- Luncurkan ke GitHub dan tambahkan ke Ansible Galaxy.
Siklus pengembangan kami dengan alat-alat ini menjadi lebih menyenangkan.
Molekul
Alat ini membantu untuk sepenuhnya menguji peran yang dimungkinkan. Untuk melakukan ini, ia memiliki segalanya:
- Integrasi dengan serat YAML dan Serat yang memungkinkan untuk memeriksa peran agar sesuai dengan persyaratan kami.
- Menguji infrastruktur untuk menjalankan tes fungsional.
- Driver Molekul adalah tempat Molekul menyebarkan bangku tes kami. Semuanya didukung: Azure, Didelegasikan, Docker, EC2, GCE, LXC, LXD, Openstack, Vagrant.
- Masih ada hal yang berguna dan sederhana - delegasi. Ini berarti Molekul tidak bertanggung jawab untuk memasang bangku tes dan pengembang harus menulis Playbook untuk menaikkan bangku tes. Jika Anda memiliki cloud super-pribadi, maka delegasikan pembuatan dan penghapusan mesin uji, dan Molecule sendiri akan menambahkan semua yang ada di dalamnya.
Matriks uji
Pertimbangkan matriks tes dalam beberapa langkah. Ada 11 langkah secara total, tapi saya akan singkat.
No. 1. Lint
Mereka menjalankan YAML lint dan Ansible lint, dan menemukan sesuatu.
Dalam contoh di atas, serat bersumpah bahwa cangkang seharusnya tidak hanya disebut dalam Ansible, tetapi harus diperbaiki, mengikat sesuatu.
No. 2. Hancurkan
Molekul menyingkirkan semua yang tersisa setelah tes sebelumnya.
Ada saat-saat ketika lari telah berlalu, tempat pelatihan telah dibuka, dan pengujian telah selesai. Dudukan harus dibersihkan pada akhirnya, tetapi force majeure campur tangan dan tidak ada pembersihan. Untuk situasi seperti itu, Molekul lari menghancurkan dan membersihkan lingkungan residu.
No. 3. Ketergantungan
Kami mengambil file requirement.yml dan menambahkan dependensi peran kami pada peran lain. Misalnya, referensi ke fakta bahwa peran tidak akan lepas landas tanpa Java diinstal pada sistem:
--- - src: lean_delivery.java version: 1.4
Molekul memahami ini dan akan menjalankan skrip:
- Goes Galaxy atau Git
- Akan menyadari bahwa perlu untuk menyelesaikan dependensi;
- Pergi ke Galaxy lagi;
- unduhan;
- akan berkembang.
No. 4. Sintaks
Langkah selanjutnya adalah memeriksa sintaksis. tetapi bukan peran Anda, tetapi tes Playbook yang Anda tambahkan ke Molecule. Ada kesalahan sintaks pada langkah ini juga.
Slide menunjukkan bahwa peran yang memungkinkan disebut 'kibana', dan dalam Playbook tes, itu disebut ansible-role-kibana. Sistem mengatakan: "Semuanya akan baik-baik saja dan Anda dapat membuatnya di sini, tapi saya tidak akan melakukannya karena namanya tidak cocok!"
No. 5. Buat
Pada tahap ini, kami menunjukkan driver yang digunakan untuk menguji situs tersebut. Point Google - itu akan meningkatkan mesin uji di Google Cloud.
Kita dapat menulis di file molecule.yml apa yang kita inginkan. Mari kita lihat tampilannya pada contoh untuk Docker.
- Saya menentukan gambar buruh pelabuhan untuk menarik.
- Saya menunjukkan cara mengelompokkan mereka sehingga file inventaris terbentuk.
Saya ingin memiliki dua gambar buruh pelabuhan: satu untuk RHEL-like, yang kedua untuk Debian-like, untuk memastikan bahwa selama uji coba semuanya akan baik-baik saja dengan RHEL dan Debian.
No. 6. Bersiap
Ini adalah langkah persiapan awal untuk lingkungan pelaksanaan tes.
Tampaknya semuanya telah meningkat, tetapi terkadang Anda perlu melakukan beberapa pengaturan tambahan. Dalam hal pengujian di dalam Docker yang ditinggikan di Debian atau Ubuntu, Anda perlu menginstal Python kedua, yang sering terjadi.
No. 7. Berkumpul
Tahap menjalankan besar pertama peran di dalam instance, untuk memastikan bahwa itu mencapai akhir, dijalankan, dan Ansible mengkonfirmasi bahwa semuanya baik-baik saja.
- Molekul mengacu pada Ansible.
- Kemungkinan dikerahkan ke situs uji.
- Itu berjalan.
- Semuanya baik-baik saja!
No. 8. Idempotence
Tes idempotensi sederhana dan terlihat seperti ini.
- Pertama kali peran dijalankan melalui langkah sebelumnya.
- Laporan yang memungkinkan berapa banyak perubahan yang telah dilakukan.
- Meluncurkan kembali peran yang sama.
- Memeriksa bahwa sistem telah dibawa ke keadaan yang diharapkan, tetapi tidak ada perubahan di rental kedua.
Sebagai hasilnya, kami memahami bahwa peran kami tidak bertindak destruktif.
Tahap ini menyebabkan rasa sakit bagi orang-orang yang bekerja dengan saya. Mereka berusaha menyiasati untuk mengalahkan tes idempotensi. Molekul dapat mengontrol tahapan yang dilaluinya, dan hal pertama yang mereka lakukan adalah mematikan pemeriksaan idempotensi.
Kami menangkap pingsan dan mengalahkan kami untuk itu, tetapi para insinyur cerdas dan masuk lebih dalam. Pengembang memutuskan untuk mengatakan bahwa langkah ini dalam Ansible tidak mengubah apa pun.
Meskipun sebenarnya beberapa jenis tim akan muncul di sini. Ansible akan langsung mengambil dan
akan menimpa file, tetapi pada saat yang sama semuanya terlihat idempoten.
Ketika trik ini juga tertangkap, gambar mulai terlihat seperti ini.
Bagus - skrip dijalankan dengan nama default, dan idempotent.
9. Efek samping
Pada tahap selanjutnya, efek samping ditumpangkan. Tidak perlu melakukan ini, tetapi akan lebih mudah jika Anda menguji peran penyebaran kompleks yang saling bergantung.
Misalnya, angkat tumpukan ELK, lalu Elasticsearch dalam sebuah cluster. Pada tahap side_effect, tambahkan data uji dan hapus beberapa node dari cluster. Situs uji siap untuk tes fungsional yang terjadi pada langkah berikutnya.
Nomor 10. Verifikasi
Menguji infrastruktur.
Di atas adalah contoh dari tes yang sangat sederhana. Kami memeriksa bahwa kami memiliki paket Edisi Komunitas Docker diinstal jika Ubuntu diinstal, ia memiliki versi yang benar, dan layanan sedang berjalan.
Pada tahap peluncuran tes fungsional ini, semuanya bisa sangat rumit.
Mungkin contoh terbaik adalah, dalam kasus tumpukan ELK, jika kita membuat permintaan dalam beberapa permintaan Elasticsearch untuk beberapa data uji, dan karena kita tahu data uji, itu akan menjawab kita. Kami tidak akan memverifikasi bahwa semua komponen yang diinstal sudah terpasang, tetapi melihat bahwa Elasticsearch sudah aktif, berjalan dan memberikan apa yang Anda butuhkan pada pencarian.
Ketika tes fungsional berjalan, tampaknya menjadi indah, berjalan naik dan turun di seluruh inventaris, dan sistem memberi tahu kita bahwa semuanya baik-baik saja dengan kita. Sekali lagi, tes akan berjalan jika kita menulisnya.
11. Hancurkan
Kami melakukan tes, ada laporan pengujian dalam beberapa bentuk, dan sekarang kami membuang semua sampah di belakang kami.
Otomasi
Molekul adalah alat yang hebat. Sekarang hal yang paling sederhana tetap ada - untuk menghubungkan sistem integrasi berkelanjutan untuk menikmati pengujian otomatis peran kami, yang kami lakukan.
Seperti di tempat lain, ada beberapa fitur.
Beberapa peran yang kami tulis untuk mengotomatiskan sesuatu adalah baik, tetapi kami tidak dapat menguji sistem menggunakan Travis, karena peran tersebut menyebarkan produk yang tidak dapat kami bagikan dengan alasan lisensi.
Misalnya, Anda memiliki penyebaran otomatis dari basis data Oracle. Jika Anda meletakkan basis pemasang dalam file, maka pengacara perusahaan akan mendatangi Anda dan akan sangat bersumpah. Agar setiap orang hidup dalam damai dan tidak bersumpah, kami memutuskan untuk melakukan hal berikut.
- GitLab, dalam salah satu rilis terbarunya, belajar bagaimana melakukan CI untuk repositori pihak ketiga.
- Perannya terletak di GitHub publik, publik yang sama dengan GitLab.com terhubung, di mana kami mengindikasikan: "GitLab yang terhormat, kumpulkan CI untuk kami di repositori eksternal".
- Pelari pribadi dibaut ke GitLab, dalam batas tertutup, dan mereka sudah memiliki akses ke biner, yang dapat mereka gunakan.
Bahkan, perannya terletak di depan umum, data juga, dan kami tidak menipu siapa pun - kami menjalankan tes nyata dengan alat nyata.
Mari kita lihat langkah-langkahnya di Travis.
Travis
Langkah-langkahnya:
- Pada langkah pertama, baris ke-8, kami memberi tahu Travis bahwa kami tidak hanya ingin meluncurkannya, tetapi juga menggunakan layanan Docker sehingga Docker tersedia di dalam Travis.
- Selanjutnya, baris ke-10, kita ambil aturan serat kita. Kami tidak hanya menggunakan aturan serat Ansible default, tetapi juga menulis sendiri.
- Pada saluran 15, pertama-tama kita memanggil serat untuk menghemat waktu dalam menjalankan matriks tes. Jika sesuatu tidak ditulis sesuai aturan, dan tidak ditemukannya, maka ia pergi ke awal dan meninggalkan laporan. Pengembang yang melakukan, memperbaiki komitnya, atau membuang perubahan. Ketika sudah diperbaiki, biarkan datang, dan kami akan terus melanjutkan tes.
CI publik
CI publik terlihat sederhana.
Dari GitHub, panah ke Travis, di dalamnya tinggal Molecule dan Docker.
CI pribadi
Untuk bagian pribadi GitLab, semuanya sama.
Di perimeter pribadi, kami menjalankan pelari, dan gambar terlihat lebih menyenangkan.
Kode didapat dari GitHub ke GitLab, di suatu tempat runner pribadi menjalankan yang dapat menarik layanan eksternal, misalnya, menjalankan sesuatu di Amazon.
Sedikit penyimpangan. Memulai dan menggunakan lingkungan pengujian di Amazon tidak ingin porting, karena Anda memerlukan kunci. Untuk membuat mekanisme untuk menempatkannya di publik, tetapi pada saat yang sama tidak menjadi platform startup berikutnya untuk penambangan - ini adalah tugas yang tidak sepele. Karena itu, kami tidak menyelesaikannya, tetapi mengambil pelari secara pribadi agar tidak menambang bitcoin Amazon.
Bahkan di sini, kami sedikit malas dan melakukan yang berikut. Kami di EPAM memiliki cloud pribadi kami sendiri dan itu adalah hybrid. Ini berarti bahwa banyak awan publik dapat diakses dari awan bagian dalam, seperti daerah. Anda tidak dapat menulis seribu tes, tetapi bermain-main dengan wilayah dan berkata: "Sekarang uji sesuai dengan skenario tes ini untuk AWS, EPAM Cloud, wilayah Azure."
Galaksi yang memungkinkan
Kami datang ke final, peran kami hijau, cantik, kami akan menerbitkannya di Galaxy.
Ini adalah operasi sederhana:
- Panggilan webhook yang ada di Travis.
- Dalam hal ini, Travis akan memicu, CI akan berjalan lagi.
- Hubungi webhook.
- Versi baru akan berhasil tumbuh di Galaxy.
Ada satu fitur - jika Anda tidak menandai peran, jangan menandai, jangan tetapkan versi untuknya, maka di Galaxy itu akan selalu tanpa versi. Segera setelah pengembang lain ingin menginstalnya sendiri melalui pemasangan Ansible Galaxy, ia akan mengambil peran yang terletak di cabang master, atau di cabang lain secara default. Secara default, cabang tidak selalu stabil, yang merepotkan.
Jika Anda menerbitkan sesuatu di Galaxy, jangan lupa untuk menandainya, benar sehingga ada versi, dan semuanya keren.
Pola
Saya membagikan sedikit trik: agar tidak menyalin-menempel setiap kali menulis peran baru, kami memutuskan untuk membuat templat dan repositori terpisah tempat kami meletakkan templat agar dapat dengan cepat menulis peran dari awal.
Templat memiliki pengaturan default untuk Anonymous lint dan GitHub issue_template. Semuanya ada dalam domain publik, oleh karena itu issue_template dalam bentuk yang indah juga indah bagi kami untuk mengeluarkan permintaan tarik atau laporan bug. Kami menambahkan templat untuk Gitignore, Gitlab-ci dan lisensi ke repositori yang sama.
Secara default, kami menerbitkan di bawah lisensi Apache 2.0. Jika Anda ingin datang kepada kami dan menggunakan kembali templat, Anda dapat mengambil semuanya, membuat repositori tertutup dan tidak menjelaskan apa pun kepada siapa pun. Terima kasih Apache.
Kami memiliki beberapa opsi pengujian sehingga Anda dapat dengan cepat menendang dan memulai semuanya.
Ringkasan
Tidak akan ada kesimpulan, sebaliknya ada tautan ke
GitHub saya,
profil Galaxy saya,
Pengiriman Lean GitHub dan
Galaksi yang Mungkin . Dengan menggunakan tautan, Anda dapat melihat cara kerja semuanya. Semua contoh tersedia secara bebas.
Konferensi DevOps berikutnya akan diadakan pada bulan Mei.
Sementara kami menunggu acara, berlangganan saluran dan buletin YouTube . Saluran akan diisi ulang dengan catatan laporan terbaik, dan di milis akan ada pilihan bahan yang berguna, transkrip dan berita DevOps.
Berlangganan, itu akan menarik :)