Cara membuat infrastruktur TI Anda membosankan

Michael DeHaan adalah orang yang menciptakan Ansible. Banyak hal yang dilakukan oleh administrator sistem, rilis, dan teknisi DevOps secara teratur, secara halus, tidak menarik. DeHaan ingin orang-orang ini meluangkan waktu mereka untuk hal-hal yang lebih menarik (di tempat kerja atau di luar pintu kantor), dan menulis kode produk yang membebaskan waktu administrator.
Lebih banyak waktu, lebih sedikit adrenalin selama jam kerja, lebih sedikit skrip dan lebih sedikit kesalahan.
Ngomong-ngomong, Anda bisa selesai membaca paragraf ini dengan menghubungkan ke streaming langsung pada 6 Juni di sini .



Jika Anda masih terus membaca ...

Ansible: Integrasi dan Pengiriman berkelanjutan

Ansible adalah bahasa otomatisasi open source yang kuat. Ya, ini bagus tidak hanya untuk manajemen, tetapi juga untuk penyebaran dan pengaturan sistem TI. Ansible pada awalnya diciptakan untuk secara efektif menyelesaikan berbagai tugas otomatisasi, dan sebagai dasar universal sederhana untuk mengganti kontrol tradisional, tetapi pada akhirnya ternyata sangat berguna di banyak bidang. Misalnya, sambil memastikan nol waktu henti selama integrasi dan pengiriman aplikasi (CI / CD) yang berkelanjutan. Biasanya masalah ini diselesaikan karena penyempurnaan perangkat lunak yang luas, penggunaan berbagai paket perangkat lunak dan banyak trik unik untuk setiap konfigurasi spesifik. Ansible pada awalnya dirancang khusus untuk skenario orkestrasi semacam itu dan menawarkan solusi turnkey "all in one."

Integrasi dan Pengiriman Aplikasi (CI / CD) Berkelanjutan

Beberapa kebenaran umum. Praktek mengembangkan sistem perangkat lunak selama 10 tahun terakhir menunjukkan bahwa siklus hidup yang panjang dari versi perangkat lunak (cascading development model) memiliki overhead yang jauh lebih tinggi dibandingkan dengan siklus pendek (yang disebut "iteratif" atau pengembangan gesit). Ini semua tentang aritmia: ketika programmer baru mulai bekerja pada versi baru, tidak ada yang bisa dilakukan oleh staf TI yang bertanggung jawab atas pengujian dan penerapan. Tetapi semakin dekat versi ke rilis, semakin profesional TI yang sibuk, dan semakin sering programmer harus mengubah konteks, bergantian antara mengerjakan bug dan merencanakan versi berikutnya.

Selain itu, siklus panjang meningkatkan interval antara identifikasi dan penghapusan kesalahan dan kekurangan perangkat lunak, yang sangat penting untuk sistem web besar dengan khalayak pengguna jutaan dolar. Oleh karena itu, industri perangkat lunak dengan cepat mengadopsi metodologi lincah di bawah slogan "rilis lebih cepat dan lebih sering" sehingga peserta dalam proses pengembangan dapat lebih jarang mengubah konteks pekerjaan mereka dan membuat, men-debug dan mengimplementasikan perbaikan dan inovasi lebih cepat.

Otomatisasi kontrol kualitas, pengembangan TDD melalui pengujian dan teknik terkait lainnya semakin meningkatkan efektivitas metode kerja baru. Di mana otomasi itu? Di mana teknologi yang membuat roda gigi berputar lebih cepat dan mengurangi partisipasi manusia seminimal mungkin?

Dan di sini, misalnya, Red Hat's Ansible dan Ansible Tower untuk mengatur sistem TI sebagai bagian dari proses pengembangan perangkat lunak modern.

Zero Downtime

Sedikit lebih jelas. Downtime berarti kehilangan untung dan pelanggan yang tidak puas. Oleh karena itu, dalam sistem antrian web, pengguna yang didistribusikan di semua zona waktu, penjadwalan yang dijadwalkan hanya diperbolehkan dalam kasus yang sangat serius, daftar yang tidak secara eksplisit menyertakan pembaruan versi aplikasi. Situasi serupa di lingkungan perusahaan di mana tidak dapat diaksesnya suatu intranet atau sistem akuntansi secara dramatis mengurangi produktivitas karyawan. Dengan demikian, otomatisasi proses apa pun harus menyediakan pembaruan tanpa mengganggu operasi - dengan kata lain, dengan nol downtime.

