🥇Ansible-г хэрхэн туршиж эхлэх вэ, нэг жилийн дотор төслийг дахин боловсруулж, галзуурахгүй байх

Энэ бол хуулбар юм тоглолтууд тухай DevOps-40 2020-03-18:

Хоёр дахь амлалтаас эхлэн аливаа код нь өвлөгддөг, учир нь анхны санаанууд нь хатуу ширүүн бодит байдлаас зөрж эхэлдэг. Энэ бол сайн ч биш, муу ч биш, маргахад хэцүү, хамт амьдрах ёстой өгөгдсөн зүйл юм. Энэ үйл явцын нэг хэсэг нь рефакторинг юм. Дэд бүтцийг код болгон өөрчлөх. Жилийн дараа Ansible-г хэрхэн дахин засварлаж, галзуурахгүй байх тухай түүхийг эхэлцгээе.

Өв залгамжлалын төрөлт

Өдөр №1: Өвчтөн тэг

Нэгэн цагт болзолт төсөл байсан. Энэ нь Dev хөгжүүлэлтийн баг болон үйлдлийн инженерүүдтэй байсан. Тэд ижил асуудлыг шийдэж байсан: серверүүдийг хэрхэн байрлуулах, програм ажиллуулах. Асуудал нь баг бүр энэ асуудлыг өөр өөрийнхөөрөө шийддэг байсан. Төслийн хүрээнд Dev болон Ops багуудын хооронд мэдлэгийг синхрончлохын тулд Ansible ашиглахаар шийдсэн.

Өдөр №89: Өв залгамжлалын төрөлт

Тэд өөрсдөө үүнийг анзааралгүй аль болох сайн хийхийг хүссэн боловч энэ нь өвлөгдөв. Энэ нь яаж болдог вэ?

Бидэнд яаралтай ажил байна, бохир хакердаад дараа нь засъя.
Та бичиг баримт бичих шаардлагагүй бөгөөд энд юу болж байгаа нь тодорхой байна.
Би Ansible/Python/Bash/Terraform-ийг мэднэ! Би яаж зугтаж чадахаа хараарай!
Би Full Stack Overflow хөгжүүлэгч бөгөөд үүнийг stackoverflow-аас хуулсан, энэ нь хэрхэн ажилладагийг мэдэхгүй ч энэ нь гайхалтай харагдаж, асуудлыг шийдэж байна.

Үүний үр дүнд та ямар ч баримт бичиггүй, юу хийдэг, шаардлагатай эсэх нь тодорхойгүй, ойлгомжгүй төрлийн код авах боломжтой, гэхдээ асуудал нь та үүнийг боловсруулж, өөрчлөх, таяг, тулгуур нэмэх хэрэгтэй. , нөхцөл байдлыг улам дордуулж байна.

- hosts: localhost
  tasks:
    - shell: echo -n Z >> a.txt && cat a.txt
      register: output
      delay: 1
      retries: 5
      until: not output.stdout.find("ZZZ")

Өдөр №109: Асуудлыг ухамсарлах

Анх бодож, хэрэгжүүлсэн IaC загвар нь хэрэглэгчид / бизнес / бусад багуудын шаардлагыг хангахаа больсон бөгөөд дэд бүтцэд өөрчлөлт оруулах хугацаа нь хүлээн зөвшөөрөгдөхгүй болсон. Энэ мөчид арга хэмжээ авах цаг нь болсон гэсэн ойлголт ирж байна.

IaC рефакторинг

Өдөр №139: Танд үнэхээр рефакторинг хэрэгтэй байна уу?

Та дахин засварлах гэж яарахаасаа өмнө хэд хэдэн чухал асуултанд хариулах ёстой.

Яагаад чамд энэ бүхэн хэрэгтэй байна вэ?
Танд зав байна уу?
Мэдлэг хангалттай юу?

