Machine: Docker Machine is now in maintenance mode

Oh :(

Well this was nice while it lasted :)
Thx everyone for the good work !

I would ask that you also update the readme.md

If official support for machine is closing, what is the likelihood for continued community-driven support in this repo?

for those of you needing machine, there is some activity in the https://github.com/machine-drivers organisation, and it may make sense for you to work on, and release from https://github.com/machine-drivers/machine...

We have already looked into adding patches to this organisation, as they seem to be held from being merged here: #4509 (This is blocking for localized versions of Windows). Best is to move ahead with some form of releases, however for us: minikube and minishift we only need to link against a library.

@shin- As a thought, the new user "Getting Started" docs still use docker-machine as a central part of the intro.

For people interested in updating the docs, which should they walk people through instead?

• Windows: Seems like Docker Desktop for Windows
• Mac: Seems like Docker Desktop for macOS
• Linux: Keep using the Machine docs?

I think that this really is a shame. The real power of machine was somewhere between the simplicity of getting things work on one machine using Desktop and the complexity behind infrakit. machine was perfect to fire up a few machines for testing distributed workloads at smaller scale.

Hi!

Does somebody have an alternative software for Linux? I don't want to run docker as root on my host machine and docker-machine was giving some isolation in this respect. Is there any plan for Docker for Linux?

Thanks!

@gilbsgilbs You can still use docker-machine as you currently do!

@shin- Thanks for your suggestion. I'm starting a new project, so using docker-machine for it would be a weird move, wouldn't it?

@shin- Weelll... being closed to PR's kind of means using it for new projects is probably a bad idea. :wink:

@justinclift I don't want to get into too much detail because we've got more info coming in a prepared statement, but as I tried to state in the original post, the project is not closed to PRs; we're simply looking to limit those to bugfixes as opposed to new features. If the featureset of the current iteration of docker-machine fits your needs, there is no reason to abandon it, even for new projects.

It looks like infrakit is not active either. There were no releases for more than a year, no update on DockerCon 2018, no user documentation similar to https://docs.docker.com/machine/

Docker machine documentation suggests to try Docker Cloud which in turn is shutting down in favor of Docker EE (which is not generally available)

It all encourages to either fork the project or look elsewhere: https://landscape.cncf.io/grouping=landscape&landscape=infrastructure-automation&sort=first-commit

Not complaining, just describing my perspective.

Interesting. Looking at the commit history for InfraKit, although it does receive new commits every few days, it mostly appears to be a one-man effort.

Activity seems to have dried up around April/May. Guessing people's time was redirected to other stuff.

Is that an incorrect way of looking at things?

@shin- but many of the PRs (like bugfixes I provide to make internationalization on Hyper-V working) have not been taken for merge. This is not a good indication of "we're simply looking to limit those to bugfixes as opposed to new features" in light of "there is no reason to abandon it, even for new projects".

@shin-

I don't want to get into too much detail because we've got more info coming in a prepared statement

Could you link to that official statement (whenever it is published?) I can't find it.

I strongly recommend changing the docs so that they are up to date.
My last hour was a senseless exploration of boot2docker, which clearly points to docker machine, which has a warning on its main page advising to use docker cloud as an up to date technology. This points to the Docker cloud doc description (not the migration page!!!!), which required me some googling to find out it was discontinued in May (but announced in March, so 7 months ago). Now came here to suggest removing the warning from the docker machine doc, I find out in this 3 months old issue docker machine is also being discontinued.
This is just not how documentation should work. I'll revert back to some ad hoc solution, but I'd abandon docker if I wasn't already using it.

@aliceminotto It would help us all update outdated doc's if you could point to the sites or pages you're talking about.

docker-machine isn't going away, it's just not increasing the scope of features.

Docker Cloud isn't going away, it's just no longer used for server provisioning/management. It's still there for image building. Docker has other tooling for production servers like Docker for AWS, Docker for Azure, and DCI for Docker Enterprise.

I had forgotten entirely about the old http://boot2docker.io website and didn't realize the notice there was worded so poorly (apologies for any confusion that contributed to!) -- I've now updated (and slimmed down) that content to hopefully clarify better that boot2docker the ancient CLI tool is what was deprecated in favor of Docker Machine and that boot2docker the distribution is not deprecated but is rather in maintenance mode (same as Docker Machine).

