New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Attach to existing machine from another client #1328

Open
AlexZeitler opened this Issue Jun 8, 2015 · 82 comments

Comments

Projects
None yet
@AlexZeitler

AlexZeitler commented Jun 8, 2015

Lets consider I created a machine on Digital Ocean running some containers.
After creating the machine, I can run eval "$(docker-machine env test-machine)"
Now I'm moving to another local computer which does not know about that particular machine and I want to attach to that machine.
How do I do that?

@Oliboy50

This comment has been minimized.

Oliboy50 commented Jun 8, 2015

👍

@clnperez

This comment has been minimized.

Contributor

clnperez commented Jun 10, 2015

How about adding it to the 2nd system using the 'generic' driver, and then use the same eval command there?

@Oliboy50

This comment has been minimized.

Oliboy50 commented Jun 10, 2015

@clnperez is this a proposal or something you're confident that it work (means that will reuse the existing remote machine even if currently running)?

@clnperez

This comment has been minimized.

Contributor

clnperez commented Jun 10, 2015

Well, in hindsight, I don't think you can do this b/c you'd have to set up the ssh keys again, or import them from your other system.

@ljrittle

This comment has been minimized.

ljrittle commented Jun 10, 2015

I see your case. One can't add a docker-machine entry on the second system using the generic driver unless you want to invalidate the original docker-machine setup (since e.g. new creds are generated). One may run docker-machine create -d none --url [...] on the second system mirroring important options (like the swarm flags) from the original create on the first system and then manually copying selected .pem files and the id_rsa file from the first machine to the second machine AND manually add sections for SSH access (and manually change the driver to generic from none). It is a PITA. A proper export/import function would be nice to allow sharing. One can also share just the cred files needed to manually configure docker.

@ehazlett

This comment has been minimized.

Member

ehazlett commented Jun 11, 2015

Correct. The only current way would be to take the entire directory but this won't work with some drivers (i.e. VirtualBox because it registers VMs and networks with UUIDs that would not match). There has been discussion around an import/export feature in the past (#23)

@nathanleclaire

This comment has been minimized.

Contributor

nathanleclaire commented Jul 6, 2015

I have a PR/hacky solution to this in the wings... Generally I think I want to move config over to being portable / templated instead of hardcoded like things are now.

@jcmoore

This comment has been minimized.

jcmoore commented Jul 13, 2015

+1

I would love to be able to quickly reconnect to cloud instances (I'm using GCE) that already exist.

Certainly having importable/exportable configs would be very useful, but I wonder if (additionally) addressing the issue as a driver concern might not yield a simpler user experience.

That way, using the google driver, one could connect to an existing instance on an alternate computer simply by providing a valid access-token (which the driver may prompt the user to generate automatically).

Similarly, when using the aws driver for instance, (which I have yet to do myself, but I presume) one could connect to an existing instance by providing a valid key/secret pair (perhaps through environment variables corresponding to the relevant driver-specific flags -- assuming that the process will occur through some docker-machine subcommand other than "create", since the expectations are a bit different).

@robwhess

This comment has been minimized.

robwhess commented Jul 29, 2015

Just want to chime in that this would be a really great feature to have. I'd really like to be able to share a machine with my teammates and was disappointed to find out there was basically no way of doing this right now. It'd be awesome if, e.g. the generic driver could automatically detect whether a particular box had already been provisioned with docker-machine and re-use tls certs, etc. when someone ran docker-machine create on that box again.

@potiuk

This comment has been minimized.

potiuk commented Aug 13, 2015

:+1 . I would love to see it working. Currently we are co-managing the same machines (on Google Compute Engine) with another person and the only way I found working is to copy the whole directory (+ change the absolute links in the config.json file). That's lame. I think generic driver cannot be used easily this way - there is an issue of authentication of course (tls certs etc.) cannot be simply re-used when you run --create with generic driver (somehow you need to authenticate and prove that you have access to the machine which is different for every driver - in GCE you'd have to check if your gcloud authentication allows you to access the machine). Also there is a small issue that unless you already created the machine before with given driver, your authentication piece is missing (the only way to authenticate is to .. create machine).

