Implantar aplicativos na nuvem

Concluído

Após ser projetado e desenvolvido, o aplicativo de nuvem pode ser movido para a fase de implantação para liberação para os clientes. A implantação pode ser um processo de várias fases, com cada um deles envolvendo uma série de verificações para garantir que as metas do aplicativo sejam cumpridas.

Antes de implantar um aplicativo de nuvem para produção, é útil ter uma lista de verificação para ajudar você a avaliá-lo quanto a melhores práticas essenciais e recomendadas. São exemplos a lista de verificação de implantação da AWS e do Azure. Muitos provedores de nuvem fornecem uma lista abrangente de ferramentas e serviços que auxiliam na implantação, como este documento do Azure.

Processo de implantação

A implantação de um aplicativo de nuvem é um processo iterativo que começa do fim do desenvolvimento e continua até o lançamento do aplicativo nos recursos de produção:

Code deployment process.

Figura 1: Processo de implantação de código

É comum que os desenvolvedores de nuvem mantenham várias versões de seus aplicativos em execução simultânea para que haja um pipeline de implantação desses aplicativos em vários estágios:

  1. Teste
  2. Preparo
  3. Produção

Idealmente, cada um dos três estágios deve ter configurações e recursos idênticos, permitindo que os desenvolvedores testem e implantem o aplicativo e minimizem as chances de alterações no ambiente e na configuração gerarem inconsistências.

Pipeline de alterações do aplicativo

Em um cenário típico de desenvolvimento de aplicativos ágil (como mostrado na figura anterior), os aplicativos são mantidos por um grupo de engenheiros e desenvolvedores que trabalham nos problemas e bugs usando algum tipo de mecanismo de acompanhamento de problemas. As alterações no código são mantidas por meio de um sistema de repositório de código (digamos, svn, mercurial ou git), em que branches separados são mantidos para liberação do código. Depois de passar por alterações, revisões e aprovações, o código pode ser encaminhado para as fases de teste, preparo e produção. Isso pode ser feito de várias maneiras:

Scripts personalizados: os desenvolvedores podem usar scripts personalizados para efetuar pull da última versão do código e executar comandos específicos para compilar o aplicativo e colocá-lo em um estado de produção.

Imagens de máquina virtual pré-capturadas: os desenvolvedores também podem provisionar e configurar uma máquina virtual com todo o ambiente e o software necessários para implantar o aplicativo. Após configurá-la, é possível fazer um instantâneo da máquina virtual e exportá-lo como uma imagem da máquina virtual. Essa imagem pode ser fornecida a vários sistemas de orquestração da nuvem para ser implantada e configurada automaticamente para uma implantação de produção.

Sistemas de integração contínua: a fim de simplificar as várias tarefas envolvidas na implantação, ferramentas de CI (integração contínua) podem ser usadas para automatizar tarefas (como a recuperação da última versão de um repositório, a criação de binários do aplicativo e a execução de casos de teste) que precisam ser concluídas nos vários computadores que compõem a infraestrutura de produção. O Jenkins, o Bamboo e o Travis são exemplos de ferramentas de CI populares. O Azure Pipelines é uma ferramenta de CI específica do Azure projetada para funcionar com implantações do Azure.

Gerenciar o tempo de inatividade

Determinadas alterações no aplicativo podem exigir o encerramento parcial ou completo de seus serviços para incorporar a alteração no back-end do aplicativo. Normalmente, os desenvolvedores precisam agendar uma hora específica do dia para minimizar as interrupções para os clientes do aplicativo. Aplicativos projetados para integração contínua têm a capacidade de executar essas alterações em sistemas de produção com pouca ou nenhuma interrupção para os clientes do aplicativo.

Redundância e tolerância a falhas

Normalmente, as melhores práticas de implantação de aplicativos pressupõem que a infraestrutura de nuvem é efêmera e pode ficar não disponível ou ser alterada a qualquer momento. Por exemplo, máquinas virtuais implantadas em um serviço de IaaS podem ser agendadas para encerramento a critério do provedor de nuvem, dependendo do tipo de SLA.

