Как люди организуют свои манифесты и модули Puppet в вашем репозитории исходного кода? Я не вижу очевидного способа поэтапного внедрения изменений в Puppet на одном мастере Puppet.
Как другие люди справляются с этим? Один экземпляр главного сервера на группу серверов / этап SDLC? Я бы очень хотел использовать одни и те же модули Puppet на каждой фазе и просто использовать Subversion, чтобы изменить, какая версия модулей Puppet применяется к каждой группе серверов / фазе SDLC, чтобы я мог вносить изменения поэтапно. Я ищу способ использовать одни и те же модули и избежать несчастных случаев и отклонений из-за дублирования модулей.
У меня есть множество серверов, которые я собираюсь использовать для управления с помощью марионетки, с несколькими этапами SDLC (жизненный цикл разработки программного обеспечения), которые нужно охватить. Аварийное восстановление, производство, постановка, приемочное тестирование пользователей, тестирование, разработка, обучение
Отредактируйте, чтобы уточнить вторую часть:
И как вы поддерживаете свои ветки в исходном репо? Например, с ветвями dev и test, а также с файлом, который определяет, откуда я беру свои патчи.
Вы редактируете:
репо: /dev/patchessource.txt, чтобы содержать «patchserver / dev»
репо: /test/patchessource.txt, чтобы содержать «patchserver / test»
и иметь эти файлы разными, и они должны поддерживать эту разницу со слиянием и всем, от разработки до тестирования, или люди имеют разные файлы для каждой среды и переносят их в целом:
репо: /dev/devpatchsource.txt, чтобы содержать «patchserver / dev»
репо: /dev/testpatchsource.txt, чтобы содержать «patchserver / test»
Таким образом, когда вы объединяете репозиторий разработчика с тестовым репозиторием, вам не нужно беспокоиться о том, что конкретный параметр разработчика перезаписывает настройки конкретного теста?
Я не вижу очевидного решения, упрощающего задачу для последующих администраторов, которые, возможно, не очень хорошо разбираются в инструментах управления исходным кодом.
Будем признательны за любые советы.
Среды как это решается. С помощью среды вы можете определять конфигурации для производства, подготовки, тестирования ua, тестирования, разработки, обучения и т. Д.
Подробное объяснение того, как это сделать, немного обширно, но вот несколько ссылок, которые вы можете прочитать, чтобы начать:
В главном репозитории у вас есть ветка для development, testing и production (или что угодно, что подходит вашему рабочему процессу). Вы с удовольствием пишете свой код Puppet в ветке разработки, фиксируете, фиксируете, нажимаете. Ваш Puppet Master обновляется (R10K), когда вы нажимаете (через какой-то Git-крючок или задание cron), и ваши узлы получают свои обновления в свое время расписания.
Предположительно, у вас есть узел, для которого установлено значение development среды, поэтому изменения, внесенные вами в development филиал. Вы можете все это проверить.
Вы довольны своими изменениями, слейтесь с веткой следующего шага рабочего процесса - скажем production. Отправьте объединенные изменения, и цикл начнется - Хозяин Марионеток получит изменения в production среда и производственные узлы применяют новую конфигурацию.
-
Я вижу, что у людей есть общее замешательство. А development ветка для Control Repo не означает «это конфигурация для машин программистов». Нет, это означает, что это ваша ветка разработки марионеток.
Итак, как вы поддерживаете набор серверов, скажем, веб-сервер, для трех команд - разработчиков, контроля качества и производства. Т.е. у каждой из этих групп есть веб-сервер, который настроен практически одинаково, но имеет нюансы: одна - это действующая производственная система, одна - группа контроля качества, а другая - разработчик.
Для этого вы используете Hiera. К каждому узлу будут применены одни и те же классы, но нюансы в параметрах или том, что у вас есть, задаются через Hiera.
Конечно, вы можете использовать ветки для обозначения «типа управляемой машины» вместо Hiera, но это немного смешно, потому что вы не будете использовать ветку Git для их реальной цели. Ветвь будет совершенно другой, и вам нужно будет вручную «объединить» их, скопировав / вставив из одного в другой. Это было бы некрасиво.