Автоматизируем и ускоряем процесс настройки облачных серверов с Ansible. Часть 2: вывод, отладка, и повторное использование playbook

    В предыдущей статье мы начали изучение Ansible, популярного инструмента для автоматизации настройки и развертывания ИТ-инфраструктуры. Ansible был успешно установлен в InfoboxCloud, описаны принципы работы, базовая настройка. В завершении статьи мы показали как быстро установить nginx на несколько серверов.
    Ansible InfoboxCloud
    В этой статье мы продолжим изучение Ansible: разберем вывод playbook, научимся отлаживать их и разделять для удобства повторного использования.

    Управление конфигурациями


    Разбор нашего первого playbook

    В прошлой статье мы получили вывод от исполнения нашего первого playbook. Давайте разберем его.



    Gathering facts – это первая задача по умолчанию в любом playbook. Задача собирает полезные метаданные о серверах в форме переменных, которые могут использоваться в playbook в дальнейшем. Например, такими переменными может быть ip–адрес, архитектура ОС и имя хоста.
    Можно посмотреть эти переменные, используя команду:
    ansible -m setup experiments
    
    , где experiments – название секции в вашем inventory.
    или записать ее в файл
    ansible -m setup experiments >> facts
    

    Ниже в выводе указаны задачи TASK, согласно ходу выполнения playbook: установка nginx, запуск сервиса.

    Давайте запустим выполнение playbook повторно.
    ansible-playbook playbooks/setup_nginx.yml
    



    По сравнению с предыдущим выводом задача Install nginx package выполнена без изменений. Состояние уже достигнуто: nginx установлен. Задача старта сервиса nginx в обоих случаях выполнена без изменений, так как сервис nginx стартует сам сразу после установки. Если остановить сервис nginx на одном из серверов вручную, после запуска playbook он поднимется.



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

    Давайте посмотрим на секцию PLAY RECAP ниже в выводе. Параметр changed показывает, сколько раз в задачах менялось состояние сервера. ok – количество исполняемых задач вместе с Gathering facts.

    Oтладка playbook

    Понимать, что случилось при исполнении playbook, бывает очень полезно для исправления ошибок.
    Есть 3 уровня вывода отладочной информации (Verbose).

    -v. Вывод базовой информации.
    ansible-playbook playbooks/setup_nginx.yml -v
    



    -vv. Более подробный вывод.
    ansible-playbook playbooks/setup_nginx.yml -vv
    



    -vvv. Самый подробный вывод.
    В этом выводе указаны SSH–команды, которые Ansible использует для создания временных файлов на удаленном хосте для запуска скрипта удаленно.
    ansible-playbook playbooks/setup_nginx.yml -vvv
    



    Можно выводить любые переменные ansible для отладки. Для этого добавьте в playbook следующую секцию:
     - name: Debug
        debug: msg={{ ansible_distribution }}
    

    При запуске playbook вы увидите вывод этой переменной. Каждая переменная Ansible начинается с префикса ansible_.



    Еще одна полезная команда — возможность посмотреть на все задачи, выполняющиеся в playbook. Она особенно полезна, когда есть несколько playbook, исполнающих другие playbook.

    ansible-playbook playbooks/setup_nginx.yml --list-tasks
    



    Можно исполнить только конкретную задачу из playbook:
    ansible-playbook playbooks/setup_nginx.yml --start-at-task="Debug"
    



    Повторное использование в Playbook


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

    Создайте папку для повторно используемых задач:
    mkdir ~/ansible/playbooks/tasks
    

    Давайте создадим задачу обновления ОС в файле ~/ansible/playbooks/tasks/os_update.yml:
    ---
    #Update and upgrade apt-based linux
    - name: Update and upgrade apt-based Linux
      apt: update-cache=yes state=latest
      sudo: yes
    

    Tеперь мы можем включить секцию обновления ОС в ~/ansible/playbooks/setup_nginx.yml:
    ---
    - hosts: experiments
      remote_user: root
      tasks:
    
      - include: tasks/os_update.yml
    
      - name: Install nginx package
        apt: name=nginx update_cache=yes
        sudo: yes
    
      - name: Starting nginx service
        service: name=nginx state=started
        sudo: yes
    

    Теперь до установки nginx Ubuntu на обслуживаемых серверах из Inventory будет обновлена.
    Стоит и установку nginx (~/ansible/playbooks/tasks/pkg_nginx_install.yml) вынести в отдельную задачу, если вы часто ставите nginx.
    ---
    #Install NGINX package
      - name: Install nginx package
        apt: name=nginx update_cache=yes
        sudo: yes
    
      - name: Starting nginx service
        service: name=nginx state=started
        sudo: yes
    

    В результате наш playbook станет совсем простым:
    ---
    - hosts: experiments
      remote_user: root
      tasks:
    
      - include: tasks/os_update.yml
      - include: tasks/pkg_nginx_install.yml
    

    Можно написать и задачу для удаления nginx (~/ansible/tasks/pkg_nginx_remove.yml):
    ---
    #Remove NGINX package
     - name: Stopping nginx service
       service: name=nginx state=stopped
       sudo: yes
    
     - name: Remove nginx package
       apt: name=nginx state=removed
       sudo: yes
    

    и вызвать ее (~/ansible/playbooks/remove_nginx.yml):
    ---
    - hosts: experiments
      remote_user: root
      tasks:
      - include: tasks/pkg_nginx_remove.yml
    

    ansible-playbook ~/ansible/playbooks/remove_nginx.yml -i ~/ansible/inventory
    

    , где через -i указываем путь к файлу inventory, что позволяет нам запускать ansible-playbook не только из папки ansible.

    В следующей статье мы поговорим о переменных и условиях Ansible. Наконец-то наши playbook будут корректно работать на разных ОС.

    Заключение


    В написании статьи очень помогла книга "Learning Ansible" и конечно официальная документация.

    Все эксперименты с Ansible удобно делать в InfoboxCloud, так как имеется возможность для каждого виртуального сервера установить именно то количество ресурсов, которое необходимо для задачи (CPU/Ram/диск независимо друг от друга) или использовать автомасштабирование.

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

    Часть 3: Переменные и файл inventory
    Часть 4: работаем с модулями
    Часть 5: local_action, условия, циклы и роли

    Успешной работы!
    • +7
    • 15.3k
    • 9
    Infobox
    34.76
    Company
    Share post

    Comments 9

    • UFO just landed and posted this here
        0
        Дойдем еще до ролей :)
        0
        Как выше написали для повторного использования надо роли делать, да и вообще если там задача не уровня apt-get update, то надо role делать, по тому что потребуется какой-никакой конфиг, надо будет перегонять файлы с настройками на сервер и так далее.

        А для отладки, надо vmware или virtualbox использовать.
          0
          У меня нубский вопрос. Например, я для конфигурирования машин в aws ec2 использую puppet. Каждый раз, когда поднимается новая машина, она самостоятетельно идет к puppet master'у и выписывает у него свою актуальную конфигурацию. Как этого можно добиться с ansible? Я видел, что там есть некий ansible pull. Но как я понял, он тупо копирует себе весь репозиторий (даже с теми деталями, которые конкретной машине видеть не желательно).
          Как, вообще, в случае с ansible принято осуществлять провижонинг машин, которые скейлятся автоматически?
            +1
            У вас же машина поднимается посредством ваших скриптов? Почему бы этими же скриптами не запускать с управляющей машины плейбук провижининга против нового хоста?
              0
              Мде… О самом очевидном варианте я и не подумал. Спасибо. Единственное, что меня смущает — невозможность со стороны (т.е., с машины, которая запускает новый инстанс) понять, готов инстанс провижониться, или еще нет. Получается, что остается только ломиться ansible'ом на этот инстанс до тех пор, пока он-таки не примет соединение?
              0
              есть такая штука — ansible-pull
              он идет в гит, читает оттуда playbook и выполняет на локальной машине.
                0
                Это я видел, да (я, собственно, упомянул его в оригинальном вопросе). Суть в том, что я не хочу, чтобы автоскейлящиеся машины выписывали себе весь репозиторий. Там же могут быть достаточно эрогенные данные, которые конкретно этому инстансу видеть не следует.
                  0
                  Ну мне кажется решить это не сложно — у меня в AMI прописана роль сервера в /etc/ansible/hosts
                  ansible-pull получает репозиторий, запускает то, что релевантно для этой роли сервера, а втот то, что он запускает ужев может идти в какое то специфичное место (отдельный репозиторий например) чтобы получить что то, что только ему можно увидеть.

                  У нас, просто, этой проблемы нет — на всех серверах бежит наш код, мы ничего от них не скрываем :)

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