Хэрэв та асуултуудад хэрхэн хариулахаа мэдэхгүй байгаа бол рефакторинг эхлэхээс өмнө дуусна, эсвэл бүр дордож магадгүй. Учир нь туршлагатай байсан ( 200 мөрийн дэд бүтцийн кодыг туршиж үзээд юу сурсан), дараа нь төсөл нь дүрүүдийг засах, тестээр хамрахад туслах хүсэлтийг хүлээн авсан.

Өдөр №149: Рефакторинг бэлтгэх

Хамгийн эхний зүйл бол бэлтгэх явдал юм. Бид юу хийхээ шийдээрэй. Үүнийг хийхийн тулд бид харилцаж, асуудлын талбарыг олж, тэдгээрийг шийдвэрлэх арга замыг хайж олдог. Бид үүссэн ухагдахууныг ямар нэгэн байдлаар, жишээлбэл, нэг өгүүлэлд тэмдэглэдэг бөгөөд ингэснээр "хамгийн сайн нь юу вэ?" Гэсэн асуулт гарч ирэхэд. эсвэл "аль нь зөв бэ?" Бид замаа алдаагүй. Манай тохиолдолд бид санаагаа барьж байсан хувааж, захир: бид дэд бүтцийг жижиг хэсэг/тоосго болгон задалдаг. Энэ арга нь дэд бүтцийн тусгаарлагдсан хэсгийг авч, юу хийдгийг ойлгож, туршилтаар бүрхэж, юу ч эвдэхээс айхгүйгээр өөрчлөх боломжийг олгодог.

Дэд бүтцийн туршилт нь тулгын чулуу болж байгаа бөгөөд энд дэд бүтцийн туршилтын пирамидын талаар дурдах нь зүйтэй болов уу. Хөгжиж буйтай яг ижил санаа, гэхдээ дэд бүтцийн хувьд: бид догол гэх мэт энгийн зүйлсийг шалгадаг хямд хурдан тестээс дэд бүтцийг бүхэлд нь ашигладаг үнэтэй бүрэн хэмжээний туршилт руу шилжиж байна.

Туршилтын боломжит оролдлого

Төслийн Ansible тестүүдийг хэрхэн авч үзсэнээ тайлбарлахын өмнө би гаргасан шийдвэрийн нөхцөл байдлыг ойлгохын тулд өмнө нь ашиглах боломж байсан оролдлого, арга барилын талаар тайлбарлах болно.

Өдрийн дугаар -997: SDS хангах

Би анх удаа Ansible-г SDS (Програм хангамжаар тодорхойлогдсон хадгалах) боловсруулах төсөл дээр туршиж үзсэн. Энэ сэдвээр тусдаа нийтлэл байна
Хуваарилалтаа туршихдаа таяг дээр унадаг дугуйг хэрхэн эвдэх вэ, гэхдээ товчхондоо бид урвуу туршилтын пирамидтай болж, туршилтанд бид нэг дүрд 60-90 минут зарцуулсан бөгөөд энэ нь урт хугацаа юм. Үүний үндэс нь e2e тестүүд, өөрөөр хэлбэл. Бид бүрэн хэмжээний суулгацыг суулгаж, дараа нь туршиж үзсэн. Бүр хүндрүүлсэн зүйл бол өөрийн дугуй зохион бүтээсэн явдал байв. Гэхдээ энэ шийдэл нь ажиллаж, тогтвортой хувилбар гаргах боломжийг олгосон гэдгийг би хүлээн зөвшөөрөх ёстой.

Өдөр # -701: Ansible болон туршилтын гал тогоо

Ansible тестийн санааг хөгжүүлэх нь бэлэн багаж хэрэгсэл, тухайлбал, туршилтын гал тогоо / гал тогооны-ci болон inspec ашиглах явдал байв. Сонголтыг Ruby-ийн мэдлэгээр тодорхойлсон (дэлгэрэнгүй мэдээллийг Habré-ийн нийтлэлээс үзнэ үү: YML програмистууд Ansible-г туршихыг мөрөөддөг үү?) илүү хурдан, 40 дүрд 10 минут орчим ажилласан. Бид виртуал машинуудын багцыг бүтээж, дотор нь туршилт хийсэн.

