Giters

Alexrm86 / Projeto-teste-comando-Docker

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Boas-vindas ao repositório do projeto Docker Todo List!

Aqui você vai encontrar os detalhes de como estruturar o desenvolvimento do seu projeto a partir deste repositório, utilizando uma branch específica e um Pull Request para colocar seus códigos.

👨‍💻 O que deverá ser desenvolvido

Neste projeto você irá:

  1. Conteinerizar aplicações;
  2. Criar uma conexão entre elas;
  3. Orquestrar seu funcionamento.

Temos uma aplicação full-stack neste repositório: um aplicativo de tarefas! Esta aplicação precisa ser conteinerizada para funcionar. Você deverá desenvolver os arquivos de configuração para cada frente específica: Front-end, Back-end e, no nosso caso, para um aplicativo de teste que valida se as aplicações estão se comunicando.

Você deverá criar as imagens para as aplicações e configurar essas imagens com o docker-compose.

Para isto, você irá utilizar uma série de comandos do docker com diferentes níveis de complexidade.

Cada comando deverá ser escrito em seu próprio arquivo.

Para isto, siga os seguintes passos:

  1. Leia o requisito e crie um arquivo chamado commandN.dc no diretório docker-commands, onde N é o número do requisito. Por exemplo:

    Requisito 1: ./docker/docker-commands/command01.dc
Requisito 2: ./docker/docker-commands/command02.dc
Requisito 3: ./docker/docker-commands/command03.dc

    ⚠️ É muito importante que os seus arquivos tenham exatamente estes nomes! ⚠️

  2. Escreva neste arquivo o comando do CLI (Interface de Linha de Comando) do Docker que resolve o requisito. Um exemplo de como vai ficar seu arquivo:

    docker network inspect bridge

Os arquivos principais do projeto estão na pasta docker, na raiz do projeto. Nela estão contidos:

  1. Pasta docker-commands: onde ficarão os comandos exigidos pelos requisitos;
    • ⚠️ Importante: você deve assumir que essa é a pasta raiz para os comandos.
    • Por exemplo, se você precisa referenciar um caminho em um comando, você deve assumir que sua pasta raiz esta partindo de ./docker.
  2. Pasta todo-app: onde fica a nossa pseudo-aplicação, que servirá como base para nossos Dockerfiles e Compose;
    • ⚠️ Essa aplicação conta com um README.md próprio, que pode ser usado como referência na criação dos dockerfiles e do docker-compose.yml!

Quando for necessário fazer a orquestração das aplicações, o arquivo docker-compose.yml deverá ser criado na pasta ./docker. conforme o arquivo de exemplo docker/docker-compose.yml.example.

Orientações

📋︎ Sobre o avaliador

⚠️ Importante: ⚠️

Para que o avaliador funcione corretamente é importante que a instalação do 
Docker (vista no dia 1) seja feita corretamente.

Aqui também é importante que o seu usuário esteja no grupo `docker` (para que 
não haja a necessidade de rodar comandos utilizando o `sudo`)

O avaliador cria um container especial para executar a avaliação de comandos, Dockerfiles e docker-compose.

Esse container é temporário, portanto, ao começar ou terminar os testes locais, o avaliador remove automaticamente esse mesmo container, assim como seu volume associado.

O volume desse container mapeia a pasta ./docker/ do seu projeto, para dentro dele, ou seja, a raiz desse container vai conter as pastas ./docker-commands/, ./todo-app/ e seu arquivo ./docker-compose.yml quando estiver pronto.

Isso significa que, se pudéssemos olhar para dentro do container de avaliação, veríamos a seguinte estrutura:

.
├── docker-commands
└── todo-app
    ├── back-end
    │   └── *
    ├── front-end
    │   └── *
    └── tests
        └── *

Portanto, é importante entender que os comandos docker escritos em command*.dc estarão rodando dentro desse container especial (e não a partir da raiz do projeto, como em projetos anteriores).

⌨️ Durante o desenvolvimento
  • ⚠ PULL REQUESTS COM ISSUES NO DOCKERFILE-LINTER NÃO SERÃO AVALIADOS. É PRECISO RESOLVÊ-LAS ANTES DE FINALIZAR O DESENVOLVIMENTO! ⚠

⚠️ Importante:

Esse projeto tem como intuito te treinar para ter mais familiaridade com a documentação de aplicações, portanto, poderão haver alguns comandos ou atributos que não estão no course, mas que devem ser descritos no decorrer dos requisitos.

Nesses casos, é importante se atentar àquilo que o requisito pede e lembrar sempre de utilizar a documentação oficial do Docker para pesquisar detalhes sobre comandos.

Ao criar um Dockerfile para o nosso pseudo-aplicativo, seu README (./docker/tests/README.md) deve servir como "tradutor" para os passos de execução. Lembre-se de que o Dockerfile é como uma receita para execução dessas aplicações.

Aqui, também é importante a utilização do comando --help no CLI (docker <comando> <subcomando> --help), dado que para cada comando do docker, é possível aplicar subcomandos ou parâmetros, exemplo: docker network --help

🛠 Testes

⚠ É necessário ter o Docker instalado corretamente na sua máquina para rodar os testes locais.

Todos os requisitos do projeto serão testados automaticamente por meio do Jest. Basta executar o comando abaixo:

npm test

Você pode rodar um arquivo de test por vez, exemplo:

npm test 01container

⚠ Atenção: ⚠ Não utilize a função .only ou .skip após o describe. Os testes precisam rodar por completo para que o projeto seja avaliado localmente.

🗣 Nos dê feedbacks sobre o projeto!

Requisitos obrigatórios do projeto

Comandos docker

⚠ Lembre-se das instruções da seção Entregáveis, especialmente no tópico O que deverá ser desenvolvido!

1. Crie um container em modo interativo, sem rodá-lo, nomeando-o como 01container e utilizando a imagem alpine na versão 3.12

➕ Informações adicionais

O avaliador executará o comando no arquivo command01.dc.

Observações técnicas

  • O container não deve ser inicializado, somente criado;
  • O container deve estar preparado para acesso interativo.

Dicas

  • Dê uma olhada no comando create. 😉
  • Lembre-se que um parâmetro não é necessariamente aplicável a apenas um comando;
  • Consulte sempre que possível a Documentação Oficial sobre comandos básicos;
  • Lembre-se que a esmagadora parte dos comandos docker recebe parâmetros (opções), como nesse exemplo.

O que será testado

  • O nome do container deve ser 01container;
  • O container deve usar a imagem alpine na versão 3.12;
  • O status do container deve ser created;
  • O container não deve estar em execução após ter sido criado.

2. Inicie o container 01container

➕ Informações adicionais

O avaliador executará o comando no arquivo command02.dc.

Observações técnicas

  • O container 01container, que acabou de ser criado e está parado, deve ser iniciado;
  • Se o container tiver sido iniciado de modo interativo, ele deve se manter ativo ao iniciá-lo.

O que será testado

  • O avaliador verificará se o container está parado;
  • O avaliador executará o comando criado neste requisito;
  • O container deve estar em execução.

3. Liste os containers filtrando pelo nome 01container

➕ Informações adicionais

O avaliador executará o comando no arquivo command03.dc.

Dicas

  • Praticamente todo comando de listagem no Docker possui uma forma de filtragem.

O que será testado

  • O comando deve retornar uma lista contendo informações apenas do 01container.

4. Execute o comando cat /etc/os-release no container 01container sem se acoplar a ele

➕ Informações adicionais

O avaliador executará o comando no arquivo command04.dc.

Observações técnicas

  • O container deve estar rodando e você deve ser capaz de executar um comando nesse container.

Dicas

  • É possível fazer isso sem usar o comando attach.

O que será testado

  • Que o comando retornará os dados corretos da distro no container:
    • NAME="Alpine Linux"
    • ID=alpine
    • VERSION_ID=3.12

5. Remova o container 01container

➕ Informações adicionais

O avaliador executará os comandos nos arquivos command05.dc e command03.dc.

O que será testado

  • O avaliador rodará o comando 5;
  • O avaliador validará o processo com o comando 3.

6. Faça o download da imagem nginx com a versão 1.21.3-alpine sem criar ou rodar um container

➕ Informações adicionais

O avaliador executará o comando no arquivo command06.dc.

O que será testado

  • Que a imagem correta foi baixada;
  • Que nenhum container foi iniciado para isso.

7. Rode um novo container com a imagem nginx com a versão 1.21.3-alpine em segundo plano nomeando-o como 02images e mapeando sua porta padrão de acesso para porta 3000 do sistema hospedeiro

