Статьи

Часть 4: Ansible Tower

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

За 6 с лишним месяцев с тех пор, как я написал части 1 , 2 и 3 моего руководства «Приступая к работе с Ansible», его посетили более 10 000 уникальных посетителей. Я очень впечатлен этим одним. Я построил конвейеры инициализации и развертывания на основе ANBIL для еще двух компаний, обе из которых основаны на моей отправной точке Parallax, над которой я работаю с января. Это само по себе собирало звезды и вилки на Github.

И так, к четвертой части: Ansible Tower.

Ansible Tower — это веб-интерфейс пользователя для Ansible , разработанный компанией за проектом Ansible.

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

В Tower также встроен API REST, который помогает в задачах автоматизации (мы вернемся к этому в части 5).

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

Предпосылки:

Сервер Ansible Tower (я использую среду VMware, поэтому оба моих сервера являются виртуальными машинами)

1 ядро, 1 ГБ оперативной памяти Ubuntu 12.04 LTS Server, 64-разрядный

Сервер Active Directory (я использую Windows Server 2012 R2)

2 ядра, 4 ГБ оперативной памяти

Официально Tower поддерживает CentOS 6, RedHat Enterprise Linux 6, Ubuntu Server 12.04 LTS и Ubuntu Server 14.04 LTS.

Установка Tower требует подключения к Интернету, поскольку она загружается с их серверов репо.

Мне удалось выполнить автономную установку, но вам нужно настроить какую-то систему для зеркалирования их репозиториев и изменить некоторые настройки в файле Ansible Installer.  

Я * настоятельно * рекомендую вам выделить сервер (vm или другой) для Ansible Tower, поскольку установщик перепишет pg_hba.conf и supervisord.conf в соответствии с его потребностями. Все проще, если вы предоставите ему собственную среду для запуска.  

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

Я предполагаю, что вы уже знаете об установке Windows Server 2012 и создании контроллера домена. (Если есть существенный призыв к этому, я мог бы написать отдельный пост в блоге об этом …)

Шаги установки:

 SSH на сервер Tower и загрузите файл ansible-tower-setup-latest.gz в каталог ~.

Извлеки это

Загрузите и откройте http://releases.ansible.com/ansible-tower/docs/tower_user_guide-latest.pdf на вкладке браузера для просмотра и ознакомления.

Установить зависимости:

sudo apt-get install python-dev python-yaml python-paramiko python-jinja2 python-pip sshpass
sudo pip install ansible
cd ansible-tower-setup-$VERSION 

(где $ VERSION — версия Ansible, которой он не подвергался. Mine’s 1.4.11.)

Неудивительно, что установщик Ansible Tower на самом деле является Ansible Playbook (hosts включает в себя 127.0.0.1, и все это определено в group_vars / all и site.yml) — Отлично, да? 

Отредактируйте group_vars / all, чтобы установить некоторые нормальные значения по умолчанию — в основном изменяя пароли от того, с чем они поставляются.

pg_password: AWsecret
admin_password: password
rabbitmq_password: "AWXbunnies"

** Важно ** — Вам действительно нужно изменить эти значения по умолчанию, иначе теоретически возможно, что вы сможете раскрыть свои секреты миру!

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

На самом деле я собираюсь сделать интеграцию LDAP на более позднем этапе.

 sudo ./setup.sh

Если вам повезет, вы должны получить следующее сообщение.

The setup process completed successfully.

Установив Ansible Tower, вы можете открыть веб-браузер и перейти на http: //

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

Sidenote по SSL.  

Все это делается через Apache2, поэтому файл, который вы хотите отредактировать:

/etc/apache2/conf.d/awx-httpd-443.conf

и редактировать:

  SSLCertificateFile /etc/awx/awx.cert
  SSLCertificateKeyFile /etc/awx/awx.key

Теперь вы можете войти в Tower с именем пользователя: admin и любым паролем, который вы указали в group_vars / all во время установки.

Что касается фактического начала работы с Ansible Tower, я настоятельно рекомендую вам ознакомиться с руководством пользователя в формате PDF, на которое я ссылался ранее. Есть хороший пример быстрого старта, и действительно легко импортировать ваши автономные книги.

