Ansible-ді тестілеуді қалай бастау керек, жобаны бір жылдан кейін қайта өңдеңіз және ақылсыз болмаңыз

Бұл транскрипт қойылымдар туралы DevOps-40 2020:

Екінші міндеттемеден бастап кез келген код мұраға айналады, өйткені бастапқы идеялар қатал шындықтан алшақтай бастайды. Бұл жақсы да, жаман да емес, бұл дауласу қиын және онымен өмір сүру керек берілген. Бұл процестің бір бөлігі рефакторинг болып табылады. Инфрақұрылымды код ретінде қайта өңдеу. Әңгімені бір жылдан кейін Ansible-ді қалай рефакторлау және есінен танып қалмау туралы бастайық.

Мұраның туылуы

№1 күн: пациент нөл

Бір кездері шартты жоба болған. Оның әзірлеушілер тобы және операциялық инженерлер болды. Олар бірдей мәселені шешті: серверлерді қалай орналастыру және қолданбаны іске қосу. Мәселе әр команданың бұл мәселені өзінше шешуінде болды. Жобада 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 күн: Сізге рефакторинг қажет пе?

Рефакторға асығар алдында сіз бірқатар маңызды сұрақтарға жауап беруіңіз керек:

1. Мұның бәрі сізге не үшін керек?
2. Уақытыңыз бар ма?
3. Білім жеткілікті ме?

Егер сіз сұрақтарға қалай жауап беру керектігін білмесеңіз, рефакторинг басталмай тұрып аяқталады немесе нашарлауы мүмкін. Өйткені тәжірибесі болды( Инфрақұрылымдық кодтың 200 000 жолын сынаудан не білдім), содан кейін жоба рөлдерді түзетуге және оларды сынақтармен қамтуға көмек сұрауын алды.

№149 күн: Рефакторингті дайындау

Бірінші нәрсе - дайындық. Не істейтінімізді шешіңіз. Ол үшін біз қарым-қатынас жасаймыз, проблемалық аймақтарды тауып, оларды шешу жолдарын анықтаймыз. Біз қандай да бір жолмен алынған тұжырымдамаларды, мысалы, мақаланы біріктіріп жазамыз, сонда «не жақсы?» Деген сұрақ туындайды. немесе «қайсысы дұрыс?» Біз жолымыздан адаспадық. Біздің жағдайда біз идеяны ұстандық бөлу және басқару: біз инфрақұрылымды кішкене бөліктерге/кірпішке бөлеміз. Бұл тәсіл инфрақұрылымның оқшауланған бөлігін алуға, оның не істейтінін түсінуге, оны сынақтармен жабуға және ештеңені бұзудан қорықпай өзгертуге мүмкіндік береді.

Инфрақұрылымдық тестілеу іргетасқа айналады және бұл жерде инфрақұрылымды тестілеу пирамидасын атап өткен жөн. Дәл сол идея әзірленуде, бірақ инфрақұрылым үшін: біз шегініс сияқты қарапайым нәрселерді тексеретін арзан жылдам сынақтардан бүкіл инфрақұрылымды орналастыратын қымбат толыққанды сынақтарға көшеміз.

Ақылға қонымды сынақ әрекеттері

Жоба бойынша Ansible сынақтарын қалай қарастырғанымызды сипаттауға бармас бұрын, мен қабылданған шешімдердің контекстін түсіну үшін бұрын қолдану мүмкіндігім болған әрекеттер мен тәсілдерді сипаттаймын.

Күн № -997: SDS қамтамасыз ету

Мен Ansible-ді бірінші рет SDS (бағдарламалық құрал анықталған сақтау) әзірлеу жобасында сынадым. Бұл тақырып бойынша бөлек мақала бар
Таратуды сынау кезінде велосипедтерді балдақпен қалай бұзуға болады, бірақ қысқаша айтқанда, біз инверттелген тестілеу пирамидасымен аяқталдық және тестілеуге біз бір рөлге 60-90 минут жұмсадық, бұл ұзақ уақыт. Негізі e2e сынақтары болды, яғни. біз толыққанды қондырғыны орналастырдық, содан кейін оны сынақтан өткіздік. Одан да ауырлататыны – өз велосипедін ойлап табу болды. Бірақ мойындауым керек, бұл шешім жұмыс істеді және тұрақты босатуға мүмкіндік берді.

