Docker

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!

O que esperar do Windows Subsystem for Linux (WSL) 2

O Windows Subsystem Linux (WSL) é uma alternativa para desenvolvedores que procuram utilizar ferramentas de linha de comando compatíveis somente com Linux no Windows. Disponível para Windows 10, com ele é possível executar nativamente binários Linux na sua máquina Windows, escolhendo sua distribuição Linux preferida, como Debian, Ubuntu, Suse, até mesmo Kali Linux. Entretanto, tudo na vida pode ser aprimorado.

Vamos conhecer nesse artigo quais são as limitações do WSL e como será a evolução para o WSL 2.

Windows - Fundamentos para desenvolvedores
Curso de Windows - Fundamentos para desenvolvedores
CONHEÇA O CURSO

Limitações do WSL

O WSL permite você executar qualquer binário compilado para Linux diretamente no Windows, através de um subsistema que é responsável pro traduzir as chamadas de sistema (do inglês system calls) do Linux para uma chamada equivalente para o Windows. Você pode ver com mais detalhes como o WSL funciona e como instalá-lo na sua máquina nesse artigo.

Duas grandes limitações do WSL são a sua performance envolvendo operações de disco e a sua compatibilidade com algumas system calls específicas.

Sobre a performance em disco, atividades que envolvem operações intensivas com o disco, com comandos como git clone, npm install, apt upgrade, entre outros acabam demorando mais do que deveriam. Isso acontece pois esses dados são salvos diretamente no disco do seu sistema, e toda a operação que precisa interagir com esses arquivos precisa de alguns passos extras para a tradução dos comandos enviados pela system call do Linux até a persistência do dado em si.

Outra limitação é a compatibilidade com system calls. Embora grande parte das system calls funcione graças a implementação e melhorias adicionadas pela equipe do WSL, elas não correspondem 100% de todas as system calls disponíveis para o Linux, fazendo que aplicações específicas que façam uso de chamadas mais avançadas do Linux não seja compatíveis com o WSL. Um exemplo desse tipo de aplicação é o Docker, ferramenta presente no dia a dia de muitos desenvolvedores atualmente.

Tendo em vista esses problemas, o time responsável pelo desenvolvimento anunciou o WLS 2, com o foco em melhorar a performance em disco e fornecer total compatibilidade com system calls em Linux, não mais traduzindo essas chamadas, mas fornecendo um kernel Linux dentro do Windows!

Como funciona o WSL 2

O WSL 2 utiliza uma arquitetura completamente diferente do WSL 1. Ao invés de traduzir as system calls, ele utiliza diretamente um kernel do Linux atualizado através de uma máquina virtual. Mas não estamos tratando de uma máquina virtual qualquer!

O WSL 2 utiliza as mais recentes tecnologias de virtualização fornecidas pelo Hyper-V para fornecer uma máquina virtual leve, rápida e altamente integrada com o Windows. Com isso é possível utilizar de todas as vantagens que o WSL 1 trouxe, mas agora com total compatibilidade do sistema, até para rodar Docker.

Graças ao uso dessa máquina virtual, a performance com operações em disco aumentaram drasticamente. Antes, seus arquivos eram armazenados diretamente no disco do sistema, agora todos os arquivos utilizados pelo WSL 2 estão dentro de uma disco virtual do formato VHD, conseguindo entregar uma performance até 5 vezes mais em operações como npm install nessa nova arquitetura.

É possível notar essa diferença a partir do vídeo abaixo encontrado no anuncio do WSL 2. Ele mostra o tempo necessário para iniciar o WSL e executar um container Docker. Tudo isso leva menos que 30 segundos!

Performace do WSL 2

Uma desvantagem dessa abordagem é que não temos acesso direto aos arquivos armazenados dentro do WSL 2, mas temos outras formas de acessar esses arquivos, através da rede ou com extensões especialidades nas nossas IDE, como a extensão Remote WSL do Visual Studio Code. Assim podemos utilizar da melhoria de performance em disco trazido pelo WSL 2.

Instalação

O processo de instalação do WSL 2 é muito próximo WSL 1. No momento ele está disponível na versão Insider do Windows 10. Sua previsão de lançamento está para o release 2003 do Windows 10 que deve ser lançado por volta de Abril de 2020.

Para use o WSL 2, precisamos habilitar a feature do Windows Subsystem for Linux e também o Virtual Machine Platform. Isso pode ser feito executando os comandos abaixo a partir de uma janela do PowerShell com permissão de Administrador:

Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

Feito isso, caso você já tenha uma distribuição Linux instalada a partir do Microsoft Store, você pode migrar essa distribuição para executar dentro do WSL 2 e poder assim utilizar de todas as suas melhorias. Por exemplo, se você tem o Ubuntu 18.04 instalado, execute o comando abaixo:

wsl --set-version Ubuntu-18.04 2

Altere o nome de acordo com a distribuição que você utiliza. Para descobrir quais distribuições estão instaladas, execute o comando:

wsl --list --verbose

Lista com distribuições WSL

Isso vai te mostrar quais distribuições estão instaladas, juntamente com a versão do WSL em uso.

Caso esteja utilizando uma instalação limpa do Windows, você pode definir a versão padrão do WSL para sua segunda versão:

wsl --set-default-version 2

O restante do processo é semelhante com o WSL 1. Você vai até a Microsoft Store e escolhe a distribuição desejada. Você pode acompanhar com mais detalhes no artigo sobre WSL como é feito esse processo.

O que esperar do WSL 2

