Docker. Зачем и как

    Есть множество прекрасных публикаций для тех, кто уже пользуется docker-ом. Есть хорошие статьи для тех, кто хочет этому научиться. Я пишу для тех, кто не только не знает, что такое docker, но и не уверен стоит ли ему это знать.

    Я сознательно опускаю некоторые технические подробности, а кое где допускаю упрощения. Если вы увидите, что docker – то, что вам нужно, вы легко найдете более полную и точную информацию в других статьях.

    Начну я с описания нескольких типичных проблем.

    Проблемы


    Первая проблема — как передать продукт клиенту.

    Предположим у вас есть серверный проект, который вы закончили и теперь его необходимо передать пользователю. Вы готовите много разных файликов, скриптов и пишите инструкцию по установке. А потом тратите уйму времени на решения проблем клиента вроде: «у меня ничего не работает», «ваш скрипт упал на середине — что теперь делать», «я перепутал порядок шагов в инструкции и теперь не могу идти дальше» и т. п.

    Всё усугубляется если продукт тиражируемый и вместо одного клиента у вас сотни или тысячи покупателей. И становится еще сложнее, если вспомнить о необходимости установки новых версий продукта.

    Вторая проблема — тиражируемость. Пусть вам нужно поднять 5 (или 50) почти одинаковых серверов. Делать это вручную долго, дорого и подвержено ошибкам.

    Наконец, третья проблема — переиспользуемость. Предположим у вас есть отдел, который делает браузерные игры. Предположим, что их у вас уже несколько. И все они используют один и тот же технологический стэк (например — java-tomcat-nginx-postgre). Но при этом, чтобы поставить новую игру вы вынуждены заново подготавливать на новом сервере почти одинаковую конфигурацию. Вы не можете просто так взять и сказать — «хочу сервер, как в игре странники но только с другим веб архивом»

    Обычные решения


    Как обычно решаются эти проблемы.

    Установочный скрипт


    Первый подход я уже упомянул — вы можете написать скрипт, который установит всё, что вам нужно и запускать его на всех нужных серверах. ( Скрипт может быть как простым sh файлом, так и чем-то сложным, созданным с использованием специальных инструментов).

    Недостатки этого подхода — хрупкость и неустойчивость к ошибкам. Как бы хорошо не был написан скрипт, рано или поздно на какой-то машине он упадёт. И после этого падения машина фактически окажется «испорченной» — просто так «откатить» те действия, которые скрипт успел выполнить, у вашего клиента не получится.

    Облачные сервисы


    Второй подход — использование облачных сервисов. Вы вручную устанавливаете на виртуальный сервер всё, что вам нужно. Затем делаете его image. И далее клонируете его столько раз, сколько вам надо.

    Недостатка здесь два. Во-первых, vendor-lock-in. Вы не можете запускать свое решение вне выбранного облака, что не всегда удобно и может привести к потерям несогласных с этим выбором клиентов. Во-вторых, облака медленны. Виртуальные (и даже «bare-metal») сервера предоставляемые облаками на сегодняшний день сильно уступают по производительности dedicated серверам.

    Виртуальные машины


    Третий подход — использование виртуальных машин. Здесь тоже есть недостатки:

    Размер — не всегда удобно качать образ виртуальной машины, который может быть довольно большим. При этом, любое изменение внутри образа виртуальной машины требует скачать весь образ заново.

    Сложное управление совместным использованием серверных ресурсов — не все виртуальные машины вообще поддерживают совместное использование памяти или CPU. Те что поддерживают, требуют тонкой настройки.

    Подход докера — контейнеризация


    И вот тут появляется docker, в котором

    • есть контролируемая среда (как в виртуальных машинах)
    • есть эффективное управление серверными ресурсами
    • и нет vendor lock-in

    Подобно виртуальной машине докер запускает свои процессы в собственной, заранее настроенной операционной системе. Но при этом все процессы докера работают на физическом host сервере деля все процессоры и всю доступную память со всеми другими процессами, запущенными в host системе. Подход, используемый докером находится посередине между запуском всего на физическом сервере и полной виртуализацией, предлагаемой виртуальными машинами. Этот подход называется контейнеризацией.

    Как работает docker


    Создание образа


    Сначала создается docker image (или образ). Он создается при помощи скрипта, который вы для этого пишете.
    Образы наследуются и, обычно, для создания своего первого образа мы берём готовый образ и наследуемся от него.
    Чаще всего мы берем образ в котором содержится та или иная версия linux. Скрипт тогда начинается как-то так:

    FROM ubuntu:16.04

    Далее при помощи директивы RUN мы можем исполнять любые команды, которые поддерживает этот линукс.
    Например RUN apt-get install -y mc установит в наш образ midnight commander.

    Кроме этого, мы можем копировать в наш образ любые локальные файлы при помощи директивы COPY.

    Например:

    COPY mzoo.war /opt/tomcat/webapps/ROOT.war

    Докер поддерживает гораздо больше различных директив. Например, директива USER roman говорит докеру что все следующие директивы нужно выполнять из под пользователя roman. А директива ENTRYPOINT [“/opt/tomcat/catalina.sh”] задает исполняемый файл, который будет запускаться при старте.

    Я не буду перечислять все остальные директивы — в этом нет смысла. Здесь главное — принцип: вы создаёте вот такой скрипт, называете его Dockerfile и запускаете команду docker build, docker выполняет скрипт и создает image.

    Если в процессе возникают какие-то ошибки, докер о них сообщает и вы их исправляете. То есть исправление скрипта происходит на этапе создания image. На этапе установки скрипт уже не используется.

    Создание контейнера


    Когда у вас уже есть docker image вы можете создать из него контейнер на любом физическом сервере, где установлен докер. Если image – это тиражируемый образ некоторой «машины», то container это уже сама «машина», которую можно запускать и останавливать.

    Важный момент — при создании контейнера из image, его можно параметризовать. Вы можете передавать докеру переменные окружения, которые он использует при создании контейнера из image. Так вы сможете создавать немного разные машины из одного образа. Например, передать образу web-сервера его доменное имя.

    Хорошей практикой в докере считается «упаковка» в один контейнер ровно одного постоянно работающего серверного процесса. Как я уже упоминал, этот процесс работает на уровне физического сервера и честно регулируется установленной там операционной системой. Поэтому, в отличие от виртуальных машин, контейнеры докера не требуют специального управления памятью и процессорами. Использование ресурсов становится простым и эффективным.

    Union filesystem


    Ок — память и процессор используется эффективно. А как насчёт файловой системы? Ведь если у каждого контейнера докера своя собственная копия операционной системы, то мы получим ту же проблему, что и с виртуальными машинами — тяжеловесные образы, которые содержат одно и тоже.

    На самом деле в докере это не так. Если вы используете 100500 контейнеров, основанных на одном и том же образе операционной системы, то файлы этой системы будут скачаны докером ровно один раз. Это достигается за счёт использования докером union file system.

    Union file system состоит из слоёв (layers). Слои как бы наложены друг на друга. Некоторые слои защищены от записи. Например, все наши контейнеры используют общие защищенные от записи слои, в которых находятся неизменяемые файлы операционной системы.

    Для изменяемых файлов каждый из контейнеров будет иметь собственный слой. Естественно, докер использует такой подход не только для операционной системы, но и для любых общих частей контейнеров, которые были созданы на основе общих «предков» их образов.

    Container registry


    Получается, что docker image состоит из слоёв. И хорошо было бы уметь скачивать на наш сервер только те слои, которых на нём пока нет. Иначе для установки 100 контейнеров, основанных на Ubuntu мы скачаем Ubuntu внутри их образов 100 раз. Зачем?

    Хорошая новость в том, что докер решает эту проблему. Докер предоставляет специальный сервис, называемый docker registry. Docker registry предназначен для хранения и дистрибуции готовых образов. Собрав новый образ (или новую версию образа) вы можете закачать его в docker registry. Соответственно, потом его можно скачать оттуда на любой сервер. Главная фишка здесь в том, что физически качаться будут только те слои, которые нужны.

    Например, если вы создали новую версию образа, в котором поменяли несколько файлов, то в registry будут отправлены только слои, содержащие эти файлы.

    Аналогично, если сервер качает из registry какой-то образ, скачаны будут только слои, отсутствующие на сервере.
    Docker registry существует и как общедоступный сервис и как open source проект, доступный для скачивания и установки на собственной инфрастуктуре.

    Использование контейнеров


    Созданные контейнеры можно запускать, останавливать, проверять их статус и т д. При создании контейнера можно дополнительно передать докеру некоторые параметры. Например, попросить докер автоматически рестартовать контейнер, если тот упадёт.

    Взаимодействие между контейнерами


    Если контейнеров на сервере несколько, управлять ими вручную становится проблематично. Для этого есть технология docker compose. Она существует поверх докера и просто позволяет управлять контейнерами на основе единого конфигурационного файла, в котором описаны контейнеры, их параметры и их взаимосвязи (например контейнер A имеет право соединяться с портом 5432 контейнера B)

    Выводы


    Таким образом докер очень хорошо подходит для решения перечисленных выше задач:

    • удобная передача серверного проекта клиенту
    • обеспечение тиражируемости серверов
    • обеспечение переиспользуемости ранее созданных серверных конфигураций

    Отдельно хочу отметить, что докер также крайне удобен для обновления ранее установленных версий продукта и для создания тестовых серверов, полностью идентичных «натуральным».
    Share post

    Comments 159

      +1
      Даже если контейнер на сервере один docker-compose позволяет забыть про поиск параметров запуска текущего контейнера и отказаться от «history | grep docker».

      Также я бы рекомендовал ( а может и посоветуют мне? =) ) отказаться от хранения рабочих файлов и конфигов внутри докер контейнеров и мапить их с самого сервера. Почему:
      1. Чтобы изменить файл, нужно зайти сначала на сервер, потом сделать docker exec, изменить файл, выйти и закоммитить контейнер. А если у нас какой-нибудь легкий alpine образ, а не FROM: ubuntu:16.04, то это становится огромной проблемой.
      2. При обновлении контейнера не нужно думать, что что-то в процессе обновления пойдет не так. Мы просто обновляем докер образ, убиваем контейнер, создаем заново из композа и вуаля, новый обновленный контейнер без лишних хлопот.
        0
        В случае отдельного файла конфигурации контейнер придётся стартовать в среднем два раза, второй с мыслью «опять забыл конфиг добавить»
          0
          Я сейчас конфиги как volumes добавляю. Вроде жизнеспособный вариант:

                  volumes:
                      - .:/opt/project
                      - .docker/app/parameters.yml:/opt/project/app/config/parameters.yml
          

            +1

            Обычно вопрос конфигурации решают через environment variables, особенно это актуально в облачных деплойментах, где смонтировать файл в контейнер может быть большой проблемой

            0

            А история изменений хранится (как в системах версий)?

              +1
              Если вы о возможности сравнить два образа, то такого нет. Образы — это бинарные файлы. Неясно как их сравнивать.
              Здесь логичнее хранить Dockerfile в какой-то системе контроля версий.
              Из него всегда можно сделать образ. И тут история изменний будет прозрачна.
                0
                Судя по тому как это делают на dockerhub — используются таги, кроме того есть некий аналог git — образы можно push'ить, ну а когда собирается контейнер, образы соответственно pull'ятся…

                Я тоже пока не эксперт, но стараюсь локальную разработку переводить на докер, есть и кое-что в продакшене.

                Рекомендую сразу использовать docker-compose — отличная вещь!
                  0
                  некий аналог git


                  Это и есть docker registry. Я писал о ней в статье.
                  Но историю изменений там не увидишь. Можно просто хранить несколько версий одного образа, назначая версию вручную, при помощи тэга.
                    0

                    Кстати, я вот когда заходил на сайты с архивами LaTex, R, Ada, Sage и что то не заметил использования предлагаемых пользователям контейнеров докера — только обычные образы нашел и виртуальные машины — нет ли тут скрытых камней, на которые можно напороться, из за которых образы-контейнеры докера не используются?

                      0
                      Можно помотреть на официальном докер регистри.
                      Вот по слову Ada, например.
                      Хотя, думаю, эти образы сделаны энтузиастами и непонятно, как хорошо они работают.

                      0
                      гит сравнивает изменения только в текстовых файлах, поэтому сравнения сомнительны
                  0
                  По поводу решения проблем — вы забыли упомянуть о системах управления конфигурациями — Puppet, Ansible и т.д.
                  Отлично справляются с проблемами тиражируемости серверов
                    0
                    Я отнёс их к скриптам. Потому что они запускают свои сценарии непосредственно на серверах, на которые делается установка.
                    В этом смысле, они подвержены тем же проблемам. Хотя, конечно, они лучше справляются с задачей, чем самописные shell скрипты.
                      0

                      Мне кажется вы несколько путаете их цели. Докер для виртуализации конкретных приложений, Ansible — для первичной установки и настройки того, что должно быть вне контейнеров.

                        0
                        Ничего не имею против такого использования.
                        Мне не нравится только использование ansible, puppet и т п в качестве единсвенного средства deployment-a.
                          0
                          Видимо, вы не сталкивались вплотную с настройкой configuration management в puppet / chef. В отличие от «одноразовых» stateful скриптов конфигурации puppet/chef описывают не что сделать с системой, а какой она _должна_ быть (записи в конфигурационных файлах, состояние сервисов, наличие пользователей и т.п.)

                          Поэтому, в теории, любой сломанный пользовательский сервер на котором что-то случилось, puppet/chef приведет в эталонное рабочее состояние (обычное использование — синхронизация раз в час и принудительный возврат всех измененных параметров в эталонные значения).
                          В этом смысле использование Configuration management более «дуракоупорное», чем docker — он сам себя чинит.

                          Неспроста огромное количество программного обеспечения распространяется через chef-solo (дистрибутив и настройщик в одном флаконе)
                            0
                            Разница здесь в том, что puppet/chef запускает на продакшен серверах команды, чтобы добиться там появления кастомной конфигурации, созданной пользователем.
                            Эта задача заведомо более сложная, чем то, что делает докер — тупо запускает заранее подготовленные процессы — никакой кастомной логики во время установки не выполняется.
                            Другими словами, в случае с паппетом есть чему ломаться во время установки на продакшен.
                            В случае с докером поломки будут не во время установки, а во время сборки образа. То есть для их устранения не нало иметь доступ на production server.
                    +1
                    Скажите, пожалуйста, правильно ли я понял, что если у нас есть, например, LAMP стек, то каждый серверный процесс этого стека можно запускать в отдельном контейнере? Т.е. вообще говоря, например, контейнер базы данных потом можно обновлять независимо.

                    Также очень любопытно как докер взаимодействует с файрволом домашней ОС. Ну, например, в контейнере висит Postgre на порту 5432. В домашней ОС этот процесс биндится на тот же порт?
                      0
                      1) Вы поняли правильно
                      2) Здесь все сложнее. По умолчанию докер создает виртуальную сеть для каждого контейнера. Если использовать docker compose, то его умолчание — виртуальная сеть, в которой каждый контейнер будет хостом. Можно управлять виртуальными сетями гибко. А можно и вовсе их отключить и заставить все контейнеры напрямую использовать сеть хоста.
                      В последнем случае порты окажутся в общем адресном пространстве. Но так тоже делают, когда очен важен performance. Виртуальная сеть докера может добавить задержку до 70мс.
                        0
                        Ошибся тут: По умолчанию докер создает виртуальную сеть для каждого контейнера
                        На самом деле умолчания у докера и docker-compose одинаковы: виртуальная сеть, в которой каждый контейнер будет хостом
                          0
                          Большое спасибо за подробный ответ. Из всего сказанного мне кажется, что Docker также это и реально крутой способ развертывания development окружения для разработчика. Например, можно быстро попробовать свое приложение с разными DBMS. Также, если надо отладить взаимодейсткие с какой-то внешней системой, можно держать ее минимальный рабочий прототип в виде подключаемого контейнера.
                            0
                            Docker также это и реально крутой способ развертывания development окружения для разработчика


                            Да. И даже более того.
                            Некоторые считают, что сам deployment вообще исчезнет, как отдельный процесс.
                            Dockerfile будет создаваться в процессе разработки.
                            Образы будут сразу тестироваться а потом, как есть отправляться в production.
                            Звучит интересно.
                              +1
                              Расскажите, а какой best practice в данном случае для замены конфигов с девелоперских на те, которые должны работать в проде? Отличия могу быть, например, в:
                              — разных паролях и хостах с БД
                              — разных требованиях к памяти и CPU affinity (например, на dev'е nginx работает в минимальной конфигурации на 2-х ядрах, а в проде ему надо выдать кучу памяти и 16 ядер)
                              — запрете разработчикам подключаться к прод-серверам (т.е. другие имена/пароли/ключи локальных пользователей системы)
                                0
                                разных паролях и хостах с БД

                                Здесь проще всего задать пароль, имя пользователя, хост и имя базы данных переменными окружения, передаваемыми самому контейнеру с СУБД. Так, чтобы они совпали с вашими.

                                разных требованиях к памяти и CPU affinity

                                Здесь обычно создаётся volume с конфигурацией, этот volume мэпится на директорию хост системы и там конфигурация правится руками. Некоторые параметры тоже можно передавать переменными окружения. Другой вариант — отнаследовать production image от development image и поменять там конфигурацию, просто перекрыв её новой при помощи директивы COPY.

                                запрете разработчикам подключаться к прод-серверам

                                Тут даже не скажу. Я написал «некоторые считают, что deployment исчезнет», но это не значит, что он уже исчез конкретно у нас.
                                Думаю, можно поступить также, как с конфигурацией, вынесенной на отдельный volume. Или опять отнаследовать образ.
                                Но сам я такого не делал.
                                  0
                                  Спасибо за ответ
                                    0
                                    пожалуйста
                              0
                              И еще одно интересное применение. Один из важных компонентов одного из наших проектов делается территориально удаленной командой разработчиков. Компонент написан на c++ и собирается под определенной версией linux.
                              До применения докера мы тратили массу времени на интеграцию этого компонента.
                              То авторы добавили новую зависимость, которой у нас нет и которая конфликтует с чем-то еще на нашем сервере.
                              То их бинарник просто почему-то не запускается, а при попытке сборки из сорцов вылетает ошибка компиляции.

                              Теперь они предоставляяют этот компонент, как докер image. Проблем больше нет. Вообще.
                                0
                                А почему бы не собирать бинарь статически? Мы так и делаем. 1 бинарь проще, чем образ с бинарем
                                  0
                                  Интересный вопрос. Спрошу у лида этого проекта и напишу.
                                    0
                                    Ответ простой — там, кроме бинарника были еще какие-то файлы, которые он использовал. Они тоже часто менялись (в том числе и их набор)
                                    Можно, конечно, было передавать все архивом и раскладывать файлы по местам, а старые удалять. Но это — неустойчиво к человеческим ошибкам.
                            0
                            Спасибо, наглядно для тех, кто никогда не сталкивался.
                            Сразу вопрос — у нас большая часть приложений на стеке Microsoft. Умеет ли с ним работать docker?
                              0
                              Насколько мне извесно, нет. Но точно говорить не буду.
                                +1
                                Microsoft реализовала поддержку docker-контейнеров в Windows Server 2016. В превью уже можно пощупать. Приятно то, инструментарий работает как с *nix так и с windows хостами. Жалко только образы должны быть с соответствующей операционной системой.
                                  0
                                  умеет. недавно настраивал. базовых образов мало и работают только образы для windows.
                                    0

                                    Надо понимать важный момент. В основе докера изначально лежит технология LXC, что подразумевает необходимость линукса и, соответственно, для разных ОС будут и разные, несовместимые образы. В основе докера для винды лежит технология hyper-v и некоторое кол-во костылей для получений специфичных особенностей ядра линукса.

                                      0
                                      LbISS а вопрос был не про запуск образа винды в докере? Или я неверно вас понял?
                                        0
                                        Да, вы правильно поняли. Сейчас у нас коробочный продукт на ASP.Net, который приходиться разворачивать на огромном количестве серверов каждый раз с нуля. Естественно, сейчас это происходит на Windows Server. Если образ винды в докере получится развернуть под линуксом и он будет хорошо работать — вполне себе вариант хотя бы для новых клиентов.
                                          0
                                          Не получится. Docker под линуксом может запускать только процессы способные работать под линуксом.
                                            0
                                            А вот тут про что? (Сам я не знаю, но выглядит так, будто МС что-то такое делает)

                                              0
                                              Видимо про windows контейнеры на windows хосте.
                                                0
                                                Похоже на то. Но они используют там докер.
                                                  0
                                                  Ну, если ядро винды может предоставить тот же api и те же возможности что и линукс, то почему нет, но запускать он очевидно сможет только windows процессы.
                                                    0
                                                    Вроде бы LbISS именно это и нужно.
                                                    Только, оно пока выглядит недоделанным. Но раз МС взялась, возможно сделают.
                                                      0
                                                      Если образ винды в докере получится развернуть под линуксом и он будет хорошо работать — вполне себе вариант хотя бы для новых клиентов

                                                      Я написал, что не получится так.
                                                        0
                                                        Точно. Так не получится — невнимательно прочитал. Но и винда в винде может оказаться неплохим вариантом.
                                    –7
                                    Может я тут плохо понял — но чем ЭТО принципиально отличается от подхода в винде с работой связки код-данные? (один код — разные данные). Откуда в основном и проблемы у них растут с «падением» и «синими экранами»…
                                      +3
                                      Не понял ваш вопрос. Поясните подробнее.
                                        –3
                                        Ну ниже подняли практический вопрос из моего теоретического.
                                        Поясняю — по статье выходит, что данная система по принципу построения мало отличается от принципа построения ОС от Майкрософт, т.е. у них — один программный код работает с раздельными данными и сбой в работе кода ведет к сбою работы со всеми данными. И в самом плачевном случае — сбою всей системы. Поэтому при установке ПО ОС надо перезагружать. Поэтому и вечные проблемы с надежностью работы.
                                        В *nix-ах каждый код работает со своими данными — что и дает надежность.
                                        То, что описано в статье, на мой взгляд — попытка привнести неудачный подход в надежности работы системы.
                                        Ниже уже утверждается — да — надо перезагружаться при обновлениях, да — влияет на работоспособность всех зависимых контейнеров.
                                        Мое мнение — этот инструмент больше подходит для тестировщиков (где надо промоделировать схожие ситуации в работе ПО и/или собрать статистику), чем для внедрения в реальные системы.
                                          +1
                                          Не вижу почему в докере код работает не со своими данными.

                                          да — надо перезагружаться при обновлениях


                                          А если вы обновили скажем tomcat, postgre или ваш собственный код БЕЗ докера, то перегружаться не надо?
                                          Host систему никто не перегружает. А перезапуск контейнера делается очень быстро. Контейнеры вообще быстры и легковесны. По сравнению с native процессами penalty составляет 1-2%

                                          да — влияет на работоспособность всех зависимых контейнеров


                                          Напрямую не влияет. Они изолированы. Влияет в то же степени, в которой остановка сервера управления базой данных повлияет на приложение, которое его использует.
                                            –1
                                            А если вы обновили скажем tomcat, postgre или ваш собственный код БЕЗ докера, то перегружаться не надо?

                                            нет — не надо — во всяком случае пока этот код работает с этими данными — код будет работать, а вот при следующем вызове запустится уже обновленный новый экземпляр кода. И да — в системе могут работать сразу два кода. Даже ядро так работает. И да — даже при обновлении ядра не надо перезагружать всю систему (ну уж если не совсем все поменяли).
                                            Это все уже давно-давно есть в *nix-ах.

                                            Влияет в то же степени, в которой остановка сервера управления базой данных повлияет на приложение, которое его использует.


                                            Ну и чем это не подход от МС — сбой в работе с данными приводит к сбою приложения (и соответственно с другими данными)?

                                            Так что нового и удобного дает докер для «нетестировщиков»?
                                              0
                                              И да — в системе могут работать сразу два кода


                                              Как вы себе представляете работу сразу двух application серверов в одной системе? Как они порты поделят, например? А если они еще и данные кэшируют? А если новая версия приложения вносит изменения в схему базы данных?

                                              сбой в работе с данными приводит к сбою приложения


                                              Давайте уточним терминологию. Что вы называете «данными»? Неужели docker image? Или что?

                                              На всякий случай: для хранения persistent данных в докере используются volumes. Данные хранятся отдельно от контейнеров и сохраняются при рестарте или обновлении. Docker image — это не данные. Это, если хотите — параметризованный код.
                                                0
                                                Что вы вообще понимаете под «кодом» и «данными»?

                                                а вот при следующем вызове запустится уже обновленный новый экземпляр кода. И да — в системе могут работать сразу два кода. Даже ядро так работает. И да — даже при обновлении ядра не надо перезагружать всю систему (ну уж если не совсем все поменяли).


                                                Вы про hot-reload что ли?
                                                  –1
                                                  код — то, что передается на исполнение (команда процессору)
                                                  данные — то, над чем оперирует код (информация)

                                                  холодная перезагрузка — перезагрузка системы при помощи аппаратного механизма (железо)
                                                  горячая перезагрузка (hot-reload) — перезагрузка системы при помощи команды (кода) процессору

                                                  то о чем я писал — обновление и запуск ядра системы «не лету» — без перезагрузок вообще.

                                                  Насколько я понимаю — докер хранит и использует разность кода от базового образа как свои данные, которые передает на исполнение. Фактически контейнер это разностная копия данных. Так?

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


                                                  То есть при «падении» докера — «упадут» и все контейнеры — со всеми своими пользовательскими приложениями и данными? И времени до «падения» будет ровно столько, пока к докеру не обратится.

                                                  От чего зависит в итоге конечный пользователь:
                                                  Зависимость от хост-системы,
                                                  зависимость от докера,
                                                  зависимость от изначального образа для контейнера
                                                  зависимость от настройки контейнера,
                                                  зависимость настройки конечного ПО в контейнере

                                                  Сравните с работой при использовании гипервизора (который намного легче и проще хост-системы — а значит и надежнее)

                                                  В итоге:
                                                  Это более надежная система? Нет. Удобная по быстроте разворачивания? Да.
                                                  Т.е. область применения — девелоперы и тестировщики.
                                                    0
                                                    Фактически контейнер это разностная копия данных. Так?


                                                    Нет. Union FS работает не так.

                                                    То есть при «падении» докера — «упадут» и все контейнеры — со всеми своими пользовательскими приложениями и данными?


                                                    Тоже нет. Процессы продолжат работать даже если упадет docker daemon.

                                                    Зависимость от хост-системы


                                                    Минимальна. В идеале её нет вовсе.

                                                    зависимость от докера


                                                    Да. Докер контейнеры зависят от докера. Если бы докер был ненадежным или некачественным продуктом, это было бы важным аргументом против.

                                                    зависимость от настройки контейнера


                                                    Как эта зависимость влияет на надежность? Настройка конейнера не может «упасть» и потянуть за собой какие-то проблемы. Настройка контейнера — это конфигурация.

                                                    зависимость настройки конечного ПО в контейнере


                                                    То есть ваше ПО зависит от его настройки. Неудивительно.
                                                    При этом докер как раз сильно снижает количество проблем такого рода, позволяя проверить ваш контейнер заранее точно в таком же окружении, в котором ему предстоит работать.
                                                      –1
                                                      Нет. Union FS работает не так.

                                                      По приведенной ссылке — именно так — с построением древовидной структуры и приоритетом доступа.
                                                      Тоже нет. Процессы продолжат работать даже если упадет docker daemon.
                                                      пока не надо будет к нему обратится, а обратится надо будет — если вдруг перезапуск системы или сверка с изначальным образом, или чтение конфигурации…
                                                      Зависимость от хост-системы
                                                      Минимальна. В идеале её нет вовсе.

                                                      не надо лукавить — докер — одино из приложений в хост-системе — со всеми вытекающими

                                                      Если бы докер был ненадежным или некачественным продуктом, это было бы важным аргументом против.
                                                      Сбои происходят с любым ПО — насколько часто — это зависит от многих факторов. Я указал что это еще один уровень в возможном сбое. То же относится и настройке конечного ПО — это уровень возможного отказа (сбоя).

                                                      позволяя проверить ваш контейнер заранее точно в таком же окружении

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

                                                        В итоге мы пришли к мнению о применении у тестировщиках и девелоперах. Пользователям незачем проверять работу приложения — пользователям надо чтобы оно уже работало.


                                                        Мало смысла использовать докер для тестировщиков, если потом не запускать тот же самый образ в production. Получится тестировали одно, а работает другое.
                                                          0
                                                          ну тогда нет логики в написании отдельного ПО как такового — сразу надо с ОС поставлять — но так же не делают — верно?
                                                            0
                                                            сразу надо с ОС поставлять — но так же не делаю — верно?

                                                            По сути, докер так и делает :)

                                                            А вообще ситуации бывают разные. Я начал статью с типовых ситуаций, где докер применять есть смысл.
                                                            Совершенно очевидно, что в массе других ситуаций докер не нужен, а нужно как раз «отдельное ПО».
                                                              0
                                                              Вы похоже слабо представляете себе область применения докера. При разработке больших веб-сервисов и всяких сложных систем, например для телекомов или банков, могут не то что ОС поставлять, могут целое облако в эксплуатацию отдавать, с кучей машин, специфически настроенных ОС и сотнями взаимодействующих между собой приложений. Когда стоит именно такая задача — докер один из отличных инструментов для ее решения.
                                                                –1
                                                                Строго говоря для надежности сложная система должна иметь несколько автономных (и/или дублированных-троированных) узлов (в идеале все — что экономически не выгодно) для гарантированного выполнения своих задач.
                                                                Докер же как мне представляется, делает с точностью до наоборот — все сводится к полной централизации. Т.е.придется прилагать усилия для обеспечения его надежной работы, а также используемых линий связи — в сложных и распределенных системах.
                                                                  0
                                                                  Если и есть централизация, то только в рамках одного физического сервера.
                                                                  Так можно упрекнуть в полной централизации и операционную систему.
                                                                    –1
                                                                    Можно. ОС — это и есть централизованное управление доступом к конкретным аппаратным ресурсам. И ее надежность по сравнению с гипервизором ниже. Поэтому его (гипервизор) и используют для повышения надежности — убирают слой прикладного ПО на более высокий уровень. Ну для надежности еще и дублируют (создают кластеры).
                                                                    0
                                                                    Ппц каша у вас в голове.
                                                            0
                                                            > Тоже нет. Процессы продолжат работать даже если упадет docker daemon.

                                                            Как Вы этого добились? Я по-прежнему вижу такое поведение в последней на текущий момент версии 1.12.1:

                                                            [root@home ~]# docker run -d alpine sleep 100500
                                                            5875809562f9be61f52de3d863a26d2aa45b9446e7b8a4683c1083727ea1d705
                                                            [root@home ~]# docker run -d alpine sleep 100500
                                                            4d60cf6ca2a64f711b93c1b67f1b6605d93ac4501782a6325a46d7fa94818626
                                                            [root@home ~]# docker ps
                                                            CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
                                                            4d60cf6ca2a6        alpine              "sleep 100500"      4 seconds ago       Up 3 seconds                            agitated_agnesi
                                                            5875809562f9        alpine              "sleep 100500"      7 seconds ago       Up 5 seconds                            serene_meitner
                                                            [root@home ~]# systemctl restart docker
                                                            [root@home ~]# docker ps
                                                            CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
                                                            [root@home ~]#
                                                            


                                                            В докере процессы порождаются не системой инициализации, а самим докер-демоном. Умирает демон — умирают его дети.

                                                            Rkt и systemd-nspawn запускают контейнеры правильно. Docker, увы, по-прежнему нет.
                                                              0
                                                              Если вы честно выключаете докер, то так оно и будет.
                                                              Но попробуйте убить его процесс через

                                                              kill -9

                                                              Дети останутся. Так же они останутся, если докер демон закрэшится из-за внутренней ошибки. Именно об этом шла речь.
                                                                0
                                                                Да, это так. Только остаются они только до тех пор, пока докер не запустится вновь (например, через docker.socket). При запуске он чистит старые контейнеры и благополучно убивает процессы, не запуская новых (что ожидаемо, ведь для них не установлен restart policy). Это недопустимо.
                                                                Вдобавок, проблема не в том, что докер может упасть. Мне ещё не встречались падения его на ровном месте, поэтому в этом плане можно считать его достаточно надёжным. Проблема в обновлениях самого докера, к примеру, из системных пакетов, при котором происходит стандартный рестарт. С убийством детей.
                                                                Докер берёт на себя роль супервизора процессов. Апофеоз такого подхода — RancherOS, где systemd заменен на докер. Я бы не рискнул использовать это в продакшене. Просто потому, что при всём уважении к труду авторов докера, он не может сравниться с инструментом, который специально создан для управления всеми системными процессами.
                                                                  +1
                                                                  Разумеется, докер — не универсальное решение любой задачи.

                                                                  Но есть задачи, где его вполне можно использовать в production.
                                                                  Сам по себе он обновляться не будет. Ничто не мешает включить restart policy.
                                                            0
                                                            hot-reload с точки зрения ПО — замена исполнимого кода без остановки приложения. Erlang так умеет, например.

                                                            Сравните с работой при использовании гипервизора (который намного легче и проще хост-системы — а значит и надежнее)

                                                            Работая на более низком уровне гипервизор НАМНОГО сложнее чем докер. И требования к надежности гипервизова намного выше. Так как при ошибке в докере упадет конкретный контейнер (наверно, я не знаю, кто знает — поправьте), а при ошибке в гипервизоре у вас упадет все, что выше него: хост-система(ы), докер и все остальное.

                                                            Докер, к слову, работает за счет механизмов ОС, поэтмоу его надежность упрощенно можно приравнять надежности самой ОС.
                                                              –1
                                                              Работая на более низком уровне гипервизор НАМНОГО сложнее чем докер

                                                              Ничего удивительного — гипервизор реально управляет системой (ее основными функциями), а докер — всего лишь приложение и много чего передает для отработки хост-системе и работает в принципе из-под нее (с меньшим приоритетом)
                                                              И поэтому его надежность выносится отдельно от надежности хост-системы. Упрощенно.
                                                              0
                                                              холодная перезагрузка — перезагрузка системы при помощи аппаратного механизма (железо)
                                                              горячая перезагрузка (hot-reload) — перезагрузка системы при помощи команды (кода) процессору


                                                              Холодная перезагрузка и горячая отличаются тем, что при «горячей» не производится проверка памяти, так как она была проверена при холодной, за счет чего ПК загружается быстрее. В большинстве случаев, простая перезагрузка ПК будет как раз-таки горячей. Полное выключение и последующий запуск — тоже, в каком-то смысле холодная перезагрузка. Reload и Restart, это, кстати, разные вещи.
                                                                0
                                                                я добавлю и больше — при горячей и память может не очищается — и в общем-то зависит от конкретной реализации железа. Уж не говорю о том что с портами и периферией происходит. Неизменно одно — процессор начинает работу с «нуля».
                                                                0
                                                                код — то, что передается на исполнение (команда процессору)
                                                                данные — то, над чем оперирует код (информация)

                                                                Ок, теперь объясните:
                                                                1. что такое «свои» данные и чем они отличаются от «не своих»
                                                                2. Что означает ваша фраза:
                                                                в системе могут работать сразу два кода.

                                                                докер хранит и использует разность кода от базового образа как свои данные, которые передает на исполнение.

                                                                Ну… очень корявая формулировка, но направление мысли примерно правильное. Docker image хранит слои файловой системы с нужным конкретному процессу набором файлов. В таком же смысле можно сказать что любая ОС «хранит и использует разность кода от базового образа (свежеустановленного) как свои данные, которые передает на исполнение».
                                                                Фактически контейнер это разностная копия данных. Так?

                                                                Нет, контейнер — это процесс(ы) запущенный в и изолированном окружении, которое предоставляет image.
                                                                Также получается, что сбой в организации хранения и вызова данных для исполнения контейнера (докера) может привести к сбою работы других контейнеров

                                                                Какого рода «сбой»? Что такое «организация хранения и вызова данных»? Если вы о файловой системе контейнера, то нет, проблемы одного контейнера никак не повлияют на остальные.
                                                                То есть при «падении» докера — «упадут» и все контейнеры — со всеми своими пользовательскими приложениями и данными?

                                                                Вроде бы с версии 1.12.0 контейнеры должны спокойно относиться к рестартам docker демона, в любом случае, хороший контейнер должен быть stateless и ему должно быть наплевать на то перезагружают его или нет. Пользовательские данные хранить в контейнере не нужно.
                                                                И времени до «падения» будет ровно столько, пока к докеру не обратится.

                                                                Эту фразу я вообще не понял
                                                                гипервизора (который намного легче и проще хост-системы — а значит и надежнее)

                                                                В каком смысле он легче и проще? Вы теплое с мягким сравниваете, гипервизора работает поверх хост системы. В этом смысле докер легче и проще, тк по сути предоставляет средства изоляции на уровне ядра ОС хост системы. Как раз гипервизор менее надежен, тк его падение гарантированно уюивает все виртуальные машины.
                                                                Это более надежная система? Нет. Удобная по быстроте разворачивания? Да.

                                                                Более надежная и удобная по быстроте чем что?
                                                                Т.е. область применения — девелоперы и тестировщики.

                                                                Неверно
                                                                  –1
                                                                  1. что такое «свои» данные и чем они отличаются от «не своих»

                                                                  Извините, но тут уж должен направить на изучение работы процессора в защищенном режиме (хотя бы в общих чертах)
                                                                  2. Что означает ваша фраза:

                                                                  в системе могут работать сразу два кода.

                                                                  А здесь к общим понятием запуска и работы процессов (кода) в *nix системах.

                                                                  гипервизора работает поверх хост системы.

                                                                  Извините — но это Вы путаете понятие гипервизора и систему виртуализации.
                                                                  Чтобы попроще — гипервизор устанавливается на железо, система виртуализации — на хост-систему. И тут гипервизор более надежен — т.к. у него меньше код, а значит и меньше верятность сбоя.Также гипервизор не работает с пользовательским ПО — он работает с системным ПО — его надежность намного выше, чем хост-системы.
                                                                  Более надежная и удобная по быстроте чем что?
                                                                  Чем стандартно установленная ОС.

                                                                    0
                                                                    Извините, но тут уж должен направить на изучение работы процессора в защищенном режиме (хотя бы в общих чертах)

                                                                    Извините, но ответ не принимается, к контексту нашей беседы защищенный режим никакого отношения не имеет. Вы противопоставляли операционки МС и *nix, по-вашему что, в винде процессы в реальном режиме работают?
                                                                    А здесь к общим понятием запуска и работы процессов (кода) в *nix системах.

                                                                    Тут видимо отсылка к многозадачности, ну так я вас удивлю, в винде тоже реализованна такая абстракция как процесс и есть в наличии средства управления процессами и многозадачность.
                                                                    Извините — но это Вы путаете понятие гипервизора и систему виртуализации.

                                                                    Это одно и то же, гипервизоры бывают как реализованные поверх железа так и поверх ОСи, но эта деталь никак не влияет на тот факт, что падение гипервизора приведет к падению всех гостевых операционок.

                                                                    Ну и по поводу «направления на изучение», вы несете бред и демонстрируете полное непонимание темы, лучше бы уж помолчали, чем направлять меня куда-то, потому что выглядит это глупо и смешно :)
                                                                      –1
                                                                      Т.е. Вы утверждаете что докер работает на любой архитектуре железа и напрямую к процессору не обращается? В статье и комментариях утверждается обратное.

                                                                      Насчет ОС от МС — по умолчанию (для оптимизации использования памяти) ОС делает интересные «финты» с кодом и данными — и надо использовать доп системные утилиты и настройки чтобы использовать возможность действительно независимого использования кода и данных.
                                                                      ну так я вас удивлю, в винде тоже реализованна такая абстракция как процесс

                                                                      Да не надо меня удивлять — просто внимательно прочитайте свои же слова.

                                                                      И про гипервизоры — ну хоть википедию почитайте внимательнее что-ли.

                                                                      ОФФ И кстати — переход на личности, и личные характеристики говорит о невозможности аргументировать свою точку зрения и отсутствию самой возможности конструктивного решения нашего спора. Не любите критику — лучше молчите.
                                                                        0
                                                                        В статье и комментариях утверждается обратное.


                                                                        Где именно в статье утверждется обратное?
                                                                          0
                                                                          вот в комментах
                                                                          f0rk
                                                                          докер легче и проще, тк по сути предоставляет средства изоляции на уровне ядра ОС хост системы.

                                                                          «Уровень ядра» — это прямое обращение к аппаратуре — т.к. у ядра ОС наивысший приоритет обычно.
                                                                            0
                                                                            А таки в статье где?
                                                                              0
                                                                              Но при этом все процессы докера работают на физическом host сервере деля все процессоры и всю доступную память. Подход, используемый докером находится посередине между запуском всего на физическом сервере и полной виртуализацией,
                                                                                0
                                                                                Возможно, я неточно выразился. Но имел ввиду: деля все процессоры и всю доступную память со всеми другими процессами, запущенными в host системе.
                                                                              0
                                                                              Ок, уточню формулировку. Docker — это тула, которая позволяет удобно использовать средства изоляции на уровне ядра ОС хост системы, такие как cgroups. Сам докер естественно работает в user space.
                                                                                0
                                                                                ну вот — наконец место в хост-системе определили.

                                                                                Далее — что произойдет если докер упадет?
                                                                                Из обсуждений ниже и этой фразы выходит что, докер посредством cgroups запускает на исполнение образ системы с изменениями взятыми из конфига для контейнера?
                                                                                Этот код независим уже или все-таки управляется докером?
                                                                                Как это работает с распределенной сложной системой? Типа удаленной загрузки?
                                                                                  0
                                                                                  Докер запускает не образ системы с изменениями, а просто образ. Что там в нём будет определяется вашим Dockerfile.
                                                                                  Из конфига для контейнера берутся переменные окружения и некоторые параметры определяющие, как именно стартовать контейнер.
                                                                                  Код независим. Но процесс является child-ом от докеровского демона.
                                                                                  Докер может этот процесс остановить (послав ему SIGTERM, а если не реагирует то просто убить)
                                                                                  Если докеровский демон умрёт, контейнеры станут сиротами (orphan) со всеми вытекающими.
                                                                                    0
                                                                                    Как это работает с распределенной сложной системой? Типа удаленной загрузки?


                                                                                    А вот это поясните, пожалуйста. На первый взгляд кажется, что это вообще не относится к делу.
                                                                                      0
                                                                                      Сформулирую по другому — существует ли у докера возможность работать с несколькими физическими серверами — т.е. своя система репликации образов систем и контейнеров? Или все ограничивается одним сервером с его ФС?
                                                                                        0
                                                                                        существует ли у докера возможность работать с несколькими физическими серверами


                                                                                        Существует. Но это — самостоятельный продукт. Docker swarm

                                                                                        Обычный докер работает в рамках одного физического сервера.
                                                                                      0
                                                                                      Далее — что произойдет если докер упадет?

                                                                                      Насчет падения не уверен, на моей практике он ни разу не падал, но скорее всего если его получится сразу рестартануть, ничего плохого не случится, хотя могут быть и траблы с доступом к контейнерам по сети. Если контейнеры запущены с --net=host и работают с сетевыми интерфейсами хоста, то вероятность проблем меньше. Но это мои предположения, их нужно проверять. Просто рестарт демона контейнеры переживают без проблем, по сути, контейнеризованные процессы — такие же полноценные процесы в рамках ОС, просто разбитые по namespace.
                                                                                      докер посредством cgroups запускает на исполнение образ системы

                                                                                      Не совсем понятно, что вы имеете в виду под «образом системы». Докер запускает процесс в хост системе, этот процесс использует ядро хост системы для системных вызовов, по сути разница с обычным процессом в том, что он не видит файловую систему хоста и не видит остальные процессы запущенные вне его контейнера.
                                                                                      с изменениями взятыми из конфига для контейнера

                                                                                      Эту часть не понял, что вы подразумеваете под «конфигом для контейнера»?
                                                                                      Этот код независим уже или все-таки управляется докером?

                                                                                      Процесс в контейнере независим настолько, насколько независим любой дочерний процесс.
                                                                                      Как это работает с распределенной сложной системой?

                                                                                      На каждом хосте должен быть свой демон, контейнеры могут общаться через overlay network, можете тут почитать
                                                                                0
                                                                                И про гипервизоры — ну хоть википедию почитайте внимательнее что-ли

                                                                                Вот картинка из Википедии:
                                                                                image
                                                                                невозможности аргументировать свою точку зрения
                                                                                То что вы абсолютно не разбираетесь в теме настолько очевидно, что у меня нет никакой необходимости что либо аргументировать, я кстати могу нести полнейшую чушь и все равно будет смешно :)
                                                                                  0
                                                                                  Так если посмотреть, то в комментариях есть одна главная тема — вот эта и пара более мелких, где народ хоть как-то обсуждает докер.
                                                                                    0
                                                                                    холивары — наше всё
                                                                                      0
                                                                                      Ну а что, по вашему, является главным двигателем интернета? Котики, холивары и порно. Ранжировать эти двигатели можно в зависимости от личных предпочтений.
                                                                                        0
                                                                                        в зависимости от личных предпочтений.


                                                                                        Не выйдет. Котики и порно на хабре запрещены.
                                                                                          0
                                                                                          Я думаю, при желании можно и то и то найти и на хабре.
                                                                                    0
                                                                                    Хорошо. Признаю свою ограниченную точку зрения на виды гипервизоров. Хотя я пользовался другими статьями при определении виртуализации ОС.

                                                                                    я кстати могу нести полнейшую чушь и все равно будет смешно :)
                                                                                    я рад что Вы весело провели время
                                                                                      0
                                                                                      я рад что Вы весело провели время
                                                                                      А я рад, что вы готовы расширять свой кругозор :)
                                                                              –1
                                                                              В таком же смысле можно сказать что любая ОС «хранит и использует разность кода от базового образа (свежеустановленного) как свои данные, которые передает на исполнение».

                                                                              Ваше утверждение не верно.
                                                                              Образ системы — это сохраненная копия кода и (возможно) данных на определенный момент времени. Как правило для его создания используются сторонние инструменты, т.к. обычно ОС имеет наивысший приоритет выполнения и не дает доступа к критическому коду.
                                                                              Даже в обычном ПК (с х86 архитектурой) код ОС не изменяется произвольно. Я уж не говорю о других системах (ну навскидку были процессоры PowerMac или реализации суперЭВМ, встроенные системы) — для изменения кода требовался особый алгоритм и средства.
                                                                              К тому что Вы описали больше подходят системы с произвольно изменяемой архитектурой к созданию которых только подошли, и в какой-то мере нейросистемы.
                                                                                0
                                                                                были процессоры PowerMac


                                                                                А можно подробнее про них? Я о таких к своему стыду не слышал.
                                                                                  –1
                                                                                  Извините, ошибся — это были компьютеры от Apple на базе PowerPC ()

                                                                                  В данном контексте упомянул, т.к. в них аппаратно была разделена память программ (для кода) и память данных. (надо заметить что зависали они тоже довольно часто, но все же меньше чем с х86 архитектурой). В принципе подобных подход в архитектуре наблюдаем в микроконтроллерах.
                                                                                    0
                                                                                    Это называется Гарвардская Архитектура.

                                                                                    надо заметить что зависали они тоже довольно часто, но все же меньше чем с х86 архитектурой

                                                                                    Чтож от них отказались, раз они так хороши?

                                                                                    Насколько я помню, кэш L1 в x86 тоже разделяет код и данные.
                                                                                      –1
                                                                                      деньги направляют. В какой-то момент в Apple решили что свои процессоры выпускать — себе дороже и перешли на x86. Ну и Intel тоже давил конкурентов. Сейчас вот все больше начинают переходить на ARM, т.к. х86 уже не дает нужных результатов.
                                                                                      Насколько я помню, кэш L1 в x86 тоже разделяет код и данные.
                                                                                      Не совсем так. Он хранит их отдельно — соответственно к частоте обращений. Ну и при многоядерности и/или эмуляции многоядерности — это дает неплохой прирост производительности.
                                                                                  0
                                                                                  Даже в обычном ПК (с х86 архитектурой) код ОС не изменяется произвольно.
                                                                                  Когда-то давно (я еще зеленым школьником был) у меня было хобби компилять ядро для слаки, так вот, что-то не припомню, чтоб мой пень (с х86 архитектурой) как-то противился таким экспериментам.
                                                                                    0
                                                                                    в данном случае Вы запускали минимальное ядро — производили компляцию кода под свое железо, и при перезагрузке уже запускали полученный код. Конечно все это вообще работало через BIOS — или его Вы тоже произвольно меняли? Прям во время работы системы?
                                                                                      0
                                                                                      Конечно все это вообще работало через BIOS — или его Вы тоже произвольно меняли?

                                                                                      Нет конечно, у меня так брат умер.
                                                                          +2
                                                                          Что вы несете? Я ничего не понял…
                                                                            0
                                                                            Давайте коллективно выясним, о чем речь. Я тоже ничего не понял. Код, данные, два кода (почему не три?) свои не свои данные. Бред какой-то.
                                                                              0
                                                                              Может я тут плохо понял

                                                                              Я думаю, что предположение из первого коммента в ветке верное.
                                                                                0
                                                                                Я вот это не могу осознать:
                                                                                Поясняю — по статье выходит, что данная система по принципу построения мало отличается от принципа построения ОС от Майкрософт, т.е. у них — один программный код работает с раздельными данными и сбой в работе кода ведет к сбою работы со всеми данными. И в самом плачевном случае — сбою всей системы. Поэтому при установке ПО ОС надо перезагружать. Поэтому и вечные проблемы с надежностью работы.
                                                                                В *nix-ах каждый код работает со своими данными — что и дает надежность.


                                                                                Что понимается под кодом, работающим с «раздельными» данными, и что понимается под «своими» данными. И что понимается под кодом в данном случае. И как сбой в работе «кода» приводит к «сбою работы со всеми данными».
                                                                                  +1
                                                                                  Я вот это не могу осознать

                                                                                  Кажется, проблема тут не у вас.
                                                                                    +1
                                                                                    Радует, что я не один такой.
                                                                        0
                                                                        Что-то я ничего не понял.

                                                                        у них — один программный код работает с раздельными данными и сбой в работе кода ведет к сбою работы со всеми данными


                                                                        Что под этим понимается? Какой код, с какими данными? Что понимается под «раздельными» данными? Процессы изолированы друг от друга, в общем случае они друг на друга не влияют, поэтому падение одного никак не трогает другие. Синий экран — ошибка в ядре (или в драйвере, так как они работают в одном АП с ядром).

                                                                        В *nix-ах каждый код работает со своими данными — что и дает надежность.

                                                                        Что понимается под «своими» данными?

                                                                        В докере идея в том, что каждый процесс считает, что он единственный запущен, хотя на самом деле их может быть много, точно также, как ОС в виртуальный машине считает, что она работает на голом железе и больше никто на этом железе не работает. Отличие в том, что докер «недо-виртуализует» окружение, все процессы работают на физическом процессоре и напрямую читают/пишут в физическую память, не обращаясь сначала к виртуальной машине. С точки зрения хостовой ОС — это просто процессы, которыми она управляет, как ей привычно.
                                                                          +4
                                                                          Гуманитарии в треде
                                                                      +2
                                                                      Любопытно, как люди обычно делают security update для OS которые используются как базовый образ для Docker?

                                                                      т.е. есть у тебя ~100 контейнеров унаследованных от образа, к примеру Ubuntu LInux 16.04.
                                                                      Тут появляется 0-day уязвимость, надо обновить образ операционной системы.

                                                                      Правильно ли я понимаю что тогда будет нужно пересобрать все контейнеры Docker и перезапустить их все с пересобранного образа?
                                                                        0
                                                                        Можно вставить какой-нибудь apt-get upgrade прямо в свой Dockerfile.
                                                                        В случае уязвимости — просто пересобрать образ (он при этом обновится), перезалить его в регистри и, да, перезапустить все контейнеры.
                                                                        Для этого, кстати, иногда настраивают крон, который периодически проверяет наличие новых версий образа в регистри и, если находит, то делает обновление самостоятельно. Так удобно делать, если серверов много.
                                                                          0
                                                                          > Можно вставить какой-нибудь apt-get upgrade прямо в свой Dockerfile.

                                                                          Что не рекомендуется авторами докера: https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/#/apt-get
                                                                            0
                                                                            Да, это так.
                                                                            Авторы докера еще не рекомендуют запускать в контейнере более одного процесса.
                                                                            А вот эти авторы очень популярного base image другого мнения.

                                                                            У любого решения есть плюсы и минусы. Взвешивать их и принимать решения только тому, кто несёт ответствнность за результат.
                                                                          0
                                                                          Я тоже так понял. Пересобираешь — перезапускаешь… Ну и при сборке я делаю apt-get update / upgrade, хотя на этот счет есть мнение, что чем компактнее контейнер, там он эффективнее.
                                                                            0
                                                                            Вот тут отличный разбор на Ваш вопрос. Тема поднята не раз и всех волнует
                                                                              –1
                                                                              Докер — это отличная возможность переложить проблемы поддержания актуальных версий системных библиотек (того же самого libssl) с поставщиков ОС и сисадминов на никого


                                                                              Разве это не организационный вопрос? Пусть тот же сисадмин следит за актуальностью образов.
                                                                                +1
                                                                                В начале статьи вы писали, что докер решает проблему сложности установки программного обеспечения. Но оказывается что для секьюрити фиксов все таки нужен админ который обновит образ. А если в процессе apt-get upgrade в контейнере что то сломается, опять же нужно кому то чинить — опять же нужен админ.
                                                                                Итого мы приходим что все таки нам нужен админ который теперь вместо того чтоб разбираться с правилами сборки пакетов под используемый дистрибутив и построения единообразной системы, будет заниматься изучением чьих то контейнеров.

                                                                                Кроме того, если практически во всех дистрибутивах есть средства для мониторинга устаревшего/уязвимого ПО, как это делать в случае повсеместного использования контейнеров — не понятно, опять же доставлять нужное ПО в контейнеры? Или пересобирать все образы самому? Тогда в чем профит?

                                                                                  0
                                                                                  Профит в том, что теперь этот админ может сидеть у меня в офисе, а ранее он должен был иметь доступ на все физические сервера моих клиентов.
                                                                                    0
                                                                                    Зачем apt-get upgrade в контейнере делать? Пакеты ставятся в процессе сборки имаджа, в контейнере запускается только то что нам нужно (например веб-сервер) и ничего более. Если в контейнере что-то сломалось, то его никто не чинит, его просто убивают и запускают новый, так же как с упавшим/зависшим процессом.

                                                                                    Кроме того, если практически во всех дистрибутивах есть средства для мониторинга устаревшего/уязвимого ПО, как это делать в случае повсеместного использования контейнеров — не понятно, опять же доставлять нужное ПО в контейнеры? Или пересобирать все образы самому?

                                                                                    Пересобирать самому. Это не сложнее чем просто поставить новый пакет на машине. В принципе можно использовать те же средства для автоматического мониторинга и внутри контейнера, но хз… я бы не хотел чтоб у меня на live машине что-то само переустанавливалось.

                                                                                    А админ нужен, да, куда без него…
                                                                                      0
                                                                                      Зачем apt-get upgrade в контейнере делать?


                                                                                      Здесь речь шла о закрытии уязвимостей, иже такие обнаружатся в используемом вами образе.
                                                                                        0
                                                                                        А, ну лучше новый имадж собрать, запустить новый контейнер, старый потом кильнуть. Zero-downtime, все дела…
                                                                                0
                                                                                Важный момент тут. Дырка в системе-образе не особенно важна, поскольку сама эта система не запускается.
                                                                                Процесс докера работает а host-системе и взаимодействует с ядром host-системы.
                                                                                Проблемой может быть только такая уязвимость, благодаря которой уязвимым станет сам бинарник процесса еще на этапе сборки.
                                                                                0
                                                                                Кстати наверняка тот же puppet или fabric можно подружить с докером и развёртывание проектов станет еще проще! =)
                                                                                  0
                                                                                  Вот тут рекомендуют «дружить» докер с ansible.
                                                                                    0
                                                                                    Ну так статья на сайте ansible =) Было бы удивительно, если бы они предложили дружить докер с паппетом.

                                                                                    А за статью отдельно — большое спасибо!
                                                                                      0
                                                                                      Я к тому, что подобные мысли уже кто-то пытается реализовать.
                                                                                  0
                                                                                  14 сентября кстати будет meet up на тему Docker for developers от vJUG, детали: https://www.meetup.com/virtualJUG/events/232887371/
                                                                                    0
                                                                                    Кучу статей читал про докер, но так и не понял имеет ли смысл использовать его в продакшене? Не привнесет ли простота контейнирезации какие-то дополнительные проблемы администрирования и стабильности системы? Все очень часто пишут, как докер помогает им при тестировании или разработки, но очень редко кто-то пишет про то, как он использовал докер на продакшен серверах. А из того, что я видел, это были какие-то очень специфичные случаи с кучей костылей для нормальной работы.
                                                                                      0
                                                                                      Вот тут писали
                                                                                        0
                                                                                        Ну про это я как раз и говорил. Им там вроде пришлось очень много сделать поверх докера, чтобы действительно запустить его в продакшен. И если каждому, кто захочет использовать докер на боевых серверах, придется проходить через все это, то это звучит довольно пугающе.
                                                                                          0
                                                                                          Ну у них и масштабы серьезные. 300 миллионов конейнеров подразумевают какие-то дополнительные усилия.
                                                                                      +1
                                                                                      Пользуясь случаем, хочу
                                                                                      Кто-нибудь смог TensorFlow запустить под докером? Хоть убейте не пойму как это работает, и главное — почему оно должно работать!
                                                                                      https://www.tensorflow.org/versions/r0.10/get_started/os_setup.html#docker-installation
                                                                                      Контейнер успешно скачивается и деплоится, сервер блокнота доступен на нужном порту.
                                                                                      Вопрос:
                                                                                      На шаге https://www.tensorflow.org/versions/r0.10/get_started/os_setup.html#test-the-tensorflow-installation
                                                                                      Open a terminal and type the following
                                                                                      Я терминал должен где открыть? На машине на своей? С какой стати у меня питон должен знать, что такое tensorflow, tf же контейнирезован?!?!?!
                                                                                      Поймите, простите за оффтоп, помогите.
                                                                                      Спасибо.
                                                                                        +1
                                                                                        Может имеется ввиду терминал в контейнере?
                                                                                        Обычно он открывается так:
                                                                                        docker exec -it {имя конейнера} bash
                                                                                          0
                                                                                          Блин, офигеть как это неочевидно
                                                                                            +1
                                                                                            Ну это претензия к авторам инструкции.
                                                                                            так то:
                                                                                            docker, выполни итеративно в контейнере ИМЯ bash
                                                                                              0
                                                                                              Клево, работает, спасибо!
                                                                                                0
                                                                                                Пожалуйста!
                                                                                          +1
                                                                                          del
                                                                                            +1
                                                                                            И еще можно в веб интерфейс:sudo docker run -it -p 8888:8888 tensorflow/tensorflow:0.10.0 -> http://127.0.0.1:8888/tree -> кнопка New -> Terminal
                                                                                              0
                                                                                              Тоже работает, но не так красиво :-)
                                                                                            0
                                                                                            Насчет «плюс докера — нет vendor-lock-in»: никакого противоречия тут не замечаете? 8-)
                                                                                            Хотя лично мне докер очень нравится.
                                                                                            но вот этот самый vendor-lock-in…
                                                                                              0
                                                                                              Vendor lock in обычно означает привязку к коммерческому продукту. Или к продукту, контролируемому узкой группой лиц.
                                                                                              Докер — бесплатный, с открытыми исходниками, предоставляется по лицензии Apache 2.
                                                                                              То есть vendor lock in здесь такой же, как при использовании Linux.
                                                                                              0
                                                                                              А что насчёт kubernetes?
                                                                                                0
                                                                                                То же, что и насчет ansible или puppet.
                                                                                                Их проблема в исполнении кастомного кода во время установки.
                                                                                                Это — бОльшая хрупкость, по сравнению с докером у которого кастомный установочный код выполняется во время сборки образа.
                                                                                                В первом случае для устранения сбоев при установке нужен доступ на production.
                                                                                                Во втором сбои устраняются заранее во время сборки образа.

                                                                                                Другими словами, первая группа инструментов отправляет в продакшен код, который должен там исполниться в незнакомой среде хост системы.
                                                                                                Докер отправляет в продакшен заранее собранный процесс и требуемые ему данные. Здесь нет стадии исполнения кода во время установки. А нет исполнения — нет ошибок.
                                                                                                  0
                                                                                                  Эмм. kubernetes работает с docker-образами.
                                                                                                    0
                                                                                                    Вы правы. Я ошибся.
                                                                                                    Тогда отвечу так: я понятия не имею :)
                                                                                                0
                                                                                                Докер для ХР\2003 существует?
                                                                                                  0
                                                                                                  Только в виде виртуальной машины с линуксом.
                                                                                                  0
                                                                                                  Если приложение упаковано в docker, насколько больше оперативки оно начинает потреблять?
                                                                                                  Нужен ли будет более мощный сервер, или можно будет по-прежнему на крохотных vps-ках держать какие-то сервисы?
                                                                                                  (У некоторых проектов, к примеру у sentry, рекомендуемый способ установки теперь уже через docker, а классический уже как бы почти deprecated)
                                                                                                    +1
                                                                                                    Не намного. Хотя вот сам докер демон тоже что-то съест.
                                                                                                    Вот тут, например, обсуждают мажину с 12гб памяти 12 свопа, где запущено 183 контейнера и там докер съел 5гб виртуальной памяти.

                                                                                                    Вообще, процесс докера работает через cgroups и использует системные вызовы ядра хост системы. Он не тащит с собой дополнительный линукс в свою память.
                                                                                                      0
                                                                                                      Спасибо!
                                                                                                    +1
                                                                                                    Можно практический пример, как лучше всего быть, если хочется использовать docker для заворачивания в контейнер какой-нибудь СУБД (например, PostgreSQL)? Где в этом случае должны лежать файлы с данными базы? Если внутри контейнера, тогда теряются все преимущества легкого развертывания (потому что база же исчезнет). Если снаружи, тогда придется как-то ими управлять (и что делать в случае физической смерти железного сервера — неясно), т.е. теряются преимущества docker-а по масштабированию и обновлению.

                                                                                                    Такое ощущение, что со stateless-сервисами (типа веб-серверов) сравнительно легко что с docker, что без docker. А вот что делать со stateful?
                                                                                                      +1
                                                                                                      У докера есть понятие томов (volumes). Вы можете объявить volume в докер файле.
                                                                                                      Как то так:

                                                                                                      VOLUME ["/opt/tomcat/logs"]

                                                                                                      Данные, сохраненные контейнером в эту директорию не будут удалены вместе с контейнером.
                                                                                                      Можно также мэпить тома на директории host системы.
                                                                                                      0
                                                                                                      Вопрос для использующих контейнеры (и докер в частности).
                                                                                                      Насколько я понял, концепт упирается на т.н. микросервисы: не нужно упаковывать всю систему в один контейнер (иначе разница с полноценной виртуальной машиной невелика), а запускать интеграцию, например, из трех контейнеров: веб-сервер+приложение, сервер приложений и СУБД.
                                                                                                      В статьях увлекательно пишут, о том, что если это работало на машине разработчика, то без изменений будет крутиться в эксплуатации.
                                                                                                      Первый вопрос, параметры системы (речь о системе уровня небольшой ERP) у разработчика, у испытателей и в эксплуатации у клиентов принципиально разные, поскольку разные цели. Как это совместить?
                                                                                                      Второй вопрос, какой смысл упаковывать в контейнер терабайтную… ладно, даже 50 Гб базу данных?
                                                                                                      Третий вопрос, с какого масштаба системы докер становится бесполезен и использование полноценной виртуальной среды (а то и физической) становится выгоднее (могу ошибаться, но у меня есть подозрения на уровень LAMP-приложения до 100К строк кода и 100 таблиц в БД)?
                                                                                                      Спасибо за пояснения на реальных примерах.
                                                                                                        0
                                                                                                        Первый вопрос:

                                                                                                        Да, тут немного лукавят. Обычно через переменные окружения передаются такие параметры. Например, количество памяти, которое может использовать сервис в проде и в тестовой среде обычно отличаются. Однако, отличия почти всегда сводятся к ограничениям ресурсов, налагаемых на проект в тестовом окружении. Что позволяет делать вывод: работает в тестовом окружении, значит заработает и в проде с очень высокой вероятностью

                                                                                                        Второй вопрос:

                                                                                                        Ответ — никакого. Так никто и не делает. Данные вообще не пакуют в контейнеры, так как они не должны уничтожаться при уничтожении контейнеров. Для данных есть volumes.

                                                                                                        Третий вопрос:

                                                                                                        Вот тут habrahabr.ru/post/247969 описывали довольно масштабное использование докера. Я с таким сам не сталкивался.

                                                                                                        Но вот по сравнению с виртуальной машиной, контейнеризация докера скорее выигрывает в performance. В докере все процессы на самом деле работают в host системе, используя механизм cgroups. Накладных расходов там меньше, чем в виртуалках.
                                                                                                          0
                                                                                                          Тестовых и приемочных сред должно быть несколько, все они с разными целями и, соответственно, с разными параметрами окружения. Например, нагрузочное тестирование ориентировано на время отклика, приемочные тесты ориентированы на функционал. В эксплуатации несколько мелких клиентов будут использовать один сервер и разделяемое хранилище данных, крупный — выделенный кусок этого хранилища и несколько серверов. Как при этом контейнеризация поможет быстрее доставить продукт клиенту не вполне ясно.

                                                                                                          Если данные живут отдельно от контейнеров, можно ли вообще говорить об идентичности окружения? Разница уровня одной строки в таблице параметров может полностью менять поведение системы.

                                                                                                          Если докер работает в виртуальной среде, как он может быть быстрее непосредственной работы приложения в этой среде? Каждый уровень виртуализации, пусть даже тонкий, только снижает производительность.

                                                                                                      Only users with full accounts can post comments. Log in, please.