DEV Community

Cover image for Porque as pessoas estão desenvolvendo dentro de containers?
Pachi 🥑 for GitHub

Posted on

Porque as pessoas estão desenvolvendo dentro de containers?

Esse artigo foi escrito com base no artigo Why are people developing inside containers? Escrito pela minha colega de trabalho Rizèl Scarlett. Se você consome conteúdo em inglês, super recomendo que siga ela!

Nove anos atrás, em março de 2013, Solomon Hykes e seus co-fundadores revolucionaram a forma como desenvolvemos software com uma plataforma Open Source chamada Docker. Embora os criadores do Docker não tenham inventado os contêineres, ou containers, eles os popularizaram.

Graças ao Docker, pessoas engenheiras podem criar ferramentas, como GitHub Codespaces, que nos permitem codar em um container de desenvolvimento hospedado na nuvem.

Eu admito para vocês que, até hoje o tópico de containers me gera várias dúvidas, como:

  • Por que as pessoas estão desenvolvendo dentro de containers?

  • O que são containers?

Se você tem dúvidas semelhantes, este post é para você, vamos aprender juntes!

Neste post, explicarei o que são containers, como eles beneficiam o desenvolvimento e como configurar devcontainers no GitHub Codespaces.

P.S. Eu estarei usando a palavra containers, em inglês, para facilitar a busca por palavra chave, mas também é normal usar a palavra em português contêineres, que inclusive é a que usam na localização das documentações do Kubernetes em ptbr, aprendi isso no twitter, obrigada Flávio.

O que significa desenvolver dentro de um container?

Levanta a mão aí quem já falou (ou pensou): "Funciona no meu PC" o/

Se você não conhece esse meme, saiba que essa frase não virou um meme a toa. Nós, tecnologistas, nos pegamos dizendo isso com certa frequência quando trabalhamos com uma base de código em que os ambientes variam.

Embora trabalhar em ambientes variados não seja o ideal, isso acontece. Situações como essa ocorrem quando seu ambiente local, os ambientes locais de colegas de trabalho, staging e a produção têm pequenas diferenças.

Como os ambientes têm configurações diferentes (mesmo que com pequenas diferenças), os bugs existiam em um ambiente, mas não no outro. Pode ser muito embaraçoso e frustrante criar uma feature ou corrigir um bug que funciona localmente, mas não funciona na produção ou no teste.

E é aqui que entram os containers! Para resolver o problema de inconsistência de ambientes de desenvolvimento.

Os containers permitem que pessoas engenheiras de software programem em um ambiente consistente. Agora, seu ambiente de programação pode espelhar a produção usando o mesmo sistema operacional, configurações e dependências. Isso garante que bugs e recursos se comportem da mesma forma em todos os ambientes, nos salvando da vergonha de ter que dizer "Funciona na minha máquina".

Agora que entendemos o propósito dos containers, vamos explorar como o Codespaces aproveita os containers.

GitHub Codespaces leva software e desenvolvimento em nuvem para o próximo level

O GitHub Codespaces permite codar em um container hospedado na nuvem. Nesse contexto, a nuvem é um ambiente que não reside no seu computador, mas sim na internet.

Onboardings mais rápidos

Normalmente, as pessoas programadoras são responsáveis ​​por configurar seu ambiente local quando ingressam em uma equipe. A configuração do ambiente local inclui a instalação das dependências necessárias, linters, variáveis ​​de ambiente e muito mais.

É normal gastarmos até uma semana configurando nosso ambiente, dependendo da qualidade da documentação. Essa experiência é chata, porque quando a gente começa um projeto novo a gente quer codar logo! Mas em vez disso, temos que alimentar nosso banco de dados e editar arquivos .zshrc, dentre outras coisas.

Felizmente, empresas podem automatizar o processo de integração usando GitHub Codespaces para configurar um ambiente personalizado. Quando uma nova pessoa entra na equipe, ela pode abrir um codespace e pular a configuração do ambiente local porque as extensões, dependências e variáveis ​​de ambiente necessárias existem no codespace.

Code de qualquer lugar

E não estou falando apenas de qualquer lugar, geograficamente falando, mas também de qualquer máquina.

Com Codespaces, posso codar em qualquer lugar que tenha acesso à Internet, notebook ou tablet, meu ou emprestado da coleguinha .

Se eu trocar de dispositivo ou esquecer meu laptop em casa, posso facilmente retomar meu trabalho em um iPad enquanto estou no avião sem clonar um repositório, baixar meu IDE preferido e configurar um ambiente local. Isso é possível porque o Codespaces abre um editor semelhante ao Visual Studio Code dentro do navegador.

