Machine: Машины для экспорта / импорта

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

Создавая машину, вы можете использовать ее и управлять ею только с одного компьютера. Вы можете захотеть:

1) сделайте резервную копию ваших хостов
2) перенести их на другой компьютер
3) поделитесь ими с членом команды

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

Что именно будет содержать сохраненный файл? т.е. Будет ли он содержать токен для подключения к демону?

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

@bfirsh @waitingkuo Кажется, это действительно полезная функция, которую мы бы использовали в Rancher (мы хотели бы использовать машину на стороне сервера).

По любой причине, кажется, что реализация (# 29) остановилась. Что я могу сделать, чтобы помочь?

+1 было бы круто

+1

+1

+1

У нас есть инструмент, который мы используем сами, чтобы упростить экспорт докер-машин. Он в основном экспортирует все ssh-ключи сертификатов. Обратная связь приветствуется!

https://github.com/blackbeardapp/docker-machine-export

может быть излишним, но что-то вроде реестра докер-машины было бы здорово!

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

@kevinsimper как их обратно импортировать?

Включает ли эта проблема идея совместного использования кластеров роя между разработчиками?

@saada Я думаю, что это касается только совместного использования учетных данных , а не конфигурации кластера.
Было бы здорово иметь эту способность в машине.
В настоящее время я знаю только https://github.com/efrecon/machinery и https://github.com/nathanleclaire/moby

+1

Я ищу возможность совместно использовать машину между пользователями на одних и тех же хостах.
И есть ли обходной путь для этого? Я сейчас копирую всю папку ~/.docker/machine/

+1

+1

+1

+1

+1

+1

+1

+1

+1

Я думаю, что лучший способ показать свое намерение - это нажать на Subscribe (справа Уведомления ).

Я написал сценарий импорта / экспорта, который вы можете использовать до тех пор, пока эта функция не будет реализована изначально. Надеюсь это поможет :)

https://gist.github.com/schickling/2c48da462a7def0a577e

@schickling, может быть, что-то нужно добавить в каталог "contrib" в этом репозитории? https://github.com/docker/machine/tree/master/contrib/completion

К сожалению, у меня нет на это времени, но, пожалуйста, не стесняйтесь втягивать его туда!

+1

+1

+1

Я написал еще одну небольшую утилиту для экспорта / импорта докеров. Мы используем это для развертывания CI. https://www.npmjs.com/package/@mumbacloud/dmport

Спасибо kevinsimper за https://github.com/blackbeardapp/docker-machine-export. Я использовал вашу идею для экспорта в формате JSON, что делает его довольно переносимым для сред CI.

Я также начал работать над некоторым сценарием экспорта / импорта, чего я действительно не понимаю, почему есть некоторые дублированные файлы в certs и конкретной папке машины machines/<myMachine> . Также после настройки путей в config.json для некоторых пользовательских путей за пределами .docker/machine/machines... я заметил, что докер по-прежнему ожидает, что некоторые сертификаты / pems / ключи будут расположены в этой папке

Может ли кто-нибудь порекомендовать некоторую документацию о том, что где на самом деле должно быть?

Похоже, что разработчики Node.js активно этим пользуются (и переписывают собственные решения). Это я нашел через Twitter

https://www.npmjs.com/package/machine-share

Совместное использование конфигурации Docker Machine:

npm install -g machine-share
machine-export <machine-name>
machine-import <machine-name>.zip

В том же пакете узлов (как упоминалось @StefanScherer ) также есть сценарии оболочки, если у вас не установлен Node.

https://github.com/bhurlow/machine-share/blob/master/export.sh
https://github.com/bhurlow/machine-share/blob/master/import.sh

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

проблема, с которой я столкнулся с текущими сценариями экспорта / импорта, заключается в том, что они будут перезаписывать существующие файлы в ~/.docker/machine/certs , не так ли?

Я могу говорить только о dmport, он перезапишет файлы, если они существуют.

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

Я планирую в ближайшее время очистить dmport, я могу добавить флаг, который предотвратит
перезапись существующих файлов, если это поможет
1 июня 2016 г. в 1:54 утра "Макс Брухманн" [email protected] написал:

проблема с текущими сценариями экспорта / импорта заключается в том, что они
перезапишет существующие файлы в ~ / .docker / machine / certs, не так ли?

-
Вы получили это, потому что оставили комментарий.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/docker/machine/issues/23#issuecomment -222932695 или отключить звук
нить
https://github.com/notifications/unsubscribe/ADIV-3T7FEa9CJvn_UdTb9AeQfwI3lkCks5qHUjegaJpZM4DFGT5
.

+1

Для этой задачи мы используем докер-контейнер - что еще 😄

Идея также состоит в том, чтобы иметь одинаковую среду (например, пути конфигурации сертификатов) для всех пользователей, смонтированных как хост-том. Вы можете использовать docker-machine , docker-compose и docker в контейнерах, созданных из roj. И вы можете передать папку с данными в виде zip-архива по электронной почте или поместить ее в частное репозиторий git.

+1

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

https://www.npmjs.com/package/machine-share , похоже, не уважает мой MACHINE_STORAGE_PATH. Сценарий schickling создает резервную копию пары больших двоичных файлов (например, boot2docker.iso). https://www.npmjs.com/package/@mumbacloud/dmport выдал пару ошибок.

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

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

@jcrben Привет, а как насчет того, чтобы опубликовать полную версию вопроса о MACHINE_STORAGE_PATH?

Я недавно просмотрел работы Бхурлоу, и мне любопытно посмотреть, не сломается ли что-нибудь

@jcrben Вы тоже пробовали https://github.com/dmstr/docker-roj? ... Мне просто любопытно.