При импорте книги воспроизведения вручную или с помощью какого-либо механизма управления исходным кодом важно помнить, что в файле YAML книги воспроизведения вы задаете hosts: all , потому что определение хоста теперь будет контролироваться Tower, поэтому, если вы забудете сделать это, вы, вероятно, обнаружите, что ничего не происходит, когда вы запускаете работу.

Теперь для интересной части … (и давайте посмотрим правде в глаза, это бит, который вы все ждали)

Интеграция Ansible Tower с LDAP / Active Directory

Во-первых, убедитесь, что вы можете a) пропинговать сервер AD и b) установить к нему соединение LDAP.

ping — это просто. Просто пропингуйте его по имени хоста (если вы настроили DNS или файл hosts)

LDAP тоже довольно прост, просто подключитесь к нему через порт 389. Если вы получили отказ в соединении, вам нужно проверить настройки брандмауэра Windows.

На сервере Tower откройте:

 /etc/awx/settings.py

После строки 80 (или около того) есть раздел о настройках LDAP.

Настройки, которые вы хотите изменить (и некоторые вменяемые примеры):

AUTH_LDAP_SERVER_URI = ''

установите это в строку подключения ldap для вашего сервера:

AUTH_LDAP_SERVER_URI = 'ldap://ad0.wibblesplat.com:389'

На сервере AD откройте «Пользователи и компьютеры» и создайте пользователя в управляемых учетных записях служб с именем «Ansible Tower» и назначьте ему соответственно непонятный пароль. Отметьте это как «Пароль никогда не истекает».

Мы будем использовать этого пользователя для формирования Bind DN для аутентификации LDAP.

Я также создал другую учетную запись в AD-> Users, как «Таблицы Бобби» — с sAMAccountName для bobby.tables и простым паролем. Мы будем использовать это, чтобы проверить, что интеграция работает позже.

Нам понадобится полный путь DN для файла конфигурации, поэтому откройте Powershell и запустите

`dsquery user`

В возвращаемом списке найдите DN LDAP вновь созданного пользователя:

 “CN=Ansible Tower,CN=Managed Service Accounts,DC=wibblesplat,DC=com”

Вернитесь в /etc/awx/settings.py и установите:

AUTH_LDAP_BIND_DN = 'CN=Ansible Tower,CN=Managed Service Accounts,DC=wibblesplat,DC=com'

# Пароль используется для привязки над учетной записью пользователя.

AUTH_LDAP_BIND_PASSWORD = 'P4ssW0Rd%!'
AUTH_LDAP_USER_SEARCH = LDAPSearch(
    ‘CN=Users,DC=wibblesplat,DC=com',   # Base DN
    ldap.SCOPE_SUBTREE,             # SCOPE_BASE, SCOPE_ONELEVEL, SCOPE_SUBTREE
    '(sAMAccountName=%(user)s)',    # Query
)

Вам нужно отредактировать  атрибут AUTH_LDAP_USER_SEARCH, чтобы правильно установить базовый DN вашего сайта. Если вы храните своих пользователей в подразделении, вы можете указать это здесь.

AUTH_LDAP_GROUP_SEARCH = LDAPSearch(
    'CN=Users,DC=wibblesplat,DC=com',    # Base DN
    ldap.SCOPE_SUBTREE,     # SCOPE_BASE, SCOPE_ONELEVEL, SCOPE_SUBTREE
    '(objectClass=group)',  # Query
)

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

Это интересная настройка:

# Group DN required to login. If specified, user must be a member of this
# group to login via LDAP.  If not set, everyone in LDAP that matches the
# user search defined above will be able to login via AWX.  Only one
# require group is supported.
#AUTH_LDAP_REQUIRE_GROUP = 'CN=ansible-tower-users,CN=Users,DC=wibblesplat,DC=com'
# Group DN denied from login. If specified, user will not be allowed to login
# if a member of this group.  Only one deny group is supported.
#AUTH_LDAP_DENY_GROUP = 'CN=ansible-tower-denied,CN=Users,DC=wibblesplat,DC=com'

По сути, вы можете выбрать группу, и если пользователь не входит в эту группу, он не входит. 

Оба они указаны в качестве DN группы:

Групповые DN легко обнаружить с помощью

dsquery group

из Powershell на вашем сервере AD.

