Tanya mana-mana sysadmin bagaimana hari Selasa mereka dan anda akan mendengar cerita yang sama: SSH ke pelayan satu, jalankan enam arahan, SSH ke pelayan dua, ulang, ulang, ulang. Ia berfungsi — sehingga anda terlupa arahan keenam pada pelayan empat, atau rakan sekerja membuat "perubahan kecil" yang hanya mendarat pada separuh armada. Inilah sebenarnya masalah yang dibina untuk diselesaikan oleh Ansible. Ia bukan alat lain untuk belajar demi itu; ia adalah alat yang menukar "konfigurasikan 20 pelayan" dari satu petang penuh salin-tampal kepada satu arahan yang berjalan secara sama di mana-mana.

Dalam panduan ini, kami akan membincangkan perkara yang menjadikan Ansible berbeza daripada alat automasi lain, cara memulakan inventori dan arahan ad-hoc, cara menulis buku main sebenar anda yang pertama dan amalan terbaik yang memisahkan automasi bersih daripada kekacauan YAML yang tidak dijejaki. Jika anda menjalankan lebih daripada segelintir pelayan Linux, ini adalah kemahiran yang membayar untuk dirinya sendiri dalam minggu pertama.

Apa yang Membuatkan Ansible Berbeza

Perkara pertama yang mengejutkan orang tentang Ansible ialah tiada ejen. Tidak seperti Puppet atau Chef, yang memerlukan anda memasang dan menyelenggara perisian pada setiap mesin terurus, Ansible menyambung melalui SSH biasa — protokol yang sama yang telah anda gunakan setiap hari. Nod kawalan (mesin yang anda jalankan dari Ansible) menolak arahan kepada hos terurus, melaksanakannya dan melaporkan kembali.

Reka bentuk tanpa agen ini membawa tiga kelebihan praktikal:

• Pemasangan sifar pada pelayan sasaran — tiada pakej untuk digunakan, tiada ejen untuk dikemas kini, tiada port untuk dibuka di luar SSH.
• Pelaksanaan berasaskan tolak — anda memutuskan bila perubahan berlaku, dan bukannya menunggu daftar masuk berjadual seterusnya ejen.
• Keperluan Python sahaja — selagi hos jauh mempunyai Python (yang hampir setiap pengedaran Linux dihantar secara lalai), anda boleh melakukannya.

Ansible juga ditulis dalam YAML, bahasa penanda yang boleh dibaca manusia, yang bermaksud automasi anda pada masa yang sama dokumentasi anda. Enam bulan dari sekarang, ahli pasukan baharu boleh membuka buku permainan dan memahami dengan tepat apa yang dilakukannya — sesuatu yang jarang boleh dikatakan tentang timbunan skrip shell.

Inventori: Senarai Pelayan Anda

Sebelum Ansible boleh menguruskan apa-apa, ia perlu mengetahui apa yang wujud. Senarai itu disimpan dalam fail inventori — biasanya dipanggil `hos` atau `inventori.ini`. Inventori paling mudah mengumpulkan pelayan mengikut fungsi:

```ini
[pelayan web]
web01.example.com
web02.example.com

[pangkalan data]
db01.example.com ansible_host=10.0.0.5

[semua:vars]
ansible_user=deploy
ansiblesshprivatekeyfile=~/.ssh/id_ed25519
```

Kumpulan menjadikan hidup lebih mudah secara mendadak. Daripada menjalankan tugas terhadap "setiap pelayan yang saya ada", anda menyasarkan kumpulan `pelayan web` dan biarkan Ansible mengendalikan yang lain. Anda juga boleh menggunakan inventori dinamik yang menarik senarai hos daripada AWS, DigitalOcean atau CMDB anda sendiri — naik taraf kemudian, tetapi patut mengetahui corak itu wujud.

Perintah Ad-Hoc: Menang Pantas Sebelum Playbooks

Anda tidak memerlukan buku main penuh untuk mendapatkan nilai pada hari pertama. Perintah ad-hoc membolehkan anda menjalankan satu tugas merentasi banyak hos dengan satu baris:

```bash

Semak ruang cakera pada setiap pelayan web

pelayan web ansible -m shell -a "df -h | head -5"

Pastikan ntp dipasang di mana-mana

ansible all -m apt -a "nama=ntp state=present" -b

Mulakan semula perkhidmatan pada hos tertentu

ansible db01 -m service -a "name=postgresql state=restarted" ```

Coraknya mudah: `boleh -m -a ""`. Bendera `-b` bermaksud menjadi — Ansible akan meningkatkan keistimewaan menggunakan sudo, seperti yang anda lakukan secara manual. Ini sesuai untuk kerja "sekali sahaja" yang sebaliknya bermakna log masuk ke lima kotak dan berharap anda mengingati bendera yang sama pada setiap satu.