Sangat mungkin untuk mencapai zero downtime, tetapi untuk ini kita membutuhkan alat yang tepat - seperti untuk menyediakan orkestrasi multi-level, multi-level, dan canggih, seperti, misalnya, sistem Ansible.

Sistem Bangun Aplikasi

Pengiriman Berkelanjutan (CD) dimulai dengan Continuous Integration (CI). Suatu sistem yang memonitor repositori kode sumber untuk perubahan, secara independen menjalankan tes yang sesuai dan secara otomatis membangun (dan idealnya menguji) versi baru aplikasi dengan setiap pembaruan kode, misalnya, proyek Jenkins (jenkins.io).

Untuk menyampaikan tongkat ke sistem CD setelah berhasil merakit versi baru aplikasi, subsistem sistem CI dapat memanggil Ansible untuk segera memberikan versi baru ini kepada mereka yang melakukan pengujian unit atau integrasi. Secara khusus, Jenkins dapat menggunakan Tower untuk mengerahkan majelis di berbagai lingkungan, dan lingkungan uji atau menengah dapat dimodelkan berdasarkan lingkungan produksi, yang sangat meningkatkan prediktabilitas sepanjang siklus hidup perangkat lunak. Data yang dikembalikan oleh Ansible dari hasil pelaksanaan skrip otomatisasi dapat secara langsung terlibat dalam pekerjaan Build Systems pada sistem Tower. Bahkan, Tower bahkan memungkinkan Anda untuk menguji skenario penempatan di lingkungan perantara sebelum menjalankannya di server "tempur".

Pembaruan aplikasi bertingkat satu per satu

Sistem CD harus dapat mengatur proses pembaruan bergulir aplikasi multilevel. Berkat arsitektur push dan kemampuan orkestrasi multi-level multi-level, Ansible dapat mengatasi tugas ini dengan memperbarui setiap level aplikasi dengan level, sambil bertukar data di antara mereka.

Untuk menerapkan pembaruan satu-per-satu, Ansible menggunakan skrip Play yang memungkinkan Anda menentukan dengan tepat grup host target dan menetapkan tugas (Peran) yang harus dilakukan pada mereka. Tugas biasanya adalah pengumuman bahwa sumber daya IT tertentu harus dalam keadaan tertentu, misalnya, untuk satu versi perangkat lunak, paket tertentu harus diinstal, dan untuk yang lain perlu untuk memeriksa repositori kode. Topologi aplikasi web, sebagai suatu peraturan, memerlukan pembaruan mereka dalam urutan yang ketat, dan Anda masih tidak dapat memperbarui aplikasi dan konfigurasi sistem pada semua mesin secara bersamaan.

Ketika layanan restart, itu tetap tidak tersedia untuk beberapa waktu, dan mengganti versi aplikasi juga tidak terjadi secara instan. Karena itu, sebelum memperbarui sistem, kami menariknya dari kelompok penyeimbang. Akibatnya, Anda memerlukan kemampuan untuk mengotomatiskan operasi menghubungkan dan melepaskan mesin dari kolam. Secara konsisten adalah kata kuncinya. Ansible dapat dengan tepat mengontrol ukuran jendela dari pembaruan yang berurutan. Ya, pengembangan pembaruan semacam itu dilakukan dengan sangat hati-hati, dan jika pada tahap tertentu terjadi kegagalan, pembaruan tersebut ditangguhkan agar tidak menonaktifkan infrastruktur TI lainnya.

Penerapan berkelanjutan untuk Skrip Otomasi

Selain fungsionalitas CD untuk layanan yang beroperasi dalam mode operasi komersial, Anda juga dapat mengatur sendiri penerapan skrip otomasi (Kumpulan instruksi Playbook yang mungkin. Jangan berhenti membaca, di bagian kedua akan ada contoh playbook). Ini memungkinkan administrator sistem dan pengembang untuk mengelola skrip menggunakan repositori kode sumber, menguji skrip ini di lingkungan perantara dan secara otomatis mentransfernya ke lingkungan produksi jika pembobolan berhasil. Dengan kata lain, ketika bekerja dengan skrip, Anda mendapatkan semua keuntungan metodologis dan lainnya dari repositori kode pusat yang biasa Anda gunakan ketika mengembangkan perangkat lunak.