Os aplicativos devem evitar efetuar hard-coding ou pressupor que os pontos de extremidade são estáticos para vários componentes, como bancos de dados e pontos de extremidade de armazenamento. Idealmente, aplicativos bem projetados devem usar APIs de serviço para consultar e descobrir recursos e conectá-los de maneira dinâmica.

Falhas catastróficas em recursos ou na conectividade podem ocorrer a qualquer momento. Aplicativos críticos devem ser projetados tendo essas falhas em vista e tendo redundância de failover.

Muitos provedores de nuvem distribuem seus datacenters em regiões e zonas. Uma região é um local geográfico específico que abriga um datacenter completo, enquanto as zonas são seções individuais do datacenter que são isoladas para fins de tolerância a falhas. Por exemplo, duas ou mais zonas dentro de um datacenter podem ter infraestruturas separadas de energia, resfriamento e conectividade para que uma falha em uma zona não afete a infraestrutura em outra. Normalmente, as informações sobre as regiões e zonas são disponibilizadas pelos provedores de serviço de nuvem para os clientes e desenvolvedores para que eles projetem e desenvolvam aplicativos capazes de utilizar essa propriedade de isolamento.

Assim, os desenvolvedores podem configurar o aplicativo para usar recursos em várias regiões ou zonas, a fim de aprimorar a disponibilidade do aplicativo e tolerar falhas que podem ocorrer em uma zona ou região. Eles precisarão configurar sistemas capazes de rotear e balancear o tráfego entre regiões e zonas. Servidores DNS também podem ser configurados para responder a solicitações de pesquisa de domínio para endereços IP específicos em cada zona, dependendo do local de origem da solicitação. Isso fornece um método de balanceamento de carga baseado na proximidade geográfica dos clientes.

Segurança e proteção em produção

A execução de aplicativos de Internet em uma nuvem pública deve ser feita com cuidado. Como os intervalos de IP de nuvem são locais bem conhecidos para alvos de alto valor, é importante garantir que todos os aplicativos implantados na nuvem sigam as melhores práticas quando se trata de proteger e preservar os pontos de extremidade e as interfaces. Alguns princípios bastante básicos que devem ser seguidos incluem:

  • Todo o software deve ser alterado para o modo de produção. A maioria dos programas de software tem suporte para o "modo de depuração" para testes locais e para o "modo de produção" para implantações reais. Geralmente, aplicativos em modo de depuração vazam uma grande quantidade de informações para invasores que enviam entradas malformadas e, portanto, são uma fonte fácil de reconhecimento para hackers. Quer você esteja usando uma estrutura da Web como o Django e o Rails ou um banco de dados como o Oracle, é importante seguir as diretrizes relevantes para a implantação de aplicativos de produção.
  • O acesso a serviços não públicos deve permanecer restrito a determinados endereços IP internos para acesso de administrador. Certifique-se de que os administradores não possam fazer logon em um recurso crítico diretamente da Internet sem visitar um launchpad interno. Configure firewalls com regras baseadas na porta e no endereço IP para permitir o mínimo de acessos necessários definido, especialmente por SSH e outras ferramentas de conectividade remota.
  • Siga o princípio dos privilégios mínimos. Execute todos os serviços como o usuário com menos privilégios que pode desempenhar a função necessária. Restrinja o uso de credenciais raiz a logons manuais específicos por administradores do sistema que precisam depurar ou configurar alguns problemas críticos no sistema. Isso também se aplica ao acesso a bancos de dados e painéis administrativos. De modo geral, os acessos devem ser protegidos usando um par de chaves pública-privada longo e aleatório. Esse par de chaves deve ser armazenado com segurança em uma localização restrita e criptografada. Todas as senhas devem ter requisitos rígidos de força.
  • Use técnicas e ferramentas de defesa conhecidas para sistemas de IDS/IPS (detecção e prevenção de intrusões), SIEM (gerenciamento de eventos e informações de segurança), firewalls de camada de aplicativo e sistemas antimalware.
  • Defina uma agenda de aplicação de patches que coincida com os lançamentos de patches do fornecedor dos sistemas que você usa. Muitas vezes, fornecedores como a Microsoft têm um ciclo de lançamento fixo para patches.