Deploy с помощью Salt

До сих пор во многих компаниях 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

Источник