Melhores Práticas: Gerenciamento e implementação de aplicativos e guias de procedimentos

Importante

O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no AWS re:POST ou por meio do Premium AWS Support.

AWS OpsWorks O Stacks implanta aplicativos e livros de receitas em cada nova instância a partir de um repositório remoto. Durante o ciclo de vida de uma instância, você deve atualizar frequentemente os aplicativos ou guias de procedimentos nas instâncias online das pilhas para adicionar recursos, corrigir erros e assim por diante. Existe uma série de maneiras para gerenciar os aplicativos e guias de procedimentos de uma pilha, mas a abordagem usada deve cumprir os seguintes requisitos gerais:

• Todas as instâncias da pilha de produção devem ter o mesmo aplicativo e código do guia de procedimentos personalizado, com exceções limitadas para algumas finalidades, como o teste A/B.

• A implementação de uma atualização não deve interromper a operação do site, mesmo se algo der errado.

Esta seção descreve as práticas recomendadas para o gerenciamento e a implementação de aplicativos e guias de procedimentos personalizados.

Manutenção da consistência

Em geral, você precisa manter total controle sobre o aplicativo ou código do guia de procedimentos que é executado em sua pilha de produção. Normalmente, todas as instâncias devem executar a versão atualmente aprovada do código. As exceções ocorrem ao atualizar seus aplicativos ou guias de procedimentos, conforme descrito posteriormente, e ao acomodar casos especiais, como a execução do teste A/B.

O código do aplicativo e guia de procedimentos é implementado a partir de um repositório de origem especificado para suas instâncias da pilha de duas formas:

• Quando você inicia uma instância, o AWS OpsWorks Stacks implanta automaticamente o código atual do aplicativo e do livro de receitas na instância.

• Para instâncias online, você deve implementar manualmente o código do aplicativo ou guia de procedimentos atual, executando um Comando de implementação (para aplicativos) ou um Comando de atualização de guias de procedimentos personalizados (para guias de procedimentos).

Como existem dois mecanismos de implementação, é essencial que você gerencie seu código-fonte cuidadosamente para evitar a execução involuntária de um código diferente em instâncias diferentes. Por exemplo, se você implanta aplicativos ou livros de receitas de uma ramificação mestre do Git AWS OpsWorks , o Stacks implanta o que está nessa ramificação no momento. Se você atualizar o código no branch mestre e, em seguida, iniciar uma nova instância, essa instância terá uma versão mais recente do código em relação às instâncias mais antigas. A versão mais recente pode nem estar aprovada para produção.

Recomendação: arquivos Amazon S3

Para garantir que todas as suas instâncias tenham a versão de código aprovada, recomendamos a implantação dos seus aplicativos e livros de receitas a partir de um arquivo do Amazon Simple Storage Service (Amazon S3). Isso garante que o código é um artefato estático, um .zip ou outro ficheiro de arquivo, que deve ser atualizado de forma explícita. Além disso, o Amazon S3 é altamente confiável, para que você raramente, se nunca, encontre dificuldades para acessar o arquivo. Para garantir ainda mais a consistência, atribua versões explicitamente a cada arquivo usando uma convenção de nomenclatura ou através do Versionamento do Amazon S3, que fornece uma trilha de auditoria e uma maneira fácil de reverter para uma versão anterior.

Por exemplo, você pode criar uma estrutura de implementação utilizando a ferramenta Jenkins. Assim que o código que você deseja implementar for comprometido e testado, crie um ficheiro de arquivos e faça o upload para o Amazon S3. Todas as implantações de aplicativos ou atualizações de livros de receita instalarão o código nesse arquivo compactado, e cada instância terá o mesmo código.

Recomendação: Repositórios Git ou Subversão

Se você preferir usar um repositório Git ou Subversão, não implemente a partir do branch mestre. Em vez disso, marque a versão aprovada e especifique essa versão como a fonte do aplicativo ou guia de procedimentos.

Implementação do código em instâncias online

