Как стать автором
Обновить

Комментарии 13

gitfs у нас очень тормозил. Заменили на git pull на мастере и потом работали просто с файлами на диске. В остальном — та же история, что и у вас.

Здравствуйте!
Да, мы тоже думали о таком варианте, но проблему удалось решить.

То есть пока у вас еще один мастер? Про мультимастер не думали?

Здравствуйте!

На самом деле, у нас два мастера: один — в проде, второй — для тестовых веток. У них общие ключи миньонов, поэтому для перехода на мультимастер нужен будет только общий ключ мастера, но один пока хорошо справляется.
> Для тех команд, которые использовали ранее Ansible, будет актуальной возможность использовать плейбуки от Ansible. Это позволит безболезненно мигрировать на Salt.

Можете поделится результатами этого подхода?
Здравствуйте!

Мы написали стейты, которые выполняют плейбуки. Это позволило нам отложить написание новых стейтов — полноценной замены плейбуков.

Так как Ansible у нас не был внедрен повсеместно (всего было около 50 плейбуков), скорее, это была проба инструмента, постепенно мы переделали плейбуки на стейты.
web gui какие-нибудь используете?
github.com/latenighttales/alcali?

Пока не используем. Указанный Вами alcali смотрели, и он нам очень понравился! В нём только необходимо сделать авторизацию в freeipa.

Salt master в HA режиме? Или одна нода?

HA-режима нет, одна нода. Сейчас Salt используется для применения конфигурации. Деплой, оркестрацию еще не используем, поэтому можем себе позволить некоторый простой в работе мастера.

К тому же, сам мастер управляет собой, и вся его актуальная конфигурация есть в Git'е, поэтому создание нового мастера не проблема.
К тому же, сам мастер управляет собой, и вся его актуальная конфигурация есть в Git'е, поэтому создание нового мастера не проблема.

тогда есть беспректис — не использовать gitfs (лишний гемор с кэшированием), а использовать отдельный стейт для синхронизации мастера и гита (мастер сам себя конфигурирует)


В остальном — ок, понял

Согласны! Это сильно бы упростило использование Salt'a в случае с одним репозиторием, но у нас их два. Они имеют одинаковую структуру и должны правильно мержиться (пиллары и стейты).
Заюзали gitpython ( по совету самих солт спецов с enterprise ) вроде помогло, но подтикает в другом месте ( salt api, ws4py + cherrypy ) будем еще tornado пробовать
Вот как! Оказывается, они сами рекомендует pygit2.

А есть ли какие-то ограничения или особенности при использовании GitPython?

Мы пока API мало используем, CherryPy устраивает. Только после перезапуска salt-api бывает, что первый запрос фейлится.

А мы тоже на сайт ссылались, но смогли достать enterprise спецов с их стороны и они сказали что, мол, юзайте gitpython потому он юзает просто git( + у них тоже проблемы были и просто заюзали gitpython и все мол хорошо ), так как pygit2 пытается переизобрести обычный git через python

Зарегистрируйтесь на Хабре , чтобы оставить комментарий