Если коротко отвечать на первую часть вопроса, хватит одной команды docker:
docker exec -ti {{ container name }} /bin/sh– так мы запустим в интерактивном режиме команду /bin/sh (shell, командная строка)
внутри уже запущенного контейнера.
-i– интерактивный режим, не закрываем STDIN при старте.-t– запуск псевдо-терменала.
Опять же, узнать имя контейнера можно с помощью
docker ps -a– ключ -a покажет нам все контейнеры, в том числе погашенные. В выключенные вы,
естественно, не зайдёте. И это первая причина не лезть своими шаловливыми ручками
в контейнер. Нет, правда, что вы там хотите посмотреть?
Логи вы можете увидеть через
docker logs {{ container name }}А если вы их там не видите – а вы вообще правильно используете Docker?
О вреде старых привычек
Часто вижу "оригинальные" подходы а ля "запущу ка я supervisord как entry point, а в нём подниму все остальные процессы". Спорить не буду – такой финт ушами пройдёт, но он возникает в основном от того, что лень разбираться с Docker, что повлечёт весьма странное поведение системы.
Используйте стандартные средства, не скупитесь на контейнеры: один контейнер – один небольшой простой процесс.
И если вам нужно перезапускать упавшие сервисы (некоторые пеняют на это) – используйте политики перезапуска Docker.
О шаловливых ручонках
Лезть в Docker-контейнер вредно потому, что вы решите (если решите) проблему для одного конкретного контейнера, который при следующем перезапуске будет перераскатан из образа. Стоит относиться к нему как к процессу без состояния – в любой момент могут быть потеряны все изменения, данные.
Поэтому и ковыряться в контейнере может иметь смысл, если вы разрабатываете в сервис в контейнере, но вносите все фиксы именно в образ.
Используйте внешние специализированные средства
Но что же делать, если вам таки надо иногда смотреть на нагрузку, читать логи и т.д.? Всё это стоит автоматизировать и упаковать в ваши сервисы, которые крутятся в Docker-контейнерах.
К примеру, логи можно собирать через filebeat, метрики через prometheus, а про ошибки узнавать не от пользователей, а через sentry.
Таким образом, на не нужно ходить в контейнер, а данные не потеряются при его дропе / перезапуске / выходе из строя хостовой машины. Вместо этого мы получаем централизованную систему для обработки служебных данных. А учитывая, что один запрос может ходить между несколькими сервисами, так ещё и проще будет разобраться в судьбе этого запроса, чем лезть на десяток машин.