To put that another way: new Docker releases, kernel updates, etc, but concerted attempts to keep new features/functionality to an absolute minimum to ensure continued maintainability for the few folks who can't yet transition to the better-suited Docker for Windows / Docker for Mac products or the production server tooling / solutions referenced above (Windows 7 users who can't Docker for Windows at all, Windows 10 Home users who thus can't Hyper-V, VirtualBox users who thus can't Hyper-V, etc etc).

@tianon : you might also want to mention Linux users who don't want to transition to Mac or Windows...

@afbjorklund Why do you need boot2docker if you're already using Linux?

@Vanuan : either because your distro was too old (e.g. RHEL6), or because you weren't allowed root...

Either way, transitioning to Docker Desktop is _not_ an option - it's either Docker Engine or DIY LinuxKit ?

I would like to thank the makers of docker-machine and boot2docker, for making docker more acessible.

And with the effort of machine-drivers (for KVM), hopefully it will continue working for a while longer still

Why would I use server distro for desktop? And why I'm not administrator of my desktop? But somehow I'm allowed to access KVM?

It looks like you're looking for solution to run docker on KVM server? If that's the case, I'm currently exploring infrakit here: https://github.com/docker/infrakit/issues/913

But if you're only looking to run docker on Linux desktop I don't get why wouldn't you install latest Ubuntu along with Docker CE. If you want to run it in VM then do so. You can mount your home directory in VirtualBox and use docker over SSH. What's the problem here? There's no Docker for Linux Desktop because it doesn't make sense. At least to me.

Why would I use server distro for desktop? And why I'm not administrator of my desktop? But somehow I'm allowed to access KVM?

Some people have to use whatever desktop OS their employer hands them. RHEL6 is an example that I've (a few months ago) been told about by a guy working in a stock trading place. :wink:

As a general data point, with Libvirt it (at least used to) have a concept of VM's that users could run in their account, that would be just for them. eg not accessible to other people logged into the same machine

Not sure if that was ever developed in any depth, as most of the Libvirt development effort went towards "system level" VM things instead of user level.

if you're only looking to run docker on Linux desktop I don't get why wouldn't you install latest Ubuntu

Quite a few people dislike Ubuntu for one reason or another. :wink:

Starting with v18.09 (DOCKER_HOST=ssh://), setting up remote Docker machines without docker-machine is really trivial: https://medium.com/lucjuggery/docker-tips-access-the-docker-daemon-via-ssh-97cd6b44a53

As a general data point, with Libvirt it (at least used to) have a concept of VM's that users could run in their account, that would be just for them. eg not accessible to other people logged into the same machine

Yes, its called qemu://session
Latest GNOME even has a nice app for that - Boxes: https://en.wikipedia.org/wiki/GNOME_Boxes

User mode KVM virtualization has some drawbacks wrt networking. So I think Virtualbox is the only choice in those conditions.

And to have CLI for VirtualBox the choice is vagrant. You only need some Linux distribution to run docker on top of it. And the most battle tested is Ubuntu/Debian. You can download any other distro though. But you have to package it yourself to use with Vagrant: https://www.vagrantup.com/docs/virtualbox/boxes.html

Just saying that docker-machine was a good solution for those Linux users, just as it was for users of old Mac and old Windows... All that it needed was to run docker on a non-standard port, instead of hardcoded 2376 ? And a new qemu driver that didn't require libvirt group (i.e. root). Maybe infrakit/hyperkit will be an alternative in the future, but at the moment (the link above) it looks _quite_ rough around the edges still.

@Vanuan : I know about the ubuntu/vagrant options, I just referred to it simply as "Docker Engine" above.

@justinclift : each user gets their own ssh keys/docker certs, so the machines are reasonably separated.

@afbjorklund No worries. It's been years since I worked at Red Hat on the Libvirt team. These days I generally just use it when diagnosing issues, rather than still being super in-depth with it. :smile:

@afbjorklund Let's clear this up.

you might also want to mention Linux users who don't want to transition to Mac or Windows...
Either way, transitioning to Docker Desktop is not an option - it's either Docker Engine or DIY LinuxKit ?
I know about the ubuntu/vagrant options, I just referred to it simply as "Docker Engine" above.

boot2docker is both distribution (boot2docker.iso) and the tool to manage virtualbox (boot2docker-cli). boot2docker.iso includes Docker CE (former Docker Engine):

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

And this will keep updated to new Docker CE releases.

The boot2docker-cli is gone, but in essence it's just vagrant with virtualbox. Vagrant is still around.

Docker-machine with KVM driver uses boot2docker.iso to provision _Docker CE_ to new libvirt VMs.

Docker Desktop uses distributions built with linuxkit to provision _Docker CE_ to Hyper-V and xhyve.

To picture it all:

So as you can see, all the solutions include Docker Engine (currently called Docker CE for Linux) in one way on another.

There are just too many environments and virtualization/cloud solutions. Consequently there's no one tool that can work equally well on windows/mac/linux and support QEMU/Virtualbox/xhyve/Hyper-v along with different clouds and over-SSH provisioning. And such tool also needs configurability: support different ports, memory/cpu resource management, networking, etc. So probably a general purpose tool along with some configuration file downloaded over http would be the best solution.

@Vanuan : yes, this what we said above. In order to replace docker-machine, you need to switch to Mac or Windows and Docker Desktop - at least until _someone_ creates something similar with LinuxKit and libvirt...

We don't need to talk about boot2docker-cli anymore, and the support for Linux drivers has _already_ moved to the "machine-drivers" organization - as only VirtualBox is available with the standard docker-machine.

@shin- If you're not allowing new features anymore, please consider adding a very clear note at the top of the README.md AND CONTRIBUTING.md.

It's quite annoying to read both of those files carefully, implementing a driver (several days of work) and not realizing that you guys will never merge any driver anymore. This should be way clearer.

If this is all a misunderstanding and I'm still allowed to pull request my driver, please let us know. It's just that at the moment it's only mentioned in a hidden file that people will see once they create the pull request.

There is still no clear info about maintenance mode in README.md and/or CONTRIBUTING.md. I spent half of my holiday time to figure out working solution for ProxmoxVE VM creation and lightweight Linux for Docker deployment - I found combination of docker-machine + docker-machine-driver-proxmox-ve to work pretty good for that use case. Unfortunately it rely on boot2docker, which say it is deprecated in favor of docker-machine and maintainer on some thread suggest Rancher OS. docker-machine going maintenance mode without clearly defining what that means (saying only bug-fixes would be accepted and suggesting that it is fine for new projects is IMO in contradiction). There was also official announcement mentioned in August 2018, but no signs of any reference here.

From outsider perspective, that want to build reasonable infrastructure for SMB, docker-machine doesn't look like correct long term solution. Anyone can suggest what would be Reasonably Good™ for provisioning and managing ProxmoxVE VM as hypervisor and minimal Linux supporting Docker?

Unfortunately it rely on boot2docker, which say it is deprecated in favor of docker-machine and maintainer on some thread suggest Rancher OS.

Can you please be more specific to where boot2docker is claiming to be deprecated in favor of docker-machine so I can clarify that appropriately? (because it isn't true unless you're referring very specifically to the ancient boot2docker CLI tool that hasn't been actively maintained in years now)

The boot2docker distribution (specifically, the boot2docker.iso artifact released with every new release of Docker CE) is not going away any time soon that I'm aware of, although it does have a very narrow focus now (and thus new features/functionality are not likely to be considered for merging).

@tianon You are right, I'm sorry for confusion. The message on website say boot2docker CLI - at first glance it was not clear to me if there is any difference. I'm pretty sure other users also can be confused, since most likely you will face boot2docker.iso. boot2docker CLI is something you never heard of it is hard to say what is the relation between projects. OTOH boot2docker.iso statement "maintenance mode" is vague in the same way as docker-machine, which I conclude based on this reply.

To sum up confusion:

1. "maintenance mode" - is not clear in both projects, can I use that for production in small business?
2. both projects lead developers/maintainers suggest use of other projects that seems to not cover all use previously supported use cases

Ideally would be to have clear statement from @tianon and @shin- if use of docker-machine is fine for production?

I can't speak for Docker Machine, but boot2docker has never been a good choice for production; its target is development / personal workstation use.

See also the added notes on https://github.com/boot2docker/boot2docker#readme, where I've tried to clarify both what we mean by maintainance mode and that b2d is not intended nor recommended for production workloads.

Same as many others, I was frustrated to learn about this from Github Issues, after I put effort into using machine for a SMB client

I've created a PR to update the official documentation, adding an advisory about machine's maintenance mode.

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

It'd be nice to change the docker getting started too https://docs.docker.com/get-started/part4/

edit: Found a solution which is to install docker-ce on the aws ec2 instance, and then ssh port forward the docker daemon.

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

🎉

I started using docker-machine recently because it was installed with Docker Desktop and I realized I could have docker run on aws instances far more powerful than my local machine. The beauty is that local apps that use docker commands, like Visual Studio Code, can work with docker-machine containers just as if they were running locally.

It seems to me that docker-machine has not been superseded, so much as just there are many new ways to provision clusters including infrakit, kubernetes, etc.

I could be misunderstanding. Is there a migration strategy for doing what I described above?

We use GitLab, with their GitLab Runner tool to dynamically provision EC2 Spot instances for running CI/CD jobs. GitLab Runner uses Docker Machine to perform this machine provisioning.

We've decided to move all services off (bloated) Ubuntu in favor of Amazon Linux 2. To my delight, PR #3609 would allow for this.

However, because of this "closing of the faucet", #3609 seems like it'll die in place. Please consider merging it, in its present non-conflicting, mergeable state.

Since the guys at Gitlab are already maintaining a fork, maybe they could be interested in taking care of this repo?

@usha-mandya @Dawn-Wood any update on docker/docker.github.io#9239? As a reminder, it adds advisory warnings on all Docker Machine pages. This was merged, but then reverted while the enterprise split was happening so yall could make some decisions on the future of DM. Would be good to have this advisory if DM is going to continue being in maintenance mode

AFAIK, the latest version of Docker Desktop no longer includes docker-machine

AFAIK, the latest version of Docker Desktop no longer includes docker-machine

Just learned about this issue that way, as our internal docker-machine tooling stopped working after the update to docker for desktop 2.2.0.0

It is kind of irritating this move is not mentioned in the docker for desktop release notes either.

We heavily use docker-machine to manage and maintain shared booot2docker-based docker-machines for internal DEV and staging environments using the Hyper-V driver (so, we provision boot2docker hyper-v VMs using docker-machine). So even though we have linux and mac clients and thus use docker for windows / os x, we still heavily rely on docker-machine for our CI/CD stuff.

I'm not aware of any similar replacement for this setup - am I missing something obvious here?

You can always download the latest binary with brew (macOS) and directly
from the repo. It's still being maintained (patches) but being slowly
phased out of tools like Docker Desktop.
https://github.com/docker/machine/releases

On Mon, Jan 27, 2020 at 11:47 AM sambernet notifications@github.com wrote:

AFAIK, the latest version of Docker Desktop no longer includes
docker-machine

AFAIK, the latest version of Docker Desktop no longer includes
docker-machine

Just learned about this issue that way, as our internal docker-machine
tooling stopped working after the update to docker for desktop 2.2.0.0

It is kind of irritating this move is not mentioned in the docker for
desktop release notes either.

We heavily use docker-machine to manage and maintain shared
booot2docker-based docker-machines for internal DEV and staging
environments using the Hyper-V driver (so, we provision boot2docker hyper-v
VMs using docker-machine). So even though we have linux and mac clients and
thus use docker for windows / os x, we still heavily rely on docker-machine
for our CI/CD stuff.

I'm not aware of any similar replacement for this setup - am I missing
something obvious here?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/docker/machine/issues/4537?email_source=notifications&email_token=AAGBNX2APIHK6CBNGSAMLDDQ74FYPA5CNFSM4FJ53G3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKAGK7Y#issuecomment-578839935,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGBNXZV7PCYP3TLWSZ7QODQ74FYPANCNFSM4FJ53G3A
.

I also learned that docker-machine is phased out the hard way last week 😒
On docs.docker.com it says that docker-machine is "superseded" but I can't find any information about what it is superseded by. I want to keep managing my local virtualbox machines with SOMEthing, any tips on how to do that in a future-proof way?

export DOCKER_HOST=ssh://user@host may work for you

I want to keep managing my local virtualbox machines with SOMEthing, any tips on how to do that in a future-proof way?

You can use Vagrant for that perhaps ? Or you could just continue to use docker-machine...

But you would have to come here for the binaries, since it is no longer a part of Docker (Desktop)

I'm not aware of any similar replacement for this setup - am I missing something obvious here?

There is no replacement, but lots of people are interested in continued use of machine and libmachine.

Of course there are _alternatives_ (different products), but that is not really the same thing (as the forks).

@afbjorklund Well I hope docker-machine will stick around... and I would love to get it directly from here, but for some reason downloads from github are suuuuuper slow for me. The first 10-12 MB come through in a few seconds (as I expect with my pretty fast line), then it goes down to 1-2kB/s and fails eventually. I know this is kind of off-topic, but I'm confident that it's not my line, is github throttling things for some reason maybe?

If it's not just something that's happening for you right now (only), then probably best to ping GitHub Support about it.

I'm extremely confused about what's the preferred way to simply deploy my containers.
Making containers through Docker is promoted as a standard, widely used way to create services. So that's what I used to make containers for the website I'm creating right now.
But then I very obviously need to deploy these containers to my VPS. So I use docker-machine as it is the only documented, not actually deprecated, way I know of to do this. And now I learn it is in "maintenance mode" so I may not want to use it in a new project but what's infrakit ? There is 2K stars but I struggle to understand what is it for (and can it replace docker machine in a simple way) or official documentations and it is now in read-only mode (archived) so I feel like I should not even use it and there is no link in this repo Readme/issues to a new repository. Why is there no documentation and is discontinued if it replaces docker machine.
Docker seems such a popular solution yet I can't find a single one non discontinued (or in "maintenance mode") way to deploy my containers. If docker is so widely used how do the possibly millions of devs working with it deal with deploying their application ??

I think originally, Docker promoted Docker EE, its paid version, as an official way to deploy containers. So they nixed Docker machine and Infrakit initiatives as it threatened their business model.

In addition, k8s completely changed the landscape and Docker struggled to adapt.

Now, that Mirantis acquired Docker EE, Docker seeks another business model. I think a new direction is trying to inject application bundles into k8s ecosystem and leaving k8s deployment itself up to community. Especially since k8s is not a part of Docker CE (on Linux).

K8s, OTOH is managed by Google, which has all the incentive to make K8s deployment so complicated that people would just literally say "Hey, Google, please install K8s cluster for me". Thus locking in to Google cloud services.

So the vision of Solomon Hykes of freeing the cloud from lock-in and making the cloud a commodity has miserably failed.

@NitroBAY Because the "software lifecycle" from code-creation to apps running on servers (and eventually updated on servers) is so complex, with a ton of varying ways of "getting container images built and downloaded to servers", it's hard to say what your solution should be.

Originally, docker-machine was to do three things:

1. provision simple VM's on the major cloud providers, or a local machine VM manager (VirtualBox, Hyper-V, VMWare, Parallels, etc.)
2. install docker on that VM, including a self-signed cert and opening the API TCP port
3. easy ssh to that server, and controlling docker remotely with the docker cli (docker-machine env)

(let's forget about legacy features like creating a classic swarm)

With the first one "creating a Linux VM": I recommend you replace it with your cloud's tool of choice for how they create VM's. If it's local and you want something faster then installing a Linux VM, check out multipass, which is my favorite way to spin up a new Ubuntu VM in minutes with a single command.

With the second one "installing docker on a Linux VM": you can install docker on any modern VM using the install script or the official docs for your OS distribution. Most clouds have an official image with docker already in it, as an option.

Docker was never able to solve all your CI/CD problems, and docker-machine is really just a VM provisioning and basic install tool, so many people needed a more flexible and maintainable solution (for example, docker-machine doesn't easily share server configs between machines). The Docker team never meant for the machine tool to solve all those problems. It still works today for those original things, so feel free to use it as long as it works for you. I still use it monthly, and have since 2015.

Maybe if you detailed a specific problem that docker-machine solved, we could recommend specific alternatives you could implement.

For example with regards to #3 above "control docker remotely", I always liked that docker-machine would provision a self-signed certificate for API authentication and allow me to change my docker env locally so it could control the remote server. That legacy method has been replaced with the much easier (and more flexible and secure) SSH tunnel build-in method for the docker CLI since 2018. It means that all you need is the ability to SSH to a server, and you can tell your local docker cli to use that rather than the traditional "open docker TCP socket". This gives me the ability to never have to manually SSH to a server running docker just to "docker run". I just need to tell my local docker CLI where to connect to via one of two methods: I have a quick demo of it here using the DOCKER_HOST env method, and we had a demo on my live show last summer of the new context feature, which lets you store a list of docker servers right in the docker CLI and use SSH or TCP to control them remotely.

Also, InfraKit is a tool for system builders (ppl who create custom Linux OS's), not Linux users like us who want a normal Linux distribution created with our hoster and to install docker on it.

Wow @BretFisher thanks a lot for your very detailed answer. I'm sure it will be considered also a golden gift by future people who will read you.
For the record I ended up create a script uploading my config.json on the remote machine (so it could download my private image) and the compose file. And then executing "docker stack deploy"
My deploy sh looks like this

#!/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 is not needed obviously, I just happen to have different subdomains based on the Git branch that trigger my script (I use CI/CD))
And I still use docker-machine create to have docker on my ubuntu remote VPS.

Anyway docker machine is NOT a good idea on CI/CD because sharing certificate is not easy (it is a whole folder) and regenerating certificate may stop Docker so it's not an option either.

I still believe a tool should exist (made by the community or by docker) that'd provision DOCKER_HOST etc. and simply use SSH key. It would be easier than "scp" and "ssh".

Docker machine turned out not to be unavoidable.

I'm not a professional, I'm just someone who learned on my own web programming and who's working on my side time on a big project so I don't think K8s fits my need as it's described as a not easy tool, meant only for at least medium/large professional teams and really not for one individual who has little time and do both the development (front/back end) and the deployment. So I guessed there was still a place for Docker but, maybe because of their lack of fuding problem I've heard about, things should be clearer about the official preferred way to deploy apps and their plans for the successor of docker machine or if they don't have a plan about that.

I still believe a tool should exist (made by the community or by docker) that'd provision DOCKER_HOST etc. and simply use SSH key. It would be easier than "scp" and "ssh".

Just do export DOCKER_HOST=ssh://[email protected]

Note if you have ssh login disabled for root user, you can use a non-root user user via
export DOCKER_HOST=ssh://[email protected] after you add the user to the docker group using sudo usermod -aG docker user. (tested on Ubuntu 18.04)

Any alternative for playing around with multi-node Docker Swarm on Windows ? The swarm tutorial states that currently this is not possible on Windows without Docker Machine:

Currently, you cannot use Docker Desktop for Mac or Docker Desktop for Windows alone to test a multi-node swarm. However, you can use the included version of Docker Machine to create the swarm nodes (see Get started with Docker Machine and a local VM), then follow the tutorial for all multi-node features.

I use https://multipass.run/ to quickly make multiple Ubuntu VM's. Just as fast as docker-machine. See a demo for how I use it for a 3-node Swarm: https://www.pscp.tv/BretFisher/1mrGmQvNEWBGy?t=

Its desktop usage has mostly been supplanted by our Docker Desktop product.

Note to everyone in this thread: Docker Desktop is not free software, is not open source, and has a ton of spyware embedded in it, so you might want to think twice about following that upgrade path.

In case this might be helpful for someone, here is a script to install docker on a remote host (tested on Debian 10 = buster):
https://github.com/minireference/sample-book/blob/master/fabfile.py#L213-L252

It's based on the server automation framework called Fabric (specifically fab-classic github and docs]. Even if you don't want to use Fabric, you can easily read the commands and run manually turn into a bash script, since nothing fancy.

After that, run export DOCKER_HOST=ssh://[email protected] and it's back to the way things were when using docker machine.

Note to everyone in this thread: Docker Desktop is not free software, is not open source, and has a ton of spyware embedded in it, so you might want to think twice about following that upgrade path.

@sneak "ton of spyware" are you referring to the Preferences setting "send usage statistics" which says it "Send error reports, system version and language as well as Docker Desktop lifecycle information (e.g., starts, stops, resets).", which can be turned off?

I’m not interested in spending time discussing proprietary, closed-source spyware further.

low quality troll

Trolling requires subterfuge. I'm being sincere, and my statements are accurate:

• docker desktop is proprietary

• docker desktop is closed source software

• docker desktop spies on its users without obtaining consent to do so (as does docker machine)

From these above points, a reasonable person might thus conclude that Docker-the-company doesn't care about software freedoms, user privacy, or user consent to surveillance.

I’m on GitHub and other sites like it to work on free software and open source, and nonfree projects like docker desktop are simply a distraction from working on free software that benefits everyone; I have no wish to divert my time or attention to such things.

It would do you well to address the issues directly rather than resorting to personal attacks. Muting this thread now, have a nice day.

In case this might be helpful for someone, here is a script to install docker on a remote host (tested on Debian 10 = buster):
https://github.com/minireference/sample-book/blob/master/fabfile.py#L213-L252

It's based on the server automation framework called Fabric (specifically fab-classic github and docs]. Even if you don't want to use Fabric, you can easily read the commands and run manually turn into a bash script, since nothing fancy.

After that, run export DOCKER_HOST=ssh://[email protected] and it's back to the way things were when using docker machine.

@ivanistheone NO it's not. docker-machine is (was?) great because it also implements all the APIs at various Cloud providers to create machines at the CLI in a uniform way. Of course, there is gcloud, az, etc. but each of them have different options and semantics. docker-machine is one CLI to all of them. It makes working with hybrid clouds a tad bit easier...