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

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

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

Для переменных окружения:

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

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

---
aws_access_key: "--REMOVED--"
aws_secret_key: "--REMOVED--"

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

- amazon.aws.ec2_instance:
    aws_access_key: "{{ aws_access_key }}"
    aws_secret_key: "{{ aws_secret_key }}"
    key_name: "example-ssh-key"
    image_id: "..."

Их также можно указать с помощью “module_defaults” в начале сценария playbook:

# demo_setup.yml

- hosts: localhost
  module_defaults:
    group/aws:
      aws_access_key: '{{ aws_access_key }}'
      aws_secret_key: '{{ aws_secret_key }}'
      region: '{{ region }}'
  tasks:
    - amazon.aws.ec2_instance:
        key_name: "example-ssh-key"
        image_id: "..."

Учётные данные также можно получить из профиля учётных данных:

- amazon.aws.ec2_instance:
    aws_profile: default
    key_name: "example-ssh-key"
    image_id: "..."

Подготовка ресурсов

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

Ниже приведён пример создания экземпляра с назначенным публичным IP-адресом.

Параметр “name” создаст для экземпляра тег “tag:Name”. Дополнительные теги можно указать с помощью параметра “tags”:

# demo_setup.yml

- hosts: localhost
  gather_facts: False

  tasks:

    - name: Provision an EC2 instance with a public IP address
      amazon.aws.ec2_instance:
        name: Demo
        key_name: "example-ssh-key"
        vpc_subnet_id: subnet-5ca1ab1e
        instance_type: c5.large
        security_group: default
        network:
          assign_public_ip: true
        image_id: ami-123456
        tags:
          Environment: Testing
      register: result

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

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

# demo_setup.yml

- hosts: localhost
  gather_facts: False

  tasks:

    - name: Provision an EC2 instance with a public IP address
      amazon.aws.ec2_instance:
        name: Demo
        key_name: "example-ssh-key"
        vpc_subnet_id: subnet-5ca1ab1e
        instance_type: c5.large
        security_group: default
        network:
          assign_public_ip: true
        image_id: ami-123456
        tags:
          Environment: Testing
      register: result

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

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

# 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

Группы безопасности

Группы безопасности в AWS учитывают состояние соединений. Ответ на запрос от вашего экземпляра может проходить независимо от правил входящего трафика группы безопасности, и наоборот. Если вы хотите разрешить трафик только со службой AWS S3, необходимо получить текущие диапазоны IP-адресов AWS S3 для одного региона и применить их в качестве правила исходящего трафика:

- name: fetch raw ip ranges for aws s3
  set_fact:
    raw_s3_ranges: "{{ lookup('aws_service_ip_ranges', region='eu-central-1', service='S3', wantlist=True) }}"

- name: prepare list structure for ec2_group module
  set_fact:
    s3_ranges: "{{ s3_ranges | default([]) + [{'proto': 'all', 'cidr_ip': item, 'rule_desc': 'S3 Service IP range'}] }}"
  loop: "{{ raw_s3_ranges }}"

- name: set S3 IP ranges to egress rules
  ec2_group:
    name: aws_s3_ip_ranges
    description: allow outgoing traffic to aws S3 service
    region: eu-central-1
    state: present
    vpc_id: vpc-123456
    purge_rules: true
    purge_rules_egress: true
    rules: []
    rules_egress: "{{ s3_ranges }}"
    tags:
      Name: aws_s3_ip_ranges

Инвентаризация узлов

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

Плагин также возвращает экземпляры, созданные не с помощью Ansible, и позволяет Ansible управлять ими.

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

При использовании плагина инвентаризации можно настроить дополнительную структуру инвентаризации на основе метаданных, возвращаемых AWS.

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

plugin: amazon.aws.aws_ec2
keyed_groups:
  - prefix: tag
    key: ec2_tags

Затем в сценарии play можно выбрать все экземпляры с тегом “class”, значение которого равно “webserver”:

- hosts: tag_class_webserver
  tasks:
    - ping

Эти группы также можно использовать с ‘group_vars’, чтобы задавать переменные, автоматически применяемые к соответствующим экземплярам.

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

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

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

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

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

Дополнительные сведения о сценариях playbook в режиме pull см. в разделе ansible-pull.

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

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

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

Ansible вместе с CloudFormation (и в сравнении с ним)

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

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

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

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

Дополнительные сведения см. в примерах модуля Ansible CloudFormation.

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

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

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

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

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

Дальнейшие шаги: изучение модулей

Ansible поставляется с большим количеством модулей для настройки широкого спектра сервисов EC2. Полный список модулей с примерами см. в категории “Cloud” документации по модулям.