Руководство по Microsoft Azure

Ansible включает набор модулей для взаимодействия с Azure Resource Manager, предоставляя вам инструменты для лёгкого создания и управления инфраструктурой в облаке Microsoft Azure.

Требования

Использование модулей Azure Resource Manager требует наличия установленных модулей Azure SDK на хосте, на котором работает Ansible.

$ pip install 'ansible[azure]'

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

$ pip install .[azure]

Вы также можете напрямую запустить Ansible в Azure Cloud Shell, где Ansible уже предварительно установлен.

Авторизация в Azure

Использование модулей Azure Resource Manager требует авторизации в API Azure. Вы можете выбрать одну из двух стратегий авторизации:

• Имя пользователя/пароль Active Directory
• Учетные данные службы-принципала

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

Использование службы-принципала

Теперь есть подробный официальный учебник, описывающий создание службы-принципала.

После прохождения учебника у вас будут:

• Ваш идентификатор клиента, который находится в поле «client id» на странице «Настройка» вашего приложения в портале Azure
• Ваш секретный ключ, сгенерированный при создании приложения. Вы не можете просмотреть ключ после создания. Если вы потеряли ключ, вам необходимо создать новый на странице «Настройка» вашего приложения.
• И, наконец, идентификатор клиента. Это UUID (например, ABCDEFGH-1234-ABCD-1234-ABCDEFGHIJKL), указывающий на AD, содержащий ваше приложение. Вы найдёте его в URL внутри портала Azure или в разделе «Просмотр конечных точек» любого URL.

Использование имени пользователя/пароля Active Directory

Чтобы создать имя пользователя/пароль Active Directory:

• Подключитесь к классическому порталу Azure с помощью своей учетной записи администратора
• Создайте пользователя в вашей стандартной AAD. Вы НЕ должны активировать многофакторную аутентификацию
• Перейдите в Настройки - Администраторы
• Нажмите Добавить и введите адрес электронной почты нового пользователя.
• Установите флажок подписки, с которой вы хотите протестировать этого пользователя.
• Войдите в портал Azure с этим новым пользователем, чтобы изменить временный пароль на новый. Вы не сможете использовать временный пароль для входа с помощью OAuth.

Предоставление учетных данных модулям Azure

Модули предлагают несколько способов предоставления ваших учетных данных. Для инструмента CI/CD, такого как Ansible Tower или Jenkins, вы, скорее всего, захотите использовать переменные окружения. Для локального разработки вы можете сохранить свои учетные данные в файле в домашней директории. И, конечно, вы всегда можете передать учетные данные в качестве параметров задаче внутри playbook. Порядок приоритета: параметры, затем переменные окружения, и, наконец, файл в вашей домашней директории.

Использование переменных окружения

Для передачи учетных данных службы-принципала через среду, определите следующие переменные:

• AZURE_CLIENT_ID
• AZURE_SECRET
• AZURE_SUBSCRIPTION_ID
• AZURE_TENANT

Для передачи учетных данных имени пользователя/пароля Active Directory через среду, определите следующие переменные:

• AZURE_AD_USER
• AZURE_PASSWORD
• AZURE_SUBSCRIPTION_ID

Для передачи учетных данных имени пользователя/пароля Active Directory в ADFS через среду, определите следующие переменные:

• AZURE_AD_USER
• AZURE_PASSWORD
• AZURE_CLIENT_ID
• AZURE_TENANT
• AZURE_ADFS_AUTHORITY_URL

«AZURE_ADFS_AUTHORITY_URL» необязательно. Она нужна только при наличии собственного ADFS-сервера, например https://yourdomain.com/adfs.

Сохранение в файле

При работе в среде разработки может быть желательно хранить учетные данные в файле. Модули будут искать учетные данные в $HOME/.azure/credentials. Этот файл имеет формат ini. Он будет выглядеть следующим образом:

[default]
subscription_id=xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
client_id=xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
secret=xxxxxxxxxxxxxxxxx
tenant=xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

В файле учетных данных можно хранить несколько наборов учетных данных, создавая несколько разделов. Каждый раздел считается профилем. Модули автоматически ищут профиль [default]. Определите AZURE_PROFILE в переменных среды или передайте параметр профиля для указания конкретного профиля.

Передача в качестве параметров

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

• client_id
• secret
• subscription_id
• tenant

Или передайте следующие параметры для учетных данных имени пользователя/пароля Active Directory:

• ad_user
• password
• subscription_id

Или передайте следующие параметры для учетных данных имени пользователя/пароля ADFS:

• ad_user
• password
• client_id
• tenant
• adfs_authority_url

«adfs_authority_url» необязательно. Она нужна только при наличии собственного ADFS-сервера, например https://yourdomain.com/adfs.

Другие облачные среды

Для использования облака Azure помимо стандартного общедоступного облака (например, Azure China Cloud, Azure US Government Cloud, Azure Stack), передайте аргумент «cloud_environment» в модули, настройте его в профиле учетных данных или установите переменную окружения «AZURE_CLOUD_ENVIRONMENT». Значение может быть именем облака, как определено Azure Python SDK (например, «AzureChinaCloud», «AzureUSGovernment»; по умолчанию «AzureCloud»), или URL обнаружения метаданных Azure (для Azure Stack).

Создание виртуальных машин

Существует два способа создания виртуальной машины, оба с использованием модуля azure_rm_virtualmachine. Мы можем либо создать хранилище, сетевой интерфейс, группу безопасности и общедоступный IP-адрес и передать имена этих объектов в модуль в качестве параметров, либо позволить модулю выполнить работу за нас и принять значения по умолчанию.

Создание отдельных компонентов

Модуль Azure доступен для создания хранилища, виртуальной сети, подсети, сетевого интерфейса, группы безопасности и общедоступного IP-адреса. Вот полный пример создания каждого из них и передачи имён в модуль azure.azcollection.azure_rm_virtualmachine в конце:

- name: Create storage account
  azure.azcollection.azure_rm_storageaccount:
    resource_group: Testing
    name: testaccount001
    account_type: Standard_LRS

- name: Create virtual network
  azure.azcollection.azure_rm_virtualnetwork:
    resource_group: Testing
    name: testvn001
    address_prefixes: "10.10.0.0/16"

- name: Add subnet
  azure.azcollection.azure_rm_subnet:
    resource_group: Testing
    name: subnet001
    address_prefix: "10.10.0.0/24"
    virtual_network: testvn001

- name: Create public ip
  azure.azcollection.azure_rm_publicipaddress:
    resource_group: Testing
    allocation_method: Static
    name: publicip001

- name: Create security group that allows SSH
  azure.azcollection.azure_rm_securitygroup:
    resource_group: Testing
    name: secgroup001
    rules:
      - name: SSH
        protocol: Tcp
        destination_port_range: 22
        access: Allow
        priority: 101
        direction: Inbound

- name: Create NIC
  azure.azcollection.azure_rm_networkinterface:
    resource_group: Testing
    name: testnic001
    virtual_network: testvn001
    subnet: subnet001
    public_ip_name: publicip001
    security_group: secgroup001

- name: Create virtual machine
  azure.azcollection.azure_rm_virtualmachine:
    resource_group: Testing
    name: testvm001
    vm_size: Standard_D1
    storage_account: testaccount001
    storage_container: testvm001
    storage_blob: testvm001.vhd
    admin_username: admin
    admin_password: Password!
    network_interfaces: testnic001
    image:
      offer: CentOS
      publisher: OpenLogic
      sku: '7.1'
      version: latest

Каждый из модулей Azure предоставляет различные параметры. Не все варианты показаны в примере выше. См. каждый отдельный модуль для получения дополнительных подробностей и примеров.

Создание виртуальной машины с параметрами по умолчанию

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

azure.azcollection.azure_rm_virtualmachine:
  resource_group: Testing
  name: testvm10
  vm_size: Standard_D1
  admin_username: chouseknecht
  ssh_password_enabled: false
  ssh_public_keys: "{{ ssh_keys }}"
  image:
    offer: CentOS
    publisher: OpenLogic
    sku: '7.1'
    version: latest

Создание виртуальной машины в зонах доступности

Если вы хотите создать VM в зоне доступности, рассмотрите следующее:

• Диск ОС и все данные должны быть «управляемыми дисками», а не «неуправляемыми дисками».
• При создании VM с модулем azure.azcollection.azure_rm_virtualmachine, вам необходимо явно установить параметр managed_disk_type, чтобы изменить диск ОС на управляемый диск. В противном случае диск ОС станет неуправляемым диском.
• При создании диска данных с модулем azure.azcollection.azure_rm_manageddisk, вам нужно явно указать параметр storage_account_type, чтобы сделать его управляемым диском. В противном случае диск данных будет неуправляемым.
• Управляемый диск не требует хранилища или контейнера, в отличие от неуправляемого диска. Обратите внимание, что после создания VM на неуправляемом диске автоматически создаётся ненужный контейнер «vhds».
• При создании IP-адреса с модулем azure.azcollection.azure_rm_publicipaddress, необходимо установить параметр sku в standard. В противном случае IP-адрес не может быть использован в зоне доступности.

Динамический скрипт инвентаризации

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

Скрипт инвентаризации Azure Resource Manager называется azure_rm.py. Он выполняет аутентификацию в API Azure точно так же, как и модули Azure, то есть вы можете определить те же переменные окружения, что и в Разделе по переменным окружения, создать файл $HOME/.azure/credentials (также описанный выше в Разделе по хранению в файле) или передать параметры командной строки. Чтобы увидеть доступные параметры командной строки, выполните:

$ wget https://raw.githubusercontent.com/ansible-collections/community.general/main/scripts/inventory/azure_rm.py
$ ./azure_rm.py --help

Как и все скрипты динамической инвентаризации, скрипт может быть выполнен напрямую, передан в качестве параметра команде ansible или передан непосредственно в ansible-playbook с помощью параметра -i. В любом случае, скрипт генерирует JSON, представляющий все хосты, найденные в вашей подписке Azure. Вы можете ограничить это только хостами, найденными в определённом наборе групп ресурсов Azure, или даже до конкретного хоста.

Для каждого хоста скрипт инвентаризации предоставляет следующие переменные хоста:

{
  "ansible_host": "XXX.XXX.XXX.XXX",
  "computer_name": "computer_name2",
  "fqdn": null,
  "id": "/subscriptions/subscription-id/resourceGroups/galaxy-production/providers/Microsoft.Compute/virtualMachines/object-name",
  "image": {
    "offer": "CentOS",
    "publisher": "OpenLogic",
    "sku": "7.1",
    "version": "latest"
  },
  "location": "westus",
  "mac_address": "00-00-5E-00-53-FE",
  "name": "object-name",
  "network_interface": "interface-name",
  "network_interface_id": "/subscriptions/subscription-id/resourceGroups/galaxy-production/providers/Microsoft.Network/networkInterfaces/object-name1",
  "network_security_group": null,
  "network_security_group_id": null,
  "os_disk": {
    "name": "object-name",
    "operating_system_type": "Linux"
  },
  "plan": null,
  "powerstate": "running",
  "private_ip": "172.26.3.6",
  "private_ip_alloc_method": "Static",
  "provisioning_state": "Succeeded",
  "public_ip": "XXX.XXX.XXX.XXX",
  "public_ip_alloc_method": "Static",
  "public_ip_id": "/subscriptions/subscription-id/resourceGroups/galaxy-production/providers/Microsoft.Network/publicIPAddresses/object-name",
  "public_ip_name": "object-name",
  "resource_group": "galaxy-production",
  "security_group": "object-name",
  "security_group_id": "/subscriptions/subscription-id/resourceGroups/galaxy-production/providers/Microsoft.Network/networkSecurityGroups/object-name",
  "tags": {
    "db": "mysql"
  },
  "type": "Microsoft.Compute/virtualMachines",
  "virtual_machine_size": "Standard_DS4"
}

Группы хостов

По умолчанию хосты сгруппированы по:

• azure (все хосты)
• имени местоположения
• имени группы ресурсов
• имени группы безопасности
• ключу тега
• значению ключа тега
• типу операционной системы на диске ОС (Windows/Linux)

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

ПРИМЕЧАНИЕ: Файл .ini будет иметь приоритет над переменными окружения.

