×
Фото Как войти в запущенный Docker-контейнер и почему так делать не надо

Как войти в запущенный Docker-контейнер и почему так делать не надо

Иногда интересно: что же происходит внутри Docker-контейнера

Если коротко отвечать на первую часть вопроса, хватит одной команды 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.

Таким образом, на не нужно ходить в контейнер, а данные не потеряются при его дропе / перезапуске / выходе из строя хостовой машины. Вместо этого мы получаем централизованную систему для обработки служебных данных. А учитывая, что один запрос может ходить между несколькими сервисами, так ещё и проще будет разобраться в судьбе этого запроса, чем лезть на десяток машин.

Будь первым – оставь комментарий!

Фото Как узнать, кто подключился по SSH
Предыдущая запись:
Как узнать, кто подключился по SSH
Фото Скрытая угроза. Git и зловреды уже на серверах
Следующая запись:
Скрытая угроза. Git и зловреды уже на серверах