Implementar aplicações na cloud

Concluído

Após uma aplicação na cloud ter sido concebida e desenvolvida, pode ser movida para a fase de implementação para lançamento para os clientes. A implementação pode ser um processo de várias fases, cada uma envolvendo uma série de verificações para garantir que os objetivos da aplicação são cumpridos.

Antes de implementar uma aplicação na cloud para produção, é útil ter uma lista de verificação para ajudar na avaliação da sua aplicação relativamente a uma lista de boas práticas essenciais e recomendadas. Exemplos incluem a lista de verificação de implementação de AWS e Azure. Muitos fornecedores de serviços cloud fornecem uma lista abrangente de ferramentas e serviços que ajudam na implementação, tal como este documento do Azure.

Processo de implementação

A implementação de uma aplicação na cloud é um processo iterativo que começa desde o fim do desenvolvimento e continua até ao lançamento da aplicação nos recursos de produção:

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

É normal que os programadores de cloud mantenham múltiplas versões simultaneamente em execução das suas aplicações para a implementação do pipeline da sua aplicação em múltiplas fases:

1. Testar
2. Processo de teste
3. Produção

Cada uma das três fases deve ter, idealmente, recursos e configuração idênticos, o que permite aos programadores testar e implementar a aplicação e minimizar as hipóteses de inconsistências decorrentes de uma alteração no ambiente e configuração.

Alterações de aplicação de pipeline

Num cenário típico de desenvolvimento de aplicações ágeis (como ilustrado na figura anterior), a manutenção das aplicações é feita por um conjunto de engenheiros e programadores que trabalham em problemas e erros utilizando algum tipo de mecanismo de controlo de problemas. As alterações ao código são mantidas através de um sistema de repositório (por exemplo, svn, mercurial ou git), no qual são mantidos ramos separados para o lançamento do código. Após passar por alterações, revisões e aprovações do código, o mesmo pode ser colocado em pipeline nas fases de teste, transição e produção. Tal pode ser feito de múltiplas formas:

Scripts personalizados: os desenvolvedores podem usar scripts personalizados para extrair a versão mais recente do código e executar comandos específicos para criar o aplicativo e colocá-lo em um estado de produção.

Imagens de máquina virtual pré-preparadas: os desenvolvedores também podem provisionar e configurar uma máquina virtual com todo o ambiente e software necessários para implantar seu aplicativo. Uma vez configurada a máquina virtual, pode ser criado um instantâneo da mesma que é depois exportado para uma imagem de máquina virtual. Esta imagem pode ser fornecida a vários sistemas de orquestração na cloud para ser automaticamente implementada e configurada para uma implementação de produção.

Sistemas de integração contínua: Para simplificar as várias tarefas envolvidas na implantação, as ferramentas de integração contínua (CI) podem ser usadas para automatizar tarefas (como a recuperação da versão mais recente de um repositório, a criação de binários de aplicativos e a execução de casos de teste) que precisam ser concluídas nas várias máquinas que compõem a infraestrutura de produção. Exemplos de ferramentas populares de IC incluem o Jenkins, Bamboo e Travis. O Azure Pipelines é uma ferramenta de IC específica do Azure concebida para funcionar com as implementações do Azure.

Gerir o período de inatividade

Algumas alterações à aplicação podem exigir uma cessação parcial ou total dos serviços da aplicação para incorporar uma alteração no back-end da aplicação. Os programadores têm normalmente de agendar uma hora específica para minimizar as interrupções da aplicação para os clientes. As aplicações que foram concebidas para uma integração contínua podem conseguir fazer estas alterações em tempo real nos sistemas de produção com um mínimo ou nenhuma interrupção para os clientes da aplicação.

Redundância e tolerância a falhas

As melhores práticas na implementação de aplicações presumem normalmente que a infraestrutura de cloud é efémera e pode estar indisponível ou mudar a qualquer momento. Por exemplo, as máquinas virtuais implementadas num serviço IaaS podem ser agendadas para cessarem a critério do fornecedor de serviços cloud, consoante o tipo de SLA.

