Ao contrário da transição anterior e igualmente revolucionária de bare metal para máquinas virtuais, os contêineres reduzem drasticamente a redundância da pilha de software e mudam a própria natureza do gerenciamento de sistemas operacionais na empresa.
Muitos estão optando por acelerar sua transição para contêineres com a Red Hat OpenShift Container Platform, a plataforma Kubernetes líder do setor para o setor empresarial. Essa solução assume automaticamente muitas das tarefas do primeiro dia e oferece o melhor ecossistema Kubernetes em uma plataforma única, rigorosamente testada e altamente segura. Esta é a solução mais abrangente e funcional para empresas, que contém tudo que você precisa para começar e remove muitas barreiras técnicas e complexidades ao criar uma plataforma Kubernetes.
No entanto, o OpenShift não é uma varinha mágica que resolve todos os problemas por conta própria. Sim, graças às suas capacidades, esta plataforma é capaz de trazer - e traz aos seus clientes - muitos benefícios e rapidamente compensa, desde que na altura do seu lançamento tenha um plano bem pensado. Para ter sucesso, existem sete áreas que precisam ser totalmente trabalhadas antes de mover qualquer carga de trabalho para o OpenShift.
1. Padronização de regras de nomenclatura e metadados
Na ciência da computação, existem apenas duas coisas difíceis: invalidar o cache e nomear entidades.
- Phil Karlton
Cada entidade em OpenShift e Kubernetes tem seu próprio nome. E cada serviço deve ter seu próprio nome DNS , a única limitação aqui são as regras de nomenclatura DNS. Agora imagine que um aplicativo monolítico foi decomposto em 100.500 microsserviços separados, cada um com seu próprio banco de dados. E sim, no OpenShift tudo é hierárquico, relacionado ou deve seguir um padrão. Portanto, a massa e a massa de tudo terão que ser nomeadas. E se você não preparar os padrões com antecedência, será um verdadeiro faroeste.
Você já planejou o esquema de implementação do serviço? Digamos que será um grande namespace, por exemplo, "bancos de dados", no qual todos hospedarão seus bancos de dados. OK, e vamos supor que todo mundo faça isso, mas então eles começam a hospedar seus clusters Kafka em seus próprios namespaces. Sim, mas você precisa criar um "middleware" de namespace? Ou é melhor chamá-lo de "mensagem"? E como de costume, em algum momento há caras que sempre seguem seu próprio caminho e se consideram especiais, e dizem que precisam de seus próprios namespaces. E ouça, temos 17 departamentos na organização, talvez precisemos anexar nossos prefixos de departamento padrão a todos os namespaces?
Considere os padrões de nomenclatura e agrupamento antes de colocar qualquer coisa em produção - você pode economizar muito tempo e esforço se fizer isso antes do tempo. Estabeleça padrões para tudo. Além disso, não é tanto sua qualidade que é importante aqui, mas sua disponibilidade, integridade e implementação.
Outra coisa megaútil são os metadados . Padronize quais ativos você deseja rastrear e certifique-se de que os metadados corretos sejam escritos nos recursos corretos. Comece com rótulos recomendados... Por exemplo, anotar "support_email" nos metadados do namespace pode economizar um tempo valioso ao entrar em contato com o suporte de nível 2 no caso de uma falha grave. Além disso, os metadados podem ser usados para encurtar os nomes dos recursos para um comprimento significativo, em vez de hifenizar todas as informações necessárias. Envolva todos, desde arquitetos de aplicativos a operadores de TI, faça um brainstorm e descubra o que pode ser necessário para ter padrões sólidos quando o OpenShift for lançado.
2. Padronização de imagens de base corporativa
Um dos principais recursos dos contêineres é a capacidade de misturar e combinar todas as peças da pilha de software. Você pode, é claro, pegar seu tipo de sistema operacional favorito e construir tudo nele, mas, agindo dessa forma, a organização está perdendo grandes oportunidades. Afinal, o que é realmente legal sobre as imagens de contêiner? Camadas. Você pode remover muitas tarefas críticas dos desenvolvedores e resolvê-las padronizando imagens.
Pegue um aplicativo Java básico, por exemplo. É improvável que seus desenvolvedores dêem errado com o OpenJDK, mas com o gerenciamento de vulnerabilidades, atualização de bibliotecas e outras questões de higiene de TI - eles podem. Todos nós sabemos que os problemas de negócios costumam ser resolvidos às custas de compromissos técnicos, como o uso deliberado de versões mais antigas do Java. Felizmente, essas tarefas são facilmente automatizadas e gerenciadas no nível corporativo. Você ainda pode usar as imagens de base do fornecedor , mas ao mesmo tempo definir e controlar seus ciclos de atualização criando suas próprias imagens de base.
Voltando ao exemplo acima, digamos que os desenvolvedores queiram Java 11 e que eles sempre usem a versão mais recente do Java 11. Em seguida, você cria uma imagem de base corporativa (registry.yourcompany.io/java11) usando como ponto de partida imagem de base do fornecedor do sistema operacional (registry.redhat.io/ubi8/openjdk-11). E quando esta imagem de base é atualizada, você ajuda automaticamente os desenvolvedores a usar as atualizações mais recentes. Além disso, oferece uma camada de abstração que permite estender perfeitamente a imagem padrão com as bibliotecas ou pacotes Linux necessários.
3. Padronização de verificações de saúde e prontidão
Monitoramento da capacidade de manutenção é necessário em quase todos os lugares. Acredita-se que um exame médico anual seja suficiente para uma pessoa. A integridade dos aplicativos deve ser verificada, é claro, com muito mais frequência, e duas coisas principais devem ser monitoradas:
- Se o aplicativo está em execução (verificação de saúde).
- Se o aplicativo está pronto (verificação de prontidão).
Existem várias outras métricas para facilitar o monitoramento de aplicativos, mas essas duas são a base não apenas do monitoramento, mas também do dimensionamento. A integridade geralmente é determinada pela disponibilidade de conectividade de rede e pela capacidade do host que executa o aplicativo de responder a uma solicitação. No que se refere à prontidão, já aqui cada aplicativo deve responder às solicitações de acordo com seus próprios padrões. Por exemplo, iniciar um aplicativo com latência muito baixa pode resultar em uma longa atualização do cache ou aquecimento da JVM . E, consequentemente, a pausa entre as respostas "Iniciado" e "Pronto" pode chegar a vários minutos. Mas, por exemplo, para uma API REST sem estado com um banco de dados relacional, essas respostas virão simultaneamente.
O mais importante nessas verificações é não se desviar da lógica puramente binária. Lançado significa lançado, sem nenhum "tipo de lançamento" ali. Feito significa pronto, e sem gradações, como "pronto para atender a tais solicitações, mas não a tais solicitações". O princípio é simples: tudo ou nada.
O segundo aspecto dessas verificações é a padronização. Como verificar a prontidão? Se você não tem padrões, mesmo uma pergunta tão simples pode ser um verdadeiro pesadelo de monitoramento. Basta comparar como os padrões Quarkus e os padrões Spring Boot divergem . Mas ninguém queria isso, mas os padrões sempre são assim. A única diferença é que sua organização agora tem o poder de desenvolver e aplicar padrões.
Observe na margem. Não invente seus próprios padrões. Basta encontrar e usar um já pronto .
4. Padronização de logs
Continuando com o tópico de monitoramento, observamos que a combinação de armazenamentos baratos e soluções de big data deu origem a um novo monstro nas empresas - registro total. Anteriormente, eram logs de console arcaicos e não estruturados, que não duravam muito e eram criados de tempos em tempos. Agora, eles se esforçam para registrar tudo e construir ciência de dados com aprendizado de máquina para otimizar operações e monitoramento da forma mais revolucionária. Infelizmente, devemos admitir o óbvio: qualquer tentativa de começar a coletar logs de centenas de aplicativos sem ter absolutamente nenhum padrão e sem nem mesmo pensar sobre eles invariavelmente leva a despesas inúteis e exorbitantes com ferramentas para gerenciar logs e transformação de dados apenas para começar. trabalhos. Ou seja, antes mesmo de você entenderque as mensagens "Transição concluída" ou "Este bloqueio acionado" provavelmente não têm nada a ver com suas operações.
A estrutura precisa ser padronizada. Novamente, a integridade dos padrões é mais importante do que sua correção. Você deve ser capaz de escrever um analisador de log separado para cada aplicativo que está na empresa. Sim, eles serão apenas peças, não coisas replicadas. Sim, você terá um monte de exceções que não podem ser controladas, especialmente para aplicativos em caixa. Mas não jogue o bebê fora com a água, preste atenção aos detalhes: por exemplo, o carimbo de data / hora em cada registro deve atender ao padrão ISO adequado ; a própria saída deve ser em UTC com uma precisão do 5º dígito em microssegundos (2018-11-07T00: 25: 00.07387Z). Os níveis de log devem ser emitidos com CAPS e deve haver os elementos TRACE, DEBUG, INFO, WARN, ERROR. Em geral, defina a estrutura e só então entre em detalhes.
Padronizar a estrutura forçará todos a seguir as mesmas regras e usar os mesmos padrões arquitetônicos. Isso é verdadeiro para logs de aplicativo e plataforma. E não se desvie da solução pronta, a menos que seja absolutamente necessário. A pilha EFK (Elasticsearch, Fluentd e Kibana) da plataforma OpenShift deve ser capaz de lidar com todos os seus scripts. Afinal, ele entrou na plataforma por um motivo, e na hora de atualizá-la, é outra coisa com que você não precisa se preocupar.
5. Mudando para GitOps
Uma das melhores coisas sobre o OpenShift é que tudo aqui - literalmente: tudo - é basicamente configuração ou código, o que significa que pode ser controlado por meio de um sistema de controle de versão. Isso permite revolucionar os métodos de entrega e se livrar da burocracia ao iniciar a produção.
Em particular, o esquema tradicional baseado em tíquetes pode ser completamente substituído por um modelo com solicitações git pull.... Digamos que o proprietário do aplicativo deseja ajustar os recursos alocados ao aplicativo após implementar novas funções nele, por exemplo, aumentar a memória de 8 GB para 16 GB. No esquema tradicional, o desenvolvedor precisa criar um tíquete e esperar que outra pessoa conclua a tarefa correspondente. Essa outra pessoa é na maioria das vezes um operador de TI que apenas introduz um atraso tangível no processo de implementação de mudanças, sem agregar valor a este processo, ou pior, adicionando ciclos adicionais desnecessários a este processo. Na verdade, a operadora tem duas opções. Primeiro, ele revisa o aplicativo e decide executá-lo, para o qual entra no ambiente de produção, faz as alterações solicitadas manualmente e reinicia o aplicativo.
Além do tempo de execução do trabalho propriamente dito, aqui há um atraso adicional, pois a operadora, via de regra, sempre tem uma fila inteira de solicitações para execução. Além disso, existe o risco de erro humano, como 160 GB de entrada em vez de 16 GB. A segunda opção: o operador questiona o aplicativo e, assim, lança uma reação em cadeia para descobrir os motivos e as consequências das alterações solicitadas, tanto que por vezes as autoridades têm de intervir.
Agora vamos ver como isso é feito no GitOps. A solicitação de mudança vai para o repositório git e se torna uma solicitação pull. Depois disso, o desenvolvedor pode enviar essa solicitação de pull (especialmente se essas forem alterações no ambiente de produção) para aprovação das partes envolvidas. Dessa forma, os profissionais de segurança podem se envolver em um estágio inicial e sempre há a oportunidade de rastrear a sequência de alterações. Os padrões nesta área podem ser implementados programaticamente usando ferramentas apropriadas na cadeia de ferramentas CI / CD. Depois de aprovada, a solicitação pull tem controle de versão e é facilmente auditada. Além disso, ele pode ser testado em um ambiente de pré-produção como parte de um processo padrão , eliminando completamente o risco de erro humano.
Como você pode ver, as mudanças são radicais. Mas eles serão novos, não tanto para desenvolvedores que estão acostumados com sistemas de controle de versão, mas para administradores de sistema e especialistas em segurança. Mas assim que eles mergulharem no novo paradigma e apreciarem sua força e simplicidade, a ideia explodirá.
6. Projetos
A mudança de aplicativos monolíticos para microsserviços aprimora a função dos padrões de design de aplicativos (padrões). Na verdade, a aplicação monolítica típica não é muito classificável. Normalmente, existem APIs REST, processamento em lote e orientado a eventos. HTTP, FTP, kafka, JMS e Infinispan ? Sim, por favor, e também funciona com três bancos de dados diferentes ao mesmo tempo. E como você pode criar um esquema quando um monte de padrões de integração de aplicativos corporativos são misturados aqui? De jeito nenhum.
Mas se você decompor esse aplicativo monolítico em partes separadas, os modelos serão diferenciados com muito mais facilidade e facilidade. Digamos que agora haja quatro aplicativos separados e eles usem os seguintes modelos:
- API REST para gerenciamento de dados em um DBMS.
- O processamento em lote que verifica se há atualizações no servidor FTP e as envia para o tópico kafka.
- Camel é um adaptador que obtém dados deste tópico kafka e os envia para a API REST
- APIs REST que expõem informações agregadas coletadas de um Data Grid que atua como uma máquina de estado.
Portanto, agora temos esquemas, e os esquemas podem ser padronizados. As APIs REST devem estar em conformidade com os padrões da API aberta . Os trabalhos em lote serão gerenciados como trabalhos em lote OpenShift . As integrações usarão Camel... Você pode criar esquemas para APIs, para jobs em lote, para AI / ML, para aplicativos multicast ou o que for. E então você pode determinar como implantar esses esquemas, como configurá-los e quais modelos usar. Com esses padrões em vigor, você não terá que reinventar a roda todas as vezes e poderá se concentrar melhor nas tarefas realmente importantes, como a criação de novas funcionalidades de negócios. Elaborar os esquemas pode parecer perda de tempo, mas o esforço despendido será cem vezes maior no futuro.
7. Prepare-se para a API
APIs vêm com arquitetura de microsserviço. Eles também terão que ser gerenciados e melhor preparados com antecedência para isso.
Primeiro, os padrões são necessários aqui novamente. Você pode pegar os padrões da API aberta como ponto de partida , mas precisa se aprofundar mais na selva. Embora seja importante encontrar um equilíbrio aqui e não cair em um excesso de regulamentação com um monte de restrições. Observe estas perguntas: Quando uma nova entidade é criada usando POST, devemos retornar 201 ou 200? é permitido atualizar entidades usando POST e não PUT? Qual é a diferença entre 400 e 500 respostas? - aproximadamente o mesmo nível de detalhes de que você precisa.
Em segundo lugar, você precisa de uma malha de serviço... Isso é algo muito forte e, com o tempo, se tornará parte integrante do Kubernetes. Por quê? Porque o tráfego, mais cedo ou mais tarde, se tornará um problema, e você vai querer gerenciá-lo tanto dentro do data center (o chamado tráfego “leste-oeste”) e entre o data center e o mundo externo (“norte- sul"). Você desejará obter autenticação e autorização de aplicativos e trazê-los para o nível de plataforma. Você precisará dos recursos do Kiali para visualizar o tráfego dentro da malha de serviço, bem como esquemas de implantação de aplicativos azul-verde e canário ou, por exemplo, controle de tráfego dinâmico. Em geral, a malha de serviço se enquadra na categoria de tarefas do primeiro dia sem dúvida.
Terceiro, você precisará de uma solução de gerenciamento de API centralizada... Você desejará ter uma “janela única” para localizar e reutilizar APIs. Os desenvolvedores precisarão acessar a API Store, encontrar a API que desejam e obter a documentação sobre como usá-la. Você desejará gerenciar consistentemente versões e depreciações. Se você estiver construindo uma API para consumidores externos, pode ser um endpoint norte-sul para segurança e gerenciamento de carga. A 3Scale pode até ajudar na monetização da API. Bem, mais cedo ou mais tarde, sua administração vai querer receber um relatório respondendo à pergunta "Qual API nós temos?"
Em conclusão, observamos que embora a identificação de áreas para padronização e documentação de padrões corporativos possa ser assustadora em si mesma, a maior parte do esforço não é gasta nisso, mas no monitoramento e fiscalização da conformidade com os padrões. Mistura poderosa de entropia organizacionale uma relutância completamente natural em entrar em conflito com colegas desde o início, trabalhando contra os padrões. A luta se divide em incontáveis batalhas minúsculas e às vezes invisíveis: o rótulo obrigatório está faltando aqui, e este nome, embora não completamente, ainda atende o padrão suficientemente. Os padrões geralmente morrem de morte por mil cortes, e poucos, se houver, na organização sabem sobre isso. De certo modo, os padrões são como exercícios: ninguém quer suar e se esforçar, mas todos sabem que uma vida longa e saudável é impossível sem eles.
No entanto, há esperança e ela reside na automação. Qualquer um dos padrões acima pode ser implementado usando automação. O processo GitOps pode verificar se todos os rótulos e anotações necessários estão presentes em todos os arquivos yaml relevantes. O processo de CI / CD pode impor padrões para imagens corporativas. Tudo pode ser codificado, testado e harmonizado. Além disso, a automação pode ser aprimorada quando você introduz novos padrões ou altera os existentes. A vantagem indiscutível da padronização por meio da automação é que o computador não evita conflitos, mas simplesmente informa os fatos. Portanto, com bastante sofisticação e investimento em automação, a plataforma na qual você está investindo tanto hoje épode trazer um retorno do investimento muito maior no futuro, na forma de melhor desempenho e estabilidade.