Machine: Máquina Docker agora está em modo de manutenção

Oh :(

Bem, isso foi bom enquanto durou :)
Obrigado a todos pelo bom trabalho!

Peço que você também atualize o readme.md

Se o suporte oficial para a máquina estiver sendo encerrado, qual é a probabilidade de um suporte contínuo voltado para a comunidade neste repo?

para aqueles que precisam de máquina, há alguma atividade na organização https://github.com/machine-drivers , e pode fazer sentido para você trabalhar e liberar em https://github.com/machine- drivers / máquina ...

Já examinamos a adição de patches a esta organização, pois eles parecem não ter sido mesclados aqui: # 4509 (Isso está bloqueando as versões localizadas do Windows). O melhor é seguir em frente com algum tipo de lançamento, no entanto, para nós: minikube e minishift, só precisamos conectar a uma biblioteca.

@ shin- Como um pensamento, os documentos do novo usuário "Getting Started" ainda usam docker-machine como uma parte central da introdução.

Para as pessoas interessadas em atualizar os documentos, o que eles deveriam orientar?

• Windows: parece Docker Desktop para Windows
• Mac: parece Docker Desktop para macOS
• Linux: Continuar usando os documentos da Máquina?

Eu acho que isso realmente é uma pena. O verdadeiro poder da máquina estava em algum lugar entre a simplicidade de fazer as coisas funcionarem em uma máquina usando Desktop e a complexidade por trás do infrakit . máquina era perfeita para acionar algumas máquinas para testar cargas de trabalho distribuídas em menor escala.

Oi!

Alguém tem um software alternativo para Linux? Eu não quero executar docker como root em minha máquina host e docker-machine estava dando algum isolamento a esse respeito. Existe algum plano para o Docker para Linux?

Obrigado!

@gilbsgilbs Você ainda pode usar docker-machine como faz atualmente!

@ shin- Obrigado pela sua sugestão. Estou começando um novo projeto, então usar docker-machine para isso seria uma jogada estranha, não seria?

@ shin- Weelll ... estar fechado para os meios de relações públicas, usá-lo para novos projetos é provavelmente uma má ideia. :piscadela:

@justinclift Não quero entrar em muitos detalhes porque temos mais informações chegando em uma declaração preparada, mas como tentei afirmar no post original, o projeto não está fechado para PRs; estamos simplesmente tentando limitar essas correções de bugs em vez de novos recursos. Se o conjunto de recursos da iteração atual de docker-machine atende às suas necessidades, não há razão para abandoná-lo, mesmo para novos projetos.

Parece que o infrakit também não está ativo. Não houve lançamentos por mais de um ano, nenhuma atualização no DockerCon 2018, nenhuma documentação do usuário semelhante a https://docs.docker.com/machine/

A documentação da máquina Docker sugere experimentar o Docker Cloud, que por sua vez está sendo encerrado em favor do Docker EE (que geralmente não está disponível)

Tudo isso incentiva a bifurcar o projeto ou procurar outro lugar: https://landscape.cncf.io/grouping=landscape&landscape=infrastructure-automation&sort=first-commit

Não reclamando, apenas descrevendo minha perspectiva.

Interessante. Olhando para o histórico de commits do um homem só .

A atividade parece ter cessado por volta de abril / maio . Adivinhar o tempo das pessoas foi redirecionado para outras coisas.

É uma maneira incorreta de ver as coisas?

@ shin- mas muitos dos PRs (como correções de bugs que forneço para fazer a internacionalização no Hyper-V funcionar) não foram considerados para fusão. Esta não é uma boa indicação de "estamos simplesmente tentando limitar as correções de bugs em vez de novos recursos", visto que "não há razão para abandoná-lo, mesmo para novos projetos".

@canela-

Não quero entrar em muitos detalhes porque temos mais informações chegando em uma declaração preparada

Você poderia criar um link para essa declaração oficial (sempre que for publicada?) Não consigo encontrar.

Eu recomendo fortemente alterar os documentos para que estejam atualizados .
Minha última hora foi uma exploração sem sentido do boot2docker, que aponta claramente para a docker machine, que tem um aviso em sua página principal aconselhando o uso da docker cloud como uma tecnologia atualizada. Isso aponta para a descrição do documento da nuvem do Docker (não a página de migração !!!!), o que exigiu que eu pesquisasse no Google para descobrir que foi descontinuado em maio (mas anunciado em março, portanto, 7 meses atrás). Agora vim aqui para sugerir a remoção do aviso do doc da máquina docker, descobri que neste problema de máquina docker de 3 meses também está sendo descontinuado.
Não é assim que a documentação deve funcionar. Voltarei a alguma solução ad hoc, mas abandonaria o docker se já não o estivesse usando.