A melhor parte é que os Codespaces podem salvar automaticamente o meu código, mesmo que eu esqueça de enviar minhas alterações para meu repositório (Não que eu já tenha perdido código por esquecer de salvar…)

Ambientes consistentes

Conforme mencionado acima, os containers permitem que você trabalhe em um ambiente de produção espelhado. Como o GitHub Codespaces usa containers, você pode obter os mesmos resultados e experiência de desenvolvevimento em seu ambiente local que obteria em seu ambiente de produção.

Além disso, às vezes, quando ocorrem alterações na base de código, como aprimoramentos de infraestrutura, os ambientes locais podem ser interrompidos. Quando os ambientes locais quebram, cabe a pessoa desenvolvedora restaurar seu ambiente de desenvolvimento. No entanto, o uso de containers do GitHub Codespaces traz uniformidade aos ambientes e reduz as chances de trabalhar em um ambiente quebrado.

Três arquivos que você precisa configurar no Codespaces

Você pode aproveitar três arquivos para fazer com que a experiência do Codespaces funcione para você e sua equipe: o arquivo devcontainer.json, o Dockerfile e o arquivo docker-compose.yml.

Cada um desses arquivos reside no diretório.devcontainer na raiz do seu repositório.

Devcontainer.json

O arquivo devcontainer.json é um arquivo de configuração que informa ao GitHub Codespaces como configurar um codespace. Dentro de um arquivo devcontainer, você pode configurar o seguinte:

  • Extensões

  • Variáveis ​​de ambiente

  • Dockerfile

  • Encaminhamento de Port

  • Comandos pós-criação

  • E mais…

Isso significa que sempre que você ou alguém abrir um codepspace, as extensões, variáveis ​​de ambiente e outras configurações especificadas no arquivo devcontainer.json serão instaladas automaticamente quando abrirem um codespace no repositório especificado.

Por exemplo, se eu quisesse que as pessoas tivessem o mesmo linter e as mesmas extensões que eu, poderia adicionar o seguinte ao meu arquivo devcontainer.json:

{

"name":  "Node.js",

"build":  {

"dockerfile":  "Dockerfile",

//  Update  'VARIANT'  to  pick  a  Node  version:  18,  16,  14.

//  Append  -bullseye  or  -buster  to  pin  to  an  OS  version.

//  Use  -bullseye  variants  on  local  arm64/Apple  Silicon.

"args":  {  "VARIANT":  "16-bullseye"  }

},



//  Configure  tool-specific  properties.

"customizations":  {

//  Configure  properties  specific  to  VS  Code.

"vscode":  {

//  Add  the  IDs  of  extensions  you  want  installed  when  the  container  is  created.

"extensions":  [

"dbaeumer.vscode-eslint",  //  this  is  the  exentension  id  for  eslint

"esbenp.prettier-vscode",  //  this  is  the  extension  id  for  prettier

"ms-vsliveshare.vsliveshare",  //  this  is  the  extension  id  for  live  share

]

}

},



//  Use  'forwardPorts'  to  make  a  list  of  ports  inside  the  container  available  locally.

//  "forwardPorts":  [],



//  Use  'postCreateCommand'  to  run  commands  after  the  container  is  created.

//  "postCreateCommand":  "yarn  install",



//  Comment  out  to  connect  as  root  instead.  More  info:  https://aka.ms/vscode-remote/containers/non-root.

"remoteUser":  "node"

}

Enter fullscreen mode Exit fullscreen mode

Você pode aprender mais sobre o devcontainer.json aqui.

Dockerfile

O Dockerfile é um arquivo de configuração que informa ao GitHub Codespaces como construir um container. Ele contém uma lista de comandos que o cliente Docker chama ao criar uma imagem. Dockerfiles são usados ​​para automatizar a instalação e configuração de um conainer. Por exemplo, se eu quisesse instalar o Node.js em um container, poderia adicionar o seguinte ao meu Dockerfile:

FROM node:16-bullseye

Você pode aprender mais sobre Dockerfiles aqui.

Docker-compose.yml

Você não precisa de um arquivo docker-compose.yml em um Codespace, mas é útil se você deseja executar vários containers.

Por exemplo, se você deseja executar um banco de dados e um servidor da Web em um Codespace, pode usar o arquivo docker-compose.yml para executar os dois containers.

