Acompanhe online o evento final da Maratona Behind the Code 2020 Inscreva-se já!

Execute o GitLab no Kubernetes

Apresentação

Os containers são uma forte tendência na implementação de aplicativos, em clouds públicas e particulares. A recente adoção generalizada de containers se deve, em grande parte, ao desenvolvimento de normas destinadas a facilitar seu uso, como, por exemplo, o modelo de distribuição e o formato de imagem Docker. Um dos principais casos de uso dos containers é a possibilidade de migrar aplicativos legados para plataformas de orquestração de containers como o Kubernetes, o que permite distribuição, ajuste de escala e manutenção superiores.

Descrição

Este aplicativo mostra a força dos containers e como migrar, de modo contínuo, aplicativos existentes para a cloud. Fornecemos um roteiro completo para desenvolvedores, ajudando-os a migrar seus aplicativos para a cloud e a aproveitar o empacotamento nativo na cloud com o uso de containers. Mostramos como um aplicativo comum com vários componentes pode ser implementado no IBM Cloud Container Service utilizando o Kubernetes.

O GitLab representa um aplicativo típico de multicamada; cada componente terá seus próprios containers. Os containers de microsserviços serão para a camada da web, enquanto o banco de dados de estado/tarefa será com Redis e PostgreSQL como banco de dados.

Fluxo

Fluxograma das etapas para criação do app

  1. O usuário interage com o GitLab pela interface da web, ou enviando um código por push para um repositório do GitHub. O container do GitLab executa o aplicativo principal Ruby on Rails atrás do NGINX e do workhorse do GitLab, que é um proxy reverso para grandes solicitações de HTTP, como downloads de arquivos e push/pull de Git. Enquanto atende repositórios por HTTP/HTTPS, o GitLab utiliza a API GitLab para resolver a autorização e o acesso, além de atender objetos Git.
  2. Após a autenticação e a autorização, o aplicativo GitLab Rails coloca as tarefas recebidas, suas informações e os metadados na fila de tarefas do Redis, que funciona como um banco de dados não persistente.
  3. Os repositórios são criados em um sistema de arquivos local.
  4. O usuário cria usuários, funções, solicitações de mesclagem, grupos e muito mais. Em seguida, tudo é armazenado em PostgreSQL.
  5. Para acessar o repositório, o usuário entra por meio do shell Git.

Instruções

Pronto para colocar esse padrão de código em uso? Detalhe completo em como começar a rodar e usar essa aplicação estão em README.

Aviso

O conteúdo aqui presente foi traduzido da página IBM Developer US. Caso haja qualquer divergência de texto e/ou versões, consulte o conteúdo original.