Saya melakukan banyak ulasan tentang kod Ansible orang lain dan banyak menulis sendiri. Semasa menganalisis kesilapan (kesilapan orang lain dan saya sendiri), serta beberapa temu bual, saya menyedari kesilapan utama yang dilakukan oleh pengguna Ansible - mereka masuk ke dalam perkara yang rumit tanpa menguasai yang asas.

Untuk membetulkan ketidakadilan sejagat ini, saya memutuskan untuk menulis pengenalan kepada Ansible bagi mereka yang sudah mengetahuinya. Saya memberi amaran kepada anda, ini bukan penceritaan semula tentang lelaki, ini adalah bacaan panjang dengan banyak surat dan tiada gambar.

Tahap pembaca yang dijangkakan ialah beberapa ribu baris yamla telah ditulis, sesuatu sudah dalam pengeluaran, tetapi "entah bagaimana semuanya bengkok."

Nama-nama

Kesilapan utama pengguna Ansible ialah tidak mengetahui apa yang dipanggil. Jika anda tidak tahu nama, anda tidak dapat memahami apa yang dinyatakan dalam dokumentasi. Contoh hidup: semasa temu bual, seseorang yang seolah-olah mengatakan bahawa dia banyak menulis dalam Ansible tidak dapat menjawab soalan "elemen apakah yang mengandungi buku permainan?" Dan apabila saya mencadangkan bahawa "jawapan dijangkakan bahawa buku permainan itu terdiri daripada permainan," komen terkutuk "kami tidak menggunakannya" diikuti. Orang menulis Ansible untuk wang dan tidak menggunakan permainan. Mereka sebenarnya menggunakannya, tetapi tidak tahu apa itu.

Jadi mari kita mulakan dengan sesuatu yang mudah: apa namanya. Mungkin anda tahu ini, atau mungkin tidak, kerana anda tidak memberi perhatian apabila anda membaca dokumentasi.

ansible-playbook melaksanakan playbook. Buku permainan ialah fail dengan sambungan yml/yaml, di dalamnya terdapat sesuatu seperti ini:

---
- hosts: group1
  roles:
    - role1

- hosts: group2,group3
  tasks:
    - debug:

Kami telah menyedari bahawa keseluruhan fail ini adalah buku permainan. Kami boleh menunjukkan di mana peranan dan di mana tugas itu. Tetapi di manakah permainan? Dan apakah perbezaan antara permainan dan peranan atau buku permainan?

Semuanya ada dalam dokumentasi. Dan mereka merinduinya. Pemula - kerana terlalu banyak dan anda tidak akan mengingati semuanya sekaligus. Berpengalaman - kerana "perkara remeh". Jika anda berpengalaman, baca semula halaman ini sekurang-kurangnya sekali setiap enam bulan, dan kod anda akan menjadi peneraju kelas.

Jadi, ingat: Playbook ialah senarai yang terdiri daripada main dan import_playbook.
Ini adalah satu permainan:

- hosts: group1
  roles:
    - role1

dan ini juga satu lagi lakonan:

- hosts: group2,group3
  tasks:
    - debug:

Apakah permainan? Kenapa dia?

Main ialah elemen utama untuk buku permainan, kerana main dan main hanya mengaitkan senarai peranan dan/atau tugasan dengan senarai hos yang mana ia mesti dilaksanakan. Dalam kedalaman dokumentasi yang anda boleh temui sebutan delegate_to, pemalam carian tempatan, tetapan khusus cli rangkaian, hos lompat, dsb. Mereka membenarkan anda mengubah sedikit tempat di mana tugas dilakukan. Tapi, lupakanlah. Setiap pilihan pintar ini mempunyai kegunaan yang sangat khusus, dan ia pastinya tidak universal. Dan kita bercakap tentang perkara asas yang semua orang patut tahu dan gunakan.