Aqui está um exemplo de como pode ser um arquivo docker-compose.yml que está se conectando a um banco de dados:

version:  '3.8'



services:

app:

build:

context:  ..

dockerfile:  .devcontainer/Dockerfile

args:

VARIANT:  "3"

NODE_VERSION:  "none"



volumes:

-  ..:/workspace:cached



command:  sleep  infinity



network_mode:  service:db



db:

image:  postgres:latest

restart:  unless-stopped

volumes:

-  postgres-data:/var/lib/postgresql/data

hostname:  postgres

environment:

POSTGRES_DB:  my_media

POSTGRES_USER:  example

POSTGRES_PASSWORD:  pass

POSTGRES_HOST_AUTH_METHOD:  trust

ports:

-  5432:5432



volumes:

postgres-data:  null
Enter fullscreen mode Exit fullscreen mode

O Codespaces não é a mesma coisa que o editor de web do Github

O GitHub Codespaces não é o mesmo que o editor web do GitHub.

O editor web é aquele editor mágico que aparece quando você pressiona "." em um repositório (Se você nunca fez isso, vai fazer AGORA, eu espero…).

Esse é um editor leve que permite editar arquivos em seu repositório. O editor da Web é ótimo para fazer pequenas alterações em um arquivo, mas não é ideal para escrever e executar aplicativos da Web Full-Stack.
Isso porque o editor da web do GitHub não possui um terminal.
No entanto, o Codespaces permite que você execute um IDE completo no navegador equipado com um terminal e muito mais.

Chegou a hora da revisão

Nesse artigo aprendemos o que é um container e porque as pessoas usam eles! Ebaaa!
De brinde ainda aprendemos mais sobre o GitHub Codespaces!

Espero que você, assim como eu, tenha aprendido algo novo hoj!

Obrigada por ler até final e sigam o GitHub Brasil das redes sociais para ficar por dentro de novidades <3

GitHub Brasil Twitter 🐦

GitHub Brasil no LinkedIn 📝

GitHub Brasil na Twitch 🟣

Meet-ups do GitHub em português🗣️

Oldest comments (5)

Collapse
 
brmartin profile image
brmartin | Bruno Martins

Ótimo conteúdo e realmente esclarecedor para, pessoas como eu, novatas nesse assunto. Uma pergunta:: sei que o post é pro GitHub, mas que outra ferramenta se assemelha ao Codespaces?

Collapse
 
dhayllin profile image
Dhayllin Jesus

Existe o aws cloud9, diferente do github ele não tem opção free. A vantagem dele é quando se trabalha com serviceless na aws . É bem mais robostudo que o codespace mais pelo tempo de maturidade, tem muito tempo que foi lançado.

Collapse
 
brmartin profile image
brmartin | Bruno Martins

Obrigado pela informação, @dhayllin !!

Collapse
 
dhayllin profile image
Dhayllin Jesus

Muito bom o artigo e esclarecedor 🎉

Collapse
 
eduardoklosowski profile image
Eduardo Klosowski

Eu já trabalhei em uma empresa que as pessoas tinham medo de pegar um contêiner de um computador e ele não funcionar em outro, e eles tinham seus motivos racionais para isso. Assim como também é possível pegar algo fora de contêineres, colocar em outro ambiente diferente e funcionar. Mesmo trabalhando com contêineres, existe a possibilidade de "na minha máquina funciona", porém seguindo boas práticas (o que muitas vezes não ocorre, já vi empresa que fazia exatamente o oposto de uma lista de 10 boas práticas divulgadas pela RedHat), a probabilidade de funcionar com contêineres tende a ser maior do que quando não se usa.

Outro ponto interessante sobre contêiner é o isolamento. Se eu tiver um servidor com Debian stable, eu prefiro criar/usar aplicações em cima de contêineres baseado em Debian stable do que instalar as coisas diretamente no servidor, isso pelas facilidades de remover as aplicações sem deixar sujeira. Inclusive eu tenho imagens docker de LaTeX e Wine para não precisar ter eles instalados no meu sistema.

Um terceiro ponto é que vejo que ambientes de desenvolvimento diversificado podem ser interessantes. Trabalhei num lugar que desenvolvia um sistema para instalar nos clientes, e alguns clientes tinham o banco de dados em PostgreSQL, outros em SQL Server, Oracle. Como cada desenvolvedor usava em banco diferente na sua máquina, isso ajudava a testar e evitar "no cliente não funcionou" por ele usar um banco diferente.