containers

Docker Desktop no Windows rodando com WSL 2

Com a inclusão de um kernel Linux completo dentro do Windows graças ao Windows Subsystem for Linux (WSL) 2, ferramentas que antes não podiam ser utilizadas no WSL por questões de compatibilidade agora podem ser executadas sem problemas. Uma dessas ferramentas muito utilizadas pelos desenvolvedores é o Docker.

No Windows 10 é possível utilizar o Docker Desktop para ter uma experiência integrada com o Docker, se aproximando muito de um sistema Linux. Entretanto, existem algumas limitações que com a atual versão que serão tratadas com a nova integração entre o Docker Desktop com o WSL 2.

Docker Desktop

O Docker Desktop é uma solução para executar containers Linux nos sistemas Windows e macOS. Ele permite que você tenha uma experiência semelhante a uma distribuição Linux, integrando o sistema de arquivos do sistemas e a rede com a máquina virtual que executa o Docker.

Essa máquina virtual é gerenciada pelo Docker Desktop através do hypervisor de virtualização do sistema, no caso do Windows o Hyper-V e do macOS o hyperkit. A execução dos containers em si acontece nessa máquina virtual, como podemos ver no diagrama abaixo:

Arquitetura do Docker Desktop

O Docker Desktop está disponível faz alguns anos, sendo a forma recomendada de executar Docker nos sistemas Windows e macOS, sendo possível com ele até executar um cluster de Kubernetes na sua máquina local.

Restrições do Docker Desktop

Apesar de ser a forma recomendada de executar o Docker nesses sistemas, um grande fator que impacta no seu uso é a performance em operações de leitura e escrita. Por executar dentro de uma máquina virtual, existe um delay para sincronizar os arquivos que estão no sistema operacional com a máquina virtual.

Isso pode ser um problema para aplicações que exigem constante leitura em disco, como é o caso de linguagens interpretadas, como o PHP. Além disso, mais especificamente com o Docker Desktop for Windows, é preciso ter o Hyper-V habilitado, que só é incluído com o Windows 10 Pro.

Então se você utiliza o Windows 10 Home ou trabalha com uma linguagem interpretada, sua experiência com o Docker no Windows pode não ser a melhor possível. Felizmente, isso vai mudar com o Docker com WSL 2.

Docker com WSL 2

O WSL 2 traz para o Windows o kernel completo do Linux através de uma máquina virtual moderna e com uma performance de disco próxima a uma máquina rodando Linux. Você pode ler mais sobre o WSL 2 nesse artigo aqui.

Com esse anúncio, o WSL 2 se tornou uma opção mais interessante para executar o Docker nos sistemas Windows. Além do ganho de performance, o WSL 2 será compatível com o Windows 10 Home, tornando o Docker Desktop disponível para um maior número de usuários.

O suporte do Docker Desktop utilizando o WSL 2 ainda está em preview, mas você já pode testá-lo se tiver executando o Windows 10 Insider. A previsão de lançamento do WSL 2 será no release 2003, e se espera que o suporte na versão estável do Docker chegue nessa época também.

O Docker Desktop irá incluir o suporte ao WSL 2 e utilizá-lo sempre que possível, mantendo o comportamento atual de usar uma máquina virtual no Hyper-V como um fallback para versões do Windows 10 que ainda não suportam WSL 2. Com isso, teremos todas as vantagens presentes no Docker Desktop, mas com uma melhor performance e suporte para o Windows 10 Home (o que hoje não é possível por requerer o Hyper-V).

Internamente, o Docker Desktop provisiona duas distribuições Linux na sua máquina, uma contendo o daemon do Docker e outra é utilizada para armazenar dados como os containers e as imagens que você utilizará. A comunicação entre essas distribuições acontece através de sockets, tanto entre o Windows como com a distribuição que você utiliza com o WSL 2 no seu dia-a-dia. Mais detalhes dessa implementação podem ser encontrados nesse post do blog de engenharia do Docker.

Arquitetura do Docker com WSL 2

Mas será que tudo isso vale a pena? Além do tempo de carregamento para iniciar o Docker Desktop, que reduziu para poucos segundos, a performance com o disco melhorou bastante. Podemos comparar esses números com o benchmark abaixo.

Teste de performance com disco

Para esse teste, vamos comparar a diferença entre o Docker Desktop utilizando Hyper-V e o WSL 2. Ambos os testes foram executados no mesmo ambiente, com a mesma máquina e quantidade de recursos disponíveis.