Люди, из любви ко всему, пожалуйста, OP, а не как отдельный комментарий. Спам «+1» отвлекает от разговора.

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

@lnshi Я думаю, что проблема с импортом существующего док-сервера с docker-machine create -d generic ... заключается в том, что он воссоздает сертификаты и перезапускает Docker, поэтому не подходит для сценария производства / совместной работы.

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

@ntwrkguru тем не менее, это делает проблему актуальной и живой. Уведомлений об эмодзи нет.

Этому вопросу почти 4 года, я сомневаюсь, что еще несколько комментариев +1 внезапно сделают его приоритетным.

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

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

То же: https://github.com/docker/machine/issues/1328 ?

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

Это потому, что docker-machine никогда не создавалась как инструмент команды. Для человека это означает, что легко создавать виртуальные машины, которые автоматически устанавливают докеры и настраивают сертификаты TLS dockerd для удаленного управления клиентом.

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

@BretFisher и какие это были бы инструменты? Не то чтобы я хотел использовать его для команд, просто с 3 разных рабочих станций ...

Одним из больших преимуществ docker-machine является то, что он устанавливает TLS на движке докера для удаленного управления клиентом.

Сегодня был выпущен Docker Engine 18.09, а вместе с ним и замечательная новая функция, которая позволяет удаленное управление клиентом с помощью SSH-туннелирования (своего рода) и является гораздо лучшим подходом IMO для тех из нас, кому не нужен полный движок докеров RBAC. Тем, кто использует docker-machine просто для упрощения удаленного управления, я рекомендую проверить это в 18.09. И ваш док-сервер, и клиент должны быть на 18.09, и пока вы можете подключиться по SSH, вы можете использовать cli удаленно.

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

Я понимаю, о чем вы говорите @BretFisher , но было бы неплохо иметь его в докер-машине, поскольку он все равно отслеживает пульты. Если я собираюсь управлять ими через SSH, то я, скорее всего, даже не буду использовать docker-machine для их развертывания, а вместо этого буду использовать Ansible. Docker-machine - еще один инструмент, который может быть отличным, но считается посредственным из-за отсутствия разработки.

Параметры @adilinden для одного пользователя включают:

1. синхронизировать ~/.docker/machine/machines между этими машинами в частном и / или зашифрованном репозитории git. Вам также может понадобиться ~/.docker/machine/certs , я не уверен. Он должен быть достаточно безопасным, поскольку хранит частные сертификаты.

2. Выберите AMI, Droplet и т. Д., На которых уже установлен докер, и разверните их. Затем используйте новую функцию SSH 18.09 для удаленного управления движком докера.

3. Попробуйте один из многих инструментов, которые экспортируют / импортируют каталоги машинных данных, которые я перечислил выше.

@BretFisher Мне очень нравится №2, это лучший вариант для моего сценария, поскольку все ручки и кнопки для этого уже есть. Переключение хостов также выглядит тривиальным, поскольку это просто установка одной переменной среды.

Теперь просто выясним, как установить Docker для Mac на 18.09 вместо 18.06.1-ce-mac73 (26764).

Докер-машина @ntwrkguru отлично подходит для одноразовых машин или личных настроек или для кого-то, кому, возможно, нужно не более 10 серверов максимум, но если вы когда-либо пытались управлять с ним 10+ серверами, вы сразу увидите его ограничения. Я бы не сказал, что это из-за отсутствия разработки, скорее, это «не в рамках» первоначальных целей инструмента.

В этом случае в SSH вы бы не использовали ansible, я говорю, что после того, как вы развернете любой докер-сервер (доступный или другой), который работает 18.09+, если у вас есть разрешение SSH на этот сервер, теперь можно сделать что-то вроде:

docker -H ssh://[email protected] run -p 80:80 nginx
или же
DOCKER_HOST=ssh://[email protected] docker system prune

Для удаленного управления этим движком без какой-либо специальной конфигурации или настройки. Возможность экспортировать envvar и затем запускать кучу команд для этого движка (не помещая их в анзибл и т. Д.) Очень удобна.

@adilinden выпуск Linux только что вышел сегодня, поэтому вам нужно дать командам несколько дней или недель, чтобы развернуть все последующие продукты, которые его используют :). Если вы хотите его сегодня , используйте выпуск Edge, который имеет бета-версию 18.09 и отлично работает для меня на Mac.

По общему признанию, я уже несколько лет не возился с докер-машиной. У меня осталось 4 сервера с простым движком Docker.

Итак, в чем преимущество между docker -H ssh://[email protected] run -p 80:80 nginx и ssh://[email protected] docker run -p 80:80 nginx ?

[править] Отсутствие аргументов; Мне интересно, есть ли явная выгода.

@ntwrkguru Я могу построить из файла Docker на своей рабочей станции с помощью команды docker -H ssh://[email protected] . . Тогда как то же самое не удается (как и ожидалось) с использованием ssh -luser 10.10.10.10 docker build .

Для информации, также можно использовать ssh для переадресации сокетов. Согласно https://medium.com/@dperny/forwarding -the-docker-socket-over-ssh-e6567cfab160, но с небольшими изменениями.

За один запуск терминальной сессии

ssh -nNT -L $(pwd)/docker.sock:/var/run/docker.sock -l user 10.10.10.10

В другом пробеге

docker -H "unix:///$(pwd)/docker.sock" run -p 80:80 nginx

или же

export DOCKER_HOST="unix:///$(pwd)/docker.sock"
docker run -p 80:80 nginx

У меня была такая же проблема, и я создал сценарии оболочки для резервного копирования и восстановления:
https://github.com/usr42/docker-machine-backup

Копируются только действительно необходимые данные. Например, в резервной копии нет файлов iso.