Ерөнхийдөө шийдэл нь үр дүнтэй байсан ч гетероген байдлаас шалтгаалан бага зэрэг тунадас үүссэн. Туршилтанд хамрагдсан хүмүүсийн тоог 13 үндсэн үүрэг, 2 мета үүрэг болгон жижиг дүрүүдийг нэгтгэсэн үед гэнэт туршилтууд 70 минутын турш ажиллаж эхэлсэн бөгөөд энэ нь бараг 2 дахин урт юм. XP (Extreme programming) дадлагын талаар ярихад хэцүү байсан, учир нь... 70 минут хүлээхийг хэн ч хүсэхгүй. Энэ нь арга барилаа өөрчлөх шалтгаан болсон юм

Өдөр # -601: Ансибл ба молекул

Үзэл баримтлалын хувьд энэ нь testkitchen-тэй төстэй бөгөөд зөвхөн бид дүрийн тестийг докер руу шилжүүлж, стекийг өөрчилсөн. Үүний үр дүнд 20 дүрд тогтвор суурьшилтай 25-7 минут болж багассан.

Туршсан дүрүүдийн тоог 17 болгож, 45 дүрд оруулснаар бид үүнийг 28 Женкинсийн боол дээр 2 минутын дотор гүйцэтгэсэн.

Өдөр №167: Төсөлд Ansible тест нэмэх

Рефактор хийх ажлыг яаран хийх боломжгүй байх магадлалтай. Даалгавар нь хэмжигдэхүйц байх ёстой бөгөөд ингэснээр та үүнийг жижиг хэсгүүдэд хувааж, зааныг цайны халбагаар хэсэг хэсгээр нь идэж болно. Зөв чиглэлд явж байна уу, хэр удаан явах вэ гэсэн ойлголт байх ёстой.

Ер нь яаж хийх нь хамаагүй, цаасан дээр бичиж болно, шүүгээн дээр наалт нааж болно, Jira-д даалгавар хийж болно, эсвэл Google Docs-ийг нээж, одоогийн статусаа бичиж болно. Тэнд. Үйл явц нь нэн даруй биш, урт, уйтгартай байх болно гэдгийг хөл нь ургадаг. Рефактор хийх явцад хэн нэгэн таныг санаанаасаа салж, ядарч, хэт их бухимдахыг хүсэх нь юу л бол.

Дахин засварлах нь энгийн:

Хоолоо ид.
Унтах.
Код.
IaC тест.
Давтах

мөн бид зорилгодоо хүрэх хүртлээ үүнийг давтана.

Бүх зүйлийг нэн даруй шалгаж эхлэх боломжгүй байж магадгүй тул бидний хамгийн эхний ажил бол синтаксийг сайтар шалгаж үзэх явдал байв.

Өдөр №181: Ногоон байгууламжийн мастер

Linting нь Green Build Master руу чиглэсэн анхны жижиг алхам юм. Энэ нь бараг юу ч эвдэхгүй, гэхдээ энэ нь танд процессуудыг дибаг хийх, Женкинс дэх ногоон байгууламжуудыг хийх боломжийг олгоно. Гол санаа нь багийн дунд зуршлыг хөгжүүлэх явдал юм.

Улаан тест муу байна.
Би ямар нэг зүйлийг засахын зэрэгцээ кодыг таны өмнөхөөс арай дээр болгох гэж ирсэн.

Өдөр №193: Хувцасны хөвөнгөөс эхлээд нэгжийн туршилт хүртэл

Мастерт код оруулах үйл явцыг бий болгосны дараа та алхам алхмаар сайжруулах үйл явцыг эхлүүлж болно - хөвөнг эхлүүлэх дүрээр сольж, та үүнийг чадваргүй болгох боломжтой. Та дүрүүдийг хэрхэн хэрэгжүүлэх, тэдгээр нь хэрхэн ажилладагийг ойлгох хэрэгтэй.

