Spec-Zone.ru › Ansible 2.6

Руководство по Amazon Web Services

Введение

Ansible содержит ряд модулей для управления Amazon Web Services (AWS). Цель этого раздела — объяснить, как комбинировать модули Ansible (и использовать скрипты инвентаризации) для использования Ansible в контексте AWS.

Требования к модулям AWS минимальны.

Все модули требуют и тестируются с последними версиями boto. Вам нужно будет установить этот модуль Python на вашей управляющей машине. Boto можно установить из дистрибутива вашей операционной системы или с помощью «pip install boto» Python.

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

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

- hosts: localhost
  connection: local
  gather_facts: False
  tasks:
    - ...

Аутентификация

Аутентификация с модулями, связанными с AWS, выполняется путём указания вашего ключа доступа и секретного ключа в качестве переменных среды или аргументов модуля.

Для переменных среды:

export AWS_ACCESS_KEY_ID='AK123'
export AWS_SECRET_ACCESS_KEY='abc123'

Для хранения этих данных в файле vars_file, желательно зашифрованном с помощью ansible-vault:

---
ec2_access_key: "--REMOVED--"
ec2_secret_key: "--REMOVED--"

Обратите внимание, что если вы храните свои учетные данные в файле vars_file, вам необходимо ссылаться на них в каждом модуле AWS. Например:

- ec2
  aws_access_key: "{{ec2_access_key}}"
  aws_secret_key: "{{ec2_secret_key}}"
  image: "..."

Развертывание

Модуль ec2 развертывает и удаляет экземпляры в EC2.

Следующий пример показывает, как убедиться, что в EC2 существует только 5 экземпляров, помеченных как «Demo».

В примере ниже «exact_count» экземпляров установлен в 5. Это означает, что если уже существуют 0 экземпляров, будут созданы 5 новых. Если было 2 экземпляра, будет создано только 3, а если 8, то 3 экземпляра будут удалены.

Подсчитывается то, что указано параметром «count_tag». Параметр «instance_tags» используется для применения тегов к вновь созданному экземпляру.:

# demo_setup.yml

- hosts: localhost
  connection: local
  gather_facts: False

  tasks:

    - name: Provision a set of instances
      ec2:
         key_name: my_key
         group: test
         instance_type: t2.micro
         image: "{{ ami_id }}"
         wait: true
         exact_count: 5
         count_tag:
            Name: Demo
         instance_tags:
            Name: Demo
      register: ec2

Данные о созданных экземплярах сохраняются ключевым словом «register» в переменной с именем «ec2».

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

# demo_setup.yml

- hosts: localhost
  connection: local
  gather_facts: False

  tasks:

    - name: Provision a set of instances
      ec2:
         key_name: my_key
         group: test
         instance_type: t2.micro
         image: "{{ ami_id }}"
         wait: true
         exact_count: 5
         count_tag:
            Name: Demo
         instance_tags:
            Name: Demo
      register: ec2

   - name: Add all instance public IPs to host group
     add_host: hostname={{ item.public_ip }} groups=ec2hosts
     loop: "{{ ec2.instances }}"

После создания группы хостов второй playbook в нижней части того же файла playbook может содержать некоторые шаги конфигурации:

# demo_setup.yml

- name: Provision a set of instances
  hosts: localhost
  # ... AS ABOVE ...

- hosts: ec2hosts
  name: configuration play
  user: ec2-user
  gather_facts: true

  tasks:

     - name: Check NTP service
       service: name=ntpd state=started

Инвентаризация хостов

После запуска ваших узлов вам, вероятно, нужно будет с ними снова связаться. В настройках облака лучше не поддерживать статический список имён облачных хостов в текстовых файлах. Лучший способ сделать это — использовать скрипт динамической инвентаризации ec2. См. Работа с динамической инвентаризацией.

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

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

Теги, группы и переменные

При использовании скрипта инвентаризации ec2 хосты автоматически появляются в группах на основе того, как они помечены в EC2.

Например, если хосту задан тег «class» со значением «webserver», он будет автоматически обнаруживаться динамической группой следующим образом:

- hosts: tag_class_webserver
  tasks:
    - ping

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

В этом примере, если мы хотим определить переменные, которые автоматически применяются к каждой машине, помеченной тегом «class» как «webserver», можно использовать «group_vars» в ansible. См. Разделение данных хоста и группы.

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

Автомасштабирование с Ansible Pull

Функция Amazon Autoscaling автоматически увеличивает или уменьшает емкость в зависимости от нагрузки. В документации облака также показаны модули Ansible, которые могут настроить политику автомасштабирования.

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

Для этого можно предварительно создать образы машин, содержащие вызов ansible-pull. Ansible-pull — это командная утилита, которая извлекает playbook из сервера git и выполняет его локально.

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

Прочитайте ansible-pull для получения дополнительной информации о playbook в режиме pull.

Автомасштабирование с Ansible Tower

Ansible Tower также содержит очень полезную функцию для случаев использования автомасштабирования. В этом режиме простой скрипт curl может вызывать определённый URL, и сервер «вызовет» запрос и настроит экземпляр, который запускается. Это может быть отличный способ переконфигурации временных узлов. См. документацию по установке и продуктам Tower для получения более подробной информации.

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

Ansible с (и против) CloudFormation

CloudFormation — это технология Amazon для определения стека облака в виде JSON-документа.

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

Однако для пользователей, которые решили использовать CloudFormation, существует модуль Ansible, который можно использовать для применения шаблона CloudFormation к Amazon.

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

См. примеры в модуле Ansible CloudFormation для получения более подробной информации.

Создание образов AWS с помощью Ansible

Многие пользователи могут захотеть, чтобы образы загружались с более полной конфигурацией, а не с её полной конфигурацией после создания. Для этого можно использовать различные программы с playbooks Ansible для определения и загрузки базового образа, который получит собственный идентификатор AMI для использования с модулем ec2 или другими модулями Ansible AWS, такими как ec2_asg или модуль cloudformation. Возможные инструменты включают Packer, aminator и модуль ec2_ami Ansible.

Как правило, мы наблюдаем, что большинство пользователей используют Packer.

См. документацию Packer по локальному провайдеру Ansible для Packer и удаленному провайдеру Ansible для Packer.

Если вы не хотите использовать Packer в данный момент, конфигурирование базового образа с помощью Ansible после развертывания (как показано выше) приемлемо.

Следующие шаги: изучение модулей

Ansible поставляется с множеством модулей для настройки широкого спектра сервисов EC2. Просмотрите категорию «Облако» в документации по модулям для получения полного списка с примерами.

См. также

Все модули
Вся документация по модулям Ansible
Работа с playbooks
Введение в playbooks
Делегирование, обновление по очереди и локальные действия
Делегирование, полезно для работы с балансировщиками нагрузки, облаками и локальными шагами.
Список рассылки пользователей
Есть вопрос? Загляните в группу Google!
irc.freenode.net
IRC-чат-канал #ansible

© 2012–2018 Michael DeHaan
© 2018–2019 Red Hat, Inc.
Licensed under the GNU General Public License version 3.
https://docs.ansible.com/ansible/2.6/scenario_guides/guide_aws.html

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API