AWS OpsWorks O Stacks não implanta automaticamente o código atualizado em instâncias on-line. Você deve executar essa operação manualmente, o que implica nos seguintes desafios:

• A implementação eficiente da atualização, sem comprometer a habilidade do site de lidar com solicitações de clientes durante o processo de implementação.

• O tratamento de uma implementação malsucedida, seja devido a problemas com o aplicativo ou guia de procedimentos implementado, ou devido a problemas com o processo de implementação em si.

A abordagem mais simples é executar um Comando de implementação (para aplicativos) ou Comando de atualização de guias de procedimentos personalizados (para guias de procedimentos) padrão, que implementa a atualização simultaneamente em todas as instâncias. Essa abordagem é simples e rápida, mas não há margem para erro. Se a implementação falhar ou o código atualizado possuir qualquer problema, cada instância da sua pilha de produção pode ser afetada, o que pode interromper ou desativar seu site até que o problema seja corrigido ou aconteça a reversão para a versão anterior.

Recomendação: Use uma estratégia de implementação robusta, o que permite que as instâncias que executam a versão antiga do código possam continuar lidando com as solicitações até que ocorra a verificação de que a implementação foi bem-sucedida e todo o tráfego de entrada pode ser transferido com confiança para a nova versão.

As seções a seguir oferecem dois exemplos de estratégias de implementação robustas, seguidos por uma discussão sobre como gerenciar um banco de dados de backend durante a implementação. Em resumo, eles descrevem as atualizações do aplicativo, mas você pode usar estratégias semelhantes para os livros de receitas.

Tópicos

• Utilização de uma implementação rolling
• Uso de pilhas separadas
• Gerenciamento de um banco de dados backend

Utilização de uma implementação rolling

Uma implementação rolling atualiza um aplicativo nas instâncias do servidor de aplicativos online da pilha em várias fases. Com cada fase, você atualiza um subconjunto de instâncias online e verifica se a atualização foi bem-sucedida antes de iniciar a próxima fase. Se encontrar problemas, as instâncias que ainda estão executando a versão antiga do aplicativo podem continuar lidando com o tráfego de entrada até que você resolva os problemas.

O exemplo a seguir considera que você está usando a prática recomendada de distribuir as instâncias do servidor de aplicativos da pilha em várias Zonas de Disponibilidade.

Para executar uma implementação rolling

1. Na página Deploy App, selecione Advanced, escolha uma única instância do servidor de aplicativos e implemente o aplicativo para essa instância.

   Se você quiser ser cauteloso, você pode remover a instância do load balancer antes de implementar o aplicativo. Isso garante que os usuários não irão encontrar o aplicativo atualizado até que seja verificado o seu funcionamento correto. Se você usar o Elastic Load Balancing, remova a instância do balanceador de carga usando o console, a CLI ou um SDK do Elastic Load Balancing.

2. Verifique se o aplicativo atualizado está funcionamento corretamente e se a instância possui índices de desempenho aceitáveis.

   Se você removeu a instância de um balanceador de carga do Elastic Load Balancing, use o console, CLI ou um SDK do Elastic Load Balancing para restaurar. A versão atualizada do aplicativo está, agora, lidando com as solicitações de usuários.

3. Implemente a atualização para o restante das instâncias na Zona de Disponibilidade e verifique se elas estão funcionando corretamente e se possuem os índices aceitáveis.

4. Repita a etapa 3 para as outras Zonas de Disponibilidade da pilha, uma zona por vez. Se você quiser ser especialmente cauteloso, repita as etapas 1 a 3.

nota

Caso use um balanceador de carga do Elastic Load Balancing, você pode usar sua verificação de integridade para verificar se a implantação foi bem-sucedida. No entanto, defina o caminho de ping para um aplicativo que confira as dependências e verifique se tudo está trabalhando corretamente, e não um arquivo estático que apenas confirma se o servidor do aplicativo está em execução.

Uso de pilhas separadas

