Machine: Se connecter à une machine existante depuis un autre client

: +1:

Que diriez-vous de l'ajouter au 2ème système en utilisant le pilote «générique», puis d'utiliser la même commande eval là-bas?

@clnperez est-ce une proposition ou quelque chose dont vous êtes sûr que cela fonctionne (cela signifie que cela réutilisera la machine distante existante même si elle est en cours d'exécution)?

Eh bien, avec le recul, je ne pense pas que vous puissiez faire cela car vous auriez à configurer à nouveau les clés ssh ou à les importer depuis votre autre système.

Je vois votre cas. On ne peut pas ajouter une entrée de docker-machine sur le deuxième système en utilisant le pilote générique à moins que vous ne vouliez invalider la configuration d'origine de docker-machine (puisque par exemple de nouvelles creds sont générées). On peut exécuter docker-machine create -d none --url [...] sur le deuxième système en reflétant les options importantes (comme les indicateurs swarm) de la création originale sur le premier système, puis en copiant manuellement les fichiers .pem sélectionnés et le fichier id_rsa de la première machine vers la deuxième machine ET ajoutez manuellement des sections pour l'accès SSH (et changez manuellement le pilote en générique à partir de aucun). C'est un PITA. Une fonction d'exportation / importation appropriée serait bien pour permettre le partage. On peut également partager uniquement les fichiers cred nécessaires pour configurer manuellement le docker.

Correct. La seule façon actuelle serait de prendre tout le répertoire mais cela ne fonctionnera pas avec certains pilotes (c'est-à-dire VirtualBox car il enregistre les VM et les réseaux avec des UUID qui ne correspondent pas). Il y a eu des discussions autour d'une fonctionnalité d'importation / exportation dans le passé (https://github.com/docker/machine/issues/23)

J'ai une solution PR / hacky à cela dans les coulisses ... En général, je pense que je veux passer à la configuration pour être portable / templée au lieu d'être codée en dur comme les choses le sont maintenant.

+1

J'aimerais pouvoir me reconnecter rapidement aux instances cloud (j'utilise GCE) qui existent déjà.

Certes, avoir des configurations importables / exportables serait très utile, mais je me demande si (en plus) aborder le problème en tant que problème de pilote pourrait ne pas donner une expérience utilisateur plus simple.

De cette façon, en utilisant le pilote google, on pourrait se connecter à une instance existante sur un autre ordinateur simplement en fournissant un jeton d'accès valide (que le pilote peut inviter l'utilisateur à générer automatiquement).

De même, lors de l'utilisation du pilote aws par exemple, (ce que je n'ai pas encore fait moi-même, mais je suppose), on pourrait se connecter à une instance existante en fournissant une paire clé / secret valide (peut-être via des variables d'environnement correspondant au pilote spécifique flags - en supposant que le processus se produira via une sous-commande de docker-machine autre que "create", car les attentes sont un peu différentes).

Je veux juste dire que ce serait une fonctionnalité vraiment intéressante. J'aimerais vraiment pouvoir partager une machine avec mes coéquipiers et j'ai été déçu de découvrir qu'il n'y avait pratiquement aucun moyen de le faire pour le moment. Ce serait génial si, par exemple, le pilote generic pouvait détecter automatiquement si une boîte particulière avait déjà été provisionnée avec docker-machine et réutiliser les certificats tls, etc. quand quelqu'un exécutait docker-machine create sur cette boîte à nouveau.

: +1. J'adorerais le voir fonctionner. Actuellement, nous co-gérons les mêmes machines (sur Google Compute Engine) avec une autre personne et le seul moyen que j'ai trouvé de travailler est de copier tout le répertoire (+ modifier les liens absolus dans le fichier config.json). C'est nul. Je pense que le pilote générique ne peut pas être utilisé facilement de cette façon - il y a bien sûr un problème d'authentification (certificats tls, etc.) ne peut pas être simplement réutilisé lorsque vous exécutez - créez avec un pilote générique (vous devez d'une manière ou d'une autre vous avoir accès à la machine qui est différent pour chaque pilote - dans GCE, vous devrez vérifier si votre authentification gcloud vous permet d'accéder à la machine). Il y a aussi un petit problème à moins que vous n'ayez déjà créé la machine auparavant avec un pilote donné, votre pièce d'authentification est manquante (le seul moyen de s'authentifier est de .. créer la machine).

Ce que je pense être la meilleure solution est d'avoir la commande "import" (avec une implémentation différente pour différents pilotes). Par exemple, dans GCE, vous pouvez stocker tous les détails nécessaires (clés, etc.) quelque part dans les méta-données de la machine: https://cloud.google.com/compute/docs/metadata?hl=en#project_and_instance_metadata puis en spécifiant le nom du projet / de la machine (et l'authentification), vous pouvez obtenir toutes les clés nécessaires et configurer la machine.