Jika anda ingin melakukan "sesuatu" "di suatu tempat", anda menulis permainan. Bukan peranan. Bukan peranan dengan modul dan perwakilan. Anda mengambilnya dan menulis permainan. Di mana, dalam medan hos anda menyenaraikan tempat untuk dilaksanakan, dan dalam peranan/tugas - perkara yang perlu dilaksanakan.

Mudah, kan? Bagaimana mungkin sebaliknya?

Salah satu momen ciri apabila orang mempunyai keinginan untuk melakukan ini bukan melalui permainan ialah "peranan yang menetapkan segala-galanya." Saya ingin mempunyai peranan yang mengkonfigurasi kedua-dua pelayan jenis pertama dan pelayan jenis kedua.

Contoh arketipe ialah pemantauan. Saya ingin mempunyai peranan pemantauan yang akan mengkonfigurasi pemantauan. Peranan pemantauan diberikan kepada hos pemantauan (mengikut permainan). Tetapi ternyata untuk pemantauan kami perlu menghantar pakej kepada hos yang kami pantau. Mengapa tidak menggunakan perwakilan? Anda juga perlu mengkonfigurasi iptables. mewakilkan? Anda juga perlu menulis/membetulkan konfigurasi untuk DBMS untuk membolehkan pemantauan. perwakilan! Dan jika kreativiti kurang, maka anda boleh membuat delegasi include_role dalam gelung bersarang menggunakan penapis rumit pada senarai kumpulan, dan dalam include_role anda boleh melakukan lebih banyak lagi delegate_to sekali lagi. Dan pergilah kita...

Harapan yang baik - untuk mempunyai satu peranan pemantauan tunggal, yang "melakukan segala-galanya" - membawa kita ke dalam neraka yang paling kerap hanya ada satu jalan keluar: untuk menulis semula segala-galanya dari awal.

Di manakah kesilapan berlaku di sini? Sebaik sahaja anda mendapati bahawa untuk melakukan tugasan "x" pada hos X anda perlu pergi ke hos Y dan melakukan "y" di sana, anda perlu melakukan latihan mudah: pergi dan tulis main, yang mana pada hos Y melakukan y. Jangan tambah sesuatu pada "x", tetapi tulis dari awal. Walaupun dengan pembolehubah berkod keras.

Nampaknya semua dalam perenggan di atas dikatakan betul. Tetapi ini bukan kes anda! Kerana anda ingin menulis kod boleh guna semula yang DRY dan seperti perpustakaan, dan anda perlu mencari kaedah bagaimana untuk melakukannya.

Di sinilah satu lagi kesilapan serius mengintai. Ralat yang mengubah banyak projek daripada penulisan yang boleh diterima (ia mungkin lebih baik, tetapi semuanya berfungsi dan mudah untuk diselesaikan) menjadi seram lengkap yang tidak dapat diketahui oleh pengarang. Ia berfungsi, tetapi Allah melarang anda mengubah apa-apa.

Ralatnya ialah: peranan ialah fungsi perpustakaan. Analogi ini telah merosakkan begitu banyak permulaan yang baik sehingga ia hanya menyedihkan untuk ditonton. Peranan itu bukan fungsi perpustakaan. Dia tidak boleh membuat pengiraan dan dia tidak boleh membuat keputusan peringkat permainan. Ingatkan saya apakah keputusan yang dibuat oleh permainan?

Terima kasih, anda betul. Play membuat keputusan (lebih tepat lagi, ia mengandungi maklumat) tentang tugas dan peranan yang perlu dilaksanakan pada hos mana.

Jika anda mewakilkan keputusan ini kepada peranan, dan walaupun dengan pengiraan, anda menghukum diri sendiri (dan orang yang akan cuba menghuraikan kod anda) kepada kewujudan yang menyedihkan. Peranan tidak menentukan di mana ia dilakukan. Keputusan ini dibuat secara main-main. Peranan melakukan apa yang diberitahu, di mana ia diberitahu.