Күн № -701: Ansible және сынақ асханасы

Ansible тестілеу идеясының дамуы дайын құралдарды пайдалану болды, атап айтқанда test kitchen / kitchen-ci және inspec. Таңдау Ruby туралы біліммен анықталды (толығырақ ақпарат алу үшін Habre туралы мақаланы қараңыз: YML бағдарламашылары Ansible-ді сынауды армандай ма?) жылдамырақ жұмыс істеді, 40 рөлге шамамен 10 минут. Біз виртуалды машиналар пакетін жасап, оның ішінде сынақтарды жүргіздік.

Жалпы алғанда, ерітінді жұмыс істеді, бірақ гетерогенділікке байланысты кейбір шөгінділер болды. Тестілеуден өткен адамдар саны 13 негізгі рөлге және кішірек рөлдерді біріктіретін 2 мета рөлге дейін ұлғайтылған кезде, кенеттен сынақтар 70 минутқа жұмыс істей бастады, бұл 2 есе көп. XP (экстремалды бағдарламалау) тәжірибесі туралы айту қиын болды, себебі... ешкім 70 минут күткісі келмейді. Бұл тәсілді өзгертуге себеп болды

Күн # -601: Ansible және молекула

Тұжырымдама бойынша бұл testkitchen-ге ұқсас, тек біз рөлдік тестілеуді докерге ауыстырдық және стекті өзгерттік. Нәтижесінде 20 рөлге арналған тұрақты 25-7 минутқа дейін уақыт қысқарды.

Сыналған рөлдердің санын 17-ге дейін көбейтіп, 45 рөлді белгілеу арқылы біз мұны 28 Дженкинс құлында 2 минутта орындадық.

№167 күн: Жобаға Ansible сынақтарын қосу

Сірә, рефакторинг тапсырмасын асығыс орындау мүмкін емес. Тапсырма өлшенетін болуы керек, сондықтан оны кішкене бөліктерге бөліп, пілді шай қасықпен бөлшектеп жеуге болады. Сіз дұрыс бағытта келе жатырсыз ба, қанша уақыт жүру керек деген түсінік болуы керек.

Жалпы қалай жасалатыны маңызды емес, қағазға жазуға болады, шкафқа стикерлерді қоюға болады, Jira-да тапсырмалар жасауға болады немесе Google Docs ашып, ағымдағы күйді жазуға болады. Ана жерде. Аяқтар процесс бірден емес, ұзақ және жалықтыратындықтан өседі. Рефакторинг кезінде ешкім сіздің идеяларыңыздан тайып, шаршағаныңызды және күйзелуіңізді қалауы екіталай.

Рефакторинг қарапайым:

• Жей беріңіз.
• Ұйқы.
• Код.
• IaC сынағы.
• қайталау

және біз бұл мақсатқа жеткенше қайталаймыз.

Барлығын бірден тестілеуді бастау мүмкін болмауы мүмкін, сондықтан біздің бірінші міндетіміз синтаксисті линтингтен және тексеруден бастау болды.

№181 күн: Жасыл құрылыс шебері

Линтинг - бұл Green Build Master жолындағы шағын алғашқы қадам. Бұл дерлік ештеңені бұзбайды, бірақ ол сізге процестерді жөндеуге және Дженкинсте жасыл құрылыстар жасауға мүмкіндік береді. Ұжым арасында әдеттерді дамыту идеясы:

• Қызыл сынақтар нашар.
• Мен бірдеңені түзету үшін келдім және сонымен бірге кодты сізден бұрынғыдан сәл жақсырақ етіп жасадым.

№193 күн: линтингтен бірлік сынақтарына дейін