Membuat perubahan pada konfigurasi perangkat lunak dan sistem adalah salah satu alasan utama pemadaman yang tidak direncanakan. Karena itu, selain pengujian otomatis, ada kontrol manusia. Itu dapat diatur dengan mengintegrasikan dengan sistem inspeksi kode seperti Gerrit , dan menerapkan perubahan hanya setelah disetujui oleh kawan-kawan yang bertanggung jawab.

Pembaruan alternatif dan sistem penyeimbangan beban

Ansible bekerja sangat mandiri dengan sistem penyeimbangan beban saat melakukan pembaruan berurutan. Oleh karena itu, Anda cukup menulis dalam skrip Playbook, dalam siklus apa pun untuk sekelompok host, sesuatu seperti "melakukan tindakan ini pada sistem X atas nama host Y", dan Ansible akan mengurus sisanya.

Kemungkinan berinteraksi dengan baik dengan penyeimbang beban dari semua jenis dan dapat menetapkan tanda untuk memutus sementara suatu host untuk menonaktifkan pemantauan ketersediaan untuknya selama periode pembaruan. Skema sederhana "matikan pemantauan - hapus dari kolam - perbarui level perangkat lunak yang diinginkan - kembali ke kolam - matikan pemantauan" dengan mudah mengimplementasikan pembaruan berurutan dengan downtime nol dan tanpa alarm palsu. Dan semua ini dalam mode otomatis sepenuhnya, tanpa campur tangan operator.

Pengujian Menengah Terintegrasi

Tower dapat bekerja dengan berbagai file inventaris sumber daya (Inventaris), yang membuatnya mudah untuk menguji skenario pembaruan berturut-turut di lingkungan perantara sebelum menjalankannya di server "battle". Untuk melakukan ini, cukup mensimulasikan lingkungan produksi di lingkungan pengujian, menjalankan Ansible dengan parameter "-i" dan menunjukkan file inventaris mana yang harus digunakan saat menjalankan skrip - untuk lingkungan pengujian atau untuk lingkungan produksi. Script itu sendiri tidak perlu dimodifikasi.

Penerapan Kontrol Versi

Beberapa orang suka mengemas aplikasi bersama dengan paket OS (RPM, debs, dll.) Lebih panas, tetapi seringkali, terutama untuk aplikasi web, pengemasan seperti itu tidak diperlukan. Oleh karena itu, Ansible mencakup beberapa modul untuk menyebarkan aplikasi langsung dari sistem kontrol versi. Dalam skrip Playbook, Anda dapat menulis rekonsiliasi dengan repositori kode untuk tag atau nomor versi yang ditentukan, setelah itu Ansible akan memeriksa kondisi ini di semua server target dan mengaktifkan langkah-langkah berikutnya hanya jika versi perlu diganti, sehingga menghilangkan restart layanan yang tidak perlu.

Integrasi dengan alat pemantauan

Sebagai sistem orkestrasi yang lengkap, Ansible mendukung integrasi dengan sistem manajemen kinerja aplikasi berbasis APM di tingkat pemantauan. Misalnya, selama fase pengujian penerapan atau integrasi, Anda harus menginstal atau memutakhirkan agen perangkat lunak APM dengan aplikasi tersebut. Ansible memiliki peran khusus untuk ini, dan setelah menginstal dan mengaktifkan agen, Ansible dapat mengkonfigurasinya dalam tumpukan pemantauan APM (jika belum dikonfigurasi) sehingga manajer aplikasi dapat segera memverifikasi bahwa versi baru telah diinstal dan berfungsi tanpa masalah .

Jika ada yang tidak beres setelah memperbarui aplikasi di lingkungan produksi, alat pemantauan mungkin memanggil Kemungkinan untuk memutar kembali ke versi sebelumnya. Tentu saja, hanya jika kemunduran seperti itu diizinkan.

Pemberitahuan Acara

Dalam paradigma CI / CD, semua orang ingin menerima pemberitahuan acara secepat mungkin. Ansible menawarkan fungsi bawaan, termasuk modul email, serta integrasi dengan alat pemberitahuan eksternal, seperti pesan instan, jejaring sosial atau sistem pendaftaran acara.

Penerapan menggunakan model status sumber daya