Mengapa berbahaya untuk memprogram dalam Ansible dan mengapa COBOL lebih baik daripada Ansible kita akan bercakap dalam bab tentang pembolehubah dan jinja. Buat masa ini, katakan satu perkara - setiap pengiraan anda meninggalkan kesan perubahan yang tidak dapat dihapuskan dalam pembolehubah global, dan anda tidak boleh berbuat apa-apa mengenainya. Sebaik sahaja dua "jejak" itu bersilang, semuanya hilang.

Nota untuk yang culas: peranan pasti boleh mempengaruhi aliran kawalan. makan delegate_to dan ia mempunyai kegunaan yang munasabah. makan meta: end host/play. Tetapi! Ingat kita ajar asas? Terlupa tentang delegate_to. Kita bercakap tentang kod Ansible yang paling mudah dan paling cantik. Yang mudah dibaca, mudah ditulis, mudah dinyahpepijat, mudah diuji dan mudah dilengkapkan. Jadi, sekali lagi:

bermain dan hanya bermain menentukan hos mana yang akan dilaksanakan.

Dalam bahagian ini, kami menangani pertentangan antara bermain dan peranan. Sekarang mari kita bercakap tentang hubungan tugas vs peranan.

Tugas dan Peranan

Pertimbangkan bermain:

- hosts: somegroup
  pre_tasks:
    - some_tasks1:
  roles:
     - role1
     - role2
  post_tasks:
     - some_task2:
     - some_task3:

Katakan anda perlu melakukan foo. Dan ia kelihatan seperti foo: name=foobar state=present. Di manakah saya harus menulis ini? dalam pra? jawatan? Buat peranan?

... Dan ke mana perginya tugasan itu?

Kami bermula dengan asas sekali lagi - peranti main. Jika anda terapung dalam isu ini, anda tidak boleh menggunakan main sebagai asas untuk semua perkara lain dan keputusan anda akan menjadi "goyah".

Peranti main: hos arahan, tetapan untuk main itu sendiri dan bahagian pra_tugas, tugasan, peranan, post_tasks. Parameter selebihnya untuk bermain tidak penting kepada kami sekarang.

Susunan bahagian mereka dengan tugas dan peranan: pre_tasks, roles, tasks, post_tasks. Oleh kerana secara semantik susunan pelaksanaan adalah antara tasks и roles tidak jelas, maka amalan terbaik mengatakan bahawa kami menambah bahagian tasks, hanya jika tidak roles... Jika ada roles, maka semua tugas yang dilampirkan diletakkan dalam bahagian pre_tasks/post_tasks.

Apa yang tinggal ialah semuanya jelas dari segi semantik: pertama pre_taskskemudian roleskemudian post_tasks.

Tetapi kami masih belum menjawab soalan: di manakah panggilan modul? foo menulis? Adakah kita perlu menulis keseluruhan peranan untuk setiap modul? Atau adakah lebih baik untuk mempunyai peranan yang tebal untuk segala-galanya? Dan jika bukan peranan, maka di mana saya harus menulis - dalam pra atau pasca?

Sekiranya tidak ada jawapan yang munasabah untuk soalan-soalan ini, maka ini adalah tanda kekurangan intuisi, iaitu, "asas goyah" yang sama. Mari kita fikirkan. Pertama, soalan keselamatan: Jika bermain ada pre_tasks и post_tasks (dan tiada tugas atau peranan), maka bolehkah sesuatu pecah jika saya melaksanakan tugas pertama daripada post_tasks Saya akan memindahkannya ke akhir pre_tasks?

Sudah tentu, perkataan soalan membayangkan bahawa ia akan pecah. Tetapi apa sebenarnya?

... Pengendali. Membaca asas mendedahkan fakta penting: semua pengendali disiram secara automatik selepas setiap bahagian. Itu. semua tugas daripada pre_tasks, kemudian semua pengendali yang dimaklumkan. Kemudian semua peranan dan semua pengendali yang dimaklumkan dalam peranan itu dilaksanakan. Selepas post_tasks dan pengendali mereka.

