Теперь вы должны были пройти через часть 1: Начало работы с Ansible . Если нет, то иди и сделай это сейчас.
В этой статье я продемонстрирую очень простой рабочий процесс развертывания приложения, развертывание безумно простого приложения node.js из репозитория github и настройку его для запуска с supervisord и обратного прокси с Nginx.
Как и в прошлый раз, мы будем использовать Parallax в качестве отправной точки для этого. Я на самом деле прошел и положил туда конфиг (если вы не хотите делать это самостоятельно;)
- name: Install all the packages and stuff required for a demobox
hosts: demoboxes
user: user
sudo: yes
roles:
- redis
- nginx
- nodejs
- zeromq
# - deploy_thingy
В версии 9c818d0b8f вы увидите, что я создал новую роль, изобретательно называемую «deploy_thingy».
** Обновлено **
Мне было рекомендовано, чтобы моя роль __template__ была основана на выводе
ansible-galaxy init $rolename
Поэтому я воссоздаю роль __template__, основываясь на шаблоне роли ansible-galaxy.
Изменений не так много, но он включает в себя новый каталог default / , содержащий метаданные Galaxy, необходимые, если вы хотите вернуться к общедоступному индексу роли галактики.
Пытаясь упростить создание новых ролей, я поместил роль __template__ в дерево файлов при первом создании Parallax, чтобы все, что вы делаете для создания новой роли, — это выполните:
cp -R __template__ new_role_name
в каталоге ролей / .
.
├── files
│ ├── .empty
│ ├── thingy.nginx.conf
│ └── thingy.super.conf
├── handlers
│ ├── .empty
│ └── main.yml
├── meta
│ ├── .empty
│ └── main.yml
├── tasks
│ └── main.yml
└── templates
└── .empty
В этой роли мы определяем некоторые зависимости в meta / main.yml , в каталоге files / есть два файла , и есть набор задач, определенных в tasks / main.yml . Есть также некоторые обработчики, определенные в handlers / main.yml .
Давайте быстро взглянем на файл meta / main.yml .
---
dependencies:
- { role: nodejs }
- { role: nginx }
Это в основном устанавливает требование, что эта роль deploy_thingy зависит от служб, установленных ролями: nginx и nodejs.
Хотя эти роли явно указаны для установки в site.yml, это дает нам уровень конфигурации пояс и фигурных скобок, в случае, если роль deploy_thingy когда-либо была включена без указания двух других ролей, или если она была настроена на запустить до того, как его зависимости были явно установлены для запуска.
tasks / main.yml прост.
---
- name: Create directory under /srv for thingy
file: path=/srv/thingy state=directory mode=755
- name: Git checkout from github
git: repo=https://github.com/tomoconnor/shiny-octo-computing-machine.git
dest=/srv/thingy
- name: Drop Config for supervisord into the conf.d directory
copy: src=thingy.super.conf dest=/etc/supervisor/conf.d/thingy.conf
notify: reread supervisord
- name: Drop Reverse Proxy Config for Nginx
copy: src=thingy.nginx.conf dest=/etc/nginx/sites-enabled/thingy.conf
notify: restart nginx
Мы создадим где-нибудь, чтобы он работал, проверим код из моего репозитория git [1] , затем оставим два файла конфигурации на месте, один для настройки supervisor (d), а другой для настройки Nginx.
Поскольку команда для конфигурирования supervisor (d) и nginx изменяет конфигурацию этих сервисов, существуют уведомления: обработчики для перезагрузки конфигурации или перезапуска сервиса.
Давайте теперь взглянем на эти обработчики:
---
- name: reread supervisord
shell: /usr/bin/supervisorctl reread && /usr/bin/supervisorctl update
- name: restart nginx
service: name=nginx state=restarted
Когда конфигурация супервизора изменяется (и мы добавляем что-то в /etc/supervisor/conf.d), нам нужно сказать супервизору перечитать его конфигурационные файлы, после чего он увидит новые сервисы и затем запустит обновление supervisorctl , который установит состояние вновь добавленных элементов с «доступно» на «начато».
Когда мы изменим конфигурацию nginx, мы перезапустим nginx. Здесь можно выполнять более мягкие действия, такие как перезагрузка, но я выбрал перезапуск службы для простоты.
Я также изменил базовую конфигурацию Ansible и конфигурацию role / common / files / insecure_sudoers, чтобы она по-прежнему запрашивала пароль sudo в свете небольшой критики.
Я обнаружил, что если вы разрабатываете Ansible playbooks в изолированной системе, то нет большого вреда в отключении SSH Host Key Checking (в ansible.cfg ), точно так же, как нет больших проблем в отключении аутентификации sudo, так что это NOPASSWD использовать.
Тем не менее, Майкл сделал очень хорошую мысль, что в живых средах это немного глупо, если не сказать больше. Итак, я прокомментировал эти строки из сборника игр в Parallax, чтобы он обеспечил пользователям разумный уровень базовой безопасности. В конце концов, вам решать, как вы используете Parallax, и если вы обнаружите, что отключение защиты работает для вас, тогда все в порядке. Не то чтобы тебя не предупреждали.
Но я отвлекся.
Следующее, что нужно сделать, это отредактировать site.yml и убедиться, что новая роль, которую мы создали, сопоставлена с группой хостов в конфигурации воспроизведения.
В последней версии Parallax это уже сделано для вас, но пока имя роли в списке совпадает с каталогом в role /, оно должно быть готово к работе.
Теперь, если мы запустим:
ansible-playbook -k -K -i playbooks/example/hosts playbooks/example/site.yml
Он должен пройти по книге игр, установить материал, а затем, наконец, выполнить клон git из github, развернуть файлы конфигурации, вызвать перечитывание supervisord и перезапустить nginx.
Если я сейчас проверю, что это работает, с:
curl -i http://192.168.20.151/ HTTP/1.1 200 OK Server: nginx/1.4.1 (Ubuntu) Date: Mon, 27 Jan 2014 14:51:29 GMT Content-Type: text/html; charset=utf-8 Content-Length: 170 Connection: keep-alive X-Powered-By: Express ETag: "1827834703"
Эта строка X-Powered-By: Express показывает, что Nginx действительно работает и что приложение node.js также работает.
Вы можете получить больше информации о том, что контролирует супервизор, запустив:
sudo supervisorctl status
на целевом хосте.
$ sudo supervisorctl status thingy RUNNING pid 19756, uptime 0:00:06
Если сторона Nginx настроена, но приложение node.js не запущено, вы получите ошибку HTTP 502, как показано ниже:
curl -i http://192.168.20.151/ HTTP/1.1 502 Bad Gateway Server: nginx/1.4.1 (Ubuntu) Date: Mon, 27 Jan 2014 14:59:34 GMT Content-Type: text/html Content-Length: 181 Connection: keep-alive
Итак, это все.
Очень простое руководство для развертывания очень простого приложения с анзиблем. Конечно, должно быть очевидно, что вы можете развернуть * что угодно * из репозитория git, это действительно сводится к конфигурации supervisord. В этом отношении это не должно быть наблюдателем.
Я считаю, что настройка супервизора для управления процессами выходит за рамки этой статьи, но я мог бы коснуться этого в будущем более подробно.
Далее, часть 3: Ansible и Amazon Web Services.
1: Это действительно просто, и я не очень разбираюсь в нодах, так что извините, если это отстой.