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.
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!
Top comments (5)
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.
Ó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?
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.
Obrigado pela informação, @dhayllin !!
Muito bom o artigo e esclarecedor 🎉