Эта статья является продолжением моих изысканий по Docker. Тема навеяна простым примером из жизни.
Администратору занимающемуся преимущественно Windows был задан вопрос, если у тебя есть контейнер Docker, как ты будешь им управлять. Не задумываясь тот ответил: «поставлю в контейнер SSH и буду к нему подключаться«.
Сегодня я попытаюсь объяснить, почему так делать не нужно.
Собственно, это вполне просто реализовать, подключиться к контейнеру, поставить SSH, повесить его на какой-то свободный порт и подключаться как к виртуальной машине, через порт. При этом, основная машина будет предоставлять свой SSH, на другом порту.
Идея выглядит жизнеспособно, но так делать ни в коем случае нельзя! Контейнеры не должны запускать SSH, если конечно вы не решили загрузить SSH-сервер в контейнер.
Почему же нельзя использовать SSH в контейнерах Docker?
Во-первых, контейнеров может быть много, во-вторых, я уже писал, что запустить Bash в контейнере проще-простого, для этого стоит воспользоваться командой Exex.
В официальных блогах Docker много писали про это. Чтобы понять проблему с которой вы столкнулись, достаточно подумать: «а что я, собственно, хочу сделать?».
Этот вопрос спас меня от многих проблем, надеюсь поможет еще кому-то.
Правильно сформулировав вопрос, мы начнем мыслить в правильном направлении.
Далее, я попытаюсь решить несколько типовых задач не устанавливая SSH- сервер в контейнеры.
Не перегружайте контейнеры
Следуя принципу бритвы Окама мы должны отрезать все лишнее. Речь сейчас не только про SSH. Идея контейнеров так высоко взлетела именно из-за простоты, из-за того, что не нужно 100500 раз конфигурировать сервер. Вы создаете образ, запекаете в него все, что необходимо для работы вашего проекта, ни больше ни меньше. При необходимости, нужно поправить только Docker.file.
При необходимости обновлений безопасности, нам придется обновлять все контейнеры и чем больше мы в них установили, тем сложнее нам предстоит работа. Это противоречит основным принципам простоты Docker: один контейнер реализует один сервис.
Так же мы получим проблемы в больших корпоративных сетях, со сложными политиками доступа. Наши подключения могут просто блокироваться.
Нагромождая контейнер, мы имеем сложную, плохо структурированную реализацию, которая потребует настройки при каждой установке. В таком случае теряется смысл использования контейнеров.
Важно так же понимать, что не получится просто установить SSH. Docker следит только за одним процессом в контейнере. Чтобы все работало как мы запланировали, необходимо будет пользоваться дополнительными инструментами.
В итоге, идея уже не выглядит так привлекательно, а в базовой установке Docker она и вовсе не жизнеспособна.
В Docker все уже есть
В первых версиях действительно было сложно управлять контейнерами. В связи с чем появилось множество статей о том как управлять ими в том числе и при помощи сторонних утилит. Многие из этих статей довольно популярны, но стоит учесть тот факт, что разработчики не стоят на месте. Docker развивается очень быстро и то, что еще год назад мы реализовывали при помощи костылей, сегодня можно делать банальным запуском уже готовых команд.
90% функций управления контейнером может взять на себя сам Docker. На сегодняшний день это серьезная и сложная среда с большим количеством базовых команд и настроек. Так что перед тем как пытаться загружать в контейнер свой софт задумайтесь о том, что скорее всего вы делаете что-то не так.
Вывод: сегодня мы обсудили почему SSH внутри контейнеров это признак плохого понимания устройства Docker. Если вы столкнулись с этой проблемой, то вы не одиноки. Множество людей становясь на путь контейнеров натыкаются на те же мысли. В следующих статьях я опишу создание локальной среды для разработки проектов на PHP.
