Aplicativos "nativos da nuvem" ou simplesmente "em nuvem" são criados especificamente para operar em infraestruturas de nuvem. Geralmente, são construídos como um conjunto de microserviços fracamente acoplados, empacotados em contêineres, que, por sua vez, são gerenciados por uma plataforma de nuvem. Esses aplicativos estão prontos para falhas por padrão, o que significa que funcionam de forma confiável e escalável, mesmo diante de falhas graves na infraestrutura. A contrapartida são os conjuntos de restrições (contratos) que a plataforma de nuvem impõe aos aplicativos em contêiner para poder gerenciá-los de forma automatizada.
Reconhecendo plenamente a necessidade e a importância da transição para aplicativos em nuvem, muitas organizações ainda não sabem por onde começar. Neste post, vamos explorar uma série de princípios, cuja observância na criação de aplicativos em contêiner permitirá aproveitar o potencial das plataformas de nuvem e garantir o funcionamento e a escalabilidade confiáveis dos aplicativos, mesmo em caso de falhas graves na infraestrutura de TI. O objetivo final desses princípios é aprender a criar aplicativos que possam ser gerenciados automaticamente por plataformas de nuvem, como o Kubernetes.
Princípios de design de software
No mundo da programação, princípios referem-se a regras bastante gerais que devem ser seguidas no desenvolvimento de software. Eles podem ser aplicados ao trabalho com qualquer linguagem de programação. Cada princípio possui seus objetivos, cujos instrumentos de alcance geralmente são padrões e práticas. Além disso, existe uma série de princípios fundamentais para a criação de software de qualidade, dos quais decorrem todos os outros. Vamos citar alguns exemplos de princípios fundamentais:
- (Keep it simple, stupid) – não complicar;
- (Don’t repeat yourself) – não se repetir;
- (You aren’t gonna need it) – não criar o que não é imediatamente necessário;
- (Separation of concerns) – separar responsabilidades.
Como se pode ver, esses princípios não impõem regras específicas, mas pertencem à categoria de considerações de bom senso baseadas na experiência prática, que muitos desenvolvedores compartilham e frequentemente referenciam.
Além disso, existe – um conjunto dos primeiros cinco princípios de programação e design orientados a objetos formulados por Robert Martin. O SOLID abrange princípios complementares que são generalizados e abertos à interpretação, os quais, quando aplicados em conjunto, ajudam a criar sistemas de software de maior qualidade e a mantê-los de forma mais eficiente a longo prazo.
Os princípios SOLID pertencem à esfera da programação orientada a objetos e são formulados na linguagem de conceitos e terminologias como classes, interfaces e herança. Analogamente, para aplicações em nuvem, também é possível formular princípios de desenvolvimento, sendo que o elemento básico aqui não é uma classe, mas um contêiner. Seguindo esses princípios, é possível criar aplicações em contêiner que atendem melhor aos objetivos e metas de plataformas em nuvem como o Kubernetes.
Contêineres orientados a nuvem: abordagem da Red Hat
Hoje em dia, é relativamente fácil empacotar praticamente qualquer aplicação em contêineres. No entanto, para que as aplicações sejam efetivamente automatizadas e orquestradas em uma plataforma em nuvem como o Kubernetes, são necessárias esforços adicionais.
A base das ideias apresentadas a seguir é a metodologia e muitos outros trabalhos sobre diversos aspectos da criação de aplicações web, desde o gerenciamento de código fonte até modelos de escalabilidade. Os princípios descritos referem-se exclusivamente ao desenvolvimento de aplicações em contêiner que são construídas com base em microserviços e destinadas a plataformas em nuvem, como o Kubernetes. O elemento básico em nossas discussões é a imagem do contêiner, e por ambiente de execução dos contêineres entendemos a plataforma de orquestração de contêineres. O objetivo dos princípios propostos é criar contêineres para os quais, na maioria das plataformas de orquestração, seja possível automatizar tarefas de agendamento (scheduling – escolha do host para executar uma instância do contêiner), escalonamento e monitoramento. Os princípios são apresentados em ordem arbitrária.
Princípio da única responsabilidade (Single Concern Principle, SCP)
Esse princípio é em muitos aspectos semelhante ao princípio da única responsabilidade (Single Responsibility Principle, ), que faz parte do conjunto SOLID e afirma que cada objeto deve ter uma única responsabilidade, e essa responsabilidade deve estar completamente encapsulada na classe. A essência do SRP é que cada responsabilidade é uma razão para mudanças, e a classe deve ter uma e somente uma razão para ser alterada.
No SCP, em vez da palavra “responsabilidade” (responsibility), usamos a palavra “tarefa” (concern) para indicar um nível mais alto de abstração e um propósito mais amplo do contêiner em comparação com uma classe OOP. E se o objetivo do SRP é ter apenas uma razão para mudanças, o SCP tem como objetivo expandir as possibilidades de reutilização e substituição de contêineres. Ao seguir o SRP e criar um contêiner que resolve uma única tarefa e faz isso de maneira funcional e completa, você aumenta as chances de reutilizar a imagem desse contêiner em diferentes contextos de aplicação.
O princípio SCP afirma que cada contêiner deve resolver uma única tarefa e fazê-lo bem. Além disso, o SCP no mundo dos contêineres é alcançado mais facilmente do que o SRP no mundo OOP, já que os contêineres geralmente executam um único processo, e na maior parte do tempo esse processo resolve uma única tarefa.
Se algum microsserviço contêiner deve resolver várias tarefas, ele pode ser dividido em contêineres de uma única tarefa e agrupados dentro de um único pod (unidade de implantação da plataforma de contêiner) usando padrões sidecar e init-containers. Além disso, o SCP facilita a substituição de um contêiner antigo (como um servidor web ou um broker de mensagens) por um novo que resolve a mesma tarefa, mas possui funcionalidades ampliadas ou melhor escalabilidade.
O princípio de alta observabilidade (High Observability Principle, HOP)
Ao usar contêineres como uma maneira unificada de empacotar e executar aplicativos, os próprios aplicativos são vistos como uma "caixa preta". No entanto, se forem contêineres em nuvem, eles devem fornecer interfaces de API especiais para o ambiente de execução, a fim de controlar a integridade dos contêineres e tomar as medidas adequadas, se necessário. Sem isso, não será possível unificar a automação da atualização dos contêineres e a gestão de seu ciclo de vida, o que, por sua vez, prejudicará a resiliência e a usabilidade do sistema de software.
Na prática, um aplicativo em contêiner deve, no mínimo, ter uma API para diferentes tipos de verificações de integridade: testes de atividade (liveness) e testes de prontidão (readiness). Se o aplicativo reivindica mais, então deve fornecer outros meios de controle de seu estado. Por exemplo, registrar eventos importantes através do STDERR e STDOUT para agregar logs usando Fluentd, Logstash e outras ferramentas semelhantes. Além disso, deve haver integração com bibliotecas de rastreamento e coleta de métricas, como OpenTracing, Prometheus e afins.
Em geral, o aplicativo ainda pode ser visto como uma "caixa preta", mas deve ser equipado com todas as APIs necessárias para que a plataforma possa monitorá-lo e gerenciá-lo da melhor maneira possível.
Princípio de Conformidade ao Ciclo de Vida (Life-cycle Conformance Principle, LCP)
O LCP é uma antítese do HOP. Enquanto o HOP afirma que o contêiner deve fornecer interfaces de API para leitura para a plataforma, o LCP exige que o aplicativo possua a capacidade de receber informações da plataforma. Além disso, o contêiner não deve apenas receber eventos, mas também se adaptar, ou seja, reagir a eles. Daí o nome do princípio, que pode ser visto como uma exigência de fornecer interfaces de API para gravação à plataforma.
As plataformas têm diferentes tipos de eventos que ajudam a gerenciar o ciclo de vida do contêiner. No entanto, cabe ao próprio aplicativo decidir quais deles perceber e como reagir.
É claro que alguns eventos são mais importantes que outros. Por exemplo, se um aplicativo lida mal com uma falha inesperada, ele deve aceitar mensagens signal: terminate (SIGTERM) e iniciar seu processo de encerramento o mais rápido possível, a fim de concluir antes de receber o signal: kill (SIGKILL), que ocorre após o SIGTERM.
Além disso, eventos como PostStart e PreStop podem ser importantes para o ciclo de vida do aplicativo. Por exemplo, após a inicialização, pode ser necessário um certo tempo de "aquecimento" antes que ele possa responder a requisições. Ou o aplicativo pode ter que liberar recursos de uma forma específica ao ser encerrado.
Princípio da Imutabilidade da Imagem do Contêiner (Image Immutability Principle, IIP)
É comum que aplicações em contêineres permaneçam imutáveis após a construção, mesmo quando executadas em diferentes ambientes. Daí surge a necessidade de externar o armazenamento de dados durante a execução (ou seja, usar ferramentas externas para isso), assim como confiar em configurações externas adaptadas para o ambiente de execução específico, em vez de modificar ou criar contêineres únicos para cada ambiente. Após qualquer alteração no aplicativo, a imagem do contêiner deve ser reconstruída e implantada em todos os ambientes utilizados. A propósito, um princípio semelhante é utilizado na gestão de sistemas de TI, conhecido como o princípio de imutabilidade de servidores e infraestrutura.
O objetivo do IIP é evitar a criação de imagens de contêiner separadas para diferentes ambientes de execução e usar a mesma imagem com a configuração correspondente para o ambiente específico. Seguir este princípio permite implementar práticas importantes do ponto de vista da automação de sistemas em nuvem, como rollback e rollout de atualizações do aplicativo.
Princípio da Descartabilidade de Processos (Process Disposability Principle, PDP)
Uma das características mais importantes de um contêiner é sua efemeridade: uma instância de contêiner pode ser facilmente criada e facilmente destruída, portanto, pode ser rapidamente substituída por outra instância a qualquer momento. Há várias razões para essa substituição: falha no teste de prontidão, escalonamento do aplicativo, migração para outro host, esgotamento de recursos da plataforma ou outras situações.
Como resultado, as aplicações em contêiner devem armazenar seu estado por meio de algum recurso externo, ou utilizar esquemas internos distribuídos com redundância. Além disso, a aplicação deve iniciar rapidamente e encerrar suas atividades de forma ágil, assim como estar preparada para uma falha de hardware súbita e fatal.
Uma das práticas que ajudam a implementar esse princípio é criar contêineres de tamanho pequeno. Ambientes em nuvem podem escolher automaticamente um host para executar uma instância do contêiner, portanto, quanto menor for o tamanho do contêiner, mais rápido ele será iniciado – ele simplesmente será copiado mais rápido para o host de destino pela rede.
Princípio da autossuficiência (Self-containment Principle, S-CP)
De acordo com esse princípio, na fase de construção, todos os componentes necessários são incluídos no contêiner. O contêiner deve ser projetado considerando que a única coisa na sistema é um núcleo Linux puro, portanto, todas as bibliotecas adicionais necessárias devem ser colocadas dentro do próprio contêiner. Também devem estar presentes coisas como o ambiente de execução para a linguagem de programação correspondente, plataforma de aplicativos (se necessário) e outras dependências que serão necessárias durante a execução da aplicação em contêiner.
Exceções são feitas apenas para configurações que variam de ambiente para ambiente e devem ser fornecidas em tempo de execução, por exemplo, através do Kubernetes ConfigMap.
A aplicação pode incluir vários componentes em contêineres, como um contêiner de SGBD dentro de uma aplicação web em contêiner. De acordo com o princípio S-CP, esses contêineres não devem ser combinados em um só, mas devem ser configurados de forma que o contêiner de SGBD contenha tudo o que é necessário para o funcionamento do banco de dados, enquanto o contêiner da aplicação web contém tudo o que é necessário para o funcionamento da aplicação web, incluindo o servidor web. Como resultado, durante a execução, o contêiner da aplicação web dependerá do contêiner de SGBD e o consultará conforme necessário.
Princípio da contenção em tempo de execução (Runtime Confinement Principle, RCP)
O princípio S-CP define como o contêiner deve ser montado e o que deve conter o arquivo binário da imagem. Contudo, o contêiner não é apenas uma "caixa preta", cuja única característica é o tamanho do arquivo. Durante a execução, o contêiner adquire outras dimensões: a quantidade de memória usada, o tempo de CPU e outros recursos do sistema.
É aqui que o princípio RCP se torna útil, segundo o qual o contêiner deve desacoplar suas exigências de recursos do sistema e transmiti-las à plataforma. Com os perfis de recursos de cada contêiner (quanta CPU, memória, rede e sistema de disco ele precisa), a plataforma pode realizar o gerenciamento e a dimensionamento automático de forma mais eficaz, gerenciando a capacidade de TI e mantendo os níveis de SLA para os contêineres.
Além de atender às exigências de recursos do contêiner, é também importante que o aplicativo não exceda os limites definidos por ele mesmo. Caso contrário, em situações de escassez de recursos, a plataforma é mais propensa a incluí-lo na lista de aplicativos a serem interrompidos ou migrados.
Ao falar sobre a orientação para nuvem, estamos nos referindo principalmente à forma de operação.
Acima, formulamos uma série de princípios gerais que estabelecem a base metodológica para a construção de aplicativos de contêiner de qualidade para ambientes de nuvem.
Vale ressaltar que além desses princípios gerais, você também precisará de métodos e técnicas avançadas adicionais para trabalhar com contêineres. Além disso, temos algumas recomendações curtas que têm um caráter mais específico e devem ser aplicadas (ou não) dependendo da situação:
- Tente reduzir o tamanho das imagens: remova arquivos temporários e não instale pacotes desnecessários – quanto menor for o tamanho do contêiner, mais rápido ele será montado e copiado para o host de destino pela rede.
- Baseie-se em User-IDs arbitrários: não use o comando sudo ou IDs de usuário especiais para iniciar seus contêineres.
- Marque portas importantes: os números das portas podem ser definidos durante a execução, mas é melhor especificá-los usando o comando EXPOSE – será mais fácil para outras pessoas e programas utilizarem suas imagens.
- Armazene dados persistentes em volumes: informações que devem permanecer após a destruição do contêiner devem ser gravadas em volumes.
- Escreva os metadados da imagem: tags, rótulos e anotações facilitam o uso das imagens - outros desenvolvedores ficarão agradecidos.
- Sincronize o host e as imagens: alguns aplicativos em contêiner exigem que o contêiner seja sincronizado com o host em certos atributos, como tempo ou identificação da máquina.
- Por fim, compartilhamos modelos e melhores práticas que ajudarão a implementar de forma mais eficaz os princípios mencionados acima:
11 de junho às 11h00
O que você irá aprender:
- Red Hat Enterprise Linux CoreOS Imutável
- Malha de serviços do OpenShift
- Framework Operator
- Framework Knative
Fonte: habr.com