Oleh itu, jika anda menyeret tugasan daripada post_tasks в pre_tasks, maka berkemungkinan anda akan melaksanakannya sebelum pengendali dilaksanakan. sebagai contoh, jika dalam pre_tasks pelayan web dipasang dan dikonfigurasikan, dan post_tasks sesuatu dihantar kepadanya, kemudian pindahkan tugas ini ke bahagian pre_tasks akan membawa kepada fakta bahawa pada masa "menghantar" pelayan belum lagi berjalan dan semuanya akan rosak.

Sekarang mari kita fikirkan semula, mengapa kita perlu pre_tasks и post_tasks? Sebagai contoh, untuk menyelesaikan semua yang diperlukan (termasuk pengendali) sebelum memenuhi peranan. A post_tasks akan membolehkan kami bekerja dengan hasil pelaksanaan peranan (termasuk pengendali).

Pakar Ansible yang cerdik akan memberitahu kami apa itu. meta: flush_handlers, tetapi mengapa kita memerlukan flush_handlers jika kita boleh bergantung pada susunan pelaksanaan bahagian dalam permainan? Selain itu, penggunaan meta: flush_handlers boleh memberi kita perkara yang tidak dijangka dengan pengendali pendua, memberi kita amaran aneh apabila digunakan when у block dan lain-lain. Lebih baik anda mengetahui ansible, lebih banyak nuansa yang boleh anda namakan untuk penyelesaian yang "rumit". Dan penyelesaian mudah - menggunakan pembahagian semula jadi antara pra/peranan/pos - tidak menyebabkan nuansa.

Dan, kembali kepada 'foo' kami. Di manakah saya harus meletakkannya? Dalam pra, jawatan atau peranan? Jelas sekali, ini bergantung kepada sama ada kita memerlukan keputusan pengendali untuk foo. Jika mereka tiada, maka foo tidak perlu diletakkan sama ada dalam pra atau pasca - bahagian ini mempunyai makna istimewa - melaksanakan tugas sebelum dan selepas badan utama kod.

Kini jawapan kepada soalan "peranan atau tugas" datang kepada perkara yang sudah dimainkan - jika terdapat tugasan di sana, maka anda perlu menambahkannya pada tugasan. Jika ada peranan, anda perlu mencipta peranan (walaupun daripada satu tugasan). Biar saya ingatkan anda bahawa tugas dan peranan tidak digunakan pada masa yang sama.

Memahami asas Ansible memberikan jawapan yang munasabah kepada persoalan rasa.

Tugas dan peranan (bahagian dua)

Sekarang mari kita bincangkan situasi apabila anda baru mula menulis buku permainan. Anda perlu membuat foo, bar dan baz. Adakah tiga tugas ini, satu peranan atau tiga peranan? Untuk meringkaskan soalan: pada titik manakah anda harus mula menulis peranan? Apa gunanya menulis peranan apabila anda boleh menulis tugasan?... Apakah itu peranan?

Salah satu kesilapan terbesar (saya sudah bercakap tentang perkara ini) ialah berfikir bahawa peranan adalah seperti fungsi dalam perpustakaan program. Apakah rupa huraian fungsi generik? Ia menerima hujah input, berinteraksi dengan sebab sampingan, melakukan kesan sampingan dan mengembalikan nilai.

Sekarang, perhatian. Apa yang boleh dilakukan daripada ini dalam peranan? Anda sentiasa dialu-alukan untuk memanggil kesan sampingan, ini adalah intipati keseluruhan Ansible - untuk mencipta kesan sampingan. Mempunyai sebab sampingan? peringkat rendah. Tetapi dengan "lulus nilai dan pulangkan" - di situlah ia tidak berfungsi. Pertama, anda tidak boleh memberikan nilai kepada peranan. Anda boleh menetapkan pembolehubah global dengan saiz permainan seumur hidup dalam bahagian vars untuk peranan tersebut. Anda boleh menetapkan pembolehubah global dengan seumur hidup dalam peranan. Atau pun dengan buku permainan sepanjang hayat (set_fact/register). Tetapi anda tidak boleh mempunyai "pembolehubah tempatan". Anda tidak boleh "mengambil nilai" dan "memulangkannya".