Өдөр №211: Нэгжээс нэгтгэх тест хүртэл

Ихэнх дүрүүд нэгжийн тестүүдээр бүрхэгдсэн бөгөөд бүх зүйл бүрхэгдсэн үед та интеграцийн тестийг нэмж болно. Тэдгээр. дэд бүтцэд нэг тоосго биш, харин тэдгээрийн хослол, жишээлбэл, бүрэн хэмжээний тохиргоог турших.

Женкинсийг ашиглан бид дүрүүд/тоглоомын дэвтэрүүдийг зэрэгцүүлэн харуулсан олон үе шат, дараа нь контейнер дэх нэгжийн тест, эцэст нь нэгтгэх тестүүдийг үүсгэсэн.

Jenkins + Docker + Ansible = Туршилтууд

Репо тооцоо хийж, бүтээх үе шатуудыг үүсгэ.
Lint playbook-ийн үе шатуудыг зэрэгцүүлэн ажиллуул.
Зэрэгцээ хөвөн дүрийн үе шатуудыг ажиллуул.
Синтакс шалгах үүргийн үе шатуудыг зэрэгцүүлэн ажиллуул.
Туршилтын үүргийн үе шатуудыг зэрэгцүүлэн ажиллуул.
1. Линт үүрэг.
2. Бусад дүрүүдээс хамааралтай эсэхийг шалгана уу.
3. Синтаксийг шалгана уу.
4. Докерын жишээ үүсгэх
5. Molecule/default/playbook.yml-г ажиллуул.
6. Идэвхгүй байдлыг шалгах.
Интеграцийн тестийг ажиллуул
Finish

Өдөр # 271: Автобусны хүчин зүйл

Эхний ээлжинд хоёр гурван хүний бүрэлдэхүүнтэйгээр рефакторинг хийдэг байсан. Тэд мастер дээрх кодыг хянаж үзсэн. Цаг хугацаа өнгөрөхөд баг хэрхэн код бичих талаархи мэдлэгийг хөгжүүлж, кодын тойм нь дэд бүтэц, хэрхэн ажилладаг талаар мэдлэгийг түгээхэд хувь нэмэр оруулсан. Энд онцлох зүйл бол тоймчдыг хуваарийн дагуу нэг нэгээр нь сонгосон, i.e. тодорхой хэмжээгээр та дэд бүтцийн шинэ хэсэг рүү авирах магадлалтай.

Мөн энд тав тухтай байх ёстой. Дүгнэлт хийх, ямар ажил хийсэн, хэлэлцүүлгийн түүхийг үзэхэд тохиромжтой. Бид jenkins + bitbucket + jira-г нэгтгэсэн.

Гэсэн хэдий ч, тойм бол эм биш бөгөөд бид ямар нэгэн байдлаар мастер код руу орсон бөгөөд энэ нь биднийг унтрах тест хийхэд хүргэсэн:

- get_url:
    url: "{{ actk_certs }}/{{ item.1 }}"
    dest: "{{ actk_src_tmp }}/"
    username: "{{ actk_mvn_user }}"
    password: "{{ actk_mvn_pass }}"
  with_subelements:
    - "{{ actk_cert_list }}"
    - "{{ actk_certs }}"
  delegate_to: localhost

- copy:
    src: "{{ actk_src_tmp }}/{{ item.1 }}"
    dest: "{{ actk_dst_tmp }}"
  with_subelements:
    - "{{ actk_cert_list }}"
    - "{{ actk_certs }}"

Дараа нь тэд үүнийг зассан боловч тунадас үлдсэн.

