Suis-je en train de me connecter à un démon compatible TLS sans TLS?

J'essaie d'en savoir plus sur Docker , mais je reçois toujours des messages d'erreur cryptiques (pour moi).

L'exemple le plus simple est peut-être d'essayer d'imprimer la version de Docker que j'ai installée:

$ sudo docker version
Client version: 1.4.1
Client API version: 1.16
Go version (client): go1.3.3
Git commit (client): 5bc2ff8
OS/Arch (client): darwin/amd64
FATA[0000] Get http:///var/run/docker.sock/v1.16/version:
    dial unix /var/run/docker.sock: no such file or directory.
    Are you trying to connect to a TLS-enabled daemon without TLS?

Je viens de parcourir le guide de l' utilisateur et de suivre exactement chaque étape, donc je suis surpris de recevoir ce message ... Que dois-je faire maintenant?

Je viens de remarquer que si je n'utilise pas, sudoje ne reçois pas l'erreur:

$ docker version
Client version: 1.4.1
Client API version: 1.16
Go version (client): go1.3.3
Git commit (client): 5bc2ff8
OS/Arch (client): darwin/amd64
Server version: 1.4.1
Server API version: 1.16
Go version (server): go1.3.3
Git commit (server): 5bc2ff8

Bien sûr, ce n'est pas une solution car je devrai peut-être utiliser sudoquelque part plus tard ...

Je viens de trouver une autre page disant " Si vous utilisez OS X, vous ne devriez pas l'utiliser sudo." Je ne sais pas s'ils signifient uniquement pour cet exemple, ou en général.

Pour moi, l'exécution a $(boot2docker shellinit 2> /dev/null)résolu le problème.

Cela exécute la sortie de la boot2docker shellinitcommande (les trois set -x ...lignes) dans votre session de terminal actuelle, ce qui permet à la dockercommande de savoir où trouver la machine virtuelle boot2docker.

L'ajout $(boot2docker shellinit 2> /dev/null)au bas de votre ~/.bash_profilefichier vous assurera que la dockercommande est configurée, chaque fois que vous ouvrez votre terminal.

Pour les personnes utilisant la coquille de poisson: boot2docker shellinit ^ /dev/null | source.

Notez que 2> /dev/null(et l'équivalent poisson ^ /dev/null) sont facultatifs. Comme l'a suggéré @ pablo-fernandez, cela masque les Writing ..lignes.

J'obtenais la même erreur sur MacOS avec sudo et sans lui.

Je l'ai résolu avec:

boot2docker start
$(boot2docker shellinit)

PS: Merci à Alan. J'ai découvert que cette approche est recommandée dans leur documentation officielle .

PS2: Parfois, il boot2docker initpeut être nécessaire de lancer deux commandes (merci Aaron).

Dans mon cas (Linux Mint 17), j'ai fait diverses choses, et je ne sais pas lesquelles sont totalement nécessaires.

J'ai inclus des packages Ubuntu manquants:

$ sudo apt-get install apparmor lxc cgroup-lite

Un utilisateur a été ajouté au groupe docker:

$ sudo usermod -aG docker ${USER}

Démon démarré (openSUSE en a juste besoin)

$ sudo docker -d

Merci \ Attribution

Merci Usman Ismail , parce que c'était peut-être juste cette dernière chose ...

Question stupide mais avez-vous démarré le démon docker? - Usman Ismail 17 décembre 14 à 15:04

Merci également à github @ MichaelJCole pour la solution qui a fonctionné pour moi, car je n'ai pas vérifié le démon lorsque j'ai lu le commentaire d'Usman.

Commentaire GitHub :

sudo apt-get install apparmor lxc cgroup-lite
sudo apt-get  install docker.io
# If you installed docker.io first, you'll have to start it manually
sudo docker -d
sudo docker run -i -t ubuntu /bin/bash

Grâce à fredjean.net pour avoir remarqué les paquets manquants et oublier les instructions d'installation d'Ubuntu par défaut et google sur d'autres façons

Il s'avère que les packages cgroup-lite et lxc ne sont pas installés par défaut sur Linux Mint. L'installation des deux m'a ensuite permis d'exécuter bash dans l'image de base, puis de créer et d'exécuter mon image.

Merci au commentaire de brettof86 sur openSUSE

Le problème sous-jacent est simple - manque d'autorisation pour /var/run/docker.sockunix socket de domaine.

À partir du chapitre sur l' option de socket Daemon de la référence de la ligne de commande Docker pour Docker 1.6.0:

Par défaut, un socket de domaine Unix (ou socket IPC) est créé sur /var/run/docker.sock, nécessitant une autorisation root ou l'appartenance à un groupe Docker .

Les étapes nécessaires pour accorder des droits aux utilisateurs sont bien décrites dans les instructions d'installation de Docker pour Fedora :

Octroi de droits aux utilisateurs pour utiliser Docker

L'outil de ligne de commande docker contacte le processus du démon docker via un fichier socket /var/run/docker.sockappartenant à root:root. Bien qu'il soit recommandé d'utiliser sudo pour les commandes docker, si les utilisateurs souhaitent l'éviter, un administrateur peut créer un groupe docker, le posséder /var/run/docker.socket ajouter des utilisateurs à ce groupe.

$ sudo groupadd docker
$ sudo chown root:docker /var/run/docker.sock
$ sudo usermod -a -G docker $USERNAME

Déconnectez-vous et reconnectez-vous pour que les modifications ci-dessus prennent effet. Veuillez noter que les packages Docker de certaines distributions Linux (Ubuntu) sont déjà placés /var/run/docker.sockdans le dockergroupe, rendant inutiles les deux premières étapes ci-dessus.

Dans le cas d'OS X et boot2dockerla situation est différente; le démon Docker s'exécute à l'intérieur d'une machine virtuelle, de sorte que la DOCKER_HOSTvariable d'environnement doit être définie sur cette machine virtuelle afin que le client Docker puisse trouver le démon Docker. Cela se fait en exécutant $(boot2docker shellinit)dans le shell.

Assurez-vous que le démon Docker est en cours d'exécution:

service docker start

Cela m'a arrangé!

1. Docker se définit comme un runtime autosuffisant pour les conteneurs Linux. En termes simples, il agit à la fois comme serveur et client.
2. La $ docker versionrequête de commande est interne à l'exécutable Docker et non au démon / service en cours d'exécution.
3. $ docker images or $ docker ps or $ docker pull centos sont des commandes qui envoient des requêtes au démon / service docker en cours d'exécution.
4. Docker prend en charge par défaut les connexions TLS à son démon / service.
5. Uniquement si l'utilisateur auquel vous êtes connecté en tant que membre du groupe d'utilisateurs dockerou que vous avez utilisé sudoavant la commande, par exemple $ sudo docker images, ne nécessite pas de connectivité TLS.

Visitez la page de documentation Docker Protéger le socket du démon Docker .

Faites défiler un peu vers le haut et recherchez la warning sectionclarté.

Vous devrez faire:

$boot2docker init
$boot2docker start

Les paramètres suivants ont résolu le problème:

$export DOCKER_HOST=tcp://192.168.59.103:2376
$export DOCKER_CERT_PATH=/Users/{profileName}/.boot2docker/certs/boot2docker-vm
$export DOCKER_TLS_VERIFY=1

Il est possible que vous n'ayez pas encore l'autorisation sur le fichier. Cela m'est arrivé après que je me suis ajouté au dockergroupe en utilisant

sudo gpasswd -a user docker

mais pas encore de déconnexion.

Pour résoudre ce problème, vous pouvez soit vous reconnecter, soit utiliser sg docker "docker <subcommand> ..."avant de vous déconnecter.

Si vous êtes en groupe docker dans /etc/group, vous devriez être en mesure d'exécuter sans mot de passe de frappe.

https://dingyichen.wordpress.com/2015/02/05/docker-dial-unix-varrundocker-sock-no-such-file-or-directory-are-you-trying-to-connect-to-a- tls-enabled-daemon-without-tls /

Sur Ubuntu après l'installation de lxc-docker, vous devez ajouter votre utilisateur au groupe d'utilisateurs docker :

sudo usermod -a -G docker myusername

Cela est dû aux autorisations du fichier socket:

srw-rw---- 1 root docker 0 Mar 20 07:43 /var/run/docker.sock

NE PAS EXÉCUTER le mode utilisateur SANS "-a" comme suggéré dans l'un des autres commentaires ou il effacera vos paramètres de groupes supplémentaires et laissera simplement le groupe "docker"

C'est ce qui se passera:

➜  ~  id pawel
uid=1000(pawel) gid=1000(pawel) groups=1000(pawel),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),108(lpadmin),124(sambashare),998(docker)
➜  ~  usermod -G docker pawel
➜  ~  id pawel               
uid=1000(pawel) gid=1000(pawel) groups=1000(pawel),998(docker)

TLDR : Cela a permis à mon groupe de rencontre Python de résoudre ce problème lorsque je dirigeais une clinique sur l'installation de docker et que la plupart des utilisateurs étaient sur OS X:

boot2docker init
boot2docker up

exécutez les exportcommandes que la sortie vous donne, puis

docker info

devrait vous dire que cela fonctionne.

Le contexte (ce qui nous a amenés au problème)

J'ai dirigé une clinique sur l'installation de Docker et la plupart des participants avaient OS X, et nous avons rencontré ce problème et je l'ai surmonté sur plusieurs machines. Voici les étapes que nous avons suivies:

Tout d'abord, nous avons installé homebrew (oui, certains participants ne l'avaient pas):

ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Ensuite, nous avons eu cask, que nous avons utilisé pour installer virtualbox, puis utilisé brew pour installer docker et boot2docker (tous requis pour OS X) N'utilisez pas sudo pour brew. :

brew install caskroom/cask/brew-cask
brew cask install virtualbox
brew install docker
brew install boot2docker

La solution

C'est à ce moment-là que nous avons rencontré le problème que le demandeur a rencontré. Ce qui suit l'a corrigé. Je comprends que initc'était une affaire unique, mais vous devrez probablement exécuter upchaque fois que vous démarrez Docker:

boot2docker init
boot2docker up

Puis quand upa été exécuté, il donne plusieurs exportcommandes. Copiez-collez et exécutez-les.

Enfin docker infodevrait vous dire qu'il est correctement installé.

Vers la démo

Le reste des commandes devrait le faire une démonstration. (sur Ubuntu linux, j'avais besoin de sudo.)

docker run hello-world
docker run -it ubuntu bash

Ensuite, vous devriez être sur un shell racine dans le conteneur:

apt-get install nano
exit

Retour à votre bash utilisateur natif:

docker ps -l

Recherchez l'identifiant hexadécimal d'environ 12 chiffres (0-9 ou af) sous "ID du conteneur", par exemple 456789abcdef. Vous pouvez ensuite valider votre modification et lui donner un nom descriptif, comme descriptivename:

docker commit 456789abcdef descriptivename`

Tout ce dont vous avez besoin pour exécuter Docker sur Linux Ubuntu / Mint:

sudo apt-get -y install lxc
sudo gpasswd -a ${USER} docker
newgrp docker
sudo service docker restart

Facultativement, vous devrez peut-être installer deux dépendances supplémentaires si ce qui précède ne fonctionne pas:

sudo apt-get -y install apparmor cgroup-lite
sudo service docker restart

J'ai essayé les solutions ici et boot2docker n'a pas fonctionné.

Ma solution: désinstaller boot2docker sur le Mac, installer une machine virtuelle Centos 7 dans VirtualBox et travailler avec Docker à l'intérieur de cette machine virtuelle.

Pour moi, les étapes suivantes ont fonctionné:

1. J'ai remarqué que la course docker run hello-worldéchoue avec cette erreur bloquée comme dans la question, mais la course a sudo docker run hello-worldfonctionné.
2. J'ai ajouté mon utilisateur actuel au dockergroupe sudo adduser user docker,. Ensuite, vous devez redémarrer votre machine ou utiliser su - user(vérifiez à l'aide de la groupscommande si vous êtes dans le dockergroupe).

Après cela, a hello-worldcommencé à travailler.

Ma réponse est basée sur Comment puis-je utiliser Docker sans sudo? ce qui explique ce qui ne va pas.

Pour ce que ça vaut, j'ai essayé toutes les solutions dans cette question et dans cette question connexe et aucune n'a résolu mon problème jusqu'à ce que j'ai désinstallé et réinstallé VirtualBox . Ce processus a mis à niveau la VirtualBox de la version 4.2.16 à la 4.3.22 (ma précédente était restée inutilisée sur le système pendant quelques mois).

Puis boot2dockeret dockertravaillé sans autres ajustements.

J'ai eu le même problème. Un simple a service docker restartrésolu le problème.

Le démon Docker se lie à un socket Unix au lieu d'un port TCP. Par défaut, le socket Unix appartient à l'utilisateur root et les autres utilisateurs ne peuvent y accéder qu'en utilisant sudo. Le démon Docker s'exécute toujours en tant qu'utilisateur root.

sudo groupadd docker
sudo usermod -aG docker $USER

Déconnectez-vous et reconnectez-vous pour que votre appartenance à un groupe soit réévaluée.

docker run hello-world

Source: Gérer Docker en tant qu'utilisateur non root

J'ai eu le même problème et j'ai essayé diverses choses pour résoudre ce problème, en modifiant le fichier .bash_profile, en me connectant et en me déconnectant, sans aucune chance. En fin de compte, le redémarrage de ma machine l'a corrigé.

Assurez-vous qu'il y a

127.0.0.1    localhost

dans votre

`/etc/hosts `

fichier.

J'ai rencontré le même problème lorsque je créais des images Docker à partir de Jenkins. Ajoutez simplement l'utilisateur audocker groupe, puis redémarrez les services Docker et dans mon cas, j'ai dû redémarrer les services Jenkins.

Ce fut l'erreur que j'ai eu:

http:///var/run/docker.sock/v1.19/build?cgroupparent=&cpuperiod=0&cpuquota=0&cpusetcpus=&cpusetmems=&cpushares=0&dockerfile=Dockerfile&memory=0&memswap=0&rm=1&t=59aec062a8dd8b579ee1b61b299e1d9d340a1340: dial unix /var/run/docker.sock: permission denied. Are you trying to connect to a TLS-enabled daemon without TLS?
FATAL: Failed to build docker image from project Dockerfile
java.lang.RuntimeException: Failed to build docker image from project Dockerfile

Solution:

[root@Jenkins ssh]# groupadd docker
[root@Jenkins ssh]# gpasswd -a jenkins docker
Adding user jenkins to group docker
[root@Jenkins ssh]# /etc/init.d/docker restart
Stopping docker:                                           [  OK  ]
Starting docker:                                           [  OK  ]
[root@Jenkins ssh]# /etc/init.d/jenkins restart
Shutting down Jenkins                                      [  OK  ]
Starting Jenkins                                           [  OK  ]
[root@Jenkins ssh]#

Une autre raison possible est que la visualisation de votre CPU BIOS n'est pas activée. Allez et activez-le d'abord!