Para esse teste utilizei a aplicação de demonstração do Symfony junto com uma configuração de containers para Symfony mantida por um de seus core contributor. O código desses dois projetos juntos se encontra no GitHub da TreinaWeb também.

Depois de clonar o projeto e ter instalado o Docker, basta executar o comando docker-compose up para iniciar o projeto. O tempo a ser medido como comparação é para o primeiro carregamento da página inicial do projeto. Graças ao Symfony Profiler temos diretamente no navegador utilitários que auxiliam o desenvolvimento da nossa aplicação, incluindo o tempo de carregamento da mesma.

No primeiro teste, abri a página inicial do projeto utilizando o Docker Desktop com Hyper-V e essa página levou 2681ms para ser carregada:

Tempo de carregamento Docker Hyper-V

Com Docker Desktop usando WSL 2, a mesma página levou apenas 249ms!

Tempo de carregamento Docker WSL 2

Tudo isso considerando o primeiro carregamento do projeto. Foi preciso baixar todas as dependências do Composer, o container do PHP não tinha nenhum OpCache, o Symfony não chegou a fazer nenhum tipo de otimização, como compilar as views do Twig, ler as rotas da aplicação presentes nas anotations. Se considerarmos essas otimizações que farão efeito nas requests subsequentes, esse tempo cai para 20ms, comparado com um Linux rodando nativamente:

Tempo de carregamento Docker WSL 2 - carregamento subsequente

Como começar a utilizar

O Docker Desktop com WSL 2 está disponível na versão edge do Docker Desktop e pode ser baixada aqui. Por enquanto é preciso utilizar a versão insider do Windows 10 para habilitar o acesso ao WSL 2 caso você queira testar hoje mesmo.

Como vimos na comparação, o Docker Desktop com WSL 2 vai trazer um grande salto na performance para aplicações que usam muito processamento em disco. Para mim, que de vez em quando trabalho com projetos em PHP vai ser uma mão na roda! 😀

E para você? Pretende testar o Docker com WSL 2 no seu projeto? Conte pra gente o que você achou!

Desenvolvendo seus projetos com o VS Code Remote Development

Tradicionalmente, quando estamos preparando nosso ambiente de desenvolvimento local, acabamos investindo boa parte de tempo configurando esse ambiente, com tarefas como instalar SDKs, servidores de aplicação, linguagens e banco de dados. Dependendo do tamanho da sua aplicação e das quantidades de dependências, fazer essa configuração manualmente pode demorar ainda mais, além de ser propenso a falhas.

Pensando nesse tipo de cenário, pode ser interessante configurar todo seu ambiente de desenvolvimento em máquina virtuais ou containers Docker para não precisar sempre repetir essas operações e auxiliar na preparação do ambiente de desenvolvimento para um novo membro do time, por exemplo.

Embora seja uma abordagem muito útil, rodar ambientes de desenvolvimento em máquinas virtuais ou containers, dependendo do sistema operacional que você esteja utilizando, pode resultar numa experiência não tão agradável do que utilizar uma IDE diretamente no host da sua máquina.

Vendo que esse cenário de ambientes em containers tem se tornado bastante popular, a Microsoft lançou uma extensão para o VS Code com o objetivo de melhorar a experiência e reduzir as diferenças entre um ambiente de desenvolvimento local e remoto. Essa extensão de chama Remote Development, e vamos conhecer como ela funciona.

O Remote Development Pack

O VS Code é um editor de código open-source mantido pela Microsoft muito utilizado atualmente. Ele é desenvolvido para funcionar em Linux, Windows e MacOS, e graças a suas inúmeras extensões ele acaba suportando grande parte das principais stacks atuais, desde Javascript, C#, PHP, Pyhton, até Java e ferramentas de DevOps, como Terraform.

Essas extensões podem fornecer diversas funcionalidades para o VS Code, desde integrar seu ambiente com um debugger de código, integrar com sistemas de controle de código (git, mercurial e svn), até integração com containers Docker. Dentre essas inúmeras extensões, temos um pack de extensões mantidas pela Microsoft chamada Remote Development.

Extensões do Remote Development Pack

Esse pack acompanha três extensões: Remote WSL, Remote SSH e Remote Containers. Cada uma delas te permite acessar o sistema de arquivos de um sistema remote e utilizá-lo como se você estivesse trabalhando localmente na sua máquina. É possível instalar individualmente cada extensão, assim se você não precisa de suporte ao WSL você pode instalar as outras extensões.

