Подскажите, а вы посылаете pull request-ы в community кукбук если что-то исправляется?
Если да, то как потом мержите вашу модифицированную версию с той что в community? Ведь рано или поздно приходит необходимость обновлять кукбук и совсем не хочется сидеть на своем старом модифицированном.
Печально, но в популярном Hetzner и Leaseweb на наших серверах смогли воспользоваться этой уязвимостью. Заметили мы это только потому что резко вырос UDP трафик
наши разработчики используют один унифицированный образ с фиксированными версими всего и всея.
Ну а как же обновление системы? Постоянно выходят новые обновления того же CentOS-а. Вы вообще все версии всех пакетов (в том числе системных) держите в puppet-е?
Вы можете хранить конфиги и в build тулзах, по сути разницы нет, просто тогда у вас странно процесс разработки, деплоя и тестов построен, если допускается ситуация с конфликтом версий.
Так вот как раз с build-tools не допускается ситуация с конфликтом версий.
Тогда у вас получается очень увесистая конфигурация puppet. Считайте каждую node описать, да еще и с вервиями софта и рецепами настроек. Я как раз за простоту. Я уже писал что считаю что на puppet нельзя навешивать логику обновления и контроля версий, особенно если у вас много рецептов настройки и тд. Проходил это очень давно и личный опыт показывает что это сильно усложняет конфигурацию в puppet-е.
Мне нравится схема = пакеты контролируются через build-tools, настройки через puppet. В таком варианте просто обнаруживать причину проблем, почему на том или ином сервере не та версия софта, или не те настройки. Понимаешь куда смотреть сразу.
Как раз build-tools и создает образ дистрибутива в виде готового репозитария. Настройки часто меняются, оптимизируются, поэтому носятся они puppet-ом. Плюшки заключаются в том что вы используя build-tools можно держать много ревизий ОС и обновлять по необходимости.
Простите, а вы накатываете обновления пакетов на сервера без тестов?
У нас подобная проблема решается средствами puppet с подробным описанием зависимостей и специфичными репами врода testing для тех пакетов, которые пересобираются руками у нас.
И цикл deploy`я идет: локальные виртуалки -> тестовый продакшен -> продакшен.
Мне кажется, ваш путь излишен в связи с современными утилитами развертывания…
Объясню почему я против контроля версий софта через puppet. Допустим вы послали команду на testing среду обновить php. Puppet пришел все красиво обновил, передернул apache и все завелось и работает. Вы прогнали тесты и теперь очередь за продакшном. Вы посылаете команду обновить php на продакшне и puppet ушел обновлять всем и сразу. В итоге продашкн у вас находится под рабочей нагрузкой и apache при этом не рестартуется как положено из-за того что на некоторых серверах была высокая нагрузка и apache просто подвис и не смог перезапуститься, остался слушать сокет и ушел в себя. Его остается только прибить и запустить занова.
Получается что в тестинге все обновилось как надо, а в продакшне получили пачку серверов с лежачим apache-ом, который нужно еще по мониторингу отследить и поднять. Спрашивается — это контролируемое обновление? Я считаю что нет.
Puppet с моем понимании должен заниматься исключительно настройкой софта, но как ни установкой и обновлением.
Вы слишком буквально воспринимаете мой пример. Конечно админы как и манагеры в курсе что «химичат» программисты. Я пытаюсь вам донести немного другое: может быть ситуация, что код в тестинге не работает, из-за того что версии пакеты более свежие. Происходит это из-за того что налали девел среду из публичных репозитариев, через какое-то время налили тестинг среду тоже из публичных репозитариев и софт уже новее и продукт по каким-то причинам не работает. В таком случае тестировщику придется вернуть продукт на доработку и время разработки автоматом увеличивается.
С другой стороны если пакетная база фиксированная, то от девела до продакшна пакеты одинаковые и проблем связанных с версиями софта — не будет.
В практике я придерживаюсь того, что система всегда обновления до максимально возможного состояния в пределах мажорной версии дистрибутива. За все 7 лет работы с CentOS/Debian я не видел ни единого минорного обновления (в пределах версии дистрибутива), которое что-либо сломало. Это же собственно для чего и нужен стабильный дистриубтив — никаких изменений в функционале и полная обратная совместимость.
Как не печально какая бы стабильный не был CentOS, баги есть и будут. С тем же libxml2 недавно был случай связанный с php, когда после обновления не корректно работали некоторые функции в php. CentOS если говорить на чистоту стабилен только в своих base и updates репозитариях но все используют еще epel, repoforge и тд, так как никому не интересно пользоваться совсем старым софтом.
Так что я по-прежнему не понимаю кейса.
В данном примере разработчики должны получить до упора обновленную систему и поддерживать ее в таком состоянии все время, пока они что-либо пишут во избежание проблем.
А зачем их напрягать этой проблемой, если им можно предоставить готовую среду разработки? Суть DevOps как раз состоит в кооперации труда. Время разработчиков стоит больших денег и я вам открою большую тайну — далеко не все разработчики умеют вмеяемо пользоваться консолью.
Кроме того с момента разработки до продакшна как правило проходит много времени и за это время много может обновиться.
Да, это не касается, например, того же Epel и тем более уж всяких RpmForge, где творят весьма нестабильные вещи подчас, но и из них нужны обычно единицы пакетов.
Ну у кого как. Мне попадались билды, где epel-а было 15-20% пакетов и еще столько же собственной сборки. Даже банальные LAMP пакеты сильно старые в базовых репозитариях и почти все пользуются сторонними репозитариями.
А вы считали сколько весит репозитарий, который вмещает весь base, updates, epel и тд? Это Теробайты данных. Здесь же вам собирается готовый репозитарий 300мб причем вы можете регулярно его версионировать и иметь еще c 10-к ревизий.
Но все равно честно говоря, не совсем понимаю, зачем это нужно. Сделать собственный репозиторий и назвать его MyAnotherCentosDistro и перенести туда десяток пакетов, например, из Epel? Это же ад адский каждый раз зависимости пакетов разбирать
Так в том то и соль что утилита стягивает все пакеты с зависимостями.
Но все равно вопрос — почему нельзя использовать исходные репозитории и в чем опасность этого?
Опишу проще, допустим программисты взялись что-то писать. Для них налили виртуалки и они что-то там химичат. Через месяц приходят с каким-то результатом, который нужно протестировать. Соответственно наливаются testing виртуалки а на них все работает по другому и немного криво потому что оказалось что за месяц обновился libxml2, из-за чего по другому стали работать какие-то функции. Ну и когда это все дойдет до продакшна, на тот момент тоже что-то обновится и вполне возможно работать не будет как надо. Поэтому и используются build-tools чтобы избежать подобных проблем.
Если да, то как потом мержите вашу модифицированную версию с той что в community? Ведь рано или поздно приходит необходимость обновлять кукбук и совсем не хочется сидеть на своем старом модифицированном.
Ну а как же обновление системы? Постоянно выходят новые обновления того же CentOS-а. Вы вообще все версии всех пакетов (в том числе системных) держите в puppet-е?
Так вот как раз с build-tools не допускается ситуация с конфликтом версий.
Мне нравится схема = пакеты контролируются через build-tools, настройки через puppet. В таком варианте просто обнаруживать причину проблем, почему на том или ином сервере не та версия софта, или не те настройки. Понимаешь куда смотреть сразу.
Объясню почему я против контроля версий софта через puppet. Допустим вы послали команду на testing среду обновить php. Puppet пришел все красиво обновил, передернул apache и все завелось и работает. Вы прогнали тесты и теперь очередь за продакшном. Вы посылаете команду обновить php на продакшне и puppet ушел обновлять всем и сразу. В итоге продашкн у вас находится под рабочей нагрузкой и apache при этом не рестартуется как положено из-за того что на некоторых серверах была высокая нагрузка и apache просто подвис и не смог перезапуститься, остался слушать сокет и ушел в себя. Его остается только прибить и запустить занова.
Получается что в тестинге все обновилось как надо, а в продакшне получили пачку серверов с лежачим apache-ом, который нужно еще по мониторингу отследить и поднять. Спрашивается — это контролируемое обновление? Я считаю что нет.
Puppet с моем понимании должен заниматься исключительно настройкой софта, но как ни установкой и обновлением.
С другой стороны если пакетная база фиксированная, то от девела до продакшна пакеты одинаковые и проблем связанных с версиями софта — не будет.
Как не печально какая бы стабильный не был CentOS, баги есть и будут. С тем же libxml2 недавно был случай связанный с php, когда после обновления не корректно работали некоторые функции в php. CentOS если говорить на чистоту стабилен только в своих base и updates репозитариях но все используют еще epel, repoforge и тд, так как никому не интересно пользоваться совсем старым софтом.
А зачем их напрягать этой проблемой, если им можно предоставить готовую среду разработки? Суть DevOps как раз состоит в кооперации труда. Время разработчиков стоит больших денег и я вам открою большую тайну — далеко не все разработчики умеют вмеяемо пользоваться консолью.
Кроме того с момента разработки до продакшна как правило проходит много времени и за это время много может обновиться.
Ну у кого как. Мне попадались билды, где epel-а было 15-20% пакетов и еще столько же собственной сборки. Даже банальные LAMP пакеты сильно старые в базовых репозитариях и почти все пользуются сторонними репозитариями.
Так в том то и соль что утилита стягивает все пакеты с зависимостями.
Опишу проще, допустим программисты взялись что-то писать. Для них налили виртуалки и они что-то там химичат. Через месяц приходят с каким-то результатом, который нужно протестировать. Соответственно наливаются testing виртуалки а на них все работает по другому и немного криво потому что оказалось что за месяц обновился libxml2, из-за чего по другому стали работать какие-то функции. Ну и когда это все дойдет до продакшна, на тот момент тоже что-то обновится и вполне возможно работать не будет как надо. Поэтому и используются build-tools чтобы избежать подобных проблем.