Pelo motivo do WSL 2 ainda estar em desenvolvimento, podemos esperar que muitas melhorias sejam implementadas até seu lançamento final. Com a melhoria de performance e compatibilidade total com Linux, temos um ambiente de desenvolvimento com performance comparável o Linux instalado de forma nativa, o que é uma grande conquista.

Muitas pessoas se sentem mais confortáveis utilizando Windows, ou precisam desenvolver aplicações legadas que só funcionam no Windows, mas ao mesmo tempo trabalham com projetos que são hospedados em servidores Linux, requerendo que você tenha um ambiente mais próximo de produção. Para esses casos o WSL 2 é uma ótima solução.

Combinado com ferramentas como o Visual Studio Code com Remote extension podemos trabalhar com o WSL 2 como se estivéssemos trabalhando no sistema local, sem perceber que estamos utilizando uma máquina virtual por baixo.

Até mesmo o Docker para Windows irá se aproveitar do WSL 2, estando disponível na versão Edge do mesmo integração com o WSL 2, aproveitando também dos ganhos de performance com disco, um dos problemas que temos atualmente com o Docker ao usá-lo no Windows com aplicações que precisam de um grande volume de leitura e escrita em disco.

Docker - Fundamentos
Curso de Docker - Fundamentos
CONHEÇA O CURSO

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!

No final das contas: o que é o Docker e como ele funciona?

Provavelmente, você já deve ter ouvido falar sobre o Docker e ficado em dúvida sobre o que ele realmente faz ou sobre o que é esse tal de container. Por isso, vamos abordar nesse artigo o que realmente vem a ser o Docker.

Docker - Primeiros Passos
Curso de Docker - Primeiros Passos
CONHEÇA O CURSO

Docker

O Docker é uma plataforma open source que facilita a criação e administração de ambientes isolados. Ele possibilita o empacotamento de uma aplicação ou ambiente dentro de um container, se tornando portátil para qualquer outro host que contenha o Docker instalado. Então, você consegue criar, implantar, copiar e migrar de um ambiente para outro com maior flexibilidade. A ideia do Docker é subir apenas uma máquina, ao invés de várias. E, nessa única máquina, você pode rodar várias aplicações sem que haja conflitos entre elas.

Vale lembrar que a tecnologia e a empresa compartilham o mesmo nome. A empresa Docker Inc. desenvolve a tecnologia com base no trabalho realizado pela comunidade do Docker. Essa comunidade trabalha gratuitamente para melhorar essas tecnologias em benefícios de todos.

Então, podemos dizer que o Docker é uma máquina virtual?

O Docker é algo parecido com uma máquina virtual extremamente leve, mas não se trata de fato de uma máquina virtual. O Docker utiliza containers que possuem uma arquitetura diferente, permitindo maior portabilidade e eficiência. O container exclui a virtualização e muda o processo para o Docker. Então, não podemos dizer que o Docker é uma máquina virtual. Veja na imagem abaixo as diferenças entre o Docker e uma virtualização.

Podemos ver que, na virtualização, temos um maior consumo de recursos, uma vez que para cada aplicação precisamos carregar um sistema operacional. Já no Docker, podemos ver que não existe essa necessidade de múltiplos sistemas operacionais convidados.

O que são esses containers?

Um container é um ambiente isolado. Um container contém um conjunto de processos que são executados a partir de uma imagem, imagem esta que fornece todos os arquivos necessários. Os containers compartilham o mesmo kernel e isolam os processos da aplicação do restante do sistema.

Por exemplo: se você está desenvolvendo uma aplicação para um cliente, você pode fazer suas configurações nessa aplicação… Mas, em um ambiente convencional, você precisará replicar estas configurações para os outros ambientes de execução. Com o Docker, você estará fazendo isso em um ambiente isolado e, por causa da facilidade para replicação de containers, você acaba criando ambientes padronizados, tanto em desenvolvimento como em produção, por exemplo. Assim, você pode disponibilizar essa arquitetura toda para seu cliente, onde ele estiver: basta replicar os containers, que serão executados da mesma maneira em qualquer lugar.

Como o container possui uma imagem que contém todas as dependências de um aplicativo, ele é portátil e consistente em todas as etapas de desenvolvimento. Essa imagem é um modelo de somente leitura que é utilizada para subir um container. O Docker nos permite construir nossas próprias imagens e utilizá-las como base para os containers.

Vale lembrar que, apesar do Docker ter sido desenvolvido inicialmente com base na tecnologia LXC (Linux Containers – sendo, portanto, mais associado aos containers Linux), hoje essa tecnologia tornou-se independente de sistema operacional: podemos utilizar o Docker em ambientes Linux, Windows e até mesmo MacOS.

Por que utilizar o Docker?

Depois de conhecer um pouco mais sobre o Docker, você já deve ter percebido algumas vantagens de sua utilização, como economia de recursos, melhor disponibilidade do sistema (pelo compartilhamento do SO e de outros componentes), possibilidades de compartilhamento, simplicidade de criação e alteração da infraestrutura, manutenção simplificada (reduzindo o esforço e o risco de problemas com as dependências do aplicativo), entre muitas outras. Sendo assim, você terá muitos motivos e oportunidades para fazer uso do Docker.

Se quiser aprender mais como funciona o Docker na prática, dê uma olhadinha nos nossos cursos de Docker.

Docker - Primeiros Passos
Curso de Docker - Primeiros Passos
CONHEÇA O CURSO
Docker DevOps - Para desenvolvedores
Curso de Docker DevOps - Para desenvolvedores
CONHEÇA O CURSO
Docker DevOps - Para operações
Curso de Docker DevOps - Para operações
CONHEÇA O CURSO

Até mais!