Um VS Code para chamar de seu (na nuvem)
Comprei um tablet Android para estudar, e meus planos com o novo brinquedo iam muito bem, até que descobri que poderia instalar um app de terminal nele, o Termux. E aqui a história começa a mudar de figura, e caí na “baixaria” (trocadilho nerd alert 😛).
Descobri que poderia usar comandos Linux a partir do Termux, uma vez que o Android é, lá no fundo, uma distro Linux. Mergulhando mais fundo nesse mundo, descobri que é possível instalar um sistema operacional baseado em Linux inteiramente novo no tablet a partir de apps como o Andronix. E assim meu fim de semana foi condenado a derivados dessas nerdices 🤓.
Um sonho (quase) distante chamado VS Code
Quando um dev descobre esse tipo de coisa, já pensa em criar um novo sandbox, codar em um novo dispositivo, ter a mobilidade de um tablet como ferramenta de trabalho, e os sonhos só aumentam.
Comecei a procurar sobre como rodar o VS Code a partir de um tablet Android, e acabei encontrando um projeto open source chamado code-server, que inclusive faz parte de um produto comercial chamado Coder.com, uma plataforma de provisionamento de ambiente de desenvolvimento na nuvem. Basicamente ao invés de você ter que configurar um ambiente de desenvolvimento novo para cada projeto e/ou cada dev, você escolhe o seu ambiente e trabalha em uma máquina virtual provisionada na nuvem, com tudo pronto para começar a produzir e com o VS Code como interface de desenvolvimento. Inclusive a Microsoft tem um projeto semelhante vinculado ao GitHub, chamado GitHub Code Spaces.
Pois bem, eu já tinha meu norte: existe um projeto open-source que permite rodar o VS Code a partir do browser. Mas codar em uma arquitetura ARM tem lá seus limitadores, e o processador da maioria dos tablets Android intermediários não é exatamente algo preparado para esse tipo de tarefa, pelo menos não no meu caso já que escolhi um tablet intermediário, porque era só pra “estudar e consumir conteúdo mesmo”.
Decepção? Não, oportunidade! 😏
Meu tablet com processador i7, 32Gb de RAM e 1.2Tb de SSD
Não, essa não é a especificação do meu tablet. Na verdade ele é um modelo bem modesto em termos de processamento (Galaxy S6 Lite), e só tem 4Gb de RAM, o que é perfeitamente suficiente para consumir conteúdo, escrever artigos (como estou fazendo agora), e estudar tomando notas (S Pen, te amo 💖). Mas instalar um ambiente de desenvolvimento nele e exigir performance é meio que pedir demais do coitado.
Minha intenção era rodar um servidor no meu notebook pessoal e acessar esse ambiente via rede local, para aí sim aproveitar meu setup i7 + 32Gb RAM + 1.2Tb SSD, tendo assim a mobilidade de um tablet e o poder de processamento de um pequeno monstro.
O CodeServer tem um repo no DockerHub onde eles ensinam a criar um container Docker a partir da imagem. E foi o que eu fiz, só tive que adaptar um pouco os parâmetros do “docker run” descritos na documentação oficial deles.
Na documentação do DockerHub, a orientação é rodar com o seguinte comando:
> mkdir -p ~/.config> docker run -it — name code-server -p 127.0.0.1:8080:8080 \
-v “$HOME/.config:/home/coder/.config” \
-v “$PWD:/home/coder/project” \
-u “$(id -u):$(id -g)” \
-e “DOCKER_USER=$USER” \
codercom/code-server:latest
Eu queria acessar o container pela minha rede local, então não poderia deixar o IP do localhost (127.0.0.1) ali fixo. E quando eu rodo uma aplicação ASP.NET por exemplo, o servidor sobe em uma porta aleatória (ou quase, já que geralmente o Kestrel sobe aplicações ASP.NET na porta 5001 para HTTPS e 5000 para HTTP). Ou seja, eu teria que alterar o port forwarding no comando de criação do container para deixar acessível para toda a minha LAN.
Quando o IP é explicitamente definido no parâmetro `-p` como `127.0.0.1`, significa que somente o IP da máquina local poderá acessar aquele container. Já quando o IP é omitido, é como se passássemos um `0.0.0.0` no parâmetro de IP (ˋ-pˋ), ou seja, qualquer IP na rede local seria capaz de encontrar essa aplicação rodando em um container. Uma explicação mais completa sobre esse recurso pode ser encontrada na documentação oficial do Docker.
TL;DR: troquei o `-p 127.0.0.1:8080:8080` por `-p 8000–8080:8000–8080`, mapeando assim o range de portas 8000 à 8080 do container para a minha máquina host (o monstrinho). De resto deixei tudo como o recomendado, inclusive para facilitar a mudança de configurações que viriam a seguir.
O comando completo ficou:
> mkdir -p ~/.config> docker run -it — name code-server -p 8000–8080:8000–8080 \
-v “$HOME/.config:/home/coder/.config” \
-v “$PWD:/home/coder/project” \
-u “$(id -u):$(id -g)” \
-e “DOCKER_USER=$USER” \
codercom/code-server:latest
Precisamos de segurança, nem se seja o mínimo
Com o container no ar, já está quase tudo pronto para acessar o nosso ambiente de desenvolvimento. Quase.
Antes precisamos alterar o arquivo “~/.config/code-server/config.yaml”. Na primeira linha vamos substituir o IP por 0.0.0.0 (precisamos acessar nosso server pela rede local, lembra?!), e trocar aquela sequência randomica alfanumérica por uma senha que… vai ficar gravada em texto plano (ಠ_ಠ).
Pois é, falei que era seguro mas nem tanto. Essa senha será requisitada ao entrarmos no ambiente de desenvolvimento. Até existe a possibilidade de usarmos HTTPS com parâmetros de inicialização do code-server, mas para uma primeira aventura de conhecimento, o padrão já serve muito bem. Para se aprofundar mais no assunto, recomendo dar uma lida no help do CodeServer, que é bem básico porém bastante claro.
Com o arquivo devidamente alterado, já podemos testar o nosso VS Code no Android (ou qualquer outro sistema operacional que tenha acesso a um browser), acessando a URL: http://<ip-da-maquina-host>:8080.
Se roda local, roda também na nuvem 👀
E esse é o aspecto mais interessante desse projeto: a escala. Basicamente se eu consigo rodar em um container local, eu posso rodar em um container na nuvem com poder de processamento ainda mais avançado do que meu notebook. E considerando que aquele container onde isso está rodando é um universo inteiro (containers Docker rodam a partir de uma imagem Linux), dentro desse ambiente eu posso instalar meus SDKs, configurar minhas variáveis de ambiente internas e rodar as coisas do meu jeito dentro deste universo contido.
Posso subir um ambiente de desenvolvimento pré-configurado de .Net, Java, Python, Node, etc., em uma máquina com quantos núcleos eu quiser, com quanta memória eu precisar, a qualquer momento. O único limite é o seu saldo bancário 💸, uma vez que esse tipo de processamento é cobrado por hora utilizada dos serviços de nuvem (AWS/Google Cloud/MS Azure, etc.). Então sempre fique de olho no custo do processamento em nuvem.
E isso é um modelo de negócio que vem ganhando força atualmente. Você não precisa mais possuir as coisas, desde que você tenha acesso a essas coisas quando e onde quiser.
Um modelo de negócio do futuro que já é presente
Netflix talvez tenha sido o primeiro grande serviço de streaming que se tornou popular em grande parte do planeta. Com ele você não precisa ir fisicamente até uma locadora (sim, sou cringe), pegar um pedaço de plástico onde o conteúdo está fisicamente/digitalmente gravado, ter um dispositivo especializado para ler esta mídia, e dias depois ter que ir para o mesmo local para devolver este pedaço de plástico.
O mesmo aconteceu com serviços de streaming de musica, e agora está acontecendo com os videogames, com serviços como o Xbox Cloud Gaming (X Cloud) ou o PS Now: pessoas não precisam mais comprar mídias físicas de jogos de videogame ou mesmo fazer o download do jogo, elas podem fazer streaming do jogo no dispositivo que achar mais adequado no momento (no caso do XCloud).
Mas isso vem se popularizando da forma como conhecemos atualmente porque temos internet relativamente estável em muitos lugares. E estabilidade de internet é a chave para esses “serviços do futuro”.
A não muito tempo atrás a Microsoft anunciou o Windows 365, um “sistema operacional” na nuvem, onde você poderia acessar uma máquina com as configurações que você desejasse por uma assinatura. Pois é, você não precisa mais comprar um super computador se não quiser, pode “alugar” esse processamento por demanda.
Lembra de como saímos de um tablet meia boca pra revolução da computação em nuvem para devs? Pois é, e o futuro está só começando, nerds! 🤩
