Spec-Zone.ru › Ansible 2.5

Руководство по Google Cloud Platform

Введение

Примечание

Этот раздел документации находится в стадии разработки. Мы работаем над добавлением больше примеров по всем модулям GCE и способам их совместной работы. Улучшения посредством запросов на вытягивание с github приветствуются!

Ansible содержит модули для управления ресурсами Google Compute Engine, включая создание виртуальных машин, управление сетевым доступом, работу с постоянными дисками и управление балансировщиками нагрузки. Кроме того, существует плагин инвентаризации, который может автоматически импортировать все ваши виртуальные машины GCE в динамическую инвентаризацию Ansible и создавать группы по тегам и другим свойствам.

Все модули GCE требуют модуль apache-libcloud, который можно установить с помощью pip:

$ pip install apache-libcloud

Примечание

Если вы используете Ansible на Mac OS X, libcloud также должен иметь доступ к цепочке сертификатов CA. Вам нужно будет скачать один (его можно получить здесь.)

Учетные данные

Для работы с модулями GCE вам сначала нужно получить учетные данные в формате JSON:

  1. Создать учетную запись сервиса
  2. Загрузить учетные данные в формате JSON

Существует три способа предоставить учетные данные Ansible, чтобы он мог взаимодействовать с Google Cloud для действий по развертыванию и конфигурированию:

Примечание

Если вы хотите использовать учетные данные в формате JSON, вам необходимо иметь libcloud >= 0.17.0

  • путем прямого предоставления модулям
  • путем заполнения файла secrets.py
  • путем задания переменных окружения

Передача учетных данных модулям

Для модулей GCE вы можете указать учетные данные в качестве аргументов:

  • service_account_email: электронный адрес, связанный с проектом
  • credentials_file: путь к файлу учетных данных в формате JSON
  • project_id: идентификатор проекта

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

- name: Create instance(s)
  hosts: localhost
  connection: local
  gather_facts: no

  vars:
    service_account_email: unique-id@developer.gserviceaccount.com
    credentials_file: /path/to/project.json
    project_id: project-id
    machine_type: n1-standard-1
    image: debian-7

  tasks:

   - name: Launch instances
     gce:
         instance_names: dev
         machine_type: "{{ machine_type }}"
         image: "{{ image }}"
         service_account_email: "{{ service_account_email }}"
         credentials_file: "{{ credentials_file }}"
         project_id: "{{ project_id }}"

При запуске Ansible внутри виртуальной машины GCE вы можете использовать учетные данные учетной записи сервиса из локального сервера метаданных, задав как service_account_email, так и credentials_file пустой строкой.

Настройка модулей с помощью secrets.py

Создайте файл secrets.py, как показано ниже, и поместите его в папку, которая находится в вашей $PYTHONPATH:

GCE_PARAMS = ('i...@project.googleusercontent.com', '/path/to/project.json')
GCE_KEYWORD_PARAMS = {'project': 'project_id', 'datacenter': 'gce_zone'}

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

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

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

GCE_PARAMS = ('', '')
GCE_KEYWORD_PARAMS = {'project': 'project_id', 'datacenter': ''}

Настройка модулей с помощью переменных окружения

Установите следующие переменные окружения перед запуском Ansible для настройки ваших учетных данных:

GCE_EMAIL
GCE_PROJECT
GCE_CREDENTIALS_FILE_PATH

Динамическая инвентаризация GCE

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

Обратите внимание, что при использовании скрипта инвентаризации gce.py, вам также необходимо заполнить файл gce.ini, который вы можете найти в каталоге contrib/inventory вашей версии ansible.

Для использования скрипта динамической инвентаризации GCE скопируйте gce.py из contrib/inventory в каталог инвентаризации и сделайте его исполняемым. Вы можете указать учетные данные для gce.py с помощью переменной окружения GCE_INI_PATH — по умолчанию ищется файл gce.ini в той же папке, что и скрипт инвентаризации.

Давайте проверим, работает ли инвентаризация:

$ ./gce.py --list

Вы должны увидеть вывод, описывающий хосты, если таковые имеются, работающие в Google Compute Engine.

Теперь давайте проверим, можем ли мы использовать скрипт инвентаризации для взаимодействия с Google.

