Beberapa minggu yang lalu, saya mulai menggunakan Ansible untuk menyederhanakan tugas administratif untuk beberapa organisasi yang saya dukung. Selain itu, saya terutama ingin menyederhanakan pengelolaan armada saya sendiri yang terdiri dari delapan atau sembilan host (jumlah pasti sering berubah). Saya telah melakukan semua otomatisasi saya menggunakan skrip Bash sejak saya mulai menggunakan Linux. Saya menggunakan skrip untuk mengotomatisasi distribusi skrip pembaruan-otomatisasi lainnya, file konfigurasi sistem dan pengguna, peningkatan ke rilis Fedora yang lebih baru, dan pembaruan ke rilis Fedora baru. Dan itu tidak termasuk semua tugas ad-hoc kecil yang muncul dalam hitungan jam.
Skrip akan terus memainkan peran penting dalam otomatisasi administratif saya. Namun, Ansible sepertinya dapat mengambil alih banyak tugas dan melakukannya jauh lebih baik daripada skrip yang rumit. Ini semua tentang buku pedoman , dan dalam artikel ini, saya membuat yang dapat melakukan pembaruan sistem sambil memperhitungkan perbedaan sistem.
Saya baru-baru ini menulis tentang Hari Pertama Saya Menggunakan Ansible. Jika Anda belum membaca artikel itu, Anda mungkin ingin melakukannya sebelum melanjutkan dengan yang ini. Artikel ini mengasumsikan bahwa Anda memiliki beberapa keakraban yang sangat mendasar dengan menggunakan Ansible. Jika Anda telah membaca artikel saya pada tautan di atas, Anda seharusnya dapat mengikuti teks ini tanpa kesulitan.
Artikel ini dibagi menjadi dua bagian, jadi pastikan untuk membaca bagian kedua. Di bagian ini, kita akan mendefinisikan beberapa konsep dan istilah Ansible yang penting, mendiskusikan komentar, dan menerapkan permainan pertama dari buku pedoman. Bagian dua berlanjut dengan dua drama yang tersisa, beberapa informasi lanjutan, dan daftar sumber daya saya.
Buku pedoman artikel ini tidak memerlukan pemasangan modul atau koleksi Ansible apa pun di luar modul bawaan bawaan. Playbook ini telah diuji dengan Ansible 2.9.14.
[ Pembaca juga menyukai: Tambahkan repo dan instal paket dengan cara yang Mungkin ]
Apa itu buku pedoman?
Saat saya menulis artikel ini, saya juga menonton beberapa sesi AnsibleFest virtual tahun ini. Saat menonton, saya mengembangkan deskripsi saya sendiri tentang buku pedoman—yang masuk akal bagi saya. Uraian ini berisi kepingan-kepingan hikmah dari buku pedoman dari beberapa penyaji, serta beberapa buku dan postingan blog yang telah saya baca.
Ini definisi saya:
Buku pedoman Ansible adalah deskripsi buatan manusia tentang keadaan yang diinginkan dari satu atau lebih komputer. Ansible membaca buku pedoman, membandingkan keadaan komputer yang sebenarnya dengan keadaan yang ditentukan dalam buku pedoman, dan melakukan tugas yang diperlukan untuk membawa komputer tersebut agar sesuai dengan keadaan yang dijelaskan dalam buku pedoman.
Pembaruan
Menginstal pembaruan pada host Linux modern adalah tugas yang hampir konstan, dibuat penting oleh jumlah perbaikan keamanan dan peningkatan fitur yang keluar terus menerus. Jika perangkat lunak tertentu, seperti kernel, glibc, atau systemd diperbarui, host juga perlu di-boot ulang. Beberapa tugas tambahan juga perlu dilakukan, seperti memperbarui database halaman manual.
Meskipun saya memiliki instalasi pembaruan otomatis dengan skrip yang keren, beberapa host saya perlu diperlakukan sedikit berbeda dari yang lain. Misalnya, saya tidak ingin memperbarui firewall dan server email/web/DHCP/DNS saya secara bersamaan. Jika server di-boot ulang, firewall tidak dapat memperoleh informasi yang diperlukan untuk melanjutkan pembaruannya sendiri, begitu pula dengan host lain di jaringan saya. Jika firewall mati, akses ke repositori Fedora eksternal hilang ke server saya dan semua host internal lainnya. Itu berarti menunggu kedua host ini melakukan boot ulang sebelum pembaruan dapat dimulai pada host lain.
Jadi saya biasa melakukan pembaruan itu dengan memulai skrip di firewall dan kemudian menunggu sampai selesai, kemudian pindah ke server dan menunggu sampai selesai sebelum menjalankan program baris perintah kecil untuk menjalankan skrip pembaruan secara berurutan pada host saya yang lain. Saya bisa saja menulis dependensi ini ke dalam skrip saya, tetapi beberapa hari pertama saya dengan Ansible menunjukkan kepada saya bahwa ia sudah memiliki kemampuan itu dan banyak lagi yang akan membuat tugas saya jauh lebih mudah. Sungguh—JAUH lebih sederhana. Dan lebih cepat secara keseluruhan, tanpa intervensi dari saya.
Strategi yang Mungkin
Ansible menggunakan strategi hub untuk mengelola host. Perangkat lunak Ansible diinstal pada host yang bertindak sebagai pengontrol. Perangkat lunak Ansible sisi klien tidak ada, jadi tidak ada yang perlu diinstal pada host jarak jauh.
Ansible menggunakan SSH, yang sudah diinstal oleh hampir semua distribusi Linux, untuk berkomunikasi dengan host jarak jauh. Meskipun Sysadmin dapat memilih untuk menggunakan kata sandi untuk akses jarak jauh ke host, itu tentu saja mengurangi efisiensi dan sifat lepas tangan dari alat seperti Ansible. Jadi, seperti kebanyakan admin lainnya, saya menggunakan pasangan kunci publik/pribadi (PPKP), yang dianggap lebih aman daripada kata sandi dan memungkinkan otomatisasi tugas dari satu hingga ribuan host jarak jauh tanpa intervensi dari administrator.
Ansible mengirimkan perintah ke host jarak jauh melalui SSH dan menggunakan hasilnya untuk menentukan keberhasilan perintah. Itu juga dapat menggunakan hasil tersebut untuk menentukan tindakan selanjutnya menggunakan kondisi kapan pernyataan.
Mendefinisikan persyaratan
Sama seperti program apa pun, baik yang ditulis dalam C, Python, Bash, atau bahasa lainnya, saya selalu memulai dengan serangkaian persyaratan. Anda telah membaca buku saya, Filosofi Linux untuk SysAdmins, bukan? Ini juga berlaku untuk alat seperti Ansible. Saya perlu menentukan ke mana saya akan pergi sehingga saya dapat mengidentifikasi kapan saya telah tiba.
Ini adalah persyaratan untuk buku pedoman Ansible saya:
Mainkan 1:Pengontrol yang memungkinkan
- Pertama, instal pembaruan pada node kontrol Ansible.
- Perbarui basis data halaman manual.
- Matikan jika perlu. Ini berbeda untuk node kontrol saya daripada untuk host lain karena motherboard aneh yang tidak melakukan reboot dengan benar.
- Masuk setelah reboot dan jalankan kembali buku pedoman. Karena node kontrol sudah dalam keadaan yang diinginkan, tidak ada tindakan lebih lanjut yang akan diambil, dan Play 2 akan dimulai.
Mainkan 2:Server
- Instal pembaruan pada firewall dan server secara berurutan, yaitu, satu per satu.
- Perbarui basis data halaman manual.
- Mulai ulang jika perlu.
- Tunggu host pertama melakukan boot ulang, jika perlu, sebelum memulai yang berikutnya.
Mainkan 3:Stasiun Kerja
- Jangan mulai memperbarui stasiun kerja sampai server selesai.
- Instal pembaruan di setiap komputer yang berjalan secara paralel secara bersamaan.
- Perbarui basis data halaman manual.
- Mulai ulang jika perlu.
Ya, saya tahu bahwa ada cara lain untuk melakukan ini. Saya memang berpikir untuk melakukan pengontrol Ansible terakhir sehingga saya tidak perlu berurusan dengan memulai ulang playbook setelah pengontrol melakukan boot ulang. Tetapi cara saya melakukan sesuatu adalah melakukan pembaruan pada workstation utama saya terlebih dahulu — yang juga merupakan node kontrol Ansible saya — dan kemudian melakukan beberapa pengujian sebelum memperbarui sistem lainnya, jadi strategi ini berfungsi dengan baik untuk itu. Kebutuhan Anda mungkin akan berbeda dari kebutuhan saya, jadi Anda harus menggunakan metode apa pun yang paling sesuai untuk Anda. Hal tentang Ansible adalah cukup fleksibel untuk mengakomodasi kebutuhan yang berbeda.
Sekarang setelah saya memiliki persyaratan untuk suatu tugas, saya dapat memulai buku pedoman.
Sintaks
Playbook yang memungkinkan harus sesuai dengan sintaks dan format YAML standar. Kesalahan yang paling sering saya temui adalah kesalahan pemformatan saya sendiri. Ini biasanya karena saya telah menggunakan atau tidak menggunakan tanda hubung awal sebagaimana diperlukan, atau saya telah menggunakan lekukan yang salah.
Nama drama dimulai di kolom satu buku pedoman, dan setiap tugas berikut diberi indentasi tepat dua spasi . Tepat dua spasi menjorok setiap tindakan dalam tugas, dan sub-tugas selanjutnya diindentasi dengan tepat dua spasi. Jumlah spasi lainnya atau penggunaan spasi selain spasi, seperti tab, akan menghasilkan kesalahan runtime. Spasi putih ekstra di akhir baris juga menghasilkan kesalahan.
Anda akan membuat kesalahan pemformatan dan dengan cepat akan belajar melihat masalahnya. Ada beberapa alat yang dapat saya gunakan untuk membantu kami menemukan kesalahan ini sebelum mencoba menjalankan buku pedoman, dan alat ini dapat menghemat banyak waktu dalam jangka panjang.
Memulai buku pedoman
Jadi mari kita mulai buku pedoman yang akan melakukan tugas-tugas itu dalam urutan yang diperlukan. Playbook hanyalah kumpulan tugas yang menentukan keadaan host yang diinginkan. Nama host atau grup inventaris ditentukan di awal buku pedoman dan menentukan host tempat Ansible akan menjalankan buku pedoman.
Buku pedoman kami akan berisi tiga permainan untuk menangani setiap jenis host yang saya identifikasi dalam pernyataan persyaratan. Setiap permainan akan memiliki logika yang sedikit berbeda tetapi akan menghasilkan hasil yang sama—satu atau lebih host dengan semua pembaruan terpasang.
Buku pedoman saya bernama doUpdates.yml dan terletak di /root/ansible/Updates direktori, yang saya buat untuk proyek ini. Program Bash yang diinstal oleh drama dalam buku pedoman ini terletak di /root/ansible/Updates/files direktori.
Mari jelajahi buku pedoman ini satu per satu.
Mendefinisikan ini sebagai file YAML
Saya memulai semua kode saya dengan komentar yang terstruktur dengan baik sehingga nama file dan deskripsi singkat dari buku pedoman ini ada untuk saya sendiri atau sysadmin lain di masa mendatang. Playbook dapat berisi komentar, meskipun saya telah melihat beberapa artikel atau buku yang menyebutkan hal ini.
Sebagai Sysadmin yang percaya dalam mendokumentasikan segala sesuatu, saya menemukan bahwa komentar bisa sangat membantu. Ini bukan tentang mengatakan hal yang sama di komentar seperti yang saya lakukan di nama tugas, tetapi sebaliknya, ini tentang mengidentifikasi tujuan kelompok tugas dan memastikan bahwa saya mencatat alasan saya untuk melakukan hal-hal tertentu dengan cara tertentu atau memesan. Ini dapat membantu dengan masalah debugging di kemudian hari ketika saya mungkin lupa pemikiran awal saya. Seperti di Bash, komentar dimulai dengan # .
Fungsi utama dari bagian pertama ini adalah tiga tanda hubung (--- ) yang digunakan untuk mendefinisikan ini sebagai file YAML. yml ekstensi pada nama file adalah singkatan dari YAML. Saya telah melihat beberapa arti untuk itu, tetapi taruhan saya adalah pada "Yet Another Markup Language", terlepas dari kenyataan bahwa saya telah melihat beberapa klaim bahwa YAML bukan salah satunya.
########################################################################
# doUpdates.yml
#------------------------------------------------------------------
# This playbook installs all available RPM updates on the inventory hosts.
#
#
#------------------------------------------------------------------
#
# Change History
# Date Name Version Description
# 2020/10/01 David Both 00.00 Started new code
# 2020/10/10 David Both 01.00 First release code finished
# 2020/10/18 David Both 01.01 Minor changes to sequence and
# fix a couple minor problems.
#
########################################################################
--- Permainan pertama
Bagian berikut ini mendefinisikan permainan pertama dalam buku pedoman. Playbook dapat memiliki satu atau beberapa pemutaran, dan Playbook kami memiliki tiga:Satu untuk host kontrol tempat Ansible dijalankan, satu untuk dua server di jaringan saya, dan satu untuk workstation lainnya. Selanjutnya, saya mendefinisikan drama pertama—bagaimanapun juga, ini adalah buku pedoman.
Perhatikan bahwa permainan dimulai di kolom nol, dan kemudian ada lekukan ketat dari garis yang tersisa dalam permainan. Tidak ada pernyataan yang mendefinisikan awal permainan. Ansible menggunakan struktur YAML yang kaku untuk menentukan di mana setiap permainan dan tugas dimulai.
########################################################################
#######################################################################
# Play 1 - Do updates for host david
########################################################################
########################################################################
- name: Play 1 - Install updates on david - the Ansible controler
hosts: david
remote_user: root
vars:
run: false
reboot: false Kami akan sering menemukan berbagai kata kunci, jadi inilah beberapa penjelasan yang saya harap saya miliki ketika saya mulai bekerja dengan Ansible.
nama :Baris ini adalah nama pemutaran, dan nama pemutaran ditampilkan di aliran data STDOUT. Ini memudahkan untuk mengidentifikasi setiap pemutaran yang berjalan untuk melacak saat saya menonton atau melihat aliran yang dialihkan nanti. Kata kunci diperlukan untuk setiap permainan dan tugas, tetapi konten teks bersifat opsional.
host :Ini mendefinisikan nama host tempat permainan akan dijalankan. Itu dapat berisi daftar nama host yang dipisahkan spasi atau nama sekelompok host. Grup host dan nama semua host yang terdaftar harus muncul di file inventaris. Secara default, yaitu /etc/ansible/hosts tetapi dapat berupa file lain selama Anda menggunakan -i (--inventory ) opsi untuk menentukan file alternatif.
pengguna_jarak jauh :Baris ini bukan persyaratan, tetapi menentukan pengguna bahwa Ansible akan bertindak sebagai host jarak jauh. Jika pengguna di host jarak jauh sama dengan pengguna di host lokal, baris ini tidak diperlukan. Secara default, Ansible menggunakan ID pengguna yang sama pada host jarak jauh sebagai pengguna yang menjalankan buku pedoman Ansible. Saya menggunakannya di sini hanya untuk tujuan informasi. Saya menjalankan sebagian besar buku pedoman sebagai root di localhost, jadi Ansible masuk ke host jarak jauh sebagai root.
var :Bagian ini dapat digunakan untuk mendefinisikan satu atau lebih variabel, yang dapat digunakan seperti dalam bahasa pemrograman apa pun. Dalam hal ini, saya menggunakannya dalam pernyataan "kapan" bersyarat nanti di buku pedoman untuk mengontrol jalur eksekusi.
Ruang lingkup variabel terbatas pada bagian di mana mereka didefinisikan. Dalam hal ini, mereka didefinisikan dalam Play 1, jadi mereka terbatas pada permainan itu. Jika saya ingin menggunakannya di drama selanjutnya, saya perlu mengaturnya lagi di setiap permainan di mana mereka diperlukan. Jika variabel disetel dalam tugas, maka variabel tersebut hanya tersedia di dalam tugas itu dan tidak di sisa permainan itu.
Nilai variabel dapat diganti pada baris perintah dengan menggunakan -e (--extra_variables ) opsi untuk menentukan nilai yang berbeda. Kita akan melihatnya ketika saatnya menjalankan buku pedoman.
Tugas
Ini adalah awal dari bagian tugas untuk Play 1. tugas :kata kunci diindentasi dengan tepat dua spasi. Setiap tugas harus memiliki nama pernyataan, bahkan jika tidak ada teks untuk namanya. Teks memudahkan untuk mengikuti logika buku pedoman dan ditampilkan di layar selama eksekusi untuk membantu saya mengikuti kemajuan secara realtime.
tasks:
########################################################################
# Do some preliminary checking
########################################################################
- name: Install the latest version of the doUpdates script
copy:
src: /root/ansible/Updates/files/doUpdates
dest: /usr/local/bin
mode: 0774
owner: root
group: root
- name: Check for currently available updates
command: doUpdates -c
register: check
- debug: var=check.stdout_lines Bagian pertama ini berisi tiga tugas. Tugas pertama menyalin program Bash yang saya tulis ke host target. Yang kedua menjalankan program yang baru saja diinstal dan menetapkan—mendaftarkan—aliran data STDOUT dari doUpdates program ke variabel "periksa." Tugas ketiga mencetak semua baris STDOUT dalam variabel cek ke layar.
Mari kita lihat kata kunci baru lebih detail:
salin :Kata kunci salin mendefinisikan awal bait yang dapat menyalin satu atau lebih file dari lokasi sumber tertentu (src ) ke lokasi target yang ditentukan (tujuan ). Kata kunci di bagian ini mendefinisikan berbagai aspek operasi penyalinan dan status akhir file yang disalin.
src :Ini adalah jalur dan nama file yang sepenuhnya memenuhi syarat untuk disalin. Dalam hal ini, saya hanya akan menyalin satu file, tetapi mudah untuk menyalin semua file dalam direktori atau hanya yang cocok dengan pola gumpalan file. File sumber biasanya disimpan di lokasi di pohon direktori hub Ansible. Dalam hal ini, jalur yang sepenuhnya memenuhi syarat ke file sumber saya terletak di /root/ansible/Updates/files/doUpdates .
tujuan :Ini adalah jalur tujuan pada host target tempat file sumber akan disalin.
modus :Kata kunci mode mendefinisikan mode file yang akan diterapkan ke file yang disalin. Terlepas dari mode file dari file sumber, Ansible akan mengatur mode file ke yang ditentukan dalam pernyataan ini. Misalnya, rwxr_xr__ atau 0754 . Pastikan untuk menggunakan keempat byte saat menggunakan format oktal.
pemilik :Ini adalah akun pemilik yang akan diterapkan ke file.
grup :Ini adalah akun grup yang akan diterapkan ke file.
perintah :Semua perintah shell Linux, skrip shell, atau program baris perintah bersama dengan opsi dan argumen dapat digunakan dengan kata kunci ini. Saya telah menggunakan program Bash yang baru saja diinstal untuk mendapatkan beberapa informasi yang tidak mudah diperoleh menggunakan built-in Ansible, seperti dnf .
daftar :Kata kunci ini menetapkan STDOUT dari perintah yang ditentukan di atas ke dalam variabel bernama "periksa." kapan: kata kunci dapat menanyakan konten variabel ini. Ini kemudian digunakan sebagai syarat untuk menentukan apakah tugas yang menjadi bagiannya akan dilakukan. Kita akan melihat ini di bagian selanjutnya.
men-debug :Mencetak konten variabel yang ditentukan ke layar. Saya sering menggunakan ini sebagai alat debug. Saya menemukan ini membantu dalam debugging. Petunjuk, petunjuk.
Sekarang sedikit tentang doUpdates saya Program bash.
Saya awalnya menulis program Bash ini untuk benar-benar melakukan pembaruan yang sekarang saya mulai lakukan dengan Ansible. Ini berisi beberapa kode yang menentukan apakah pembaruan tersedia. Ini juga menentukan apakah kernel, systemd, atau glibc telah diperbarui, salah satunya harus memerlukan boot ulang agar berfungsi penuh. Program saya memancarkan beberapa baris ke STDOUT yang dapat saya gunakan di Ansible sebagai syarat untuk memutuskan apakah akan me-reboot host target. Saya menggunakannya di bagian selanjutnya ini, yang melakukan pembaruan aktual, dan yang berikut ini mematikan untuk workstation utama saya. Kode serupa melakukan reboot pada semua host lain, seperti yang akan Anda lihat.
STDOUT dari program ini digunakan dengan -c opsi terlihat seperti ini ketika pembaruan tersedia, tetapi reboot tidak diperlukan. Saya dapat menggunakan ekspresi reguler untuk menelusuri teks mana pun dalam aliran data ini untuk string kunci, yang dapat digunakan dalam kapan :kondisional untuk menentukan apakah tugas tertentu dilakukan.
TASK [debug] ******************************************************************************************************************************************
ok: [wally1] => {
"check.stdout_lines": [
"########## 48 updates ARE available for host wally1.both.org. ##########",
"########## Including: ##########",
"Last metadata expiration check: 1:47:12 ago on Tue 20 Oct 2020 01:50:07 PM EDT.",
"Updates Information Summary: available",
" 3 Security notice(s)",
" 2 Moderate Security notice(s)",
" 3 Bugfix notice(s)",
" 2 Enhancement notice(s)",
" 2 other notice(s)",
"########## A reboot will NOT be required after these updates are installed. ##########",
"Program terminated normally"
]
}
Bagian berikutnya tepat di atas ini melakukan pembaruan aktual jika semua persyaratan di kapan :pernyataan benar. Bagian ini menggunakan dnf bawaan Ansible pengelola paket.
########################################################################
# Do the updates.
########################################################################
# Install all available updates
- name: Install all current updates
dnf:
name: "*"
state: latest
when: (check.stdout | regex_search('updates ARE available')) and run == "true"
dnf :Memanggil Ansible built-in yang berinteraksi dengan manajer paket DNF. Meskipun kemampuannya agak terbatas, ia dapat menginstal, menghapus, dan memperbarui paket. Salah satu keterbatasan modul DNF adalah tidak memiliki check-update fungsi. Oleh karena itu, saya terus menggunakan program Bash saya untuk menemukan daftar paket yang akan diperbarui dan dari situ menentukan apakah reboot (atau matikan) perlu dilakukan. Ansible juga memiliki built-in YUM dan APT.
nama :Memberikan nama paket yang akan dioperasikan. Dalam hal ini, karakter glob file * menunjukkan semua paket yang diinstal.
negara bagian :Nilai "terbaru" untuk kata kunci ini menunjukkan bahwa semua paket yang diinstal harus dibawa ke versi terbaru. Beberapa opsi status lainnya adalah "hadir", yang berarti bahwa paket telah diinstal tetapi belum tentu versi terbaru, dan "absen", yang berarti menghapus paket jika telah diinstal.
kapan :Frasa kondisional ini menentukan kondisi yang harus dipenuhi agar tugas ini dapat dijalankan. Dalam contoh ini, pembaruan hanya akan diinstal ketika string teks yang didefinisikan dalam ekspresi reguler ada di variabel "check" yang sebelumnya terdaftar, dan variabel "run" disetel ke "true".
Sekarang setelah pembaruan selesai, saya mungkin perlu mem-boot ulang, jadi mari kita lihat bagaimana saya bisa mengatasinya. Tugas berikutnya melakukannya untuk kita.
Pertama, saya memiliki sedikit dokumentasi melalui komentar, yang menjelaskan bahwa saya telah mematikan daripada me-reboot untuk host ini karena potensi masalah perangkat keras. Ini adalah contoh sempurna mengapa kami harus menyertakan komentar dalam kode dan buku pedoman kami karena mereka menjelaskan mengapa permainan khusus ini diperlukan dan mengapa itu berbeda dari yang lain. Ini juga merupakan contoh yang bagus tentang bagaimana saya dapat memperlakukan satu tuan rumah secara berbeda dari yang lain.
########################################################################
# Now poweroff host david because of MB problems that won't let it
# do a reboot without manual intervention. Need to see if I
# can figure out this problem and fix it but it is a hardware issue
# and this is just a temporary circumvention.
########################################################################
- name: Poweroff this host if necessary and reboot extra variable is true
command: poweroff
when: (check.stdout | regex_search('reboot will be required')) and reboot == "true" and run == "true"
Dalam tugas ini, saya mengirim poweroff perintah alih-alih tindakan yang disukai untuk me-reboot komputer. Saya melakukan ini untuk alasan yang dinyatakan dalam komentar:Karena motherboard pada workstation utama saya — yang juga merupakan hub Ansible saya — tidak melakukan boot ulang dengan benar. Ini mungkin karena kesalahan konfigurasi di pihak saya daripada jenis kerusakan apa pun. Saya belum menemukan alasannya karena saya menemukan waktu yang telah saya habiskan untuk mencari dan membuat perubahan konfigurasi BIOS telah melampaui batas toleransi saya, dan saya harus menyelesaikan pekerjaan. Sering kali, saya mengerjakannya sedikit lebih banyak, tetapi itu tidak lagi sepadan dengan waktu ekstra.
Eksekusi buku pedoman berhenti setelah matikan (atau reboot jika perangkat hub Ansible Anda reboot dengan benar) sehingga saya perlu memulai ulang setelah akhirnya bangun dan berjalan kembali. Kali ini, karena pembaruan telah diinstal, matikan atau reboot tidak terjadi, dan pemutaran berikutnya dijalankan.
Dan ini mengakhiri drama pertama.
[ Butuh lebih banyak tentang Ansible? Ikuti kursus tinjauan teknis gratis dari Red Hat. Ansible Essentials:Kesederhanaan dalam Tinjauan Teknis Otomasi. ]
Menutup
Kami membahas banyak informasi di sini dan saya harap penjelasan yang solid tentang kata kunci dan tugas dapat membantu. Juga jelas apa pendapat saya tentang komentar:Mereka kritis. Play 1 membuat playbook Ansible kami bergulir.
Di bagian kedua artikel ini, kami akan menyimpulkan buku pedoman dengan dua permainan tambahan untuk mengelola firewall dan server, dan kemudian host lainnya di jaringan. Saya juga akan memberikan beberapa detail dan konsep tindak lanjut.