Deploy с помощью Salt

[erthad]

Salt работает без агента или внутрь вагранта агент сперва ставится?

[vaniaPooh]

Там 2 демона: salt-master и salt-minion. При использовании Vagrant они ставятся автоматически.

[slav0nic]

уже появился salt-ssh

[FINTER]

Ага, но он пока сыроват. Иногда попадаю на баги, хотя и редко.

[slav0nic]

их там тьма, начиная от неработающего root_fs :)

[vaniaPooh]

В конфигурации Vagrant можно еще указать директивы чтобы ставить только мастер или только миньон. Подробности тут: github.com/saltstack/salty-vagrant

[drunken]

как доставляются на энвайронмент креденшлы и разнообразные токены?
есть аналог зашифрованных датабагов, как в chef?

[FINTER]

Ну на мастер сервере все настройки хранятся в открытом виде для рута.
Настройки делятся на переменные(pillar), и все остальное (salt).
А все общения с воркерами происходят по шифрованному протоколу.

Или нужно что-то еще?

[drunken]

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

[FINTER]

Пароли и токены всякие лежат только на мастер сервере. Встречный поперечный видит их только тот, у кого есть судо уровня рута на мастер сервере (обычно это 2 человека).

Идеология salt как раз подразумевает, что настройки типа паролей к базам, токены, хэши лежат в /etc/pillar. Туда стараются спихнуть все, что меняется между установками в разных условиях типа ip, hostname и пр.

Все остальные конфиги лежат в /etc/salt — туда можно давать доступ хоть всем.

Вот пример того, что будет лежать в репо:

/etc/pillar/top.sls — корневой конфиг переменных с раскладкой по хостам

base:
  'my-super-server':
    - super_app

/etc/pillar/super_app.sls.sample

super_app:
  db_name: blablabla
  db_pass: yahoo!@#$

Эти два файлика будут лежать в репо.

Дальше если нам нужно инсталлировать приложение на реальный my-super-server, то мы апаемся из репо, делаем копию super_app.sls.sample -> super_app.sls, расписываем там настоящие настройки (обычно это самый минимум: как раз логины, пароли, ключи) и запускаем синхронизацию состояний salt my-super-server state.highstate.

Вроде все прозрачно и просто by design

[drunken]

т.е. вы храните креденшлы в репозитории, не опасаясь утечек?
сильно.

[FINTER]

Это как вы такой вывод сделали?

[cadmi]

В предложении «делаем копию super_app.sls.sample -> super_app.sls» какое из слов непонятно?

[dsx]

Push или pull?

[cbx]

И так и так. Порты слушает только master, а minion подключается к нему хоть из-за NAT. После установления соединения мастер может делать push. Также можно периодически выполнять pull на minion и можно даже вообще без мастера.

[Snowindy]

Да и вообще, когда один разработчик работает на OS X, другой на Windows, а продакшен на Debian, то жди беды, это не считая того, что каждый делает работу по настройке окружения.

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

Особенно это очевидно, если разработка, к примеру, под виндой, а продакшн сервер — *nix.

[vmakhaev]

Если хочется деплоить/поднимать у себя на машние много хостов, то, на мой взгляд, проекты, основанные на Docker, интереснее. Например, Flynn. Правда он еще толком не вышел.

[Ramm]

Докер — он вообще не про «хосты».

[vmakhaev]

Да, про контейнеры. На каждом хосте может быть несколько контейнеров.

[Ramm]

И не про контейнеры. Про контейнеры — это LXC. А докер — вообще про другое.

[vmakhaev]

Вы меня заинтриговали. В чем же разгадка? Про что Docker?

[Ramm]

Docker это система для изоляции приложений. И тот факт, что она работает поверх LXC ничего не значит.
Вполне могла бы работать поверх того же virtualbox, как Vagrant.

[kmmbvnr]

А как Salt по сравнению с Ansible?

[slav0nic]

сравните примеры рецептов и выберите что больше нравится, у ансибл разве что веб-морда из коробки, хотя в салте она тоже есть, но отдельно

[FINTER]

salt изначально спроектирован для управления огромными кластерами.

Например, когда я смотрел на Ansimble, он ходил по ssh на каждую машину и выполнял там какие-то задачи. Мне такой подход не понравился, потому что теряется вся суть cluster orchestration.

В salt задачи раздаются и выполняются через очередь сообщений, а исполняются уже на месте миньёнами. Причем в salt есть возможность построить дерево мастеров (salt-syndic), если машин о-о-очень много, хотя даже 1 мастер может обслуживать до тысячи машинок не напрягаясь.

Ну и еще один момент: в salt гарантируется, что процесс конфигурирования на машине выполняется только один в любой момент времени. Вы и, скажем, ваш коллега одновременно не сможете запустить процессы конфигурирования, что как не трудно догадаться может все поломать. Возможно в Ansimble это как-то тоже контролируется, но в salt это by design.

[marselester]

Я делал презентацию про Salt и написал пару постов: "Developing Django project with SaltStack", "Developing & Deploying Django project with SaltStack". Возможно кому-нибудь будет полезно.

[FINTER]

Ваша презентация — моё почтение! Сделано очень круто.

Только вот вопрос возник. В последнем посту вы с git работаете через cmd.run. Вот стало интересно чем вас salt.states.git не устроил? Я им пользуюсь и вроде ок.

[marselester]

Спасибо, рад что вам понравилось.

В посте есть объяснение:

I have tried to use built in git.latest Salt state but it requires to configure git name and email on server

Наверное я плохо сформулировал мысль. При вызове «git pull» GIT просил указать имя пользователя и почту, чтобы использовать их в merge коммите. Я решил не добавлять лишних настроек и использовать «git reset --hard origin/master».

[marselester]

btw, ссылки в домене .ru не работают, т.к. переехал на .com:
— marselester.com/saltstack-slides.html
— marselester.com/developing-and-deploying-django-project-with-saltstack.html
— marselester.com/developing-django-project-with-saltstack.html

[tuupic]

Спасибо за пост. Наконец-то я наглядно(на примере) понял, для чего нужны pillar.

[B7W]

Подскажите, структура директорий/файлов как-то определена? salt/roots/salt имеет какое-то значение?

[FINTER]

Никакого значения нет. Просто так исторически сложилось.

Только не забудьте подправить Vagrantfile, если у вас изменится раскладка проекта.

[TriAn]

А чем данный инструмент отличается, например, от Puppet?

[FINTER]

Я знаком с Puppet лишь понаслышке.

Salt и Puppet в плане силы «конфигурирования» состояний примерно равны.
Salt кроме поддержки состояний умеет еще и оркестрацию. То есть фактически заменяет fabric.
В отличие от fabric соль использует 0mq в качестве транспорта, поэтому работает в разы быстрее, но требует предустановленного minion на машинках.
Не уверен, что в Puppet это есть.