@aliceminotto Ajudaria a todos nós a atualizar documentos desatualizados se você pudesse apontar para os sites ou páginas de que está falando.

docker-machine não está indo embora, ela apenas não está aumentando o escopo de recursos.

O Docker Cloud não vai desaparecer, apenas não é mais usado para provisionamento / gerenciamento de servidor. Ele ainda está lá para construção de imagem. Docker tem outras ferramentas para servidores de produção como Docker para AWS , Docker para Azure e DCI para Docker Enterprise.

Eu tinha me esquecido completamente do antigo site http://boot2docker.io e não percebi que o aviso estava tão mal redigido (desculpas por qualquer confusão que contribuiu para!) - Agora atualizei (e reduzi) que conteúdo para esclarecer melhor que boot2docker, a antiga ferramenta CLI, é o que foi preterido em favor da Docker Machine e que boot2docker a distribuição não está obsoleta, mas está em modo de manutenção (igual à Docker Machine).

Colocando de outra forma: novos lançamentos do Docker, atualizações do kernel, etc., mas tentativas concertadas de manter os novos recursos / funcionalidades em um mínimo absoluto para garantir a manutenção contínua para as poucas pessoas que ainda não podem fazer a transição para o Docker mais adequado para Windows / Docker para produtos Mac ou as ferramentas / soluções de servidor de produção mencionadas acima (usuários do Windows 7 que não podem Docker para Windows, usuários do Windows 10 Home que, portanto, não podem Hyper-V, usuários do VirtualBox que, portanto, não podem Hyper- V, etc etc).

@tianon : você também pode querer mencionar usuários Linux que não desejam fazer a transição para Mac ou Windows ...

@afbjorklund Por que você precisa do boot2docker se já está usando o Linux?

@Vanuan : ou porque sua distro era muito antiga (por exemplo, RHEL6) ou porque você não tinha permissão para fazer root ...

De qualquer forma, a transição para o Docker Desktop _não_ é uma opção - é Docker Engine ou DIY LinuxKit?

Gostaria de agradecer aos fabricantes de docker-machine e boot2docker, por tornarem o docker mais acessível.

E com o esforço dos drivers de

Por que eu usaria uma distribuição de servidor para desktop? E por que não sou administrador do meu desktop? Mas de alguma forma tenho permissão para acessar o KVM?

Parece que você está procurando uma solução para executar o docker no servidor KVM? Se for esse o caso, estou explorando o infrakit aqui: https://github.com/docker/infrakit/issues/913

Mas se você está apenas tentando executar o docker no desktop Linux, não entendo por que você não instalaria o Ubuntu mais recente junto com o Docker CE. Se você quiser executá-lo na VM, faça isso. Você pode montar seu diretório inicial no VirtualBox e usar o docker sobre SSH. Qual é o problema aqui? Não há Docker para Linux Desktop porque não faz sentido. Pelo menos para mim

Por que eu usaria uma distribuição de servidor para desktop? E por que não sou administrador do meu desktop? Mas de alguma forma tenho permissão para acessar o KVM?

Algumas pessoas precisam usar qualquer sistema operacional de desktop que seu empregador lhes dê. RHEL6 é um exemplo que (alguns meses atrás) ouvi de um cara que trabalhava em uma bolsa de valores. :piscadela:

Como um dado geral, com o Libvirt ele (pelo menos costumava) ter um conceito de VMs que os usuários poderiam executar em suas contas, que seria apenas para eles. por exemplo, não acessível a outras pessoas logadas na mesma máquina

Não tenho certeza se isso foi desenvolvido em alguma profundidade, já que a maior parte do esforço de desenvolvimento da Libvirt foi para coisas de VM de "nível de sistema" em vez de nível de usuário.

se você está apenas tentando executar o docker no desktop Linux, não entendo porque você não instalaria o Ubuntu mais recente

Muitas pessoas não gostam do Ubuntu por um motivo ou outro. :piscadela:

A partir da v18.09 ( DOCKER_HOST=ssh:// ), configurar máquinas Docker remotas sem docker-machine é realmente trivial: https://medium.com/lucjuggery/docker-tips-access-the-docker- daemon-via-ssh-97cd6b44a53

Como um dado geral, com o Libvirt ele (pelo menos costumava) ter um conceito de VMs que os usuários poderiam executar em suas contas, que seria apenas para eles. por exemplo, não acessível a outras pessoas logadas na mesma máquina

Sim, é chamado qemu: // sessão
O GNOME mais recente tem até um aplicativo legal para isso - Caixas: https://en.wikipedia.org/wiki/GNOME_Boxes

A virtualização KVM do modo de usuário tem algumas desvantagens em relação à rede. Portanto, acho que o Virtualbox é a única opção nessas condições.

E para ter CLI para VirtualBox a escolha é vagrant. Você só precisa de alguma distribuição do Linux para executar o docker em cima dele. E a batalha mais testada é o Ubuntu / Debian. Você pode baixar qualquer outra distro. Mas você mesmo deve empacotar para usar com o Vagrant: https://www.vagrantup.com/docs/virtualbox/boxes.html

Apenas dizer que docker-machine era uma boa solução para os usuários de Linux, assim como era para usuários de Mac e Windows antigos ... Tudo o que era necessário era executar o docker em uma porta não padrão, em vez de codificado 2376? E um novo driver qemu que não requer o grupo libvirt (ou seja, root). Talvez infrakit / hyperkit seja uma alternativa no futuro, mas no momento (o link acima) ele ainda parece _bastante_ irregular.

@Vanuan : Eu sei sobre as opções ubuntu / vagrant, apenas me referi a elas simplesmente como " Docker Engine " acima.

@justinclift : cada usuário recebe suas próprias chaves ssh / certificados docker, de forma que as máquinas são razoavelmente separadas.

@afbjorklund Não se preocupe. Já se passaram anos desde que trabalhei na Red Hat na equipe Libvirt. Hoje em dia, geralmente só o uso para diagnosticar problemas, em vez de continuar sendo muito aprofundado com ele. :sorriso:

@afbjorklund Vamos esclarecer isso.

você também pode querer mencionar usuários Linux que não desejam fazer a transição para Mac ou Windows ...
De qualquer forma, a transição para o Docker Desktop não é uma opção - é Docker Engine ou DIY LinuxKit?
Eu sei sobre as opções ubuntu / vagrant, apenas me referi a ele simplesmente como "Docker Engine" acima.

boot2docker é a distribuição ( boot2docker.iso ) e a ferramenta para gerenciar o virtualbox ( boot2docker-cli ). boot2docker.iso inclui Docker CE (antigo Docker Engine):

https://github.com/boot2docker/boot2docker/blob/d465167d83310295b5847ba315905f52c3ca1435/Dockerfile#L426 -L435

E isso será atualizado para novas versões do Docker CE.

O boot2docker-cli se foi, mas em essência é apenas vagrant com o virtualbox. O Vagrant ainda está por aí.

A máquina docker com driver KVM usa boot2docker.iso para provisionar _Docker CE_ para novas VMs libvirt .

O Docker Desktop usa distribuições criadas com o linuxkit para provisionar _Docker CE_ para Hyper-V e xhyve.

Para imaginar tudo:

Como você pode ver, todas as soluções incluem Docker Engine (atualmente chamado de Docker CE para Linux ) de uma maneira a outra.

Existem muitos ambientes e soluções de virtualização / nuvem. Consequentemente, não há uma ferramenta que possa funcionar igualmente bem em windows / mac / linux e suporte QEMU / Virtualbox / xhyve / Hyper-v junto com diferentes nuvens e provisionamento over-SSH. E tal ferramenta também precisa de configurabilidade: suporta portas diferentes, gerenciamento de recursos de memória / CPU, rede, etc. Portanto, provavelmente uma ferramenta de uso geral junto com algum arquivo de configuração baixado em http seria a melhor solução.

@Vanuan : sim, isso é o que dissemos acima. Para substituir a docker-machine, você precisa mudar para Mac ou Windows e Docker Desktop - pelo menos até que _alguém_ crie algo semelhante com LinuxKit e libvirt ...

Não precisamos mais falar sobre boot2docker-cli, e o suporte para drivers Linux _já_ mudou para a organização "drivers de máquina" - já que apenas o VirtualBox está disponível com a máquina docker padrão.

@ shin- Se você não está permitindo mais novos recursos, considere adicionar uma nota muito clara no topo de README.md AND CONTRIBUTING.md .

É muito chato ler ambos os arquivos com atenção, implementando um driver (vários dias de trabalho) e não perceber que vocês nunca irão fundir nenhum driver mais. Isso deve ser bem mais claro.

Se tudo isso for um mal-entendido e eu ainda tiver permissão para puxar a solicitação do meu driver, entre em contato conosco. Só que, no momento, só é mencionado em um arquivo oculto que as pessoas verão depois de criarem a solicitação de pull.

Ainda não há informações claras sobre o modo de manutenção em README.md e / ou CONTRIBUTING.md . Eu gastei metade do meu tempo de férias para descobrir uma solução de trabalho para criação de VM ProxmoxVE e Linux leve para implantação de Docker - encontrei a combinação de docker-machine + docker-machine-driver-proxmox-ve para funcionar muito bem para esse uso caso. Infelizmente, ele depende do boot2docker, que diz que ele está obsoleto em favor de docker-machine e o mantenedor de algum tópico sugere o Rancher OS. docker-machine vai para o modo de manutenção sem definir claramente o que isso significa (dizer que apenas correções de bugs seriam aceitas e sugerir que está tudo bem para novos projetos é IMO em contradição). Também houve anúncio oficial mencionado em agosto de 2018, mas nenhum sinal de qualquer referência aqui.

Do ponto de vista externo, que deseja construir uma infraestrutura razoável para SMB, docker-machine não parece ser a solução correta de longo prazo. Qualquer um pode sugerir o que seria Reasonably Good ™ para provisionar e gerenciar o ProxmoxVE VM como hypervisor e Linux com suporte mínimo para Docker?

Infelizmente, ele depende do boot2docker, que diz que ele está obsoleto em favor do docker-machine e o mantenedor de alguma thread sugere o SO Rancher.

Você pode ser mais específico sobre onde o boot2docker está alegando ser preterido em favor do docker-machine para que eu possa esclarecer isso apropriadamente? (porque não é verdade, a menos que você esteja se referindo muito especificamente à antiga ferramenta boot2docker CLI que não é mantida ativamente há anos)

A distribuição boot2docker (especificamente, o artefato boot2docker.iso lançado com cada nova versão do Docker CE) não irá embora tão cedo que eu saiba, embora tenha um foco muito estreito agora (e, portanto, não é provável que novos recursos / funcionalidades sejam considerados para fusão).

@tianon Você está certo, desculpe a confusão. A mensagem no site diz boot2docker CLI - à primeira vista não estava claro para mim se havia alguma diferença. Tenho certeza de que outros usuários também podem ficar confusos, já que provavelmente você enfrentará boot2docker.iso . boot2docker CLI é algo que você nunca ouviu falar, é difícil dizer qual é a relação entre projetos. OTOH boot2docker.iso statement "maintenance mode" é vago da mesma forma que docker-machine , que concluo com base nesta resposta .

Para resumir a confusão:

1. "maintenance mode" - não está claro em ambos os projetos, posso usar isso para produção em pequenas empresas?
2. ambos os projetos principais desenvolvedores / mantenedores sugerem o uso de outros projetos que parecem não cobrir todos os casos de uso suportados anteriormente

O ideal seria ter uma declaração clara de @tianon e @ shin- se o uso de docker-machine é adequado para produção?

Não posso falar pela Docker Machine, mas boot2docker nunca foi uma boa escolha para produção; seu alvo é o desenvolvimento / uso da estação de trabalho pessoal.

Veja também as notas adicionadas em https://github.com/boot2docker/boot2docker#readme , onde tentei esclarecer o que entendemos por modo de manutenção e que b2d não se destina nem é recomendado para cargas de trabalho de produção.

Como muitos outros, fiquei frustrado ao saber sobre isso nos problemas do Github, depois de me esforçar para usar a máquina para um cliente SMB

Criei um PR para atualizar a documentação oficial, adicionando um aviso sobre o modo de manutenção da máquina.

Veja https://github.com/docker/docker.github.io/pull/9239

Seria bom mudar o docker para começar também https://docs.docker.com/get-started/part4/

editar: Encontrada uma solução que é instalar docker-ce na instância aws ec2, e então a porta ssh encaminhar o daemon docker.

ssh -NL localhost:23750:/var/run/docker.sock -i ***.pem ubuntu@***.compute.amazonaws.com
docker -H tcp://localhost:23750 run hello-world

🎉

Comecei a usar o docker-machine recentemente porque ele foi instalado com o Docker Desktop e percebi que poderia fazer o docker rodar em instâncias aws muito mais poderosas do que minha máquina local. A beleza é que os aplicativos locais que usam comandos docker, como o Visual Studio Code, podem funcionar com contêineres docker-machine como se estivessem sendo executados localmente.

Parece-me que docker-machine não foi substituído, apenas existem muitas novas maneiras de provisionar clusters, incluindo infrakit, kubernetes, etc.

Eu poderia estar entendendo mal. Existe uma estratégia de migração para fazer o que descrevi acima?

Usamos o GitLab, com sua ferramenta GitLab Runner para provisionar dinamicamente instâncias EC2 Spot para a execução de trabalhos de CI / CD. GitLab Runner usa Docker Machine para realizar o provisionamento dessa máquina.

Decidimos mudar todos os serviços do Ubuntu (inchado) em favor do Amazon Linux 2. Para minha alegria, PR # 3609 permitiria isso.

No entanto, por causa deste "fechamento da torneira", # 3609 parece que vai morrer no lugar. Considere mesclá-lo, em seu estado atual não conflitante e mesclável.

Como os caras do Gitlab já estão mantendo um fork, talvez eles possam estar interessados ​​em cuidar desse repo?

@ usha-mandya @ Dawn-Wood alguma atualização no docker / docker.github.io # 9239? Como um lembrete, ele adiciona avisos consultivos em todas as páginas da máquina Docker. Isso foi mesclado, mas revertido enquanto a divisão da empresa acontecia para que todos pudessem tomar algumas decisões sobre o futuro do DM. Seria bom ter este aviso se o DM continuar em modo de manutenção

AFAIK, a versão mais recente do Docker Desktop não inclui mais docker-machine

AFAIK, a versão mais recente do Docker Desktop não inclui mais docker-machine

Acabei de aprender sobre esse problema dessa maneira, já que nossas ferramentas internas de docker-machine pararam de funcionar após a atualização para docker para desktop 2.2.0.0

É meio irritante que essa mudança também não seja mencionada na janela de encaixe para notas de versão de desktop.

Usamos fortemente docker-machine para gerenciar e manter docker-machines compartilhadas baseadas em booot2docker para ambientes DEV internos e de preparação usando o driver Hyper-V (portanto, provisionamos VMs boot2docker hyper-v usando docker-machine). Portanto, embora tenhamos clientes linux e mac e, portanto, usemos o docker para windows / os x, ainda dependemos muito do docker-machine para nosso material de CI / CD.

Não tenho conhecimento de nenhuma substituição semelhante para esta configuração - estou faltando algo óbvio aqui?

Você sempre pode baixar o binário mais recente com brew (macOS) e diretamente
do repo. Ainda está sendo mantido (patches), mas está sendo lentamente
eliminação de ferramentas como o Docker Desktop.
https://github.com/docker/machine/releases

Na segunda-feira, 27 de janeiro de 2020 às 11h47, sambernet [email protected] escreveu:

AFAIK, a versão mais recente do Docker Desktop não inclui mais
docker

AFAIK, a versão mais recente do Docker Desktop não inclui mais
docker

Acabei de aprender sobre esse problema dessa forma, como nossa docker-machine interna
o conjunto de ferramentas parou de funcionar após a atualização para docker para desktop 2.2.0.0

É meio irritante esse movimento não ser mencionado no docker para
notas de versão de desktop também.

Usamos fortemente docker-machine para gerenciar e manter
máquinas docker baseadas em booot2docker para DEV interno e teste
ambientes usando o driver Hyper-V (portanto, provisionamos boot2docker hyper-v
VMs usando docker-machine). Portanto, embora tenhamos clientes Linux e Mac e
portanto, use o docker para windows / os x, ainda dependemos muito do docker-machine
para nosso material de CI / CD.

Não tenho conhecimento de nenhuma substituição semelhante para esta configuração - estou faltando
algo óbvio aqui?

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/docker/machine/issues/4537?email_source=notifications&email_token=AAGBNX2APIHK6CBNGSAMLDDQ74FYPA5CNFSM4FJ53G3KYY3PNVWWWK3TUL52HS4DFVREWSJG43VMVBW63LNVREWORG4FDQ74FYPA5CNFSM4FJ53G3KYY3PNVWWK3TUL52HS4DFVREWSJG43VMVBW63LNH83HGU355KY35KY35KY35EU35KY35KY35KY35KY35KTZK35EU35KY35KY35KY35KY35KY35KKY35KKY35WKY35KY35KWH83
ou cancelar
https://github.com/notifications/unsubscribe-auth/AAGBNXZV7PCYP3TLWSZ7QODQ74FYPANCNFSM4FJ53G3A
.

Eu também aprendi que a docker-machine foi eliminada da maneira mais difícil na semana passada 😒
Em docs.docker.com, diz que docker-machine foi "substituído", mas não consigo encontrar nenhuma informação sobre o que foi substituído. Quero continuar gerenciando minhas máquinas de caixa virtual local com ALGUMA coisa, alguma dica sobre como fazer isso de maneira preparada para o futuro?

export DOCKER_HOST = ssh: // user @ host pode funcionar para você

Quero continuar gerenciando minhas máquinas de caixa virtual local com ALGUMA coisa, alguma dica sobre como fazer isso de maneira preparada para o futuro?

Você pode usar o Vagrant para isso, talvez? Ou você pode simplesmente continuar a usar docker-machine ...

Mas você teria que vir aqui para os binários, uma vez que não faz mais parte do Docker (Desktop)

Não tenho conhecimento de nenhuma substituição semelhante para esta configuração - estou faltando algo óbvio aqui?

Não há substituição, mas muitas pessoas estão interessadas no uso continuado de machine e libmachine.

Claro que existem _alternativas_ (produtos diferentes), mas isso não é realmente a mesma coisa (como os garfos).

@afbjorklund Bem, espero que a docker-machine

Se não for apenas algo que está acontecendo para você agora (apenas), então provavelmente é melhor dar um ping no suporte do GitHub sobre isso.

Estou extremamente confuso sobre qual é a maneira preferida de simplesmente implantar meus contêineres.
A criação de contêineres por meio do Docker é promovida como uma forma padrão amplamente usada de criar serviços. Então é isso que eu usei para fazer contêineres para o site que estou criando agora.
Mas então eu obviamente preciso implantar esses contêineres em meu VPS. Portanto, eu uso docker-machine, pois é a única maneira documentada, e não obsoleta, que conheço de fazer isso. E agora eu aprendi que está em "modo de manutenção" então posso não querer usar em um novo projeto, mas o que é infrakit? Há 2 mil estrelas, mas tenho dificuldade em entender para que serve (e pode substituir a máquina docker de uma forma simples) ou documentações oficiais e agora está em modo somente leitura (arquivado), então sinto que não deveria nem mesmo usá-lo e não há nenhum link neste Leiame / questões de repositório para um novo repositório. Por que não há documentação e foi descontinuado se substituir a máquina docker.
Docker parece uma solução tão popular, mas não consigo encontrar uma única maneira não descontinuada (ou em "modo de manutenção") de implantar meus contêineres. Se o docker é tão amplamente usado, como os possivelmente milhões de desenvolvedores que trabalham com ele lidam com a implantação de seus aplicativos?

Acho que originalmente o Docker promoveu o Docker EE, sua versão paga, como uma forma oficial de implantar contêineres. Então, eles rejeitaram as iniciativas de máquina Docker e Infrakit, pois isso ameaçava seu modelo de negócios.

Além disso, o k8s mudou completamente a paisagem e o Docker teve dificuldade para se adaptar.

Agora que a Mirantis adquiriu a Docker EE, a Docker busca outro modelo de negócios. Acho que uma nova direção é tentar injetar pacotes de aplicativos no ecossistema k8s e deixar a própria implantação do k8s para a comunidade. Especialmente porque o k8s não faz parte do Docker CE (no Linux).

K8s, OTOH é gerenciado pelo Google, que tem todo o incentivo para tornar a implantação do K8s tão complicada que as pessoas diriam literalmente "Ei, Google, instale o cluster K8s para mim". Assim, bloqueando os serviços em nuvem do Google.

Portanto, a visão de Solomon Hykes de libertar a nuvem do aprisionamento e torná-la uma mercadoria falhou miseravelmente.

@NitroBAY Como o "ciclo de vida do software", desde a criação do código até os aplicativos executados em servidores (e eventualmente atualizados em servidores) é tão complexo, com uma tonelada de maneiras variadas de "construir imagens de contêiner e baixá-las para os servidores", é difícil dizer qual deve ser sua solução.

Originalmente, docker-machine devia fazer três coisas:

1. provisionar VMs simples nos principais provedores de nuvem ou um gerenciador de VM de máquina local (VirtualBox, Hyper-V, VMWare, Parallels, etc.)
2. instale o docker nessa VM, incluindo um certificado autoassinado e abrindo a porta API TCP
3. ssh fácil para esse servidor e controle do docker remotamente com o docker cli (env docker-machine)

(vamos esquecer os recursos legados, como a criação de um enxame clássico)

Com o primeiro "criando uma VM Linux": eu recomendo que você substitua-o pela ferramenta de sua escolha na nuvem para como eles criam VMs. Se for local e você quiser algo mais rápido do que instalar uma VM Linux, dê uma olhada no

Com o segundo "instalando o docker em uma VM Linux": você pode instalar o docker em qualquer VM moderna usando o script de instalação ou os documentos oficiais da distribuição do seu sistema operacional . A maioria das nuvens tem uma imagem oficial com docker, como uma opção.

Docker nunca foi capaz de resolver todos os seus problemas de CI / CD, e docker-machine é realmente apenas um provisionamento de VM e ferramenta de instalação básica, então muitas pessoas precisavam de uma solução mais flexível e sustentável (por exemplo, docker-machine não é compartilhada facilmente configurações de servidor entre máquinas). A equipe do Docker nunca quis que a máquina-ferramenta resolvesse todos esses problemas. Ele ainda funciona hoje para aquelas coisas originais, então fique à vontade para usá-lo, contanto que funcione para você. Ainda uso mensalmente, desde 2015.

Talvez se você detalhou um problema específico que a docker-machine resolveu, poderíamos recomendar alternativas específicas que você poderia implementar.

Por exemplo, com relação ao item 3 acima "controlar docker remotamente" , sempre gostei que a docker-machine provisionaria um certificado autoassinado para autenticação API e me permitiria alterar meu ambiente docker localmente para que pudesse controlar o servidor remoto. Esse método legado foi substituído pelo demonstração rápida aqui usando o método env DOCKER_HOST e tivemos uma demonstração em meu show ao vivo no verão passado do novo recurso de contexto , que permite armazenar uma lista de servidores docker diretamente no docker CLI e usar SSH ou TCP para controlá-los remotamente.

Além disso, o InfraKit é uma ferramenta para integradores de sistema (pessoas que criam sistemas operacionais Linux personalizados), não para usuários Linux como nós, que desejam uma distribuição normal do Linux criada com nosso hoster e para instalar o docker nele.

Uau @BretFisher, muito obrigado pela sua resposta tão detalhada. Tenho certeza de que também será considerado um presente de ouro por futuras pessoas que lerão você.
Só para constar, acabei criando um script carregando meu config.json na máquina remota (para que pudesse baixar minha imagem privada) e o arquivo de composição. E, em seguida, executar "docker stack deploy"
Minha implantação sh se parece com isso

#!/bin/bash
ssh -o StrictHostKeyChecking=no -l root "$HOST" root@$HOST "mkdir /opt/app; mkdir /root/.docker"
source ./devops/generate-branch-hostname.sh
scp ./devops/docker-compose-prod.yml root@$HOST:/opt/app/docker-compose-prod.yml
scp $HOME/.docker/config.json root@$HOST:/root/.docker/config.json
echo "BRANCH_HOSTNAME=$BRANCH_HOSTNAME"
ssh root@$HOST "export BRANCH_HOSTNAME=$BRANCH_HOSTNAME; docker stack deploy --compose-file /opt/app/docker-compose-prod.yml webapp --with-registry-auth"

(BRANCH_HOSTNAME não é necessário obviamente, eu apenas tenho diferentes subdomínios com base no branch Git que aciona meu script (eu uso CI / CD))
E eu ainda uso docker-machine create para ter docker no meu VPS remoto do ubuntu.

De qualquer forma, a máquina docker NÃO é uma boa ideia em CI / CD porque compartilhar o certificado não é fácil (é uma pasta inteira) e regenerar o certificado pode parar o Docker, portanto também não é uma opção.

Eu ainda acredito que deve existir uma ferramenta (feita pela comunidade ou pelo docker) que provisione DOCKER_HOST etc. e simplesmente use a chave SSH. Seria mais fácil do que "scp" e "ssh".

A máquina Docker acabou não sendo inevitável.

Não sou um profissional, sou apenas alguém que aprendeu em minha própria programação web e que está trabalhando meu tempo em um grande projeto, então não acho que o K8s atenda às minhas necessidades, pois é descrito como uma ferramenta não fácil. apenas para equipes profissionais de médio / grande porte e realmente não para um indivíduo que tem pouco tempo e faz tanto o desenvolvimento (front / back end) quanto a implantação. Então, imaginei que ainda houvesse um lugar para o Docker, mas, talvez por causa da falta de problemas de fusão de que ouvi falar, as coisas deveriam ficar mais claras sobre a forma oficial preferida de implantar aplicativos e seus planos para o sucessor da máquina docker ou se eles não tenho um plano sobre isso.

Eu ainda acredito que deve existir uma ferramenta (feita pela comunidade ou pelo docker) que provisione DOCKER_HOST etc. e simplesmente use a chave SSH. Seria mais fácil do que "scp" e "ssh".

Basta fazer export DOCKER_HOST=ssh://[email protected]

Observe que se você desativou o login do ssh para o usuário root , pode usar um usuário não root user via
export DOCKER_HOST=ssh://[email protected] depois de adicionar user ao grupo docker usando sudo usermod -aG docker user . (testado no Ubuntu 18.04)

Alguma alternativa para brincar com o Docker Swarm de vários nós no Windows? O tutorial do swarm afirma que atualmente isso não é possível no Windows sem a máquina Docker:

Atualmente, você não pode usar Docker Desktop para Mac ou Docker Desktop para Windows sozinho para testar um enxame de vários nós. No entanto, você pode usar a versão incluída da máquina Docker para criar os nós do swarm (consulte Primeiros passos com a máquina Docker e uma VM local) e siga o tutorial para todos os recursos de vários nós.

Eu uso https://multipass.run/ para fazer rapidamente várias VMs do Ubuntu. Tão rápido quanto a docker-machine. Veja uma demonstração de como eu o uso para um Swarm de 3 nós: https://www.pscp.tv/BretFisher/1mrGmQvNEWBGy?t=

Seu uso de desktop foi suplantado principalmente por nosso produto Docker Desktop.

Observação para todos neste tópico: o Docker Desktop não é um software livre, não é de código aberto e tem uma tonelada de spyware embutido, então você pode querer pensar duas vezes antes de seguir o caminho de atualização.

Caso isso possa ser útil para alguém, aqui está um script para instalar o docker em um host remoto (testado no Debian 10 = buster):
https://github.com/minireference/sample-book/blob/master/fabfile.py#L213 -L252

É baseado na estrutura de automação de servidor chamada Fabric (especificamente fab-classic github e docs ]. Mesmo se você não quiser usar o Fabric, pode facilmente ler os comandos e executar manualmente para transformar em um script bash, já que nada sofisticado.

Depois disso, execute export DOCKER_HOST=ssh://[email protected] e volte ao modo como as coisas eram ao usar a máquina docker.

Observação para todos neste tópico: o Docker Desktop não é um software livre, não é de código aberto e tem uma tonelada de spyware embutido, então você pode querer pensar duas vezes antes de seguir o caminho de atualização.

@sneak "toneladas de spyware" você está se referindo à configuração de Preferências "enviar estatísticas de uso", que diz "Enviar relatórios de erros, versão do sistema e idioma, bem como informações de ciclo de vida do Docker Desktop (por exemplo, inicia, pára, redefine).", que pode ser desligado?

Não estou interessado em perder mais tempo discutindo spyware proprietário de código fechado.

troll de baixa qualidade

Trolling requer subterfúgios. Estou sendo sincero e minhas declarações são precisas:

• docker desktop é proprietário

• docker desktop é um software com código fechado

• docker desktop espia seus usuários sem obter consentimento para fazê-lo (assim como a máquina docker)

A partir desses pontos acima, uma pessoa razoável pode, portanto, concluir que a Docker-the-company não se preocupa com a liberdade do software, privacidade do usuário ou consentimento do usuário para vigilância.

Estou no GitHub e em outros sites semelhantes para trabalhar com software livre e open source, e projetos não gratuitos como docker desktop são simplesmente uma distração do trabalho com software livre que beneficia a todos; Não desejo desviar meu tempo ou atenção para essas coisas.

Faria bem em abordar os problemas diretamente, em vez de recorrer a ataques pessoais. Silenciando este tópico agora, tenha um bom dia.

Caso isso possa ser útil para alguém, aqui está um script para instalar o docker em um host remoto (testado no Debian 10 = buster):
https://github.com/minireference/sample-book/blob/master/fabfile.py#L213 -L252

É baseado na estrutura de automação de servidor chamada Fabric (especificamente fab-classic github e docs ]. Mesmo se você não quiser usar o Fabric, pode facilmente ler os comandos e executar manualmente para transformar em um script bash, já que nada sofisticado.

Depois disso, execute export DOCKER_HOST=ssh://[email protected] e volte ao modo como as coisas eram ao usar a máquina docker.

@ivanistheone NÃO, não é. docker-machine é (era?) Ótimo porque também implementa todas as APIs em vários provedores de nuvem para criar máquinas na CLI de maneira uniforme. Claro, há gcloud , az , etc., mas cada um deles tem opções e semânticas diferentes. docker-machine é um CLI para todos eles. Isso torna o trabalho com nuvens híbridas um pouco mais fácil ...