Ну у вас две у меня хостов за 20, тут виртуалхосты хочешь, не хочешь - либо в темлейты, либо upload файлы по хостам из inventory, и всё в git .

> upload файлы по хостам из inventory, и всё в git единственный рабочий вариант :(

рулить виртуалхостами ещё как-то можно, но если появляются всякие if-ы map-ы и т.д. становится всё печально

Вот поэтому у нас виртуал-хосты это часть тасков роли приложения

А не общей роли тginx

а ну т.е. оно выкатывается с приложением и тоже под контролем версий

Ну конечно. Я же говорю - все в ансибле

ну методов обеспечения контроля изменений хватает, главное применять их по уму. С postgresql например мне проще playbook из galaxy юзать, чуть допилив template

Я вот не сторонник galaxy потому что нет доверия к вендору

так я хоть и тюнить легче под параметры по хосту

Вот хер его знает что он там поменял спустя месяц

А мне надо конфигурацию раскатать. А если --check --diff показывает changes?

Короче трата времени на то что можно было бы и не тратить

Если уж есть желание использовать что то из galaxy - можно просто оттуда скопипастить нужное, и положить в свою роль

Гарантия неизменений 100%. Экономия времени тоже

ну дык срез делашь же и у себя свою версию playbook поддерживаешь, не рисуя с нуля (коллективный разум хорошая подмога и экономит время).

Как правило там много всего лишнего

точнее роли

Проще оттуда накопипастить к себе

Куча вот этого "мета конфигурирования" которое нафиг не вперлось белым людям

Может есть смысл для компаний со 1000 хостов. Но у 90% их не 1000.

И зачем мне такой переусложненая роль? А если я нанял джуниора как он в этом разбираться будет?

У нас в компании идеалогия такая - каждый разработчик - девопс.

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

бедняги разработчики ^^

И не надо потом задаваться вопросом - "А где нам девопса найти?"

Да там много ума не надо чтобы с ансиблем разобратьсяю. Я вас уверяю. Все успешно с этим справлялись

Бонусом ко всему этому идет то, что экспертиза размазывается более плавно по команде разработки.

Люди лучше понимают друг друга. И самое главное нет такого "А эти разработики, суки, опять что то сделали мне на сервере"

- DevOps (c).

Ну или сис-админы тоже часто грешат такими высказываниями.

не совсем это правильно, когда разработчики рулят продакшеном

но жело ваше

Так по факту они не рулят продакшеном

по факту они рулят ансиблом, который..

С мета программированием частично согласен (выбираю роли на galaxy которые этим не особо грешат). В плане devops-каждый и роста экспертизы - только поддержу, я таким образом сейчас пытаюсь объеденить работу сисадминов (типичных таких, выросших (или вросших) в ИТ-инфраструктуру и программистов (в основном web) ).

метапрограммирование! ха!

который в git

вы видели debops?

видел

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

Вы знаете, мне иногда разработчик говорит - "Я сделал задачу"

Вы знаете, мне иногда разработчик говорит - "Я сделал задачу"

Хорошо, что говорят!

А по факту она сделана когда: смержена в мастер, раскатана конфигурация, прошла QA, задеплоена на прод и т.д. и. т.п.

Т.е. огромный пласт пролетет мимо.

А если вовлекать разработчика к конфигурированию у него целый новый мир открывается.

Да, всякие специфичные кластерные штуки я не заставляю делать

Но блин, опцию в конфиг добавить это он явно в состоянии

Или extra хедер в nginx. CORS там, или whatever.

А потом если видишь что у чела получается и легко идет, можно пытаться это развивать

И все счастливы как бы.

У нас был джуниор один нанят, через год от нас уволился и ушел работать на 130 тыщ.

Ещё один профит от этого - ревью конфигов, кто-то может сразу сказать - "это будет тормозить, а это не секьюрно".

Вот вам показатель как качественно растет уровень людей при таком подходе.

Ещё один профит от этого - ревью конфигов, кто-то может сразу сказать - "это будет тормозить, а это не секьюрно".

Да, естественно. Плюс это публичные обсуждения. Все видят, все наращивают опыт.

А не когда там девопс себе надевопсит имедж в докере.

359 новых сообщений, у вас тут хардкор начался наконец?

А разработчик будет ныть почему это у него file_put_contents в webroot не созраняет корретно.

359 новых сообщений, у вас тут хардкор начался наконец?

Все началось с моего вброса про докер :)

359 новых сообщений, у вас тут хардкор начался наконец?

это не хардкор а филиал ЛОРа - пора отписываться

это не хардкор а филиал ЛОРа - пора отписываться

«Скатились, подписываюсь»

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

так кто конфиги nginx-a то правит?

фронтендер?

Нет. не перегибай :)

в целях наращивания опыта? )

Но и ткие фронтендеры у нас тоже были.

Удобно кстати.

Да пусть правит, оно же в релиз не переедет пока не пройдёт ревью у сисадмина

Все так, да.

Особенно когда работает один бэкенд + фронтен на фиче и бекендер может помочь фронтендеру с конфигурацией.

Да пусть правит, оно же в релиз не переедет пока не пройдёт ревью у сисадмина

http://s003.radikal.ru/i201/1208/c1/d0e7323f980a.jpg

Архитектор - Тимлид/Девопс - Разработчик/Девопсик - Разработчик/Девопсик - Разработчик - Разработчик - Разработчик - Junior

Вот примерно так я вижу "размазываение" экспертизы.

девопсики :D

Александр, я ещё помню как такой картинку виндоузфаны, линуксойдов тролили ))

*картинкой

Первые двое могут деплоить конфигурацию на прод, следующие двое могут делать пуллреквесты к ней.

Цифры "двое" - утрированы и поддаются адекватному масштабированию.

Чё не так-то? Дмитий дело-же говорит. Я тоже к этому команды двигаю. На прод, выкатывается только с master, в master непозволено пушить никому кроме тимлида и суперадмина. Защищённые ветки же. Ключи для выкатки и т.п. в gitsubmodule на которые пермишины только у суперадмина и тимлида.