Machine: L'utilisation de docker-machine pour importer des hôtes avec --driver = generic et / ou --url ne fonctionne pas.

Salut @smakam , je crois que ce que vous recherchez est le pilote url : http://docs.docker.com/machine/#adding -a-host-without-a-driver

Salut @nathanleclaire
Merci pour la réponse.
J'ai regardé le lien que vous avez mentionné et j'ai essayé ce qui suit, pas de chance.

Tout d'abord, j'ai essayé sans TLS:
Sur la machine Ubuntu, j'ai fait ceci pour démarrer l'agent docker:
sudo docker -d -H unix: ///var/run/docker.sock -H tcp: //192.168.56.101 : 2376 &

Sur Windows, où j'avais installé docker-machine, j'ai fait ceci:
$ docker-machine create --url = tcp: //192.168.56.101 : 2376 personnalisé6
← [34mINFO ← [0m [0000] "custom6" a été créé et est maintenant la machine active.
$ docker-machine ls
NOM ACTIVE DRIVER STATE URL SWARM
custom6 * aucun tcp: //192.168.56.101 : 2376

J'obtiens cette erreur:
$ docker-machine env personnalisé6
← [31mFATA ← [0m [0000] open C: \ Users \ srmakam.docker \ machine \ machines \ custom6ca.pem: Le système ne trouve pas le fichier spécifié.

Je ne sais pas si docker-machine applique TLS. J'ai essayé de démarrer l'agent docker avec un certificat et une clé et j'ai essayé avec le client docker, pas de chance non plus.

Merci
Sreenivas

Nous mandatons essentiellement TLS dans notre forme actuelle. Si vous configurez votre propre CA et vos propres certificats / clés, je pense que vous pourriez probablement les utiliser via les options --tls-ca-cert , --tls-ca-key gloabl de Docker Machine. @ehazlett Un commentaire?

salut

J'ai essayé avec TLS, je ne pouvais toujours pas le faire fonctionner, je ne sais pas ce qu'il me manque:
J'ai démarré docker sur mon hôte Ubuntu:
sudo / usr / bin / docker -d --tlsverify --tlscacert =

Vous voudrez probablement utiliser l'autorité de certification existante, le client, etc. pour tous les éléments liés à la machine, car les paramètres --tls-ca-cert etc. sont globaux.

En ce qui concerne votre démon docker, vous souhaitez utiliser le certificat / clés de l'autorité de certification et du serveur - dans ce qui précède, vous utilisez le certificat de l'autorité de certification, mais la clé et le certificat du client. Vous auriez besoin de quelque chose comme:

docker -d --tlsverify --tlscacert ca.pem --tlscakey ca-key.pem --tlscert server.pem --tlskey server-key.pem

@ehazlett
J'ai essayé d'utiliser les paramètres globaux dans le répertoire "certs" pour docker-machine create en spécifiant des options en ligne de commande, mais il se plaint toujours de "ca.pem" manquant dans les machines /\ répertoire.
Comment obtenir "server.pem" et "server-key.pem"? Dois-je le générer?

J'ai pu me connecter entre le client docker et l'agent docker sur une machine séparée en utilisant TLS sans utiliser docker-machine.

Merci
Sreenivas

Pouvez-vous montrer les arguments de ligne de commande utilisés? Si vous spécifiez les certificats, la machine doit simplement les utiliser. Sinon, c'est un bug :)

Salut @ehazlett
Tout d'abord, j'ai commencé l'agent docker comme ceci:
sudo / usr / bin / docker -d --tlsverify --tlscacert = / home / xxx / .docker / machine / certs / ca.pem --tlskey = / home / xxx / .docker / machine / certs / key.pem --tlscert = / home / xxx / .docker / machine / certs / cert.pem --host = unix: ///var/run/docker.sock --host = tcp: //0.0.0.0 : 2376

Ensuite, j'ai démarré le client docker-machine comme ceci:
docker-machine --tls-ca-cert = / home / xxx / .docker / machine / certs / ca.pem --tls-client-key = / home / xxx / .docker / machine / certs / key.pem - -tls-client-cert = / home / xxx / .docker / machine / certs / cert.pem create --url = tcp: //0.0.0.0 : 2376 custom3

J'ai eu cette erreur lors de la configuration de l'environnement:
xxx @ ubuntu : ~ $ docker-machine env personnalisé3
open /home/xxx/.docker/machine/machines/custom3/ca.pem: aucun fichier ou répertoire de ce type

Ici, j'exécute l'agent docker et la machine docker sur la même machine Ubuntu. J'obtiens une erreur similaire lors de l'exécution de l'agent docker dans Ubuntu et de docker-machine sous Windows.

Merci
Sreenivas

Vous ne devriez pas utiliser key.pem et cert.pem pour le moteur Docker. Le moteur a besoin d'une paire clé / certificat de serveur (la machine les créera).

Pour l'environnement, comment avez-vous créé la machine custom3 ? Il semble que quelque chose s'est mal passé lors de la création si ce fichier n'existe pas.

Salut @ehazlett
Comment démarrer le moteur Docker? Selon ce que je comprends, les mandats de docker-machine utilisant TLS.

C'est ainsi que j'ai créé la machine custom3. Cela ne m'a donné aucune erreur.
docker-machine --tls-ca-cert = / home / xxx / .docker / machine / certs / ca.pem --tls-client-key = / home / xxx / .docker / machine / certs / key.pem - -tls-client-cert = / home / xxx / .docker / machine / certs / cert.pem create --url = tcp: //0.0.0.0 : 2376 custom3

Dois-je créer manuellement une paire clé / certificat de serveur comme ce que ferait la machine si le pilote était utilisé avec docker-machine?

Merci
Sreenivas

@smakam cela devrait être correct. Il doit générer une clé de serveur basée sur cette autorité de certification existante. Je vais faire quelques tests pour voir s'il y a un problème.

@smakam Une mise à jour sur ce problème ou pouvons-nous le fermer?

@nathanleclaire Je
Voici ce qui est mentionné:
docker-machine create -d generic \
--generic-ssh-user ubuntu \
--generic-ssh-key ~ / Téléchargements / manuellement_created_key.pub \
- adresse-ip-générique 12.34.56.78 \
jungle

Je suppose que .pub est une faute de frappe et que nous devons donner une clé privée. J'ai eu 2 types d'erreurs dans 2 hôtes différents:

cas 1:
Importation de la clé SSH ...
Erreur lors de la création de la machine: état de sortie 1
Vous voudrez vérifier le fournisseur pour vous assurer que la machine et les ressources associées ont été correctement supprimées.

cas 2:
Importation de la clé SSH ...
Erreur lors de l'obtention de la commande SSH pour vérifier si le démon est actif: état de sortie 1
Erreur lors de l'obtention de la commande SSH pour vérifier si le démon est actif: état de sortie 1

btw, où les journaux détaillés de docker-machine sont-ils stockés?
J'ai essayé avec docker-machine pour Windows et Linux.

Merci
Sreenivas

Le même problème.
Les méthodes génériques --url et -d ne fonctionnent pas.

J'ai essayé les mêmes étapes que l'affiche originale et j'ai eu un problème similaire, auquel cas j'ai essayé le pilote générique et j'ai rencontré une erreur similaire au cas 1 (CentOS 7)

Même problème. Impossible d'utiliser --url et de spécifier le certificat.

Pourrais-je suggérer à l'équipe Docker d'écrire un court tutoriel nous expliquant étape par étape, ce serait très utile.

Même problème ici avec anyconnect VPN connecté, bien après avoir redémarré mon ordinateur portable sans aucune connexion, il est parti.

+1 pour le problème.
J'ai essayé d'utiliser docker-machine create --url= avec ma configuration de docker existante sur l'hôte distant, mais pas de chance. DM ne parvient pas à obtenir TLS à partir de $HOME/.docker/machine/machines/<name>/ca.pem .

Même problème. J'ai essayé les mêmes étapes, mais toujours aucun certificat / clé de serveur généré.
docker-machine version 0.4.0
Docker version 1.8.0

Même problème. J'ai essayé les mêmes étapes, mais toujours aucun certificat / clé de serveur généré.
docker-machine version 0.4.1
Docker version 1.8.1

@csokun @ miracle-in-sunday @narqo En général, il est supposé qu'en utilisant --url vous "apportez vos propres certificats" bien que je l'admets, ce morceau de code languit donc il peut être cassé.

Si vous souhaitez que les certificats et les clés soient générés automatiquement, essayez le pilote generic : https://docs.docker.com/machine/drivers/generic/

Si cela ne fonctionne pas pour votre cas d'utilisation, puis-je vous demander de déposer un problème distinct détaillant les étapes exactes que vous prenez et les résultats que vous voyez?

Merci!

Salut les gars, Avez-vous essayé avec --virtualbox-hostonly-cidr speciefied? A travaillé pour moi:

BartSlaman @ VLRNB176 ~
$ docker-machine create -d virtualbox --virtualbox-hostonly-cidr "192.168.99.100/24" dev4
Création de la VM VirtualBox ...
Création de la clé SSH ...
Démarrage de la VM VirtualBox ...
Démarrage de la VM ...
Pour voir comment connecter Docker à cette machine, exécutez: C: \ Program Files (x86) \ Git \ bindocker-machine env dev4

BartSlaman @ VLRNB176 ~
$ docker-machine env dev4
export DOCKER_TLS_VERIFY = "1"
export DOCKER_HOST = " tcp: //192.168.99.101 : 2376"
export DOCKER_CERT_PATH = "C: \ Users \ BartSlaman.docker \ machine \ machines \ dev4"
exporter DOCKER_MACHINE_NAME = "dev4"

Cordialement
Bart Slaman

Une mise à jour sur ce problème? J'ai essayé --url avec --tls- * mais je me suis trompé "open /Users/user/.docker/machine/machine/ss/ca.pem aucun fichier ou répertoire". J'utilise la version 0.4.1 de docker-machine

Idem ici, mais erreur différente lors de la création:

Importation de la clé SSH ...
Erreur cmd SSH!
commande: sudo hostname internal && echo "internal" | sudo tee / etc / hostname
err: état de sortie 1
sortie: sudo: aucun tty présent et aucun programme askpass spécifié

Et puis lors de l'exécution de eval "$ (docker-machine env internal)":
open /Users/marlon/.docker/machine/machines/internal/ca.pem: aucun fichier ou répertoire de ce type

Cela signifie que les certificats ne sont pas générés.

Chose drôle, je peux ssh sur la machine exécutant "docker-machine ssh internal".

J'ai pu faire fonctionner --url et pointer vers un moteur Docker existant sur DigitalOcean créé avec Docker Machine.

Pour utiliser --url ou le pilote none , je viens de copier le dossier ~/.docker/machine/machines/dobox/ existant sur la machine que j'ai utilisée pour créer l'hôte et j'ai supprimé cert.pem , key.pem , id_rsa.pub , id_rsa et config.json (laissant ca.pem , server.pem et server-key.pem ). J'ai ensuite généré une nouvelle paire cert / clé client (https://docs.docker.com/articles/https/, en commençant par "Pour l'authentification client") dans le répertoire nouvellement créé d'avant et je l'ai copié sur la machine que j'étais essayer de se connecter à partir de. Enfin, j'ai ajouté l'hôte distant en utilisant docker-machine create --url=tcp://SOME_IP:2376 dobox et j'ai déplacé les certificats là où Docker Machine les attend: ~/.docker/machine/machines/dobox/ . Le dossier devrait déjà être là et contenir config.json , donc vous ajoutez simplement vos certificats. Je n'essaye pas de changer les indicateurs TLS / schéma d'authentification que Docker utilise, qui sont:

--tlsverify \
--tlscacert="/home/roberto/.docker/machine/machines/dobox/ca.pem" \
--tlscert="/home/roberto/.docker/machine/machines/dobox/cert.pem" \
--tlskey="/home/roberto/.docker/machine/machines/dobox/key.pem" \
-H=tcp://SOME_IP:2376

Maintenant, je peux docker $(docker-machine config dobox) images ou juste eval "$(docker-machine env dobox)" etc sur la deuxième machine cliente.

docker-machine version 0.4.0
Docker version 1.8.2

Comment authentifier le client et le serveur dans docker dont je dois configurer le nom d'utilisateur et le mot de passe
J'utilise https://docs.docker.com/reference/api/docker_remote_api_v1.20/
et avoir un client et un serveur docker sur la même machine hôte.
Et faites-moi savoir si les deux ne sont pas sur la même machine.

Les gars pour l'amour du Dieu, ajoutez un tutoriel sur la façon d'importer des machines docker existantes.
J'ai créé 2 machines cloud azure différentes à partir de 2 PC séparés et maintenant je ne peux pas me connecter d'un PC à une machine azure qui ont été créées sur une autre.
Passez déjà 2 soirées, essayez toutes les suggestions et aucun résultat.

@nathanleclaire wdyt?

@ dmp42 À propos de quoi exactement? --url être cassé est un problème assez bien connu, et nous voulons bientôt prendre en charge l'utilisation de machines à partir de plusieurs ordinateurs différents avec des configurations portables.

Je suppose que ce serait formidable d'avoir au moins une déclaration claire selon laquelle l'importation d'hôtes existants, de PC à PC, ne fonctionne pas pour l'instant (ou a des problèmes connus) quelque part dans la documentation officielle ou ici sur github.

@baio +1

J'ai un hôte Centos 7 sur lequel j'ai déjà installé le package docker standard du repo Centos standard - c'est-à-dire que je n'ai pas utilisé le package du site Web Docker.

Depuis mon poste de travail local, lorsque j'essaye de créer la machine pour cet hôte Centos 7 en utilisant le pilote générique, il échoue avec "exit status 1" quand il essaie d'installer un package appelé "docker-engine".

Je suppose que cela ne fonctionne pas si Docker est déjà installé sur l'hôte distant?

Connexes: # 2270

Je pense avoir un exemple minimal reproductible:

créer un Vagrantfile simple

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|

  # Box
  config.vm.box = "ubuntu/precise64"
  config.vm.box_url = "http://cloud-images.ubuntu.com/vagrant/precise/current/precise-server-cloudimg-amd64-vagrant-disk1.box"

  # To make this easily reproducible
  config.ssh.insert_key = false
  config.vm.network "private_network", ip: "192.168.50.4"

end

démarrer la VM

$ vagrant up

confirmez que vous pouvez SSH avec la clé, l'utilisateur et l'adresse IP que vous attendez

ssh -i ~/.vagrant.d/insecure_private_key [email protected]

^ Cela fonctionne pour moi

créer la machine Docker

$ docker-machine create -d generic --generic-ssh-user vagrant --generic-ssh-key ~/.vagrant.d/insecure_private_key --generic-ip-address 192.168.50.4 repro

Importing SSH key...
Error creating machine: Maximum number of retries (60) exceeded
You will want to check the provider to make sure the machine and associated resources were properly removed.

Est-ce que vous obtenez le même résultat? Faites-moi savoir s'il y a autre chose que je peux essayer pour aider au débogage.

Même problème ici. Impossible de faire fonctionner --url (pas de pilote) avec:

• Docker Machine 0.5.1 (côté client) sous OSX
• Docker 1.9 (côté serveur distant)
• Le démon distant a démarré avec:

--tlsverify -H=unix:///var/run/docker.sock -H=0.0.0.0:2376 --tlscacert=/root/.docker/ca.pem --tlscert=/root/.docker/cert.pem --tlskey=/root/.docker/key.pem

• Certificats clients (ca, key, cert) installés sous ~/.docker/machine/machines/mymachine/

Lorsque vous tapez docker-machine env mymachine , il échoue dans:

Error running connection boilerplate: Error checking and/or regenerating the certs: There was an error validating certificates for host "": open /Users/f2i/.docker/machine/machines/anakin/server.pem: no such file or directory
You can attempt to regenerate them using 'docker-machine regenerate-certs name'.
Be advised that this will trigger a Docker daemon restart which will stop running containers.

Sans docker-machine, tout semble bien:

> docker --tlsverify -H=myhost:2376 ps
CONTAINER ID        IMAGE                       COMMAND                  CREATED             STATUS              PORTS 

Vous vous demandez simplement quelle est la vraie différence entre générique ( --driver "generic" --generic-ip-address ... ) et aucun pilote ( --driver "none" --url ...) ?
Je comprends le générique se connecte via SSH (c'est donc comme utiliser docker directement sur le serveur distant) et aucun pilote ne se connecte à l'hôte en utilisant TCP.

Par conséquent, en n'utilisant aucun pilote , pourquoi avons-nous besoin d'avoir server.pem et server-key.pem sur l'hôte client? Ils ne doivent pas être gérés par machine. Droite ?

Même en fournissant ces derniers fichiers PEM, il échoue dans:

Error running connection boilerplate: Error checking and/or regenerating the certs: There was an error validating certificates for host "": crypto/tls: failed to parse private key
You can attempt to regenerate them using 'docker-machine regenerate-certs name'.
Be advised that this will trigger a Docker daemon restart which will stop running containers.

Le "no driver" est plus un pilote de test d'intégration utilisé pour le développement. Mais si vous piratez suffisamment, votre configuration peut être utilisée pour enregistrer une machine existante. Il est prévu de le supprimer dans une prochaine version (# 2437). La documentation actuelle est trompeuse sur ce pilote none .

Le pilote generic doit être utilisé pour enregistrer et installer correctement le docker sur n'importe quel hôte.
Notez qu'il redémarrera au moins le démon docker sur l'hôte cible. Mais c'est un moyen fiable d'enregistrer n'importe quelle machine «générique» dans la machine docker tant que vous fournissez un accès ssh.

@jeanlaurent le problème avec le pilote generic est qu'il se moque de votre machine si docker est déjà installé (par exemple, changer le nom d'hôte; exécuter yum update ). Je pense que ce que beaucoup d'entre nous essayent de dire, c'est que le pilote none a un cas d'utilisation de première classe, et s'il fonctionnait correctement, ce serait une capacité précieuse pour beaucoup d'entre nous (en plus des pilotes ciblés) .

D'accord avec @metasim à ce sujet. Le pilote none est un cas d'utilisation si courant. C'est l'un des moyens les plus élémentaires d'interagir avec l'API Docker à distance. Il serait malheureux de le nommer test . Peraphs le trompeur vient du fait que nous ne voulons pas créer / gérer une nouvelle machine ( docker-machine create ) mais seulement nous connecter à une machine existante ...

Je ne dis pas que nous ne devrions pas pouvoir «enregistrer» une machine existante dans docker-machine d'une manière ou d'une autre, nous devons juste le faire correctement. Il y a beaucoup de confusion autour du pilote none , il ne fonctionne pas dans beaucoup d'endroits, et les gens en abusent. L'intention ici est de préparer le terrain pour une vraie fonctionnalité register existing machine .

Mais une fois qu'une machine est `` piratée '' dans docker-machine via le pilote none, il y a beaucoup de choses qui vont briser la chaîne -> restart , upgrade et ssh évidemment. Faire une modification manuelle du fichier json est aussi efficace que d'utiliser le pilote none pour enregistrer réellement une machine.

@metasim Mettre à jour le generic pour ne pas «gâcher avec votre machine» est une façon de le gérer.

@vpusher Nous

@jeanlaurent Merci pour votre réponse. Je peux voir que la mise generic niveau de existing ?, preconfig ?, manual ?, diy ? :-)) pour gérer ce cas d'utilisation, en particulier pour que la stabilité dans ce contexte étroit puisse être mieux établie.

FYI. # 2260 et # 2269 (fermés mais pas vraiment abordés) étaient une tentative de capturer une partie de cette confusion autour du pilote none

PS: Je pense qu'il est tout à fait acceptable que certaines commandes ne soient pas explicitement prises en charge dans ce cas d'utilisation (par exemple restart , upgrade , etc.).

@metasim Yup un pilote dédié est probablement le meilleur moyen de gérer une fonction de registre mais pas le seul, une commande dédiée en est une autre. Mais avant de décider comment le faire, nous devons clarifier / définir dans quel cas nous devons tous enregistrer une nouvelle machine sans docker-machine installer docker dessus.

Si vous regardez le PR # 2442 par exemple, nous envoyons un ping à l'hôte du docker pour la version du docker. Parce que nous voulons être en mesure de fournir une mise à niveau à un moment donné, ou vous avertir que votre hôte docker est trop ancien avec votre client docker actuel. Avec une machine sur laquelle nous n'avons pas installé le démon docker, cela s'avérera difficile ou du moins très floconneux.

Si nous considérons que nous pouvons mettre à jour le pilote generic d'une manière ou d'une autre, je me demande pour quel cas d'utilisation quelqu'un aimerait enregistrer une machine dans docker-machine sans fournir d'accès ssh?

Quel est ton ? Énumérons-les.

Quelques commentaires sur la définition du cas d'utilisation pour none et / ou le déconseiller potentiellement ici: https://github.com/docker/machine/pull/2437#issuecomment -160768813

Mon sentiment est que nous (l'équipe Machine) devrions:

• Suivez les directives existantes de Docker sur la dépréciation des fonctionnalités (obsolète sur 2 cycles de publication).
• Par conséquent, si nous allons désapprouver le pilote none , nous devrions attendre de le supprimer complètement jusqu'à 0.7.0.
• Dans l'intervalle, corrigez les bugs existants avec le pilote none , et travaillez à définir le flux de travail futur idéal (qu'il s'agisse de import / register ou de modifications du generic driver) afin que les utilisateurs intéressés puissent suivre et avoir suffisamment de temps pour se préparer aux changements à venir.

@dgageot @jeanlaurent Comment ça sonne?

@jeanlaurent Je peux voir que ssh serait à peu près nécessaire, ce qui n'est pas si mal. Jusqu'à présent, je supposais que presque tout pouvait être fait via l'API REST.

J'utilise docker-machine principalement comme un outil pour configurer les variables d'environnement requises pour que docker parle à un autre hôte. Je n'utilise jamais les commandes upgrade / restart etc. Mes hôtes Docker sont dans vSphere avec un modèle personnalisé créé via un flux de travail vOrchestrator - l'utilisation du pilote vSphere dans docker-machine n'est pas une option.

Cela dit, je me rends compte que mon cas d'utilisation n'est pas le seul cas d'utilisation, mais j'espère que c'est quelque chose à considérer au moins.

Je pourrais probablement remplacer docker-machine par un alias de shell, du moins pour mes besoins.

Voici un exemple de cas d'utilisation au cas où cela aiderait:

Je voudrais créer mes machines ec2 dans Amazon en utilisant Elasticbeanstalk au lieu de Docker-machine, car Elasticbeanstalk a beaucoup de goodies (comme la mise à l'échelle automatique et le redémarrage de la machine). Je voudrais les enregistrer avec docker-machine et les contrôler en utilisant docker-swarm.

La mise à niveau de ces machines pour avoir docker 1.9 est triviale, mais elles exécutent un certain linux amazon (ancienne fourche centos) et générique ne fonctionne pas avec elles. Parce que le moteur docker n'a pas de tls, l'astuce que j'utilise pour les gérer à distance avec docker simple est d'exposer le docker.sock dans localhost: 2375 en utilisant socat (un peu comme dans https://github.com/sequenceiq/docker- socat) et effectuez un tunnel ssh depuis ma machine locale avec quelque chose comme ssh -i id_rsa [email protected] -L 2375: localhost: 2375 -N. Ensuite, je peux me connecter sur le réseau avec docker --tls = false -H tcp: // localhost : 2375.

C'est beaucoup de gymnastique. La combinaison de l'accès ssh et d'une configuration de docker fonctionnelle (même sans SSL) devrait être tout ce dont la machine docker a besoin pour de nombreux cas intéressants (pas de mise à niveau, redémarrer comme d'autres remarqué, mais je ne les utilise jamais de toute façon).

J'espère que c'est utile.

@bonitao Content que vous ayez précisé cela. J'ai également le cas d'utilisation "tunnel via ssh" dans certains engagements d'entreprise.

Je recommence juste à essayer d'utiliser la machine Docker avec des hôtes existants ... Je suis d'accord avec les déclarations @metasim sur autour du pilote none ... Cela a de la valeur aujourd'hui pour la communauté, puisque le generic ne fait pas encore son intention ... J'ai passé d'innombrables heures à essayer de faire travailler le none pour apprendre qu'il y avait une proposition pour le renommer en test . @nathanleclaire Tout projet de faire fonctionner le pilote generic comme décrit à propos de ???

J'ai passé beaucoup de temps sur https://github.com/docker/machine/issues/2628 et c'est un cas d'utilisation que nous avons ... Soutenir les équipes existantes dans toute l'entreprise avec docker ...

J'ai cherché sur Google, en supposant que je manquais complètement de compréhension, en essayant de comprendre comment me connecter à une machine docker azure à partir de mon serveur CI que j'ai créé ailleurs. Je me suis retrouvé ici et je suis surpris que ce ne soit pas possible (sans piratage).

J'ai créé et mis en place des instances de machine azure docker entièrement opérationnelles à partir d'un poste de travail et je veux juste pouvoir la contrôler et la déployer à partir de scripts CI, qui peuvent s'exécuter à partir d'un certain nombre d'instances esclaves CI. N'y a-t-il vraiment aucun moyen officiel que cela soit censé être accompli?

J'ai mis à jour mon docker et maintenant je ne peux plus me connecter à mon ancienne instance de docker-machine. Je reçois

Error running connection boilerplate: Error checking and/or regenerating the certs: There was an error validating certificates for host "xxxxx:2376": open : no such file or directory
You can attempt to regenerate them using 'docker-machine regenerate-certs [name]'.
Be advised that this will trigger a Docker daemon restart which will stop running containers.

les commandes regeenrate-certs me donnent

Regenerate TLS machine certs?  Warning: this is irreversible. (y/n): y
Regenerating TLS certificates
Detecting the provisioner...
Installing Docker...
Copying certs to the local machine directory...
Copying ca.pem to machine dir failed: open : no such file or directory

ce qui est drôle, c'est que je peux

docker-machine ssh

sans aucun problème..

des correctifs?

Scénario: serveur existant et opérationnel avec Docker et TLS activés.

Ajouter un serveur / une machine existante à docker-machine:

docker-machine --tls-ca-cert path/to/ca.pem --tls-ca-key path/to/ca-key.pem --tls-client-cert path/to/client.pem --tls-client-key path/to/client-key.pem create --driver none --url tcp://HOST:2376 NAME

Dans votre répertoire utilisateur (~ / .docker / machine / machines / NAME), ajoutez le même certificat client que "cert.pem" et "server.pem" et la clé de certificat client sous "key.pem" et "server-key. pem "ajustez également votre config.json pour inclure les paramètres SSH appropriés ...

J'avais soulevé cette question. J'ai récemment fait fonctionner cela et j'ai mis les instructions ici (https://sreeninet.wordpress.com/2015/05/31/docker-machine/) au cas où quelqu'un voudrait se référer.

Voici un script qui fonctionne un peu pour moi:
https://github.com/docker/machine/issues/3344#issuecomment -212536797

@devcrust où sont exactement ceux-ci:

path/to/ca.pem
path/to/ca-key.pem
path/to/client.pem
path/to/client-key.pem

???

$ ls certs/
ca-key.pem  ca.pem  cert.pem  key.pem
$ ls machines/adhoc/
ca.pem  cert.pem  config.json  id_rsa  id_rsa.pub  key.pem  server-key.pem  server.pem

Je ne peux pas le configurer correctement. J'ai aussi ce problème:

Copying ca.pem to machine dir failed: open : no such file or directory

après la mise à niveau vers 0.6.0 .... j'ai perdu l'accès tcp à 12 machines

@nathanleclaire Une mise à jour à ce sujet? J'essaie de comprendre comment je me connecterais à un hôte Docker fonctionnant dans Microsoft Azure, que j'ai créé à partir d'un autre ordinateur, en utilisant docker-machine . À l'heure actuelle, je n'ai aucune solution.

Solution: _ (vous souhaitez) _

docker-machine ajouter <🖥️ nom> --driver <☁️️ pilote du fournisseur>

Tellement triste que tant de temps ait passé et qu'aucune fonctionnalité ne soit introduite pour résoudre ce problème.

Pour ce que ça vaut. Vous pouvez créer une machine en utilisant le pilote générique mais cela redémarrera tous vos conteneurs.
Ajout de redémarrage: toujours sur vos conteneurs garantira qu'ils ne s'arrêtent pas. Je soutiendrais l'option d' ajout de docker-machine

Je suis également partisan d'avoir une option d'ajout de docker-machine.

Voici deux projets avec différentes approches du partage de machine:

• https://github.com/dmstr/docker-roj
• https://github.com/bhurlow/machine-share

@jeanlaurent

Quel est ton ? Énumérons-les.

Mon idée était de connecter ma machine locale à un serveur physique existant avec une charge de conteneurs en cours d'exécution. Faire docker-machine create --driver generic les arrêtera probablement, et plus encore . Je me demande pourquoi il faut redémarrer docker ...

Eh bien, je peux simplement exécuter des commandes sur ssh, mais d'après sa description, il semblait que docker-machine pouvait également être utilisé.

Mais alors, si vous avez créé une machine virtuelle à partir d'un ordinateur et que vous souhaitez la gérer à partir d'un autre. Ou vous avez réinstallé votre système d'exploitation local ... Ou vous souhaitez déléguer le contrôle de la VM à quelqu'un d'autre ...

PS Je fais mes premiers pas avec Docker, donc il me manque peut-être des points ...

@ x-yuri Pour "créer" une machine manuellement, copiez simplement ses fichiers depuis .docker/machine/machines et ajustez ses chemins.