get_url:
    url: "{{ actk_certs }}/{{ actk_item }}"
    dest: "{{ actk_src_tmp }}/{{ actk_item }}"
    username: "{{ actk_mvn_user }}"
    password: "{{ actk_mvn_pass }}"
  loop_control:
    loop_var: actk_item
  with_items: "{{ actk_cert_list }}"
  delegate_to: localhost

- copy:
    src: "{{ actk_src_tmp }}/{{ actk_item }}"
    dest: "{{ actk_dst_tmp }}"
  loop_control:
    loop_var: actk_item
  with_items: "{{ actk_cert_list }}"

Өдөр №311: Туршилтыг хурдасгах

Цаг хугацаа өнгөрөхөд олон туршилтууд гарч, барилгын ажил удааширч, хамгийн муу тохиолдолд нэг цаг хүртэл үргэлжилсэн. Нэг чимэг дээр "Тест байгаа нь сайн, гэхдээ тэд удаан байна" гэсэн өгүүлбэр байсан. Үүний үр дүнд бид виртуал машинууд дээрх интеграцийн туршилтыг орхиж, үүнийг илүү хурдан болгохын тулд Docker-д тохируулсан. Мөн хэрэглэгдэх хэрэгслийн тоог багасгахын тулд бид testinfra-г ansible verifier-ээр сольсон.

Хатуухан хэлэхэд хэд хэдэн арга хэмжээ авсан:

Докер руу шилжих.
Хамааралтай байдлаас болж давхардсан дүрийн тестийг устгана уу.
Боолуудын тоог нэмэгдүүл.
Туршилтын дараалал.
Хөвсгөх чадвар БҮГД нэг тушаалаар орон нутагт.

Үүний үр дүнд Pipeline on jenkins-ийг мөн нэгтгэсэн

Барилгын үе шатуудыг бий болгох.
Бүгдийг зэрэгцүүлэн хөвөн хатга.
Туршилтын үүргийн үе шатуудыг зэрэгцүүлэн ажиллуул.
Дуусга.

Хичээл сурсан

Глобал хувьсагчаас зайлсхий

Ansible нь глобал хувьсагчдыг ашигладаг бөгөөд маягт дээр хэсэгчилсэн тойрон гарах арга байдаг хувийн_үүргийн_хувьсгалууд, гэхдээ энэ нь эм биш юм.

Би танд нэг жишээ хэлье. Байгаа role_a и role_b

# cat role_a/defaults/main.yml
---
msg: a

# cat role_a/tasks/main.yml
---
- debug:
    msg: role_a={{ msg }}

# cat role_b/defaults/main.yml
---
msg: b

# cat role_b/tasks/main.yml
---
- set_fact:
    msg: b
- debug:
    msg: role_b={{ msg }}

- hosts: localhost
  vars:
    msg: hello
  roles:
    - role: role_a
    - role: role_b
  tasks:
    - debug:
        msg: play={{msg}}

Хамгийн инээдтэй нь тоглоомын дэвтрийн үр дүн нь дүрүүдийг жагсаасан дараалал гэх мэт үргэлж тодорхой байдаггүй зүйлсээс шалтгаална. Харамсалтай нь энэ бол Ansible-ийн мөн чанар бөгөөд хийж болох хамгийн сайн зүйл бол ямар нэгэн тохиролцоог ашиглах, жишээлбэл, дүрд зөвхөн энэ дүрд тайлбарласан хувьсагчийг ашиглах явдал юм.

BAD: глобал хувьсагч ашиглах.

# cat roles/some_role/tasks/main.yml
---
debug:
  var: java_home

САЙН: В. defaults шаардлагатай хувьсагчдыг тодорхойлж, дараа нь зөвхөн тэдгээрийг ашиглана.

# cat roles/some_role/defaults/main.yml
---
r__java_home:
 "{{ java_home | default('/path') }}"

# cat roles/some_role/tasks/main.yml
---
debug:
  var: r__java_home

Угтвар үүрэг хувьсагчид

BAD: глобал хувьсагч ашиглах.