Outra abordagem para o gerenciamento de aplicativos é usar uma pilha separada para cada fase do ciclo de vida do aplicativo. As diversas pilhas são, geralmente, chamadas de ambientes. Esse arranjo permite que você execute o desenvolvimento e os testes em pilhas que não estão acessíveis publicamente. Quando estiver pronto para implementar uma atualização, troque o tráfego de usuários da pilha que hospeda a versão atual do aplicativo, para a pilha que hospeda a versão atualizada.

Tópicos

• Uso de pilhas de desenvolvimento, preparação e produção
• Uso de uma estratégia de implementação azul-verde

Uso de pilhas de desenvolvimento, preparação e produção

A abordagem mais comum usa as seguintes pilhas.

Pilha de desenvolvimento

Use uma pilha de desenvolvimento para tarefas como a implementação de novos recursos ou correção de erros. Uma pilha de desenvolvimento é, essencialmente, um protótipo da pilha de produção, com as mesmas camadas, aplicativos, recursos, etc., inclusos na sua pilha de produção. Como a pilha de desenvolvimento normalmente não precisa lidar com a mesma carga da pilha de produção, você normalmente pode usar menos instâncias, ou instâncias menores.

As pilhas de desenvolvimento não são abertas ao público; você controla o acesso da seguinte forma:

• Restrinja o acesso à rede, configurando as regras de entrada do grupo de segurança do load balancer ou do servidor do aplicativo para aceitar apenas solicitações de endereços IP, ou intervalos de endereços, específicos.

  Por exemplo, limite o acesso HTTP, HTTPS e SSH para endereços dentro do seu intervalo de endereços corporativo.

• Controle o acesso à funcionalidade de gerenciamento de AWS OpsWorks pilhas usando a página de permissões da pilha.

  Por exemplo, conceder o nível de permissões Gerenciar para a equipe de desenvolvimento, e o nível Mostrar para todos os outros funcionários.

Pilha de preparação

Use uma pilha de preparação para testar e finalizar candidatos para uma pilha de produção atualizada. Ao concluir o desenvolvimento, crie uma pilha de preparação através da clonagem da pilha de desenvolvimento. Em seguida, execute o pacote de testes na pilha de preparação e implemente as atualizações nessa pilha para corrigir problemas que surgirem.

As pilhas de preparação também não são abertas ao público; você controla o acesso à pilha e à rede da mesma forma que faria para a pilha de desenvolvimento. Observe que, ao clonar uma pilha de desenvolvimento para criar uma pilha de teste, você pode clonar as permissões concedidas pelo gerenciamento de permissões de pilhas. AWS OpsWorks No entanto, a clonagem não afeta as permissões concedidas por políticas IAM dos usuários. Você deve usar o console, CLI ou um SDK do IAM para modificar essas permissões. Para ter mais informações, consulte Gerenciamento de permissões de usuário.

Pilha de produção

A pilha de produção é a pilha aberta ao público que oferece suporte ao seu aplicativo atual. Quando a pilha de preparação passar nos testes, você promove-a para produção e retira a pilha de produção antiga. Para obter um exemplo de como fazer isso, consulte Uso de uma estratégia de implementação azul-verde.

nota

Em vez de usar o console AWS OpsWorks Stacks para criar pilhas manualmente, crie um AWS CloudFormation modelo para cada pilha. Essa abordagem tem as seguintes vantagens:

• Velocidade e conveniência: ao iniciar o modelo, o AWS CloudFormation cria automaticamente a pilha, incluindo todas as instâncias necessárias.

• Consistência: armazene o modelo de cada pilha em seu repositório de origem para garantir que os desenvolvedores usem a mesma pilha para a mesma finalidade.

Uso de uma estratégia de implementação azul-verde

Uma estratégia de implementação azul-verde é uma maneira comum de usar pilhas separadas de modo eficiente, para implementar uma atualização do aplicativo na produção.

• O ambiente azul é a pilha de produção, que hospeda o aplicativo atual.

