Em uma grande empresa, muitas vezes é muito difícil coordenar a alocação de recursos para tarefas de trabalho. Todo o Agile esmagando a parede de um contrato de três semanas com o IS da nova infraestrutura. Portanto, geralmente recebemos solicitações para transferir a infraestrutura para contêineres, a fim de implementar as alterações não uma vez a cada três meses e quando a empresa precisar. Ao mesmo tempo, eles pedem para configurar / implementar o Kubernetes como o instrumento mais popular de orquestração, embora, como mostra a prática, de 10 projetos, sejam necessários no máximo três. Mas, na verdade, vale a pena usar o Kubernetes, mas o OpenShift, ou trabalhar com ele não em sua infraestrutura, mas em uma nuvem pública, por exemplo. Vou tentar falar sobre os casos reais de negócios que decidimos, descreverei as principais diferenças entre o Kubernetes e o OpenShift. E também sobre como reduzimos a coordenação da segurança da informação para 30 minutos e todos continuamos vivos.
Tivemos várias implementações interessantes nas quais resolvemos os problemas acumulados do cliente. Por exemplo, uma empresa de varejo veio até nós e precisava lançar novos chips continuamente. A competição é louca! E eles só têm infraestrutura para desenvolvimento cada vez que leva de seis a dez dias, o que causa tempo de inatividade. Resolver o problema comprando um novo hardware para teste e desenvolvimento é caro e o caminho para lugar nenhum. Como resultado, transferimos a infraestrutura de TI para a virtualização de contêineres. Como resultado, graças aos contêineres, a carga foi reduzida em 40% e a infraestrutura para o novo desenvolvimento agora está sendo preparada de uma a quatro horas. O bônus é a economia, uma vez que todos os processos podem continuar sendo conduzidos com base nas capacidades existentes sem a compra de novas.
O que vamos fazer com segurança da informação?
IB são pessoas muito necessárias. Eles costumam ir um pouco longe demais em seus requisitos internos para projetos, mas isso é muito melhor do que ver uma vez que seu servidor SFTP externo foi cercado por hackers romenos.
Mas há um problema com eles. Se considerarmos o processo de negócios como um transportador, sua divisão geralmente se torna o gargalo em que todos os demais se baseiam. Por um lado, eles são responsáveis por todos os riscos associados à segurança, por outro, eles simplesmente não conseguem visualizar fisicamente manualmente o código e todos os detalhes da arquitetura do novo produto.
A situação é muito semelhante aos serviços de segurança em áreas com um grande fluxo de pessoas. Podemos organizar uma inspeção total de cada passageiro no metrô, enfiando-o nos scanners, revirando os bolsos e inspecionando o telefone. Como resultado, no entanto, em vez de segurança, você obterá um colapso total do transporte e uma paralisia do sistema. A única opção nessa situação é a organização de sistemas automatizados que responderão, digamos, a indivíduos, identificando pessoas procuradas ou reagindo a algum comportamento anormal.
Em nosso contexto, esses sistemas automatizados são processos de CI / CD adequadamente organizados com analisadores de código em estágios intermediários, soluções como o JFrog Xray for Artifactory e porcas Kubernetes / OpenShift corretamente apertadas que não permitem abordagens inseguras, como o lançamento de um contêiner pelo usuário raiz. Agora estamos preparando uma solução in a box que fornecerá tudo isso.
O objetivo é passar do conceito de "não entrará na venda até examinarmos" para "se não houver objeções, ele será implantado automaticamente". Não há sentido em automação se os processos organizacionais permanecerem os mesmos.
Em um dos projetos, conseguimos reduzir o tempo de falha de SI para 30 minutos. Em outras palavras, se em meia hora o "guarda de segurança" não rejeitar a ação, será automaticamente acordado e as alterações serão lançadas em produção. Agora, estamos tentando atingir um prazo de 60 minutos para todos os coordenadores do projeto sem comprometer a segurança.
Qual é a diferença entre sistemas de gerenciamento de contêineres?
Kubernetes e OpenShift são as principais soluções para orquestração de contêineres. Vamos analisar as principais diferenças e vantagens para os negócios.
AberturaO Kubernetes é um produto totalmente aberto que pode ser implantado de forma independente e atendido por conta própria ou com suporte externo. A situação no mercado de trabalho já está mais ou menos estabilizada, e encontrar especialistas nesse tópico não é mais um problema.
O OpenShift é um produto semi-fechado com um sofisticado sistema de licenciamento da RedHat. De fato, ele contém Kubernetes, mas possui várias ligações adicionais que simplificam muitas tarefas. O fornecedor fornece suporte pago integral ao seu produto.
Aqui, a escolha depende do que melhor lhe convier - apoio das forças de seus especialistas ou fornecedores.
PlataformasO Kubernetes funciona em quase qualquer plataforma Linux e na maioria dos provedores de nuvem.
O OpenShift não funciona em nenhum lugar, exceto no RHEL, Red Hat Atomic, Red Hat CoreOS. Existe uma versão da comunidade - OKD, mas está fortemente ligada às distribuições. A única exceção é que ele pode ser instalado no CentOS. E lembre-se de que oficialmente a Red Hat não garante suporte pago.
Políticas de segurançaO OpenShift pronto para uso possui configurações de segurança mais rígidas. Essa é uma vantagem ao implantar a infraestrutura do zero, mas pode ser um problema devido à incompatibilidade de algumas imagens com os políticos. Por exemplo, no OpenShift, é proibido executar o contêiner a partir da raiz, o que quebra a compatibilidade com imagens antigas. Por outro lado, essa abordagem, combinada com a integração conveniente com o AD, o registro conveniente com base na pilha EFK (ElasticSearch, Fluentd, Kibana) nos oferece a segurança imediata necessária para descarregar a unidade IS.
O Kubernetes também pode ser finalizado para esse nível, mas exigirá muito esforço e tempo da parte dos engenheiros.
PadrõesOs modelos do OpenShift são menos flexíveis que os gráficos do Kubernetes Helm. Devido a políticas de segurança mais rigorosas, a Red Hat não pode fornecer a flexibilidade dos gráficos Helm no momento. No entanto, no OpenShift 4, a situação se estabilizou graças ao
OperatorHub integrado.
Ter modelos bem projetados prontos para uso facilita a vida. De fato, essa é uma opção do gerenciador de pacotes para criar e configurar vários serviços.
Um comando condicional “helm install prometheus-operator” implementa um sistema bastante complexo, que leva muito tempo para ser implementado. Kubernetes está liderando o caminho.
Conclusões geraisComo a maioria dos produtos, o Red Hat OpenShift é uma solução mais in a box, mas arquiteturalmente mais difícil. Exige menos funcionários de olhos vermelhos e mais experientes para trabalhar. Cenários de implantação mais convenientes, excelente integração com soluções de CI / CD, em particular com Jenkins. O OpenShift é ótimo para empresas que são mais fáceis de pagar para oferecer suporte a um produto acabado do que contratar seus próprios especialistas.
Para empresas com fortes especialistas neste campo, o Kubernetes pode ser uma solução mais flexível e interessante. Também pode ser adequado para uma empresa relativamente pequena que deseja economizar nas licenças da Red Hat, mas não possui tarefas complexas que exigem especialistas altamente qualificados.
Casos reais
Vou tentar mostrar como as tecnologias de contêineres ajudaram a resolver problemas de negócios, salvaram licenças e garantiram a suavização do pico de cargas durante ataques em massa a usuários.
Estudo de caso: Comércio eletrônico
O problemaO cliente tinha mais de 100 serviços ativos executando a base de nuvem da VMware. E todo esse parque teve vários problemas diferentes:
- 12 serviços que exigem recursos e sem margem foram lançados no VMware, consumindo um orçamento de aproximadamente US $ 408.000 por ano.
- Três serviços (um portal e dois aplicativos móveis) começaram a se desenvolver ativamente: ao longo de sete meses, a quantidade de recursos necessários para o trabalho aumentou 4,5 vezes e continua a crescer.
- Vários serviços ao cliente têm picos de carga, durante os quais os recursos são necessários seis a sete vezes mais do que nos períodos normais. Consequentemente, os equipamentos foram alocados para a operação correta, que na maioria das vezes era utilizada em menos de 15%.
Além de tudo isso, o cliente deseja evitar a vinculação a um fornecedor de virtualização.
Nossa decisãoA primeira e mais simples solução: transferimos serviços com picos para a
nuvem pública do CROC . Com cobrança por recursos consumidos. Tudo é o mais simples e chato possível. A mudança do VMware de alguém para o nosso KVM é um dos casos mais frequentes para engenheiros de nuvem.
Como o hardware para dimensionamento já foi adquirido pelo cliente, tivemos que calcular apenas as licenças. Para novos hosts da VMware, eles custam cerca de US $ 2.100.000, o que não agradou muito ao cliente. Propusemos transferir alguns dos serviços para o KVM executando o OpenStack. E para não se perder, integre o gerenciamento de ambas as infra-estruturas pelo CloudForms (e ao mesmo tempo OpenShift).
Como resultado, o cliente recebeu o segundo ombro de uma nuvem privada baseada no OpenStack, que encerrou a pergunta do fornecedor. Ao mudar alguns dos serviços que consomem muitos recursos para um novo local, reduziu o custo das licenças VMware (o suporte 24x7 da CROC era mais barato).
Caso: Varejo
O problemaDurante a auditoria, aconteceu que algo terrível estava acontecendo com o cliente em relação à alocação de infraestrutura. Projetos - mais de 250, equipes de desenvolvimento - mais de 150, meio contêineres no Kubernetes. Os recursos para cada novo projeto são adquiridos e permanecem atribuídos a ele sem a capacidade de selecionar, mesmo que não sejam usados. Não há cobrança, não existe um portal único. Custos enormes para ambientes de teste e pré-produção, pois eles também usam o VMware.
Ao mesmo tempo, o cliente não deseja mudar completamente para uma nova plataforma e deseja montar tudo em um único portal de gerenciamento. Além disso, “tudo” não é apenas VMware, mas também PaaS, contêineres e um único faturamento.
Nossa decisãoComo resultado, o interior da solução acabou sendo bastante amontoado, mas, para o cliente, tudo parece extremamente simples.
O diretório em que o usuário seleciona os parâmetros da máquina virtual e o circuito necessário: DevTest, PreProd, Prod. E o CloudForms escolhe onde implantar o recurso solicitado: no VMware ou no OpenShift. Ainda estamos trabalhando no faturamento único, pois a solução híbrida VMware + OpenShift é bastante difícil de montar.
De fato, dessa maneira, colocamos as coisas em ordem na infraestrutura, separando os escombros que o cliente empilhava.
Caso: Indústria
O problemaA cópia de VMs para vários ambientes (Teste, Desenvolvimento, Produção, Pré-produção) leva mais de três dias e requer a execução manual de 15 operações diferentes, cada uma levando até 30 minutos. Uma auditoria mais profunda mostrou que, anteriormente, eram necessárias duas semanas para alocar recursos para um novo projeto, e havia de 10 a 20 solicitações por mês. Agora, existem mais de dez solicitações de recursos por dia, o que, sem automação, levou ao colapso.
Nossa decisãoDe fato, o cliente precisava transferir a infraestrutura de TI para o modelo de serviço, reconstruir e automatizar o processo de fazer alterações na infraestrutura, criar um portal de autoatendimento, preenchê-lo com um catálogo de serviços e implementar um ambiente para gerenciar aplicativos em contêiner. Automatizamos o processo de cópia da VM, mas ainda demorou muito tempo: 40 a 60 minutos, isso não era adequado ao cliente. Como resultado, propusemos a mudança para contêineres, o que reduziu o tempo de cópia para três a cinco minutos.
Conclusões
Contêiner e microsserviços não são indulgências por códigos incorretos que serão gravados com o pé esquerdo e voarão imediatamente para a produção. Pelo contrário, este é um conceito completo, envolvendo várias melhorias devido à profunda automação de todos os processos:
- O código fica mais limpo: linter, analisadores de código, testes automatizados.
- O código e a arquitetura estão se tornando mais seguros: ferramentas de segurança com amplos recursos, até o bloqueio automático da implantação de código não seguro.
- Os serviços estão se tornando mais flexíveis e móveis: os ciclos de desenvolvimento agora são extremamente curtos e respondem rapidamente às mudanças.
- Escalonamento automático sob carga: seu recurso não diminui mais na hora do rush, perdendo vendas e clientes.
- Alocação simples de recursos para novos projetos, redução do tempo gasto na coordenação.
- Freqüentemente, a conteinerização pode reduzir significativamente o tempo de colocação no mercado.
E, às vezes, a conteinerização não é necessária e o problema pode ser resolvido pela migração para uma nuvem externa. Mas, para tomar uma decisão, em qualquer caso, precisamos de uma boa auditoria externa e análise do que está acontecendo. Em suma, os contêineres são apenas uma das ferramentas para resolver problemas de negócios, embora muito legais.