Automatizando a implantação do servidor

Acho que estou constantemente configurando servidores e VPS praticamente idênticos para vários de meus clientes e isso pode consumir muito tempo. Geralmente, a única coisa que muda entre cada implantação é o site diferente que deve ser veiculado. Existe uma maneira fácil de automatizar tudo isso e tomar a monotonia chata de configurar 56 servidores idênticos?

Os servidores que implantei até agora são apenas o Ubuntu, mas pode ser possível que eu comece a usar outros sistemas operacionais Linux ou mesmo Windows. Até agora, olhei para Capistrano, mas parece focado em escrever pequenos programas de rubi para fazer o trabalho, e não tenho nenhum conhecimento.

O Puppet parece perfeito para o que você está tentando fazer, com a ressalva de que, no momento, não há suporte para o Windows.

No seu caso, você definiria um nó do servidor em termos de todos os pacotes que são idênticos nas máquinas. Em seguida, você define os hosts individuais como nós que herdam do Servidor e configura as coisas exclusivas específicas para ele.

O Puppet é declarativo - permite que você descreva suas caixas em termos dos recursos que cada caixa deve ter. Então, se você quiser ssh- você escreve uma classe para esse recurso - e dentro da classe você pode incluir uma lógica sobre como o ssh é chamado de ligeiramente diferente no FreeBSD vs Ubuntu. Ele também sabe usar yumdentro do Redhat e apt-getdentro das distribuições baseadas no Debian e portsnos BSDs. Agora, no nó do servidor, você terá uma linha como include ssh- e o fantoche fará a coisa certa e colocará o SSH na máquina sem que você precise se lembrar se é Ubuntu, Redhat ou FreeBSD.

O interessante é que todos os itens do servidor residem em um único local - e, a qualquer momento, você adiciona à definição do nó do servidor, TODAS as máquinas atualizam sua configuração de acordo.

No momento, estou gerenciando apenas três caixas usando o Puppet - mas já valeu a pena. Depois de passar uma semana configurando uma caixa que usaremos para a apresentação de estímulos em um experimento, o driver da placa gráfica era muito antigo na versão do Ubuntu que eu coloquei nela (8.04). Eu tive que instalar o Ubuntu mais recente (9.04), mas depois disso eu apenas tive que apt-get e executar o fantoche - e tudo o que eu havia passado uma semana configurando foi restaurado.

O Puppet tem um pouco de curva de aprendizado, mas evitei aprender o Ruby - sei que estou usando, já que é nisso que está escrito o fantoche -, mas até agora consegui apenas modificar os exemplos em a documentação e as receitas no wiki . Outra desvantagem é que o boneco demora um pouco mais para fazer as coisas pela primeira vez. O lado positivo é que tudo o que você muda em todas as suas máquinas é armazenado em um só lugar - é prática padrão manter sua configuração de marionetes em um sistema de controle de versão - para que você possa sempre olhar para trás e ver como configurou servidores no passado - ou reverta algumas alterações sem êxito.

Finalmente, aqui está um vídeo rápido que faz uma demonstração simples de marionetes que me iniciou rapidamente.

Nós usar Cobbler e Puppet para construção e automatização de configuração de ambas as máquinas reais e virtuais.

O sapateiro une o DHCP, a inicialização PXE e o Kickstart para tornar a implantação nada mais do que adicionar um perfil de máquina e pressionar o botão liga / desliga. Para VMs, o koan comando faz a mágica (no nosso caso) do Xen para iniciar a instalação - no que dom0eu apenas digito:

koan --system vps.fqdn --server cobbler --no-gfx

depois, virsh consoleassista a um edifício VPS sem nenhuma interação.

Usamos o RHEL e temos vários perfis configurados para particionar discos, configurar redes e instalar pacotes básicos para diferentes classes de servidores. O Sapateiro suporta raças Debian e Ubuntu, mas nunca tentei. Um aspecto a parte: outros usos interessantes do Cobbler incluem a execução de ISOs de teste e atualizações de firmware da HP .

Depois que nossos sistemas são construídos com o Cobbler Puppet, assume a configuração dos aplicativos, daemons do sistema, registra a caixa no RHN etc. O Puppet é executado como um daemon que verifica periodicamente se a configuração do sistema corresponde aos manifestos definidos - você sabe que suas atualizações foram removidas para todos os servidores. Também é uma ótima maneira de garantir que uma caixa que esteja em manutenção tenha a configuração correta antes de devolvê-la ao serviço ativo.