As aplicações têm de se abster de pré-programar ou assumir pontos finais estáticos para vários componentes, tais como bases de dados e pontos finais de armazenamento. As aplicações bem concebidas devem, idealmente, utilizar APIs de serviço para consultar e descobrir recursos e ligar-se aos mesmos de forma dinâmica.

As falhas catastróficas em recursos ou a conectividade podem acontecer a qualquer momento. As aplicações críticas têm de ser concebidas de forma a antecipar tais falhas e para a redundância da ativação pós-falha.

Muitos fornecedores de serviços cloud concebem os seus datacenters em regiões e zonas. Uma região é um local geográfico específico que aloja um datacenter completo, ao passo que as zonas são secções individuais dentro de um datacenter que estão isoladas para a tolerância a falhas. Por exemplo, duas ou mais zonas dentro de um datacenter podem ter infraestruturas separadas de potência, arrefecimento e conectividade, para que uma falha numa zona não afete a infraestrutura noutra. A informação da região e zona é normalmente disponibilizada por fornecedor de serviços cloud a clientes e programadores para conceberem e desenvolverem aplicações que possam utilizar esta propriedade de isolamento.

Como tal, os programadores podem configurar a sua aplicação para utilizar recursos em múltiplas regiões ou zonas de forma a melhorar a disponibilidade da sua aplicação e tolerar falhas que possam ocorrer numa zona ou região. Terão de configurar sistemas que possam encaminhar e equilibrar o tráfego entre regiões e zonas. Os servidores DNS também podem ser configurados para responder a pedidos de procura de domínio a endereços IP particulares em cada zona, dependendo do local onde o pedido teve origem. Tal fornece um método de balanceamento de carga com base na proximidade geográfica dos clientes.

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

A execução de aplicações na Internet numa cloud pública tem de ser efetuada com cuidado. Uma vez que os intervalos de IP são localizações bem conhecidas para alvos de alto valor, é importante garantir que todas as aplicações implementadas na cloud seguem as melhores práticas no que respeita à proteção e segurança de pontos finais e interfaces. Alguns princípios muito básicos que devem ser seguidos incluem:

• Todo o software deve ser alterado para o modo de produção. A maioria dos softwares suporta o "modo de depuração" para os testes locais e o "modo de produção" para implementações reais. As aplicações em modo de depuração divulgam normalmente uma grande quantidade de informação aos atacantes que enviam entradas com formato incorreto e, como tal, fornecem uma fonte fácil de reconhecimento para hackers. Independentemente de estar a utilizar uma arquitetura Web como Django e Rails ou uma base de dados como a Oracle, é importante seguir as diretrizes relevantes para a implementação de aplicações de produção.
• O acesso a serviços não públicos deve restringir-se a determinados endereços IP para acesso de administrador. Certifique-se de que os administradores não podem iniciar sessão diretamente num recurso crítico a partir da Internet sem visitar uma plataforma de lançamento interna. Configure firewalls com endereço IP e regras baseadas na porta para permitir o conjunto mínimo de acessos necessários, sobretudo em SSH e outras ferramentas de conectividade remota.
• Siga o princípio do menor privilégio. Execute todos os serviços como o utilizador menos privilegiado que possa desempenhar a função necessária. Restrinja a utilização de credenciais de raiz a inícios de sessão manuais específicos por parte de administradores de sistema que precisem de depurar ou configurar alguns problemas críticos no sistema. Tal também se aplica ao acesso a bases de dados e painéis administrativos. Os acessos devem ser geralmente protegidos através da utilização de um par de chaves públicas/privadas aleatório e longo, sendo que este par de chaves deve ser armazenado de forma segura num local restrito e encriptado. Todas as palavras-passe devem ter requisitos de segurança rigorosos.
• Utilize técnicas e ferramentas defensivas bem conhecidas para sistemas de deteção e prevenção de intrusões (IDS/IPS), gestão de informações e eventos de segurança (SIEM), firewalls de camada de aplicação e sistemas anti-malware.
• Estabeleça um calendário de correções que coincida com os lançamentos de correções do fornecedor dos sistemas que utiliza. Muitas vezes, fornecedores como a Microsoft têm um ciclo de lançamento fixo para correções.