“A correção está pronta!” …mas e o deploy?
Três meses depois de entrar na empresa, quando meu período de experiência estava chegando ao fim, recebi pela primeira vez uma tarefa real de trabalho. Era só uma correção bem simples, mas mesmo assim eu estava metade nervoso, metade empolgado, enquanto terminava de ajustar o código e fechar todos os testes na minha própria máquina, no localhost.
“Chefe, todos os testes locais passaram!”
O líder assentiu e mandou fazer o deploy. “Bom trabalho. Agora faz o commit no GitLab, um repositório de código como o GitHub, e depois sobe isso no servidor de produção.”
Deploy? Corri para procurar o documento de passagem de tarefa que recebi no onboarding. Ele estava cheio de termos que eu não conhecia.
Primeiro subi o código do jeito que tinham mandado. Agora faltava só a última etapa: conectar no servidor de produção. Eu realmente comecei a me levantar da cadeira. Como nos dramas, achei que precisaria entrar numa sala de servidores congelante, um IDC, e digitar diretamente em um teclado ligado ao servidor.
Meu sênior viu aquilo e caiu na risada. “Onde você vai? Fica sentado aí e entra por SSH.”
Meu primeiro encontro com uma tela preta
Abri um programa chamado SSH(Secure Shell), digitei o endereço IP e a senha que meu sênior me passou e apertei Enter. Se fosse no Windows, uma área de trabalho colorida teria me recebido. Mas tudo o que apareceu no meu monitor foi um cursor piscando em um fundo completamente preto.
ubuntu@ip-172-31-0-1:~$ _
Não havia ícones para clicar com o mouse nem menu de botão direito para criar uma nova pasta. Em pânico, apertei teclas aleatórias, depois digitei ls, e de repente uma lista de arquivos apareceu em texto puro.
‘Ah, então é isso aquela tal de CLI(Command Line Interface) de que eu só tinha ouvido falar.’
Mas o medo de verdade chegou quando tentei executar um arquivo. Rodei o script update que estava no manual, e aquilo que no Windows seria um simples clique duplo voltou aqui como uma mensagem de erro vermelha.
Permission denied (permissão negada)
Era o meu próprio servidor, e mesmo assim eu não conseguia executar. Por que o Linux era tão pouco amigável?
O estoquista de um centro logístico digital
Vamos voltar para a nossa metáfora do ‘centro logístico digital’. Se o meu notebook com Windows é um escritório particular confortável, então um servidor Linux é um enorme galpão construído apenas para processar logística. Dentro dele existem dezenas de milhares de caixas, ou seja, arquivos.
Se o estoquista precisasse andar até cada caixa para verificar uma por uma, GUI, e abrir cada porta com uma chave, clique por clique, o trabalho seria lento demais. É por isso que o Linux usa um rádio chamado comandos.
“Mostra a lista completa das caixas da área 1!” (ls) “Move a caixa 3 para a área 5!” (mv) “Executa esta caixa!” (./start.sh)
Não é desconfortável porque não há mouse. Os gráficos foram removidos de propósito porque, depois que você se acostuma, consegue controlar milhares de arquivos cem vezes mais rápido do que com um mouse.
[Code Verification] A lei absoluta das permissões
O que mais atormenta quem está começando no Linux é justamente o problema de permissões. No Windows, um clique em ‘Executar como administrador’ resolve quase tudo. Já o Linux verifica com rigor, arquivo por arquivo, quem pode fazer o quê.
Para sobreviver, você precisa saber ler aquele idioma alienígena que aparece com ls -l no terminal.
$ ls -l myscript.sh
-rwxr-xr-- 1 owner group 1024 Jan 1 12:00 myscript.sh
Análise: a parte principal é -rwxr-xr-- logo no começo. Tirando o primeiro -, que indica arquivo, o restante precisa ser lido em grupos de três.
Um script que você escreveu não executa? Em nove de cada dez casos, ele só está sem permissão de execução, x. Nessa hora, iniciantes costumam se frustrar e lançar o feitiço proibido chmod 777.
# O que voce nunca deve fazer
$ chmod 777 myscript.sh
777 significa: “Eu, você e até qualquer cachorro que estiver passando podem modificar e executar este arquivo.” Isso equivale a deixar o portão de segurança completamente escancarado. No trabalho real, isso é absolutamente proibido. Você precisa criar o hábito de conceder apenas as permissões mínimas necessárias, como chmod +x.
chmod 777 é conveniente, mas também facilita a vida de quem ataca.Conselho prático: vencer o medo do terminal
Quando entrei na empresa, meu sênior mandou que eu usasse PuTTY como ferramenta de conexão ao servidor. Mas, pesquisando na internet, encontrei uma ferramenta melhor: MobaXterm. Assim que você se conecta por SSH, esse programa mostra à esquerda uma lista de arquivos por SFTP, quase como o explorador de arquivos do meu próprio computador.
Por causa disso, mesmo sem conhecer de verdade os comandos de terminal, eu conseguia abrir arquivos com clique duplo, editar e salvar. Mas se você depender só desse tipo de atalho, nunca vai realmente se tornar próximo do Linux. Em uma urgência de produção, não há tempo para esperar uma ferramenta com GUI abrir.
Encerrando: quem domina o ambiente
Sair da estufa chamada Windows e se adaptar à selva chamada Linux é doloroso. Mas, depois de atravessar essa dor, você ganha um nível de controle impossível de conseguir com um mouse.
Linux não é mais um território desconhecido. Mas ainda resta um problema fundamental. E se no meu notebook, isto é, no ambiente de desenvolvimento, estiver instalado o Java 17, enquanto no servidor Linux, isto é, no ambiente de deploy, houver apenas Java 8? Ou se existir uma biblioteca no Linux que não existe no meu Windows?
A desculpa “Mas na minha máquina funciona” nasce das diferenças de sistema operacional e de versão de bibliotecas. Não daria para eliminar completamente essa diferença de ambiente? Não daria para congelar o ambiente do meu notebook exatamente como está e levá-lo direto para o servidor?
Existe uma tecnologia que transformou essa ideia aparentemente absurda em realidade. Na próxima, vamos falar sobre o Docker, a tecnologia que foi além da virtualização e desencadeou a revolução dos containers.