Мастерге кодты алу процесін құрастырғаннан кейін, сіз кезең-кезеңмен жетілдіру процесін бастай аласыз - линтингті іске қосу рөлдерімен ауыстыру, сіз оны импульссіз де жасай аласыз. Рөлдерді қалай қолдану керектігін және олардың қалай жұмыс істейтінін түсінуіңіз керек.

№211 күн: Бірліктен интеграциялық сынақтарға дейін

Көптеген рөлдер бірлік сынақтарымен қамтылған кезде және барлығы сызылған болса, интеграция сынақтарын қосуға көшуге болады. Анау. инфрақұрылымдағы бір кірпішті емес, олардың комбинациясын, мысалы, толық даналық конфигурацияны сынау.

Дженкинсті пайдалана отырып, біз рөлдерді/ойын кітаптарын қатарластыратын көптеген кезеңдерді, содан кейін контейнерлердегі бірлік сынақтарын және ең соңында интеграция сынақтарын жасадық.

Дженкинс + Докер + Ansible = Тесттер

1. Репо тексеру және құрастыру кезеңдерін жасау.
2. Lint Playbook кезеңдерін параллель орындаңыз.
3. Линт рөлі кезеңдерін параллель орындаңыз.
4. Синтаксистік тексеру рөл кезеңдерін параллель орындаңыз.
5. Сынақ рөл кезеңдерін параллель орындаңыз.
   1. Линт рөлі.
   2. Басқа рөлдерге тәуелділікті тексеріңіз.
   3. Синтаксисті тексеру.
   4. Докер данасын жасаңыз
   5. Molecule/default/playbook.yml іске қосыңыз.
   6. Импотенттілікті тексеріңіз.
6. Интеграция сынақтарын іске қосыңыз
7. Аяқтау

№271 күн: Автобус факторы

Алғашында рефакторингті екі-үш адамнан тұратын шағын топ жүргізді. Олар шебердегі кодты қарап шықты. Уақыт өте келе команда кодты қалай жазу керектігі туралы білімін дамытты және кодты шолу инфрақұрылым және оның қалай жұмыс істейтіні туралы білімнің таралуына ықпал етті. Мұндағы ерекше жағдай рецензенттер кесте бойынша бірінен соң бірі таңдалды, яғни. белгілі бір ықтималдық дәрежесімен сіз инфрақұрылымның жаңа бөлігіне көтерілесіз.

Және бұл жерде ыңғайлы болуы керек. Қарап шығуға, оның қандай тапсырманың орындалғанын және талқылаулар тарихын қарауға ыңғайлы. Бізде біріктірілген 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-ге ауыстырдық.

Қатаң айтқанда, шаралар кешені болды:

1. Докерге ауысу.
2. Тәуелділіктерге байланысты қайталанатын рөлді тексеруді алып тастаңыз.
3. Құлдардың санын көбейтіңіз.
4. Сынақ жүргізу тәртібі.
5. Тітіркену қабілеті БАРЛЫҚ бір пәрменмен жергілікті.

Нәтижесінде Дженкинстегі құбыр желісі де біртұтас болды

1. Құрастыру кезеңдерін жасаңыз.
2. Барлығын параллель жабыңыз.
3. Сынақ рөл кезеңдерін параллель орындаңыз.
4. Аяқтау.

Алынған сабақтар

Жаһандық айнымалылардан аулақ болыңыз

Ansible жаһандық айнымалы мәндерді пайдаланады, пішінде ішінара уақытша шешім бар private_role_vars, бірақ бұл панацея емес.

Бір мысал келтірейін. Болсын 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 сипаты және жасалуы мүмкін ең жақсы нәрсе - келісімнің қандай да бір түрін пайдалану, мысалы, рөл ішінде осы рөлде сипатталған айнымалыны ғана пайдаланыңыз.

ЖАМАН: жаһандық айнымалыны пайдаланыңыз.

# 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

Префикс рөлдік айнымалылар

ЖАМАН: жаһандық айнымалыны пайдаланыңыз.

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

