GNU/Linux >> Belajar Linux >  >> Linux

6 keterampilan pemecahan masalah untuk buku pedoman Ansible

Ansible adalah alat yang sangat kuat yang memungkinkan Anda untuk mengotomatisasi berbagai macam platform di seluruh server, awan, jaringan, wadah, dan banyak lagi.

Seringkali Anda dapat mengotomatiskan apa yang Anda inginkan hanya dengan menggunakan kembali peran dan koleksi yang ada.

Dan ada banyak modul yang dapat dipilih yang dapat Anda gunakan di playbook Anda.

Tetapi ketika Anda mulai mengembangkan dan menguji buku pedoman yang lebih kompleks, pada akhirnya Anda akan memerlukan beberapa metode pemecahan masalah. Hal-hal seperti:

  • Memeriksa alur tugas Ansible.
  • Mengonfirmasi tipe data variabel Anda.
  • Bahkan berhenti sejenak untuk memeriksa nilainya.

Beberapa tips yang dibahas dalam artikel ini hanya akan berlaku untuk Ansible execution melalui command line. Yang lain juga valid saat berlari dari Ansible Tower.

1. Lingkungan dan parameter Anda yang memungkinkan

Jika Anda perlu menyelidiki mengapa sesuatu tidak berperilaku seperti yang diharapkan dalam buku pedoman Anda, biasanya baik untuk memulai dengan memeriksa lingkungan Ansible Anda.

Versi dan jalur binari Ansible dan Python mana yang Anda jalankan?

Jika Anda menambahkan paket OS atau modul Python yang diperlukan oleh buku pedoman Anda, apakah juru bahasa Ansible "melihatnya"?

Anda dapat memperoleh informasi dasar ini dengan berbagai cara. Dari baris perintah, jalankan ansible --version perintah.

❯ ansible --version

ansible 2.9.10

  config file = /etc/ansible/ansible.cfg

  configured module search path = ['/home/admin/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']

  ansible python module location = /usr/lib/python3.6/site-packages/ansible

  executable location = /usr/bin/ansible

  python version = 3.6.8 (default, Mar 18 2021, 08:58:41) [GCC 8.4.1 20200928 (Red Hat 8.4.1-1)]

Anda bisa mendapatkan info yang sama dengan menjalankan perintah Ansible lainnya seperti ansible-playbook atau ansible-config dengan --version pilihan.

Di Menara Ansible, informasi ini ditampilkan jika templat pekerjaan dijalankan dengan VERBOSITY 2 (Lebih bertele-tele) atau lebih tinggi.

Selain versi dan lokasi binari Ansible dan Python, selalu baik untuk memeriksa ulang jalur yang digunakan untuk modul, termasuk apakah eksekusi menggunakan ansible.cfg file yang bukan default (yaitu, bukan /etc/ansible/ansible.cfg ).

Untuk menyelidiki opsi yang berasal dari ansible.cfg khusus file, Anda dapat menjalankan yang berikut dari baris perintah:

❯ ansible-config dump --only-changed

DEFAULT_BECOME(/home/admin/ansible/ansible.cfg) = True

DEFAULT_BECOME_USER(/home/admin/ansible/ansible.cfg) = root

DEFAULT_FORKS(/home/admin/ansible/ansible.cfg) = 10

DEFAULT_HOST_LIST(/home/admin/ansible/ansible.cfg) = ['/home/admin/ansible/inventory']

DEFAULT_ROLES_PATH(/home/admin/ansible/ansible.cfg) = ['/home/admin/ansible/roles']

HOST_KEY_CHECKING(/home/admin/ansible/ansible.cfg) = False

Sesuai dengan namanya, ini akan mencantumkan parameter yang berbeda dari yang default.

2. Berjalan dalam mode verbose

Menjalankan playbook dalam mode debug dapat menjadi langkah berikutnya untuk mendapatkan detail selengkapnya tentang apa yang terjadi dalam tugas dan variabel.

Dari baris perintah, Anda dapat menambahkan -v (atau -vv , -vvv , -vvvv , -vvvvv ). Tingkat verbositas tertinggi terkadang bisa menjadi terlalu banyak informasi, jadi lebih baik untuk meningkatkan secara bertahap dalam beberapa eksekusi sampai Anda mendapatkan apa yang Anda butuhkan.

Level 4 dapat membantu saat memecahkan masalah konektivitas dan level 5 berguna untuk masalah WinRM.

Dari Menara, Anda dapat memilih VERBOSITAS tingkat dari definisi template pekerjaan.

Catatan :Ingatlah untuk menonaktifkan mode debug setelah Anda menyelesaikan situasi karena informasi mendetail hanya berguna untuk pemecahan masalah.

Juga, dalam mode debug, nilai variabel tertentu (kata sandi, misalnya) akan ditampilkan kecuali Anda menggunakan no_log opsi dalam tugas, jadi hapus output setelah Anda selesai.

3. Menggunakan debug untuk menampilkan variabel

Jika Anda memiliki ide bagus tentang di mana masalahnya mungkin, Anda dapat menggunakan pendekatan yang lebih bedah:Tampilkan hanya variabel yang perlu Anda lihat.

