O típico modelo de marionete consiste em um mestre de marionetes e os clientes de marionetes.
Dito isto, é possível pular o mestre de marionetes completamente e apenas usar os clientes de marionetes por si mesmos. (Chamado de módulos de fantoches sem master).
Para fazer isso, você quebra o comando puppet apply em um script bash.
Aqui está um exemplo simples de um manifesto fantoche sem mestre que compila a última versão dos redis a partir da fonte e cria um RPM.
link
Aqui está um exemplo mais complexo que usamos na minha empresa chamada construtor. Você pode assistir a apresentação sobre isso aqui:
link
O Builder é apenas um script que qualquer desenvolvedor pode aplicar em qualquer VM que instale automaticamente um pacote de produtos por meio do fantoche. É de código fechado, mas vou tentar o meu melhor para explicar a arquitetura básica.
Ele é escrito para que, quando o desenvolvedor executar o construtor, seja solicitada a versão e a edição do software que deseja instalar.
$ sudo ./builder.sh
"Welcome to Builder"
1) Enterprise
2) Basic
3) Quit
Please select an edition: 1
"You have selected: Enterprise"
1) 7.5.0
2) 7.6.0
3) 7.7.0
4) 7.8.0
5) Quit
Please select a release: 2
"You have selected 7.6.0, applying manifests"
Uma das vantagens de envolver seu manifesto de marionete em um script bash como este, é que você pode simplesmente escrever suas próprias variáveis de facetador que podem ser usadas posteriormente. Olhando para o exemplo simples do github / spuder / fpm-redis:
Prefira as variáveis com maiúsculas 'FACTER'
cat fpm-redis
#!/bin/bash
export FACTER_REDIS_VERSION='2.8.8'
puppet apply ./manifests/init.pp
O manifesto de fantoches pode então se referir à variável minúscula (a palavra 'FACTER_' é removida automaticamente).
cat ./manifests/init.pp
class foo {
file { "${::redis_version}":
ensure => file,
content => 'foo'
}
}
include foo
Voltando ao código do construtor, ele é modularizado para que haja um diretório para cada produto que precisa ser instalado. Dessa forma, você pode definir arquivos de propriedades.
$ tree /tmp/builder
|
build
\_ Enterprise.prop
\_ Basic.prop
|
packages
\_ java_7
\_ manifests
\_ init.pp
\_ java_6
\_ manifests
\_ init.pp
\_ foo
\_ manifests
\_ init.pp
|
builder.sh
Os arquivos de propriedades são apenas scripts bash que contêm variáveis de ambiente e também uma lista de manifestos de puppet a serem aplicados. Às vezes, os pacotes precisam ser instalados em uma ordem específica, então eles são divididos em operações pré e pós.
$ cat Enterprise.prop
PRE_APPLY_LIST= "build/java_6/manifests/init.pp \
build/foo/manifests/init.pp"
POST_APPLY_LIST= "build/foobar/manifests/init.pp"
export FACTER_FOO='bar'
export FACTER_DB_PASSWORD='correct horse battery staple'
$ cat Basic.prop
PRE_APPLY_LIST= "build/java_7"
export FACTER_HERP='derp'
Voltando ao prompt do menu mencionado anteriormente. O Construtor gerou a lista de opções de menu, iterando sobre o diretório de construção.
$ cat /tmp/builder.sh
# prompt the user for which product
OPTIONS='ls build/*.prop'
for opt in $OPTIONS
do
PP_APPLY=$opt
break
done
# import the variables from the property file
source $PP_APPLY
# install the desired packages
puppet apply $PRE_APPLY_LIST
puppet apply $POST_APPLY_LIST
Esta é uma ótima maneira de aproveitar as vantagens do fantoche, sem precisar de um mestre de marionetes.