Perkara utama berikut daripada ini: anda tidak boleh menulis sesuatu dalam Ansible tanpa menyebabkan kesan sampingan. Menukar pembolehubah global sentiasa menjadi kesan sampingan untuk sesuatu fungsi. Dalam Rust, sebagai contoh, menukar pembolehubah global ialah unsafe. Dan dalam Ansible ia adalah satu-satunya kaedah untuk mempengaruhi nilai untuk peranan. Perhatikan perkataan yang digunakan: bukan "luluskan nilai kepada peranan", tetapi "ubah nilai yang digunakan oleh peranan". Tiada pengasingan antara peranan. Tiada pengasingan antara tugas dan peranan.

Jumlah: peranan bukan fungsi.

Apa yang bagus tentang peranan itu? Pertama, peranan mempunyai nilai lalai (/default/main.yaml), kedua, peranan mempunyai direktori tambahan untuk menyimpan fail.

Apakah faedah nilai lalai? Oleh kerana dalam piramid Maslow, jadual keutamaan boleh ubah Ansible yang agak herot, lalai peranan adalah keutamaan paling rendah (tolak parameter baris arahan Ansible). Ini bermakna jika anda perlu memberikan nilai lalai dan tidak bimbang tentang nilai tersebut mengatasi nilai daripada inventori atau pembolehubah kumpulan, maka lalai peranan adalah satu-satunya tempat yang sesuai untuk anda. (Saya berbohong sedikit - ada lagi |d(your_default_here), tetapi jika kita bercakap tentang tempat pegun, maka hanya lalai peranan).

Apa lagi yang hebat tentang peranan? Kerana mereka mempunyai katalog sendiri. Ini adalah direktori untuk pembolehubah, kedua-dua pemalar (iaitu dikira untuk peranan) dan dinamik (sama ada terdapat corak atau anti-corak - include_vars dengan {{ ansible_distribution }}-{{ ansible_distribution_major_version }}.yml.). Ini adalah direktori untuk files/, templates/. Juga, ia membolehkan anda mempunyai modul dan pemalam anda sendiri (library/). Tetapi, berbanding dengan tugasan dalam buku main (yang juga boleh mempunyai semua ini), satu-satunya faedah di sini ialah fail tidak dibuang ke dalam satu longgokan, tetapi beberapa longgokan berasingan.

Satu lagi butiran: anda boleh cuba mencipta peranan yang akan tersedia untuk digunakan semula (melalui galaksi). Dengan adanya koleksi, pengagihan peranan boleh dianggap hampir dilupakan.

Oleh itu, peranan mempunyai dua ciri penting: ia mempunyai lalai (ciri unik) dan ia membenarkan anda menstruktur kod anda.

Kembali kepada soalan asal: bila hendak melakukan tugas dan bila hendak melakukan peranan? Tugasan dalam buku main paling kerap digunakan sama ada sebagai "gam" sebelum/selepas peranan, atau sebagai elemen binaan bebas (maka tidak sepatutnya ada peranan dalam kod). Timbunan tugas biasa yang dicampur dengan peranan adalah kecerobohan yang jelas. Anda harus mematuhi gaya tertentu - sama ada tugas atau peranan. Peranan menyediakan pemisahan entiti dan lalai, tugas membolehkan anda membaca kod dengan lebih cepat. Biasanya, lebih banyak kod "pegun" (penting dan kompleks) dimasukkan ke dalam peranan, dan skrip tambahan ditulis dalam gaya tugas.

Anda boleh melakukan import_role sebagai tugasan, tetapi jika anda menulis ini, maka bersedialah untuk menerangkan kepada deria kecantikan anda sendiri mengapa anda mahu melakukan ini.