• O ambiente verde é a pilha de preparação, que hospeda o aplicativo atualizado.

Quando você estiver pronto para implementar o aplicativo atualizado para a produção, basta alternar o tráfego de usuários da pilha azul para a pilha verde, que se torna a nova pilha de produção. Você então retira a antiga pilha azul.

O exemplo a seguir descreve como executar uma implementação azul-verde com pilhas do AWS OpsWorks Stacks em conjunto com o Route 53 e um grupo de balanceadores de carga do Elastic Load Balancing. Antes de fazer a inversão, você deve garantir o seguinte:

• A atualização do aplicativo na pilha verde passou nos testes e está pronta para a produção.

• A pilha verde é idêntica à azul, exceto pelo fato de incluir a aplicativo atualizado e não ser aberta ao público.

  Ambas as pilhas têm as mesmas permissões, o mesmo número e tipo de instâncias em cada camada, a mesma configuração com base no tempo e carga, e assim por diante.

• Todas as instâncias 24/7 e as instâncias com base no tempo agendadas da pilha verde estão online.

• Você tem um grupo de balanceadores de carga do Elastic Load Balancing que podem ser conectados dinamicamente a uma camada em ambas as pilhas e pode ser pré-aquecido para processar o volume de tráfego esperado.

• Você usou o atributo de roteamento ponderado Route 53 para criar um conjunto de registros em uma zona hospedada que inclui seu grupo de balanceadores de carga.

• Você atribuiu um peso diferente de zero para o load balancer que está conectado à camada do servidor de aplicativo da sua pilha azul, e peso zero para os load balancers não utilizados. Isso garante que o load balancer da pilha azul lida com todo o tráfego de entrada.

Para transferir os usuários para a pilha verde

1. Anexe um dos load balancers não utilizados do grupo na camada do servidor de aplicativo da pilha verde. Em alguns casos, como quando você espera tráfego instantâneo, ou se não for possível configurar um teste de carga para aumentar o tráfego gradualmente, prepare o load balancer para lidar com o tráfego esperado.

2. Após todas as instâncias da pilha verde terem passado pela verificação de integridade do Elastic Load Balancing, altere os pesos no conjunto de registros do Route 53, de modo que o balanceador de carga da pilha verde tenha peso zero e o balanceador de carga da pilha azul tenha um peso reduzido correspondente. Recomendamos que você comece deixando a pilha verde cuidar de uma pequena porcentagem das solicitações, talvez 5%, com a pilha azul cuidando do resto. Agora você tem duas pilhas de produção, com a pilha verde cuidando de algumas solicitações e a pilha azul cuidando do restante.

3. Monitore os índices de desempenho da pilha verde. Se eles estão aceitáveis, aumente o peso da pilha verde para que ela cuide de, talvez, 10% do tráfego de entrada.

4. Repita a etapa 3 até que a pilha verde esteja cuidando de aproximadamente metade do tráfego de entrada. Quaisquer possíveis problemas devem ter emergido até esse momento, portanto, se a pilha verde está funcionando de forma aceitável, você pode concluir o processo, reduzindo o peso da pilha azul para zero. A pilha verde é agora a nova pilha azul, e está cuidando de todo o tráfego de entrada.

5. Separe o load balancer da camada do servidor de aplicativo da antiga pilha azul e devolva-o para o grupo.

6. Embora a antiga pilha azul não esteja mais cuidando das solicitações de usuários, recomendamos mantê-la por um tempo caso ocorram problemas com a nova pilha azul. Neste caso, você pode reverter a atualização, revertendo o procedimento para direcionar o tráfego de entrada de volta para a antiga pilha azul. Quando estiver certo de que a nova pilha azul está operando de forma aceitável, encerre a antiga pilha azul.

Gerenciamento de um banco de dados backend

Se seu aplicativo depender de um banco de dados de back-end, você precisará fazer a transição do aplicativo antigo para o novo. AWS OpsWorks O Stacks oferece suporte às seguintes opções de banco de dados.