Еще одна умная настройка. Можно назначить пользователям флаг «is_superuser» в Tower, основываясь на членстве в группах AD / LDAP:

AUTH_LDAP_USER_FLAGS_BY_GROUP = {
    'is_superuser': 'CN=Domain Admins,CN=Users,DC=wibblesplat,DC=com',
}

Наконец, последний параметр позволяет сопоставить организации Tower (организации) с группами AD / LDAP:

AUTH_LDAP_ORGANIZATION_MAP = {
    'Test Org': {
        'admins': 'CN=Domain Admins,CN=Users,DC=wibblesplat,DC=com',
        'users': ['CN=ansible-tower-users,CN=Users,DC=wibblesplat,DC=com'],
        'remove_users' : False,
        'remove_admins' : False,
    },
    #'Test Org 2': {
    #    'admins': ['CN=Administrators,CN=Builtin,DC=example,DC=com'],
    #    'users': True,
    #    'remove_users' : False,
    #    'remove_admins' : False,
    #},
}

Передать изменения так же просто, как перезапустить Apache и сервисы AWX.

Сначала перезапустите сервисы AWX с помощью

supervisorctl restart all

Теперь перезапустите Apache с помощью:

service apache2 restart

Я создал две группы в

CN=Users,DC=wibblesplat,DC=com

Называется «пользователи ансибл-башни» и «пользователи ансайбл-башни».

Я создал двух пользователей: «Таблицы Бобби (bobby.tables)» — для пользователей ansible-tower , и «Evil Emily (evil.emily)» — для пользователя ansible-tower-denied .  

Когда я перезапустил службы Ansible и попытался войти с помощью bobby.tables , я вошел .  

Когда я просматриваю организации, я вижу тестовую организацию (в соответствии с отображением) и таблицы Бобби в этой организации.

Когда я пытаюсь войти в систему как evil.emily, я получаю сообщение «Невозможно войти с предоставленными учетными данными». — Это то, что мы ожидаем, так как этот пользователь находится в группе запрета доступа.

Используя Ansible Tower

Что касается использования Tower, я действительно не хочу перефразировать то, что Ansible уже сказал в их Руководстве пользователя PDF. 

Однако я пройдусь по шагам, чтобы импортировать и развернуть Parallax на тестовом сервере.

Для этой цели я создал тестовую виртуальную машину в своей среде разработки под управлением Ubuntu 14.04. Я собираюсь настроить Tower для управления этой виртуальной машиной, загрузить книги игр Parallax с Github и создать шаблон задания для запуска их на тестовом сервере.

В этом примере я вошел в систему под учетной записью суперпользователя «admin», хотя с правильными разрешениями, настроенными в Tower, с использованием Active Directory или назначением разрешений вручную, это можно сделать как на индивидуальном, так и на командном уровне.

Несколько быстрых определений: 

Организации : — Это единица верхнего уровня иерархической организации в Башне. Организация содержит пользователей , команды , проекты и запасы . Несколько организаций могут быть использованы для создания нескольких арендаторов на сервере Tower.

Пользователи : — Это логины в Башню. Они либо создаются вручную, либо отображаются из LDAP. У пользователей есть Свойства (имя, адрес электронной почты, имя пользователя и т. Д.), Учетные данные (используются для подключения к службам и серверам), Разрешения (для предоставления им контроля доступа на основе ролей к инвентарям и развертываниям), Организации (организации, членами которых они являются. ) и команды (полезно для разделения организаций на группы пользователей, проекты, учетные данные и разрешения).

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

Разрешения : — Они связывают пользователей и команды с запасами и рабочими местами. У вас есть разрешения инвентаризации и развертывания. 

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

Разрешения на развертывание дают пользователям и командам возможность запускать задания, которые вносят изменения «Запускать задания», или запускать задания, проверяющие состояние «Проверять задания»

Учетные данные : — это пароли и ключи доступа, которые Tower должен иметь возможность использовать ssh (или использовать другие протоколы) для подключения к узлам, которыми он управляет.

Существует несколько типов учетных данных, которыми Tower может управлять и использовать:

Пароль SSH — обычный старый пароль, основанный на пароле.

Закрытый ключ SSH — используется для аутентификации SSH на основе ключей.

