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

    Ansible – популярный инструмент для автоматизации настройки и развертывания ИТ-инфраструктуры.

    Основные задачи, которые решает Ansible:
    • Управление конфигурациями. Максимально быстрая и правильная настройка серверов до описанной конфигурации.
    • Провижнинг. Управление процессом развертывания новых облачных серверов (например через API, с помощью Docker или LXC).
    • Развертывание. Инсталляция и обновление ваших приложений без простоя наилучшим образом.
    • Оркестрация. Координация компонентов вашей инфраструктуры для выполнения развертываний. Например проверка, что веб-сервер отключен от балансировщика нагрузки, до апгрейда ПО на сервере.
    • Мониторинг и уведомления.
    • Логгирование. Централизованный сбор логов.



    По сравнению с другими популярными инструментами автоматизации ит-инфраструктуры, Ansible не требует установки клиентских приложений на обслуживаемые сервера, что может сократить время настройки перед развертыванием инфраструктуры. Для работы Ansible подключается к обслуживаемым серверам по SSH.

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

    Что нам потребуется для настройки


    Мы надеемся, что у вас уже есть учетная запись в InfoboxCloud. Если еще нет — создайте ее.

    Для работы Ansible нам понадобится управляющий сервер. Создайте его (рекомендуется использовать Ubuntu 14.04 или CentOS 7). Также создайте как минимум пару серверов с Linux, которые и будут настраиваться с помощью Ansible. Данные для доступа к серверам будут отправлены на ваш email.

    Подключитесь к управляющему серверу по SSH.

    Установка Ansible


    Ubuntu 14.04 LTS

    Для установки, на управляющем сервере введите:
    apt-key update && apt-get update && apt-get -y upgrade && apt-get -y install python-software-properties && apt-get -y install software-properties-common && apt-add-repository -y ppa:rquillo/ansible && apt-get update && apt-get -y install ansible
    

    CentOS 7

    Для установки, на управляющем сервере введите:
    yum -y update && yum -y install epel-release && yum -y install ansible
    


    Как работает Ansible


    Основная идея Ansible – наличие одного или нескольких управляющих серверов, из которых вы можете отправлять команды или наборы последовательных инструкций (playbooks) на удаленные сервера, подключаясь к ним по SSH.


    Файл Host inventory содержит информацию об обслуживаемых серверах, где команды будут исполнены. Файл конфигурации Ansible может быть полезен для указания настроек вашего окружения.

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

    Также вы можете использовать Ansible API для запуска скриптов. Если скрипту-обертке (wrapper) может потребоваться запуск playbook, это можно сделать через API. Сами playbooks описываются декларативно в формате YAML. Ansible поддерживает сценарии развертывания новых облачных серверов и конфигурирования их на основании ролей. Часть работы может быть проведена в локальном режиме на управляющем сервере, а остальная — на созданном сервере после его первой загрузки. Ведется работа над модулем провижнинга для InfoboxCloud.

    Настройка Ansible


    Файл конфигурации описывается в INI–формате. Вы можете переопределить часть или всю конфигурацию в параметрах playbook или переменных окружения.
    При исполнении команд Ansible проверяет наличие файла конфигурации в следующих расположениях:
    1. Проверяется переменная окружения ANSIBLE_CONFIG, которая может указывать на файл конфигурации.
    2. ./ansible.cfg – в текущей директории
    3. ~/.ansible.cfg — в домашней директории
    4. /etc/ansible/ansible.cfg — в каталоге, сгенерированном при установке ansible через менеджер пакетов.

    Настройка через переменные окружения

    Большинство параметров конфигурации можно установить через переменные окружения, используя префикс ANSIBLE_ перед названием параметра конфигурации (большими буквами).
    Например:
    export ANSIBLE_SUDO_USER=root
    После этого переменная ANSIBLE_SUDO_USER может быть использована в playbook.

    Настройка в ansible.cfg

    Параметров конфигурации Ansible множество. Давайте рассмотрим некоторые из них:
    • hostfile: Параметр указывает на путь к inventory file, в котором содержится список адресов хостов, к которым Ansible может подключиться.
      Например: hostfile = /etc/ansible/hosts
    • library: Путь к директории, где хранятся модули Ansible. Например: library = /usr/share/ansible
    • forks: Количество процессов, которые может породить Ansible. По-умолчанию установлено 5 процессов.
      Например: forks = 5
    • sudo_user: Пользователь по умолчанию, от которого Ansible запускает команды на удаленных серверах.
      Например: sudo_user = root
    • remote_port: Порт для соединения по SSH (по умолчанию 22).
      Например: remote_port = 22
    • host_key_checking: Параметр позволяет отключить проверку SSH–ключа на хосте. По-умолчанию проверка выполняется.
      Например: host_key_checking = False
    • timeout: Значение таймаута попытки подключения по SSH.
      Например: timeout = 60
    • log_path: Путь для хранения файлов логов. По-умолчанию Ansible не хранит их совсем, но указав этот параметр можно активировать запись логов.
      Например: log_path = /var/log/ansible.log

    Пишем первый файл конфигурации Ansible

    Давайте создадим наш первый файл конфигурации Ansible в InfoboxCloud. Подключитесь по SSH к созданному управляющему серверу с установленным Ansible. Создайте директорию для наших экспериментов 'ansible' и перейдите в нее:
    mkdir ~/ansible
    cd ~/ansible
    

    Также создайте папку для хранения модулей Ansible и папку для хранения логов:
    mkdir ~/ansible/modules
    mkdir ~/ansible/logs
    

    Создайте файл ansible.cfg со следующим содержимым:
    [defaults]
    hostfile = ~/ansible/inventory
    sudo_user = root
    log_path = ~/ansible/logs/ansible.log
    

    Указываем обслуживаемые сервера в host inventory

    Для экспериментов ранее мы создали пару серверов, которые и будем настраивать. Нужно сообщить Ansible их адреса и сгруппировать их. Для этого создайте файл inventory нашей директории ~/ansible/inventory со следующим содержимым:
    [experiments]
    ip_первой_машины
    ip_второй_машины
    

    ip_адреса серверов можно посмотреть в панели управления InfoboxCloud.


    Обратите внимание, что для использования управляющего сервера Ansible с серверами в одном регионе можно указать локальные IP–адреса и работать по внутренней сети.



    Необходимо сгенерировать на управляющем сервере ключ, который будет использоваться для доступа к настраиваемым серверам.
    Это делается с помощью команды:
    ssh-keygen
    

    На все вопросы можно просто нажать Enter.

    Теперь необходимо скопировать публичный ключ на настраиваемые сервера. Это можно сделать с помощью утилиты ssh-copy-id с управляющего сервера Ansible для каждого настраиваемого сервера:
    ssh-copy-id root@ip_адрес_настраиваемого_сервера
    



    Проверить корректность можно, залогинившись в настраиваемый сервер с управляющего по SSH. Если пароль больше не спрашивается — все в порядке.

    В InfoboxCloud можно создавать новые сервера с уже указанным публичным ключом. Для этого создайте чистый сервер. Скопируйте на него публичный SSH-ключ, как показано выше. Далее создайте образ ОС:



    Теперь в разделе «Образы серверов» панели управления можно при необходимости нажать «Создать сервер» на нашем образе и получить готовую к конфигурации машину для Ansible.



    Давайте теперь проверим корректность настройки Ansible полностью.
    Можно попинговать обслуживаемые сервера:
    ansible experiments -m ping
    



    или отправить в echo «Hello World»:
    ansible experiments -a "/bin/echo Hello, World!"
    



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


    Работаем с playbooks

    Исполнение Playbooks – одна из основных задач Ansible. Playbooks содержат списки задач. Каждая задача внутри Ansible использует кусок кода-модуля. Сами Playbooks описываются в формате YAML, но модули могут быть написаны на любом языке программирования. Важно, чтобы формат сообщений от модулей был в JSON.

    YAML

    Playbook пишется на YAML. Давайте посмотрим на основные правила написания YAML-файлов.

    Для Ansible практически каждый YAML файл начинается со списка. Каждый элемент списка — список пар «ключ-значение», часто называемая словарем.

    Все YAML файлы должны начинаться с "---". Это часть формата YAML и означает начало документа.

    Все члены списка должны находится с одинаковым отступом от начала строки, и должны начинаться с пробела или "-". Комментарии начинаются с "#".
    Например:
    ---
    #Message
    - Hosting
    – Cloud
    

    Словарь представлен в виде «ключ:» (двоеточие и пробел) «значение»:
    ---
    #Message
    site: habr
    blog: infobox
    

    При необходимости словари могут быть представлены в сокращенной форме:
    ---
    #Comment
    {site: habr, blog: infobox}
    

    Можно указать логические значение (истина/ложь) так:
    ---
    need_access: no
    use_service: yes
    file_conf: TRUE
    read_value: True
    kill_process: false
    

    Целиком наш пример YAML–файла будет выглядеть так:
    ---
    #About blog
    site: habr
    blog: infobox
    must_read: True
    themes:
     - hosting
     - cloud
     - it
     - geeks
    brands:
     - infobox
     - infoboxcloud
    

    Для переменных Ansible использует "{{ var }}". Если значение после двоеточия начинается с "{", то YAML будет думать, что это словать.
    Для использования переменных нужно заключить скобки в кавычки:
    word: "{{ variable }}"
    

    Этого достаточно для начала написания playbooks.

    Пишем наш первый playbook

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

    Цель игры — связать группу хостов с предопределенными ролями, представленными как вызов задач Ansible.

    В качестве примера давайте рассмотрим процесс установки nginx.
    Создадим директорию, где будут хранится playbooks:
    mkdir ~/ansible/playbooks
    

    Создадим файл setup_nginx.yml в директории playbooks со следующим содержанием:
    ---
    - hosts: experiments
      tasks:
    
      - name: Install nginx package
        apt: name=nginx update_cache=yes
        sudo: yes
    
      - name: Starting nginx service
        service: name=nginx state=started
        sudo: yes
    

    Давайте рассмотрим содержимое:
    • hosts: Список хостов или группа, на которой вы запускаете задачу. Это поле обязательное и каждый playbook должен иметь его, за исключением ролей. Если указана хост-группа, сначала Ansible ее ищет в playbook, а затем в файле inventory. Узнать, на каких хостах будет происходить работа, можно командой: ansible-playbook --list-host, где – путь к вашему playbook (playbooks/setup_nginx.yml).

      tasks: Задачи. Все playbooks содержат задачи. Задача — это список действий, которые вы хотите выполнить. Поле задачи содержит имя задачи (справочная информация о задаче для пользователя playbook), модуль, который должен быть выполнен и аргументы, требуемые для модуля. Параметр «name» опциональный, но рекомендуемый.


    • Успешной работы!
    Infobox
    35.22
    Company
    Share post

    Comments 32

      0
      Ansible это интересно.

      Вопросы по теме:
      Как там с гетерогенностью — насколько удобно создавать много разных серверов с похожими, но слегка отличающимися конфигами?
      Как там с индемпотентностью — еcли я попрошу скачать фаил он будет его скачивать каждый раз или проверит что фаил уже есть?
      Есть ли какие то решения кроме ssh — если я открою 10к ssh сессий одновременно моей системе поплохеет.
        +1
        1) Гетерогенность
        Можно выделить группу серверов
        [app_nodes]
        app1.someapp.example.com
        app3.someapp.example.com
        

        Включить одну группу в другую
        [all_apps:children]
        app_nodes
        


        И для каждой группы задать свои параметры (group_vars/app_nodes.yml)
        Или для каждой конкретной машины подправить пару-тройку переменных (host_vars/app3.someapp.example.com.yml)
          0
          Ок. А как с зависимостями — обновили конфиг и надо передернуть демона?
            +1
            notify: <нужный хэндлер>

            - name: install nginx
              apt: >
                name={{ nginx_name }}
                state=installed
                force=yes
            
            - name: write nginx.conf
              template: >
                src=nginx.conf.j2
                dest=/etc/nginx/nginx.conf
              notify: reload nginx
            
            - name: nginx deny ip default host
              copy:
                dest: /etc/nginx/sites-enabled/deny_by_ip.conf
                src: deny_by_ip.conf
                force: no
              when: nginx_deny_by_ip
              notify: reload nginx
            


            Handler запускается один раз если сработал хоть один notify. Описывается как-то так:
              - name: reload nginx
                sudo: yes
                service: name=nginx state={{ item }} pattern=nginx
                with_items:
                  - reloaded
                  - running
            
              0
              Всё верно. Добавлю, что все хэндлеры по умолчанию запускаются в конце прохода, но есть возможность и в конкретный момент времени запустить сработавшие.
                0
                Как раз нужно — подскажите как сделать?
                  +1
                  В официальной документации пишут, что следом за задачей, которая могла заставить сработать хэндлер, нужно сбросить очередь хэндлеров:

                  tasks:
                     - shell: some tasks go here
                     - meta: flush_handlers
                     - shell: some other tasks
                  
                    0
                    Ещё есть опция --force-handlers к ansible-playbook. Здесь хорошо описаны нюансы с примерами.
                      0
                      deleted
                    0
                    Ещё стоит учитывать, что namespace хэндлеров общий, т. е. в двух ролях одинаковый handler использовать не стоит. Кроме того, в названиях хэндлеров нельзя использовать шаблонизацию, что печалит.
                0
                2) Идемпотентность:
                В общем случае — проверит что файл (конфиг, например) есть и ничего делать не будет, задачу из playbook'а пометит как 'Ok'. Если конфига нет или его содержимое отличается — скажет 'Changed' и приведёт файл на машине в соответствие с исходным.

                3) Работа по ssh — наиболее удобна и соответствует принципу «мы сами знаем когда нам что-то накатывать».
                Однако возможна работа и по принципу Ceph'a, когда на каждой подконтрольной машине стоит ansible-pull, мониторящий какой-то репозиторий. Как только в нём появляются изменения — запускается локальный самодеплой (в теории, на живую не использовал)
                  0
                  3.1) Можно задать сколько хостов деплоить одновременно
                    0
                    2) В общем случае, ответственность за идемпотентность поведения лежит на авторах модулей к ansible. Те модули, которые делала команда проекта, в этом смысле очень хороши. А вот законтрибученые модули не особо сильно проверяют на это дело, по моему опыту. Но оно и понятно, почему.
                      0
                      Чтобы читающего не смутило обобщение, надо отметить, что есть много случаев, когда при работе даже с core-моудлями за идемпотентностью следит пользователь, например, это касается модуля replace, где пользователю требуется внести изменение так, чтобы при повторном проигрывании той же самой игры однажды изменённая строка вдруг опять не дала положительной реакции и не привела к очередному изменению.
                      0
                      3) Работа по ssh — наиболее удобна и соответствует принципу «мы сами знаем когда нам что-то накатывать».

                      Если у вас три с половиной VPS на Амазоне, то нет никакой разницы чем пользоваться — push, pull, Ansible, Chef, скрипт на баше или руками. Если у вас распределённая система с большим количеством серверов, виртуальных машин, софта, конфигураций и так далее, то наиболее скалируемый и безопасный вариант — это pull с добровольной кооперацией, когда не вы, а сервер «знает» когда ему обращаться к центральному хранилищу за новыми инструкциями и когда эти инструкции выполнять, с механизмом, позволяющим начать этот процесс по команде из центра. К сожалению Ansible в такой конфигурации не блещет совсем. С другой стороны, ниша, в которой может быть достаточно Ansible или скрипта, достаточно велика и большинство проектов не успевает настолько вырасти, чтобы увидеть эти проблемы хотя бы на горизонте.
                        0
                          0
                          Я в курсе, что можно, но это считается инвертированной архитектурой со всеми вытекающими последствиями. Вообще же исторически pull в Ansible был добавлен не без драм (с пассажами вроде «только идиот может хотеть pull», это почти дословная цитата) и с тех пор живёт там по остаточному принципу. И это вполне понятно, будь pull основным методом работы Ansible, было бы ещё хуже — это значит, что буквально на каждый хост нужно было бы ставить Python с набором библиотек, которые совершенно ни к чему на, скажем, публично доступном рекурсивном DNS-сервере, хотя там и SSH не нужен, если уж на то пошло. Но как я уже писал, большинство проектов проблем с архитектурой Ansible не увидит даже в перспективе, и потому нет причин волноваться. Однако, нужно быть морально готовым к тому, что в какой-то момент придётся мигрировать на более приспособленный для серьёзного использования софт.
                            0
                            Python на обслуживаемом ansible хосте всё равно нужен, т. к. ansible собирает python-скрипты, копирует на хост и выполняет локально.
                              0
                              Да? Спасибо за уточнение. Я почему-то был уверен, что Ansible «всё своё носит с собой», в том числе и интерпретатор, но видимо я что-то не так понял, когда тестировал его для своих нужд. Раз так, то стало быть для ещё большего круга задач Ansible абсолютно не подходит, что вообще печально, так как среди альтернатив выбора попросту нет, только CFEngine, прародитель Puppet, Chef и, в конечном итоге, Ansible. Но у него и порог входа сильно выше уровня эникеев, и баги есть досадные, которые очень тяжело исправлять, и, как следствие, меньше коммьюнити и меньше набор готовых решений.
                                0
                                On the managed nodes, you only need Python 2.4 or later, but if you are running less than Python 2.5 on the remotes, you will also need:
                                — python-simplejson
                                docs.ansible.com/intro_installation.html#managed-node-requirements

                                Кроме того если используется selinux необходимо ещё поставить libselinux-python до использования copy/file/template и аналогичный тасков.

                                Кроме того, есть модуль raw, который позволяет сделать бутстрап пайтона, если это необходимо. Не требует ничего, кроме ssh.

                                Сейчас python2.4+ нет только на очень сильно урезанных инсталляциях. На том же RHEL/CentOS он есть из коробки, т. к. yum на нем написан. Подозреваю, что в debian он тоже есть даже в более-менее компактных установках
                                  0
                                  В Debian на Python не завязано никаких ключевых компонентов системы и в базовой системе его нет. Другие дистрибутивы в проде, естественно, не используем.
                      0
                      Про идемпотентность:
                      Все зависит от вашего стиля написания плейбуков. Если вы использовали raw: wget foo.bla/file — то файл будет скачиваться каждый раз. Если же вы используете модуль get_url — то он будет проверять наличие и хэш файла перед скачиванием. Мы же в своей работе обычно пишем вначале стек проверок и заносим результаты в переменные. После чего в каждом шаге есть проверка вида «если nginx -v != заданной версии nginx — то берем собранный пакет и ставим. Если же nginx -v = заданной версии — то скипаем шаг. У нас, например, все роли обеспечивают идемпотентность.

                      Про кучу серверов единовременно:
                      У нас такой задачи не стоит обычно, но сами разработчики рапортуют об успешных инсталяциях на инфраструктурах в десятки тысяч машин. Можно запускать по очереди, по 10-20 хостов за раз. Можно отправить все задачи в кролика — и кем-то их разбирать. Архитектуры, которые решают подобные задачи уже изобретены.
                      0
                      1. А почему «рекомендуется Ubuntu или CentOS»? Вроде как ansible всё равно где работать, хоть на Plan9 — главное, чтобы там был python. Ну с Plan9 понятно — окружение может быть не то, но с *nix-like вообще разницы не вижу.
                      2. Вот сразу с ключей SSH. Сходу не помню есть ли готовое, но почему бы первым таском не сделать раскладку ключей и кстати подтягивание python на серверах?
                        0
                        Рекомендуется Ubuntu или CentOS для начала изучения, т.к. ставится не из Testing репозитория, быстро и просто. Для эксплуатации подходит практически любой дистрибутив. Про поднятие python не рассказано, т.к. нужные версии уже устанавливаются в указанных дистрибутивах. Как запустить на других — если нужно будет — есть в документации по Ansible. Не хотелось перегружать и так большое руководство, должно быть понятно и новичкам. Если не испугаются на первом этапе — хорошо.
                          –1
                          А. Ну да, про тестинг репозитарий не подумал.
                          0
                          2. Кроме того ansible умеет подключаться не только по ключам, но и по паролю. Причем пароль умеет как запрашиваться в ходе выполнения, так и браться из файла настроек. Так что тем кто не знаком с работой по ключам или по какой-то причине нет возможности применить ключ — можно пользоваться вариантом с паролями и ключи раскладывать не придется.
                            0
                            И так тоже, кстати. Ещё он умеет как от юзера, так и через sudo. А ещё он, гад такой, не умел raw режим на FreeBSD до весны из-за очень неаккуратной работы с ключами внутри себя )
                          +1
                          Так же указано, что необходимы права суперпользователя для обоих задач.

                          Нужно отметить, что если права суперпользователя нужны для выполнения всех задач в игре, то можно просто указать ключ sudo на уровне игры:

                          - hosts: webservers
                            remote_user: yourname
                            sudo: yes
                          

                          Или в файле ansible.cfg. Или в качестве ключа в командной строке.
                            +1
                            Отличная статья. Год назад начал внедрять Ansible у себя — порядка 700 хостов ею держим на данный момент, не все автоматизированно, но некоторый пул задач безусловно ею решается.
                            В процессе эксплуатации конечно вылезают велосипеды, но куда же без них.
                            В будущем будет книжка целая — shop.oreilly.com/product/0636920035626.do
                              0
                              У нас порядка 400. А какие велосипеды писали, для чего, поделитесь? Нас ansible полностью устроил, основная проблема была в утрясании workflow, много итераций прошли в этом процессе.
                                0
                                Сейчас все и не упомнишь, мы еще свой workflow утрясаем)
                                Из того, что вспомнил — пляски с генерацией ИД уникального по последним трем октетам адреса:

                                server-id={{ ansible_default_ipv4.address |replace(".","")|reverse|truncate(9,True,"")|reverse }}
                                


                                Из-за большого кол-ва проектов (порядка 10), пришлось в каждый подключать свой собственный файл с некими константами.
                                А потом решать проблему с доступом пользователей и их заведением на разные группы хостов…
                                Раз
                                В итоге родилось вот такое вот:

                                - name: Add ssh user
                                  user: 
                                    name={{ item.user }} 
                                    groups={{ item.group }} 
                                    comment={{ item.comment }} uid={{ item.uid }}
                                    password={{ item.password }}
                                    shell={{ user_shell | default("/bin/bash") }} 
                                    state={{ item.state | default("present") }}
                                  with_items: "ssh_users"
                                  when: item.user is defined
                                


                                А группа ssh_users для каждой группы хостов определяет список пользователей, данные о которых берутся из общего файла group_vars/all. Фильм Начало тут отдыхает :)
                                пользователь определялся видом
                                dtest:
                                    - { user: 'd.test', group: 'ssh_access', comment: "Test_User", uid: '10403', password: 'MEGAHASH', state: 'absent' }
                                

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

                                Из последнего скорее не велосипед, а просто особенность — настроил автоматическое добавление хоста в мониторинг заббикса при его первоначальной настройке. Использую для этого API заббикса и модуль ансибла uri, так он заставляет писать json как будто я сотону вызываю.
                                Два
                                - name: register host in zabbix database
                                  uri: url=http://"{{zabbix_server}}"/api_jsonrpc.php HEADER_Content-Type="application/json" method=POST
                                       body="{\"jsonrpc\":\"2.0\",\"method\":\"host.create\", \"params\":{\"host\":\"{{ ansible_fqdn }}\",\"interfaces\":[{\"type\":1,\"main\":1,\"useip\":1,\"ip\":\"{{ ansible_ssh_host | default (ansible_default_ipv4.address) }}\", \"dns\":\"{{ ansible_fqdn }}\", \"port\":\"10050\"}], \"groups\":[{\"groupid\":\"{{zabbix_group_id.json.result[0].groupid}}\"}]}, \"auth\":\"{{zabbix_auth_code.json.result}}\",\"id\":4}"
                                  delegate_to: localhost
                                  when: zabbix_host_exist.json.result == False
                                


                                В основном велосипеды делались для переменных, которые ансибл страсть как любит. Переменные для переменных в переменных. В итоге через месяц ты уже не понимаешь, как оно работает :)
                                А вообще с ним весело )
                              0
                              Да, Ansible — мощная штука!

                              Я заморочался и создал несколько ролей, которые можно повторно использовать, в основном, это касается веб-разработки и LAMP-стека: github.com/andyceo/ansible-roles Еще несколько ролей можно найти на Ansible Galaxy, сервисе, куда можно закачивать свои роли, чтобы все ими могли пользоваться.

                              Еще долго думал, в каком виде хранить все свои настройки для всех хостов в виде одного репозитория, и вот пока пришел к этому: github.com/andyceo/ansible-example

                              Об использовании Ansible для разработке под Друпал я рассказывал на последнем Drupal-кемпе в Москве, вот доклад, кому интересно: 2014.drupalcampmsk.ru/program/sessions/ispolzovanie-ansible-dlya-upravleniya-serverami-i-drupal

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