Pembaca yang bijak mungkin mengatakan bahawa peranan boleh mengimport peranan, peranan boleh mempunyai kebergantungan melalui galaxy.yml, dan terdapat juga yang dahsyat dan dahsyat include_role — Saya mengingatkan anda bahawa kami sedang meningkatkan kemahiran dalam Ansible asas, dan bukan dalam gimnastik angka.

Pengendali dan tugas

Mari kita bincangkan satu lagi perkara yang jelas: pengendali. Mengetahui cara menggunakannya dengan betul adalah hampir satu seni. Apakah perbezaan antara pengendali dan seretan?

Memandangkan kita mengingati asasnya, berikut ialah contoh:

- hosts: group1
  tasks:
    - foo:
      notify: handler1
  handlers:
     - name: handler1
       bar:

Pengendali peranan terletak di rolename/handlers/main.yaml. Pengendali menyelongkar antara semua peserta permainan: pra/pasca_tugas boleh menarik pengendali peranan, dan peranan boleh menarik pengendali daripada permainan. Walau bagaimanapun, panggilan "peranan silang" kepada pengendali menyebabkan lebih banyak masalah daripada mengulangi pengendali remeh. (Satu lagi elemen amalan terbaik ialah cuba untuk tidak mengulangi nama pengendali).

Perbezaan utama ialah tugas itu sentiasa dilaksanakan (tidak berdaya) (tag tambah/tolak dan when), dan pengendali - mengikut keadaan berubah (beritahu kebakaran hanya jika ia telah diubah). Apakah maksud ini? Sebagai contoh, fakta bahawa apabila anda memulakan semula, jika tidak ada perubahan, maka tidak akan ada pengendali. Mengapa mungkin kita perlu melaksanakan pengendali apabila tiada perubahan dalam tugas penjanaan? Sebagai contoh, kerana sesuatu pecah dan berubah, tetapi pelaksanaan tidak sampai kepada pengendali. Contohnya, kerana rangkaian terputus buat sementara waktu. Konfigurasi telah berubah, perkhidmatan belum dimulakan semula. Kali seterusnya anda memulakannya, konfigurasi tidak lagi berubah dan perkhidmatan kekal dengan versi lama konfigurasi.

Situasi dengan konfigurasi tidak dapat diselesaikan (lebih tepat lagi, anda boleh mencipta protokol restart khas untuk diri anda dengan bendera fail, dll., tetapi ini tidak lagi 'asas boleh' dalam sebarang bentuk). Tetapi ada satu lagi cerita biasa: kami memasang aplikasi, merekodkannya .service-fail, dan kini kami mahukannya daemon_reload и state=started. Dan tempat semula jadi untuk ini nampaknya adalah pengendali. Tetapi jika anda menjadikannya bukan pengendali tetapi tugas di penghujung senarai tugas atau peranan, maka ia akan dilaksanakan secara idempoten setiap kali. Walaupun buku permainan pecah di tengah. Ini sama sekali tidak menyelesaikan masalah yang dimulakan semula (anda tidak boleh melakukan tugas dengan atribut yang dimulakan semula, kerana idempotensi hilang), tetapi ia pasti bernilai melakukan state=started, kestabilan keseluruhan buku permainan meningkat, kerana bilangan sambungan dan keadaan dinamik berkurangan.

Satu lagi sifat positif pengendali ialah ia tidak menyumbat keluaran. Tiada perubahan - tiada tambahan dilangkau atau ok dalam output - lebih mudah dibaca. Ia juga merupakan sifat negatif - jika anda mendapati kesilapan menaip dalam tugasan yang dilaksanakan secara linear pada larian pertama, maka pengendali akan dilaksanakan hanya apabila diubah, i.e. dalam beberapa keadaan - sangat jarang. Sebagai contoh, buat pertama kali dalam hidup saya lima tahun kemudian. Dan, sudah tentu, akan ada kesilapan dalam nama dan semuanya akan rosak. Dan jika anda tidak menjalankannya untuk kali kedua, tiada perubahan.

