Machine: Подключиться к существующей машине от другого клиента

: +1:

Как насчет того, чтобы добавить его во вторую систему с помощью «универсального» драйвера, а затем использовать там ту же команду eval?

@clnperez - это предложение или то, что вы уверены, что оно работает (означает, что будет повторно использоваться существующий удаленный компьютер, даже если он уже запущен)?

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

Я вижу твой случай. Нельзя добавить запись докер-машины во вторую систему с использованием универсального драйвера, если вы не хотите аннулировать исходную настройку докер-машины (поскольку, например, генерируются новые кредиты). Можно запустить docker-machine create -d none --url [...] во второй системе, отразив важные параметры (например, флаги роя) из исходного создания в первой системе, а затем вручную скопировать выбранные файлы .pem и файл id_rsa с первой машины на вторую. И вручную добавьте разделы для доступа по SSH (и вручную измените драйвер на общий с нуля). Это ПИТА. Правильная функция экспорта / импорта было бы неплохо, чтобы разрешить совместное использование. Можно также поделиться только кредитными файлами, необходимыми для ручной настройки докера.

Верный. Единственный текущий способ - взять весь каталог, но это не будет работать с некоторыми драйверами (например, VirtualBox, потому что он регистрирует виртуальные машины и сети с UUID, которые не совпадают). Ранее обсуждались возможности импорта / экспорта (https://github.com/docker/machine/issues/23)

У меня есть PR / хакерское решение этой проблемы ... В общем, я думаю, что хочу перенести конфигурацию на переносную / шаблонную, а не жестко запрограммированную, как сейчас.

+1

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

Конечно, наличие импортируемых / экспортируемых конфигураций было бы очень полезно, но мне интересно, может ли (дополнительно) решение этой проблемы как проблемы драйвера не упростить взаимодействие с пользователем.

Таким образом, используя драйвер Google, можно подключиться к существующему экземпляру на альтернативном компьютере, просто предоставив действительный токен доступа (который драйвер может предложить пользователю создать автоматически).

Точно так же, например, при использовании драйвера aws (что мне еще предстоит сделать, но я предполагаю), можно подключиться к существующему экземпляру, предоставив действительную пару ключ / секрет (возможно, через переменные среды, соответствующие соответствующему драйверу. flags - предполагается, что процесс будет происходить с помощью какой-либо подкоманды docker-machine, отличной от «create», поскольку ожидания немного другие).

Просто хочу сказать, что это действительно отличная функция. Я действительно хотел бы иметь возможность поделиться машиной со своими товарищами по команде и был разочарован, узнав, что прямо сейчас у меня нет возможности сделать это. Было бы здорово, если бы, например, драйвер generic мог автоматически определять, был ли конкретный ящик уже подготовлен с помощью docker-machine и повторно использовать сертификаты tls и т. Д., Когда кто-то запускал docker-machine create снова на этой коробке.

: +1. Я бы хотел, чтобы это работало. В настоящее время мы совместно управляем одними и теми же машинами (в Google Compute Engine) с другим человеком, и единственный способ, который я нашел работающим, - это скопировать весь каталог (+ изменить абсолютные ссылки в файле config.json). Это глупо. Я думаю, что общий драйвер не может быть легко использован таким образом - конечно, существует проблема аутентификации (tls-сертификаты и т. Д.), Которые нельзя просто повторно использовать при запуске --create с универсальным драйвером (каким-то образом вам нужно аутентифицировать и доказать, что вы иметь доступ к машине, которая отличается для каждого драйвера - в GCE вам нужно будет проверить, позволяет ли ваша аутентификация gcloud получить доступ к машине). Также существует небольшая проблема, заключающаяся в том, что если вы еще не создали машину с заданным драйвером, ваша часть аутентификации отсутствует (единственный способ аутентификации - это .. создать машину).

Я считаю, что лучшим решением является наличие команды «import» (с разной реализацией для разных драйверов). Например, в GCE вы можете хранить все необходимые данные (ключи и т. Д.) Где-нибудь в метаданных машины: https://cloud.google.com/compute/docs/metadata?hl=en#project_and_instance_metadata, а затем указав имя проекта / машины (и аутентификация) вы можете получить все необходимые ключи и настроить машину.

Я был бы очень признателен за эту функцию!

@potiuk Какой каталог вы копируете?

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

+1!

+1 Я бы тоже хотел найти решение для этого :-)

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

+1 !!!!!

Кажется, это копия №23, верно?
Почти через год с тех пор, как мы говорили об этой функции, некоторые пытались сделать для нее пиар, но они были закрыты ...
Надеюсь, эта функция будет в следующем (основном) выпуске :)

Это абсолютно необходимо в сценариях непрерывной доставки, когда вы хотите развернуть с помощью этих ключей от Travis или Circle CI. Есть какие-нибудь подсказки относительно ETA?

тоже нужно поставить +1

+1

+1

Есть ли что-нибудь, что вам нужно сделать, кроме копирования папки ~/.docker/machine/machines/<name> и изменения абсолютных путей? Я получаю сообщение об ошибке, связанное с моими сертификатами, и попытка восстановить их также не удалась.

@jbasrai Изменился ли IP-адрес того, к чему вы пытаетесь получить доступ?

Я подал https://github.com/docker/machine/issues/2516, чтобы начать обдумывать шаги в правильном направлении, чтобы сделать это проще.

Это жизненно важная функция, и я хотел бы увидеть ее в ближайшем будущем. На мой взгляд, конфигурация машины должна оставаться уникальной для клиента, а не импортироваться / экспортироваться. Вместо этого (как упоминали другие) docker-machine create run с теми же аргументами должен иметь возможность создавать конфигурацию для машины, даже если она уже существует удаленно, вместо того, чтобы терпеть неудачу, как сейчас. При повторном запуске моей команды create для существующей машины amazonec2 я получаю эту ошибку, сообщающую мне, что хост уже существует:

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.

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

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

+1

+1

Верный. Единственный текущий способ - взять весь каталог, но это не будет работать с некоторыми драйверами (например, VirtualBox, потому что он регистрирует виртуальные машины и сети с UUID, которые не совпадают). В прошлом было обсуждение функции импорта / экспорта (# 23)

@ehazlett, поэтому я использую драйвер aws, могу ли я:

1. сжать облачную машину ~/.docker/machine/machines/staging
2. поделитесь с членами команды, они распаковываются на ~/.docker/machine/machines/
3. у них будет постановочная машина как у меня? docker-machine ls (или им нужно выполнить другую команду)

@leandromoreira Одним из препятствий для этого подхода является то, что в файлах конфигурации докер-машины есть жестко заданные пути, специфичные для хост-машины:

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"
        }

поэтому простое копирование всего каталога не является полным решением

@bhurlow большое спасибо: smile:, есть ли какой-нибудь инструмент, чтобы помочь в этом? или мне нужно вручную отредактировать config.json ? это единственный барьер?

@leandromoreira я сценарий вокруг него , как это , более поздние версии от Докер-машины больше не base64 кодировать ключи в файле конфигурации. В конце концов, любой, кто хочет использовать удаленную докер-машину, должен иметь сертификаты TLS, поэтому я думаю, что требуется обмен между сторонами.

Спасибо @bhurlow

@bcwalrus сделал отличный инструмент, пока мы не получим что-то официальное.

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 выглядит великолепно, чувак, мне удалось успешно экспортировать и импортировать конфигурации.

@muhammadghazali это @bhurlow идеи и усилия: stuck_out_tongue:

+1 Есть обновления относительно официального решения для этого?

В докере версии 1.10.1 я заметил, что файл config.json содержит ссылки на следующее из каталога ~ / 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",

Вам также необходимо скопировать папку ~ / .docker / machine / certs с исходного компьютера, чтобы этот сценарий работал.

Текущее решение для этого выглядит следующим образом (например, если вы хотите создать Docker Machine на AWS на одном компьютере и просматривать журналы или SSH на машине с другого):

1. Создайте новый каталог my-dir и my-dir/machine для машин Docker, которыми вы хотите поделиться, чтобы он не использовал ваши сертификаты по умолчанию.
2. Создайте свой Docker Machine, используя параметр --storage-path my-dir/machine (убедитесь, что вы указали абсолютный путь)
3. Чтобы поделиться Машиной, отредактируйте config.json в my-dir/machine/machines/machine-name и замените абсолютный путь к my-dir/machine на $MACHINE_STORAGE_PATH
4. Загрузите куда-нибудь my-dir , например на Github

Когда кто-то хочет импортировать эту Машину:

1. Клонировать или скачать my-dir
2. Отредактируйте config.json для Машины в my-dir/machine/machines/machine-name и замените $MACHINE_STORAGE_PATH абсолютным путем к my-dir/machine на локальном компьютере.
3. chmod 0600 id_rsa в my-dir/machine/machines/machine-name

Теперь вы можете использовать команды Docker Machine с параметром --storage-path my-dir/machine (убедитесь, что вы указали абсолютный путь).

Возможно, это можно улучшить:

• Docker Machine хранит относительные пути в config.json, поэтому редактировать это не нужно.
• Docker Machine SSH (и связанные команды) автоматически изменяют id_rsa на 0600 (если у них есть разрешение)

Одно быстрое замечание: если вы используете envsubst вы можете программно заменить $ MACHINE_STORAGE_PATH и вам не придется вручную редактировать. Тем не менее, все это неудобно для команд, пытающихся использовать ферму систем докер-машин.

Однако, если люди ищут обходной путь, самое простое, что я нашел, - это:

1. Скопируйте .docker/machine/certs в частное место. Обратите внимание, _не_ помещайте это в репо, так как у него есть секреты, которые дают вам доступ к другим машинам. Для этого мы используем частный магазин.
2. На новом хост-компьютере скопируйте сертификаты в новый .docker/machine/certs
3. Теперь перезапустите созданную вами докер-машину, и вы сможете использовать ее, не изменяя все конфигурации. Это занимает больше времени, но более переносимо, и вам не нужно редактировать все эти файлы конфигурации.

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

1) Создайте каплю в DigitalOcean с помощью docker-machine и драйвера DigitalOcean (с некоторым токеном, который вы получаете из панели управления 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) Перейдите на другой компьютер, получите еще один токен от DigitalOcean и подключитесь к существующему компьютеру с помощью волшебной команды присоединения, например:

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

Какие препятствия на пути к этой работе? Я думаю, что токен доступа DigitalOcean дает достаточно привилегий для подключения к существующему хосту и настройки всей безопасной связи.

А пока я собираюсь попробовать разделить машину на @bhurlow : https://github.com/bhurlow/machine-share

+1 Удар по этому поводу - у кого-нибудь есть обновления по этому поводу?

@brandontamm : Я написал несколько скриптов, чтобы решить эту проблему самостоятельно. Не знаю, решат ли они вашу, но я могу хотя бы попробовать. Посмотрите суть здесь

Краткое содержание: есть две функции - store_machine и load_machine. store_machine хранит всю информацию о машине в безопасном тайнике (зашифрованном в хранилище данных на диске). Вам нужно будет указать пароль. Функция load_machine загружает машину из хранилища данных на диске.

Обратите внимание, что этот код Python предполагает, что у вас установлен sstash (Python Secure Stash). Вы можете установить его, запустив

pip install sstash

+1

Серьезно - что хорошего в Docker-Machine, если вы не можете получить к нему доступ с другого заранее определенного устройства ....

СЛУЧАЙ ИСПОЛЬЗОВАНИЯ - построил докер-машину на работе, но потом понадобится ноутбук для отпуска на случай, если сервер взорвется ...

Да ладно, где администратор Docker может вмешиваться в это ?! Это вариант использования, который может оценить ВСЕ.

@realcr Вы пробовали совместное использование машины ?

Я отказываюсь от использования каких-либо зависимостей :) Копирование папки .docker на обе машины OSX отлично сработало для меня. Мои пути и имена пользователей были одинаковыми на обеих машинах, так что это ключ без ручного редактирования путей.

Брэндон Тамм
отправлено с мобильного телефона

4 ноября 2016 г. в 3:36 Себастьян Буле [email protected] написал:

@realcr Вы пробовали совместное использование машины?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub или отключите чат.

+1

+1

+1

+1

Я написал docker_machinator, чтобы попытаться решить эту проблему.
Это инструмент Python, который позволяет вам сохранять все учетные данные и конфигурацию вашей докер-машины в зашифрованном хранилище, которое вы можете хранить, например, у своего облачного провайдера. Затем вы можете загрузить это с другого хоста и загрузить свои машины обратно из тайника.
Это инструмент Python, поэтому вы должны быть на один pip install от его использования.

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

Ребята, вы должны знать, что общий доступ к

@mxl docker-machine предоставляет подкоманду ssh которая предоставит вам доступ к серверу, поэтому описываемая вами ситуация неизбежна, если у вас есть инструмент, который создает всю конфигурацию в виде импортируемого файла.

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

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

Возможность управлять докер-машиной только с одного хоста - неудобное ограничение.
Я также хотел бы увидеть что-нибудь вроде docker-machine config-from <otherhost> .

Так что +1 от меня тоже.

/ Edit: в настоящее время я решаю проблему, синхронизируя .docker с "главного сервера" со всеми другими серверами, которым нужны те же конфигурации - через cron и rsync. Это, например, необходимо для нескольких ведомых устройств сборки. Не очень хорошее решение.

+1

Вот другой сценарий, который приводит меня сюда.

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

Вопрос в том, как прикрепить экземпляр докер-машины, восстановленный из моментального снимка, запущенного на новом хосте?

Пт, 10 марта 2017 г., в 6:16, exjimsk [email protected] написал:

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

Если сертификаты не изменились, вы сможете просто изменить свой локальный
docker-machine config, чтобы указать ему новый IP-адрес. Вы найдете
файл в ~ / .docker / machine / machines / your-machine-name / config.json.

В качестве альтернативы, если вы никогда не сохраняете данные в контейнерах Docker, вместо этого
перемещения хоста, просто убейте его, создайте новый и запустите тот же
контейнеры на новом хосте.
ᐧ

+1

+1

+1

+1

+1

+1

+1

+1

docker-machine attach , пожалуйста.

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

В моем случае очень рад присоединить существующий хост ${HOST} с

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

Но необходимо скопировать сертификаты ( ca.pem, cert.pem, key.pem ) в DOCKER_CERT_PATH вручную.

Какие планы на это? Записывать полные пути в config.json очень неприятно.

Мой вариант использования: у меня есть репозиторий git с конфигурациями машин в нем (я использую -s чтобы указать на него докер-машину). Секреты хранятся в git encrypt и идея состоит в том, чтобы задания CI могли использовать эти конфигурации для управления машинами, к которым им нужен доступ.

К вашему сведению: # 3212

@lyda Мы используем такой подход с https://github.com/dmstr/docker-roj - но без шифрования, что на самом деле было бы очень хорошей функцией!

Хотя roj всегда работает с одними и теми же путями, поскольку он находится в контейнере, есть и другие решения, например:

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

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

docker-machine активно разрабатывается докером? Я спрашиваю, потому что прошло больше месяца с тех пор, как коммит стал мастером: https://github.com/docker/machine/commit/master

+1

+1

+1

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

Я полагаю, что docker-machine мертв (по крайней мере, для меня: D). Я перешел на kubernetes . Даже собственный kubeadm в версии alfa работает лучше, чем это на самом деле. Могу рекомендовать :)

пожалуйста, поддержите это :(

добавьте «~ / .docker» в папку, которая синхронизирована или может быть символически связана с облачной папкой на обеих машинах. есть пара готовых решений. не слишком сложные ребята, просто проведите небольшое исследование - никогда не было проблем после настройки один раз в течение 30 секунд.

+1

+1

Я не понимаю, как эта функция, а также указание статического IP-адреса - две наиболее востребованные функции в истории проекта docker-machine - остаются нереализованными.

Прошло почти 4 года 😮 Есть ли обновления по этому поводу?

На данный момент во многих статьях / руководствах по Docker все еще предлагается использовать docker-machine как де-факто инструмент для управления хостами. Однако наличие этой проблемы является сильным ограничивающим фактором!

В настоящее время я продолжаю использовать docker-machine и использую подход «copy-certs-dirs» для обмена между нашими локальными компьютерами. Я хотел бы перейти на Kubernetes, но это выглядит слишком для моего проекта.

Как насчет запуска docker-machine create из контейнера докеров? Затем этот контейнер можно было экспортировать, импортировать на другой компьютер, а затем запустить там.

По-прежнему нет привязанности, боже мой