Machine: 【Решено】 Как докер-машина может добавить существующий докер-хост?

Поддерживает ли докер-машина существующий хост-докер?

Поскольку я искал документы последние 5 часов, на самом деле есть опция "--driver = none" (недокументированная). См. Https://github.com/docker/machine/issues/2270 .

@ tdy218 @atemerev Насколько я помню, параметры --driver none были намеренно похоронены (и я думал, что они удалены из выпущенного исполняемого файла), потому что они используются только для целей тестирования.

Связанная проблема: у меня есть капля в цифровом океане, созданная с помощью docker-machine. Как я могу управлять экземпляром с другого ноутбука?

Коллега воссоздал сертификаты со своего ноутбука, используя docker-machine regenerate-certs [name] . и теперь я больше не могу получить доступ к своему экземпляру. Следует ли копировать новые сертификаты куда-нибудь вручную? Документация по этому поводу действительно сбивает с толку.

$ docker-machine ls
NAME           ACTIVE   DRIVER         STATE     URL                        SWARM   DOCKER    ERRORS
default        -        virtualbox     Stopped                                      Unknown   
gapp-sandbox   *        digitalocean   Running   tcp://xx.xxx.xxx.xx:2376           Unknown   Unable to query docker version: Get https://xx.xxx.xxx.xx:2376/v1.15/version: x509: certificate signed by unknown authority

Я нашел обходной путь: https://github.com/docker/machine/issues/2270

Отредактируйте config.json машины, чтобы он указывал на ключи CA и клиента для этой конкретной машины, а не на глобальные.

Поэтому я скопировал все файлы из папки моего коллеги и заменил все пути на пути моей машины. В моем случае последний путь - /Users/mturatti/.docker/machine/machines/gapp-sandbox/ .
Неприятное решение, но вроде работает.

ca.pem
cert.pem
config.json
id_rsa
id_rsa.pub
key.pem
server-key.pem
server.pem

@dweomer Разве добавление существующей док-машины с другого компьютера не является очень распространенным и базовым вариантом использования?

@dweomer Разве добавление существующей док-машины с другого компьютера не является очень распространенным и базовым вариантом использования?

@atemerev : Нет, не думаю. Насколько я понимаю, Docker Machine существует для создания / предоставления хостов с поддержкой Docker.

При этом существует несколько менее очевидный драйвер generic который, я думаю, должен использовать @ tdy218 . Драйвер generic возьмет на себя управление хостом и повторно подготовит его. Все, что для этого требуется, - это работающий хост с демоном ssh и пользователь на этом хосте с доступом без пароля sudo (или просто root). Это повторное предоставление не является разрушительным, поскольку существующая установка Docker будет не более чем обновлена.

@dweomer
Я попытался использовать общий драйвер для добавления существующего узла докеров в следующем тестировании.
Имя локального хоста (мой ноутбук): Chris-Laptop
docker-machine уже установлена, версия 0.6.0, сборка e27fb87, Mac OS X 10.11
Имя удаленного хоста (Мой VPS): li845-130 (139.162.3.130)
docker-engine уже установлен, CentOS 7.0

1. процесс демона докера на удаленном хосте
[ root @ li845-130 ~] # ps -ef | grep docker |
корень 12093 1 0 02:09? 00:00:00 / usr / bin / docker daemon -H tcp: //0.0.0.0 : 2376

2. Настройте ssh-соединение без пароля
[ tdy218 @ Chris-Laptop ~] $ ssh [email protected]
Последний вход: Пн 28 Мар 03:06:07 2016 от 111.193.199.188

3.Добавьте удаленный хост-докер к локальным докер-машинам
[ tdy218 @ Chris-Laptop ~] $ docker-machine -D create --driver generic --generic-ip-address 139.162.3.130 --generic-ssh-user root linodevps
Версия Docker Machine: 0.6.0, сборка e27fb87
Найден двоичный путь в / usr / local / bin / docker-machine
Запуск сервера плагинов для драйвера generic
Сервер плагина прослушивает адрес 127.0.0.1:50319
() Вызов .GetVersion
Использование API версии 1
() Вызов .SetConfigRaw
() Вызов .GetMachineName
(flag-lookup) Вызов .GetMachineName
(flag-lookup) Вызов .DriverName
(flag-lookup) Вызов .GetCreateFlags
Найден двоичный путь в / usr / local / bin / docker-machine
Запуск сервера плагинов для драйвера generic
Сервер плагина прослушивает адрес 127.0.0.1:50323
() Вызов .GetVersion
Использование API версии 1
() Вызов .SetConfigRaw
() Вызов .GetMachineName
(linodevps) Вызов .GetMachineName
(linodevps) Вызов .DriverName
(linodevps) Вызов .GetCreateFlags
(linodevps) Вызов .SetConfigFromFlags
Выполнение предварительных проверок ...
(linodevps) Вызов .PreCreateCheck
(linodevps) Вызов .GetConfigRaw
Создание машины ...
(linodevps) Вызов .Create
(linodevps) Вызов .GetConfigRaw
(linodevps) Не указан ключ SSH. Для подключения к этому компьютеру сейчас и в будущем потребуется, чтобы агент ssh содержал соответствующий ключ.
(линодевпс) DBG | IP: 139.162.3.130
(linodevps) Вызов .DriverName
(linodevps) Вызов .DriverName
Ожидание запуска машины, это может занять несколько минут ...
(linodevps) Вызов .GetState
Обнаружение операционной системы созданного экземпляра ...
Ожидание доступности SSH ...
Переход к функции WaitForSSH ...
(linodevps) Вызов .GetSSHHostname
(linodevps) Вызов .GetSSHPort
(linodevps) Вызов .GetSSHKeyPath
(linodevps) Вызов .GetSSHUsername
Тип клиента SSH: внешний
{[-o BatchMode = yes -o PasswordAuthentication = no -o StrictHostKeyChecking = no -o UserKnownHostsFile = / dev / null -o LogLevel = quiet -o ConnectionAttempts = 3 -o ConnectTimeout = 10 -o ControlMaster = no -o ControlPath = none [email protected] -p 22] / usr / bin / ssh}
О запуске команды SSH:
выход 0
SSH cmd err, вывод::
Обнаружение инициатора ...
(linodevps) Вызов .GetSSHHostname
(linodevps) Вызов .GetSSHPort
(linodevps) Вызов .GetSSHKeyPath
(linodevps) Вызов .GetSSHUsername
Тип клиента SSH: внешний
{[-o BatchMode = yes -o PasswordAuthentication = no -o StrictHostKeyChecking = no -o UserKnownHostsFile = / dev / null -o LogLevel = quiet -o ConnectionAttempts = 3 -o ConnectTimeout = 10 -o ControlMaster = no -o ControlPath = none [email protected] -p 22] / usr / bin / ssh}
О запуске команды SSH:
кошка / и т. д. / os-release
SSH cmd err, вывод:: NAME = "CentOS Linux"
VERSION = "7 (Core)"
ID = "centos"
ID_LIKE = "Рел Федора"
VERSION_ID = "7"
PRETTY_NAME = "CentOS Linux 7 (Core)"
ANSI_COLOR = "0; 31"
CPE_NAME = "cpe: / o: centos: centos : 7"
HOME_URL = " https://www.centos.org/ "
BUG_REPORT_URL = " https://bugs.centos.org/ "

CENTOS_MANTISBT_PROJECT = "CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION = "7"
REDHAT_SUPPORT_PRODUCT = "centos"
REDHAT_SUPPORT_PRODUCT_VERSION = «7»

Не удалось установить ключевой CPE_NAME, соответствующее поле структуры не найдено
Не удалось установить ключ, соответствующее поле структуры не найдено
Не удалось установить ключ CENTOS_MANTISBT_PROJECT, соответствующее поле структуры не найдено
Не удалось установить ключ CENTOS_MANTISBT_PROJECT_VERSION, соответствующее поле структуры не найдено
Не удалось установить ключ REDHAT_SUPPORT_PRODUCT, соответствующее поле структуры не найдено
Не удалось установить ключ REDHAT_SUPPORT_PRODUCT_VERSION, соответствующее поле структуры не найдено
Не удалось установить ключ, соответствующее поле структуры не найдено
найден совместимый хост: centos
Подготовка с помощью centos ...
Не указан драйвер хранилища, используя devicemapper

(linodevps) Вызов .GetMachineName
(linodevps) Вызов .GetSSHHostname
(linodevps) Вызов .GetSSHPort
(linodevps) Вызов .GetSSHKeyPath
(linodevps) Вызов .GetSSHUsername
Тип клиента SSH: внешний
{[-o BatchMode = yes -o PasswordAuthentication = no -o StrictHostKeyChecking = no -o UserKnownHostsFile = / dev / null -o LogLevel = quiet -o ConnectionAttempts = 3 -o ConnectTimeout = 10 -o ControlMaster = no -o ControlPath = none [email protected] -p 22] / usr / bin / ssh}

4. Командная строка удаленного хоста докера.
[ root @ linodevps ~] # ps -ef | grep docker |
корень 17079 1 0 03:06? 00:00:00 / usr / bin / docker daemon -H tcp: //0.0.0.0 : 2376
корень 17185 1 0 03:06? 00:00:00 версия sudo docker
корень 17190 17185 0 03:06? 00:00:00 версия докера

Процесс демона докера был перезапущен, но было еще два процесса версии докера, затем я попытался выполнить команду версии докера вручную, она зависла.

Так сложно добавить существующий хост докера в командную строку докер-машины ...

Если удаленный хост без какого-либо механизма докера в нем, легко создать хост докера (установить механизм докера) из командной строки докер-машины, но, как указано выше, докер-машина ограничена.

@dweomer Это правда, но если я подготовил docker-machine или docker-swarm, как мне, скажем, разрешить другому разработчику развертывать там контейнеры? Как передать переменные конфигурации / env между машинами? Пока что я могу использовать только подготовленные хосты док-машины и только с одной машины (что, если она сломана? Как мне восстановить конфигурацию на другой машине?).

Для меня docker-machine / docker-swarm очень далеки от готовности к производству, и их следует как минимум пометить как beta. Или я хотел бы получить известие от тех, кто действительно использует его в производстве ...

FWIW, если вы просто перетащите ~ / .docker с этого хоста рабочей станции на новый (предполагая, что домашний каталог имеет тот же путь), он будет работать. Если домашний каталог отличается, вам нужно будет отредактировать файлы .json в нескольких местах (ключи, сертификаты и т. Д.), Чтобы изменить, например, /Users/macuser/.docker на /home/linuxuser/.docker .

Похоже, этот вопрос был тщательно рассмотрен и / или охватывает почву, уже установленную в других вопросах. Спасибо всем.

@nathanleclaire Чтобы прояснить, является ли официальный подход к добавлению существующих хостов докеров (созданных докер-машиной или другим способом) для копирования папки ~ / .docker между клиентскими машинами? Если да, то есть ли какое-то конкретное подмножество файлов / файла, которые нам нужно скопировать?

Если вместо этого официальный подход заключается в использовании универсального драйвера, было бы полезно решить проблему @ tdy218, описанную в комментарии здесь .

Не думаю, что этот вопрос вообще решался. Я пытаюсь перенести код на новую машину и лучший ответ, который может придумать любой, - найти парня, который сделал машину, и скопировать его файлы на мои.

Я не уверен, пробовал ли кто-нибудь это здесь, в реальном мире, но это отстой.

@TheSeanBrady Давайте продолжим обсуждение гражданских вопросов. Если у вас есть предложения по решениям, которые вы хотели бы видеть, поделитесь ими. Давайте сосредоточимся на решениях, а не на проблемах.

Я просто честен. Вы пытаетесь отправлять электронные письма с просьбой о файлах, потому что пока у меня это не работает. Это было закрыто без решения проблемы.

Я просто честен. Вы пытаетесь отправлять электронные письма с просьбой о файлах, потому что пока у меня это не работает. Это было закрыто без решения проблемы.

Вам не кажется, что сказать что-то «отстой» и намекнуть, что остальные из нас не живут «в реальном мире», является излишне резким и неконструктивным?

Мы стараемся создать сообщество, в котором поощряются сотрудничество и позитив. Я прошу, если вы хотите участвовать, следуйте этим принципам.

Из-за использования сохраненных учетных данных API, ключей SSH и сертификатов совместное использование docker-machine s на компьютерах представляет собой полномасштабную проблему управления секретами / ACL, для решения которой были изобретены целые другие классы технологий. Это довольно большая проблема по масштабам. Потенциально можно предпринять шаги для смягчения его последствий, которые помогут вашему варианту использования, так почему бы не предложить некоторые упреждающие решения для реализации?

Если вы хотите представить предложение по решению этой проблемы, не стесняйтесь. Если вы хотите также сделать предложение, подкрепленное кодом в запросе на перенос, я также рекомендую вам это сделать. Но в любом случае, пожалуйста, сосредоточьтесь на обсуждении решений и оставайтесь позитивными.

Вам не кажется, что сказать что-то «отстой» и намекнуть, что остальные из нас не живут «в реальном мире», является излишне резким и неконструктивным?

Не совсем, когда будет продолжение ...

Похоже, этот вопрос был тщательно рассмотрен и / или охватывает почву, уже установленную в других вопросах. Спасибо всем.

Это в значительной степени то, что я называю увольнением. И под «реальным миром» я подразумеваю среду, в которой мы используем эти вещи, а не где вы можете пройти мимо одного из разработчиков в зале.

Это был бы более подходящий ответ ...

Из-за использования сохраненных учетных данных API, ключей SSH и сертификатов совместное использование докер-машин на компьютерах представляет собой полномасштабную проблему управления секретами / ACL, для решения которой были изобретены целые другие классы технологий.

... хотя эти технологии были изобретены и большинство из них имеют открытый исходный код.

Однако, поскольку вы спросили, как насчет docker-machine add <hostname> , использующего аутентификацию с помощью ключа SSH для передачи необходимых сертификатов для TLS-соединения?

как насчет добавления докер-машины, используя аутентификацию по ключу SSH для передачи необходимых сертификатов для TLS-соединения?

Это могло бы решить проблему ... по крайней мере, для среды разработки

Другой вариант - использовать докер-сокет на хосте, доступном через SSH, что для меня намного предпочтительнее, поскольку он использует существующий механизм аутентификации SSH (который в моем случае поддерживается HSM) и не требует настройки портов / брандмауэров для поддержка TLS.

Я собрал собственное решение для этого с помощью socat, но было бы очень хорошо, если бы докер-машина могла его поддерживать. Нетрудно подключиться к хосту по ssh, установить socat, если он еще не установлен, и использовать socat, чтобы превратить сеанс ssh в локальный сокет для связи с удаленным /var/lib/docker.sock. Это также означает, что докер-машине не нужно будет ничего знать об аутентификации, сертификатах или TLS в этом режиме драйвера, хотя это зависит от socat локально для создания локального сокета ...

Было бы неплохо увидеть режим драйвера, который выполняет такую ​​настройку локального сокета так же, как существующий драйвер ssh устанавливает все материалы TLS. Во многих организациях уже решена проблема распределения / перенаправления портов SSH, и ожидать, что они теперь будут распространять / управлять PKI для TLS (и открывать другой порт), обременительно.

tyrell:~▻ cat Library/Local/bin/ber1docker 
#!/bin/bash

DOCKER_REMOTE_HOST="ber1.local"
DOCKER_SOCK="$TMPDIR/docker.sock"
export DOCKER_HOST="unix://$DOCKER_SOCK"
rm $DOCKER_SOCK

socat UNIX-LISTEN:$DOCKER_SOCK,reuseaddr,fork \
   EXEC:"ssh root@$DOCKER_REMOTE_HOST 'socat STDIO UNIX-CONNECT:/var/run/docker.sock'" &

Итак, нет "добавления докер-машины ..."?

+1 за docker-machine add ...

Мы хотим иметь красоту eval $(docker-machine env mymachine) для всех членов нашей команды (конечно, для общих сред разработки).

Я создал каплю с драйвером digitalocean и запустил сайт с помощью docker-compose со своей рабочей станции.

Затем мне пришлось поработать на сайте, но из совершенно другого места, подальше от моей рабочей станции, где я выполнял исходные команды docker-machine.

Разве это не обычная ситуация?

Это очень распространенное решение. Особенно, если вы работаете в так называемой «команде». Но вот уже около 18 месяцев они избегают этой темы. Все, что они делают, это закрывают подобные проблемы, а затем говорят что-то вроде «очень сложно реализовать такую ​​функцию», и что вы можете сделать это самостоятельно и предложить пулреквест в любое время.
Мне кажется, что они даже не начали работать над решением в течение последних 18 месяцев.

Спасибо за ответ, хотя это еще не простой способ понять.

Храните учетные данные и многое другое в облаке.

Дайте мне инструкции, как использовать мой Dropbox или Google диск для его хранения.

Позвольте мне запросить информацию из digitalocean, поскольку это драйвер, который я использовал.

Это действительно не может быть так сложно.

Да, звучит безопасно.
В среду, 9 ноября 2016 г., в 09:28 Майкл Шварц [email protected]
написал:

Храните учетные данные и многое другое в облаке.

Дайте мне инструкции, как использовать мой Dropbox или Google диск для его хранения.

Это действительно не может быть так сложно.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/docker/machine/issues/3212#issuecomment -259457472,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ABxbKbZQLUfK9ENnWpNKiF207ZGpXFs2ks5q8fSagaJpZM4H07I2
.

Не менее безопасно, чем отправка команд и всего моего кода через Интернет в первую очередь DO.

Или загружаю все свои проприетарные файлы в docker hub или github, даже в частное репо.

Для тех, кто пытается добавить докер-машину в среду разработки, вы можете сделать так:

docker-machine create -d "none" --url http://192.168.10.100 : 4243 bla

это если на хосте включена аутентификация HTTP, а не TSL.

Я потратил много времени на поиски этого недокументированного материала

Я думаю, что было бы немного недальновидно разрешить только одной машине управлять кластером докеров. Больше, чем просто разделение ответственности за управление кластером с вашей командой, как насчет наличия более одной точки отказа или разрешения нескольким автоматическим агентам взаимодействовать с кластером докеров?

+1 для команды экспорта.

Он может экспортировать все настройки и сертификаты в защищенный файл tar или zip, который можно импортировать в докер-машину с паролем.

Вроде разумная просьба.

@bmmathe Эта команда уже tar -c ~/.docker/machine | bzip2 > docker-machine-config.tbz2 .

Вот как с этим справляется lxd. Возможно, на машине можно настроить пароль или ключ, которые позволят ему копировать или восстанавливать сертификаты.

Это так грустно 😖. Мои удаленные машины теперь показывают локально timeout статус при запуске docker-machine ls , что-то испортило конфигурацию машины. Кажется, не могу понять, как перенастроить / исправить их в локальной папке машин Docker. Больше нет локального обеспечения? Следует ли мне удалить виртуальные машины и создать их заново?

Голосование за возможность добавления удаленных машин к локальным машинам Docker:

докер-машина добавить--Водитель

⏳🤒

Это действительно важная особенность. Я не понимаю, почему это так сложно. Даже если мне нужно регенерировать сертификаты, это не будет проблемой для меня, но я хотел бы, чтобы это задокументировано и команда для работы.

Если я правильно помню, моя проблема была вызвана неправильными разрешениями и / или локальным именем пользователя, не совпадающим с удаленным (пользователь по умолчанию - docker-user ). Вероятно, это проблема для вас, вам нужно копнуть глубже.
Универсальный драйвер для команды docker-machine отлично работает для разных провайдеров, например, для Google.

Проверьте это:
• https://github.com/docker/machine/issues/3522#issuecomment -280275707
• https://docs.docker.com/machine/drivers/generic/
• Не могу найти другие разговоры на эту тему, которые привели меня к решению.

Сегодня я обнаружил причину добавления сбоя удаленного хоста докера в моем случае.
[ root @ linodevps ~] # ps -ef | grep docker | grep -v grep
корень 17079 1 0 03:06? 00:00:00 / usr / bin / docker daemon -H tcp: //0.0.0.0 : 2376 // Этот стиль записи не разрешает локальную связь fd или unix-сокета между клиентом докера и сервером, поэтому он зависает в sudo docker version при выполнении команды docker-machine add.

Чтобы исправить это, просто нужно отредактировать файл конфигурации службы докеров (по умолчанию /usr/lib/systemd/system/docker.service), изменить значение параметра ExecStart с / usr / bin / docker daemon -H tcp: // 0.0.0.0 : 2376 в / usr / bin / docker daemon -H tcp: //0.0.0.0 : 2376 -H unix: ///var/run/docker.sock (по умолчанию / usr / bin / docker daemon -H fd: //) или / usr / bin / docker daemon -H tcp: //0.0.0.0 : 2376 -H fd: // или экспорт DOCKER_HOST = tcp: //0.0.0.0 : 2376,
а затем sudo systemctl daemon-reload && sudo systemctl restart docker, повторно выполните команду docker-machine add, подождите немного, она успешно добавится. В процессе добавления докер-машина сгенерирует ssl-сертификаты для целевого хост-докера и сгенерирует новый файл конфигурации службы докеров 10-machine.conf в новом каталоге с именем /etc/systemd/system/docker.service.d

tdy218 @ Chris-Ноутбук $ dm ls
ИМЯ АКТИВНЫЙ ДРАЙВЕР СОСТОЯНИЕ URL ОШИБКИ SWARM DOCKER
docker-vm119 - общий Запуск tcp: //192.168.135.119 : 2376 v17.03.1-ce
docker-vm120 - общий остановлен неизвестно

docker-vm119 - это существующий хост докера перед добавлением.

Из этого случая мы знаем, что докер-машина поддерживает добавление существующего хоста докера, спасибо @Bean Young.

docker-machine create --driver none -url=tcp://123.123.123.123:2376 dockerhost1 - лучшее, что я узнал о докере за долгое время!

На самом деле должно быть проще поделиться машиной для разработки между пользователями.

// cc @nathanleclaire

update: чтобы было ясно: в частности, я не возражаю предварительно поделиться сертификатами с другими членами команды. Там тоже есть возможности для улучшения.

@dhrp какой процесс вы выполняете для предварительного предоставления сертификатов? Где их найти?

О мой дорогой господин, не могу поверить, что за последние полтора года никто не хотел снимать эту проблему 😞 😞 😞

@thaJeztah @AkihiroSuda @albers @tianon вы действительно думаете, что это не очень распространенное и важное требование?

Я попытался повторно подготовить существующий узел докера ( docker-machine create --driver=generic --generic-ip-address <ip> <name> и, похоже, он работал без аннулирования существующих сертификатов. Это было сделано с того же компьютера, на котором изначально был подготовлен хост докера ... это ожидаемый результат?

Можете ли вы снова открыть эту проблему? Я не думаю, что это решено.

Наткнулся на это случайно.

Что ж, @nathanleclaire прояснил точку: это НЕ точка добавления функции docker-machine, а скорее точка совместного использования ключей, которые НЕ должны храниться где-либо еще, кроме исходной клиентской машины. Именно так это и должно быть сделано, и некоторые люди здесь злятся, не уделяя достаточно внимания этому предмету.

Если вы действительно хотите поделиться ключами с командой, просто продолжайте работу с любым частным репозиторием системы управления версиями и примите риски, которые вы берете на себя. Для экспорта необходимых ключей существует уже созданный скрипт: https://gist.github.com/schickling/2c48da462a7def0a577e.

«Нет причин, по которым мы не можем быть вежливыми» - Леонид.

Я все еще думаю, что docker-machine должна вести себя больше как scp. Что мешает добавить поддержку нескольких ключей?

Одно решение, которое я только что нашел.
Если у вас есть докер-машина на той же платформе (моя - google), и вы можете использовать ssh / scp на этой машине, не требуя докер-машины, вы можете скопировать другую машину и заставить ее работать.
Я сделал:

mkdir ~/.docker/machine/machines/new-machine
cp -r ~/.docker/machine/machines/old-machine/* ~/.docker/machine/machines/new-machine/

#then replace all instances of "old-machine" with "new-machine" in ~/.docker/machine/machines/new-machine/config.json

#then add the public key from your new-machine folder into the authorized_keys file for the docker-user on the new machine, e.g.
scp ~/.docker/machine/machines/new-machine/id_rsa.pub docker-user<strong i="8">@new_machine</strong>:/home/docker-user
ssh docker-user<strong i="9">@new_machine</strong> -c "cat ~/id_rsa.pub >>~/.ssh/authorized_keys"

(Не копируйте команды ssh дословно, узнайте, как это сделать правильно - https://encrypted.google.com/search?hl=en&q=ssh%20copy%20public%20key)

+1 для команды экспорта / импорта.
+1 за поддержку нескольких клавиш.

Невозможность перемещать рабочие станции управления просто недопустима и создает массовую единую точку отказа.

например, потерянный компьютер, кража, пожар, аппаратный сбой, программный сбой, проблемы с доступом к группе, проблемы с администратором и т. д.

Docker-machine задумывалась не с учетом этого - это инструмент быстрого питания для обеспечения работы одного разработчика. Вот и все, просто и понятно, и это работает - и это бесплатно!

Некоторые упомянутые здесь функции реализованы в предложении Docker EE (например, команды и RBAC).

Если люди не могут быть благодарными, постарайтесь хотя бы быть разумными.

Я не верю, что совместное использование машины еще упоминалось в этой теме:

machine-export <machine-name>
>> exported to <machine-name>.zip
machine-import <machine-name>.zip
>> imported

Привет @andrevtg

Извините, если я показался неблагодарным. Я очень люблю докер-машину и подумал, что это сделает ее еще лучше.
Я думаю, что возможность разработчикам-одиночкам легко перемещаться между компьютерами была бы действительно полезной.

Если мое расписание освободится, я могу попробовать изучить GO и попробовать добавить эту функцию.

Привет @ dmitrym0

Я думаю, что этот билет был больше ориентирован на отсутствие возможности подключиться к существующим удаленным хостам докеров.
При этом совместное использование машины кажется полезным при перемещении локальных узлов докеров.
Спасибо за предложение.

@ Jared-Harrington-Gibbs machine-share специально решает проблему «добавления существующих хостов докер-машин». Мы развертываем различные приложения через docker-compose, и нам это хорошо подходит. Мы экспортируем набор сертификатов с помощью machine-share и раздаем его всем членам команды, которым он нужен. Это не идеально, но работает нормально.

Я попытался использовать общий драйвер для добавления существующего хоста докера, он будет успешно добавлен после нескольких попыток.

@sneak Это решение, похоже, не работает для меня, поскольку пути в config.json не будут указывать на правильные файлы. Я бы предположил, что docker-machine полагается на файл config.json , но я могу ошибаться, еще не тестировал его.

Это представляет для меня проблему, потому что я, возможно, выполняю из среды, где я могу не знать точный путь, в котором хранятся файлы. Может быть, может быть вариант для относительного пути?

Если проблема в людях, я мог бы выделить несколько дней, чтобы попытаться найти решение для сообщества. Хотя я бы предпочел получить указания от сопровождающих. Означает ли [Resolved] в этом случае решение не поддерживать эту функцию изначально, или она уже поддерживается где-то, чего я не вижу?

Эта функция НЕ ПРЕДНАЗНАЧЕНА для реализации. Нет смысла ожидать, что удаленная машина будет хранить закрытые ключи, которые не должны существовать где-либо, кроме как на исходной машине разработчика.

Даже Docker EE гарантирует, что каждый раз при запросе создается новый «клиентский пакет», и не сохраняет их на хосте.

Здесь люди просят функцию, которую легко реализовать, но которую вообще нет смысла реализовывать из-за разумных ограничений безопасности.

@andrevtg Запрос предназначен не для самой виртуальной машины для хранения ключей (что сделало бы ключи совершенно бесполезными), а для клиента докер-машины (который состоит из кода, это реальное приложение), чтобы предоставить пользователям возможность добровольно передавать ключи от одного клиента другому.

Один простой способ сделать это может заключаться в предоставлении команды docker-machine export которая объединяет ключи в архив, и соответствующей команды docker-machine import для получателя этого архива для импорта машин, описанных в архив. В этом случае шифрование / дешифрование на границах передачи ключей является делом пользователей (они могут использовать электронную почту PGP, SFTP, что угодно).

Именно docker-machine create создает огромный файл конфигурации и ключи, которые новички не понимают или не умеют копировать. Возможно, создать ключ ssh так же просто, как добавить ключ в файл hosts, но это не задокументировано. В какой контейнер мы его добавляем? И как нам установить его на другой машине и уведомить об этом docker-machine ? Можем ли мы по-прежнему использовать docker-machine use или нам придется вручную устанавливать все переменные среды.

В идеале должен быть docker-machine add [name] для добавления ключа, docker-machine export для экспорта файлов конфигурации и docker-machine import для импорта этих файлов конфигурации на другой компьютер. Также было бы неплохо иметь docker-machine rm [name] для отмены доступа к ключам.

@dhrp У меня есть
docker-machine create --driver none -url=tcp://raspberry.local:22 rpihost
Это работает?

Так @ 360disrupt , не так ли? Я борюсь с тем же сценарием использования.

Так @ 360disrupt , не так ли? Я борюсь с тем же сценарием использования.

Нет, не сейчас.

Всем привет. Это еще не решено? Мы используем докер для всех приложений в компании, в которой я работаю. Наша самая большая проблема связана с совместным использованием машин. Я пытался использовать универсальный драйвер несколько раз, но проблема с этим подходом заключается в том, что когда вы создаете машину с универсальным драйвером и подключаете его к существующему серверу, создание просто удаляет те контейнеры, которые в настоящее время работают на сервере.

Единственный способ, который мы нашли, - это создать простой скрипт на Python, который просто импортирует и экспортирует машину, к которой разработчик хочет получить доступ. Этот сценарий отвечает за копирование всех файлов конфигурации и сертификатов от владельца машины в новый источник. Он работает хорошо, и у нас нет никаких проблем с этим, просто я не могу поверить, что нет официального способа совместного использования машин без необходимости делиться нашими частными сертификатами.

Я работаю над проектом и опубликую его на GitHub, чтобы решить эту проблему другим способом. По сути, я просто создаю PaaS, в котором будут собраны все сертификаты всех машин, которые есть в нашей компании. И когда кто-то хочет развернуть или сделать что-то подобное, вам просто нужно подключиться к PaaS, а не к серверу. Это похоже на туннель. Скоро я выпущу первую версию этого PaaS.

+1 за docker-machine add или docker-machine create --existing

это решило мою проблему: machine-share : computer:: rabbit2:

@dweomer Разве добавление существующей док-машины с другого компьютера не является очень распространенным и базовым вариантом использования?

@atemerev : Нет, не думаю. Насколько я понимаю, Docker Machine существует для создания / предоставления хостов с поддержкой Docker.

При этом существует несколько менее очевидный драйвер generic который, я думаю, должен использовать @ tdy218 . Драйвер generic возьмет на себя управление хостом и повторно подготовит его. Все, что для этого требуется, - это работающий хост с демоном ssh и пользователь на этом хосте с доступом без пароля sudo (или просто root). Это повторное предоставление не является разрушительным, поскольку существующая установка Docker будет не более чем обновлена.

Я знаю, что это, похоже, решенный вопрос, но я просто хотел заявить, что должен согласиться с почти еженедельно .

это решило мою проблему: разделение машины 💻 🐇

Я могу подтвердить, что этот пакет npm действительно работает.