Fantoche é realmente incrível. Você não precisa controlar todos os aspectos da sua configuração - comece gerenciando algo simples que você precisa configurar em todas as caixas ( sudoersé o exemplo canônico) e leve-a de lá. Verifique se os manifestos do Puppet também são versionados; nada é melhor do que ser capaz de reverter facilmente para uma configuração em bom estado sem ter que lembrar o que ajustar.

Onde estou trabalhando no momento, temos que gerenciar a parte Linux do nosso farm de servidores, que é um pouco mais de 300 servidores Linux. Isso inclui principalmente os HP Proliants, seguidos pelo IBM 3850s, alguns blades IBM, VMware ESX e alguns KVM para nossos servidores de gerenciamento interno.

sapateiro

Vimos o sapateiro, mas o problema era que o sapateiro é muito específico do RHEL / Red Hat. Precisamos oferecer suporte a RHEL e SLES, pelo menos, e o Ubuntu é o próximo.

fantoche

Consideramos o fantoche, no entanto, mais tarde decidimos contra, pois depende do Ruby, o que significa que uma atualização do Ruby poderia potencialmente quebrar nosso sistema de gerenciamento.

fio quente

Hotwire é o que usamos (desenvolvido internamente, mas é de código aberto) e o fizemos nos últimos anos. Primeiro, inventa os sistemas que serão construídos, o que significa inventariar o datacenter, rack, hardware, sistema operacional, rede etc. Depois que o sistema é construído, o inventário automático do hotwire mantém o inventário sincronizado, enquanto o cfengine os mantém. A Hotwire conhece o hardware do servidor conversando com os dados SMBIOS / DMI na Bios via python-dmidecode .

Os pontos de bônus são que ele combina o inventário e o processo de compilação em um, portanto, há menos para gerenciar, e o recurso de inventário ao vivo é ótimo, como sabemos se algo não estiver certo.

As desvantagens são que a interface do usuário ainda precisa ser polida, e há bugs aqui e ali, mas o desenvolvimento ainda está quente e os bugs relatados são corrigidos relativamente rápido.

cfengine

Usamos cfengine porque, além disso, e fantoche, não há mais nada. Na verdade, é uma boa ferramenta, mas "boa" apenas em função de quão boas são suas políticas - se você definir políticas perigosas, um pequeno erro poderá causar muitos danos. Por exemplo, por política, não "modificamos" os arquivos, os substituímos ou não. Além disso, todos os arquivos substituídos têm um cabeçalho que faz com que qualquer pessoa que o edite saiba que será substituído na próxima vez em que for executado (é executado via cron de hora em hora).

A configuração e todos os arquivos enviados pelo cfengine aos servidores também são mantidos em um SCM e, usando ganchos pós-confirmação, sempre que possível, verificamos a sintaxe e, se isso falhar, a confirmação é rejeitada. Isso é fácil para aplicativos agradáveis, como o Apache, mas não é tão fácil para a maioria dos aplicativos corporativos.

Eu tive sucesso com o Puppet . Chef é um novo a surgir. Para obter uma lista mais longa de opções e um gráfico de comparação, consulte o artigo da Wikipedia Comparação de software de gerenciamento de configuração de código aberto .

Para automatizar a instalação, dependendo do sistema de destino:

• Debian / Ubuntu: FAI ou pré-configuração
• RedHat / Fedora: Kickstart
• Novell / openSuSE: AutoYaST
• Solaris: Jumpstart
• Windows: unattended.sourceforge.net

Para o gerenciamento da configuração, eu sugeriria o uso de fantoches.

Estou tendo muito sucesso com o Puppet , mas você precisa escrever muita configuração.

Outro voto para o Puppet aqui. Nós o usamos extensivamente para executar todo o gerenciamento de instalação e configuração de servidores e aplicativos. Mais de 200 nós e contando. Aparentemente, o suporte ao Windows está em desenvolvimento, mas em que estado não tenho certeza.

Ainda estamos analisando o lado inicial da inicialização do sistema operacional, mas, como mencionado acima, o Cobbler parece interessante. Atualmente, estamos usando uma mistura de inicialização PXE com pré-configuração do Debian / Ubuntu, mas não é o ideal.