$ GCE_INI_PATH=~/.gce.ini ansible all -i gce.py -m setup
hostname | success >> {
  "ansible_facts": {
    "ansible_all_ipv4_addresses": [
      "x.x.x.x"
    ],

Как и во всех скриптах динамической инвентаризации в Ansible, вы можете настроить путь к инвентаризации в ansible.cfg. Рекомендуемый способ использования инвентаризации — создать каталог inventory, и поместить в него скрипт gce.py и файл, содержащий localhost. Это позволит использовать инвентаризацию облака наряду с локальной инвентаризацией (например, физического дата-центра) или машин, работающих в разных провайдерах.

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

Давайте еще раз используем наш скрипт инвентаризации, чтобы увидеть, может ли он взаимодействовать с Google Cloud:

$ ansible all -i inventory/ -m setup
hostname | success >> {
  "ansible_facts": {
    "ansible_all_ipv4_addresses": [
        "x.x.x.x"
    ],

Вывод должен быть похожим на предыдущую команду. Если вам нужен меньше вывод и вы хотите проверить только SSH-соединение, используйте «-m» ping вместо этого.

Примеры использования

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

#!/usr/bin/env bash
PLAYBOOK="$1"

if [[ -z $PLAYBOOK ]]; then
  echo "You need to pass a playbook as argument to this script."
  exit 1
fi

export SSL_CERT_FILE=$(pwd)/cacert.pem
export ANSIBLE_HOST_KEY_CHECKING=False

if [[ ! -f "$SSL_CERT_FILE" ]]; then
  curl -O http://curl.haxx.se/ca/cacert.pem
fi

ansible-playbook -v -i inventory/ "$PLAYBOOK"

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

Модуль GCE предоставляет возможность развертывания виртуальных машин в Google Compute Engine. Задача развертывания обычно выполняется с вашего сервера управления Ansible по отношению к API Google Cloud.

Плейбук будет выглядеть так:

- name: Create instance(s)
  hosts: localhost
  gather_facts: no
  connection: local

  vars:
    machine_type: n1-standard-1 # default
    image: debian-7
    service_account_email: unique-id@developer.gserviceaccount.com
    credentials_file: /path/to/project.json
    project_id: project-id

  tasks:
    - name: Launch instances
      gce:
          instance_names: dev
          machine_type: "{{ machine_type }}"
          image: "{{ image }}"
          service_account_email: "{{ service_account_email }}"
          credentials_file: "{{ credentials_file }}"
          project_id: "{{ project_id }}"
          tags: webserver
      register: gce

    - name: Wait for SSH to come up
      wait_for: host={{ item.public_ip }} port=22 delay=10 timeout=60
      loop: "{{ gce.instance_data }}"

    - name: Add host to groupname
      add_host: hostname={{ item.public_ip }} groupname=new_instances
      loop: "{{ gce.instance_data }}"

- name: Manage new instances
  hosts: new_instances
  connection: ssh
  sudo: True
  roles:
    - base_configuration
    - production_server

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

Настройка виртуальных машин в группе

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

Обычно мы также используем роли здесь, но следующий пример является простым. Здесь мы также будем использовать модуль «gce_net» для открытия доступа к порту 80 на этих узлах.

Переменные в разделе «vars» также можно хранить в файле «vars_files» или чем-то зашифрованном с помощью Ansible-vault, если вы этого хотите. Это просто базовый пример того, что возможно:

- name: Setup web servers
  hosts: tag_webserver
  gather_facts: no

  vars:
    machine_type: n1-standard-1 # default
    image: debian-7
    service_account_email: unique-id@developer.gserviceaccount.com
    credentials_file: /path/to/project.json
    project_id: project-id

  roles:

    - name: Install lighttpd
      apt: pkg=lighttpd state=installed
      sudo: True

    - name: Allow HTTP
      local_action: gce_net
      args:
        fwname: "all-http"
        name: "default"
        allowed: "tcp:80"
        state: "present"
        service_account_email: "{{ service_account_email }}"
        credentials_file: "{{ credentials_file }}"
        project_id: "{{ project_id }}"

Обратившись к IP-адресу сервера в браузере, вы должны увидеть страницу с приветствием.

Обновления этого документа приветствуются, нажмите на ссылку github в правом верхнем углу этой страницы, если вы хотите внести дополнения!

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

Spec-Zone.ru

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