Salah satu fitur kunci dari Ansible, yang membuatnya menjadi alat yang sangat berguna untuk menyebarkan aplikasi, adalah penggunaan model keadaan sumber daya secara teratur dalam proses pembaruan perangkat lunak, yang telah mendapatkan popularitas dalam mengelola konfigurasi sistem. Tidak seperti kontrol open source tradisional, Ansible tidak perlu dilengkapi dengan perangkat lunak tambahan atau skrip khusus untuk mengatur pengiriman aplikasi.

Di Ansible, Anda dapat mendaftar dan mengontrol urutan peristiwa dengan sangat tepat di tingkat arsitektur yang berbeda, yang memungkinkan Anda mendelegasikan tindakan ke sistem lain, serta menggabungkan arahan model sumber daya (seperti "paket X harus dalam keadaan Y") dan perintah skrip tradisional (seperti "skrip jalankan" .sh ") dalam satu proses.

Ansible juga memudahkan untuk menjalankan verifikasi berbagai kondisi dan membuat keputusan berdasarkan hasil mereka. Menggabungkan proses konfigurasi sistem dan penyebaran aplikasi dalam rantai alat tunggal jauh lebih efisien daripada skema dengan beberapa alat khusus, dan, di samping itu, meningkatkan konsistensi kebijakan dan aplikasi OS.

Pengujian Penempatan

Semakin banyak peluang, semakin tinggi tanggung jawabnya. Otomatisasi proses pengiriman berkelanjutan secara dramatis meningkatkan risiko penerapan konfigurasi yang gagal pada semua node sistem. Untuk mengurangi risiko, Ansible menyarankan untuk memasukkan tes kontrol dalam skrip, yang akan mengganggu pembaruan sekuensial jika terjadi kesalahan. Untuk menguji berbagai kondisi, termasuk status fungsi layanan, Anda dapat menggunakan tes sewenang-wenang menggunakan modul Command atau Script, dan bahkan membuat tes tersebut sebagai modul Ansible yang terpisah.

Modul Gagal dapat menghentikan eksekusi skrip pada host kapan saja, yang memungkinkan Anda mengetahui kegagalan pada tahap awal pembaruan sekuensial. Misalnya, karena perbedaan antara lingkungan menengah dan lingkungan produksi, yang terakhir menghasilkan kesalahan konfigurasi, yang menonaktifkan server "tempur". Dalam hal ini, jalan keluar darurat dapat didaftarkan di skrip Playbooks pada tahap pertama pembaruan berurutan. Dan jika Anda memiliki 100 server, dan ukuran jendela pembaruan berturut-turut adalah 10, maka penghentian darurat seperti itu akan memberi Anda waktu untuk dengan tenang mengetahuinya, memperbaiki skrip dan terus memperbarui.

Jika terjadi kegagalan, Ansible tidak terus bekerja, meninggalkan sistem dalam keadaan semi-konfigurasi, dan menghasilkan kesalahan untuk menarik perhatian operator dan memberi tahu dia tentang host mana yang siklus pembaruannya mengalami kesalahan dan berapa banyak perubahan yang dilakukan pada setiap platform. Ansible memiliki mode jalankan simulasi, ketika sistem membuat laporan tentang perubahan apa yang akan dilakukan jika skrip dieksekusi tanpa eksekusi sebenarnya.

Pemeriksaan kepatuhan

Ada beberapa lingkungan di mana konfigurasi berubah hanya ketika tidak ada jalan tanpanya. Setiap perubahan dalam lingkungan seperti itu sudah dianalisis sebelumnya. Ini menggunakan sistem pengiriman berkelanjutan "dengan pemesanan".

Ansible memiliki mode jalankan simulasi (diaktifkan oleh tanda “--check”), ketika sistem membuat laporan tentang perubahan apa yang akan dilakukan ketika skrip dieksekusi. Dalam kasus ini, eksekusi skrip yang sebenarnya tidak terjadi, proses simulasi tidak memungkinkan penangkapan kesalahan, tetapi membantu untuk lebih memahami dan menganalisis rincian dan hasil dari perubahan yang diajukan.

Di sisi lain, bahkan dengan penyebaran majelis baru yang terus menerus, Ansible memungkinkan Anda untuk menjalankan pemeriksaan kesesuaian lebih sering untuk menangkap momen ketika beberapa hal dalam lingkungan produksi berubah sebagai akibat dari intervensi manusia dan perlu diperbaiki dengan menjalankan skrip Ansible yang sesuai, misalnya, untuk mengubah versi perangkat lunak, sesuaikan izin, dll.

Penerapan autopilot

Jika Anda tinggal di dunia multi-level multi-tahap orkestrasi proses pembaruan perangkat lunak berurutan dengan downtime nol, maka kemungkinan besar CI / CD dilakukan secara eksklusif oleh operator (baik secara manual dan dengan otomatisasi parsial) dan memerlukan, seperti dalam tarian bundar, tindakan terkoordinasi dari semua peserta proses. Memungkinkan bersama dengan arsitekturnya yang unik dan tidak adanya agen perangkat lunak pada host target (meningkatkan keamanan dan menghilangkan kebutuhan untuk mengelola sistem manajemen itu sendiri) dapat dengan mudah menggambarkan dan dengan mudah mengotomatiskan proses penyebaran yang rumit, yaitu, Ansible mengimplementasikan mode autopilot penuh di sini.

Contoh skrip otomatisasi Ansible dapat ditemukan di GitHub , dan sekarang kami akan memberikan dasar dan contoh bagaimana menulis skrip Playbook yang dapat dijalankan di Ansible atau Ansible Tower. Bersama-sama dengan daftar modul dan dokumen lainnya, dia akan membantu Anda belajar cara membuat skrip Playbook Anda sendiri.

Apa itu buku pedoman?

Skrip Playbook pada dasarnya adalah serangkaian permainan yang dikirim untuk dieksekusi pada satu host jarak jauh atau sekelompok host. Ini seperti panduan perakitan furnitur IKEA: ikuti instruksi dengan tepat dan dapatkan apa yang Anda lihat di toko. Begitulah cara kerja skrip.

Modul

Kami akan membuat Playbook yang akan menginstal server web pada host RHEL / CentOS 7 dan membuat file index.html berdasarkan template yang ditentukan dalam skrip. Skrip sampel yang ditampilkan di sini sepenuhnya operasional dan siap digunakan. Di bawah ini kita akan melihat contoh naskah Playbook dan menunjukkan cara menggunakan modul.

Penulis (Penulis)

Seorang penulis adalah seseorang yang membuat instruksi yang akan dieksekusi oleh modul (seringkali bersama dengan nilai tambahan: argumen, lokasi, dll.). Modul dijalankan pada host target sesuai urutannya dalam skrip Playbook (termasuk include'y dan file tambahan lainnya yang disertakan di dalamnya). Keadaan host berubah (atau tidak berubah) tergantung pada hasil eksekusi modul, yang ditampilkan dalam bentuk output Ansible dan Tower.

Eksekusi skrip Playbook

Pertama, ada beberapa hal yang perlu Anda ketahui tentang menjalankan skrip Playbook. Playbook adalah sejenis sistem simbolik yang menginformasikan modul tentang perlunya melakukan beberapa tugas. Agar berhasil meluncurkan Playbook Anda, penting untuk memahami poin-poin berikut:

1. Sistem target (Target)
Karena skrip Playbook memberikan instruksi untuk dan berinteraksi dengan modul, Ansible percaya bahwa Anda memahami apa yang Anda coba lakukan dan hanya mengotomatiskannya. Itulah mengapa kami mengatakan bahwa Playbook seperti instruksi atau petunjuk: Anda memberi tahu elemen otomatis bagaimana Anda ingin mengonfigurasi tugas. Tetapi pada saat yang sama, Anda sendiri perlu memahami dengan baik bagaimana host target yang menjalankan skrip Playbook berfungsi.

2. Tugas
Jika Anda perlu memulai server web di beberapa bagian Playbook, Anda harus memahami bagaimana hal ini dilakukan untuk mengetahui modul layanan mana yang akan digunakan untuk ini dan memulai server web dengan nama. Jika Playbook menginstal paket perangkat lunak, Anda harus tahu bagaimana melakukan ini pada host target. Anda juga harus memahami, setidaknya pada tingkat dasar, esensi dari tugas yang dilakukan. Apakah konfigurasi host tambahan diperlukan untuk perangkat lunak yang ingin Anda instal? Apakah ada cabang tergantung pada kondisi dan nilai argumen? Jika ada variabel yang diteruskan dalam proses, Anda harus memahami dengan tepat apa dan mengapa.

Contoh Skrip Playbook
Contoh skrip Playbook berikut akan membantu Anda memahami apa yang baru saja Anda baca. Host target di dalamnya adalah server RHEL / CentOS 7, di mana skrip kami menginstal server web NGINX, dan kemudian membuat file index.html di direktori webroot default.Setelah menyelesaikan instalasi dan membuat indeks, server web memulai.

* Catatan: Untuk menjalankan contoh skrip Playbook ini di Ansible Tower, Anda harus terlebih dahulu mengonfigurasi inventaris dan akun.

Playbook dimulai dengan tiga tanda hubung YAML (---), diikuti oleh:

Nama : cukup nama skrip untuk menjaga keterbacaan Playbook.

Host : Daftar host target di mana Ansible harus bekerja.

Menjadi : di sini kami telah menulis pernyataan yang benar untuk memastikan bahwa nginx telah diinstal tanpa masalah (bidang ini tidak selalu diperlukan).

1 --- 2 - name: Install nginx 3 hosts: host.name.ip 4 become: true 

Dengan lekukan seperti tiga baris sebelumnya, ada tugas : direktif, setelah itu, dengan lekukan tambahan (sesuai dengan aturan bersarang YAML), tugas terdaftar (bermain). Dalam contoh ini, kami memiliki dua tugas, dan keduanya menggunakan modul Yum. Tugas pertama menambahkan repositori rilis-epel sehingga Anda dapat menginstal nginx. Setelah epel muncul di sistem, tugas kedua menginstal paket nginx.

State : directive berarti Ansible harus memeriksa keadaan host target sebelum melakukan tindakan lebih lanjut. Dalam contoh kami, jika sudah ada repositori atau nginx pada host, Ansible memahami bahwa tidak perlu melakukan dua tugas ini, dan melanjutkan ke yang berikut.

 1 tasks: 2 - name: Add epel-release repo 3 yum: 4 name: epel-release 5 state: present 6 7 - name: Install nginx 8 yum: 9 name: nginx 10 state: present 

Halaman unduhan, yang digunakan secara default di nginx, bagus untuk memeriksa apakah nginx telah diinstal dengan benar, tetapi Anda mungkin ingin melakukan ini dengan file html awal Anda. Dalam contoh ini, untuk kesederhanaan, templat file indeks berada di direktori yang sama tempat Playbook dimulai. Tujuan hanyalah jalur default di nginix tanpa situs yang dikonfigurasi.

 1 - name: Insert Index Page 2 template: 3 src: index.html 4 dest: /usr/share/nginx/html/index.html 

Baris terakhir di Playbook kami hanya berfungsi untuk memverifikasi bahwa layanan nginx telah berhasil dimulai (atau memulainya jika tidak).

 1 - name: Start NGiNX 2 service: 3 name: nginx 4 state: started 

Seluruh skrip Playbook hampir sama dengan paragraf pembuka di posting ini:

 1 --- 2 - name: Install nginx 3 hosts: host.name.ip 4 become: true 5 6 tasks: 7 - name: Add epel-release repo 8 yum: 9 name: epel-release 10 state: present 11 12 - name: Install nginx 13 yum: 14 name: nginx 15 state: present 16 17 - name: Insert Index Page 18 template: 19 src: index.html 20 dest: /usr/share/nginx/html/index.html 21 22 - name: Start NGiNX 23 service: 24 name: nginx 25 state: started 

Ringkasan

Skrip playbook adalah cara mudah dan nyaman untuk melakukan banyak hal dengan sedikit kode. Dalam contoh di atas, kami menggunakan tiga modul - yum, templat dan layanan, untuk menginstal paket repositori dan perangkat lunak di server, membuat file dari templat lokal dan kemudian memulai layanan yang baru saja diinstal. Pada saat yang sama, naskah Playbook kami keluar sedikit lebih lama dari penawaran ini! Dan meskipun kami menjalankannya pada satu host, bisa juga melakukannya pada lusinan dan ratusan server, untuk ini hanya perlu dilakukan perubahan yang sangat kecil untuk itu. Selain itu, Tower memungkinkan Anda menempatkan skrip Playbook dalam templat pekerjaan untuk dijalankan pada sekelompok server di cloud AWS atau di pusat data perusahaan.

Fitur arsitektur yang memungkinkan dan kemampuan untuk berintegrasi dengan sistem CI, seperti Jenkins, mengotomatisasikan tidak hanya proses manajemen konfigurasi, tetapi juga berbagai tugas TI yang jauh lebih luas. Itu sebabnya kami dengan sayang menyebut Ansible sistem orkestrasi terintegrasi, dan bukan hanya penyebaran perangkat lunak dan alat manajemen konfigurasi.