instância do Amazon EC2, opções viáveis e ferramentas de gerenciamento para o ambiente de desenvolvimento

Question

Sou freelancer e pretendo trabalhar com outros freelancers nos próximos tempos. Como eu estaria possuindo o (s) projeto (s), também quero possuir o ambiente de desenvolvimento. Todos nós estaremos trabalhando em nossos respectivos locais. Eu tenho pensado em usar o serviço EC2 da Amazon com o propósito de erigir um ambiente de desenvolvimento e dar o acesso desejado aos outros envolvidos.

Com o acima em mente, tenho várias consultas:

1. É uma boa ideia em primeiro lugar? É melhor ter VMs criadas e distribuídas (fisicamente) para os membros da equipe? Claro que perco o controle neste caso e os dados são vulneráveis.
2. Devo comprar uma Instância grande, instalar todas as ferramentas desejadas, criar usuários e fornecer acesso de acordo com a função?
3. Devo comprar uma instância Large / Extra Large, criar VMs dentro da instância, uma para cada função e instanciar instâncias por usuário? Não tenho certeza agora como o acesso funcionaria. Como alguém poderia acessar diretamente uma instância de VM em execução dentro da instância do EC2.
4. Existem ferramentas que ajudam no gerenciamento das instâncias do EC2 w.r.t. as APIs do EC2. No entanto, o que eu expliquei acima (especialmente o ponto # 3), existem ferramentas que podem ajudar no gerenciamento / monitoramento de instâncias e VMs dentro?

Pode haver muitas outras complexidades que não consigo pensar neste momento. Apreciará entradas / direções no caso de alguém já ter passado por isso.

    

Answer 1

A opção 2 exige ter uma instância funcionando 24 horas por dia (7 dias por semana) (ou pelo menos durante a união do horário de trabalho de todos). Isso pode não importar para você.

Não tenho certeza se a opção 3 é possível. Você está perguntando sobre a instalação do Xen (ou algo assim) dentro da sua instância do EC2 e, em seguida, criando suas próprias máquinas "sub-virtuais"?

Outra opção é criar uma imagem do EC2 (AMI) com o ambiente de desenvolvimento configurado e permitir que cada desenvolvedor ative uma instância dessa AMI sempre que quiser trabalhar.

Benefícios:

• Os desenvolvedores não competem por recursos de computação (por exemplo, CPU) em uma máquina compartilhada. Isso pode não importar para você.
• Você pode modificar a imagem (por exemplo, uma atualização do sistema operacional) e liberar uma nova "versão" sem exigir tempo de inatividade para todos os desenvolvedores.
• Economia potencial, pois você não precisa de uma instância 24 horas por dia.

Desvantagens:

• Custo potencial aumentado , pois você pode ter 5 instâncias em execução (isto é, 5 desenvolvedores trabalhando ao mesmo tempo) em vez de 1.
• Requer que cada desenvolvedor tenha acesso a uma conta da AWS.

Se você acha que isso é certo para você, o problema da conta da AWS pode ser abordado de várias maneiras:

• Cada desenvolvedor usa sua conta da AWS. Essa é a opção mais fácil, mas exige que você confie neles.
• Cada desenvolvedor cria sua própria conta e encaminha a fatura para você. Isso faz com que mais "papelada", mas permite rejeitar as contas, se você acha que o desenvolvedor não está sendo legítimo.
• Cada desenvolvedor cria sua própria conta e você usa Faturamento consolidado da AWS para pagar todos usando o mesmo cartão de crédito.

Eu acredito que você pode conceder acesso de lançamento a uma AMI sem necessariamente dar à pessoa root acesso quando a instância estiver em funcionamento. Mas você gostaria de verificar isso, pois parece que você está preocupado com a segurança.

Por fim, isso obviamente exigiria algum repositório central de código-fonte em execução 24 horas por dia, 7 dias por semana. Mais uma razão pela qual isso pode não ser a solução certa para você.