Camada Amazon RDS

Com uma camada do Amazon Relational Database Service (Amazon RDS), você cria a instância de banco de dados RDS separadamente e, em seguida, registra em sua pilha. Você pode registrar uma instância de banco de dados RDS em apenas uma pilha por vez, mas você pode alterar uma instância de banco de dados RDS de uma pilha para outra.

AWS OpsWorks O Stacks instala um arquivo com os dados de conexão em seus servidores de aplicativos em um formato que pode ser facilmente usado pelo seu aplicativo. AWS OpsWorks O Stacks também adiciona as informações de conexão do banco de dados aos atributos de configuração e implantação da pilha, que podem ser acessados por receitas. Você também pode usar JSON para fornecer dados de conexão para aplicativos. Para ter mais informações, consulte Conectar-se a um banco de dados.

Atualizar um aplicativo que depende de um banco de dados apresenta dois desafios básicos:

• Garantir que toda transação é devidamente registrada durante a transição e, ao mesmo tempo, evitar condições de corrida entre as versões nova e antiga do aplicativo.

• Executar a transição de uma forma que limite o impacto sobre o desempenho do seu site e minimize ou elimine o tempo de inatividade.

Ao usar as estratégias de implementação descritas neste tópico, não é possível simplesmente desconectar o banco de dados do aplicativo antigo e reconectá-lo ao novo. Ambas as versões do aplicativo são executadas em paralelo durante a transição e devem ter acesso aos mesmos dados. O conteúdo a seguir descreve duas abordagens para gerenciar a transição, assim como suas vantagens e desafios.

Abordagem 1: Tenha ambos os aplicativos conectados ao mesmo banco de dados

Vantagens

• Não há tempo de inatividade durante a transição.

  Um aplicativo para gradualmente de acessar o banco de dados, enquanto o outro assume gradualmente.

• Não é necessário sincronizar os dados entre dois banco de dados.

Desafios

• Ambos os aplicativos acessam o mesmo banco de dados, portanto é necessário gerenciar o acesso para evitar perda ou corrupção de dados.

• Se precisar migrar para um novo esquema de banco de dados, a versão antiga do aplicativo deve ser capaz de usar o novo esquema.

Se você estiver usando pilhas separadas, essa abordagem é provavelmente mais adequada para o Amazon RDS, pois a instância não está permanentemente vinculada a uma determinada pilha e pode ser acessada por aplicativos em execução em pilhas diferentes. No entanto, não é possível registrar uma instância de banco de dados RDS com mais de uma pilha por vez, de modo que é necessário fornecer dados de conexão para ambos os aplicativos, por exemplo usando JSON. Para ter mais informações, consulte Usando uma receita predefinida.

Se você realiza atualização frequente, as versões antiga e nova do aplicativo são hospedadas na mesma pilha, para que você possa usar uma camada do Amazon RDS ou MySQL.

Abordagem 2: Fornecer um banco de dados para cada versão do aplicativo

Vantagens

• Cada versão tem seu próprio banco de dados, portanto os esquemas não precisam ser compatíveis.

Desafios

• Sincronizar os dados entre os dois bancos de dados durante a transição sem perder ou danificar os dados.

• Garantir que o procedimento de sincronização não cause tempo de inatividade significativo ou diminua significativamente o desempenho do site.

Se você estiver usando pilhas separadas, cada uma tem seu próprio banco de dados. Se você estiver usando implementação frequente, você pode anexar dois bancos de dados à pilha, um para cada aplicativo. Se os aplicativos antigo e atualizado não possuem esquemas de banco de dados compatíveis, essa abordagem é melhor.

Recomendação: em geral, recomendamos o uso de uma camada do Amazon RDS como banco de dados de back-end de um aplicativo, pois ela é mais flexível e pode ser usada para qualquer cenário de transição. Para obter mais informações sobre como lidar com transições, consulte o Guia do usuário Amazon RDS.