Docker context через SSH: удалённый Docker host

Что важно понять до начала

Docker contexts хранят endpoint и метаданные подключения. SSH-доступ должен работать независимо от Docker CLI и пользователь на удалённой машине должен иметь право обращаться к Docker daemon. Активный context можно просмотреть командой `docker context show` и списком contexts. Переменные окружения и явные CLI-параметры могут влиять на выбранный endpoint, поэтому перед удалением данных проверка обязательна.

Совет: Практический ориентир: Нет, при SSH endpoint CLI использует SSH-транспорт; специально публиковать незашифрованный daemon TCP ради этого не требуется.

Пошаговый порядок действий

1. 1. Сначала проверьте обычный `ssh user@host` и права пользователя на удалённый Docker.
2. 2. Создайте именованный context с SSH endpoint.
3. 3. Переключитесь на него и выполните безопасную проверку `docker info`/`docker ps`.
4. 4. Перед `prune`, `rm` и `down` всегда выполните `docker context show`.
5. 5. Для возврата переключитесь на локальный context и ещё раз проверьте имя активного окружения.

Важно: Критично для этой задачи: Не используйте один и тот же незаметный shell prompt для production и local contexts: ошибка выбора endpoint может удалить реальные контейнеры и volumes.

Ошибки и пограничные случаи

Не используйте один и тот же незаметный shell prompt для production и local contexts: ошибка выбора endpoint может удалить реальные контейнеры и volumes. Для CI лучше задавать context или endpoint явно внутри job, а не полагаться на состояние интерактивного профиля разработчика.

Предупреждение: Пограничный случай: Перед опасной командой выводите `docker context show`, используйте ясные имена contexts и явный `--context` в автоматизации.

Проверка перед завершением

• Сначала проверьте обычный `ssh user@host` и права пользователя на удалённый Docker.
• Переключитесь на него и выполните безопасную проверку `docker info`/`docker ps`.
• Для возврата переключитесь на локальный context и ещё раз проверьте имя активного окружения.
• Проверено отдельно: Нет, при SSH endpoint CLI использует SSH-транспорт; специально публиковать незашифрованный daemon TCP ради этого не требуется.

Практический сценарий и контроль результата

Перед любой destructive‑командой на удалённом daemon делайте явную проверку активного context. Это особенно важно для prune, rm и compose down: синтаксис команды выглядит так же, а цель может быть другой машиной. SSH‑context не требует открывать незащищённый Docker TCP‑порт, но обычный SSH и права пользователя на daemon должны работать независимо. Если context не подключается, сначала проверьте ssh user@host и локальный docker на удалённой машине, затем возвращайтесь к настройке CLI.

Дополнительные нюансы и проверка

Для ежедневной работы удобно оставлять локальный context активным по умолчанию, а удалённый выбирать явно через --context в опасных командах. Тогда случайное переключение среды реже приводит к удалению не тех контейнеров. Перед началом работы запишите имя context в shell prompt или хотя бы проверяйте docker context show. Если SSH‑ключ защищён паролем, убедитесь, что ваш агент доступен CLI; иначе обычный интерактивный ssh может работать, а автоматизированная команда Docker — нет.

Что учитывать

Docker contexts хранят endpoint и метаданные подключения. SSH-доступ должен работать независимо от Docker CLI и пользователь на удалённой машине должен иметь право обращаться к Docker daemon. Активный context можно просмотреть командой `docker context show` и списком contexts. Переменные окружения и явные CLI-параметры могут влиять на выбранный endpoint, поэтому перед удалением данных проверка обязательна.

Источники и проверка

Фактическая часть сверена по первичным источникам (в т.ч. Docker contexts). Пример и формулировки — редакция N1RO на 2026-09-22.

• Docker contexts