Как начать тестировать Ansible, отрефакторить проект за год и не слететь с катушек


    Это расшифровка выступления на DevOps-40 2020-03-18:


    Начиная со второго коммита любой код становится legacy, т.к. изначальные задумки начинают расходиться с суровой реальностью. Это не хорошо и не плохо, это данность с которой сложно спорить и необходимо уживаться. Частью этого процесса является рефакторинг. Рефакторинг Infrastructure as Code. Да начнется история как отрефакторить Ansible за год и не слететь с катушек.


    Зарождение Legacy


    День № 1: Нулевой пациент



    Жил был условный проект. На нем была Dev команда разработки и Ops инженеры. Они решали одну и ту же задачу: как развернуть сервера и запустить приложение. Проблема была в том, что каждая команда решала эту задачу по своему. На проекте было принято решение использовать Ansible для синхронизации знаний между командами Dev и Ops.


    День № 89: Зарождение Legacy



    Сами того не заметив, хотели сделать как можно лучше, а получилось legacy. Как так получается?


    • У нас тут срочная таска, сделаем грязный хак — потом исправим.
    • Документацию можно не писать и так всё понятно что тут происходит.
    • Я знаю Ansible / Python / Bash / Terraform! Смотрите как я могу извернуться!
    • Я Full Stack Overflow Developer скопировал это со 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: Подготовка рефакторинга



    Первоочерeдное это надо подготовиться. Определиться что будем делать. Для этого общаемся, находим проблемные точки и прикидываем пути их решения. Полученные концепты как-то фиксируем, например статья в confluence, что бы при появление вопроса "как лучше?" или "как правильнее?" мы не сбились с курса. В нашем случае мы придерживались идеи разделяй и властвуй: дробим инфраструктуру на маленькие кусочки / кирпичики. Такой подход позволяет взять изолированный кусок инфраструктуры, понять что он делает, покрыть его тестами и изменить не побоявшись что-нибудь сломать.



    Получается, что тестирование инфраструктуры становится краеугольным камнем и тут стоит упомянуть пирамиду тестирования инфраструктуры. Ровно таже идея, что в разработке, но для инфраструктуры: идем от дешевых быстрых тестов которые проверяют простые вещи, например отступы, к дорогим полноценным тестами разворачивающих цельную инфраструктуру.


    Попытки тестирования Ansible


    Прежде чем пойдем описывать как покрывали тестами Ansible на проекте, опишу попытки и подходы которые довелось использовать ранее, что бы понять контекст принимаемых решений.


    День № -997: SDS provision


    Первый раз тестировать Ansible довелось на проекте по разработке SDS (Software Defined Storage). Есть отдельная статья на эту тему
    Как наломать велосипедов поверх костылей при тестировании своего дистрибутива, но если кратко, то у нас получилась перевернутая пирамида тестирования и тестирование мы тратили 60-90 минут на одну роль, что есть долго. Основа была e2e тесты, т.е. мы разворачивали полноценную инсталляцию, и потом ее тестировали. Еще отягчающим было изобретение своего велосипеда. Но надо признаться это решение работало и позволяло стабильно релизиться.


    День № -701: Ansible и test kitchen


    Развитием идеи тестирования Ansible стало использование готовых инструментов, а именно test kitchen / kitchen-ci и inspec. Выбор был обусловен знанием Ruby ( подробней в статье на хабре: Мечтают ли YML программисты о тестировании ansible?) работало быстрее порядка 40 минут на 10 ролей. Мы создавали пачку виртуальных машин и внутри гоняли тесты.



    В целом решение работало, но был осадочек из-за неоднородности. Когда же увеличили количество тестируемых до 13 базовых ролей и 2 мета ролей комбинирующие более мелкие роли, то вдруг тесты стали бежать 70 минут, что почти в 2 раза дольше. Об XP (extreme programming) практиках было сложно говорить т.к. никто не захочет ждать 70 минут. Это стало подоводом для изменения подхода


    День № -601: Ansible и molecule


    Концептуально это похоже на testkitchen, только мы перевели тестирование ролей в docker и сменили стэк. Итогом, время сократилось до стабильных 20-25 минут для 7 ролей.



    Увеличив количество тестирумых ролей до 17 и линтовку 45 ролей мы прогоняли это за 28 минут на 2 jenkins slave.


    День № 167: Добавляем на проект тесты Ansible



    С наскоку задачу рефакторинга, скорей всего сделать не получится. Задача должна быть измеримой, что бы вы могли ее разбить на мелкие кусочки и съесть слона по частям чайной ложкой. Должно быть понимание в правильном ли вы направлении идет движение, долго ли еще идти.



    В целом не суть важно как это будет сделано, можно писать на бумажку, можно клеить стикеры на шкаф, можно создавать таски в jira, а можно завести google docs И туда записывать текущий статус. Ноги растут из того, что процесс не сиюминутный, он будет долгий и нудный. Маловероятно, что кто-то хочет, что бы за время рефакторинга вы перегорели идей, устали и забили.


    Рефакторинг прост:


    • Eat.
    • Sleep.
    • Code.
    • IaC test.
    • Repeat

    и так повторяем пока не достигнем намеченной цели.



    Все сразу начать тестировать может не получится, поэтому у нас первой задачей было начать с линтовки и проверки синтаксиса.


    День № 181: Green Build Master



    Линтовка это небольшой первый шаг к Green Build Master. Это почти ничего не сломает, но позволит отладить процессы и сделать зелененькие билды в jenkins. Идея в том, что бы выработать привычки у команды:


    • Красные тесты плохо.
    • Пришёл исправить что-то заодно сделай код чуть лучше, чем он был до тебя.

    День № 193: От линтовки к unit тестам



    Выстроив процесс попадания кода в мастер можно начинать процесс поэтапного улучшения — заменяя линтовку на запуск ролей, можно даже без идемпотентности. Необходимо понять как применять роли, как они работают.


    День № 211: От unit к integration тестам



    Когда unit тестами покрыто большинство ролей и всё линтуется, можно переходит к добавлению интеграционных тестов. Т.е. тестированию не отдельного кирпичика в инфраструктуре, а их комбинации, например полноценную конфигурацию инстанса.



    На jenkins мы генерировали множество стадий, которые в параллель линтовали роли / плэйбуки, потом юнит тесты в контейнерах и в конце интеграционные тесты.


    Jenkins + Docker + Ansible = Tests



    1. Checkout repo and generate build stages.
    2. Run lint playbook stages in parallel.
    3. Run lint role stages in parallel.
    4. Run syntax check role stages in parallel.
    5. Run test role stages in parallel.
      1. Lint role.
      2. Check dependency on other roles.
      3. Check syntax.
      4. Create docker instance
      5. Run molecule/default/playbook.yml.
      6. Check idempotency.
    6. Run integration tests
    7. Finish

    День № 271: Bus Factor



    Первое время рефакторингом занималась небольшая группа людей в пару-тройку человек. Они делали ревью кода в мастерe. Со временем в команде вырабатолось знание как писать код и code review способствовало распространению знаний об инфраструктуре и том как она устроена. Изюминкой здесь было, то что ревьюверы выбирались по очереди, по графику, т.е. с некоторой долей вероятности ты залезешь в новый участок инфраструктуры.



    И здесь должно быть удобно. Удобно делать ревью, видеть в рамках какой задачи оно сделано, историю обсуждений. Мы интегрировали 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. Переход на docker.
    2. Убрать тестирование ролей, которое дублируется за счет зависимостей.
    3. Увеличить кол-во слэйвов.
    4. Порядок запуска тестов.
    5. Возможность линтовать ВСЁ локально одной командой.


    В итоге Pipeline на jenkins тоже унифицировался


    1. Generate build stages.
    2. Lint all in parallel.
    3. Run test role stages in parallel.
    4. Finish.

    Lessons learned


    Avoid global variables


    Ansible использует глобальные переменные, есть частичный workaround в виде 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 и лучшее что можно сделать, то использовать какие-то договоренности, например внутри роли использовать только переменную описанные в этой роли.


    BAD: использовать глобальную переменную.


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

    GOOD: В 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
    

    Prefix role variables


    BAD: использовать глобальную переменную.


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

    GOOD: В роли для переменных использовать переменные с префиксом имени роли, это посмотрев на inventory позволит проще понять что происходит.


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

    Use loop control variable


    BAD: Использовать в циклах стандартную переменную item, если этот таск/плэйбук будет где-то заинклюдан то это может привести к непредвиденному поведению


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

    GOOD: Переопределять переменную в цикле через loop_var.


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

    Check input variables


    Мы договорлись использовать префиксы переменных, не будет лишним проверить что они определены как мы ожидаем и, например, не были перекрыты пустым значением


    GOOD: Проверять переменные.


    - 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

    Avoid hashes dictionaries, use flat structure


    Если роль ожидает hash/dictionary в одному из параметров, то если мы захотим поправить один из дочерних параметров, нам надо будет переопределять весь hash/dictionary, что повысит сложность конфигурирования.


    BAD: Использовать hash/dictionary.


    ---
    user:
      name: admin
      group: admin

    GOOD: Использовать плоскую структуру переменных.


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

    Create idempotent playbooks & roles


    Роли и плэйбуки должны быть идемпотентными, т.к. уменьшает configuration drift и страх сломать что-то. Но если вы пользуете molecule, то это поведение по умолчанию.


    Avoid using command shell modules


    Использование shell модуля приводит к императивной парадигме описания, вместо декларативной, которая является основной Ansible.


    Test your roles via molecule


    Molecule позволяет весьма гибка штука, давай посмотрим несколько сценариев.


    Molecule Multiple instances


    В 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 verifier


    В molecule есть возможность использовать 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

    Или развернуть сервис, дождаться его доступности и сделать smoke test:


    ---
      - 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

    Put complex logic into modules & plugins


    Ansible проповедует декларативный подход, поэтому когда вы делаете ветвление кода, трансформацию данных, shell модули, то код становится сложно читаемым. Что бы побороться с этим и оставить его простым для понимания, не будет лишним, бороться с этой сложностью путём создания своих модулей.


    Summarize Tips & Tricks


    1. Avoid global variables.
    2. Prefix role variables.
    3. Use loop control variable.
    4. Check input variables.
    5. Avoid hashes dictionaries, use flat structure.
    6. Create idempotent playbooks & roles.
    7. Avoid using command shell modules.
    8. Test your roles via molecule.
    9. Put complex logic into modules & plugins.

    Заключение



    Нельзя просто так взять и отрефакторить инфраструктуру на проекте, даже если у вас IaC. Это долгий процесс требующий терпения, времени и знаний.




    UPD1 2020.05.01 20:30 — Для первичного профилирования плэйбуков можно использовать callback_whitelist = profile_tasks что бы понять что именно долго работает. После чего проходимся по классике ускорения ansible. Можно попробовать mitogen
    UPD2 2020.05.03 16:34English version

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 28

      0
      Спасибо за статью! Molecule это очень большое спасение для всех нас при тестировании ролей Ansible. У меня вопрос. Все роли у вас выполняют конфигурацию конечных хостов? то есть тестирование = запуск ВМ и раскатка ролей последовательно, зависимо от типа ОС накатывая конфиги и все что требуется для работы хоста я так понял? теперь вопрос — представьте я решил написать роль для автоматизации задачи «ежедневного резервного копирования» и разумеется моя роль/роли перед элементарным копированием бэкапа на хост-назначение выполнятет на хосте-целе куда я травлю свою роль задачи по подготовке к резервному копированию (к примеру gitlab-backup create) и на каждом хосте это свои подготовки. Как тестировать через Molecule такую роль? добавить check_mode не вариант же теряется смысл в тестировании. Может есть дельный совет?
        0
        Все роли у вас выполняют конфигурацию конечных хостов?

        не всегда так. есть базовые/generic роли: поставить java, application сервер, solr. Есть роли которые комбинирует эти кирпичики вместе строя полноценную конфигурацию сервера. Это уже больше похоже на конфиг конечного хоста. но все равно потом в host_vars, например, может приехать кастомизация.


        то есть тестирование = запуск ВМ и раскатка ролей последовательно, зависимо от типа ОС накатывая конфиги и все что требуется для работы хоста я так понял?

        зависит от. в большинстве проектов прижилась схема:


        1. линтуем все что можно
        2. если все ок, проверяем каждую роль по отдельности в docker
        3. если все ок, проверяем на виртуалках выборочно что-то

        идея в том, что бы укоротить feed back loop.


        теперь вопрос — представьте я решил написать роль для автоматизации задачи «ежедневного резервного копирования»
        Как тестировать через Molecule такую роль? добавить check_mode не вариант же теряется смысл в тестировании. Может есть дельный совет?

        я бы тут задал вопрос почему ansible для такой задачи? Поясню: сложно положить такую задачу на декларативную парадигму ansible если честно, т.к. это скорей всего потянет за собой написание модуля со сложной логикой какой-то и у этого модуля будет какой-то другой процесс тестирования. в ансибловом коде народ так вобще мокает какая команда в консоли должна запуститься. с тестированием модулей я пока в творческом поиске.

          0
          почему ansible для такой задачи?

          Почему-то все вкладывают в IaC только задачи разворачивания и обновления инфраструктуры. Но в моем понимании у инфраструктуры есть еще и регулярные задачи, которые неплохо бы тоже хранить как код: резервное копирование, обновление правил фаервола, блокировка/изменение пользователей на машинах (там где нет SSO) и т.д.
          Ну в моем конкретном примере есть какой-то простой инструмент для создания ежедневной копии (к примеру borg), и я вместо создания на каждом хосте скрипта с кроном решил описать все на ansible и выполнять эту задачу с одной точки. Плюсы: секрет в одном месте и простая конфигурация из одной точки. В какую парадигму это вписать, это скорее филосовский вопрос, но пока что мне не пришлось использовать модули со сложной логикой, все максимально просто.
            0

            звучит логично и ризонно. а можно где-то глянуть пример?

              0
              Я отвечу как большинство отвечает, тут публикующихся) я не готов выложить в открытый доступ, но подготовлю часть кода и опубликую обязательно. Спасибо за ответы!
                0

                Будет что показать — глянул бы

              0
              я вместо создания на каждом хосте скрипта с кроном решил описать все на ansible и выполнять эту задачу с одной точки

              ???


              Лишняя централизация — это зло. На самом деле надо подбирать инструмент под задачи и соответственно — вариант systemd-timer + скрипт, который разливается ансиблом может быть сильно лучше, чем полный бекап в виде отдельного плейбука.


              Почему-то все вкладывают в IaC только задачи разворачивания и обновления инфраструктуры. Но в моем понимании у инфраструктуры есть еще и регулярные задачи, которые неплохо бы тоже хранить как код: резервное копирование, обновление правил фаервола, блокировка/изменение пользователей на машинах (там где нет SSO) и т.д.

              Несомненно. Но тут надо разграничить — мы храним это все как условные настройки в репозитории с кодом IaC, которые разливаются на машины, или мы используем отдельные скрипты вне этого процесса, но в рамках более широкого понимания инфры как живого организма.
              Поделюсь болью. В рамках, например, salt это все реализуется при помощи встроенной шины сообщений и встроенных примитивов для этого, но сложность их отладки и проверки на порядок выше, чем просто "давайте накатим плейбук или стейт" и "посмотрим молекулой или кухней, что там получилось" — т.к. надо либо писать юнит-тесты, либо поднимать полную копию инфру и на ней отлаживать эту событийную модель :-/

                0

                а это теоретические выкладки как тестить или были попытки реализовать? есть примеры куда можно глянуть?

                  0

                  Это вы мне ответьте — зачем излишне централизовать то же создание бекапов? И делать некий контроллер для запуска ансибла?
                  Вы же ведь наверняка не используете AWX / Tower? Или пускалкой бекапов становится Дженкинс?

                    0

                    Про бэкапы это в соседний трэд. Касательно централизованности запуска ансибла:


                    1. Логирование действий
                    2. Воспроизводимость окружения и версий что запускаем
                      0

                      2-я проблема решается путем засовывания ансибла в докер образ :-) и написанием четкой инструкции как его применять.
                      1-я проблема — согласен. Но тогда теряется вся прелесть ансибла, т.к. он не умеет в сервер-клиент (в отличие от настоящих паппетов-chef'ов-salt'ов) — коли уж централизоваться, так по полной.


                      Мое мнение — ансибл прекрасен для первоначальной настройки или использования в пайпах. Управлять же им флотом машин, изменениями в конфигурации. Брррр

                        0
                        ???

                        Лишняя централизация — это зло. На самом деле надо подбирать инструмент под задачи и соответственно — вариант systemd-timer + скрипт, который разливается ансиблом может быть сильно лучше, чем полный бекап в виде отдельного плейбука.

                        Зачем усложнять крон? В случае с одной точкой у вас есть сразу результат вашего бэкапа, в случае с отдельными скриптами у вас куча скриптов и наверное в случае фейла вы с каждым хостом будете разбираться отдельно. И важный момент у меня шифруется хранилище — ключ в одном месте а не на каждом хосте. Я могу менять свой ключ каждые 2 минуты.
                        Несомненно. Но тут надо разграничить — мы храним это все как условные настройки в репозитории с кодом IaC, которые разливаются на машины, или мы используем отдельные скрипты вне этого процесса, но в рамках более широкого понимания инфры как живого организма.

                        IaC это подход для управления и описания инфраструктуры ЦОД через конфигурационные файлы

                        То есть и управления тоже
                        Поделюсь болью. В рамках, например, salt это все реализуется при помощи встроенной шины сообщений и встроенных примитивов для этого, но сложность их отладки и проверки на порядок выше, чем просто «давайте накатим плейбук или стейт» и «посмотрим молекулой или кухней, что там получилось» — т.к. надо либо писать юнит-тесты, либо поднимать полную копию инфру и на ней отлаживать эту событийную модель :-/

                        Может тут как раз неверно выбран инструмент? если нельзя мокать или тестить без моков хотя бы часть функционала, то эти конфиги превратятся в legacy скорее — к ним все будут бояться подойти и тем более изменить. но это мое мнение
                        Мое мнение — ансибл прекрасен для первоначальной настройки или использования в пайпах. Управлять же им флотом машин, изменениями в конфигурации. Брррр

                        Вы серъезно считаете что ансибл используется ТОЛЬКО для первоначальной настройки? зачем тогда ансибл? пишите файлы-ответы! как управлять парком в 50 серверов без централицазии? я могу получить состояние обновление всего парка в течении 10 минут. А вы?
                        Вы же ведь наверняка не используете AWX / Tower? Или пускалкой бекапов становится Дженкинс?

                        Использую AWX, командная строка чаще, иммел проблемы при его обновлении — руками приходилось править миграции он свободный сейчас лучше чем раньше
                          0
                          Вы серъезно считаете что ансибл используется ТОЛЬКО для первоначальной настройки?

                          нет, но это, что у него получается лучше всего (в packer, например, или в terraform). Иначе у нас извините не иммьютейбл инфра, а черти-знает-что.


                          пишите файлы-ответы!

                          LOL


                          я могу получить состояние обновление всего парка в течении 10 минут. А вы?

                          если инфра имьютейбл — это есть на стороне провайдера. Ну, в своей легаси инфре — да, я могу это сделать за 10 минут. И еще — ансибл у вас на сколько узлов скейлится — 100-1000-10000?


                          В случае с одной точкой у вас есть сразу результат вашего бэкапа, в случае с отдельными скриптами у вас куча скриптов и наверное в случае фейла вы с каждым хостом будете разбираться отдельно.

                          зато отдельная проблема — обеспечить отказоустойчивость этой самой точки + доступ ко всем узлам (они не смогут теперь автономном функционировать) + идемпотентность алгоритма и устойчивость его к перезапускам и локи на повторные запуски на всякий случай. Ну, что ж — каждому по велосипеду. Своему. Лучшему. Который ты лучше всего знаешь и можешь саппортить.

                            0
                            нет, но это, что у него получается лучше всего (в packer, например, или в terraform). Иначе у нас извините не иммьютейбл инфра, а черти-знает-что.

                            Вы как-то все в одну кучу) Причем здесь иммьютейбл, как этот подход связан с IaC? каждый раз при обновлении к примеру nginx — сносите все и разворачиваете новую инфру с одним измененным компонентом?
                            И еще — ансибл у вас на сколько узлов скейлится — 100-1000-10000?

                            да на любое количество, под любой тип ОС все верно у ансибл это неплохо получается.
                            зато отдельная проблема — обеспечить отказоустойчивость этой самой точки + доступ ко всем узлам (они не смогут теперь автономном функционировать) + идемпотентность алгоритма и устойчивость его к перезапускам и локи на повторные запуски на всякий случай.

                            нет проблемы в отказоустойчивости — нужна любая машина с ansible все. Доступ ко всем узлам с одного узла а не с 1000 машин, не вижу проблем — машина в DMZ. Повторяемость и локи решаются правильным написанием роли. Может я и не прав, так укажите где, в чем это Велосипед? я попытаюсь понять, в чем я не прав. Какой подход использовать?
                              0
                              каждый раз при обновлении к примеру nginx — сносите все и разворачиваете новую инфру с одним измененным компонентом?

                              если надо обновить версию пакета — почему нет. Можно пересобрать "золотой образ" и перелить сервера. Потому что иначе вы получаете почти наверняка "хвосты" в системе + configuration drift. Понятно, что такое можно проворачивать дешево только в случае, если среда построена на ВМках. На bare metal полностью делать провижионинг — больно и дорого.


                              А конфиги… Ну, с конфигами ПО все интереснее. Есть разные подходы к их доставке в зависимости от того, как часто они меняются.


                              В общем — все зависит от того, что уже есть, какие требования выдвигаются и прочее-прочее. Универсального решения нет.


                              Провокационный вопрос — Вы в своих ролях четко обрабатываете ситуации обновления пакета с произвольной версии на произвольную версию и миграции между самими версиями ролей? Честно — вот почти наверняка нет. И в целом при иммутабельном подходе это и не нужно в общем.


                              нет проблемы в отказоустойчивости — нужна любая машина с ansible все.

                              а я утверждаю, что есть. У вас сдохла машина с запущенным ансибл — дальше что будет происходить? Все плейбуки поотваливаются в процессе работы? Статусы play'ев сможете получить? Я что-то очень сомневаюсь.


                              Повторяемость и локи решаются правильным написанием роли.

                              с этим я согласен. И строго за это агитирую. Но это уже выходит за рамки большинства ролей, которые свободно доступны с гитхаба.

                              0

                              у меня хорошо для ansible заходит:


                              1. packer + ansible
                              2. конфигурирование вм
                              3. конфигурирование клиентских инсталляций когда нет админских прав на целевой системе и air gap до кастомеров

                              не очень заходит:


                              1. создание вм на винде, ну и фиг
                              2. создание вм на vmware, не очень удобное и долго, но зато в одном месте все.
                              3. создание контейнеров ansible-container пробовал — не зашел. хочу попробовать ansible bender. не идет но очень бы хоетлось
                                0

                                Спасибо, это хороший список. Никаких возражений по нему у меня нет.
                                Могу добавить, что ещё заходит


                                1. Разнообразная автоматизация, но без фанатизма.
                                2. Пайплайны разработки — развернуть что-либо на разных целевых платформах — от вм до кубернетеса. В каком-то смысле для этой цели ансибл лучше подходит, чем специализированные решения вроде helm. В том числе и благодаря широкому спектру модулей и встроенного шаблонизатора.
                                3. Как вырожденный вариант #2 — как замена docker-compose (собрать, запустить контейнеры, потушить их после тестов или цикла разработки).

                                создание вм на vmware, не очень удобное и долго, но зато в одном месте все.

                                А что Вы используете — нативные штуки от вмвари или terraform?

                                  0

                                  Vra пока будем смотреть. С терраформ вопросы есть: не понятно где Стэйт хранить нам, пс вариантов конфигов вм ну очень много и все их выпекать тяжко будет. Плюс обсуждается переезд большинства линуксовых вм в k8s

                                    0

                                    кстати, насчет кейсов, еще был один который не очень полетел — ansible как шаблонизатор для k8s/openshift. работать работает, но есть чувство создания велосипедов

                              0

                              пока вместо докера:


                              1. ansible роль как настроить окружение
                              2. модули какие есть сложили в мета-роли и они лежат в репе инклюдаясь в нужных ролях

                              для визуализации есть https://github.com/ansible-community/ara но у нас не пошло как то

                      +1
                      В целом, так делать никто не запрещает, но у разработчиков такое называется «протекание абстракций». Лучше когда полезная нагрузка выполняется хостами, без участия Ansible. А Ansible используется только по назначению: изменение конфигурации.

                      Секреты, если они критичны, лучше чтобы были хост-персональны. Это, конечно, требует доп. усилий, но тут уж «шашечки или ехать».
                        –1
                        В целом, так делать никто не запрещает, но у разработчиков такое называется «протекание абстракций». Лучше когда полезная нагрузка выполняется хостами, без участия Ansible. А Ansible используется только по назначению: изменение конфигурации.

                        Ansible запускает задачи подготовки копирования и задачи пуша бэкапа. Полезную нагрузку выполняют хосты, а не машина с ansible. Я в данном случае могу контролировать полностью какой архив бэкапа, в каком порядке и на какой скорости ложить в хранилище, а по завершению копирования получить статус по каждой машине. Поясните, что в данном случае является абстракцией и почему она течет?
                        Секреты, если они критичны, лучше чтобы были хост-персональны. Это, конечно, требует доп. усилий, но тут уж «шашечки или ехать».

                        Они хост-персональны, но хранятся не на хостах.
                          +1
                          Примерно как водитель автобусов и конструктор автобусов.
                          Задача конструктора автобуса сделать удобный и практичный автобус.
                          Задача водителя регулярно перевозить людей из одной точки в другую.
                          Если вдруг так получилось, что вышел водитель на работу или нет, целиком и полностью зависит от конструктора, то что-то в этом не так.
                          При этом зависимость водителя от конструктора все таки есть. От конструктора напрямую зависит каким будет автобус. Но в поле все зависит только от водителя. Что делает в этот момент конструктор — неважно.

                          Если вернуться к нашему кейсу с бекапами, то если ansible-хост недоступен, и из-за этого бекапы не пишутся, это уязвимая схема. Ansible нужен только в момент настройки, чтобы донести до целевого хоста нужные секреты, поднять кроны, положить скрипты, убедиться что все ок. А дальше все зависит только от самого целевого хоста.
                            0
                            Я, несмотря на ваш последующий минус, и в этот раз вам отвечу, хоть и не вижу в этом смысла. Конструкор этого автобуса — я и водитель — хост, который сам выполняет задачу копирования (исполнение обязательств по доставке пассажиров). Если водитель не выйдет на работу по моей вине, или автобус сломается — я буду оповещен об этом мониторингом и ничего критичного не произойдет, я учту ошибки, исправлю и применю исправление ко всем автобусам, чтобы не повторилась ситуация. Важнее мысль, что не только я могу исправить эти ошибки, а благодоря моей документации (IaC) любой конструктор сможет это сделать и без меня.
                              0

                              Все напрашивается картинка "троллейбус из буханки".
                              Касательно IaC. У нас разный подход. И такое ощущение, что у Вас происходит подмена понятия. Описание того, как разложить скрипт бекапа по машинам — IaC? Скорее да. А вот сам скрипт бекапа является ли элементом IaC?? Ну, это явно код. Только вот он не совсем инфраструктурный. Так какой же? Прикладной? Да вроде бы и нет тоже. Где-то посерединке. Такой вот клей между слоями. И, конечно, он может быть в основной инфраструктурной репе. Точно так же как там могут лежать деб пакеты, целиковые скрипты и прочее, что обычно считается "артефактами". Только вот удобно ли использовать Ваш подход и является ли он "чистым" с идеологической точки зрения — это отдельный вопрос.

                                0
                                Давайте абстрагируемся от резервной копии и попробуем на примере ИБ. Разложить и сконфигурить правила фаерволла тогда для вас — IaC? скорее да. Только вы это делаете 1 раз? при разворачивании ОС? — скорее нет. Я не вижу необходимости разворачивать занаво хост после изменения 1 правила в netfilter. IaC — описание и управление инфраструтктурой.

                                А по поводу «артефакты» — это файл-результат сборки или этапа сборки, деб пакет будет результатом сборки, к примеру, репа с исходниками и debian инструкциями. Не вижу аналогии с сохранением в репозитории ansible-playbook, задача которого — выполнять регулярные задания.
                                  0

                                  Я к чему — не нужно пытаться видеть во всем ансибл. А то это похоже на хирурга — а чего — у пациента болит рука — давайте ее отрежем.


                                  Давайте абстрагируемся от резервной копии и попробуем на примере ИБ. Разложить и сконфигурить правила фаерволла тогда для вас — IaC? скорее да. Только вы это делаете 1 раз? при разворачивании ОС? — скорее нет. Я не вижу необходимости разворачивать занаво хост после изменения 1 правила в netfilter. IaC — описание и управление инфраструтктурой.

                                  настройка файрволла — управление
                                  запуск РК — нет (это не является изменением в конфигурации)
                                  окей — вы хотите оркестрировать, т.е. быть дирижером по сути — но это задача ортогональная к IaC.

                  +1

                  Only users with full accounts can post comments. Log in, please.