Todos os processos executados pela sua aplicação e seu código fonte ficam armazenados dentro do sistema remoto. Para ter acesso a todas essas ferramentas, o VS Code Remote configura no sistema remoto um servidor, que será responsável por controlar os processos iniciados pelo VS Code no seu sistema local, bem como instalar extensões específicas do seu workspace, como suporte a alguma linguagem ou debuggers.

Na figura abaixo temos diagrama da documentação do Remote Development que mostra como é a integração entre o sistema remoto e seu sistema local:

Arquitetura do Remote Development

Vamos conhecer em seguida cada uma dessas extensões.

Containers

Com a extensão de containers instalada, o VS Code irá executar seu projeto dentro de containers. Ele irá utilizar um Dockefile dentro do diretório .devcontainer e o arquivo devcontainer.json com as configurações de como o VS Code deve iniciar seu container.

Antes de mais nada, preciso que o Docker esteja instalado e rodando no nosso sistema. As seguintes versões do Docker são suportadas pela extensão:

  • Windows: Docker Desktop 2.0+ com Windows 10 Pro ou Enterprise. (Docker Toolbox não é suportado.)
  • macOS: Docker Desktop 2.0+.
  • Linux: Docker 18.06+ e Docker Compose 1.21+

Seu container também precisa rodar com uma distribuição x86_64 suportada:

  • Debian 8+
  • Ubuntu 16.04+
  • CentOS / RHEL 7+
  • Alpine Linux
Docker - Fundamentos
Curso de Docker - Fundamentos
CONHEÇA O CURSO

Atendendo esses requisitos, vamos criar um projeto de exemplo.

Primeiro, vamos clonar um projeto exemplo para ser utilizado com containers. Vou utilizar o seguinte repositório de um projeto desenvolvido em Pyhton.

https://github.com/microsoft/vscode-remote-try-python

Desenvolvedor Python Júnior
Formação: Desenvolvedor Python Júnior
Aprenda os principais conceitos do Python (uso de variáveis, estruturas condicionais e estruturas de decisão), como trabalhar com orientação à objetos (métodos, construtores, destrutores, classes, herança, polimorfismo e duck-typing) e estruturas de dados (Listas, Filas, Pilhas, Árvores Binárias, Dicionários, Conjuntos, Tabelas de Espalhamento e Mapas).
CONHEÇA A FORMAÇÃO

Depois de clonado esse projeto em um diretório local, vamos iniciar o VS Code com Remote Containers. Após instalar as extensões, repare um ícone verde no canto inferior esquerdo do VS Code. Com ele você pode iniciar uma sessão remota com o projeto desejado:

Nova sessão com Remote Development

No nosso caso, vamos selecionar a opção Remote-Containers: Open Folder in Container e selecionar o diretório que clonamos o repositório. Isso irá abrir uma nova janela conectada ao nosso ambiente remoto:

Nova sessão conectada ao container

Repare que nessa nova janela o ícone verde do canto esquerdo mostra algumas informações adicionais. Caso você esteja utilizando uma conexão remota, você verá o tipo da conexão remota e o nome do projeto que estamos rodando no container. Esse container já vem preparado para você executar seu projeto, inclusive configurado para utilizar com o debugger do VSCode.

Debug com container

No menu lateral, basta você definir os breakpoints no seu código e iniciar o modo debug. Toda a configuração de mapeamento de portas é feito no arquivo devcontainer.json, assim você pode acessar diretamente do navegador na sua máquina o container que está em execução.

Essa integração também acontece com o terminal integrado do VSCode. Ao abrir o terminal, ao invés de abrir a linha de comando do sistema local, você estará acessando a linha de comando do container, podendo executar todas as ferramentas instaladas no seu container.

SSH

Com a extensão SSH é possível acessar ambientes remotos através de um túnel SSH. Pode ser utilizado em um ambiente de desenvolvimento num servidor de desenvolvimento com uma configuração de Hardware mais potente, em um ambiente mais próximo ao de produção, ou até mesmo um Vagrant configurado na sua máquina local.

Como requisitos, é preciso ter instalado na sua máquina local um cliente compatível com OpenSSH e no seu servidor ter um servidor SSH rodando em um dos sistemas abaixo:

  • Debian 8+
  • Ubuntu 16.04+
  • CentOS/RHEL 7+
  • Raspbian Stretch/9+

Temos também suporte experimental para:

Para acessar e configurar o túnel é preciso configurar um usuário SSH para essa configuração. Você pode criar um arquivo de configuração SSH e chaves SSH para a autenticação. O VS Code permite que você configure seu arquivo de configuração do SSH, geralmente localizado em ~/.ssh/config no Linux e macOS e %USERPROFILE\.ssh\config no Windows.

Abaixo temos um exemplo de um arquivo de configuração do SSH. Modifique ele de acordo com o seu ambiente:

Host host-remoto
    User usuario-remoto
    HostName ip-ou-fqdn-do-host

Host host-remoto-autenticacao-chave
    User usuario-remoto
    HostName ip-ou-fqdn-de-outro-host
    IdentityFile ~/.ssh/id_rsa-remote-ssh

Depois de configurado seu ambiente, na barra lateral temos um explorer dos nossos ambientes remotos, logo no início temos os servidores SSH configurados.

Servidores SSH configurados

A partir daí, da mesma forma que fizemos com a extensão de Containers, podemos abrir uma nova sessão remota com SSH e selecionar uma pasta do servidor para podermos trabalhar. Ao abrir o terminal integrado por exemplo, ao invés de utilizar o terminal local, você já estará utilizando uma sessão SSH dentro do servidor.

Windows Subsystem for Linux (WSL)

Por último, com a extensão do WSL, é possível executar um projeto dentro do WSL e alterar os arquivos diretamente pelo VS Code, sem a necessidade de utilizar o compartilhamento de arquivos entre o Windows e o WSL.

Utilizando essa extensão é a melhor forma de utilizar seu ambiente de desenvolvimento no WSL 2, sendo que seu sistema de arquivos não é compartilhável diretamente com o ambiente local. Assim você pode fazer uso da performance de disco que o WSL 2 te entrega.

Ao clicar novamente no ícone verde do canto inferior esquerdo é possível abrir uma nova janela do VS Code com acesso ao sistema de arquivos da sua distribuição no WSL.

Ao abrir essa nova janela, será instalado um agente dentro do WSL que permite a conexão com o VS Code. O ícone verde indicará o nome da sua distribuição que o VS Code está conectado. Ao abrir um diretório você navegará no sistema de arquivos do WSL.

Vá até o diretório em que tenha um projeto salvo. Nesse caso, tenho salvo aqui no WSL o projeto que foi utilizado no artigo Criando um ambiente de desenvolvimento PHP com WSL. Ao navegar no diretório do projeto, todos os arquivos daquele diretório estão acessíveis.

Abrir diretório

Arquivos no WSL

O agente que é instalado no WSL permite uma melhor integração com o VS Code a partir do WSL também, como por exemplo, dentro do WSL abrir qualquer diretório que você esteja navegando utilizando o comando code .. A partir do VS Code é possível utilizar o terminal integrado com acesso direto dentro do WSL.

Conclusão

Vimos aqui como utilizar a extensão Remote Development do VS Code. Com ela podemos utilizar ambientes de desenvolvimento remoto com uma experiência bem próxima de um ambiente local, com a vantagem de não precisar investir horas, até mesmo dias, configurando nosso ambiente local para começar a desenvolver.

Na documentação da Microsoft é possível consultar mais informações e configurações mais avançadas para cada uma das extensões. O link se encontra aqui.

O que vocês acharam dessa extensão? Deixem a sua opinião nos comentários, e até mais!

O que é o OpenShift?

Continuando com os posts sobre as ferramentas de DevOps, vamos abordar uma ferramenta que vem se tornando cada vez mais popular: o OpenShift, da Red Hat.

O que vem a ser o OpenShift?

O OpenShift é uma plataforma de código aberto desenvolvida pela Red Hat que auxilia no processo de orquestração de containers baseada em Kubernetes e containers Linux de maneira independente da plataforma na qual os containers serão executados.

Através de uma interface muito amigável e intuitiva, o OpenShift oferece a possibilidade de controlar todo o ciclo de vida de uma aplicação baseada em containers, desde o deploy até a execução efetiva.

Isso é possível graças a integração facilitada com várias outras ferramentas e SDKs para diferentes linguagens, o que torna o OpenShift uma ferramenta muito competente e completa não somente para o gerenciamento de containers, mas também para o controle de todo o ciclo de vida de uma aplicação.

O diagrama abaixo, fornecido pela própria Red Hat, oferece uma visão geral das ferramentas que são integradas e orquestradas pelo OpenShift.

