Возможно, вы помните, что в январе я написал трилогию блогов, посвященную использованию 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.