LINUX.ORG.RU
ФорумAdmin

Коллизии в сценариях Puppet

 


0

2

Приветствую, коллеги. Столкнулся с неприятной особенностью puppet. Наделал несколько модулей для разных задач и разных серверов. И был очень удивлён когда увидел ошибки, говорящие, что в разных модулях пересекаются имена puppet-ресурсов, а иногда даже их параметры. В результате ничего не работает пока не переименуешь все ресурсы. А когда переименуешь ресурсы вылазят другие подобные ошибки вроде этой:

err Failed to apply catalog: Parameter alias failed: sshd_tests can not create alias sshd: object already exists at /etc/puppet/modules/ssh_tests_env/manifests/init.pp:28

Кто каким образом изолирует модули паппета друг от друга? Или может быть есть другие способы обойти эту проблему. Не хотелось бы писать один огромный модуль сразу для всех систем, чтобы там было по 50 переменных на каждый сервер...

Как вариант - делать префикс с названием модуля, например?

С коллизиями перемеменных не сталкивался ни разу.

oxumorron
()

я организую что-то типа:

 file { "/path/to/file":
	ensure  => "$role"? {
	value1  => present,
	value2  => present,
	value3  => present,
	value4  => absent,
	other    => absent,
	value5  => present,
	value6  => present,
	},
	mode    => '0755',
	owner   => "$var",
	group    => "$var",
	source   => "puppet:///modules/environment/file",
	require  => File["something"],
	}
}

соответственно, в описании ноды проставляю переменные для конкретной ноды (можно и вообще для всего). Если тебе надо содержимое файла с зависимостью от ноды - то же варианты есть.

uspen ★★★★★
()
Ответ на: комментарий от uspen

Не хотелось бы писать один огромный модуль сразу для всех систем

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

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

либо у тебя наплодятся модули (очень грубо):

kvm_moscow_apache2
kvm_spb_apache1.3
web_spb_apache1.3_nginx

вместо

node kvm {
	include "generic-server"
	
	webserver { 'apache1.3': 
	geolocate => 'spb',
		}
	}

init.pp

define webserver($geolocate) {
 package { "$name":
        ensure   => "$geolocate?" {
        moscow   => absent,
        spb      => latest,
        value3   => latest,
        value4   => absent,
        }
}
}

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

uspen ★★★★★
()
Ответ на: комментарий от oxumorron

Именно этим я и занимался, пока не натолкнулся на коллизию ещё более низкого уровня, ошибку с которой я и привёл в стартовом сообщении.

itJunkie
() автор топика
Ответ на: комментарий от uspen

Тоесть ты видишь только один способ решения этой проблемы, тот которого я хотел избежать?

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

itJunkie
() автор топика
Ответ на: комментарий от itJunkie

Если честно, я вообще не понимаю нахрена нужна эта модульность, если область видимости общая для всех модулей.

Получается, что если я скачал два разных модуля, которые пересекаются в обработке одного и того же файла, то без того чтобы залазить внутрь этих модулей, я никогда не заставлю их работать вместе. На мой взгляд это маразм. Ибо если мне надо будет в процессе работы два раза обновлять один и тот же файл, то я всёравно буду это делать и то что его сначала дёргает один сценарий, а потом другой, не имеет особого значения, кроме порядка выполнения этих двух правок.

itJunkie
() автор топика
Ответ на: комментарий от itJunkie

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

Очевидно, не тот набор, чтобы наступить на такие грабли.

oxumorron
()
Ответ на: комментарий от itJunkie

если область видимости общая для всех модулей.

Неправда, область видимости в каждом модуле своя, если в модуле нет ошибки.

Если не ошибаюсь,

$::variable - глобальная область видимости
$module::variable - область видимости модуля

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

Такой подход совершенно некорректен. Ресурс должен определяться только в одном месте. Если ты говоришь, что файл А должен иметь определённое содержимое и права, puppet будет поддерживать файл именно в этом состоянии. В манифесте не может быть противоречий, и дважды задать один ресурс тебе никто не позволит.

Смотри в сторону виртуальных ресурсов, возможно это то, чего ты хочешь.

router ★★★★★
()
Последнее исправление: router (всего исправлений: 1)
Ответ на: комментарий от router

Если в site.pp в описании разных нод включать вызов классов из модулей, то область видимости у них пересекается.

node 'virtual_test' { class { 'base_gentoo_system_1': } }

node 'puppet-test' { class { 'base_gentoo_system': } #class { 'iptables_test_class': } class { 'base_apache_class': } class { 'base_mysql_class': } }

Если же инклудить куски модулей, то пересечений не происходит: node 'cheldc','yardc' { include roles::regional_shares }

# bill tests node 'billtest','coretest','zbilltest' { include roles::ssh_tests_env }

И эту инфу я смог выудить только в реальном общении в IRC чате паппета.

itJunkie
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.