Я бегу Ubuntu docker-контейнер на Linux-машине. У меня возникают большие трудности каждый раз, когда я пытаюсь скопировать файл в / из контейнера докеров с моей локальной машины. Мне нужно скопировать файл на хост-машину, а затем запустить docker cp передать это.
Есть ли способы получить доступ к контейнеру докера прямо с моего локального компьютера под управлением Windows?
Поскольку у контейнера есть только IP-адрес local-to-host, мне приходит в голову один вариант - сказать хосту, что он должен перенаправить все SSH-соединения на его конкретный порт в контейнер. Или любое другое решение, которое может у вас быть.
Одной из целей разработки контейнеров является изоляция, поэтому отчасти ожидается сложность доступа к файлам внутри контейнеров.
Есть (как минимум) три варианта. Изменить: мысль о четвертом :)
Может показаться заманчивым запустить sshd процесс внутри контейнера, чтобы иметь к нему прямой доступ через любой SSH-клиент. Это, однако, противоречит идее запуска «одного процесса» / «одной службы» для каждого контейнера (если только весь смысл контейнера не является демоном ssh). То же самое касается любой другой службы обмена файлами, работающей непосредственно внутри контейнера (например, ftpd и т. Д.).
Жизнеспособность этого варианта зависит от того, можно ли изменить контейнер для включения демона для ваших целей и нужно ли это. Я бы сказал, что в среде, где требуется изоляция, обеспечиваемая контейнерами, использование дополнительных сервисов внутри контейнеров контрпродуктивно. Однако если это больше похоже на «среду разработки», то запуск дополнительного демона внутри контейнера может быть полезным. Поскольку контейнеры обеспечивают очень ограниченный надзор за процессами, рассмотрите возможность использования подходящего диспетчера служб (systemd тяжелый, но все это делает, существуют менее полные альтернативы :)) внутри контейнера в случае запуска нескольких служб.
Итак, если у вас есть способ подключиться к части Linux, Docker предоставляет интегрированный механизм для сопоставления путей от хоста (Linux) внутри контейнера. Это делается путем указания -v флаг при создании контейнера следующим образом:
docker run --rm -it -v /home/linux-fan/wd:/media/wd debian:10 /bin/bash
Здесь мой локальный каталог /home/linux-fan/wd предоставляется в рамках /media/wd внутри контейнера. Обратите внимание, что docker не делает ничего особенного для сопоставления идентификаторов пользователей внутри и вне контейнера (может вызвать ошибки отказа в разрешении, если идентификаторы не выровнены должным образом).
Дополнительно / необязательно, чтобы избежать подключения через SSH, может быть интересно предоставить путь от хоста Linux как общий ресурс Windows с помощью samba s.t. все SSH для доступа к файлам можно исключить.
Хотя у меня нет опыта работы с ними, Docker не только позволяет предоставлять каталоги в виде томов, но также имеет возможность добавления внешнего хранилища (см. https://docs.docker.com/engine/extend/plugins_volume/). Такое хранилище снова может быть доступно со стороны Windows.
Docker сам по себе является службой и может быть доступен для внешней сети. Для этого вам необходимо настроить соответствующие сертификаты TLS и включить сетевой доступ к демону Docker на хосте Linux. Затем должна быть возможность запустить клиент Windows Docker (который подключается к демону Docker Linux через TLS) и выдать подходящий docker cp команды (как и все другие docker команд) напрямую с вашего локального компьютера.
Что-то делать с работающим контейнером, безусловно, значительно сокращает возможности.
Решение на основе SSHD-в-контейнере может быть трудным, если нет открытого порта, который он может прослушивать. Если это так, попробуйте обойти это с помощью дополнительных sshd контейнер, связанный с запущенным и выполняющий некоторую пересылку, может работать, но это хакерский.
Для удаленного доступа к Docker не требуется повторное создание контейнера, но требуется изменение конфигурации Docker и, следовательно, перезапуск (без повторного создания) всех работающих контейнеров, так как демон Docker необходимо перезапустить.
Наконец, если ничего из этого невозможно, решение на основе pull, работающее как вновь созданный процесс внутри существующего контейнера, может быть еще более хакерским, но доступным как своего рода «последнее средство». Я сомневаюсь, однако, что это удобнее существующих ssh + docker cp рабочий процесс. Если вы хотите оптимизировать существующее решение: WinSCP предлагает функцию для автоматической отправки измененных файлов в Linux (часть перед вызовом docker cp таким образом, возможно, можно упростить).