На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
! Правила трёх "С"
Пожалуйста,
1. Соблюдайте правила Форума.
2. Слушайте советы Модераторов.
(например, http://forum.sources.ru/index.php?act=ST&f=7&t=80382 )
3. Сверяйтесь с учебником по Великому и Могучему
  
> docker , несколько вопросов
    Здравствуйте, Господа!
    Совсем недавно полез разбираться с 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. И как это сделать? Более менее понятно, как добавить запись
    ExpandedWrap disabled
      echo "parametr=code" >> php.ini
    . А как быть, когда мне нужно менять множество параметров? Как подготовить нужный ini или conf файл и заменить им дефолтный в подготавливаемом image?

    Теперь, хочу прояснить, по правильной архитектуре. Мне нужно ещё добавить nginx... Вот тут я не совсем понимаю. Правильнее создавать отдельный image для nginx? Если я правильно понял, то запихивать его в image с apache&php не комильфо. Почему?
    Ну и, разумеется, nginx + apache&php, не самая сложная проблема.
    А как быть если я захотел засунуть в docker полноценный почтовый сервер (postfix, dovecot, mysql, spamassasin, etc...)?
    Это получается, что каждый модуль почтового сервера придётся запихнуть в отдельный image? А как тогда наладить межконтейнерное взаимодействие? Куча папок, пробрасываемых сразу в несколько контейнеров?

    И, допустим, я увязал все модули почтового сервера. Они даже работают и как-то взаимодействуют друг с другом. Как мне теперь весь этот зоопарк перетащить на другой сервер? Можно, конечно, на целевой сервер передать кучу dockerfile и там их уже "компилять", но это честь левой ногой за правым ухом.
    Как мне свой, собранный "зоопарк" записать на флешку?
    Как потом, правильно с флешки передать на целевой сервер?

    Я понимаю, что мои вопросы многим покажутся наивными и глупыми. Но я пока не нашёл на них внятного ответа в интернет. Вот для понимания я и спрашиваю у знатоков.
    Заранее благодарен!
      Ещё набрал на схожее с docker решение - LXE. Система паравиртуализации. Нечто среднее между OpenVZ и docker. Гостевые "системы" базируются на ядре хостовой машины.
      Кстати, не понял, почему контейнеры docker базируются на image системы, отличной, или схожей с хвостовой. Для чего этот огород? Почему не хостовое ядро?
      Пока c LXE не разбирался, только немного почитал о ней.
      Как я понял, у LXE подход ближе к виртуальным машинам. В контейнере размещается весь зоопарк одновременно, как и на TRUE виртуальном хосте kvm/qemu.
      В чем выигрышь docker? Почему его аж в венды портировали?
        Такс... Для того что бы в image докера закинуть файл из host системы, в dockerfile используется директива ADD.
        ExpandedWrap disabled
          ADD resolv.conf /etc/

        Из host системы, текущего каталога, resolv.conf копируется в создаваемый image /etc/
        Таким образом можно закидывать сильно правленые конфиги в image.
        Можно использовать следующий вариант:
        1.
        ExpandedWrap disabled
          docker images

        Показывает все image в системе
        Нам нужен ID препарируемого image, допустим 6c364d10bf5b
        ExpandedWrap disabled
          docker cp 6c364d10bf5b:/etc/resolv.conf .

        мы скопировали resolv.conf из image в хост систему, текущий каталог.
        Разумеется, resolv.conf не шибко нужен. Его я привел для примера.
        Издеваемся вдосталь над нужным конфигом, потом включаем его пересылку dockerfile, как сказано выше.
        Вообще-то docker cp работает в обе стороны и правленый конфиг можно закинуть в готовый образ, но это считается не кошерным. Потому делаем все по феншую.
        Добавляем в dockerfile
        ExpandedWrap disabled
          ADD resolv.conf /etc/

        и пересобираем образ.
          Тема вызвала сумасшедший интерес у сообщества!

          Теперь, если позволите, я выскажу собственное мнение по этому 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, для себя закрыл.
          Может, конечно, кто-то укажет на мои промахи и не правильное понимание?
          Не ставлю пока на теме "Решено".
          Сообщение отредактировано: HighMan -
            Ой, много читать как.

            Цитата 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. Ты его вообще не используешь чтоль? :huh: Это как? :blink:

            Добавлено
            Ну т.е. в результате получается 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 в единый проект. Там же пробрасываются порты друг в друга и монтируется фс. На выходе одной командой поднимается всё.
              Цитата Serafim @
              Оно всё собирается одним docker-compose.yml в единый проект. Там же пробрасываются порты друг в друга и монтируется фс. На выходе одной командой поднимается всё.

              Собираем. Перебираем. Пробрасываем. Выбрасываем.
              Я для себя нашел оптимальное решение - LXC. Данная паравиртуалка как раз полностью инкапсулированная.
              Впрочем, Docker это лишь странная обертка над LXC.
              Сейчас переделываю домашнюю машину под хост систему с графической оболочкой и всякими утилитами, не работающими с данными. Все остальное рассовывается в LXC контейнеры.
              Когда нужно - поднимаю контейнер с БД. Нужен Апач? Еще контейнер с Апач. Или, вдруг, нужен Nginx + PHPfrm. И каждый контейнер тащит в себе данные и методы работы с ними.
                На моей винде не будет работать LXC =)
                  Цитата Serafim @
                  Это как?

                  Ну мы не используем docker-compose. Это вот так. В чём проблема? (Не читал посты ТС, многабукав)
                  0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                  0 пользователей:


                  Рейтинг@Mail.ru
                  [ Script execution time: 0,0358 ]   [ 15 queries used ]   [ Generated: 28.03.24, 23:57 GMT ]