Quero contar uma história de como o aplicativo foi iniciado no Openshift. Também no decorrer da peça, consideramos utilitários para gerenciar o aplicativo dentro do Openshift. Esta é uma transcrição do desempenho no kubernetes SPB meetup # 3 .
Finalidade
Normalmente, os clientes são implantados em servidores separados, mas aqui veio a tarefa, para testar a oportunidade de executar no openshift e coletar o rake.
Primeiro você precisa falar sobre a nossa aplicação. Um projeto com uma história rica. Usado em grandes organizações e provavelmente cada um de vocês se cruza indiretamente. O aplicativo suporta muitos bancos de dados, integrações, etc., etc.
Pré-requisitos
O aplicativo deve funcionar em ambientes completamente diferentes. Como resultado, nossa documentação de instalação é muito extensa. Mas se você olhar para baixo, não há nada complicado:
- Aplique o esquema do banco de dados.
- Configure o servidor de aplicativos.
- Instale uma licença.
- Personalize o aplicativo e a integração com sistemas externos.
Mas o mundo é cruel, tivemos várias restrições:
- O aplicativo só pode ser criado especificamente no Jenkins, que está envolvido na assinatura. E só lá.
- Não há acesso do cliente Openshift ao ambiente de desenvolvimento.
- Por várias razões ideológicas, não foi possível reutilizar as imagens existentes do Docker para desenvolvimento.
- Temos playbooks ansible para instalar e configurar o aplicativo nos servidores.
Demonstração Ansible-Container
O Ansible Container é um software de código aberto que visa automatizar a montagem, implantação e controle de processos de contêineres. Como você pode imaginar pelo nome. Ansible é usado para construir contêineres. Já escrevemos funções Ansible para instalar e implantar aplicativos em cima de servidores, por isso decidimos não reinventar a roda e reutilizá-los. Não seria apenas a ferramenta perfeita, mas a rápida reutilização de funções existentes foi um fator decisivo para a demonstração.
Em geral, para fazer uma demonstração, pegamos as funções existentes que configuram tudo e tudo e fizemos um "contêiner monolítico". Não houve problemas em particular na coleta do contêiner, pois O Openshift tem ótimas recomendações , mas mencionarei separadamente:
- Os papéis precisavam ser finalizados. nós usamos systemd.
- Por padrão, por razões de segurança, é proibido usar algum syscall no openshift. Como resultado, haverá nuances com chroot, sudo. Olá CVE-2019-5736 .
- Da mesma forma, por motivos de segurança, o contêiner é iniciado sob um usuário com um ID aleatório, esse também é um comportamento personalizado.
A principal idéia neste momento é que fizemos uma demonstração muito rápido.
Demonstração de vários contêineres
O contêiner de demonstração cumpriu seu papel e o dividimos em componentes separados:
- Nossa aplicação.
- O banco de dados
- Serviços externos, etc ...
A primeira coisa que você encontrou, como inicializar o banco de dados? É claro que usamos migrações, mas quando e como aplicá-las? Aqui vale a pena fornecer um link para um artigo maravilhoso que descreve a vida do dispositivo POD: PODs . De um modo geral, existem várias abordagens:
- Use init-container
- Use sistemas de orquestração que determinarão a ordem de implantação dos serviços e rolarão a migração quando necessário.
Decidimos seguir o caminho do contêiner Init. I.e. no POD do nosso aplicativo, antes do início do nosso aplicativo, um contêiner é iniciado que faz migrações. Mas como configurar o próprio aplicativo e integrações externas?
Inicialize o aplicativo
Como já mencionei, nosso aplicativo pode e deve funcionar em ambientes completamente diferentes, com diferentes bancos de dados e integrações. Novamente, a questão é como configurar tudo isso?
- Use sistemas de orquestração que determinam a ordem na qual os serviços são implantados e aplicam a configuração após o início do aplicativo.
- Passe pelas variáveis de ambiente para o contêiner como configurar.
- Use o gancho de partida.
- Faça um contêiner separado que contenha a configuração e aplique-o ao aplicativo. Migração aproximadamente analógica para o banco de dados.
Escolhemos a última abordagem, porque permite que você torne a configuração reproduzível e auto-suficiente. Mas, por alguma razão, inicialmente fizemos esse contêiner em um controlador de replicação separado com um fator 1.
Ok, leia 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, nosso sub consistiu em 3 contêineres
- Container inicial para inicializar um PostgreSQL.
- Recipiente com app.
- Contêiner com configuração de aplicativo.
Toolkit
Temos um diagrama de como o aplicativo implantado se parece. Agora é hora de discutir as ferramentas da natureza, já há muita coisa pronta, vou considerar algumas da lista abaixo e tirar conclusões subjetivas.
Modelos Openshift
Modelos Openshift
Prós:
- Nativo e eles têm excelente documentação.
Contras:
- Outro mecanismo de modelo.
- Arquivos YAML longos e terríveis.
- Se você tiver dependências entre os serviços e sua ordem de início, será difícil.
Scripts e modelo
Prós:
- Você pode usar ótimas ferramentas e todo o poder do OOP.
Contras:
- Muletas que suportam. E não apenas para você.
Terraform k8s provider
Prós:
- Você não se preocupa com a prioridade de criar elementos de infraestrutura.
- Você pode reutilizar o código de infraestrutura como módulos.
- Você pode adicionar lógica de inicialização do aplicativo.
Contras:
- Não há suporte para Openshift, apenas k8s.
- Doca e módulos às vezes desatualizados.
- Outra tula em sua equipe.
Recipiente Ansible
Recipiente Ansible
Prós:
Contras:
- Imagens enormes, porque vá em uma camada.
- Parece abandonado e sem suporte. Foi substituído pelo dobrador Ansible .
Módulo k8s Ansible
Módulo Ansible + k8s
Prós:
- Um manual para descrever todas as infra-estruturas do projeto no Openshift.
- Reutilizando código na forma de funções.
- Você pode adicionar lógica de inicialização do aplicativo.
Contras:
- Sem suporte a proxy.
- Você cuida da remoção. Se o objeto não for mais necessário, descreva sua remoção.
- Você mesmo descreve a sequência de criação de elementos de infraestrutura.
Pacote de playbook Ansible
O utilitário Ansible Playbook Bundle (APB) oferece uma abordagem: vamos agrupar funções possíveis para implantar um aplicativo dentro do k8s / openshift em um contêiner e executar dentro do k8s / openshift.
Prós:
- Eu carrego tudo comigo.
- Testável e reproduzível.
- Integração com o catálogo de serviços (interface da web fácil de usar para iniciar aplicativos).
Contras:
- Você precisa de privilégios de nível de administrador.
- Às vezes, a documentação deixa muito a desejar.
Resultado
Não quero ser o último recurso, mas vou compartilhar minhas conclusões:
PS