Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.231.146.172] |
|
Сообщ.
#1
,
|
|
|
Здравствуйте, Господа!
Совсем недавно полез разбираться с Docker. Штука отличная! Вот только полного понимания у меня нет. Не могу окончательно понять что есть image, а что container. Базовая система (Ubuntu, Debian, Alpine, ...) это image. Является read only... Если я её запускаю голой, то она как бы упаковывается в контейнер, который уже rw. Я могу доставлять пакеты, творить там невесть что, но все изменения будут лишь до перезапуска этого контейнера? Правильно? Контейнер получается, когда image начинает выполнение, он как бы обертывается в контейнер? Так же, например я создают свой image (?). Например, рисую dcokerfile, в котором к системе добавляю Apache+PHP. Я понимаю, что можно скачать готовый image, но сейчас это делаю самостоятельно. После недолгих мытарств, PHP7.0, я получил image, который даже работает. Эврика! Но, допустим, я изначально поставил apache2, php7.0, но мне понадобилось добавить ещё php7.0-mysql. И тут я не совсем понимаю, как сделать изящнее. Конечно, я могу пересобрать свой образ, добавив к нему нужные модули php. Так же, наверное, я могу создать новый image, базирующийся на моём предыдущем образе. Я пока правильно излагаю? А теперь, вдруг, мне понадобилось поковырять php.ini. И как подходить к этой проблеме? Php.ini, благодаря нашим разрабам, редактировать приходится время от времени. Каждый раз пересобирать image? Можно, конечно, пробрасывать нужный файл из хост-системы, но тут слишком много всего придётся пробрасывать. Лучше, что бы тот же php.ini хранился в image. И, вообще, я пока не шибко разобрался как в dockerfile редактировать конфиги. Например, мне нужно поменять некий параметр в php.ini. И как это сделать? Более менее понятно, как добавить запись echo "parametr=code" >> php.ini Теперь, хочу прояснить, по правильной архитектуре. Мне нужно ещё добавить nginx... Вот тут я не совсем понимаю. Правильнее создавать отдельный image для nginx? Если я правильно понял, то запихивать его в image с apache&php не комильфо. Почему? Ну и, разумеется, nginx + apache&php, не самая сложная проблема. А как быть если я захотел засунуть в docker полноценный почтовый сервер (postfix, dovecot, mysql, spamassasin, etc...)? Это получается, что каждый модуль почтового сервера придётся запихнуть в отдельный image? А как тогда наладить межконтейнерное взаимодействие? Куча папок, пробрасываемых сразу в несколько контейнеров? И, допустим, я увязал все модули почтового сервера. Они даже работают и как-то взаимодействуют друг с другом. Как мне теперь весь этот зоопарк перетащить на другой сервер? Можно, конечно, на целевой сервер передать кучу dockerfile и там их уже "компилять", но это честь левой ногой за правым ухом. Как мне свой, собранный "зоопарк" записать на флешку? Как потом, правильно с флешки передать на целевой сервер? Я понимаю, что мои вопросы многим покажутся наивными и глупыми. Но я пока не нашёл на них внятного ответа в интернет. Вот для понимания я и спрашиваю у знатоков. Заранее благодарен! |
Сообщ.
#2
,
|
|
|
Ещё набрал на схожее с docker решение - LXE. Система паравиртуализации. Нечто среднее между OpenVZ и docker. Гостевые "системы" базируются на ядре хостовой машины.
Кстати, не понял, почему контейнеры docker базируются на image системы, отличной, или схожей с хвостовой. Для чего этот огород? Почему не хостовое ядро? Пока c LXE не разбирался, только немного почитал о ней. Как я понял, у LXE подход ближе к виртуальным машинам. В контейнере размещается весь зоопарк одновременно, как и на TRUE виртуальном хосте kvm/qemu. В чем выигрышь docker? Почему его аж в венды портировали? |
Сообщ.
#3
,
|
|
|
Такс... Для того что бы в image докера закинуть файл из host системы, в dockerfile используется директива ADD.
ADD resolv.conf /etc/ Из host системы, текущего каталога, resolv.conf копируется в создаваемый image /etc/ Таким образом можно закидывать сильно правленые конфиги в image. Можно использовать следующий вариант: 1. docker images Показывает все image в системе Нам нужен ID препарируемого image, допустим 6c364d10bf5b docker cp 6c364d10bf5b:/etc/resolv.conf . мы скопировали resolv.conf из image в хост систему, текущий каталог. Разумеется, resolv.conf не шибко нужен. Его я привел для примера. Издеваемся вдосталь над нужным конфигом, потом включаем его пересылку dockerfile, как сказано выше. Вообще-то docker cp работает в обе стороны и правленый конфиг можно закинуть в готовый образ, но это считается не кошерным. Потому делаем все по феншую. Добавляем в dockerfile ADD resolv.conf /etc/ и пересобираем образ. |
Сообщ.
#4
,
|
|
|
Тема вызвала сумасшедший интерес у сообщества!
Теперь, если позволите, я выскажу собственное мнение по этому 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, для себя закрыл. Может, конечно, кто-то укажет на мои промахи и не правильное понимание? Не ставлю пока на теме "Решено". |
Сообщ.
#5
,
|
|
|
Ой, много читать как.
Цитата HighMan @ Совсем недавно полез разбираться с Docker. Штука отличная! Вот только полного понимания у меня нет. Не могу окончательно понять что есть image, а что container. Базовая система (Ubuntu, Debian, Alpine, ...) это image. Является read only... Если я её запускаю голой, то она как бы упаковывается в контейнер, который уже rw. Я могу доставлять пакеты, творить там невесть что, но все изменения будут лишь до перезапуска этого контейнера? Правильно? image - это образ операционной системы, контейнер - это собствекнно, коробка, внутри которой образ ОС + кусок программ, которые тебе нужно. В результате вполне возможно использовать: Контейнер 1: image Ubuntu + php 7.1 Контейнер 2: image Windows 10 + MSSQL Осталось заэкспозить нужные порты. В идеальном случае используется docker-compose Добавлено Наискось пробежался по теме и не увидел упоминания docker-compose. Ты его вообще не используешь чтоль? Это как? Добавлено Ну т.е. в результате получается 5-6 разных докер файлов: 1) Сервер (Apache\Nginx\etc) 2) PHP (Ruby\Java\Python\etc) 3) Воркспейс (Git + Крон + SSH + прочие рабочие штуки) 4) MariaDB\MySQL\etc 5) Redis\Rabbit\etc Оно всё собирается одним docker-compose.yml в единый проект. Там же пробрасываются порты друг в друга и монтируется фс. На выходе одной командой поднимается всё. |
Сообщ.
#6
,
|
|
|
Цитата Serafim @ Оно всё собирается одним docker-compose.yml в единый проект. Там же пробрасываются порты друг в друга и монтируется фс. На выходе одной командой поднимается всё. Собираем. Перебираем. Пробрасываем. Выбрасываем. Я для себя нашел оптимальное решение - LXC. Данная паравиртуалка как раз полностью инкапсулированная. Впрочем, Docker это лишь странная обертка над LXC. Сейчас переделываю домашнюю машину под хост систему с графической оболочкой и всякими утилитами, не работающими с данными. Все остальное рассовывается в LXC контейнеры. Когда нужно - поднимаю контейнер с БД. Нужен Апач? Еще контейнер с Апач. Или, вдруг, нужен Nginx + PHPfrm. И каждый контейнер тащит в себе данные и методы работы с ними. |
Сообщ.
#7
,
|
|
|
На моей винде не будет работать LXC =)
|
Сообщ.
#8
,
|
|
|
Цитата Serafim @ Это как? Ну мы не используем docker-compose. Это вот так. В чём проблема? (Не читал посты ТС, многабукав) |