Chef: Pré-instale pacotes ou instale tudo do zero (rápido / inflexível versus lento / flexível)

Question

Estou curioso em saber que é uma boa estratégia pré-construir binários (instalar pacotes) e usar o chef apenas para gerenciamento de configuração. Teoricamente, isso deve acelerar o processo de inicialização quando precisamos de novas máquinas (pico de tráfego), especialmente se usarmos nuvens como a AWS, onde podemos criar nossas próprias AMI (imagens), ao mesmo tempo em que não seria flexível trabalho ..

Aguardo com expectativa os seus pensamentos sobre a questão, juntamente com as melhores práticas, experiências e ideias!

    

Answer 1

Ambas as extremidades do espectro têm seus prós e contras, assim como a área intermediária.

Use uma AMI pública padrão com configuração dinâmica do sistema na inicialização

(+) Não requer aprender como construir AMIs.

(+) Não requer aprender como gerenciar uma AMI histórica estável.

(+) Fácil de alterar e testar a configuração do sistema editando a configuração e executando uma nova instância.

(+) Fácil de gerenciar entre regiões, conta compartilhando arquivo (s) de configuração.

(+) Fácil de executar variações da configuração, ajustando as regras de configuração de inicialização.

(-) A inicialização de um sistema pode ser lenta ou muito lenta, dependendo de quanto trabalho o processo de configuração de inicialização precisa realizar.

(-) Requer compreensão de como automatizar a configuração da inicialização, especialmente se usado com instâncias de Auto Scaling ou Spot.

B. Pré-construa o AMIS personalizado

(+) A inicialização é rápida, já que nenhuma configuração precisa ser executada.

(+) funciona bem com as instâncias do Auto Scaling e Spot.

(-) Requer aprender como construir e gerenciar AMIs efetivamente.

(-) Requer a criação de uma nova AMI toda vez que a configuração desejada for alterada.

(-) Requer a criação de uma nova AMI sempre que os patches de segurança do sistema operacional forem liberados.

(-) longo ciclo de edição / criação / teste ao alterar a configuração

(-) Diversas AMIs são necessárias para diferentes regiões, contas diferentes (a menos que compartilhadas), diferentes variações de configurações, diferentes arquiteturas de instâncias.

C. Algo entre

Você pode obter alguns dos benefícios (e alguns dos inconvenientes) de ambas as estratégias, fazendo algo no meio: Crie uma AMI personalizada básica que tenha mais do que você precisa para suas instâncias e execute uma configuração dinâmica na execução tempo que atualiza e completa a configuração, aplicando quaisquer variações específicas necessárias.

Isso acelera o tempo de inicialização, possivelmente em muito, mas também dá alguma flexibilidade e não é necessário reconstruir AMIs com frequência.

Recomendações

1. Comece criando scripts automatizados (ou receitas de chef) que levarão uma AMI pública e a configurarão para o sistema desejado.

2. Use a configuração automatizada com AMIs públicas (abordagem A acima) enquanto isso funcione para você.

3. Quando e onde você se depara com problemas de desempenho de inicialização, use a configuração automatizada para criar AMIs personalizadas (abordagem B acima). Automatize esse processo o máximo possível para que você possa executá-lo quantas vezes for necessário.

4. Se você tiver várias variações de sistema sobre a mesma base básica, crie uma AMI de base personalizada e use a abordagem C acima para executar os diferentes tipos de sistema.