До сих пор во многих компаниях deploy создает большие проблемы и может занимать дни, недели и в особо запущенных случаях месяцы. Но ситуация не безнадежна. Существует много инструментов и практик, способных помочь в этом нелегком деле. Вот только эти инструменты чаще всего за один-два дня не освоишь, а сроки горят.
Чего обычно хочется:
- Возможность поднять проект локально на машине разработчика. Весь или хотя бы частями. Причем очень хочется, чтобы Dev конфигурация отличалась от Prod в минимуме паратемров. Это позволит избежать “work on my machine” багов. Да и вообще, когда один разработчик работает на OS X, другой на Windows, а продакшен на Debian, то жди беды, это не считая того, что каждый делает работу по настройке окружения.
- Dev конфигурацию хочется разворачивать на любой машине и ОС в пару команд в консоли. Это опять же позволит уменьшить фактор “work on my machine” багов. А еще позволит привлекать других разработчиков в проект за минимальное время (vagrant up и поехали).
- Конфигурация должна быть понятна и программисту, и админу.
Всего этого мы добьемся на связке Salt + Vagrant на примере Django проекта. Но большинство техник будут полезны разработчикам не только на Python, но на других языках.
Сразу дам ссылку на исходники: bitbucket.org/awnion/salt-django-deploy
Что же такое Salt?
Если вы знакомы с Salt, то можете пропустить этот раздел.
Salt — это достаточно мощный инструмент для управления кластером (cluster orchestration), но на мой личный взгляд даже использование на одной машине вполне оправдано и не будет оверкилом (грубо говоря если в вашей команде ровно 1 разработчик, то это не значит, что не надо использовать систему контроля версий).
Salt состояния — это YAML файлы с расширением sls, которые описывают в каком состоянии должна быть машина. Например, вот этот вот файл должен лежать тут, вот этот сервис должен быть запущен, вот этот юзер должен иметь такие права и так далее. В Salt можно поддерживать состояние не только системных утилит (apt, rpm, cron, init скрипты и разные конфиги), но и, например, можно проверить существует ли такой-то пользователь в RabbitMQ, последней ли версии репозиторий git, все ли пакеты стоят в вашем virtualenv и так далее. Полный список состояний можно найти тут docs.saltstack.com/ref/states/all/, и на мой взгляд он весьма внушительный.
Несколько фактов про Salt
- В качестве темплейтного языка для конфигов и фалов состояний Salt использует Jinja. Это невероятно удобно и позволяет следовать DRY даже в конфигах.
- Salt уже используют такие компании, как Apple, NASA, LinkedIn и многие другие.
- Salt написан на Python, хотя для его использования знать Python вообще не обязательно.
- Pdf документация для Salt около 1000 страниц, и написана она вполне добротно. Там вы найдете не только описание API, но и практики использования и примеры.
Dev конфигурация
На мой взгляд сложно переоценить важность хорошей и удобной среды разработки. Но на настройку “все под себя” может уйти пара дней, а то и неделя. Давайте сэкономим эти дни нашим коллегам в будущем и создадим конфигурацию, которая позволит поднять текущую версию проекта в одну команду:
git clone <repo_url> && cd <repo_name> && vagrant up
Ладно, это на самом деле это 3 команды, но если вы можете проще — жму вам руку.
Итак, мы будем строить нашу dev конфигурацию на Vagrant (тем, кто не знаком с Vagrant, настоятельно рекомендую познакомиться):
mkdir my_app && cd my_app
git init
vagrant init
В нашей папке my_app появился git репозиторий и конфиг для Vagrant.
Далее заменяем содержание Vagrantfile на следующее:
Vagrant.configure("2") do |config|
config.vm.box = "precise64"
config.vm.hostname = "dev-my-app"
config.vm.network :private_network, ip: '3.3.3.3'
config.vm.synced_folder "salt/roots/salt", "/srv/salt/"
config.vm.synced_folder "salt/roots/pillar", "/srv/pillar/"
config.vm.provision :salt do |salt|
salt.minion_config = "salt/minion"
salt.run_highstate = true
end
end
Этот конфиг позволит создать гостевую машину на Ubuntu, в конфиге мы задали имя хоста и IP, а так же определили, какие папки синхронизировать и указали, что для приведения нашей машинки к нужному состоянию мы будем использовать salt (кстати, корень нашего проекта будет по умолчанию синхронизован с папкой /vagrant гостевой машины).
Подробней о том, что тут происходит, можно узнать тут
Итак, мы готовы начать описывать состояния. Создадим файл salt/minion со следующим содержанием:
file_client: local
Фактически мы говорим, что эта машина хранит свои состояния сама. По умолчанию salt настроен так, что он берет файлы состояний с master-сервера, а локально их только кэширует где-то в /var/cache/salt. Поэтому если вы не хотите чего-то кастомного, то этот файл на prod машине скорее всего вообще не понадобится.
Теперь создадим две папки:
mkdir -p salt/roots/pillar
mkdir -p salt/roots/salt
Первая будет хранить различные переменные, а вторая — это и есть папка с состояниями для нашей гостевой машины.
Создадим файл salt/roots/salt/top.sls
base:
'dev-my-app':
- nginx
- python
- supervisor
Как можно было догадаться sls очень похож на yaml. Но главным отличаем тут будет то, что sls это еще и jinja темплейт со всеми вытекающими (дальше вы увидите, что это реально приносит пользу).
base — это название конфигурации состояний нашего воображаемого кластера. dev-my-app — это hostname нашей гостевой машины. Тут используется pattern matching, то есть мы могли бы указать ‘dev-*’, и все состояни ниже применились бы ко всем машинам типа dev-alpha, dev-foobar и т.п. Далее следует список состояний, которые нам надо будет описать.
Создадим заявленные состояния python, nginx и supervisor:
salt/roots/salt/python.sls
# это состояние просто проконтролирует, что пакеты python и python-virtualenv
# установлены, а если нет -- то поставит их с зависимостями
python:
pkg:
- installed
- names:
- python
- python-virtualenv
salt/roots/salt/nginx.sls
# это состояние поставит nginx и запустит его как сервис, при этом require
# показывает, что состояние service нужно запустить после состояния pkg
nginx:
pkg:
- installed
service:
- running
- reload: True # сервис поддерживает reload
- require:
- pkg: nginx
salt/roots/salt/supervisor.sls
supervisor:
pkg:
- installed
service:
- running
- require:
- pkg: supervisor
Итак, можно уже запустить “vagrant up”. Эта процедура скачает образ Ubuntu (если у вас его еще нет в кэше образов), установит туда salt и запустит синхронизацию состояния.
Теперь у нас на нашей гостевой машине есть python, supervisor и nginx.
Можете проверить это зайдя на машину через vagrant ssh или зайдя на 3.3.3.3
Пока вроде бы все просто. Продолжим:
Создадим переменные pillar:
salt/roots/pillar/top.sls
base:
'dev-my-app':
- my-app
salt/roots/pillar/my-app.sls
my_app:
gunicorn_bind: 127.0.0.1:8000
dns_name: dev.my-app.com
venv_dir: /home/vagrant/my_app_env
work_dir: /vagrant
Первый файл говорит, что хосту dev-my-app назначены переменные из конфига my-app. Второй файл — собственно сами переменные.
Теперь создадим папку для состояний конфигов нашего Django приложения:
mkdir -p salt/roots/salt/my_app
salt/roots/salt/my_app/init.sls
{% set my_app = pillar['my_app'] %}
my_app.venv:
virtualenv.managed:
- name: {{ my_app['venv_dir'] }}
- system_site_packages: False
- require:
- pkg: python
my_app.pip:
pip.installed:
- bin_env: {{ my_app['venv_dir'] }}
- names:
- Django==1.6
- gunicorn==18.0
- require:
- virtualenv: my_app.venv
my_app.nginx.conf:
file.managed:
- name: /etc/nginx/sites-enabled/my_app.conf
- source: salt://my_app/nginx.my_app.conf
- context: # помимо переменных вроде pillar, мы можем передать дополнительный контекст для тепмлейта
bind: {{ my_app['gunicorn_bind'] }}
dns_name: {{ my_app['dns_name'] }}
- template: jinja
- makedirs: True
- watch_in:
- service: nginx
my_app.supervisor.conf:
file.managed:
- name: /etc/supervisor/conf.d/my_app.conf
- source: salt://my_app/supervisor.my_app.conf
- context:
app_name: my_app
bind: {{ my_app['gunicorn_bind'] }}
gunicorn: {{ my_app['venv_dir'] }}/bin/gunicorn
directory: {{ my_app['work_dir'] }}
workers: {{ grains['num_cpus'] * 2 + 1 }} # в академических целях выпендрился
- template: jinja
- makedirs: True
my_app.supervisor:
supervisord.running:
- name: my_app
- watch:
- file: my_app.supervisor.conf
- require:
- pip: my_app.pip
- pkg: supervisor
Hint: при составлении зависимостей require, watch и пр. имейте в виду, что состояния будут проверяться в произвольном порядке. При составлении статьи я допустил такого рода ошибку, и пакеты django и gunicorn пытались устанавливаться в еще не созданный virtualenv.
salt/roots/salt/my_app/nginx.my_app.conf
server {
listen 80;
server_name {{ dns_name }} _;
location / {
proxy_pass http://{{ bind }};
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
salt/roots/salt/my_app/supervisor.my_app.conf
[program:{{ app_name }}]
command={{ gunicorn }} {{ app_name }}.wsgi:application -b {{ bind }} -w {{ workers }}
directory={{ directory }}
user=nobody
autostart=true
autorestart=true
redirect_stderr=true
Добавляем только что созданное состояние в salt/roots/salt/top.sls
base:
‘dev-my-app’:
- nginx
- python
- supervisor
- my_app # <----
Мы почти закончили. Но не хватает самого главного — кода нашего воображаемого Django приложения. Давайте создадим пустой тестовый Django проект следующим образом:
vagrant provision
Этот процесс займет несколько минут (большую часть времени будут ставиться django и gunicorn в virtualenv).
Когда provision отработает заходим на гостевую машину:
vagrant ssh
И внутри делает следующее:
/home/vagrant/my_app_env/bin/django-admin.py startproject my_app /vagrant
exit
И на хост машине опять делаем vagrant provision, и чтобы проверить, что все работает в файле hosts пропишите временно:
dev.my-app.com 3.3.3.3
Переходим в браузере на dev.my-app.com, и если все хорошо, то мы увидим It worked!
Dev конфигурация построена. Можно коммитить.
Теперь если вы захотите отдать поиграться со своим проектом другу, то ему нужно будет сделать только git clone и vagrant up. Причем этот воображаемый друг получит не только исходники самого проекта, но и будет иметь представление о том, как его будут деплоить.
Кроме всего прочего по умолчанию наш проект крутится самостоятельно под управлением gunicorn+supervisor. Но что если мы хотим удаленно подебажить или мы хотим вернуть наш любимый autoreload изменений кода? Не вопрос:
vagrant ssh
supervisorctl stop my_app
/home/vagrant/my_app_env/bin/python /vagrant/manage.py runserver
Теперь мы можем спокойно редактировать код, и все изменения будут подхватываться django сервером автоматически.
И если у нас все еще временно подправлен hosts, то на запросы dev.my-app.com/ будет отвечать все тот же django сервер.
Prod конфигурация
Вот мы и добрались до самого главного. Будем считать, что деплоиться мы будем на prod-my-app.
Далее мы рассмотрим вариант деплоя в ситуации, когда у нас есть отдельный сервер для salt-master (далее просто мастер).
Копируем на мастер конфиги, добавляем в /srv/salt/top.sls
‘prod-my-app’:
- nginx
- python
- supervisor
- my_app
Или в нашем случае можно сделать вот так:
base:
‘*-my-app’:
- nginx
- python
- supervisor
- my_app
Далее делаем то же самое с файлом /srv/pillar/top.sls
base:
'*-my-app':
- my-app
В /srv/pillar/my_app.sls меняем переменные согласно нашей карте раскладки.
На prod-my-app ставим salt-minion. Подключаем salt-minion к salt-master (как это сделать читай тут).
Теперь на мастере можно запустить применение конфигов:
sudo salt prod-my-app state.highstate
Что осталось:
Доставка конфигов на мастер
Тут куча способов от rsync до git. Все зависит от вашей внутренней политики.
Доставка исходников проекта на prod-my-app
Тут опять же куча вариантов. Лично я делаю так: при помощи salt поддерживаю на prod-my-app репозиторий git на определенном коммите, хэш которого хранится в pillar, и если он меняется, то salt в конце работы запускает скрипты деплоя.
Честно говоря это не самый лучший способ, но он самый простой. В идеале создавать, например, нативные пакеты, или поднимать приватный pypi.
Ссылки
www.saltstack.com/
www.vagrantup.com/
hynek.me/talks/python-deployments/ — весьма полезная статья, которая содержит набор тезисов на тему деплоя python проектов.
PS
К сожалению очень многие вещи пришлось упустить, иначе бы статья раздулась до неприлично большого размера. Я старался упускать либо очевидные вещи, либо то, что легко найти в документации. Тем не менее задавайте вопросы в комментариях.
Автор: FINTER