Secara berasingan, kita perlu bercakap tentang ketersediaan pembolehubah. Sebagai contoh, jika anda memberitahu tugasan dengan gelung, apakah yang akan ada dalam pembolehubah? Anda boleh meneka secara analitik, tetapi ia tidak selalunya remeh, terutamanya jika pembolehubah datang dari tempat yang berbeza.

... Jadi pengendali adalah kurang berguna dan lebih bermasalah daripada yang kelihatan. Jika anda boleh menulis sesuatu dengan cantik (tanpa tambahan) tanpa pengendali, lebih baik melakukannya tanpa mereka. Jika ia tidak berfungsi dengan baik, lebih baik dengan mereka.

Pembaca yang menghakis betul-betul menunjukkan bahawa kita tidak membincangkannya listenbahawa pengendali boleh memanggil pemberitahuan untuk pengendali lain, bahawa pengendali boleh memasukkan import_tasks (yang boleh melakukan include_role with with_items), bahawa sistem pengendali dalam Ansible adalah Turing-lengkap, bahawa pengendali dari include_role bersilang dengan cara yang ingin tahu dengan pengendali dari bermain, dan lain-lain .d. - semua ini jelas bukan "asas").

Walaupun terdapat satu WTF khusus yang sebenarnya merupakan ciri yang perlu anda ingat. Jika tugas anda dilaksanakan dengan delegate_to dan ia telah memberitahu, maka pengendali yang sepadan dilaksanakan tanpa delegate_to, iaitu pada hos tempat permainan ditugaskan. (Walaupun pengendali, sudah tentu, mungkin ada delegate_to Sama).

Secara berasingan, saya ingin menyatakan beberapa perkataan tentang peranan boleh guna semula. Sebelum koleksi muncul, terdapat idea bahawa anda boleh membuat peranan universal yang boleh ansible-galaxy install dan pergi. Berfungsi pada semua OS semua varian dalam semua situasi. Jadi, pendapat saya: ia tidak berfungsi. Mana-mana peranan dengan jisim include_vars, menyokong 100500 kes, ditakdirkan untuk menghadapi pepijat kes sudut. Ia boleh diliputi dengan ujian besar-besaran, tetapi seperti mana-mana ujian, sama ada anda mempunyai produk Cartesian dengan nilai input dan fungsi keseluruhan, atau anda mempunyai "senario individu diliputi." Pendapat saya adalah lebih baik jika peranannya adalah linear (kerumitan siklomatik 1).

Lebih sedikit ifs (eksplisit atau deklaratif - dalam bentuk when atau bentuk include_vars dengan set pembolehubah), lebih baik peranannya. Kadang-kadang anda perlu membuat cawangan, tetapi, saya ulangi, semakin sedikit, semakin baik. Jadi ia kelihatan seperti peranan yang baik dengan galaksi (ia berfungsi!) dengan sekumpulan when mungkin kurang diutamakan daripada peranan "sendiri" daripada lima tugas. Saat apabila peranan dengan galaksi lebih baik ialah apabila anda mula menulis sesuatu. Masa apabila ia menjadi lebih teruk ialah apabila sesuatu pecah dan anda mempunyai syak wasangka bahawa ia adalah kerana "peranan dengan galaksi". Anda membukanya, dan terdapat lima kemasukan, lapan helaian tugas dan timbunan when'ov... Dan kita perlu memikirkan perkara ini. Daripada 5 tugasan, senarai linear di mana tiada apa-apa untuk dipecahkan.

Dalam bahagian berikut

• Sedikit tentang inventori, pembolehubah kumpulan, pemalam host_group_vars, hostvars. Bagaimana untuk mengikat simpulan Gordian dengan spageti. Pembolehubah skop dan keutamaan, Model memori Ansible. "Jadi di manakah kita menyimpan nama pengguna untuk pangkalan data?"
• jinja: {{ jinja }} — nosql nosense nosense plastisin lembut. Ia ada di mana-mana, walaupun anda tidak menjangkakannya. Sedikit tentang !!unsafe dan yaml sedap.

Sumber: www.habr.com