# cat roles/some_role/defaults/main.yml
---
db_port: 5432

САЙН: Хувьсагчийн дүрүүдэд дүрийн нэрээр угтсан хувьсагчдыг ашигла; энэ нь бараа материалыг харснаар юу болж байгааг ойлгоход хялбар болгоно.

# cat roles/some_role/defaults/main.yml
---
some_role__db_port: 5432

Давталтын хяналтын хувьсагчийг ашиглана уу

BAD: Стандарт хувьсагчийг гогцоонд ашиглана item, хэрэв энэ даалгавар/тоглоомын дэвтэр хаа нэгтээ орсон бол энэ нь гэнэтийн үйлдэлд хүргэж болзошгүй

---
- hosts: localhost
  tasks:
    - debug:
        msg: "{{ item }}"
      loop:
        - item1
        - item2

САЙН: Давтамжинд байгаа хувьсагчийг дахин тодорхойлох loop_var.

---
- hosts: localhost
  tasks:
    - debug:
        msg: "{{ item_name }}"
      loop:
        - item1
        - item2
      loop_control:
        loop_var: item_name

Оролтын хувьсагчдыг шалгана уу

Бид хувьсагчийн угтварыг ашиглахаар тохиролцсон; тэдгээр нь бидний бодож байгаагаар тодорхойлогдсон, жишээлбэл, хоосон утгаар дарагдаагүй эсэхийг шалгах нь илүүц байх болно.

САЙН: Хувьсагчдыг шалгана уу.

- name: "Verify that required string variables are defined"
  assert:
    that: ahs_var is defined and ahs_var | length > 0 and ahs_var != None
    fail_msg: "{{ ahs_var }} needs to be set for the role to work "
    success_msg: "Required variables {{ ahs_var }} is defined"
  loop_control:
    loop_var: ahs_var
  with_items:
    - ahs_item1
    - ahs_item2
    - ahs_item3

Хэш толь бичгүүдээс зайлсхийж, хавтгай бүтцийг ашигла

Хэрэв үүрэг нь аль нэг параметрт нь хэш/толь бичгийг хүлээж байгаа бол бид хүүхдийн параметрүүдийн аль нэгийг өөрчлөхийг хүсвэл хэш/толь бичгийг бүхэлд нь хүчингүй болгох шаардлагатай бөгөөд энэ нь тохиргооны нарийн төвөгтэй байдлыг нэмэгдүүлнэ.

BAD: Хэш/толь бичгийг ашигла.

---
user:
  name: admin
  group: admin

САЙН: Хавтгай хувьсах бүтцийг ашиглана.

---
user_name: admin
user_group: "{{ user_name }}"

Боломжгүй тоглоомын ном, дүрүүдийг үүсгэ

Дүр болон тоглоомын номууд нь idempotent байх ёстой, учир нь тохиргооны шилжилт хөдөлгөөн болон ямар нэг зүйлийг эвдэхээс айдаг байдлыг бууруулдаг. Гэхдээ хэрэв та молекул ашигладаг бол энэ нь анхдагч зан төлөв юм.

Командын бүрхүүлийн модулиудыг ашиглахаас зайлсхий

Бүрхүүлийн модулийг ашигласнаар Ansible-ийн цөм болох тунхаглалын оронд императив тайлбарын парадигм үүсдэг.

Өөрийнхөө үүргийг молекулаар туршиж үзээрэй

Молекул бол маш уян хатан зүйл, хэд хэдэн хувилбарыг авч үзье.

Молекул Олон тохиолдлууд

В molecule.yml хэсэгт platforms та өөрийн байрлуулж болох олон хостуудыг дүрсэлж болно.

---
    driver:
      name: docker
    platforms:
      - name: postgresql-instance
        hostname: postgresql-instance
        image: registry.example.com/postgres10:latest
        pre_build_image: true
        override_command: false
        network_mode: host
      - name: app-instance
        hostname: app-instance
        pre_build_image: true
        image: registry.example.com/docker_centos_ansible_tests
        network_mode: host