J'apprécierais vraiment cette fonctionnalité!

@potiuk Quel répertoire copiez-vous?

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

+1!

+1 J'adorerais voir une solution pour ça aussi :-)

J'ai rencontré exactement ce problème aujourd'hui pour donner accès à un collègue.

+1 !!!!!

Semble être un double du n ° 23, non?
Presque 1 an que nous parlons de cette fonctionnalité, certains ont essayé de faire des PR pour cela, mais ils étaient fermés ...
J'espère que cette fonctionnalité sera sur la prochaine version (majeure) :)

Ceci est absolument nécessaire dans les scénarios de livraison continue, où vous souhaitez déployer à l'aide de ces clés de Travis ou Circle CI. Un indice concernant l'ETA?

je dois lui donner un +1 aussi

+1

+1

Avez-vous autre chose à faire que de copier le dossier ~/.docker/machine/machines/<name> et de changer les chemins absolus? J'obtiens un message d'erreur lié à mes certificats et la tentative de régénération échoue également.

@jbasrai L'IP de ce à quoi vous essayez d'accéder a-t-elle changé?

J'ai déposé https://github.com/docker/machine/issues/2516 pour commencer à envisager des étapes dans la bonne direction pour rendre cela plus facile.

C'est une fonctionnalité vitale, et j'aimerais la voir dans une prochaine version. À mon avis, la configuration de la machine doit rester unique à un client et non être importée / exportée. Au lieu de cela (comme d'autres l'ont mentionné) docker-machine create run avec les mêmes arguments devrait être capable de créer une configuration pour la machine même si elle existe déjà à distance au lieu d'échouer comme c'est le cas maintenant. Lors de la réexécution de ma commande create pour une machine amazonec2 existante, j'obtiens cette erreur m'indiquant que l'hôte existe déjà:

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.

