Ansible добавить строку в файл

Обновлено: 06.07.2024

Это руководство по стилю шпаргалки содержит краткую справку о командах и методах, обычно используемых при работе с Ansible. Для получения общего представления об Ansible и о том, как его установить и настроить, пожалуйста, ознакомьтесь с нашим руководством по установке и настройке Ansible на Ubuntu 18.04.

Как использовать это руководство:

• Это руководство представлено в формате шпаргалки с автономными фрагментами командной строки.
• Переходите к любому разделу, который имеет отношение к задаче, которую вы пытаетесь выполнить.
• Когда вы видите highlighted text в этом руководстве команды, имейте в виду, что этот текст должен относиться к хостам, именам пользователей и IP-адресам из вашего собственного инвентаря.

Глоссарий

В настоящем руководстве в основном используются следующие специфические для ansible термины:

• Управляющая машина / узел: система, в которой установлен и сконфигурирован Ansible для подключения и выполнения команд на узлах.
• Узел: сервер, управляемый Ansible.
• Файл инвентаризации: файл, содержащий информацию о серверах, на которых обычно находятся элементы управления Ansible /etc/ansible/hosts .
• Playbook: файл, содержащий ряд задач, которые должны быть выполнены на удаленном сервере.
• Роль: коллекция книг воспроизведения и других файлов, имеющих отношение к такой цели, как установка веб-сервера.
• Игра: полный пробег ansible. Пьеса может иметь несколько сборников пьес и ролей, включенных из одного сборника пьес, который действует как точка входа.

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

Тестирование подключения к узлам

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

ping Модуль проверит, есть ли у вас действительные учетные данные для подключения к узлам, определенным в вашем файле инвентаризации, в дополнение к проверке того, может ли Ansible запускать скрипты Python на удаленном сервере. Ответ pong назад означает, что Ansible готов запускать команды и PlayBook на этом узле

Подключение от имени другого пользователя

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

флагом и именем предполагаемого пользователя:

То же самое справедливо и для ansible-playbook:

Использование пользовательского ключа SSH

Если вы используете пользовательский SSH-ключ для подключения к удаленным серверам, вы можете предоставить его во время выполнения с

Эта опция также действительна для ansible-playbook:

Использование аутентификации на основе пароля

Если вам нужно использовать аутентификацию на основе пароля для подключения к узлам, вам нужно добавить эту опцию

к вашей команде Ansible.

Это позволит Ansible запрашивать пароль пользователя на удаленном сервере, к которому вы пытаетесь подключиться в качестве:

Эта опция также действительна для ansible-playbook:

Предоставление sudo пароля

Эта опция также действительна для ansible-playbook :

Использование пользовательского файла инвентаризации

Файл инвентаризации по умолчанию обычно находится по адресу /etc/ansible/hosts , но вы также можете использовать эту -i опцию, чтобы указать на пользовательские файлы инвентаризации при запуске команд Ansible и PlayBook. Это полезно для настройки запасов по каждому проекту, которые могут быть включены в системы контроля версий, такие как Git:

Тот же вариант действителен и для ansible-playbook :

Использование динамического файла инвентаризации

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

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

Следующая команда использует сценарий инвентаризации DigitalOcean от Ansible с ping командой для проверки подключения ко всем текущим активным серверам:

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

Выполнение специальных команд

Чтобы выполнить команду на узле, используйте -a опцию, за которой следует команда, которую вы хотите запустить, в кавычках.

Это будет выполняться uname -a на всех узлах в вашем инвентаре:

Кроме того, с помощью этой опции можно запускать ansible модули -m . Следующая команда установит пакет vim on server1 из вашего инвентаря:

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

Запуск Playbook

Чтобы запустить playbook и выполнить все задачи, определенные в нем, используйте ansible-playbook команду:

Чтобы перезаписать параметр hosts по умолчанию в playbook и ограничить выполнение определенной группой или хостом, включите этот параметр -l в свою команду:

Получение информации

Эта опция --list-tasks используется для перечисления всех задач, которые будут выполняться игрой без внесения каких-либо изменений на удаленные серверы:

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

Вы можете использовать теги, чтобы ограничить выполнение пьесы. Чтобы перечислить все теги, доступные в игре, используйте опцию --list-tags :

Контроль Выполнения Playbook

Вы можете использовать эту опцию --start-at-task , чтобы определить новую точку входа для вашего playbook. Затем Ansible пропустит все, что предшествует указанной задаче, выполнив оставшуюся часть воспроизведения с этого момента. Этот параметр требует допустимого имени задачи в качестве аргумента:

Этот параметр можно использовать только для выполнения задач, связанных с определенными тегами --tags . Например, если вы хотите выполнять только задачи, помеченные как nginx или mysql , вы можете использовать:

Если вы хотите пропустить все задачи, которые находятся под определенными тегами, используйте --skip-tags . Следующая команда будет выполнена myplaybook.yml , пропуская все задачи, помеченные как mysql :

Использование Ansible Vault для хранения конфиденциальных данных

Если ваши Ansible playbook имеют дело с конфиденциальными данными, такими как пароли, ключи API и учетные данные, важно обеспечить безопасность этих данных с помощью механизма шифрования. Ansible обеспечивает ansible-vault шифрование файлов и переменных.

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

Создание нового зашифрованного файла

Вы можете создать новый зашифрованный файл Ansible с помощью:

Эта команда будет выполнять следующие действия:

• • • Во-первых, он предложит вам ввести новый пароль. Вам нужно будет вводить этот пароль всякий раз, когда вы получаете доступ к содержимому файла, будь то для редактирования, просмотра или просто запуска PlayBook или команд, использующих эти значения.
    • Затем он откроет редактор командной строки по умолчанию, чтобы вы могли заполнить файл нужным содержимым.
    • Наконец, когда вы закончите редактирование, ansible-vault сохраните файл как зашифрованные данные.

    Шифрование существующего файла Ansible

    Для шифрования существующего файла Ansible можно использовать следующий синтаксис:

    Это запросит у вас пароль, который вам нужно будет вводить всякий раз, когда вы получаете доступ к файлу credentials.yml .

    Просмотр содержимого зашифрованного файла

    Если вы хотите просмотреть содержимое файла, который ранее был зашифрован, ansible-vault и вам не нужно изменять его содержимое, вы можете использовать:

    При этом вам будет предложено ввести пароль, который вы выбрали при первом шифровании файла ansible-vault .

    Редактирование зашифрованного файла

    Чтобы отредактировать содержимое файла, который ранее был зашифрован с помощью Ansible Vault, выполните команду:

    При этом вам будет предложено ввести пароль, который вы выбрали при первом шифровании файла credentials.yml ansible-vault . После проверки пароля откроется редактор командной строки по умолчанию с незашифрованным содержимым файла, что позволит вам внести необходимые изменения. Когда вы закончите, вы можете сохранить и закрыть файл, как обычно, и обновленное содержимое будет сохранено в виде зашифрованных данных.

    Расшифровка Зашифрованных Файлов

    Если вы хотите навсегда вернуть файл, который ранее был зашифрован, ansible-vault в его незашифрованную версию, вы можете сделать это с помощью этого синтаксиса:

    При этом вам будет предложено ввести тот же пароль, который использовался при первом шифровании файла credentials.yml ansible-vault . После проверки пароля содержимое файла будет сохранено на диске в виде незашифрованных данных.

    Использование Нескольких Паролей Хранилища

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

    Чтобы создать новый зашифрованный файл с помощью пользовательского идентификатора хранилища, включите эту --vault-id опцию вместе с меткой и местоположением, где ansible-vault можно найти пароль для этого хранилища. Метка может быть любым идентификатором , а расположение может быть любым prompt , что означает, что команда должна предложить вам ввести пароль или действительный путь к файлу паролей.

    Это создаст новый идентификатор хранилища с именем dev , который будет использоваться prompt в качестве источника пароля. Комбинируя этот метод с файлами групповых переменных, вы сможете иметь отдельные хранилища ansible для каждой среды приложения:

    Мы использовали dev и prod в качестве идентификаторов хранилищ, чтобы продемонстрировать, как можно создавать отдельные хранилища для каждой среды, но вы можете создать столько хранилищ, сколько захотите, и вы можете использовать любой идентификатор по вашему выбору в качестве идентификатора хранилища.

    Теперь, чтобы просмотреть, отредактировать или расшифровать эти файлы, вам нужно будет предоставить тот же идентификатор хранилища и источник пароля вместе с ansible-vault командой:

    Использование файла паролей

    Если вам нужно автоматизировать процесс подготовки серверов с помощью Ansible с помощью стороннего инструмента, вам понадобится способ предоставить пароль хранилища без запроса на него. Вы можете сделать это, используя файл пароля ansible-vault С.

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

    Чтобы использовать файл паролей ansible-vault , вам необходимо указать путь к файлу паролей при выполнении любой из команд vault:

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

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

    Запуск Playbook с данными, зашифрованными через Ansible Vault

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

    Если вы использовали параметры по умолчанию и prompt источник пароля при шифровании данных, используемых в этом сборнике воспроизведения, вы можете использовать этот параметр --ask-vault-pass , чтобы сделать Ansible запрос пароля:

    Если вы использовали файл пароля вместо запроса пароля, то вам следует использовать эту опцию --vault-password-file :

    Если вы используете данные, зашифрованные под идентификатором хранилища, вам нужно будет предоставить тот же идентификатор хранилища и источник пароля, который вы использовали при первом шифровании данных:

    Если вы используете файл паролей с вашим идентификатором хранилища, вы должны указать метку, а затем полный путь к файлу паролей в качестве источника паролей:

    Если ваша игра использует несколько хранилищ, вы должны указать --vault-id параметр для каждого из них, не в определенном порядке:

    Отладка

    Если вы столкнулись с ошибками при выполнении команд Ansible и PlayBook, это хорошая идея, чтобы увеличить детализацию вывода, чтобы получить больше информации о проблеме. Вы можете сделать это, включив -v опцию в команду:

    Если вам нужно больше деталей, вы можете использовать -vvv , и это увеличит многословность вывода. Если вы не можете подключиться к удаленным узлам через Ansible, используйте -vvvv для получения информации об отладке соединения:

    Вывод

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

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

    Инструкция представляет из себя шпаргалку по работе с Ansible. У автора не стоит задачи подробного пояснения всех операций — только описание задачи и пример того, как ее можно решить с помощью ansible. Для более подробного описания я постараюсь указать ссылки на официальную документацию. Также в данную шпаргалку не войдут все возможные действия, которые можно выполнить с помощью данной системы — только популярные и те, с которыми приходилось сталкиваться самому автору. По мере возможности, их список будет пополняться.

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

    Получение информации

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

    1. Показать информацию об удаленной системе, на которой запускается ansible.

    Выполняется с помощью модуля debug, который должен показать содержимое ansible_facts:

    - name: Print all available facts
    ansible.builtin.debug:
    var: ansible_facts

    * ansible_facts содержит массив данных с информацией о системе. Однако, функция сборки информации может быть отключена (так как на ее работу тратится, относительно, много времени) в настройках плейбука с помощью опции gather_facts: false — в этом случае, значение нужно изменить на true.

    Также мы можем обратиться к конкретному элементу массива ansible_facts, получив информацию о конкретной настройке или опции:

    * например, имя компьютера.

    2. Отображение на экран переменной.

    Выше мы уже использовали debug для отображения переменной — принцип тот же:

    * при выполнении задачи на экране мы увидим значение переменной variable. Обратите внимание, что запись ansible.builtin.debug и debug — это одно и то же, то есть, ansible.builtin можно не писать.

    3. Сохранение результата в переменную.

    Выполняется с помощью register:

    - name: Run a shell command and register its output as a variable
    shell: command
    register: command_result

    * в данном примере мы запишем в переменную command_result все то, что мы получили с помощью команды command.

    Вывести на экран содержимое можно с помощью debug:

    - name: Show Value of Variable
    debug:
    var: command_result.stdout

    * обратите внимание, что мы выводим не все содержимое, а только stdout, то есть то, что должна была вывести в консоль команда.

    4. Получить список сервисов.

    Для этого существует service_facts:

    - name: Populate service facts
    ansible.builtin.service_facts:

    - name: Print all available facts
    ansible.builtin.debug:
    var: ansible_facts.services

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

    Проверки и условия

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

    1. Проверка на пустую папку.

    Задачи сводится к двум операциям:

    • получении списка файлов в целевом каталоге (например, с помощью команды ls) и регистрации полученного значения в переменную с помощью register.
    • проверка содержимого переменной, которую мы получили на шаге 1 с помощью when.

    Пример будет таким:

    - name: Register Contents of PGDATA Folder
    shell: ls /var/lib/postgresql/11/main
    register: pg_contents

    - name: Init PostgreSQL DB
    shell: /opt/pgpro/std-11/bin/pg-setup initdb
    environment:
    PGDATA: "/var/lib/postgresql/11/main"
    when: pg_contents["stdout_lines"] | length == 0

    2. Проверить, определена ли переменная.

    Для этого используется опция is defined (определена) или is not defined (не определена):

    when: pgpro is defined

    when: pgpro is not defined

    * в данном примере мы проверим наличие переменной pgpro. На практике такая проверка имеет значение, так как если мы попробуем выполнить действия с несуществующей переменной, Ansible нам вернет ошибку.

    В официальной документации про это сказано в статье о when (ссылка выше).

    3. Выполнение команды, если сервис в рабочем состоянии.

    Нам необходимо получить информацию о службах с помощью service_facts, после чего можно уже делать проверку с помощью when:

    - name: Populate service facts
    ansible.builtin.service_facts:

    - name: Stop Service If Running One
    shell: systemctl stop apache2
    when: ansible_facts.services["apache2.service"] is defined and ansible_facts.services["apache2.service"].state == "running"

    * в данном примере мы проверим, есть ли служба apache2 и запущена ли она. Если это так, то мы ее останавливаем.

    Подробнее о service_facts можно прочитать в документации (ссылка выше в разделе 4. Получить список сервисов).

    Установки пакетов, модулей и расширений

    В данном разделе мы коснемся всего, что приводит к установке чего бы то ни было. А именно:

    • Установки пакетов в систему.
    • Загрузки исходников.
    • Установке дополнительных модулей.
    • Распаковке архивов.

    Рассмотрим это подробнее.

    1. Установка модуля в nodejs.

    Установка модулей в nodejs выполняется с помощью npm. Для него в ansible есть отдельная функция:

    - name: Install nodejs modules.
    npm:
    name: newman
    global: yes

    * в данном примере будет выполнена установка newman, которая будет доступна всем проектам (опция global).

    2. Загрузка из GIT.

    Выполняется с помощью модуля git:

    * в данном примере мы сделаем клон репозитория в каталог /tmp/docker-compose.

    3. Распаковка архива.

    Выполняется с помощью unarchive:

    * в данном примере мы распакуем исходник для nginx в каталог /tmp. Обратите внимание на две вещи:

    • Мы используем переменную nginx_ver. Данная переменная должна быть определена при запуске плейбука, или в инвентарном файле, или в var, или в default.
    • Опция creates позволит не выполнять операцию, если существует файл /tmp/nginx->.tar.gz.

    Настройка системы

    В данном разделе мы рассмотрим процессы, которые больше подходят для категории настройки системы.

    1. Добавить задание в cron.

    Выполняется с помощью модуля cron:

    * в данном примере мы создадим задание для запуска команды /scripts/command.sh каждый день, каждые 6 часов.

    2. Добавить публичный ключ хоста в known_hosts.

    Делается с помощью known_hosts. Пример из официальной документации:

    3. Создание новых SSH-ключей для сервера.

    Создание ключей реализуется с помощью модуля openssh_keypair:

    * в данном примере мы создадим 4 ключа разных типов: dsa, ecdsa, ed25519, rsa. Так как у каждого из них свои требования к размеру, перечень представлен в виде двумерного массива. Ключи будут созданы в каталоге /etc/ssh/.

    4. Создание системной учетной записи.

    Для этого есть модуль user. У него много опций, но для создания системной учетной записи нам достаточно:

    - name: Create User Consul
    user:
    name: consul
    system: yes
    comment: "Consul Agent"

    * в данном примере будет создана учетная запись consul.

    5. Работа с systemd.

    Для данной настройки есть одноименный модуль systemd. Рассмотрим варианты его использования.

    а) перечитать конфигурацию (необходимо делать каждый раз, когда мы меняем настройки юнита):

    - name: systemd reload
    systemd:
    daemon_reload: yes

    б) разрешить сервис (автозапуск):

    - name: mysql enable
    systemd:
    name: mysql
    enabled: yes

    * для сервиса mysql.

    в) перезапустить сервис:

    - name: mysql reload
    systemd:
    name: mysql
    state: restarted

    * для сервиса mysql.

    6. Настройка брандмауэра.

    Выполняется разными модулями в зависимости от используемой системы управления netfilter:

    Рассмотрим небольшие примеры.

    - name: Block specific IP
    iptables:
    chain: INPUT
    source: 8.8.8.8
    jump: DROP

    Добавить 80 порт:

    Добавить порты с циклом:

    Работа с папками и файлами

    Рассмотрим задачи, которые помогут нам создавать, копировать и работать с файлами.

    1. Создание каталогов и файлов.

    Создание файлов и каталогов выполняется с помощью модуля file.

    а) для каталога в качестве state указываем directory:

    б) для создания файла указываем убираем опцию state (или даем ей значение file):

    - name: Create File
    file:
    path: "/var/www/site1/index.php"
    owner: www-data
    group: www-data
    mode: 0644

    * в данном примере мы созданим файл index.php в каталоге /var/www/site1.

    2. Копирование файлов из каталога.

    Для копирования данных мы используем модуль copy:

    - name: Copy Cert File If Different
    copy:
    src: ">"
    dest: /etc/ssl/dmosk
    remote_src: no
    mode: 0644
    owner: root
    group: root
    with_fileglob:
    - files/*

    * в данном примере мы прочитаем все содержимое каталога files на компьютере с ansible, и скопируем его в каталог /etc/ssl/dmosk на целевом компьютере.

    3. Используем шаблон.

    Копирование из шаблона отличается от копирования из файла тем, что в шаблоне могут использоваться переменные, которые будет заменяться их значениями в момент копирования. Для самого процесса копирования из шаблона используется модуль template:

    - name: Create Config for Consul Agent
    template:
    src: templates/consul/config.json.j2
    dest: /etc/consul.d/config.json

    * в данном примере мы возьмом шаблон templates/consul/config.json.j2 на компьютере ansible и разместим его в по пути /etc/consul.d/config.json на целевом компьютере.

    4. Удалить последние 30 файлов.

    Задача решается в два этапа:

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

    Поиск выполняем с помощью модуля find, удаление — file:

    - name: "Get list of backup files"
    find:
    paths: "/backup"
    file_type: file
    register: founds

    * в данном примере мы ищем файлы в каталоге /backup, после чего сортируем найденное и удаляем по списку все файлы, которые идут после 30-го.

    Для этого используется модуль uri. Простой пример:

    * в данном примере мы скачаем файл с ресурса, где требуется аутентификация по токену, который передается в заголовке. Заголовки мы передаем с помощью параметра headers. Также мы задаем права на загруженный файл и делаем в качестве владельца пользователя и группу dmosk.

    Виртуализация VMware

    Работа с виртуальными машинами на платформе VMware выполняется с помощью модуля vmware_guest.

    Мы рассмотрим несколько примеров.

    1. Базовое подключение.

    Для выполнения действий над виртуальными машинами мы должны подключиться к хосту VMware. Для этого используем данные строки:

    * параметр validate_certs, выставленный в no, позволит избежать ошибки, если у нас на хосте используется самоподписанный сертификат (как правило, так и есть).

    2. Переименовать виртуальную машину.

    Для выполнения действия нам нужно знать идентификатор виртуальной машины:

    * где uuid — идентификатор виртуальной машины; name — новое имя виртуальной машины.

    3. Конвертировать виртуальную машину в шаблон.

    Для этого нужно просто задать признак is_template:

    Разное

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

    1. Шифрование строки.

    С помощью ansible-vault мы можем шифровать файлы и папки. Это позволит нам хранить секреты не в открытом виде. Данные расшифровываются в момент выполнения задач.

    Данной командой мы получаем шифрованную строку:

    Система запросит ввести дважды пароль и предложит ввести строку, которую нужно зашифровать. После мы должны нажать 2 раза Ctrl + D — мы получим строку, которая начинается с !Vault и различные символы.

    Для того, чтобы в момент выполнения задачи ansible расшифровал данные, при запуске плейбука мы должны указать ключ --ask-vault-pass:

    2. Игнорировать ошибки.

    Если ansible столкнется с ошибкой при выполнении задачи, работа плейбука будет завершена. Иногда, нужно пропустить ошибку при выполнении определенной задачи, чтобы выполнение было продолжено. Для этого существует опция ignore.

    а) чтобы пропустить ошибки выполнения, в настройка задачи используем:

    - name: Bad Task
    .
    ignore_errors: yes

    б чтобы игнорировать ошибки при подключении к хосту:

    - name: Bad Task
    .
    ignore_unreachable: yes

    3. Начинать выполнение с определенной задачи.

    При выполнении отладки, полезно запустить плейбук, но начать выполнение с определенной задачи. Остальные пропустить.

    Это можно сделать с помощью опции --start-at-task:

    ansible-playbook . --start-at-task="Start Job"

    * в данном примере плейбук начнет выполнять задания с задачи Start Job.

    4. Завершить выполнение плейбука после определенной задачи.

    С помощью данной конструкции:

    5. Зависимые роли.

    С помощью файла meta/main.yml в роли мы можем определить пред-роль, от которой зависит выполнение текущей роли. Для этого настраивается опция dependencies:

    dependencies:
    - role: pred

    6. Вставка роли и ее задач.

    Позволяет в процессе выполнения задачи подключить роль. Делается при помощи include_role:

    - name: "Include Other Role"
    include_role:
    name: other_role

    А это пример, как подключить роль и сделать так, чтобы все ее задачи выполнились на определенном хосте:

    7. Замены в строке.

    Замены выполняются с помощью модуля replace:

    * в данном примере мы добавляем комментарий к строке server.address=127.0.0.1.

    8. Повторы при выполнении задачи.

    Мы можем управлять цикличностью выполнения задач с помощью retries (количиство повторов), delay (задержка в секундах).

    Рассмотрим пример повтора выполнения задачи при возникновении ошибки:

    - name: Run anything command
    command: /foo/bar/cmd
    register: result
    retries: 3
    delay: 60
    until: result is not failed

    * в данном примере мы будем выполнять команду /foo/bar/cmd пока ее выполнение не закончится без ошибок. Количество повторов будет равен 3 с интервалом в 60 секунд.

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

    Как установить и первоначально настроить Ansible описано здесь:

    Так как простые задачи для Ansible реально простые, в буквальном смысле слова, то я принял решение вынести их в отдельную инструкцию:

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

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

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

    Рассмотрим структуру и правила написания таких сценариев более подробно.

    Чтобы выполнить сценарий используется команда ansible-playbook со следующим синтаксисом:

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

    Перед каждым новым разделом списка ставится дефис ( - ):

    Основными параметрами/группами простого сценария являются:

    Также в сценарии перед непосредственным описанием задач могут быть указаны следующие параметры или группы параметров:

    Рассмотрим все эти разделы более подробно.

    В разделе hosts указывается группа управляемых узлов, к которой будут применены описываемые в сценарии изменения.

    Так, строка формата:

    Это означает, что изменения будут применены к узлам из группы webservers .

    Сценарии могут выполняться не только от имени пользователя, под именем которого установлено соединение, но и любого другого.

    В следующем примере авторизация на узле будет произведена с именем yourname , но задачи будут выполняться от имени пользователя root (если, конечно, этому пользователю это разрешено):

    В разделе vars указываются переменные, которые будут использованы в сценарии, и их значения:

    Список изменений, которые необходимо произвести на управляемом узле, приводится в разделе tasks . Каждой задаче ( task ) присваивается имя ( name ).

    Далее указываются модули Ansible, которые будут задействованы при ее выполнении:

    Для каждой задачи можно указывать пользователя, от имени которого она будет выполнена:

    Еще некоторые примеры.

    Словарь представлен в виде « ключ: » (двоеточие и пробел) « значение »:

    При необходимости словари могут быть представлены в сокращенной форме:

    Можно указать логические значение (истина/ложь) так:

    Целиком наш пример YAML–файла будет выглядеть так:

    Для переменных Ansible использует « > ». Если значение после двоеточия начинается с « < », то YAML будет думать, что это словарь.

    Для использования переменных нужно заключить скобки в кавычки:

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

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

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

    4. Контроль выполнения.

    Допустим, что при выполнении сценария нам нужно проверять определённые переменные или состояния и, в зависимости от них, выполнять или не выполнять какие-либо задачи.

    Для этого можно использовать оператор « when »:

    5. Шаблонизация.

    В Ansible используется шаблонизатор Jinja2.

    Приведём пример шаблона (часть конфигурации powerdns):

    В приведённом примере мы подставляем в шаблон следующие значения:

    Обработку шаблонов и, в данном случае, генерацию конфигурационного файла выполняет модуль template ; он же может задать необходимые права доступа и изменить владельца/группу:

    Внимание! Файл шаблона и файл с паролем пользователя базы данных находятся на машине управления, а результатом будет файл на удалённом узле.

    6. Делегирование задачи другому узлу.

    Иногда требуется выполнить задачу на определённом узле, но в контексте другого узла.

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

    7. Роли.

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

    В сценариях роли назначаются следующим образом:

    8. Структура проекта.

    
    

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

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

    В качестве другого примера давайте рассмотрим процесс установки nginx.

    Создадим директорию, где будут хранится playbooks:

    Создадим файл setup_nginx.yml в директории playbooks со следующим содержанием:

    Давайте рассмотрим содержимое:

    • hosts: Список узлов или группа, на которой вы запускаете задачу.

    Это поле обязательное и каждый playbook должен иметь его, за исключением ролей. Если указана узловая-группа, сначала Ansible ее ищет в playbook, а затем в файле inventory .

    Узнать, на каких узлах будет происходить работа, можно командой:

    где – путь к вашему playbook ( playbooks/setup_nginx.yml ).

    • tasks: Задачи. Все playbooks содержат задачи.

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

    10. Пример сценария.

    11. Практические примеры плейбуков.

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

    12. Запуск плейбуков.

    Чтобы запустить плейбук и выполнить все определенные в нем задачи, используйте команду ansible-playbook:

    Чтобы перезаписать в плейбуке опцию hosts по умолчанию и ограничить выполнение определенной группой или узлом, включите в команду опцию -l :

    13. Запрос информации о play.

    Опция --list-tasks используется для перечисления всех задач, которые будут выполнены в play, при этом не внося никаких изменений на удаленные серверы:

    Точно так же можно запросить все узлы, которые будут затронуты выполнением play, без запуска каких-либо задач на удаленных серверах:

    Вы можете использовать теги, чтобы ограничить выполнение play.

    Чтобы вывести список всех тегов, доступных в play, используйте параметр --list-tags :

    14. Управление выполнением плейбука.

    Вы можете использовать опцию --start-at-task , чтобы определить новую точку входа вашего плейбука. Затем Ansible пропустит все, что предшествует указанной задаче, выполнив оставшуюся часть play с заданного момента.

    Эта опция в качестве аргумента требует правильное имя задачи:

    Чтобы выполнять только задачи, связанные с конкретными тегами, вы можете использовать опцию --tags .

    Например, если вы хотите выполнить только задачи, помеченные как nginx или mysql, вы можете использовать:

    Если вы хотите пропустить все задачи, которые находятся под определенными тегами, используйте --skip-tags .

    Следующая команда будет выполнять myplaybook.yml , пропуская все задачи, помеченные как mysql :

    15. Настройка защищенных плейбуков.

    Если ваши плейбуки Ansible содержат конфиденциальные данные, такие как пароли, ключи API и учетные данные, важно обеспечить их безопасность с помощью шифрования. Ansible предоставляет ansible-vault для шифрования файлов и переменных.

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

    
    

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

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

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

    Со всеми сложностями, о которых идет речь выше, мы хорошо знакомы на собственном опыте: у нас имеется 10 точек присутствия с NS-серверами, расположенные в разных точках планеты. На них необходимо регулярно вносить различные изменения: обновлять операционную систему, устанавливать и обновлять различное ПО, изменять конфигурцию и т.п. Мы решили все эти операции автоматизировать и внедрить систему удаленного управления конфигурациями. Изучив имеющиеся решения, мы остановили свой выбор на Ansible.

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

    Что такое Ansible?

    Ansible берет на себя всю работу по приведению удаленных серверов в необходимое состояние. Администратору необходимо лишь описать, как достичь этого состояния с помощью так называемых сценариев (playbooks; это аналог рецептов в Chef). Такая технология позволяет очень быстро осуществлять переконфигурирование системы: достаточно всего лишь добавить несколько новых строк в сценарий.

    Почему Ansible?

    Преимущества Ansible по сравнению с другими аналогичными решениями (здесь в первую очередь следует назвать такие продукты, как Puppet, Chef и Salt) заключаются в следующем:

    Push или pull?

    “Из коробки” все сценарии и команды выполняются методом push: когда возникает необходимость, мы запускаем сценарий, и он последовательно выполняется на удалённых серверах. Однако разработчики также предусмотрели метод pull и даже написали специальное приложение для установки необходимой для этого части ansible на удалённые хосты.

    Установка

    Требования для установки Ansible минимальны. На машине с которой производится управление должен быть установлен Python 2.6 или выше. На управляемых узлах должен быть установлен только Python версии не ниже 2.4, но он, как правило, по умолчанию включен в состав большинства дистрибутивов linux-систем. MS Windows не поддерживается.

    Вам также могут потребоваться следующие модули Python, устанавливаемые через pip или пакетный менеджер вашей операционной системы:

    В Ubuntu установка самого Ansible и зависимостей осуществляется добавлением репозитория и установкой пакета:

    О процедуре установки в других ОС можно прочитать в официальной документации .

    Группы серверов

    Список групп серверов, которыми нужно управлять, Ansible может получать двумя основными способами:

    • из специального текстового файла (далее этот вариант будет рассмотрен более подробно);
    • с помощью внешнего скрипта, возвращающего нужный нам список серверов, например из MongoDB . В официальном github-репозитории есть готовые скрипты для получения списка из Cobbler , Digital Ocean , EC2 , Linode , OpenStack Nova , Openshift , Spacewalk , Vagrant , Zabbix .

    Файл hosts

    Более подробно о файле hosts и правилах его написания можно почитать в официальной документации .

    Информация об узлах (Facts)

    Перед внесением изменений Ansible подключается к управляемым узлам и собирает информацию о них: о сетевых интерфейсах и их состоянии, об установленной операционной системе и т.п. Он может делать это как с помощью собственного модуля, так и с помощью инструментов ohai и facter, если они установлены (такая возможность специально предусмотрена для пользователей, уже имеющих опыт работы с системами удаленного управления конфигурациями: ohai и facter являются библиотеками фактов для Chef и Puppet).

    Переменные

    Во время деплоя, как правило, требуется не только установить какое-либо приложение, но и настроить его в соответствии с определенными параметрами на основании принадлежности к группе серверов или индивидуально (например, ip-адрес BGP-соседа и номер его AS или параметры для базы данных). Как уже было сказано, загромождать файл hosts будет не очень красиво, поэтому разработчики Ansible пошли следующим путём:

    • файлы с переменными групп хранятся в директории “group_vars/имя_группы”;
    • файлы с переменными хостов в директории “hosts_vars/имя_хоста”;
    • файлы с переменными роли (о них речь пойдет ниже) в директории “имя_роли/vars/имя_задачи.yml”;

    Помимо пользовательских переменных можно (и даже нужно) использовать факты, собранные ansible перед выполнением сценариев и отдельных задач.

    Модули Ansible

    В состав Ansible входит огромное количество модулей для развёртывания, контроля и управления различными компонентами, которые можно условно разделить на следующие группы (в скобках приведены названия некоторых продуктов и сервисов):

    • облачные ресурсы и виртуализация (Openstack, libvirt);
    • базы данных (MySQL, Postgresql, Redis, Riak);
    • файлы (шаблонизация, регулярные выражения, права доступа);
    • мониторинг (Nagios, monit);
    • оповещения о ходе выполнения сценария (Jabber, Irc, почта, MQTT, Hipchat);
    • сеть и сетевая инфраструктура (Openstack, Arista);
    • управление пакетами (apt, yum, rhn-channel, npm, pacman, pip, gem);
    • система (LVM, Selinux, ZFS, cron, файловые системы, сервисы, модули ядра);
    • работа с различными утилитами (git, hg).

    О том, с чем умеет работать Ansible “из коробки”, можно прочитать в официальной документации . Список действительно впечатляет.

    Примеры простых задач

    Следующий пример соберёт информацию о хостах и выведёт её на консоль в формате JSON:

    $ ansible dnsservers -m setup

    А вот так можно создать логический том (или, в зависимости от текущего состояния, изменить его размер) с именем examplevolume в группе examplegroup:

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

    Cценарии (playbooks)

    Чтобы выполнить сценарий используется команда ansible-playbook со следующим сиснтаксисом:

    Основными параметрами/группами простого сценария являются:

    Также в сценарии перед непосредственным описанием задач могут быть указаны следующие параметры или группы параметров:

    Рассмотрим все эти разделы более подробно.

    В разделе hosts указывается группа управляемых узлов, к которой будут применены описываемые в сценарии изменения.

    Так, строка формата:

    означает, что изменения будут применены к узлам из группы webservers.

    Сценарии могут выполняться не только от имени пользователя, под именем которого установлено соедиение, но и любого другого. В следующем примере авторизация на хосте будет произведена с именем yourname, но задачи будут выполняться от имени пользователя root (если, конечно, этому пользователю это разрешено):

    Если добавить параметр “user: postgres”, то все действия будут выполняться с привилегиями пользователя postgres.

    В разделе vars указываются переменные, которые будут использованы в сценарии, и их значения:

    Список изменений, которые необходимо произвести на управляемом узле, приводится в разделе tasks. Каждой задаче (task) присваивается имя (name). Далее указываются модули Ansible, которые будут задействованы при ее выполнении:

    Для каждой задачи можно указывать пользователя, от имени которого она будет выполнена:

    Шаблонизация

    В Ansbile используется шаблонизатор Jinja2 . Приведём пример шаблона (часть конфига powerdns ):

    В приведённом примере мы подставляем в шаблон следующие значения:

    Обработку шаблонов и, в данном случае, генерацию конфигурационного файла выполняет модуль template ; он же может задать необходимые права доступа и изменить владельца/группу:

    Обратим внимание на то, что файл шаблона и файл с паролем пользователя базы данных находятся на машине управления, а результатом будет файл на удалённом узле.

    Обработчики событий (Handlers)

    Ansible не просто выполняет задачи в указанном порядке, но и проверяет их состояние на наличие изменений. Если при выполнении сценария требовалось, например, добавить строку в конфигурационный файл, и в результате выполнения он изменился (необходимой строки действительно не было), то Ansible может выполнить специальную задачу, описанную как обработчик события (handler). Если при выполнении строка уже была в конфигурационном файле, то обработчик выполнен не будет. Обработчики событий описываются в конце сценария; в описании задачи они указываются через параметр notify. Приведём пример:

    Контроль выполнения

    Допустим, что при выполнении сценария нам нужно проверять определённые переменные или состояния и, в зависимости от них, выполнять или не выполнять какие-либо задачи. Для этого можно использовать оператор “when”:

    Делегирование задачи другому хосту

    Иногда требуется выполнить задачу на определённом узле, но в контексте другого узла. Например, во время обновления узла может возникнуть необходимость отключить для него мониторинг, находящийся на отдельном сервере. Для этого используется управляющая директива delegate_to. Приведём пример:

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

    Структура проекта

    Пример сценария

    Чтобы понять, как это все работает, рассмотрим практический пример: простой сценарий развёртывания новой версии PostgreSQL 9.3 на debian-based ОС. Роли в этом примере не используются.

    Ansible AWX

    Заключение

    Читайте также:

      
    • Dr web постоянно просит разрешение
      
    • Hikvision где qr код
      
    • Как в php сделать ссылку на другой файл
      
    • Курсор установлен на файле my txt что произойдет с файлом при нажатии клавиши delete
      
    • Vegas pro сохранить видео без потери качества