ЖАҚСЫ: Айнымалыларға арналған рөлдерде рөл атымен префикс қойылған айнымалы мәндерді пайдаланыңыз; бұл түгендеуді қарау арқылы не болып жатқанын түсінуді жеңілдетеді.

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

Циклды басқару айнымалысын пайдаланыңыз

ЖАМАН: Стандартты айнымалыны циклдарда пайдаланыңыз 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

Хэш сөздіктерінен аулақ болыңыз, тегіс құрылымды пайдаланыңыз

Егер рөл өзінің параметрлерінің бірінде хэш/сөздік күтетін болса, онда еншілес параметрлердің бірін өзгерткіміз келсе, конфигурацияның күрделілігін арттыратын бүкіл хэш/сөздікті қайта анықтауымыз керек.

ЖАМАН: Хэш/сөздікті пайдаланыңыз.

---
user:
  name: admin
  group: admin

ЖАҚСЫ: Жазық айнымалы құрылымды пайдаланыңыз.

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

Идемпотентті ойын кітаптары мен рөлдерді жасаңыз

Рөлдер мен ойын кітаптары идемпотентті болуы керек, өйткені конфигурацияның ауытқуын және бір нәрсені бұзу қорқынышын азайтады. Бірақ егер сіз молекуланы қолдансаңыз, бұл әдепкі әрекет.

Пәрмен қабықшасының модульдерін пайдаланудан аулақ болыңыз

Қабық модулін пайдалану 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 тексеруші

Молекулада дананың дұрыс конфигурацияланғанын тексеру үшін 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 декларативті тәсілді жақтайды, сондықтан кодты тармақтауды, деректерді түрлендіруді, қабық модульдерін орындаған кезде кодты оқу қиынға соғады. Мұнымен күресу және оны түсіну оңай болуы үшін, өзіңіздің модульдеріңізді жасау арқылы бұл күрделілікпен күресу артық болмайды.

Кеңестер мен амалдарды қорытындылаңыз

1. Жаһандық айнымалылардан аулақ болыңыз.
2. Префикс рөлдік айнымалылар.
3. Циклды басқару айнымалысын пайдаланыңыз.
4. Енгізілетін айнымалы мәндерді тексеріңіз.
5. Хэш сөздіктерінен аулақ болыңыз, тегіс құрылымды пайдаланыңыз.
6. Идемпотентті ойын кітаптары мен рөлдерді жасаңыз.
7. Пәрмен қабықшасының модульдерін пайдаланудан аулақ болыңыз.
8. Рөлдеріңізді молекула арқылы тексеріңіз.
9. Күрделі логиканы модульдер мен плагиндерге салыңыз.

қорытынды

Сізде IaC болса да, сіз жай ғана барып, жобадағы инфрақұрылымды қайта өңдей алмайсыз. Бұл шыдамдылықты, уақытты және білімді талап ететін ұзақ процесс.

сілтемелер

• слайдтар Ansible-ді қалай сынауға болады және жаңғақ болмаңыз
• Бейне Ansible-ді қалай сынауға болады және жаңғақ болмаңыз
• Инфрақұрылымдық кодтың 200 000 жолын сынаудан не білдім
• Ansible: 120 айда 18 VM конфигурациясын Coreos-тан Centos-қа көшіру
• Таратуды сынау кезінде велосипедтерді балдақпен қалай бұзуға болады
• Мені сынап көріңіз, егер сіз YML бағдарламашылары Ansible сынауды армандай аласыз ба?
• Керемет IaC тестілеу мақалаларының, баяндамалардың және сілтемелердің тізімі
• көлденең пост
• ағылшын нұсқасы

UPD1 2020.05.01 20:30 — Ойын кітаптарын бастапқы профильдеу үшін пайдалануға болады callback_whitelist = profile_tasks ұзақ уақыт бойы нақты не жұмыс істейтінін түсіну үшін. Содан кейін біз өтеміз Ансибльді акселерация классикасы. Көруге болады митоген
UPD2 2020.05.03 16:34 - ағылшын нұсқасы

Ақпарат көзі: www.habr.com