What I think is the best solution is to have "import" command (with different implementation for different drivers). For example in GCE, you could store all necessary details (keys etc.) somewhere in meta-data of the machine: https://cloud.google.com/compute/docs/metadata?hl=en#project_and_instance_metadata and then via specifying the project/machine name (and authenticating) you could get all the necessary keys and setup the machine.

@miguelpuyol

This comment has been minimized.

miguelpuyol commented Aug 25, 2015

I would really appreciate this feature!

@AlexZeitler

This comment has been minimized.

AlexZeitler commented Aug 31, 2015

@potiuk Which directory do you copy?

@AlexZeitler

This comment has been minimized.

AlexZeitler commented Sep 2, 2015

@AlexZeitler ~/.docker/machine/machines/<machinename>

@vovimayhem

This comment has been minimized.

vovimayhem commented Oct 3, 2015

+1!

@goloroden

This comment has been minimized.

goloroden commented Oct 3, 2015

+1 I'd love to see a solution for this, too :-)

@olibob

This comment has been minimized.

olibob commented Oct 13, 2015

I ran in exactly that problem today to give access to a colleague.

@uptownhr

This comment has been minimized.

uptownhr commented Oct 13, 2015

+1 !!!!!

@Oliboy50

This comment has been minimized.

Oliboy50 commented Oct 14, 2015

Seems to be a duplicate of #23, right?
Almost 1 year since we talk about this feature, some have tried to make PRs for it, but they were closed...
Hope this feature will be on the next (major) release :)

@rbabayoff

This comment has been minimized.

rbabayoff commented Oct 16, 2015

This is absolutely required in continuous delivery scenarios, where you want to deploy using those keys from Travis or Circle CI. Any clue regarding ETA?

@bhurlow

This comment has been minimized.

bhurlow commented Nov 8, 2015

gotta give this a +1 as well

@micheletedeschi

This comment has been minimized.

micheletedeschi commented Dec 2, 2015

+1

@jbasrai

This comment has been minimized.

jbasrai commented Dec 8, 2015

+1

Is there anything you have to do besides copying the ~/.docker/machine/machines/<name> folder and changing the absolute paths? I get an error message related to my certs, and attempting to regenerate them fails as well.

@nathanleclaire

This comment has been minimized.

Contributor

nathanleclaire commented Dec 8, 2015

@jbasrai Did the IP of what you're trying to access change?

@nathanleclaire

This comment has been minimized.

Contributor

nathanleclaire commented Dec 8, 2015

I've filed #2516 to start considering steps in the right direction to make this easier.

@jbwinters

This comment has been minimized.

jbwinters commented Jan 22, 2016

This is a vital feature, and I'd love to see it in a near-future release. In my opinion machine configuration should remain unique to a client, not be imported/exported. Instead (as others have mentioned) docker-machine create run with the same arguments should be able to create a configuration for the machine even if it already exists remotely instead of failing like it does now. When re-running my create command for an existing amazonec2 machine, I get this error telling me that the host already exists:

Error creating machine: Error with pre-create check: There is already a keypair with the name testing-recreate.  Please either remove that keypair or use a different machine name.

Instead it might warn me that the host already exists and continue to add the machine as it would in an initial creation (perhaps requiring that an override flag be passed). That way I can keep my dev/CI environment set-up scripts simple and not worry about having to store this configuration somewhere that my teammates (or other parties) can access it.

@thib-rdr

This comment has been minimized.

thib-rdr commented Feb 4, 2016

It is indeed astonishing that for multiple persons to work on the same vm, we have to export/import certificates from one machine to another. If someone found a practical, production-ready solution, that would be good to know.

@Pierre-Gilles

This comment has been minimized.

Pierre-Gilles commented Feb 4, 2016

+1

1 similar comment
@rm25282

This comment has been minimized.

rm25282 commented Feb 5, 2016

+1

@derFunk

This comment has been minimized.

derFunk commented Feb 14, 2017

Being only able to control docker-machine from one host is an uncomfortable limitation.
I'd also love to see something like docker-machine config-from <otherhost>.

So +1 from me as well.

/Edit: I'm currently solving the problem by syncing the .docker from a "master server" to all other servers which need the same configs - via cron and rsync. This is e.g. needed for multiple build slaves. Not a very nice solution.

@rudkov

This comment has been minimized.

rudkov commented Mar 3, 2017

+1

@ghost

This comment has been minimized.

ghost commented Mar 10, 2017

