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"

}

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

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.