ПРИМЕЧАНИЕ: Имя файла .ini — это имя скрипта инвентаризации (т.е., «azure_rm») с расширением «.ini». Это позволяет копировать, переименовывать и настраивать скрипт инвентаризации и иметь соответствующие файлы .ini в одной директории.

Управление группировкой с помощью следующих переменных, определённых в среде:

• AZURE_GROUP_BY_RESOURCE_GROUP=yes
• AZURE_GROUP_BY_LOCATION=yes
• AZURE_GROUP_BY_SECURITY_GROUP=yes
• AZURE_GROUP_BY_TAG=yes
• AZURE_GROUP_BY_OS_FAMILY=yes

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

• AZURE_RESOURCE_GROUPS=resource_group_a,resource_group_b

Выберите хосты для определённого ключа тега, назначив список ключей тегов, разделённых запятыми, в:

• AZURE_TAGS=key1,key2,key3

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

• AZURE_LOCATIONS=eastus,eastus2,westus

Или, выберите хосты для определённых пар ключ:значение тегов, назначив список пар ключ:значение, разделённых запятыми, в:

• AZURE_TAGS=key1:value1,key2:value2

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

• AZURE_INCLUDE_POWERSTATE=no

Пример файла azure_rm.ini приведён вместе со скриптом инвентаризации в здесь. Файл .ini будет содержать следующее:

[azure]
# Control which resource groups are included. By default all resources groups are included.
# Set resource_groups to a comma separated list of resource groups names.
#resource_groups=

# Control which tags are included. Set tags to a comma separated list of keys or key:value pairs
#tags=

# Control which locations are included. Set locations to a comma separated list of locations.
#locations=

# Include powerstate. If you don't need powerstate information, turning it off improves runtime performance.
# Valid values: yes, no, true, false, True, False, 0, 1.
include_powerstate=yes

# Control grouping with the following boolean flags. Valid values: yes, no, true, false, True, False, 0, 1.
group_by_resource_group=yes
group_by_location=yes
group_by_security_group=yes
group_by_tag=yes
group_by_os_family=yes

Примеры

Вот несколько примеров использования скрипта инвентаризации:

# Download inventory script
$ wget https://raw.githubusercontent.com/ansible-collections/community.general/main/scripts/inventory/azure_rm.py

# Execute /bin/uname on all instances in the Testing resource group
$ ansible -i azure_rm.py Testing -m shell -a "/bin/uname -a"

# Execute win_ping on all Windows instances
$ ansible -i azure_rm.py windows -m win_ping

# Execute ping on all Linux instances
$ ansible -i azure_rm.py linux -m ping

# Use the inventory script to print instance specific information
$ ./azure_rm.py --host my_instance_host_name --resource-groups=Testing --pretty

# Use the inventory script with ansible-playbook
$ ansible-playbook -i ./azure_rm.py test_playbook.yml

Вот простой playbook для проверки скрипта инвентаризации Azure:

- name: Test the inventory script
  hosts: azure
  connection: local
  gather_facts: no
  tasks:
    - debug:
        msg: "{{ inventory_hostname }} has powerstate {{ powerstate }}"

Вы можете выполнить playbook с помощью чего-то вроде:

$ ansible-playbook -i ./azure_rm.py test_azure_inventory.yml

Отключение проверки сертификатов на конечных точках Azure

Когда присутствует прокси-сервер HTTPS или используется Azure Stack, может потребоваться отключить проверку сертификатов для конечных точек Azure в модулях Azure. Это не рекомендуется с точки зрения безопасности, но может потребоваться, если хранилище системных сертификатов нельзя изменить для включения необходимого сертификата CA. Проверка сертификатов может контролироваться установкой значения «cert_validation_mode» в профиле учетных данных, через переменную среды «AZURE_CERT_VALIDATION_MODE» или путём передачи аргумента «cert_validation_mode» в любой модуль Azure. Значение по умолчанию — «validate»; установка значения на «ignore» предотвратит всю проверку сертификатов. Аргумент модуля имеет приоритет над значением в профиле учетных данных, которое имеет приоритет над значением переменной окружения.