Закрытый ключ SSH с парольной фразой — используется для защиты закрытого ключа парольной фразой. Фраза-пароль может быть сохранена в базе данных. Если это не так, Tower попросит вас ввести пароль, когда он должен использовать учетные данные.

Пароль Sudo — Требуется, если sudo должен быть запущен и требуется пароль для авторизации.

Учетные данные AWS — надежно хранит ключ доступа AWS и секретный ключ в базе данных Tower.

Учетные данные Rackspace — хранит имя пользователя и секретный ключ Rackspace. 

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

Проекты : — Здесь живут твои книги. Вы можете добавить их вручную, клонируя в

/var/lib/awx/projects

или используя Git, SVN или Mercurial и заставляя Tower автоматически выполнять клонирование перед каждым запуском задания (или по расписанию).

Запасы : — Они эффективно заменяют группировку в файле хостов каталога Playbook. Вы можете определить группы хостов, а затем настроить отдельные хосты в этих группах. Из этого можно назначить специфичные для хоста переменные или инвентаризационные переменные.

Группы : — Они живут в Инвентаризациях и позволяют собирать группы схожих хостов, к которым вы можете применить игровую книгу.

Хосты : — Они живут в группах и определяют IP-адрес / имя хоста узла, а также некоторые переменные хоста.

Шаблоны заданий : — Это в основном определение задания Ansible, которое связывает воедино Инвентарь (и его хосты / группы), Проект (и его Playbooks ), Учетные данные и некоторые дополнительные переменные. Здесь вы также можете указать теги (например, —tags в командной строке ansible-playbook).

Шаблоны заданий также могут принимать обратные вызовы HTTP, что позволяет вновь подготовленному хосту связываться с сервером Tower и запрашивать инициализацию. Мы вернемся к этой концепции в части 5.

Задания : — это то, что происходит, когда создается экземпляр шаблона задания, и он запускает playbook для набора хостов из соответствующего инвентаря.

Запуск параллакса с башней

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

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

Я назвал свою команду » DevOps «

Я собираюсь назначить им полномочия сейчас. 

Перейдите к командам / DevOps

В разделе «Учетные данные» нажмите [+]

Выберите тип «Машина»

 — На сервере где-нибудь запустите ssh-keygen и сгенерируйте ключ RSA. Скопируйте закрытый ключ в буфер обмена и вставьте его в поле SSH Private Key.  

 Прокрутите вниз и нажмите Сохранить.

В верхнем меню с вкладками нажмите «Проекты», затем нажмите [+]

Дайте проекту осмысленное имя и описание. Введите тип SCM как Git

Под URL-адресом SCM укажите публичный адрес Github для Parallax, а в разделе SCM Branch установите «tower»

Установите для параметров обновления SCM значение «Обновлять при запуске» — это выполнит обновление git перед запуском задания, поэтому вы всегда будете получать последнюю версию от Git.

Нажмите Сохранить.

Это вызовет задание, которое клонирует последнюю версию из Git и сохранит ее в каталоге Projects. Если это не удается, вам может потребоваться выполнить:

chown -R awx /var/lib/awx/projects

Далее создайте инвентарь .

Довольно просто — название, описание, организация.

Выберите этот инвентарь и создайте группу. Можно импортировать группы из EC2, выбрав вкладку «Источник» при создании новой группы.

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

На этом этапе вы можете назначить переменные для каждого хоста.

Почти там!

Нажмите « Шаблоны заданий » и создайте новый шаблон задания. Как я уже говорил, они действительно связывают все это вместе.

Дайте ему имя, затем выберите свой Инвентарь , Проект , Playbook и Credential .

Нажмите Сохранить.

Чтобы запустить его, нажмите Rocketship из списка шаблонов работ.

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

Если у вас нет очень загруженного сервера Tower, он не будет долго стоять в очереди. Нажмите кнопку «Обновить» в разделе «Очередь» для перезагрузки, и вы должны увидеть, что она перемещена в «Активная».

Вы можете щелкнуть по заданию для обновления его статуса или просто терпеливо ждать его завершения.

Когда работа будет завершена, у вас будет красная точка или зеленая точка, указывающая статус работы.

Вот и все. Вы установили Ansible Tower, интегрировали его с Active Directory и создали свое первое задание по развертыванию Parallax с Tower.