Aplicativos “nativos da nuvem” ou simplesmente “nuvem” são criados especificamente para funcionar em infraestruturas em nuvem. Eles normalmente são construídos como um conjunto de microsserviços fracamente acoplados, embalados em contêineres, que por sua vez são gerenciados por uma plataforma em nuvem. Tais aplicações estão preparadas para falhas por padrão, o que significa que funcionam de forma confiável e escaláveis mesmo no caso de falhas graves no nível da infraestrutura. A outra face da moeda são os conjuntos de restrições (contratos) que a plataforma cloud impõe às aplicações containers para poder gerenciá-las automaticamente.
Embora estejam plenamente conscientes da necessidade e da importância de migrar para aplicativos baseados em nuvem, muitas organizações ainda não sabem por onde começar. Nesta postagem, veremos uma série de princípios que, se seguidos no desenvolvimento de aplicativos em contêineres, permitirão que você aproveite o potencial das plataformas em nuvem e obtenha operação confiável e dimensionamento de aplicativos, mesmo no caso de falhas graves na infraestrutura de TI. nível. O objetivo final dos princípios descritos aqui é aprender como construir aplicativos que possam ser gerenciados automaticamente por plataformas em 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 usados ao trabalhar com qualquer linguagem de programação. Cada princípio tem seus próprios objetivos, cujas ferramentas para alcançá-los geralmente são modelos e práticas. Existem também vários princípios fundamentais para a criação de software de alta qualidade, dos quais todos os outros fluem. Aqui estão alguns exemplos de princípios fundamentais:
- (Mantenha as coisas simples, estúpido) – não complique;
- (Não se repita) - não se repita;
- (Você não vai precisar disso) - não crie algo que não seja necessário imediatamente;
- Separação de preocupações – compartilhe responsabilidades.
Como você pode ver, esses princípios não estabelecem nenhuma regra específica, mas pertencem à categoria das chamadas considerações de bom senso baseadas na experiência prática, que são compartilhadas por muitos desenvolvedores e às quais eles se referem regularmente.
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 inclui princípios complementares amplos e abertos que, quando aplicados em conjunto, ajudam a criar sistemas de software melhores e a mantê-los melhor no longo prazo.
Os princípios SOLID pertencem ao campo da OOP e são formulados na linguagem de conceitos e conceitos como classes, interfaces e herança. Por analogia, os princípios de desenvolvimento também podem ser formulados para aplicações em nuvem, 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êineres que atendam melhor às metas e objetivos de plataformas em nuvem como o Kubernetes.
Contêineres nativos da nuvem: a abordagem da Red Hat
Hoje, quase qualquer aplicativo pode ser empacotado com relativa facilidade em contêineres. Mas para que os aplicativos sejam automatizados e orquestrados de maneira eficaz em uma plataforma de nuvem como o Kubernetes, é necessário um esforço adicional.
A base para as ideias descritas abaixo foi a metodologia e muitos outros trabalhos sobre vários aspectos da construção de aplicações web, desde gerenciamento de código-fonte até modelos de escalabilidade. Os princípios descritos aplicam-se apenas ao desenvolvimento de aplicações em contêineres construídas sobre microsserviços e projetadas para plataformas em nuvem, como 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 tarefas de agendamento, escalonamento e monitoramento possam ser automatizadas na maioria das plataformas de orquestração. Os princípios não são apresentados em nenhuma ordem específica.
Princípio de Preocupação Única (SCP)
Este princípio é em muitos aspectos semelhante ao Princípio da Responsabilidade Única. ), que faz parte do conjunto SOLID e afirma que cada objeto deve ter uma responsabilidade, e essa responsabilidade deve ser completamente encapsulada em uma classe. O objetivo do SRP é que toda responsabilidade é um motivo para mudança, e uma classe deve ter um e apenas um motivo para mudança.
No SCP, usamos a palavra “preocupação” em vez da palavra “responsabilidade” para indicar o nível mais alto de abstração e o propósito mais amplo de um contêiner em comparação com uma classe OOP. E se o objetivo do SRP é ter apenas um motivo para mudança, então por trás do SCP está o desejo de expandir a capacidade de reutilização e substituição de contêineres. Seguindo o SRP e criando um contêiner que resolva um único problema e de forma funcionalmente completa, você aumenta as chances de reutilizar aquela imagem de contêiner em diferentes contextos de aplicação.
O princípio SCP afirma que cada contêiner deve resolver um único problema e fazê-lo bem. Além disso, o SCP no mundo dos contêineres é mais fácil de alcançar do que o SRP no mundo OOP, uma vez que os contêineres geralmente executam um único processo e, na maioria das vezes, esse processo resolve uma única tarefa.
Se algum microsserviço de contêiner precisar resolver vários problemas de uma vez, ele poderá ser dividido em contêineres de tarefa única e combinado em um pod (uma unidade de implantação de plataforma de contêiner) usando modelos de contêiner secundário e de inicialização. Além disso, o SCP facilita a substituição de um contêiner antigo (como um servidor web ou agente de mensagens) por um novo que resolva o mesmo problema, mas tenha funcionalidade expandida ou seja melhor dimensionado.
Princípio de Alta Observabilidade (HOP)
Quando os contêineres são usados como uma forma unificada de empacotar e executar aplicativos, os próprios aplicativos são tratados como uma caixa preta. No entanto, se forem contêineres em nuvem, eles deverão fornecer APIs especiais ao tempo de execução para monitorar a integridade dos contêineres e, se necessário, tomar as medidas apropriadas. Sem isso, não será possível unificar a automação da atualização dos containers e do gerenciamento do seu ciclo de vida, o que, por sua vez, piorará a estabilidade e usabilidade do sistema de software.
Na prática, uma aplicação contentorizada deve, no mínimo, ter uma API para vários tipos de verificações de saúde: testes de atividade e testes de prontidão. Se um aplicativo alegar fazer mais, ele deverá fornecer outros meios de monitorar seu estado. Por exemplo, registrar eventos importantes via STDERR e STDOUT para agregação de log usando Fluentd, Logstash e outras ferramentas semelhantes. Bem como integração com bibliotecas de rastreamento e coleta de métricas, como OpenTracing, Prometheus, etc.
Em geral, a aplicação ainda pode ser tratada como uma caixa preta, mas deve ser dotada de todas as APIs que a plataforma necessita para monitorá-la e gerenciá-la da melhor forma possível.
Princípio de Conformidade do Ciclo de Vida (LCP)
LCP é a antítese do HOP. Embora o HOP afirme que o contêiner deve expor APIs de leitura para a plataforma, o LCP exige que o aplicativo seja capaz de aceitar informações da plataforma. Além disso, o container 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 considerado um requisito para dotar a plataforma de escrita de APIs.
As plataformas possuem diferentes tipos de eventos para ajudar a gerenciar o ciclo de vida de um contêiner. Mas 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 uma aplicação não tolera bem travamentos, ela deve aceitar mensagens de sinal: terminar (SIGTERM) e iniciar sua rotina de encerramento o mais rápido possível para capturar o sinal: matar (SIGKILL) que vem depois de SIGTERM.
Além disso, eventos como PostStart e PreStop podem ser importantes para o ciclo de vida de um aplicativo. Por exemplo, depois de iniciar um aplicativo, pode ser necessário algum tempo de aquecimento antes de poder responder às solicitações. Ou o aplicativo deve liberar recursos de alguma forma especial ao ser encerrado.
O Princípio da Imutabilidade da Imagem (IIP)
É geralmente aceito que os aplicativos em contêineres devem permanecer inalterados após serem construídos, mesmo que sejam executados em ambientes diferentes. Isso exige a necessidade de externalizar o armazenamento de dados em tempo de execução (em outras palavras, de usar ferramentas externas para isso) e de contar com configurações externas específicas do tempo de execução, em vez de modificar ou criar contêineres exclusivos para cada ambiente. Após quaisquer alterações na aplicação, a imagem do contêiner deverá ser reconstruída e implantada em todos os ambientes utilizados. Aliás, no gerenciamento de sistemas de TI, é utilizado um princípio semelhante, conhecido como princípio da imutabilidade de servidores e infraestrutura.
O objetivo do IIP é evitar 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 específica do ambiente. Seguir este princípio permite implementar práticas importantes do ponto de vista da automação de sistemas em nuvem, como reversão e avanço de atualizações de aplicativos.
Princípio de Descarte de Processo (PDP)
Uma das características mais importantes de um contêiner é sua efemeridade: uma instância de contêiner é fácil de criar e fácil de destruir, portanto pode ser facilmente substituída por outra instância a qualquer momento. Pode haver vários motivos para tal substituição: falha em um teste de manutenção, dimensionamento da aplicação, transferência para outro host, esgotamento dos recursos da plataforma ou outras situações.
Como consequência, as aplicações conteinerizadas devem manter seu estado utilizando algum meio externo, ou utilizar esquemas internos distribuídos com redundância para isso. Além disso, o aplicativo deve iniciar e encerrar rapidamente e estar preparado para falhas repentinas e fatais de hardware.
Uma prática que ajuda a implementar este princípio é manter os recipientes pequenos. Os ambientes de 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 simplesmente copiará para o host de destino pela rede com mais rapidez.
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 contentor. O contêiner deve ser construído partindo do pressuposto de que o sistema possui apenas um kernel Linux puro, portanto, todas as bibliotecas adicionais necessárias devem ser colocadas no próprio contêiner. Ele também deve conter coisas 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 enquanto o aplicativo contêiner estiver em execução.
Exceções são feitas para configurações que variam de ambiente para ambiente e devem ser fornecidas em tempo de execução, por exemplo, por meio de um ConfigMap do Kubernetes.
Um aplicativo pode incluir vários componentes em contêineres, por exemplo, um contêiner DBMS separado dentro de um aplicativo da web em contêineres. De acordo com o princípio S-CP, esses contêineres não devem ser combinados em um, mas devem ser feitos de forma que o contêiner SGBD contenha tudo o que é necessário para o funcionamento do banco de dados, e o contêiner da aplicação web contenha tudo o que é necessário para o funcionamento do web aplicativo, o mesmo servidor web. Como resultado, em tempo de execução, o contêiner do aplicativo web dependerá do contêiner DBMS e o acessará conforme necessário.
Princípio de Confinamento de Tempo de Execução (RCP)
O princípio S-CP define como o contêiner deve ser construído e o que o binário da imagem deve conter. Mas um contêiner não é apenas uma “caixa preta” que possui apenas uma característica: o tamanho do arquivo. Durante a execução, o contêiner assume outras dimensões: quantidade de memória utilizada, tempo de CPU 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 disco são necessários), a plataforma pode realizar agendamento e escalonamento automático de maneira ideal, gerenciar a capacidade de TI e manter os níveis de SLA para contêineres.
Além de atender aos requisitos de recursos do contêiner, também é importante que a aplicação não ultrapasse seus próprios limites. Caso contrário, quando ocorrer uma escassez de recursos, é mais provável que a plataforma o inclua na lista de aplicativos que precisam ser encerrados ou migrados.
Quando falamos em priorizar a nuvem, estamos falando sobre a forma como trabalhamos.
Acima, formulamos uma série de princípios gerais que estabelecem a base metodológica para a construção de aplicações de contêiner de alta qualidade para ambientes de 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 recomendações curtas que são mais específicas e devem ser aplicadas (ou não) dependendo da situação:
- Tente reduzir o tamanho das imagens: exclua arquivos temporários e não instale pacotes desnecessários - quanto menor o tamanho do contêiner, mais rápido ele será montado e copiado para o host de destino pela rede.
- Concentre-se em IDs de usuário arbitrários: não use o comando sudo ou qualquer ID de usuário especial para iniciar seus contêineres.
- Marque portas importantes: Você pode definir números de porta em tempo de execução, mas é melhor especificá-los usando o comando EXPOSE - isso tornará mais fácil para outras pessoas e programas usarem suas imagens.
- Armazene dados persistentes em volumes: os dados que devem permanecer após a destruição do contêiner devem ser gravados em volumes.
- Escreva metadados de imagem: tags, rótulos e anotações tornam as imagens mais fáceis de usar - outros desenvolvedores agradecerão.
- Sincronize host e imagens: alguns aplicativos em contêiner exigem que o contêiner seja sincronizado com o host em determinados atributos, como hora ou ID da máquina.
- Concluindo, compartilhamos modelos e práticas recomendadas que ajudarão você a implementar de forma mais eficaz os princípios listados acima:
11 de junho às 11.00hXNUMX
O que você aprenderá:
- Imutável Red Hat Enterprise Linux CoreOS
- Malha de serviço OpenShift
- Estrutura do operador
- Estrutura Knativa
Fonte: habr.com