Pela imagem acima, podemos perceber que o OpenShift oferece uma infinidade de serviços, como gerenciamento dos processos de integração contínua/entrega contínua (CI/CD), gerenciamento de configurações e logs, monitoramento da saúde das aplicações e containers que estão sendo gerenciados e até mesmo aspectos de segurança, isso tudo de maneira completamente desacoplada do container e/ou da infraestrutura que você esteja utilizando.

Segundo a Red Hat, o OpenShift consegue oferecer todos estes serviços por ser fundamentado em uma arquitetura baseada em microsserviços que conseguem se “encaixar” uns aos outros e prover as diferentes funcionalidades que cada projeto necessita.

Analista DevOps Júnior
Formação: Analista DevOps Júnior
A formação Analista DevOps nível Júnior da TreinaWeb visa introduzir desenvolvedores a tecnologias como o Docker e o servidor HTTP Nginx, tecnologias estas intimamente relacionadas ao notável universo DevOps.
CONHEÇA A FORMAÇÃO

Como o OpenShift funciona?

Segundo a Red Hat, o OpenShift funciona em cima de um sistema baseado em camadas, onde cada camada é responsável por determinada funcionalidade. A sobreposição destas camadas é que faz com que o OpenShift consiga oferecer a quantidade de funcionalidades que são oferecidas.

A imagem abaixo, retirada da própria documentação do OpenShift ilustra estas sobreposições de camadas.

No diagrama acima, percebemos inicialmente um benefício importantíssimo do OpenShift: ele é agnóstico a ferramentas de Continuous Integration/Continuous Delivery e também a ferramentas de automação de operações, como ferramentas de automação de provisionamento de infraestrutura. Isso quer dizer que você pode utilizar o OpenShift com o Jenkins, CircleCI, TravisCI, GitLab, Terraform ou qualquer uma das ferramentas desse nicho.

O OpenShift roda em cima de cluster baseado no Kubernetes, cluster no qual os componentes são organizados em um esquema de microsserviços. Estes componentes do coração do OpenShift ficam em um nó master dentro dessa infraestrutura. Entre estes componentes que ficam dentro desse nó master, podemos destacar:

  • API/Authentication: controle de acesso às APIs do OpenShift e do Kubernetes. Esse processo de autenticação é baseado no padrão OAuth e em certificados SSL;
  • Data Store: responsável por armazenar o estado e outras informações e meta-informações dos componentes do OpenShift. O OpenShift geralmente utiliza o etcd, uma estrutura de armazenamento baseada em chave/valor, para realizar o armazenamento destes dados;
  • Scheduler: responsável por distribuir as cargas de trabalho entre nós dos clusters de componentes do OpenShift. Trata-se de um dos principais componentes do OpenShift;
  • Management/Replication: mecanismo responsável pelo processo de replicação e por coletar informações sobre o estado dos componentes e elementos do cluster. Ele é basicamente um loop infinito que, de tempos em tempos, coleta estes dados e atualiza o estado dos componentes, armazenando estes estados no Data Store (etcd). Estes processos são controlados através de estruturas chamadas controllers. Os principais controllers dentro do OpenShift são: replication controller, endpoint controller, namespace controller e service account controller. É importante salientar que as informações coletadas pelos controllers refletem na API exposta pelo nó master, assim como os comandos dados às APIs do OpenShift e do Kubernetes são executados de fato também pelos controllers.

As aplicações acabam ficando armazenadas nos outros nós da infraestrutura do OpenShift. Na ilustração acima, por exemplo, temos uma estrutura inspirada no Docker: temos as aplicações dentro de containers, containers estes que ficam agrupados pelos pods. Todos estes pods desenvolvem seu ciclo de vida dentro de um nó, ou seja: uma máquina que faz parte do cluster Kubernetes gerenciado pelo OpenShift.

A relação entre o OpenShift e o OKD

O OKD é basicamente uma distribuição “personalizada” do Kubernetes. OKD é um acrônimo para “Origin Kubernetes Distribution”. O OKD foi criado pela Red Hat para que existisse uma distribuição do Kubernetes mais otimizada para processos tradicionais em ambientes baseados em nuvem, como aplicações multi-tenancy e aplicação de processos de continuous delivery/continuous integration. Ou seja: o OKD é um Kubernetes otimizado para as situações previamente citadas, otimizações estas realizadas pela Red Hat.

O OKD não é concorrente do OpenShift. Na verdade, o core do OpenShift é justamente o OKD. A estrutura baseada em Kubernetes que é utilizada pelo OpenShift é, na verdade, o OKD. Caso você julgue necessário, você pode utilizar o OKD de maneira direta, ou seja: sem passar necessariamente pelo OpenShift.