Үүний дагуу эдгээр хостууд дараа нь байж болно converge.yml ашиглах:

---
- name: Converge all
  hosts: all
  vars:
    ansible_user: root
  roles:
    - role: some_role

- name: Converge db
  hosts: db-instance
  roles:
    - role: some_db_role

- name: Converge app
  hosts: app-instance
  roles:
    - role: some_app_role

Баталгаажуулагч

Молекулын хувьд жишээг зөв тохируулсан эсэхийг шалгахын тулд ansible ашиглах боломжтой, үүнээс гадна энэ нь 3-р хувилбараас хойш анхдагч байсан. Энэ нь testinfra/inspec шиг уян хатан биш боловч файлын агуулга бидний хүлээлттэй нийцэж байгаа эсэхийг шалгаж болно:

---
- name: Verify
  hosts: all
  tasks:
    - name: copy config
      copy:
        src: expected_standalone.conf
        dest: /root/wildfly/bin/standalone.conf
        mode: "0644"
        owner: root
        group: root
      register: config_copy_result

    - name: Certify that standalone.conf changed
      assert:
        that: not config_copy_result.changed

Эсвэл үйлчилгээг байрлуулж, ашиглах боломжтой болтол нь хүлээж, утааны тест хийнэ үү:

---
  - name: Verify
    hosts: solr
    tasks:
      - command: /blah/solr/bin/solr start -s /solr_home -p 8983 -force
      - uri:
          url: http://127.0.0.1:8983/solr
          method: GET
          status_code: 200
        register: uri_result
        until: uri_result is not failed
        retries: 12
        delay: 10
      - name: Post documents to solr
        command: /blah/solr/bin/post -c master /exampledocs/books.csv

Нарийн төвөгтэй логикийг модуль, залгаасууд руу оруулна уу

Ansible нь тунхаглалын хандлагыг дэмждэг тул кодын салбарлах, өгөгдөл хувиргах, бүрхүүлийн модулиуд хийх үед кодыг уншихад хэцүү болдог. Үүнтэй тэмцэх, ойлгоход хялбар болгохын тулд өөрийн модулиудыг бий болгосноор энэхүү нарийн төвөгтэй байдлын эсрэг тэмцэх нь илүүц байх болно.

Зөвлөмж ба заль мэхийг нэгтгэн дүгнэ

Глобал хувьсагчаас зайлсхий.
Угтвар үүрэг хувьсагчид.
Давталтын хяналтын хувьсагчийг ашиглана уу.
Оролтын хувьсагчдыг шалгана уу.
Хэш толь бичгүүдээс зайлсхийж, хавтгай бүтцийг ашигла.
Боломжгүй тоглоомын ном, дүрүүдийг үүсгэ.
Командын бүрхүүлийн модулиудыг ашиглахаас зайлсхий.
Өөрийнхөө үүргийг молекулаар туршиж үзээрэй.
Нарийн төвөгтэй логикийг модуль, залгаасууд руу оруулна уу.

дүгнэлт

Та IaC-тай байсан ч төслийн дэд бүтцээ дахин засварлаж чадахгүй. Энэ бол тэвчээр, цаг хугацаа, мэдлэг шаарддаг урт процесс юм.

Холбоосууд

UPD1 2020.05.01 20:30 - Тоглоомын дэвтрийн анхан шатны профайл хийхэд та ашиглаж болно callback_whitelist = profile_tasks яг юу болохыг удаан хугацаанд ойлгохын тулд. Дараа нь бид дамждаг Ansible хурдатгалын сонгодог. Та бас оролдож болно митоген
UPD2 2020.05.03 16:34 - Англи хувилбар

Эх сурвалж: www.habr.com

Ansible-г хэрхэн туршиж эхлэх вэ, нэг жилийн дотор төслийг дахин боловсруулж, галзуурахгүй байх