(...)

  - name: Display the value of the counter
     debug:
      msg: "Counter={{ counter }} / Data type={{ counter | type_debug }}"

(...)

TASK [Display the value of the counter] ****************************************************************************

ok: [node1] => {

    "msg": "Counter=42 / Data type=AnsibleUnicode"

}

Ini itulah sebabnya saya tidak bisa menambah penghitung. Filter type_debug menunjukkan bahwa tipe datanya adalah teks dan bukan int seperti yang saya duga.

[ Anda mungkin juga menyukai: Panduan memulai cepat untuk Ansible untuk sysadmin Linux ]

4. Memastikan bahwa vars memiliki konten dan tipe data yang tepat

Anda dapat menggunakan menegaskan modul untuk mengonfirmasi bahwa variabel memiliki konten/tipe yang diharapkan dan menyebabkan tugas gagal jika ada yang salah.

Buku pedoman berikut mengilustrasikan hal ini:

---

- name: Assert examples
  hosts: node1
  gather_facts: no
  vars:
    var01: 13
  tasks:

  - debug:
      msg: "Parameter 01 is {{ (param01 | type_debug) }}"

  - name: Make sure that we have the right type of content before proceeding
    assert:
      that: 

      - "var01 is defined"
      - "(var01 | type_debug) == 'int' "
      - "param01 is defined "
      - "(param01 | type_debug) == 'int' "

Jika saya menjalankan buku pedoman dari baris perintah, tanpa menyediakan extra-vars:

❯ ansible-playbook xassert.yml

PLAY [Assert examples] ****************************************************************************

TASK [debug] ****************************************************************************

ok: [node1] => {

    "msg": "Parameter 01 is AnsibleUndefined"

}

TASK [Make sure that we have the right type of content before proceeding] ****************************************************************************

fatal: [node1]: FAILED! => {

    "assertion": "param01 is defined ",

    "changed": false,

    "evaluated_to": false,

    "msg": "Assertion failed"

}

PLAY RECAP ****************************************************************************

node1 : ok=1 changed=0 unreachable=0 failed=1 skipped=0 rescued=0 ignored=0  

Jika saya menjalankan buku pedoman dari baris perintah, dengan ekstra-var:

❯ ansible-playbook xassert.yml -e "param01=99"

PLAY [Assert examples] ****************************************************************************

TASK [debug] ****************************************************************************

ok: [node1] => {

    "msg": "Parameter 01 is str"

}

TASK [Make sure that we have the right type of content before proceeding] ****************************************************************************

fatal: [node1]: FAILED! => {

    "assertion": "(param01 | type_debug) == 'int' ",

    "changed": false,

    "evaluated_to": false,

    "msg": "Assertion failed"

}

PLAY RECAP ****************************************************************************

node1 : ok=1 changed=0 unreachable=0 failed=1 skipped=0 rescued=0 ignored=0 

Melihat tipe data yang datang sebagai str mengejutkan bagi saya, tetapi ada penjelasan dan solusi di sini.

Juga, jika Anda menjalankan buku pedoman yang sama dari Tower, baik meneruskan parameter sebagai ekstra-var atau bidang dari survei, tipe data parameter akan menjadi int .

Ya, ini bisa rumit... tetapi jika Anda tahu apa yang harus dicari, "fitur" ini tidak akan menjadi masalah bagi Anda.

5. Mendapatkan daftar fakta dan vars

Baik Anda telah mendefinisikan variabel dalam inventaris Anda (untuk host dan/atau grup) atau membuat dan menetapkan variabel tambahan selama eksekusi buku pedoman Anda, mungkin berguna pada titik tertentu untuk memeriksa nilainya.

---
- name: vars
  hosts: node1,node2
  tasks:
 
  - name: Dump vars
    copy:
      content: "{{ hostvars[inventory_hostname] | to_nice_yaml }}"
      dest: "/tmp/{{ inventory_hostname }}_vars.txt"
    delegate_to: control

  - name: Dump facts
    copy: 
      content: "{{ ansible_facts | to_nice_yaml }}"
      dest: "/tmp/{{ inventory_hostname }}_facts.txt"
    delegate_to: control

Ini akan menyimpan vars dan fakta (jika Anda mengumpulkan fakta) dalam file individual untuk Anda analisis.

Untuk eksekusi baris perintah, saya mendelegasikan tugas ke host kontrol saya (localhost) agar file disimpan secara lokal alih-alih menyimpan file di setiap node secara terpisah. Jika berlari dari Menara, Anda juga harus memilih satu server tempat menyimpan file (kecuali Anda hanya memiliki satu node target dan tidak keberatan menganalisis file di sana).

6. Menggunakan debugger tugas untuk pemecahan masalah dari baris perintah

Anda juga dapat menggunakan debugger Ansible untuk menjalankan buku pedoman dalam mode langkah demi langkah dan untuk memeriksa konten variabel dan argumen secara interaktif.

Selain itu, Anda juga dapat mengubah nilai variabel saat itu juga, dan melanjutkan eksekusi.