Au lieu de cela, il pourrait m'avertir que l'hôte existe déjà et continuer à ajouter la machine comme il le ferait dans une création initiale (nécessitant peut-être qu'un drapeau de remplacement soit passé). De cette façon, je peux garder les scripts de configuration de mon environnement dev / CI simples et ne pas me soucier d'avoir à stocker cette configuration quelque part où mes coéquipiers (ou d'autres parties) peuvent y accéder.

Il est en effet étonnant que pour que plusieurs personnes travaillent sur la même VM, nous devions exporter / importer des certificats d'une machine à une autre. Si quelqu'un trouvait une solution pratique et prête pour la production, ce serait bon à savoir.

+1

+1

Correct. La seule façon actuelle serait de prendre tout le répertoire mais cela ne fonctionnera pas avec certains pilotes (c'est-à-dire VirtualBox car il enregistre les VM et les réseaux avec des UUID qui ne correspondent pas). Il y a eu des discussions autour d'une fonctionnalité d'importation / exportation dans le passé (# 23)

@ehazlett donc j'utilise le pilote aws puis-je:

1. compresser la machine cloud ~/.docker/machine/machines/staging
2. partager avec les membres de l'équipe, ils décompresseront à ~/.docker/machine/machines/
3. ils auront la machine de mise en scène comme moi? docker-machine ls (ou doivent-ils exécuter une autre commande)

@leandromoreira, un obstacle à cette approche est que les fichiers de configuration de la machine docker ont des chemins codés en dur spécifiques à la machine hôte:

cat ~/.docker/machine/machines/local/config.json

outputs:

...
        "AuthOptions": {
            "CertDir": "/Users/pretzel/.docker/machine/certs",
            "CaCertPath": "/Users/pretzel/.docker/machine/certs/ca.pem",
            "CaPrivateKeyPath": "/Users/pretzel/.docker/machine/certs/ca-key.pem",
            "CaCertRemotePath": "",
            "ServerCertPath": "/Users/pretzel/.docker/machine/machines/local/server.pem",
            "ServerKeyPath": "/Users/pretzel/.docker/machine/machines/local/server-key.pem",
            "ClientKeyPath": "/Users/pretzel/.docker/machine/certs/key.pem",
            "ServerCertRemotePath": "",
            "ServerKeyRemotePath": "",
            "ClientCertPath": "/Users/pretzel/.docker/machine/certs/cert.pem",
            "ServerCertSANs": [],
            "StorePath": "/Users/pretzel/.docker/machine/machines/local"
        }

donc simplement copier le répertoire entier n'est pas une solution complète

@bhurlow merci beaucoup: sourire config.json manuellement par moi-même? est-ce le seul obstacle?

@leandromoreira J'ai écrit autour de lui comme ceci , les versions plus récentes de docker-machine ne codent plus les clés en base64 dans le fichier de configuration. En fin de compte, quiconque souhaite utiliser une machine docker distante _doit_ avoir les certificats TLS, donc un échange entre les parties est nécessaire, je pense

Merci @bhurlow

@bcwalrus a fait un excellent outil jusqu'à ce que nous obtenions quelque chose d'officiel.

npm install -g machine-share

# export
machine-share export amazon

# import
machine-share import  amazon.tar

# fix locations :D (it seems this is not using base64 anymore)
machine-share driverfix amazon

@leandromoreira a l' air super mec, j'ai pu exporter et importer les configurations avec succès.

@muhammadghazali était l' idée et l' effort @bhurlow: stuck_out_tongue:

+1 Des mises à jour concernant une solution officielle pour cela?

Avec la version 1.10.1 de docker, j'ai remarqué que le fichier config.json a des références aux éléments suivants du répertoire ~ / docker / machine / certs

        "CertDir": "/home/abc/.docker/machine/certs",
        "CaCertPath": "/home/abc/.docker/machine/certs/ca.pem",
        "CaPrivateKeyPath": "/home/abc/.docker/machine/certs/ca-key.pem",
        "ClientKeyPath": "/home/abc/.docker/machine/certs/key.pem",
        "ClientCertPath": "/home/abc/.docker/machine/certs/cert.pem",

Vous devez également copier le dossier ~ / .docker / machine / certs de la machine d'origine pour que ce scénario fonctionne.

La solution actuelle semble être (par exemple, si vous souhaitez créer une machine Docker sur AWS sur un ordinateur et afficher les journaux ou SSH dans la machine à partir d'un autre):

1. Créez un nouveau répertoire my-dir et my-dir/machine pour les machines Docker que vous souhaitez partager afin qu'il n'utilise pas vos certificats par défaut
2. Créez votre Docker Machine en utilisant l'option --storage-path my-dir/machine (assurez-vous de spécifier le chemin absolu)
3. Pour partager la machine, éditez le config.json dans my-dir/machine/machines/machine-name et remplacez le chemin absolu de my-dir/machine par $MACHINE_STORAGE_PATH
4. Téléchargez my-dir quelque part, par exemple sur Github

Quand quelqu'un veut importer cette machine:

1. Cloner ou télécharger my-dir
2. Modifiez le config.json pour la machine dans my-dir/machine/machines/machine-name et remplacez $MACHINE_STORAGE_PATH par le chemin absolu de my-dir/machine sur votre ordinateur local
3. chmod 0600 le id_rsa en my-dir/machine/machines/machine-name

Vous pouvez maintenant utiliser les commandes Docker Machine en utilisant l'option --storage-path my-dir/machine (assurez-vous de spécifier le chemin absolu).

Cela pourrait éventuellement être amélioré par:

• Docker Machine stockant les chemins relatifs dans config.json, donc cela n'a pas eu à être modifié
• Docker Machine SSH (et les commandes associées) chmodding l'id_rsa à 0600 automatiquement (s'ils en ont l'autorisation)

Un point rapide, si vous utilisez le envsubst vous pouvez remplacer par programme le $ MACHINE_STORAGE_PATH et ne pas avoir à modifier manuellement. Pourtant, le tout est un peu gênant pour les équipes qui essaient d'utiliser une ferme de systèmes de docker-machine.

Cependant, si les gens recherchent une solution de contournement, le plus simple que j'ai trouvé est de:

1. Copiez le .docker/machine/certs dans un emplacement privé. Notez que _pas_ mettez ceci dans un dépôt car il a des secrets qui vous donnent accès aux autres machines. Nous utilisons un magasin privé à cet effet
2. Sur la nouvelle machine hôte, copiez les certificats dans le nouveau .docker/machine/certs
3. Maintenant, réexécutez votre docker-machine crée et vous aurez la possibilité de l'utiliser sans changer toutes les configurations. Cela prend plus de temps, mais est plus portable et vous n'avez pas à modifier tous ces fichiers de configuration.

Je travaille sur deux ordinateurs différents, et c'est un réel problème pour moi.
Je décris ici le comportement de rêve que j'attends lors de l'utilisation de docker-machine:

1) Créez une gouttelette dans DigitalOcean avec docker-machine et le pilote DigitalOcean (avec un jeton que vous obtenez du panneau de contrôle de DigitalOcean).

docker-machine create --driver digitalocean --digitalocean-access-token \
    [token_goes_here] --digitalocean-image ubuntu-16-04-x64 --digitalocean-size \
    1gb [host_name_goes_here]

2) Allez sur un autre ordinateur, obtenez un autre jeton de DigitalOcean et connectez-vous à la machine existante avec une commande d'attachement magique, comme ceci:

docker-machine **attach** --driver digitalocean --digitalocean-access-token \
    [token_goes_here]  [host_name_goes_here]

Quels sont les obstacles à la réalisation de ce travail? Je pense que le jeton d'accès DigitalOcean donne suffisamment de privilèges pour se connecter à un hôte existant et configurer toutes les communications sécurisées.

Pour l'instant, je vais essayer le partage de machine par @bhurlow : https://github.com/bhurlow/machine-share

+1 Bump à ce sujet - quelqu'un a une mise à jour à ce sujet?

@brandontamm : j'ai écrit des scripts pour gérer ce problème par moi-même. Je ne sais pas s'ils résoudront le vôtre, mais je peux au moins essayer. Découvrez l'essentiel ici

Un résumé de l'essentiel: Il y a deux fonctions - store_machine et load_machine. store_machine stocke toutes les informations sur une machine à l'intérieur de la cachette sécurisée (chiffrée sur la banque de données sur disque). Vous devrez fournir un mot de passe. La fonction load_machine charge une machine à partir d'une banque de données sur disque.

Notez que ce code python suppose que vous avez installé sstash (Python Secure Stash). Vous pouvez l'installer en exécutant

pip install sstash

+1

Sérieusement - à quoi sert Docker-Machine à moins que vous ne puissiez y accéder à partir d'un autre appareil prédéfini ...

CAS D'UTILISATION - Construit le docker-machine au travail mais ensuite besoin de l'ordinateur portable pour les vacances au cas où un serveur explose ...

Allez - où est l'administrateur Docker pour intervenir à ce sujet?! C'est un cas d'utilisation que TOUT LE MONDE peut apprécier.

@realcr Avez-vous essayé le partage de machine ?

Je refuse d'utiliser plus de dépendances :) La copie du dossier .docker sur les deux machines OSX a parfaitement fonctionné pour moi. Mes chemins et noms d'utilisateur étaient les mêmes sur les deux machines, c'est donc la clé sans modifier manuellement les chemins.

Brandon Tamm
envoyé depuis un mobile

Le 4 novembre 2016, à 3 h 36, Sébastien Boulet [email protected] écrivait:

@realcr Avez-vous essayé le partage de machine?

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub ou désactivez le fil de discussion.

+1

+1

+1

+1

J'ai écrit docker_machinator pour essayer de résoudre ce problème.
Il s'agit d'un outil Python qui vous permet d'enregistrer toutes les informations d'identification et la configuration de votre machine docker dans une réserve cryptée que vous pouvez stocker chez votre fournisseur de cloud, par exemple. Vous pouvez ensuite le télécharger à partir d'un autre hôte et charger vos machines à partir de la réserve.
Ceci est un outil python, vous devriez donc être un pip install de l'utiliser.

Je ne pense pas que ce soit la solution parfaite, mais cela pourrait vous aider jusqu'à ce que nous en trouvions une meilleure.

Les gars, vous devez savoir que le partage de la machine exporte votre clé ssh privée que vous avez utilisée pour créer un hôte docker via une machine docker avec un pilote générique. Ainsi, toutes les personnes à qui vous envoyez une archive exportée pourront accéder au serveur exécutant docker.

@mxl docker-machine fournit une sous-commande ssh qui vous accordera l'accès au serveur, donc la situation que vous décrivez est inévitable si vous avez un outil qui crée une configuration entière sous forme de fichier importable.

➜ docker-machine
Usage: docker-machine [OPTIONS] COMMAND [arg...]
...
Commands:
...
  ssh                   Log into or run a command on a machine with SSH.

Je suppose que la manière d'éviter cela serait de créer une commande qui pourrait télécharger la configuration actuelle à partir de la machine distante. Un tel téléchargement nécessiterait que vous soyez en mesure de ssh sur la machine, plutôt que d'empaqueter l'accès dans le fichier importable.

Le fait de ne pouvoir contrôler la machine docker qu'à partir d'un hôte est une limitation inconfortable.
J'aimerais aussi voir quelque chose comme docker-machine config-from <otherhost> .

Donc +1 de moi aussi.

/ Edit: Je résous actuellement le problème en synchronisant le .docker d'un "serveur maître" à tous les autres serveurs qui ont besoin des mêmes configurations - via cron et rsync. Ceci est par exemple nécessaire pour plusieurs esclaves de construction. Pas une très bonne solution.

+1

Voici un scénario différent qui m'amène ici.

J'ai créé une gouttelette pour créer un tas d'images de docker pour réaliser plus tard que je dois déplacer la région hôte ...

La question est de savoir comment attacher l'instance de docker-machine restaurée à partir de l'instantané exécuté sur le nouvel hôte?

Le vendredi 10 mars 2017 à 06:16, exjimsk [email protected] a écrit:

J'ai créé une gouttelette pour créer un tas d'images de docker pour réaliser plus tard que je
besoin de déplacer la région hôte. Comment attacher l'instance docker-machine
restauré à partir de l'instantané en cours d'exécution sur le nouvel hôte?

Si les certificats n'ont pas changé, vous devriez pouvoir simplement changer votre
docker-machine config pour le pointer vers la nouvelle adresse IP. Vous trouverez le
fichier à ~ / .docker / machine / machines / nom-de-votre-machine / config.json.

Sinon, si vous ne persistez jamais les données dans vos conteneurs Docker, à la place
de déplacer l'hôte, il suffit de le tuer, d'en créer un nouveau et de démarrer le même
conteneurs sur le nouvel hôte.
ᐧ

+1

+1

+1

+1

+1

+1

+1

+1

docker-machine attach , s'il vous plaît.

Il est assez remarquable qu'une fonctionnalité aussi évidente n'existe toujours pas hors de la boîte. Nous allons administrer conjointement les hôtes dockers, et c'est une telle nuisance.

Dans mon cas, très heureux de joindre l'hôte existant ${HOST} avec

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

Mais vous avez besoin de copier les certificats ( DOCKER_CERT_PATH manuellement.

Des plans pour ça? Avoir des chemins complets enregistrés dans config.json est frustrant.

Mon cas d'utilisation: j'ai un repo git avec des configurations de machine dedans (j'utilise le -s pour y pointer docker-machine). Les secrets sont stockés avec git encrypt et l'idée est que les jobs CI puissent utiliser ces configurations pour manipuler les machines auxquelles ils ont besoin d'accéder.

FYI: # 3212

@lyda Nous utilisons une telle approche avec https://github.com/dmstr/docker-roj - mais sans cryptage, ce qui serait en fait une fonctionnalité très intéressante!

Bien que roj fonctionne toujours avec les mêmes chemins, puisqu'il se trouve dans un conteneur, il existe d'autres solutions comme:

• https://github.com/bhurlow/machine-share
• https://gist.github.com/realcr/2363c699e893c66ac7ed72da29804b0a

qui modifient fondamentalement quelques chemins dans le config.json .
Ce n'est pas une grande magie, sauf si je manque totalement quelque chose ici.

Est-ce que docker-machine est activement développé par docker? Je demande car cela fait plus d'un mois qu'un commit est passé à master: https://github.com/docker/machine/commits/master

+1

+1

+1

Mon dieu, l'horreur! Ce fil est toujours vivant après presque trois ans?!? C'est un cas d'utilisation dans lequel tout le monde se heurte, ou semble le faire. Qu'est-ce que je rate?

Eh bien, je suppose que docker-machine est mort (au moins pour moi: D). Je suis passé à kubernetes . Même les kubeadm auto-hébergés dans la version alfa fonctionnent mieux que cela en fait. Je peux le recommander :)

veuillez soutenir ceci :(

ajoutez "~ / .docker" à un dossier qui est resynchronisé ou peut-être lié symboliquement au dossier cloud sur les deux machines. il existe quelques solutions préconfigurées. pas les gars trop durs, faites juste quelques recherches - je n'ai jamais eu de problème après une configuration unique pendant 30 secondes.

+1

+1

La façon dont cette fonctionnalité, ainsi que la spécification d'une adresse IP statique - les deux fonctionnalités les plus demandées dans l'histoire du projet docker-machine - ne sont pas implémentées, me dépasse.

Presque 4 ans se sont écoulés 😮 Y a-t-il des mises à jour à ce sujet?

Pour le moment, de nombreux articles / tutoriels sur Docker suggèrent toujours d'utiliser docker-machine comme outil de facto pour gérer les hôtes. Cependant, cette présence de problème est un facteur limitant fort!

Je continue actuellement à utiliser docker-machine et à utiliser l'approche «copy-certs-dirs» pour partager entre nos ordinateurs locaux. J'aimerais passer à Kubernetes, mais cela semble trop pour mon projet.

Que diriez-vous d'exécuter docker-machine create partir d'un conteneur Docker? Ce conteneur pourrait ensuite être exporté, importé sur un autre ordinateur et y être exécuté.

N'a toujours pas d'attachement, oh mon dieu