➕ Informações adicionais

O avaliador executará o comando no arquivo command07.dc.

O que será testado

  • Que o container foi iniciado corretamente;
  • Que é possível ter acesso ao container pelo endereço localhost:3000;
  • Que a página retorna o valor esperado.

8. Pare o container 02images que está em andamento

➕ Informações adicionais

O avaliador executará o comando no arquivo command08.dc.

O que será testado

  • Que não há nenhum container ativo após seu comando.

Dockerfile

⚠️ As aplicações a seguir contam com um README.md próprio, que deve ser usado como referência na criação dos scripts!

9. Gere uma build a partir do Dockerfile do back-end do todo-app nomeando a imagem para todobackend

Escreva no arquivo command09.dc um comando que fará o build(documentação do comando) de uma imagem a partir do arquivo ./docker/todo-app/back-end/Dockerfile, esta imagem deve ter o nome todobackend.

No arquivo ./docker/todo-app/back-end/Dockerfile escreva os comandos que farão com que a imagem:

  • rode a partir da imagem do node na versão 14;
  • exponha a porta 3001;
  • adicione o arquivo node_modules.tar.gz à imagem;
  • copie todos os arquivos da pasta back-end para a imagem. (você pode usar o caminho relativo, lembrando que a Dockerfile está em ./docker/todo-app/back-end/Dockerfile);
  • inicie a aplicação com o comando npm start.
➕ Informações adicionais
  • Nesse contexto, deve-se criar um arquivo Dockerfile na pasta ./docker/todo-app/back-end/, que será utilizado com comando exigido no requisito;
  • Esse arquivo deve buscar reproduzir as etapas de back-end contidas no README.md da pseudo-aplicação (também estão descritas na seção O que será testado, do requisito) para que ele rode corretamente;
  • O avaliador executará o comando no arquivo command09.dc.

Dicas

  • O comando ADD do Dockerfile, também pode ser utilizado para descompactar arquivos dentro do container.
    • Entenda a diferença entre o comando ADD e COPY neste artigo.

O que será testado

  • Se existe um arquivo Dockerfile em ./docker/todo-app/back-end/:
    • O Dockerfile deve rodar uma imagem node utilizando a versão 14;
      • Recomenda-se o uso da variante -alpine, pois ela é otimizada para desempenho;
      • Lembre-se de consultar o README do todo-app para validar os requisitos da aplicação.
    • Deve estar com a porta 3001 exposta;
    • Deve adicionar o arquivo node_modules.tar.gz a imagem;
    • Deve copiar todos os arquivos da pasta back-end para a imagem;
    • Ao iniciar a imagem deve rodar o comando npm start.
  • Se ao buildar o Dockerfile o nome da imagem gerada é igual a todobackend.

10. Gere uma build a partir do Dockerfile do front-end do todo-app nomeando a imagem para todofrontend

Escreva no arquivo command10.dc um comando que fará o build(documentação do comando) de uma imagem a partir do arquivo ./docker/todo-app/front-end/Dockerfile, esta imagem deve ter o nome todofrontend.

No arquivo ./docker/todo-app/front-end/Dockerfile escreva os comandos que farão com que a imagem:

  • rode a partir da imagem do node na versão 14;
  • exponha a porta 3000;
  • adicione o arquivo node_modules.tar.gz à imagem;
  • copie todos os arquivos da pasta front-end para a imagem. (você pode usar o caminho relativo, lembrando que a Dockerfile está em ./docker/todo-app/front-end/Dockerfile);
  • inicie a aplicação com o comando npm start.
➕ Informações adicionais
  • Nesse contexto, deve-se criar um arquivo Dockerfile na pasta ./docker/todo-app/back-end/, que será utilizado com comando exigido no requisito;
  • Esse arquivo deve buscar reproduzir as etapas de front-end contidas no README.md da pseudo-aplicação (também estão descritas na seção O que será testado, do requisito) para que ele rode corretamente;
  • O avaliador executará o comando no arquivo command10.dc.

Dicas

  • O comando ADD do Dockerfile, também pode ser utilizado para descompactar arquivos dentro do container.
    • Entenda a diferença entre o comando ADD e COPY neste artigo.

O que será testado

  • Se existe um arquivo Dockerfile em ./docker/todo-app/front-end/:
    • O Dockerfile pode rodar uma imagem node utilizando a versão 14;
      • Recomenda-se o uso da variante -alpine, pois ela é otimizada para desempenho;
      • Lembre-se de consultar o README do todo-app para validar os requisitos da aplicação.
    • Deve estar com a porta 3000 exposta;
    • Deve adicionar o arquivo node_modules.tar.gz a imagem, de maneira que ele seja extraído dentro do container;
    • Deve copiar todos os arquivos da pasta front-end para a imagem;
    • Ao iniciar a imagem deve rodar o comando npm start;
  • Se ao buildar o Dockerfile o nome da imagem gerada é igual a todofrontend.

11. Gere uma build a partir do Dockerfile dos testes do todo-app nomeando a imagem para todotests

Escreva no arquivo command11.dc um comando que fará o build(documentação do comando) de uma imagem a partir do arquivo ./docker/todo-app/tests/Dockerfile, esta imagem deve ter o nome todotests.

No arquivo ./docker/todo-app/tests/Dockerfile escreva os comandos que farão com que a imagem:

  • rode a partir da imagem do mjgargani/puppeteer:trybe1.0;
  • adicione o arquivo node_modules.tar.gz à imagem;
  • copie todos os arquivos da pasta tests para a imagem. (você pode usar o caminho relativo, lembrando que a Dockerfile está em ./docker/todo-app/tests/Dockerfile);
  • inicie os testes com o comando npm test.
➕ Informações adicionais
  • Nesse contexto, deve-se criar um arquivo Dockerfile na pasta ./docker/todo-app/back-end/, que será utilizado com comando exigido no requisito;
  • Esse arquivo deve buscar reproduzir as etapas de testes contidas no README.md da pseudo-aplicação (também estão descritas na seção O que será testado, do requisito) para que ele rode corretamente;
  • O avaliador executará o comando no arquivo command11.dc.

Dicas

  • O comando ADD do Dockerfile, também pode ser utilizado para descompactar arquivos dentro do container.
    • Entenda a diferença entre o comando ADD e COPY neste artigo.

Observações técnicas

  • A aplicação todotests só funciona corretamente se estiver dockerizada e dentro de uma rede docker configurada corretamente.

O que será testado

  • Se existe um arquivo Dockerfile em ./docker/todo-app/tests/:
    • O Dockerfile deve rodar a imagem mjgargani/puppeteer:trybe1.0 para que os testes funcionem;
    • Deve adicionar o arquivo node_modules.tar.gz a imagem;
    • Deve copiar todos os arquivos da pasta tests para a imagem;
    • Ao iniciar a imagem deve rodar o comando npm test;
  • Se ao buildar o Dockerfile o nome da imagem gerada é igual a todotests.

Requisito bônus do projeto

Docker-compose

12. Suba uma orquestração em segundo plano com o docker-compose de forma que backend, frontend e tests consigam se comunicar

➕ Informações adicionais

O avaliador executará o comando no arquivo command12.dc. Este comando pressupõe a existência do arquivo ./docker/docker-compose.yml.

O docker-compose deve rodar na versão 3 ou superior.

Dicas

  • Use as imagens já "buildadas" que foram executadas nos requisitos 9, 10 e 11 para a criação do compose;
  • Consulte a documentação em ./docker/todo-app/README.md;
  • É possível adicionar e extrair arquivos .tar.gz no Dockerfile com apenas um comando.

O que será testado

tests
  • O container de todotests deve ter como dependencia os containers frontend e backend;
  • O nome do service deverá ser todotests;
  • Deve ter uma variável de ambiente FRONT_HOST que recebe como valor o nome do container do frontend
    • Lembrando que, dentro de uma rede docker, o host de um container é indentificado pelo seu nome.
front-end
  • O container de todofrontend deve rodar na porta 3000;
  • O nome do service deverá ser todofront;
  • Deve ter como dependencia o container backend;
  • Deve ter uma variável de ambiente REACT_APP_API_HOST que recebe como valor o nome do container do backend.
    • Lembrando que, dentro de uma rede docker, o host de um container é indentificado pelo seu nome.
back-end
  • O container de todobackend deve rodar na porta 3001;
  • O nome do service deverá ser todoback;

About

Languages

Language:JavaScript 90.8%Language:HTML 4.6%Language:CSS 3.5%Language:Dockerfile 1.1%