Debugger dapat diaktifkan pada level tugas atau level permainan, seperti pada contoh berikut:

---

- name: Example using debugger
  hosts: localhost
  gather_facts: no
  vars:
    radius: "5.3"
    pi: "3.1415926535"
  debugger: on_failed
  tasks:

  - name: Calculate the area of a circle
    debug:
      msg:
      - "Radius.............: {{ radius }}"
      - "pi................: {{ pi }}"
      - "Area of the circle: {{ (pi * (radius * radius)) }}"

Peringatan spoiler:Saya mendefinisikan variabel sebagai string, yang jelas akan menyebabkan kesalahan saat saya mencoba melakukan perhitungan.

❯ ansible-playbook xdebugger.yml 

PLAY [Example using debugger] ****************************************************************************

TASK [Calculate the area of a circle] ****************************************************************************

fatal: [localhost]: FAILED! => {"msg": "Unexpected templating type error occurred on (Area of the circle: {{ (pi * (radius * radius)) }}): can't multiply sequence by non-int of type 'AnsibleUnicode'"}

[localhost] TASK: Calculate the area of a circle (debug)> p task_vars['pi']

'3.1415926535'

[localhost] TASK: Calculate the area of a circle (debug)> p task_vars['radius']

'5.3'

[localhost] TASK: Calculate the area of a circle (debug)> task_vars['pi']=3.1415926535

[localhost] TASK: Calculate the area of a circle (debug)> task_vars['radius']=5.3

[localhost] TASK: Calculate the area of a circle (debug)> p task_vars['radius']

5.3

[localhost] TASK: Calculate the area of a circle (debug)> task_vars['pi']=3.1415926535

[localhost] TASK: Calculate the area of a circle (debug)> redo

ok: [localhost] => {

    "msg": [

        "Radius............: 5.3",

        "pi................: 3.1415926535",

        "Area of the circle: 88.247337636815"

    ]

}

PLAY RECAP ****************************************************************************

localhost : ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0  

Apa yang terjadi di sini:

  1. Awalnya, tugas gagal, mengeluh tentang variabel non-int.
  2. Debugger dipanggil.
  3. Saya menggunakan cetakan (p ) perintah untuk menampilkan nilai variabel.
  4. Dalam hal ini, saya tahu bahwa masalahnya ada pada tipe data, tetapi orang dapat menganggap nilainya benar (jika tidak memperhatikan tanda kutip di sekitar nilai).
  5. Kemudian, saya memperbarui konten variabel, memberikan nomor padanya.
  6. Lalu, saya menggunakan redo perintah untuk menjalankan kembali tugas dengan nilai baru, dan selesai dengan sukses.

Ini adalah skenario sederhana, seperti yang kita tahu bahwa tidak ada seorang pun akan benar-benar menggunakan Ansible untuk menghitung luas lingkaran. Namun dalam situasi yang lebih kompleks, akan berguna untuk menemukan konten variabel di tengah eksekusi buku pedoman yang panjang, dan dapat melanjutkan dari titik itu tanpa memulai ulang dari awal.

[ Dapatkan ebook gratis ini:Mengelola kluster Kubernetes Anda untuk boneka. ]

Menutup

Memasukkan gudang opsi pemecahan masalah yang baik dapat membantu Anda mengidentifikasi masalah dalam buku pedoman Ansible Anda dengan lebih cepat. Tergantung di mana Anda berada dalam penyelidikan, metode tertentu lebih cocok.

Misalnya, saat Anda hanya mencoba memahami apa bisa salah, dan di mana , Anda mungkin ingin memulai dengan meningkatkan level debug secara bertahap.

Setelah Anda memiliki gagasan yang lebih baik tentang lokasi masalah, mungkin lebih mudah untuk mengurangi tingkat debug (sehingga Anda memiliki lebih sedikit output di depan Anda) dan menggunakan opsi yang khusus untuk tugas yang Anda analisis.

Pemecahan Masalah Ansible bisa jadi rumit tetapi menggunakan pendekatan metodis yang dikombinasikan dengan alat pemecahan masalah bawaan, Anda dapat membuatnya jauh lebih mudah bagi diri Anda sendiri. Konfirmasikan lingkungan Ansible dan alur tugas, lalu cari tipe data yang tepat, dan terakhir pertimbangkan untuk menjeda dan menelusuri setiap tugas.


Linux

  1. Pengantar singkat tentang peran Ansible untuk administrasi sistem Linux

  2. Contoh penggunaan perintah tcpdump untuk pemecahan masalah jaringan

  3. Bagaimana cara menunggu server restart menggunakan Ansible?

  1. Bagaimana saya menggunakan Ansible dan anacron untuk otomatisasi

  2. 10 Modul yang memungkinkan untuk otomatisasi sistem Linux

  3. Perlu mengetahui teknologi untuk sysadmin junior

  1. Memahami YAML untuk Ansible

  2. Menangani rahasia di buku pedoman Ansible Anda

  3. Menggunakan alat SS untuk pemecahan masalah jaringan