Here's a different scenario which brings me here.

I created a droplet to build a bunch of docker images to later realise I need to move host region...

The question is how do I attach the docker-machine instance restored from the snapshot running on the new host?

@davad

This comment has been minimized.

davad commented Mar 10, 2017

@ifeltsweet

This comment has been minimized.

ifeltsweet commented Apr 4, 2017

+1

7 similar comments
@AshleyAitken

This comment has been minimized.

AshleyAitken commented Apr 10, 2017

+1

@inakrin

This comment has been minimized.

inakrin commented Apr 16, 2017

+1

@moritzschaefer

This comment has been minimized.

moritzschaefer commented Apr 16, 2017

+1

@ewianda

This comment has been minimized.

ewianda commented Apr 23, 2017

+1

@HarenBroog

This comment has been minimized.

HarenBroog commented Apr 27, 2017

+1

@kcavagnolo

This comment has been minimized.

kcavagnolo commented May 1, 2017

+1

@lukin0110

This comment has been minimized.

lukin0110 commented May 10, 2017

+1

@apk

This comment has been minimized.

apk commented May 25, 2017

docker-machine attach, please.

It's pretty remarkable that such an obvious functionality still does not exist out of the box. We're going to jointly administer docker hosts, and this is such a nuisance.

@cybertk

This comment has been minimized.

cybertk commented Jun 16, 2017

In my case, very happy to attach existing host ${HOST} with

docker-machine --tlscacert=ca.pem --tlscert=cert.pem --tlskey=key.pem create \
    --drive none --url tcp://${HOST}:2376

But need copy certificates(ca.pem, cert.pem, key.pem) to DOCKER_CERT_PATH manually.

@lyda

This comment has been minimized.

lyda commented Jul 20, 2017

Any plans for this? Having full paths recorded in config.json is frustrating.

My use case: I have a git repo with machine configs in in it (I use the -s to point docker-machine into it). Secrets are stored with git encrypt and the idea is for CI jobs to be able to make use of these configs to manipulate the machines they need to access.

@lnshi

This comment has been minimized.

lnshi commented Sep 7, 2017

FYI: #3212

@schmunk42

This comment has been minimized.

schmunk42 commented Sep 7, 2017

@lyda We're using such an approach with https://github.com/dmstr/docker-roj - but without encryption, which would be a very nice feature actually!

While roj always works with the same paths, since it's in a container, there are other solutions like:

which basically change a few paths in the config.json.
It's no big magic, unless I am totally missing something here.

@montanaflynn

This comment has been minimized.

montanaflynn commented Sep 12, 2017

Is docker-machine being actively developed by docker? I ask because it's been over a month since a commit made it to master: https://github.com/docker/machine/commits/master

@vibhuyadav

This comment has been minimized.

vibhuyadav commented Dec 20, 2017

+1

2 similar comments
@amihura

This comment has been minimized.

amihura commented Jan 4, 2018

+1

@pvlg

This comment has been minimized.

pvlg commented Jan 16, 2018

+1

@jcheroske

This comment has been minimized.

jcheroske commented Jan 31, 2018

My god, the horror! This thread is still alive after almost three years?!? This is a use-case that everyone bumps into, or would seem to. What am I missing?

@HarenBroog

This comment has been minimized.

HarenBroog commented Jan 31, 2018

Well I assume docker-machine is dead (at least for me :D). I switched to kubernetes. Even self hosted kubeadm in alfa version works better that this actually. I can recommend it :)

@ivoribeiro

This comment has been minimized.

ivoribeiro commented Feb 14, 2018

please support this :(

@brandontamm

This comment has been minimized.

brandontamm commented Feb 14, 2018

add "~/.docker" to a folder that is rsynced or maybe symbolic linked to cloud folder on both machines. there are a couple pre-built solutions. not too hard guys, just do some research - never had an issue after setting up one time for 30 seconds.

@dbuni

This comment has been minimized.

dbuni commented Mar 13, 2018

+1

1 similar comment
@philippreston

This comment has been minimized.

philippreston commented Jun 5, 2018

+1

@gnat

This comment has been minimized.

gnat commented Sep 25, 2018

How this feature, as well as specifying a static IP--- the two most requested features in the history of the docker-machine project--- goes unimplemented is beyond me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment