Aplicativos "baseados em nuvem" (nativos da nuvem) ou apenas "nuvem" são criados especificamente para uso em infraestruturas em nuvem. Geralmente eles são criados como um conjunto de microsserviços fracamente acoplados, embalados em contêineres, que, por sua vez, são gerenciados por uma plataforma em nuvem. Esses aplicativos, por padrão, estão prontos para falhas, o que significa que eles funcionam de forma confiável e escalável, mesmo em caso de falhas graves no nível da infraestrutura. O outro lado da moeda é o conjunto de restrições (contratos) que a plataforma em nuvem impõe aos aplicativos de contêiner para poder gerenciá-los automaticamente.
Conscientes da necessidade e importância de mudar para aplicativos em nuvem, muitas organizações ainda não sabem por onde começar. Nesta publicação, consideraremos vários princípios, conformidade com os quais, durante o desenvolvimento de aplicativos de contêiner, perceberemos o potencial das plataformas em nuvem e obteremos operação e escalabilidade confiáveis de aplicativos, mesmo em caso de falhas graves no nível da infraestrutura de TI. O objetivo final dos princípios descritos aqui é aprender a criar aplicativos que podem ser gerenciados automaticamente por plataformas em nuvem como o Kubernetes.
Princípios de design de software
No mundo da programação, os princípios são entendidos como regras bastante gerais que devem ser observadas no desenvolvimento de software. Eles podem ser usados ao trabalhar com qualquer linguagem de programação. Cada princípio tem seus próprios objetivos, os modelos e práticas geralmente servem como um instrumento para sua conquista. Há também vários princípios fundamentais para a criação de software de alta qualidade, dos quais todos os outros seguem. Aqui estão alguns exemplos de princípios fundamentais:
- BEIJO (Seja simples, estúpido) - não complique;
- SECA (não se repita) - não repita;
- YAGNI (Você não vai precisar disso) - não crie algo em que não haja necessidade imediata;
- SoC (Separação de preocupações) - para compartilhar responsabilidades.
Como você pode ver, esses princípios não estabelecem regras específicas, mas pertencem à categoria das chamadas considerações de senso comum, com base na experiência prática compartilhada por muitos desenvolvedores e à qual eles se referem regularmente.
Além disso, há o
SOLID - um conjunto dos cinco primeiros princípios de programação e design orientado a objetos, formulado por Robert Martin. O SOLID inclui princípios mutuamente complementares, generalizados e abertos à interpretação, os quais - quando aplicados em conjunto - ajudam a criar melhores sistemas de software e a melhor suporte a longo prazo.
Os princípios do SOLID se aplicam ao POO e são formulados em termos de conceitos e conceitos como classes, interfaces e herança. Por analogia, para aplicativos em nuvem, você também pode formular os princípios de desenvolvimento, apenas o elemento básico aqui não será uma classe, mas um contêiner. Seguindo esses princípios, você pode criar aplicativos em contêiner que atendam melhor às metas e objetivos de plataformas em nuvem como o Kubernetes.
Contêineres baseados em nuvem: abordagem da Red Hat
Hoje, quase qualquer aplicativo é relativamente fácil de embalar em contêineres. Porém, para que os aplicativos sejam automatizados e orquestrados com eficiência em uma plataforma em nuvem como o Kubernetes, é necessário um esforço extra.
As idéias apresentadas abaixo foram baseadas na metodologia do
The Twelve-Factor App e em muitos outros trabalhos sobre vários aspectos da criação de aplicativos da Web, do controle de origem aos modelos em escala. Os princípios descritos se aplicam apenas ao desenvolvimento de aplicativos de contêiner criados com base em microsserviços e projetados para plataformas em nuvem como o Kubernetes. O elemento básico em nossa discussão é a imagem do contêiner, e o tempo de execução do contêiner de destino é a plataforma de orquestração do contêiner. O objetivo dos princípios propostos é criar contêineres para os quais, na maioria das plataformas de orquestração, é possível automatizar tarefas de agendamento (agendamento - escolha de um host para executar a instância do contêiner), dimensionamento e monitoramento. Os princípios são estabelecidos em ordem aleatória.
Princípio da preocupação única (SCP)
Esse princípio é, em muitos aspectos, semelhante ao Princípio de responsabilidade única (
SRP ), que faz parte do conjunto SOLID e afirma que cada objeto deve ter uma responsabilidade e que essa responsabilidade deve ser totalmente encapsulada na classe. A essência do SRP é que cada dever é um motivo de mudança, e uma classe deve ter um e apenas um motivo de mudança.
No SCP, em vez da palavra "responsabilidade", usamos a palavra "preocupação" para indicar um nível mais alto de abstração e um objetivo mais amplo do contêiner em comparação com a classe OOP. E se o objetivo do SRP é ter apenas um motivo para a mudança, o SCP deseja expandir as possibilidades de reutilizar e substituir contêineres. Ao seguir o SRP e criar um contêiner que resolve uma única tarefa e a conclui funcionalmente, você aumenta as chances de reutilizar a imagem desse contêiner em vários contextos de aplicativos.
O princípio do 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 da OOP, porque os contêineres geralmente executam um único processo e, na maioria das vezes, esse processo resolve uma única tarefa.
Se um microsserviço de contêiner precisar resolver vários problemas ao mesmo tempo, ele poderá ser dividido em contêineres de tarefa única e mesclados em um pod (unidades de implantação da plataforma de contêiner) usando modelos de side-car e contêineres init Além disso, o SCP facilita a substituição de um contêiner antigo (como um servidor da Web ou um intermediário de mensagens) por um novo que resolva o mesmo problema, mas possui funcionalidade aprimorada ou dimensiona melhor.
Princípio da conveniência do monitoramento (Princípio da Alta Observabilidade, HOP)
Ao usar contêineres como uma forma unificada de empacotar e iniciar aplicativos, os próprios aplicativos são considerados uma "caixa preta". No entanto, se esses são contêineres na nuvem, eles devem fornecer ao tempo de execução APIs especiais para monitorar a integridade dos contêineres e tomar as medidas apropriadas, se necessário. Sem isso, não será possível unificar a automação da atualização de contêineres e gerenciar seu ciclo de vida, o que, por sua vez, piorará a estabilidade e a usabilidade do sistema de software.
Na prática, um aplicativo de contêiner deve, no mínimo, ter uma API para vários tipos de verificações de saúde: testes de vivacidade e testes de prontidão. Se o aplicativo alegar ser maior, ele deve fornecer outros meios de monitorar sua condição. Por exemplo, registrando eventos importantes por meio de STDERR e STDOUT para agregar logs usando Fluentd, Logstash e outras ferramentas semelhantes. Bem como a integração com bibliotecas de rastreamento e coleção de métricas como OpenTracing, Prometheus, etc.
Em geral, o aplicativo ainda pode ser considerado como uma "caixa preta", mas, ao mesmo tempo, deve estar equipado com todas as APIs necessárias à plataforma para monitorá-lo e gerenciá-lo da melhor maneira.
Princípio de conformidade do ciclo de vida (LCP)
LCP é a antítese da HOP. Se o HOP indicar que o contêiner deve fornecer à API APIs para leitura, o LCP exigirá que o aplicativo possa receber informações da plataforma. Além disso, o contêiner não deve apenas receber eventos, mas também se adaptar, em outras palavras, responder a eles. Daí o nome do princípio, que pode ser considerado um requisito para fornecer à plataforma APIs para gravação.
As plataformas têm diferentes tipos de eventos que ajudam a gerenciar o ciclo de vida do contêiner. Mas cabe ao aplicativo decidir qual deles perceber e como responder.
É claro que alguns eventos são mais importantes que outros. Por exemplo, se o aplicativo não tolera o desligamento de emergência, ele deve aceitar as mensagens signal: terminate (SIGTERM) e iniciar seu procedimento de terminação o mais rápido possível para capturar o sinal: kill (SIGKILL) que vem 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 iniciar o aplicativo, pode levar algum tempo para "aquecer" antes que ele possa responder às solicitações. Ou o aplicativo deve, de alguma forma, liberar recursos no desligamento.
O princípio da imutabilidade da imagem do recipiente (Princípio da imutabilidade da imagem, IIP)
É geralmente aceito que aplicativos em contêiner devem permanecer inalterados após a montagem, mesmo se executados em ambientes diferentes. Isso implica na necessidade de externalizar o armazenamento de dados em tempo de execução (em outras palavras, usar ferramentas externas para isso), além de contar com configurações externas configuradas para um ambiente de tempo de execução específico, em vez de modificar ou criar contêineres exclusivos para cada ambiente. Após qualquer alteração no aplicativo, a imagem do contêiner deve ser remontada e implantada em todos os ambientes utilizados. A propósito, ao gerenciar sistemas de TI, um princípio semelhante é usado, conhecido como o princípio da imutabilidade de servidores e infraestrutura.
O objetivo do IIP é impedir a criação de imagens de contêiner separadas para diferentes ambientes de tempo de execução e usar a mesma imagem em todos os lugares, juntamente com a configuração apropriada para um ambiente específico. Seguir esse princípio permite implementar práticas importantes do ponto de vista da automação de sistemas em nuvem, como retroceder e avançar as atualizações de aplicativos.
Princípio da descartabilidade do processo (PDP)
Uma das características mais importantes de um contêiner é sua efemeridade: uma instância de contêiner é facilmente criada e destruída, para que possa ser facilmente substituída por outra instância a qualquer momento. Pode haver muitos motivos para essa substituição: falha no teste de integridade, dimensionamento do aplicativo, transferência para outro host, esgotamento dos recursos da plataforma ou outras situações.
Como resultado, os aplicativos de contêiner devem manter seu estado usando alguns meios externos ou usar circuitos distribuídos internos com redundância para isso. Além disso, o aplicativo deve ser iniciado rapidamente e encerrado rapidamente e estar preparado para uma súbita falha fatal de hardware.
Uma prática que ajuda a implementar esse princípio é criar pequenos contêineres. Os ambientes em nuvem podem selecionar automaticamente um host para iniciar uma instância de contêiner; portanto, quanto menor o contêiner, mais rápido ele será iniciado - ele será simplesmente copiado para o host de destino pela rede mais rapidamente.
Princípio de autocontenção (S-CP)
De acordo com este princípio, na fase de montagem, todos os componentes necessários são incluídos no recipiente. O contêiner deve ser construído na expectativa de que o sistema tenha apenas um kernel Linux limpo, para que todas as bibliotecas adicionais necessárias sejam colocadas no próprio contêiner. Coisas também devem estar localizadas lá, como o tempo de execução da linguagem de programação correspondente, a plataforma do aplicativo (se necessário) e outras dependências que serão necessárias durante a operação do aplicativo de 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.
Um aplicativo pode incluir vários componentes em contêiner, por exemplo, um contêiner DBMS separado como parte de um aplicativo de contêiner da web. De acordo com o princípio S-CP, esses contêineres não devem ser combinados em um, mas feitos para que o contêiner DBMS contenha tudo o necessário para o banco de dados funcionar e o contêiner de aplicativo da web contenha tudo o necessário para o aplicativo da Web funcionar, o mesmo servidor da Web . Como resultado, no tempo de execução, o contêiner de aplicativo da web dependerá do contêiner do DBMS e o acessará conforme necessário.
Princípio de confinamento de tempo de execução (RCP)
O princípio S-CP define como um contêiner deve ser montado e o que um arquivo de imagem binário deve conter. Mas um contêiner não é apenas uma "caixa preta", que possui apenas uma característica - tamanho do arquivo. No tempo de execução, o contêiner adquire outras dimensões: a quantidade de memória usada, tempo do processador e outros recursos do sistema.
E aqui o princípio RCP é útil, segundo o qual o contêiner deve decapitar seus requisitos de recursos do sistema e transferi-los para a plataforma. Com os perfis de recursos de cada contêiner (quantos recursos de CPU, memória, rede e sistema de disco precisam), a plataforma pode otimizar o agendamento e o dimensionamento automático, gerenciar as capacidades de TI e dar suporte aos níveis de SLA para contêineres.
Além de atender aos requisitos de recursos do contêiner, também é importante que o aplicativo não ultrapasse a estrutura designada por ele. Caso contrário, se houver escassez de recursos, é mais provável que a plataforma a inclua na lista de aplicativos que precisam ser interrompidos ou migrados.
Falando sobre o foco na nuvem, queremos dizer principalmente a maneira como trabalhamos.
Acima, formulamos vários princípios gerais que estabelecem a base metodológica para a criação de aplicativos de contêineres de alta qualidade para ambientes em nuvem.
Observe 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 breves recomendações mais específicas e devem ser aplicadas (ou não aplicadas) dependendo da situação:
Seminário on-line sobre a nova versão do OpenShift Container Platform - 411 de junho às 11h00
O que você aprenderá:
- Imutável Red Hat Enterprise Linux CoreOS
- Malha de serviço Openshift
- Estrutura do operador
- Quadro Knative