Команда docker exec служит для выполнения команд внутри запущенных Docker-контейнеров.
С помощь данной команды существует возможность входа в уже запущенный Docker-контейнер и старта bash-сессии.
В этом посте я покажу как войти в Docker-контейнер и запустить в нем интерактивную оболочку bash .
Дельный Совет: Копирование файлов и папок между хостом и Docker-контейнерами! Читать Далее →
Как Войти В Docker-Контейнер
Чтобы узнать имя или ID контейнера, выполните команду docker ps :
Войдите в Docker-контейнер по имени или ID контейнера и запустите интерактивную оболочку bash :
Если внутри контейнера не удастся найти оболочку bash , вы увидите что-то вроде следующего сообщения:
oci runtime error: exec failed: container_linux.go:265: starting container process caused «exec: »bash»: executable file not found in $PATH»
В этом случае вы можете войти в Docker-контейнер и затупить простую оболочку sh :
Для входа в Docker-контейнер используются следующе опции:
Задача стоит так:
1)запустить проект с помощью Docker
2)потом с ним работать
С первой частью всё понятно — нашел нужный контейнер (https://registry.hub.docker.com/u/audreyt/ethercalc/), подтянул его и запустил на хостинге (использовал Digitalocean).
Собственно — а что дальше? Как теперь работать с проектом? Все файлы с исходниками я так понял находятся внутри этого докера и мне недоступны. У меня такое чувство, что я неправильно понял саму концепцию докера. До этого момента я считал его чем-то вроде виртуалки. С ним вообще работать можно (я имею ввиду править код), или он только для запуска проекта?
- Вопрос задан более трёх лет назад
- 16830 просмотров
это LXС, он нужен для изоляции окружения, необходимого приложению для работы. То есть это такой быстрый способ развернуть приложение не парясь о зависимостях.
Залесть внутрь конечно можно, но проще сделать так:
https://github.com/audreyt/ethercalc
там есть Dockerfile по которому строится и провиженится контейнер.
Вообще фишка докера в том, что это по сути механизм версионизации контейнеров. То есть мы берем один снапшот, изменяем его и сохраняем. Как git для окружения.
Залезать можно по ssh и можно маунтить директории.
Иногда интересно: что же происходит внутри Docker-контейнера
Если коротко отвечать на первую часть вопроса, хватит одной команды docker:
– так мы запустим в интерактивном режиме команду /bin/sh (shell, командная строка) внутри уже запущенного контейнера.
- -i – интерактивный режим, не закрываем STDIN при старте.
- -t – запуск псевдо-терменала.
Опять же, узнать имя контейнера можно с помощью
– ключ -a покажет нам все контейнеры, в том числе погашенные. В выключенные вы, естественно, не зайдёте. И это первая причина не лезть своими шаловливыми ручками в контейнер. Нет, правда, что вы там хотите посмотреть?
Логи вы можете увидеть через
А если вы их там не видите – а вы вообще правильно используете Docker?
О вреде старых привычек
Часто вижу «оригинальные» подходы а ля «запущу ка я supervisord как entry point, а в нём подниму все остальные процессы». Спорить не буду – такой финт ушами пройдёт, но он возникает в основном от того, что лень разбираться с Docker, что повлечёт весьма странное поведение системы.
Используйте стандартные средства, не скупитесь на контейнеры: один контейнер – один небольшой простой процесс.
И если вам нужно перезапускать упавшие сервисы (некоторые пеняют на это) – используйте политики перезапуска Docker.
О шаловливых ручонках
Лезть в Docker-контейнер вредно потому, что вы решите (если решите) проблему для одного конкретного контейнера, который при следующем перезапуске будет перераскатан из образа. Стоит относиться к нему как к процессу без состояния – в любой момент могут быть потеряны все изменения, данные.
Поэтому и ковыряться в контейнере может иметь смысл, если вы разрабатываете в сервис в контейнере, но вносите все фиксы именно в образ.
Используйте внешние специализированные средства
Но что же делать, если вам таки надо иногда смотреть на нагрузку, читать логи и т.д.? Всё это стоит автоматизировать и упаковать в ваши сервисы, которые крутятся в Docker-контейнерах.
К примеру, логи можно собирать через filebeat, метрики через prometheus, а про ошибки узнавать не от пользователей, а через sentry.
Таким образом, на не нужно ходить в контейнер, а данные не потеряются при его дропе / перезапуске / выходе из строя хостовой машины. Вместо этого мы получаем централизованную систему для обработки служебных данных. А учитывая, что один запрос может ходить между несколькими сервисами, так ещё и проще будет разобраться в судьбе этого запроса, чем лезть на десяток машин.