Тема вызвала сумасшедший интерес у сообщества!
Теперь, если позволите, я выскажу собственное мнение по этому docker.
Docker сильно распиареный и, не менее сильно, переоцененный продукт!
Я читал восторженную статью на хабре https://habrahabr.ru/post/277699/, в которой предрекается совершенно новый подход к построению серверов, когда хост система - голый Linux, разьве что с ssh, а все остальные сервисы крутятся в контейнерах и переносятся за пару минут на новый/новые сервера. Отлично, правда?
Только возникает вопрос: тот хабаровчанин с docker работал?
Давайте вернёмся к базовой идеологии docker. Есть image, т.е. готовый образ с урезанной системой и сервисом, ради которого, он и затевался. Image read only! Reand & write он становится лишь, когда запущен и "обернут" в контейнер. Даже не так! Image, всегда read only, read & write лишь слои контейнера. При перезапуска все изменения, внесенные в слоях теряются. Отлично, правда?
Давайте рассмотрим банальный образ с Apache2 + PHP. Т.к. после перезапуска контейнера все изменения исчезают нужно пробрасывать ему кучу каталогов от хоста.
Давайте, примерно, прикинем, что ему нужно пробросить, что бы работал сайт с кучей виртуальных хостов, скриптами, аплоадом и прочим... Тут перечислять замучаешься. Нужны ВСЕ настройки апача, для быстрой правки. Потому, смело пробрасываем /etc/apache2. Целиком! Так же нужно пробросить место жительства сайтов (пусть будет /var/www). Теперь вспоминаем, что порой нужен аплоад файлов пользователей, и пробрасываем ещё каталог, куда PHP заливает принятые файлы, например /Temp.
Для одной только банальнейшей связки apache2 + php, нам нужно прокидывать 3!! Каталога!
Теперь вспоминаем, что сайты, обычно, ещё работают с БД...
Помните о read only? Значит, тот же MySQL должен хранить свои БД, опять же на хостовой системе. В противном случае, после перезапуска, БД окажется в девственном состоянии.
Возникает вопрос: нахрена все эти мучения? Для пущей безопасности? Так и так всае нормально работает! Для быстрого развертывания она новом сервере? Сомнительная скорость. Новый сервис устанавливается довольно быстро. Основные затяжки во времени - перенос ДАННЫХ! Ну и в дополнение придётся создавать монструозные скрипты для запуска каждого контейнера.
В чем скорость и лёгкость?
Ещё, для создания нового образа, нужно отлично знать, как устанавливаемый сервис работает, что требует, какие изменения нужно внести в конфиги. Т.е., перед созданием образа, нужно установить сервис на тестовой машине, вылизать конфиги, предусмотреть все нюансы и только потом браться за создание образа. В противном случае, у вас ни чего не получится.
Я собирал на удаленном сервере банальнейший образ apache2 + php7.0. Собирал для понимания, как и что нужно делать. В качестве базого, системного, image я выбрал Debian. Опущу мытарства с dockerfile. Это, больше от незнания. Остановлюсь лишь на времени сборки образа... Более 10 минут! Более 10 минут обновлялись репозитарии, и устанавливались пакеты.
В случае любой ошибки в dockerfile приходится пересобирать образ и чистить весь мусор.
Для создания рабочего образа мне пришлось ожидать, суммарно, более часа.
Да, сервер не поражает мощью. Он старенький, хоть и брендовый. Интернет всего 10 МБ. Я пользовался удаленными репозитариями.
А скорость и лёгкость, все таки есть! Очень просто скачать нужный image с hub.docker.com. Скачать и запустить, поражаясь, как все просто. А после запуска начинать мучительно думать, что и как нужно хранить на хостовой системе, разбираясь с каталогами и параметрами окружения!
Посмотрите dockerfile официального образа mysql. Посмотрите и ужаснитесь. А потом бегло пробегитесь по инструкции подключения... Вот где волосы зашевелятся!
Ну должна же быть хоть какая-то фишка в docker! Вот так сходу, я могу назвать лишь пару: пара апачей с разными версиями php. Ещё, возможно, запихнуть в образ bind9 с уже прописанными DNS зонами нескольких сайтов.. Но в этом есть смысл, если не придётся часто что-то менять. А если придётся? А вот тогда городить огороды с пробросами каталогов и параметрами запуска. Или плюнуть на docker.
Последнее мне кажется наиболее предпочтительным.
За виртуализацией, даже не будущее, а самое настоящее! Вот только не за такой.
Контейнер должен быть инкапсулированным! Он должен содержать приложения и данные! И не по одному приложению, а по комплекту, который отвечает за некий функционал.
Например я поднял полновесную виртуальную машину на kvm и туда засунул почтовый сервер. А это тот ещё зверинец: postfix, dovecot, postgresql, spamassasin, greylist и ещё по мелочи.
В моём подходе есть слабое звено. Оно именно, в полноценной виртуальной машине. Нет в ней особого смысла. Куда экономнее была бы паравиртуализация.
PS Я совсем забыл упомянуть о такой мелочи, как логи... Помните о read only? Значит хранить в контейнере их бессмысленно. Есть какой-то способ собирать логи. Вроде, даже, не основанный на пробросе каталога. Не разбирался и нет желания. Скорее всего, вопрос с docker, для себя закрыл.
Может, конечно, кто-то укажет на мои промахи и не правильное понимание?
Не ставлю пока на теме "Решено". |
Это как? 