Gostaria de compartilhar minha história sobre a migração de um aplicativo para o Openshift. Além disso, como resultado, compararei algumas das soluções e ferramentas mais populares para gerenciar seu aplicativo no Openshift. É a transcrição da minha apresentação no kubernetes SPB meetup # 3 .
Vamos implantar no Openshift
O que devemos fazer?
Primeiro de tudo, vamos falar sobre a nossa aplicação. É uma solução corporativa pronta para uso, suporta diferentes bancos de dados, servidores de aplicativos e interfaces de integração com sistemas de terceiros. Normalmente, nossos clientes estavam instalando em servidores dedicados; no entanto, enfrentávamos o problema. Tivemos que ajustar o aplicativo dentro do Openshift.
Pré-requisitos
O aplicativo é o produto com uma longa história, deve funcionar imediatamente em ambientes completamente diferentes. Como resultado, há muitas páginas em nossos guias de instalação. No entanto, o esquema de nível superior é fácil como torta, você deve:
- Aplique o esquema do banco de dados.
- Prepare a configuração do servidor de aplicativos.
- Instale sua licença.
- Inicialize o aplicativo.
Infelizmente, o mundo é cruel, havia alguns pré-requisitos importantes.
- Poderíamos criar o aplicativo apenas em um escravo Jenkins especial, devido a restrições de segurança
- Não houve acesso da instalação Openshift do cliente ao registro do docker dos desenvolvedores privados.
- Não foi possível reutilizar as imagens do docker existentes, porque elas foram criadas apenas para desenvolvimento e teste.
- Havia playbooks ansible para implantação de aplicativos em VMs.
Demonstração Ansible-Container
O Ansible Container é um projeto de código aberto que visa permitir a automação de todo o processo de criação, implantação e gerenciamento de contêineres. O melhor de tudo é que ele usa a mesma linguagem de automação Ansible simples, poderosa e sem agente que você já está usando, garantindo a automatização de todo o ciclo de vida do aplicativo.
Já tínhamos escrito algumas funções do Ansible para instalar o aplicativo nas VMs, então as reutilizamos com o ansible-container . O container Ansible é um conjunto de ferramentas para a construção de containers. Não tenho certeza se é realmente um bom conjunto de ferramentas, no entanto, permite:
- Crie contêineres da mesma maneira que implantamos nossos servidores.
- Pare de encadear comandos de shell nos Dockerfiles.
Não houve grande problema com o ansible-container porque o Openshift, criando linhas de guia de imagens, é incrível. No entanto, gostaria de observar:
- Nós modificamos nossos papéis ansíveis, porque
Docker + systemd = pain . - Não há capacidade de usar chroot, sudo dentro do Openshift por padrão, devido à segurança. Basta ler CVE-2019-5736 .
- Por motivos de segurança, o Openshift como padrão também gera UID aleatório para cada contêiner, ou seja, o openshift ignora a opção USER de um Dockerfile.
O ponto principal é que o ansible-container nos ajudou a criar uma demonstração muito rapidamente, por causa da reutilização.
Demonstração de vários contêineres
O primeiro contêiner de demonstração foi construído via ansible-container. Foi bom o suficiente para a demonstração, no entanto, decidimos não usá-la. Dividimos o contêiner de monólito em diferentes:
- Utilizamos o contêiner Openshift PostgreSQL original sem nenhuma modificação.
- Criamos o contêiner sem estado de aplicativo.
No entanto, não estava claro para inicializar o banco de dados? Encontramos um ótimo artigo sobre a vida dos PODs dentro dos kubernetes. Então, decidimos usar o container init para a inicialização do banco de dados.
Inicialize o aplicativo
Como mencionei antes, o aplicativo deve funcionar imediatamente em ambientes completamente diferentes, oferecer suporte a diferentes servidores / bancos de dados de aplicativos e interfaces de integração com sistemas de terceiros.
Existem várias maneiras de inicializar o aplicativo:
- Passe a configuração através de variáveis de ambiente. Isso significa adicionar toda a nossa documentação / conhecimento sobre como inicializar o aplicativo para cada caso de uso em cada contêiner. Não parece bom.
- Use o gancho de início, este é aproximadamente o mesmo que o primeiro.
- Inicialize durante a provisão para Openshift.
- Use um contêiner externo com configuração individual para cada caso de uso.
Escolhemos o último, criamos um controlador de replicação adicional para inicializar o aplicativo? Sério?
Lemos a documentação novamente.
Um pod (como em um pod de baleias ou de ervilha) é um grupo de um ou mais contêineres (como contêineres do Docker), com armazenamento / rede compartilhada e uma especificação de como executá-los.
POD é um grupo de contêineres. Como resultado, decidimos executar 3 contêineres em um aplicativo POD
- Contêiner de inicialização para uma inicialização do PostgreSQL.
- O contêiner do aplicativo.
- Contêiner de inicialização do aplicativo.
Essa abordagem permite armazenar nossa configuração como um código, existem dois resultados interessantes: a configuração do aplicativo é testável e reproduzível.
Já existe muito para gerenciar o openshift.
Durante a migração, testei alguns deles. Eu gostaria de compartilhar meus resultados.
Modelos Openshift
Modelos Openshift
Prós:
- Nativo Tem documentação incrível.
Contras:
- Ainda outros modelos YAML.
- Registre um arquivo YAML horrível.
- Você se importa com dependências de serviços.
Scripts e modelo
Prós:
Contras:
Terraform k8s provider
Prós:
- Não se preocupe em criar ordem.
- Reutilize o código como módulos.
- Você pode adicionar lógica de inicialização.
Contras:
- Sem suporte Openshift, apenas k8s.
- Às vezes desatualizado.
- Mais uma ferramenta.
Recipiente Ansible
Recipiente Ansible
Prós:
- Faça CM, sem festança
- Reutilize as funções existentes. papel = imagem.
- Um conjunto de ferramentas para tudo.
Contras:
- Imagens enormes, devido a uma única camada.
- Parece abandonado e desatualizado.
O recipiente Ansible foi substituído pelo dobrador Ansible .
Módulo k8s Ansible
Módulo Ansible + k8s
Prós:
- Manual único para todos.
- Reutilize o código como funções.
- Você pode adicionar lógica de inicialização.
Contras:
- Sem suporte a proxy.
- Você se preocupa em remover. Se você deseja remover algo, deve declarar.
- Você se preocupa em criar ordem. Você deve implantar o aplicativo antes da inicialização.
Pacote de playbook Ansible
Ansible Playbook Bundle (APB) é uma definição de aplicativo leve (meta-container). Eles são usados para definir e implantar grupos complexos de aplicativos, configurações de implantação, implantações e serviços em um cluster do OpenShift Origin executando o Ansible Service Broker. Os APBs oferecem mais potência e configuração simples, aproveitando o poder do Ansible. Os APBs têm os seguintes recursos:
A idéia principal é que você empacote todas as coisas necessárias em um contêiner e execute o contêiner dentro do Openshift. Pacote de playbook Ansible
Prós:
- Empacota tudo.
- Testável e reproduzível.
- Integração de catálogo de serviços.
Contras:
- Você precisa de permissões de administrador.
- A documentação às vezes está desatualizada.
Resultado
Por um lado, não quero ser a autoridade final, mas, por outro, gostaria de compartilhar meu ponto de vista. Não existe uma bala de prata.
PS