Comments 34
Salt работает без агента или внутрь вагранта агент сперва ставится?
В конфигурации Vagrant можно еще указать директивы чтобы ставить только мастер или только миньон. Подробности тут: github.com/saltstack/salty-vagrant
как доставляются на энвайронмент креденшлы и разнообразные токены?
есть аналог зашифрованных датабагов, как в chef?
есть аналог зашифрованных датабагов, как в chef?
Ну на мастер сервере все настройки хранятся в открытом виде для рута.
Настройки делятся на переменные(pillar), и все остальное (salt).
А все общения с воркерами происходят по шифрованному протоколу.
Или нужно что-то еще?
Настройки делятся на переменные(pillar), и все остальное (salt).
А все общения с воркерами происходят по шифрованному протоколу.
Или нужно что-то еще?
как раз для того, чтобы каждый встречный-поперечный не читал все кренделя, и делали шифрованные датабаги в шефе. их можно коммитить в любой публичный или приватный репозиторий, не опасаясь, что кто-нибудь уведет пароль от продакшновой базы.
а вы свои настройки с мастер-сервера храните только на мастер-сервере?
как у вас происходит коллективная разработка?
а вы свои настройки с мастер-сервера храните только на мастер-сервере?
как у вас происходит коллективная разработка?
Пароли и токены всякие лежат только на мастер сервере. Встречный поперечный видит их только тот, у кого есть судо уровня рута на мастер сервере (обычно это 2 человека).
Идеология salt как раз подразумевает, что настройки типа паролей к базам, токены, хэши лежат в /etc/pillar. Туда стараются спихнуть все, что меняется между установками в разных условиях типа ip, hostname и пр.
Все остальные конфиги лежат в /etc/salt — туда можно давать доступ хоть всем.
Вот пример того, что будет лежать в репо:
/etc/pillar/top.sls — корневой конфиг переменных с раскладкой по хостам
/etc/pillar/super_app.sls.sample
Эти два файлика будут лежать в репо.
Дальше если нам нужно инсталлировать приложение на реальный my-super-server, то мы апаемся из репо, делаем копию super_app.sls.sample -> super_app.sls, расписываем там настоящие настройки (обычно это самый минимум: как раз логины, пароли, ключи) и запускаем синхронизацию состояний salt my-super-server state.highstate.
Вроде все прозрачно и просто by design
Идеология 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
Push или pull?
Да и вообще, когда один разработчик работает на OS X, другой на Windows, а продакшен на Debian, то жди беды, это не считая того, что каждый делает работу по настройке окружения.
Не соглашусь, при должном подходе факт разработки на разных платформах заставляет делать код и скрипты мультиплатформенными и позволяет выловить редкие баги раньше.
Особенно это очевидно, если разработка, к примеру, под виндой, а продакшн сервер — *nix.
Если хочется деплоить/поднимать у себя на машние много хостов, то, на мой взгляд, проекты, основанные на Docker, интереснее. Например, Flynn. Правда он еще толком не вышел.
А как Salt по сравнению с Ansible?
сравните примеры рецептов и выберите что больше нравится, у ансибл разве что веб-морда из коробки, хотя в салте она тоже есть, но отдельно
salt изначально спроектирован для управления огромными кластерами.
Например, когда я смотрел на Ansimble, он ходил по ssh на каждую машину и выполнял там какие-то задачи. Мне такой подход не понравился, потому что теряется вся суть cluster orchestration.
В salt задачи раздаются и выполняются через очередь сообщений, а исполняются уже на месте миньёнами. Причем в salt есть возможность построить дерево мастеров (salt-syndic), если машин о-о-очень много, хотя даже 1 мастер может обслуживать до тысячи машинок не напрягаясь.
Ну и еще один момент: в salt гарантируется, что процесс конфигурирования на машине выполняется только один в любой момент времени. Вы и, скажем, ваш коллега одновременно не сможете запустить процессы конфигурирования, что как не трудно догадаться может все поломать. Возможно в Ansimble это как-то тоже контролируется, но в salt это by design.
Например, когда я смотрел на Ansimble, он ходил по ssh на каждую машину и выполнял там какие-то задачи. Мне такой подход не понравился, потому что теряется вся суть cluster orchestration.
В salt задачи раздаются и выполняются через очередь сообщений, а исполняются уже на месте миньёнами. Причем в salt есть возможность построить дерево мастеров (salt-syndic), если машин о-о-очень много, хотя даже 1 мастер может обслуживать до тысячи машинок не напрягаясь.
Ну и еще один момент: в salt гарантируется, что процесс конфигурирования на машине выполняется только один в любой момент времени. Вы и, скажем, ваш коллега одновременно не сможете запустить процессы конфигурирования, что как не трудно догадаться может все поломать. Возможно в Ansimble это как-то тоже контролируется, но в salt это by design.
Я делал презентацию про Salt и написал пару постов: "Developing Django project with SaltStack", "Developing & Deploying Django project with SaltStack". Возможно кому-нибудь будет полезно.
Ваша презентация — моё почтение! Сделано очень круто.
Только вот вопрос возник. В последнем посту вы с git работаете через cmd.run. Вот стало интересно чем вас salt.states.git не устроил? Я им пользуюсь и вроде ок.
Только вот вопрос возник. В последнем посту вы с git работаете через cmd.run. Вот стало интересно чем вас salt.states.git не устроил? Я им пользуюсь и вроде ок.
Спасибо, рад что вам понравилось.
В посте есть объяснение:
В посте есть объяснение:
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».
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
— marselester.com/saltstack-slides.html
— marselester.com/developing-and-deploying-django-project-with-saltstack.html
— marselester.com/developing-django-project-with-saltstack.html
Спасибо за пост. Наконец-то я наглядно(на примере) понял, для чего нужны pillar.
Подскажите, структура директорий/файлов как-то определена?
salt/roots/salt имеет какое-то значение? 
А чем данный инструмент отличается, например, от Puppet?
Я знаком с Puppet лишь понаслышке.
Salt и Puppet в плане силы «конфигурирования» состояний примерно равны.
Salt кроме поддержки состояний умеет еще и оркестрацию. То есть фактически заменяет fabric.
В отличие от fabric соль использует 0mq в качестве транспорта, поэтому работает в разы быстрее, но требует предустановленного minion на машинках.
Не уверен, что в Puppet это есть.
Salt и Puppet в плане силы «конфигурирования» состояний примерно равны.
Salt кроме поддержки состояний умеет еще и оркестрацию. То есть фактически заменяет fabric.
В отличие от fabric соль использует 0mq в качестве транспорта, поэтому работает в разы быстрее, но требует предустановленного minion на машинках.
Не уверен, что в Puppet это есть.
Sign up to leave a comment.
Deploy с помощью Salt