Usamos versões de Ruby, Collectd, Ant, Java (e mais) que não estão disponíveis em repositórios CentOS ou EPEL. Até agora, nossa estratégia para instalá-los foi uma espécie de hack:
escreva um script (controlado por versão) para cada pacote que baixe a origem ou os binários do site host com o curl para o mestre Puppet e compile o código-fonte, se necessário; reembala em tarball gzipado se necessário
use o servidor de arquivos Puppet para distribuir os binários aos nossos servidores, e o Puppet se manifesta para descompactar o tarball em / usr / local (ou onde)
Escrever os scripts pode ser difícil, e eles precisam ser atualizados se um dos sites dos quais dependemos para downloads mudar sua API. Também o software é compilado separadamente em cada ambiente, o que parece um desperdício e poderia resultar em problemas com a falta de dependências em tempo de compilação (por exemplo, Ruby: require 'readline' ou require 'yaml' pode funcionar em alguns ambientes, mas não em outros)
Então, posso pensar em duas outras opções:
Basta fazer o check-in dos binários de terceiros personalizados no subversion e distribuí-los com o resto do nosso código do Puppet. Eu estou preocupado que isso irá afetar gravemente o desempenho dos checkouts e os empurrões do código Puppet; nós estamos olhando quase 800MB (e crescendo) de código de terceiros. Além disso, parece errado verificar várias versões e arquiteturas de Java lado a lado no controle de versão.
Não faça a versão controlar os binários ou escrever scripts de download - quando decidirmos atualizar o Ruby, compilá-lo em uma caixa dev e carregar o novo pacote manualmente para todos os nossos mestres de marionetes sempre que decidirmos fazer a atualização. Exceto, e se os pacotes forem eliminados? Ou ficar fora de sincronia com os diferentes mestres? No momento, podemos facilmente gerar novamente todos os nossos pacotes personalizados do zero.
Qual das três opções é melhor? Como as pessoas geralmente gerenciam softwares de terceiros personalizados e reempacotados com o Puppet? Se você criar um repositório Yum local, você controla o processo que você usa para criar os RPMs? O que acontece se o seu repositório da Yum for eliminado?
O Puppet não é realmente projetado para distribuir arquivos grandes, então você deve fazer isso fora da banda. A melhor abordagem é empacotar o software personalizado / de terceiros como RPMs e hospedar seu próprio repositório RPM. O empacotamento RPM (ou seja, arquivo de especificações e correções) deve, idealmente, ser controlado por versão e o repositório RPM deve ser armazenado em backup ou hospedado em várias máquinas.
Eu sugiro utilizar um repositório Yum para implantar todo o seu software, incluindo o que você compila. Uma vez configurado corretamente, você terá todos os seus problemas de dependência resolvidos, controle de versão, etc.
Minha tendência é ter um sistema de três ramificações (dev, qa, prod) para meus repositórios. Isso permite que determinados sistemas sejam adicionados a diferentes repositórios e executem seus passos de acordo.
Eu faço isso (e o agendamento das atualizações do yum) via Puppet.
Fazendo eco às outras duas respostas: use o sistema de gerenciamento de pacotes existente da sua distribuição.
Fazemos isso com o Ubuntu e apt para instalar o RabbitMQ e o OAuth assim:
class apt::example {
file { "/etc/apt/sources.list.d/repo.example.list":
source => "puppet:///modules/apt/repo.example.list",
ensure => present,
}
exec {"install-gpg-key":
command => "/usr/bin/curl -s http://repo.example.com/[email protected] | /usr/bin/apt-key add -; /usr/bin/apt-get update",
refreshonly => true,
subscribe => File["/etc/apt/sources.list.d/repo.example.list"],
require => File["/etc/apt/sources.list.d/repo.example.list"],
}
}
e para usar o repositório:
class apache2::platform {
package { ["librabbitmq0", "php5-amqp", "php5-oauth"]:
ensure => installed,
notify => Service["apache2"],
require => File["/etc/apt/sources.list.d/repo.example.list"]
}
[...]
}
O require aqui garante que o repositório seja adicionado antes de tentarmos instalar qualquer coisa dele.
Pode haver uma maneira melhor de lidar com a adição da chave GPG e de executar e atualizar, pois esse comando retorna um código de saída positivo que faz com que o fantoche pense que ele falhou, mas como funciona eu não gastou muito esforço para corrigir a falsa mensagem de erro.
Eu não tentei adicionar a configuração do repo ao fantoche ou automatizar a compilação e adicionar ao processo de repo para novos pacotes, mas assim que você atingir um certo tamanho, essas tarefas valerão a pena. Os backups sempre valem a pena.
O processo para RPM e yum deve ser muito semelhante.