paint-brush
5 alternativas de área de trabalho do Dockerpor@ChrisChinchilla
27,286 leituras
27,286 leituras

5 alternativas de área de trabalho do Docker

por Chris Chinchilla5m2022/12/28
Read on Terminal Reader

Muito longo; Para ler

O Docker Desktop tem sido a principal maneira de usar contêineres do Docker por muitos anos. Embora continue sendo uma opção viável e utilizável para amadores e pequenas equipes de desenvolvimento, as recentes mudanças de preços para bases de usuários maiores levaram as pessoas à procura de alternativas. Não pretendo substituir o Docker Desktop, mas estou interessado em experimentar as alternativas e ver como elas se comparam.
featured image - 5 alternativas de área de trabalho do Docker
Chris Chinchilla HackerNoon profile picture

Para usuários de Windows e macOS, o Docker Desktop tem sido a principal maneira de usar contêineres do Docker por muitos anos. Embora continue sendo uma opção viável e utilizável para amadores e pequenas equipes de desenvolvimento, mudanças recentes de preços para bases de usuários maiores levaram as pessoas à procura de alternativas. Não pretendo substituir o Docker Desktop, mas estou interessado em experimentar as alternativas e ver como elas se comparam.

Versão em vídeo deste post

Você pode encontrar uma versão em vídeo desta postagem com mais práticas usando a cobertura de cada ferramenta no YouTube.

Terminologia

Os contêineres em si não são um novo conceito em tecnologia, mas o Docker em meados dos anos 2000 popularizou o conceito e os comercializou da maneira certa na hora certa para trazer o conceito para o mainstream.


Vale a pena separar o Docker empresa do Docker projeto, pois é fácil confundi-los e são entidades distintas. Devido a essa confusão, a empresa Docker renomeou e abriu o código-fonte de muitas de suas tecnologias relacionadas a contêineres, contribuindo para o que agora é conhecido como “ Open Container Initiative ” (OCI).


Estou abstraindo e resumindo muito aqui, mas quando o restante deste post se referir a contêineres “compatíveis com OCI” e termos semelhantes, pense nisso como análogo ao que você pode imaginar como um “contêiner Docker”. Todos esses eventos e mudanças realmente aconteceram há algum tempo no tempo da tecnologia, mas ainda assim, é uma fonte constante de confusão. Tldr… Todas as opções apresentadas nesta postagem podem executar as mesmas definições de contêiner e isso inclui seus contêineres pré-existentes do Docker Desktop ou criados com um Dockerfile . Outra observação, geralmente os projetos se referem a contêineres em execução com o Docker como “dockerd” e “Moby” de forma intercambiável.

1. Podman

Provavelmente a alternativa mais popular, o Podman tem muitos colaboradores da Red Hat e, como parece que a Red Hat está planejando versões comerciais do Podman, pode ser seguro dizer que é um “projeto da Red Hat”.


Está disponível para Windows, macOS e Linux e, como muitas das outras ferramentas apresentadas aqui, segue uma sintaxe semelhante ao Docker com duas ressalvas:


  1. Por padrão, você usa o podman em vez do Docker, mas pode criar um alias e esquecer essa alteração de comando.
  2. Por padrão, o Docker Desktop assume que você deseja usar imagens de contêiner do hub Docker, enquanto todas as outras alternativas, compreensivelmente, não fazem essa suposição. Isso significa que você precisa especificar o caminho completo para muitas imagens que pode usar regularmente, por exemplo, “ docker.io/library/busybox ”.


Uma das principais diferenças entre o Podman e as outras alternativas apresentadas aqui, incluindo o Docker Desktop, é que ele não possui daemonless. Isso significa que cada contêiner em execução é executado como seu próprio processo de tempo de execução, não por meio de um daemon. Se o daemon do Docker falhar, todos os contêineres em execução falharão, enquanto com o Podman, apenas o contêiner individual falhará. Dito isso, eu pessoalmente nunca tive falha no daemon do Docker, mas não estou executando cargas de trabalho de produção.


Como todas as outras ferramentas aqui, na primeira execução, o Podman precisa criar uma máquina virtual no macOS e no Windows para hospedar os contêineres. Cada vez mais no macOS e no Windows, isso nem sempre é necessário, mas para compatibilidade máxima entre plataformas (e arquitetura), faz sentido. Podman usa Fedora CoreOS (há aquela conexão red Hat novamente) e QEMU para executar a VM.

Área de trabalho do Podman

O companheiro gráfico do Podman é o Podman Desktop , mas em teoria ele deve listar imagens e contêineres criados por outros tempos de execução, inc. Como muitas das outras ferramentas gráficas, ele também adiciona recursos para interagir com o Kubernetes, mas falarei sobre eles em uma postagem futura. Ele oferece muitos dos mesmos recursos do Docker Desktop, incluindo recursos que eu não sabia que seguiam nenhum padrão, como extensões, mas é um pouco menos polido e carece de alguns dos recursos específicos do sistema operacional que o Docker Desktop oferece.

2. Colima

Disponível apenas para Linux e macOS, o Colima usa Lima para habilitar VMs Linux no macOS. Ele oferece suporte aos tempos de execução Docker, Containerd e Kubernetes e, em todos os casos, você precisa instalar esse tempo de execução junto com o Colima. No caso do Docker no macOS, isso não é exatamente igual ao Docker Desktop.


Por mais simples que seja o uso do Colima, o fato de você ainda precisar instalar um runtime junto com ele me fez pensar “o que é o Colima?” e, para ser honesto, a documentação mínima não o torna mais claro. O slogan é “Tempos de execução do contêiner no macOS (e Linux) com configuração mínima”, mas isso ainda não me esclarece por que preciso dele. Tanto quanto eu posso dizer, os principais motivos são para usar containerd ou como um back-end do Kubernetes (em vez de Docker Dkestop, minikube etc.) e talvez o principal motivo para o suporte do Docker seja a compatibilidade com versões anteriores.

3. Área de trabalho do rancheiro

Embora se apresente principalmente como uma ferramenta de gerenciamento do Kubernetes, o Rancher Desktop também oferece alguns recursos de gerenciamento de contêineres fora do Kubernetes. Ele oferece suporte a contêineres em execução com containerd ou Docker e oferece a maioria dos mesmos recursos que as outras ferramentas gráficas nesta lista. Novamente, o QEMU fornece a VM na qual tudo é executado, sem opção de alterar isso. É uma ferramenta perfeitamente decente e uma das alternativas mais maduras, mas acho que é necessário reiniciar e redefinir muito a VM quando você faz alterações, o que é um pouco tedioso.

4. Fusão VMWare

Se você já usa o VMWare Fusion para executar VMs Windows e Linux, ele também oferece suporte a contêineres . No entanto, o recurso atualmente funciona apenas com Macs baseados em Intel, apesar do instalador ainda instalar a ferramenta CLI e dar a você falsas esperanças.

5. Paralelos

Novamente, se você já possui e usa o Parallels Desktop para Linux e Windows VMs, pode usá-lo como um back-end para o minikube, que é voltado principalmente para o uso do Kubernetes, mas é adjacente ao contêiner, então eu o incluo como uma espécie de opção .

o que eu uso

Por enquanto, como colaborador individual, estou satisfeito com o Docker Desktop e gosto dos recursos extras que ele oferece para uma integração mais eficiente e perfeita com o sistema operacional host.


Se algo mudasse para desincentivar pessoas como eu também, provavelmente mudaria para o Podman, talvez com o Podman Desktop, isso dependerá do estado do projeto naquele momento.

E você?