Buku Main Pertama Anda

Perintah ad-hoc bagus untuk tugasan tunggal, tetapi automasi sebenar hidup dalam buku main. Buku main ialah fail YAML yang menerangkan keadaan yang diingini dan menjalankannya semudah:

```bash
ansible-playbook setup-nginx.yml
```

Berikut ialah buku main pertama yang realistik yang memasang dan mengkonfigurasi Nginx pada sekumpulan pelayan web:

```yaml

---

• nama: Konfigurasikan pelayan web

hos: pelayan web
menjadi: ya

tugasan:
- nama: Pasang Nginx
sesuai:
nama: nginx
negeri: sekarang
kemas kini_cache: ya

- nama: Salin konfigurasi tapak
salinan:
src: files/default.conf
dest: /etc/nginx/sites-available/default
maklumkan: muat semula nginx

- nama: Pastikan Nginx sedang berjalan
perkhidmatan:
nama: nginx
negeri: bermula
didayakan: ya

pengendali:
- nama: muat semula nginx
perkhidmatan:
nama: nginx
negeri: dimuat semula
```

Baca dari atas ke bawah dan ia berbunyi seperti resipi: pasang pakej, salin konfigurasi, pastikan perkhidmatan berjalan. Baris `notify: reload nginx` ialah permata kecil — pengendali hanya menyala jika fail konfigurasi benar-benar berubah. Tiada tambah nilai perkhidmatan yang tidak perlu, tiada makluman, tiada masa henti.

Idempotensi: Kuasa Besar Yang Menjadikannya Selamat

Berikut ialah konsep yang mengubah cara anda berfikir tentang pengurusan pelayan: idempotensi. Tugas idempoten menghasilkan keadaan akhir yang sama tidak kira berapa kali anda menjalankannya. Jalankan buku main di atas sekali, atau jalankannya lima puluh kali — hasilnya adalah sama: Nginx dipasang, dikonfigurasikan dan berjalan.

Bezakan dengan skrip shell tulisan tangan:

```bash
apt pasang nginx -y
cp default.conf /etc/nginx/sites-available/default
systemctl mulakan semula nginx
```

Larian pertama berfungsi. Larian kedua juga berfungsi, tetapi ia memulakan semula Nginx tanpa perlu - dan jika rakan sekerja mengedit fail konfigurasi itu dengan tangan, skrip anda akan menimpa kerja mereka secara senyap. Modul ansible dibina untuk menyemak keadaan semasa dahulu: modul `apt` hanya dipasang apabila pakej tiada, modul `copy` hanya melaporkan perubahan apabila fail berbeza dan `service` hanya bertindak apabila keadaan tidak sepadan. Ini bermakna automasi menjadi sesuatu yang anda boleh jalankan dengan yakin pada tengah hari, bukan hanya semasa tetingkap penyelenggaraan yang dirancang dengan teliti.

Anda juga boleh melihat impak dengan larian kering:

```bash
ansible-playbook setup-nginx.yml --check
```

Bendera `--check` berjalan melalui setiap tugas dan melaporkan perkara yang akan berubah — tanpa mengubah apa-apa. Digabungkan dengan `--diff`, ia menunjukkan kepada anda perbezaan fail konfigurasi yang tepat. Ini adalah perkara paling dekat yang sysadmin ada dengan mesin masa, dan ia percuma.

Menganjur dengan Peranan

Apabila buku main anda melepasi beberapa tugasan, fail rata menjadi tidak boleh dibaca. Di situlah peranan masuk. Peranan ialah direktori serba lengkap dengan struktur standard:

```
peranan/
└── nginx/
├── tasks/main.yml # perkara yang perlu dilakukan
├── pengendali/main.yml # tindakan untuk dicetuskan
├── templat/ # Templat Jinja2 untuk konfigurasi
├── fail/ # fail statik untuk disalin
└── vars/main.yml # pembolehubah khusus peranan
```

Buku permainan anda kemudiannya mengecut hampir tiada:

```yaml

---

• nama: Gunakan peranan pada pelayan web

hos: pelayan web
menjadi: ya
peranan:
- biasa
- nginx
- tembok api
```

Peranan adalah blok binaan yang boleh diguna semula. Bina peranan `common` sekali (pengguna, penyegerakan masa, fail2ban, pengerasan asas) dan setiap pelayan yang anda sediakan mewarisinya. Reka letak direktori juga memberi anda tempat semula jadi untuk menyimpan templat — contohnya, hos maya Nginx dengan pembolehubah untuk nama domain:

```jinja2
pelayan {
dengar 80;
namapelayan {{ namadomain }};
root /var/www/{{ domain_name }}/public;
}
```

Pembolehubah daripada inventori, buku main atau fail `vars` peranan digabungkan bersama dengan bersih, dan peraturan keutamaan Ansible didokumenkan dengan baik — bermula dengan mudah dan hanya mencapai lapisan lanjutan apabila anda benar-benar memerlukannya.

Melindungi Rahsia dengan ansible-vault

Automasi tidak berguna jika ia membocorkan kelayakan. Jika buku main anda memerlukan kata laluan pangkalan data, kunci API atau kunci peribadi SSH, jangan sekali-kali menyimpannya dalam teks biasa. Kapal yang boleh dipercayai dengan peti besi terbina dalam yang menyulitkan rahsia dengan AES-256:

```bash

Buat fail yang disulitkan

ansible-vault mencipta rahsia.yml

Edit dengan selamat kemudian

ansible-vault edit secrets.yml ```

Buku permainan anda kemudiannya boleh merujuk fail yang disulitkan dan Ansible menggesa kata laluan peti besi (atau membacanya daripada fail kata laluan dalam CI) hanya apabila ia perlu menyahsulit:

```yaml

• nama: Sertakan rahsia berkubah

include_vars: secrets.yml
```

Untuk pasukan yang lebih besar, lihat `ansible-vault` digabungkan dengan `vaultpasswordfile` `ansible.cfg` atau alihkan rahsia kepada pengurus rahsia yang betul seperti HashiCorp Vault. Peraturannya mudah: jika sesuatu nilai itu sensitif, ia tergolong dalam bilik kebal — dan fail bilik kebal itu sendiri berada dalam repositori peribadi, tidak sekali-kali bersebelahan dengan buku permainan awam anda.

Amalan Terbaik dan Perangkap

Selepas beberapa minggu penggunaan sebenar, segelintir tabiat memisahkan tetapan Ansible yang bersih daripada yang menyakitkan:

• Simpan buku main dalam Git — setiap perubahan boleh disemak, boleh diterbalikkan dan boleh diaudit. Masalah drift konfigurasi anda menjadi masalah permintaan tarik, yang merupakan masalah yang lebih baik untuk dihadapi.
• Gunakan `state: present` / `state: absent` secara eksplisit — jangan sekali-kali bergantung pada tingkah laku modul lalai; membuat keadaan yang dikehendaki jelas.
• Jalankan `--check` sebelum berjalan sebenar — terutamanya pada hos pengeluaran. Ia tidak menelan kos dan menangkap kesilapan silap dan hos yang salah.
• Sematkan versi Ansible nod kawalan — Ansible 2.9 lwn 8.x mempunyai perbezaan nyata; pastikan alatan anda boleh dihasilkan semula dengan virtualenv atau fail keperluan.
• Kumpulan sasaran, bukan hos individu — jika anda mendapati diri anda menulis `hosts: web03`, tanya sama ada `hosts: webservers` akan lebih jujur.
• Berhati-hati dengan buku main "berfungsi pada mesin saya" — ujian pada satu hos dahulu (`--hadkan web01`), kemudian keluarkan kepada kumpulan.
• Namakan setiap tugas — tugasan tanpa nama yang gagal pada 2 PG adalah teka-teki; yang bernama adalah ayat.

Perangkap yang paling biasa untuk pendatang baru ialah menganggap Ansible seperti pelari skrip shell yang lebih menarik: melontar modul `shell` dan `command` pada segala-galanya. Tolak diri anda untuk menggunakan modul yang dibina khas (`apt`, `copy`, `template`, `service`, `user`, `lineinfile`) dahulu. Mereka memberi anda idempotency dan menukar pelaporan secara percuma, dan mereka mengendalikan kes tepi yang tidak akan dilakukan oleh arahan ad-hoc anda.

Kesimpulan

Pengurusan pelayan manual tidak berskala — bukan kepada sepuluh pelayan, dan sudah tentu tidak kepada seratus. Ansible memberi anda cara untuk menyatakan infrastruktur anda sebagai kod yang jelas, boleh disemak, boleh berulang: tanpa ejen mengikut reka bentuk, idempoten melalui pembinaan dan cukup mesra sehingga YAML anda berfungsi sebagai dokumentasi. Mulakan dengan inventori dan satu buku main untuk tugasan yang paling kerap anda ulangi — memasang Nginx, menyediakan pengguna, mengeraskan SSH. Kemudian berkembang menjadi peranan, templat dan peti besi apabila automasi membuktikan dirinya.

Bahagian yang terbaik ialah anjakan minda. Daripada bertanya "apa yang saya lakukan pada pelayan itu bulan lepas?", anda bertanya "apa yang dikatakan oleh buku permainan negeri itu?" — dan itu ialah soalan dengan jawapan yang boleh anda jalankan, semak dan percayai.