Я сознательно опускаю некоторые технические подробности, а кое где допускаю упрощения. Если вы увидите, что 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)
Выводы
Таким образом докер очень хорошо подходит для решения перечисленных выше задач:
- удобная передача серверного проекта клиенту
- обеспечение тиражируемости серверов
- обеспечение переиспользуемости ранее созданных серверных конфигураций
Отдельно хочу отметить, что докер также крайне удобен для обновления ранее установленных версий продукта и для создания тестовых серверов, полностью идентичных «натуральным».
Комментарии (154)
Vjatcheslav3345
09.09.2016 09:07А история изменений хранится (как в системах версий)?
softaria
09.09.2016 09:13+1Если вы о возможности сравнить два образа, то такого нет. Образы — это бинарные файлы. Неясно как их сравнивать.
Здесь логичнее хранить Dockerfile в какой-то системе контроля версий.
Из него всегда можно сделать образ. И тут история изменний будет прозрачна.
hudson
09.09.2016 10:53Судя по тому как это делают на dockerhub — используются таги, кроме того есть некий аналог git — образы можно push'ить, ну а когда собирается контейнер, образы соответственно pull'ятся…
Я тоже пока не эксперт, но стараюсь локальную разработку переводить на докер, есть и кое-что в продакшене.
Рекомендую сразу использовать docker-compose — отличная вещь!softaria
09.09.2016 10:57некий аналог git
Это и есть docker registry. Я писал о ней в статье.
Но историю изменений там не увидишь. Можно просто хранить несколько версий одного образа, назначая версию вручную, при помощи тэга.Vjatcheslav3345
09.09.2016 15:11Кстати, я вот когда заходил на сайты с архивами LaTex, R, Ada, Sage и что то не заметил использования предлагаемых пользователям контейнеров докера — только обычные образы нашел и виртуальные машины — нет ли тут скрытых камней, на которые можно напороться, из за которых образы-контейнеры докера не используются?
feudorsam
10.09.2016 04:33гит сравнивает изменения только в текстовых файлах, поэтому сравнения сомнительны
pavlovdo
09.09.2016 10:04По поводу решения проблем — вы забыли упомянуть о системах управления конфигурациями — Puppet, Ansible и т.д.
Отлично справляются с проблемами тиражируемости серверовsoftaria
09.09.2016 10:27Я отнёс их к скриптам. Потому что они запускают свои сценарии непосредственно на серверах, на которые делается установка.
В этом смысле, они подвержены тем же проблемам. Хотя, конечно, они лучше справляются с задачей, чем самописные shell скрипты.kir_vesp
09.09.2016 12:03Мне кажется вы несколько путаете их цели. Докер для виртуализации конкретных приложений, Ansible — для первичной установки и настройки того, что должно быть вне контейнеров.
softaria
09.09.2016 12:05Ничего не имею против такого использования.
Мне не нравится только использование ansible, puppet и т п в качестве единсвенного средства deployment-a.river-fall
10.09.2016 07:43Видимо, вы не сталкивались вплотную с настройкой configuration management в puppet / chef. В отличие от «одноразовых» stateful скриптов конфигурации puppet/chef описывают не что сделать с системой, а какой она _должна_ быть (записи в конфигурационных файлах, состояние сервисов, наличие пользователей и т.п.)
Поэтому, в теории, любой сломанный пользовательский сервер на котором что-то случилось, puppet/chef приведет в эталонное рабочее состояние (обычное использование — синхронизация раз в час и принудительный возврат всех измененных параметров в эталонные значения).
В этом смысле использование Configuration management более «дуракоупорное», чем docker — он сам себя чинит.
Неспроста огромное количество программного обеспечения распространяется через chef-solo (дистрибутив и настройщик в одном флаконе)softaria
10.09.2016 07:50Разница здесь в том, что puppet/chef запускает на продакшен серверах команды, чтобы добиться там появления кастомной конфигурации, созданной пользователем.
Эта задача заведомо более сложная, чем то, что делает докер — тупо запускает заранее подготовленные процессы — никакой кастомной логики во время установки не выполняется.
Другими словами, в случае с паппетом есть чему ломаться во время установки на продакшен.
В случае с докером поломки будут не во время установки, а во время сборки образа. То есть для их устранения не нало иметь доступ на production server.
pmcode
09.09.2016 10:27+1Скажите, пожалуйста, правильно ли я понял, что если у нас есть, например, LAMP стек, то каждый серверный процесс этого стека можно запускать в отдельном контейнере? Т.е. вообще говоря, например, контейнер базы данных потом можно обновлять независимо.
Также очень любопытно как докер взаимодействует с файрволом домашней ОС. Ну, например, в контейнере висит Postgre на порту 5432. В домашней ОС этот процесс биндится на тот же порт?softaria
09.09.2016 10:311) Вы поняли правильно
2) Здесь все сложнее. По умолчанию докер создает виртуальную сеть для каждого контейнера. Если использовать docker compose, то его умолчание — виртуальная сеть, в которой каждый контейнер будет хостом. Можно управлять виртуальными сетями гибко. А можно и вовсе их отключить и заставить все контейнеры напрямую использовать сеть хоста.
В последнем случае порты окажутся в общем адресном пространстве. Но так тоже делают, когда очен важен performance. Виртуальная сеть докера может добавить задержку до 70мс.softaria
09.09.2016 10:38Ошибся тут: По умолчанию докер создает виртуальную сеть для каждого контейнера
На самом деле умолчания у докера и docker-compose одинаковы: виртуальная сеть, в которой каждый контейнер будет хостом
pmcode
09.09.2016 11:31Большое спасибо за подробный ответ. Из всего сказанного мне кажется, что Docker также это и реально крутой способ развертывания development окружения для разработчика. Например, можно быстро попробовать свое приложение с разными DBMS. Также, если надо отладить взаимодейсткие с какой-то внешней системой, можно держать ее минимальный рабочий прототип в виде подключаемого контейнера.
softaria
09.09.2016 11:34Docker также это и реально крутой способ развертывания development окружения для разработчика
Да. И даже более того.
Некоторые считают, что сам deployment вообще исчезнет, как отдельный процесс.
Dockerfile будет создаваться в процессе разработки.
Образы будут сразу тестироваться а потом, как есть отправляться в production.
Звучит интересно.jazzl0ver
12.09.2016 13:15+1Расскажите, а какой best practice в данном случае для замены конфигов с девелоперских на те, которые должны работать в проде? Отличия могу быть, например, в:
— разных паролях и хостах с БД
— разных требованиях к памяти и CPU affinity (например, на dev'е nginx работает в минимальной конфигурации на 2-х ядрах, а в проде ему надо выдать кучу памяти и 16 ядер)
— запрете разработчикам подключаться к прод-серверам (т.е. другие имена/пароли/ключи локальных пользователей системы)softaria
12.09.2016 15:58разных паролях и хостах с БД
Здесь проще всего задать пароль, имя пользователя, хост и имя базы данных переменными окружения, передаваемыми самому контейнеру с СУБД. Так, чтобы они совпали с вашими.
разных требованиях к памяти и CPU affinity
Здесь обычно создаётся volume с конфигурацией, этот volume мэпится на директорию хост системы и там конфигурация правится руками. Некоторые параметры тоже можно передавать переменными окружения. Другой вариант — отнаследовать production image от development image и поменять там конфигурацию, просто перекрыв её новой при помощи директивы COPY.
запрете разработчикам подключаться к прод-серверам
Тут даже не скажу. Я написал «некоторые считают, что deployment исчезнет», но это не значит, что он уже исчез конкретно у нас.
Думаю, можно поступить также, как с конфигурацией, вынесенной на отдельный volume. Или опять отнаследовать образ.
Но сам я такого не делал.
softaria
09.09.2016 11:39И еще одно интересное применение. Один из важных компонентов одного из наших проектов делается территориально удаленной командой разработчиков. Компонент написан на c++ и собирается под определенной версией linux.
До применения докера мы тратили массу времени на интеграцию этого компонента.
То авторы добавили новую зависимость, которой у нас нет и которая конфликтует с чем-то еще на нашем сервере.
То их бинарник просто почему-то не запускается, а при попытке сборки из сорцов вылетает ошибка компиляции.
Теперь они предоставляяют этот компонент, как докер image. Проблем больше нет. Вообще.
LbISS
09.09.2016 10:31Спасибо, наглядно для тех, кто никогда не сталкивался.
Сразу вопрос — у нас большая часть приложений на стеке Microsoft. Умеет ли с ним работать docker?Encarmine
09.09.2016 11:22+1Microsoft реализовала поддержку docker-контейнеров в Windows Server 2016. В превью уже можно пощупать. Приятно то, инструментарий работает как с *nix так и с windows хостами. Жалко только образы должны быть с соответствующей операционной системой.
kir_vesp
09.09.2016 12:06Надо понимать важный момент. В основе докера изначально лежит технология LXC, что подразумевает необходимость линукса и, соответственно, для разных ОС будут и разные, несовместимые образы. В основе докера для винды лежит технология hyper-v и некоторое кол-во костылей для получений специфичных особенностей ядра линукса.
softaria
09.09.2016 12:08LbISS а вопрос был не про запуск образа винды в докере? Или я неверно вас понял?
LbISS
09.09.2016 17:36Да, вы правильно поняли. Сейчас у нас коробочный продукт на ASP.Net, который приходиться разворачивать на огромном количестве серверов каждый раз с нуля. Естественно, сейчас это происходит на Windows Server. Если образ винды в докере получится развернуть под линуксом и он будет хорошо работать — вполне себе вариант хотя бы для новых клиентов.
f0rk
09.09.2016 18:13Не получится. Docker под линуксом может запускать только процессы способные работать под линуксом.
softaria
09.09.2016 18:15А вот тут про что? (Сам я не знаю, но выглядит так, будто МС что-то такое делает)
f0rk
09.09.2016 18:21Видимо про windows контейнеры на windows хосте.
softaria
09.09.2016 18:22Похоже на то. Но они используют там докер.
f0rk
09.09.2016 18:27Ну, если ядро винды может предоставить тот же api и те же возможности что и линукс, то почему нет, но запускать он очевидно сможет только windows процессы.
softaria
09.09.2016 18:30Вроде бы LbISS именно это и нужно.
Только, оно пока выглядит недоделанным. Но раз МС взялась, возможно сделают.f0rk
09.09.2016 18:50Если образ винды в докере получится развернуть под линуксом и он будет хорошо работать — вполне себе вариант хотя бы для новых клиентов
Я написал, что не получится так.softaria
09.09.2016 18:53Точно. Так не получится — невнимательно прочитал. Но и винда в винде может оказаться неплохим вариантом.
ashvik
09.09.2016 10:32-7Может я тут плохо понял — но чем ЭТО принципиально отличается от подхода в винде с работой связки код-данные? (один код — разные данные). Откуда в основном и проблемы у них растут с «падением» и «синими экранами»…
softaria
09.09.2016 10:32+3Не понял ваш вопрос. Поясните подробнее.
ashvik
09.09.2016 11:39-3Ну ниже подняли практический вопрос из моего теоретического.
Поясняю — по статье выходит, что данная система по принципу построения мало отличается от принципа построения ОС от Майкрософт, т.е. у них — один программный код работает с раздельными данными и сбой в работе кода ведет к сбою работы со всеми данными. И в самом плачевном случае — сбою всей системы. Поэтому при установке ПО ОС надо перезагружать. Поэтому и вечные проблемы с надежностью работы.
В *nix-ах каждый код работает со своими данными — что и дает надежность.
То, что описано в статье, на мой взгляд — попытка привнести неудачный подход в надежности работы системы.
Ниже уже утверждается — да — надо перезагружаться при обновлениях, да — влияет на работоспособность всех зависимых контейнеров.
Мое мнение — этот инструмент больше подходит для тестировщиков (где надо промоделировать схожие ситуации в работе ПО и/или собрать статистику), чем для внедрения в реальные системы.softaria
09.09.2016 11:45+1Не вижу почему в докере код работает не со своими данными.
да — надо перезагружаться при обновлениях
А если вы обновили скажем tomcat, postgre или ваш собственный код БЕЗ докера, то перегружаться не надо?
Host систему никто не перегружает. А перезапуск контейнера делается очень быстро. Контейнеры вообще быстры и легковесны. По сравнению с native процессами penalty составляет 1-2%
да — влияет на работоспособность всех зависимых контейнеров
Напрямую не влияет. Они изолированы. Влияет в то же степени, в которой остановка сервера управления базой данных повлияет на приложение, которое его использует.ashvik
09.09.2016 12:43-1А если вы обновили скажем tomcat, postgre или ваш собственный код БЕЗ докера, то перегружаться не надо?
нет — не надо — во всяком случае пока этот код работает с этими данными — код будет работать, а вот при следующем вызове запустится уже обновленный новый экземпляр кода. И да — в системе могут работать сразу два кода. Даже ядро так работает. И да — даже при обновлении ядра не надо перезагружать всю систему (ну уж если не совсем все поменяли).
Это все уже давно-давно есть в *nix-ах.
Влияет в то же степени, в которой остановка сервера управления базой данных повлияет на приложение, которое его использует.
Ну и чем это не подход от МС — сбой в работе с данными приводит к сбою приложения (и соответственно с другими данными)?
Так что нового и удобного дает докер для «нетестировщиков»?softaria
09.09.2016 12:51И да — в системе могут работать сразу два кода
Как вы себе представляете работу сразу двух application серверов в одной системе? Как они порты поделят, например? А если они еще и данные кэшируют? А если новая версия приложения вносит изменения в схему базы данных?
сбой в работе с данными приводит к сбою приложения
Давайте уточним терминологию. Что вы называете «данными»? Неужели docker image? Или что?
На всякий случай: для хранения persistent данных в докере используются volumes. Данные хранятся отдельно от контейнеров и сохраняются при рестарте или обновлении. Docker image — это не данные. Это, если хотите — параметризованный код.
Iora
09.09.2016 12:55Что вы вообще понимаете под «кодом» и «данными»?
а вот при следующем вызове запустится уже обновленный новый экземпляр кода. И да — в системе могут работать сразу два кода. Даже ядро так работает. И да — даже при обновлении ядра не надо перезагружать всю систему (ну уж если не совсем все поменяли).
Вы про hot-reload что ли?ashvik
09.09.2016 13:52-1код — то, что передается на исполнение (команда процессору)
данные — то, над чем оперирует код (информация)
холодная перезагрузка — перезагрузка системы при помощи аппаратного механизма (железо)
горячая перезагрузка (hot-reload) — перезагрузка системы при помощи команды (кода) процессору
то о чем я писал — обновление и запуск ядра системы «не лету» — без перезагрузок вообще.
Насколько я понимаю — докер хранит и использует разность кода от базового образа как свои данные, которые передает на исполнение. Фактически контейнер это разностная копия данных. Так?
Также получается, что сбой в организации хранения и вызова данных для исполнения контейнера (докера) может привести к сбою работы других контейнеров — это как раз пример
Влияет в то же степени, в которой остановка сервера управления базой данных повлияет на приложение, которое его использует.
То есть при «падении» докера — «упадут» и все контейнеры — со всеми своими пользовательскими приложениями и данными? И времени до «падения» будет ровно столько, пока к докеру не обратится.
От чего зависит в итоге конечный пользователь:
Зависимость от хост-системы,
зависимость от докера,
зависимость от изначального образа для контейнера
зависимость от настройки контейнера,
зависимость настройки конечного ПО в контейнере
Сравните с работой при использовании гипервизора (который намного легче и проще хост-системы — а значит и надежнее)
В итоге:
Это более надежная система? Нет. Удобная по быстроте разворачивания? Да.
Т.е. область применения — девелоперы и тестировщики.softaria
09.09.2016 14:13Фактически контейнер это разностная копия данных. Так?
Нет. Union FS работает не так.
То есть при «падении» докера — «упадут» и все контейнеры — со всеми своими пользовательскими приложениями и данными?
Тоже нет. Процессы продолжат работать даже если упадет docker daemon.
Зависимость от хост-системы
Минимальна. В идеале её нет вовсе.
зависимость от докера
Да. Докер контейнеры зависят от докера. Если бы докер был ненадежным или некачественным продуктом, это было бы важным аргументом против.
зависимость от настройки контейнера
Как эта зависимость влияет на надежность? Настройка конейнера не может «упасть» и потянуть за собой какие-то проблемы. Настройка контейнера — это конфигурация.
зависимость настройки конечного ПО в контейнере
То есть ваше ПО зависит от его настройки. Неудивительно.
При этом докер как раз сильно снижает количество проблем такого рода, позволяя проверить ваш контейнер заранее точно в таком же окружении, в котором ему предстоит работать.ashvik
09.09.2016 14:35-1Нет. Union FS работает не так.
По приведенной ссылке — именно так — с построением древовидной структуры и приоритетом доступа.
Тоже нет. Процессы продолжат работать даже если упадет docker daemon.
пока не надо будет к нему обратится, а обратится надо будет — если вдруг перезапуск системы или сверка с изначальным образом, или чтение конфигурации…
Зависимость от хост-системы
Минимальна. В идеале её нет вовсе.
не надо лукавить — докер — одино из приложений в хост-системе — со всеми вытекающими
Если бы докер был ненадежным или некачественным продуктом, это было бы важным аргументом против.
Сбои происходят с любым ПО — насколько часто — это зависит от многих факторов. Я указал что это еще один уровень в возможном сбое. То же относится и настройке конечного ПО — это уровень возможного отказа (сбоя).
позволяя проверить ваш контейнер заранее точно в таком же окружении
В итоге мы пришли к мнению о применении у тестировщиках и девелоперах. Пользователям незачем проверять работу приложения — пользователям надо чтобы оно уже работало.softaria
09.09.2016 14:44Вы критикуете докер за то, что он добавляет в систему сложность, а значит и дополнительные места для сбоев. Это, в принципе верно.
Только в этом плане гипервизор — предмет для точно такой же критики.
Любое добавление сложности добавляет и хрупкость.
Вопрос всегда в том ради чего идти на такое усложнение и насколько качественна добавляющая сложность вещь.
В итоге мы пришли к мнению о применении у тестировщиках и девелоперах. Пользователям незачем проверять работу приложения — пользователям надо чтобы оно уже работало.
Мало смысла использовать докер для тестировщиков, если потом не запускать тот же самый образ в production. Получится тестировали одно, а работает другое.ashvik
09.09.2016 14:48ну тогда нет логики в написании отдельного ПО как такового — сразу надо с ОС поставлять — но так же не делают — верно?
softaria
09.09.2016 14:51сразу надо с ОС поставлять — но так же не делаю — верно?
По сути, докер так и делает :)
А вообще ситуации бывают разные. Я начал статью с типовых ситуаций, где докер применять есть смысл.
Совершенно очевидно, что в массе других ситуаций докер не нужен, а нужно как раз «отдельное ПО».
f0rk
09.09.2016 14:58Вы похоже слабо представляете себе область применения докера. При разработке больших веб-сервисов и всяких сложных систем, например для телекомов или банков, могут не то что ОС поставлять, могут целое облако в эксплуатацию отдавать, с кучей машин, специфически настроенных ОС и сотнями взаимодействующих между собой приложений. Когда стоит именно такая задача — докер один из отличных инструментов для ее решения.
ashvik
09.09.2016 15:20-1Строго говоря для надежности сложная система должна иметь несколько автономных (и/или дублированных-троированных) узлов (в идеале все — что экономически не выгодно) для гарантированного выполнения своих задач.
Докер же как мне представляется, делает с точностью до наоборот — все сводится к полной централизации. Т.е.придется прилагать усилия для обеспечения его надежной работы, а также используемых линий связи — в сложных и распределенных системах.softaria
09.09.2016 15:23Если и есть централизация, то только в рамках одного физического сервера.
Так можно упрекнуть в полной централизации и операционную систему.ashvik
09.09.2016 15:32-1Можно. ОС — это и есть централизованное управление доступом к конкретным аппаратным ресурсам. И ее надежность по сравнению с гипервизором ниже. Поэтому его (гипервизор) и используют для повышения надежности — убирают слой прикладного ПО на более высокий уровень. Ну для надежности еще и дублируют (создают кластеры).
EvilShadow
13.09.2016 20:00> Тоже нет. Процессы продолжат работать даже если упадет 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, увы, по-прежнему нет.softaria
13.09.2016 20:10Если вы честно выключаете докер, то так оно и будет.
Но попробуйте убить его процесс через
kill -9
Дети останутся. Так же они останутся, если докер демон закрэшится из-за внутренней ошибки. Именно об этом шла речь.EvilShadow
13.09.2016 20:50Да, это так. Только остаются они только до тех пор, пока докер не запустится вновь (например, через docker.socket). При запуске он чистит старые контейнеры и благополучно убивает процессы, не запуская новых (что ожидаемо, ведь для них не установлен restart policy). Это недопустимо.
Вдобавок, проблема не в том, что докер может упасть. Мне ещё не встречались падения его на ровном месте, поэтому в этом плане можно считать его достаточно надёжным. Проблема в обновлениях самого докера, к примеру, из системных пакетов, при котором происходит стандартный рестарт. С убийством детей.
Докер берёт на себя роль супервизора процессов. Апофеоз такого подхода — RancherOS, где systemd заменен на докер. Я бы не рискнул использовать это в продакшене. Просто потому, что при всём уважении к труду авторов докера, он не может сравниться с инструментом, который специально создан для управления всеми системными процессами.softaria
14.09.2016 09:07+1Разумеется, докер — не универсальное решение любой задачи.
Но есть задачи, где его вполне можно использовать в production.
Сам по себе он обновляться не будет. Ничто не мешает включить restart policy.
Iora
09.09.2016 14:16hot-reload с точки зрения ПО — замена исполнимого кода без остановки приложения. Erlang так умеет, например.
Сравните с работой при использовании гипервизора (который намного легче и проще хост-системы — а значит и надежнее)
Работая на более низком уровне гипервизор НАМНОГО сложнее чем докер. И требования к надежности гипервизова намного выше. Так как при ошибке в докере упадет конкретный контейнер (наверно, я не знаю, кто знает — поправьте), а при ошибке в гипервизоре у вас упадет все, что выше него: хост-система(ы), докер и все остальное.
Докер, к слову, работает за счет механизмов ОС, поэтмоу его надежность упрощенно можно приравнять надежности самой ОС.ashvik
09.09.2016 14:47-1Работая на более низком уровне гипервизор НАМНОГО сложнее чем докер
Ничего удивительного — гипервизор реально управляет системой (ее основными функциями), а докер — всего лишь приложение и много чего передает для отработки хост-системе и работает в принципе из-под нее (с меньшим приоритетом)
И поэтому его надежность выносится отдельно от надежности хост-системы. Упрощенно.
Iora
09.09.2016 14:20холодная перезагрузка — перезагрузка системы при помощи аппаратного механизма (железо)
горячая перезагрузка (hot-reload) — перезагрузка системы при помощи команды (кода) процессору
Холодная перезагрузка и горячая отличаются тем, что при «горячей» не производится проверка памяти, так как она была проверена при холодной, за счет чего ПК загружается быстрее. В большинстве случаев, простая перезагрузка ПК будет как раз-таки горячей. Полное выключение и последующий запуск — тоже, в каком-то смысле холодная перезагрузка. Reload и Restart, это, кстати, разные вещи.ashvik
09.09.2016 14:42я добавлю и больше — при горячей и память может не очищается — и в общем-то зависит от конкретной реализации железа. Уж не говорю о том что с портами и периферией происходит. Неизменно одно — процессор начинает работу с «нуля».
f0rk
09.09.2016 14:46код — то, что передается на исполнение (команда процессору)
данные — то, над чем оперирует код (информация)
Ок, теперь объясните:
1. что такое «свои» данные и чем они отличаются от «не своих»
2. Что означает ваша фраза:
в системе могут работать сразу два кода.
докер хранит и использует разность кода от базового образа как свои данные, которые передает на исполнение.
Ну… очень корявая формулировка, но направление мысли примерно правильное. Docker image хранит слои файловой системы с нужным конкретному процессу набором файлов. В таком же смысле можно сказать что любая ОС «хранит и использует разность кода от базового образа (свежеустановленного) как свои данные, которые передает на исполнение».
Фактически контейнер это разностная копия данных. Так?
Нет, контейнер — это процесс(ы) запущенный в и изолированном окружении, которое предоставляет image.
Также получается, что сбой в организации хранения и вызова данных для исполнения контейнера (докера) может привести к сбою работы других контейнеров
Какого рода «сбой»? Что такое «организация хранения и вызова данных»? Если вы о файловой системе контейнера, то нет, проблемы одного контейнера никак не повлияют на остальные.
То есть при «падении» докера — «упадут» и все контейнеры — со всеми своими пользовательскими приложениями и данными?
Вроде бы с версии 1.12.0 контейнеры должны спокойно относиться к рестартам docker демона, в любом случае, хороший контейнер должен быть stateless и ему должно быть наплевать на то перезагружают его или нет. Пользовательские данные хранить в контейнере не нужно.
И времени до «падения» будет ровно столько, пока к докеру не обратится.
Эту фразу я вообще не понял
гипервизора (который намного легче и проще хост-системы — а значит и надежнее)
В каком смысле он легче и проще? Вы теплое с мягким сравниваете, гипервизора работает поверх хост системы. В этом смысле докер легче и проще, тк по сути предоставляет средства изоляции на уровне ядра ОС хост системы. Как раз гипервизор менее надежен, тк его падение гарантированно уюивает все виртуальные машины.
Это более надежная система? Нет. Удобная по быстроте разворачивания? Да.
Более надежная и удобная по быстроте чем что?
Т.е. область применения — девелоперы и тестировщики.
Неверноashvik
09.09.2016 15:03-11. что такое «свои» данные и чем они отличаются от «не своих»
Извините, но тут уж должен направить на изучение работы процессора в защищенном режиме (хотя бы в общих чертах)
2. Что означает ваша фраза:
в системе могут работать сразу два кода.
А здесь к общим понятием запуска и работы процессов (кода) в *nix системах.
гипервизора работает поверх хост системы.
Извините — но это Вы путаете понятие гипервизора и систему виртуализации.
Чтобы попроще — гипервизор устанавливается на железо, система виртуализации — на хост-систему. И тут гипервизор более надежен — т.к. у него меньше код, а значит и меньше верятность сбоя.Также гипервизор не работает с пользовательским ПО — он работает с системным ПО — его надежность намного выше, чем хост-системы.
Более надежная и удобная по быстроте чем что?
Чем стандартно установленная ОС.
f0rk
09.09.2016 15:57Извините, но тут уж должен направить на изучение работы процессора в защищенном режиме (хотя бы в общих чертах)
Извините, но ответ не принимается, к контексту нашей беседы защищенный режим никакого отношения не имеет. Вы противопоставляли операционки МС и *nix, по-вашему что, в винде процессы в реальном режиме работают?
А здесь к общим понятием запуска и работы процессов (кода) в *nix системах.
Тут видимо отсылка к многозадачности, ну так я вас удивлю, в винде тоже реализованна такая абстракция как процесс и есть в наличии средства управления процессами и многозадачность.
Извините — но это Вы путаете понятие гипервизора и систему виртуализации.
Это одно и то же, гипервизоры бывают как реализованные поверх железа так и поверх ОСи, но эта деталь никак не влияет на тот факт, что падение гипервизора приведет к падению всех гостевых операционок.
Ну и по поводу «направления на изучение», вы несете бред и демонстрируете полное непонимание темы, лучше бы уж помолчали, чем направлять меня куда-то, потому что выглядит это глупо и смешно :)ashvik
09.09.2016 16:24-1Т.е. Вы утверждаете что докер работает на любой архитектуре железа и напрямую к процессору не обращается? В статье и комментариях утверждается обратное.
Насчет ОС от МС — по умолчанию (для оптимизации использования памяти) ОС делает интересные «финты» с кодом и данными — и надо использовать доп системные утилиты и настройки чтобы использовать возможность действительно независимого использования кода и данных.
ну так я вас удивлю, в винде тоже реализованна такая абстракция как процесс
Да не надо меня удивлять — просто внимательно прочитайте свои же слова.
И про гипервизоры — ну хоть википедию почитайте внимательнее что-ли.
ОФФ И кстати — переход на личности, и личные характеристики говорит о невозможности аргументировать свою точку зрения и отсутствию самой возможности конструктивного решения нашего спора. Не любите критику — лучше молчите.softaria
09.09.2016 16:27В статье и комментариях утверждается обратное.
Где именно в статье утверждется обратное?ashvik
09.09.2016 17:05вот в комментах
f0rk
докер легче и проще, тк по сути предоставляет средства изоляции на уровне ядра ОС хост системы.
«Уровень ядра» — это прямое обращение к аппаратуре — т.к. у ядра ОС наивысший приоритет обычно.softaria
09.09.2016 17:06А таки в статье где?
ashvik
09.09.2016 17:20Но при этом все процессы докера работают на физическом host сервере деля все процессоры и всю доступную память. Подход, используемый докером находится посередине между запуском всего на физическом сервере и полной виртуализацией,
softaria
09.09.2016 17:23Возможно, я неточно выразился. Но имел ввиду: деля все процессоры и всю доступную память со всеми другими процессами, запущенными в host системе.
f0rk
09.09.2016 17:14Ок, уточню формулировку. Docker — это тула, которая позволяет удобно использовать средства изоляции на уровне ядра ОС хост системы, такие как cgroups. Сам докер естественно работает в user space.
ashvik
09.09.2016 17:33ну вот — наконец место в хост-системе определили.
Далее — что произойдет если докер упадет?
Из обсуждений ниже и этой фразы выходит что, докер посредством cgroups запускает на исполнение образ системы с изменениями взятыми из конфига для контейнера?
Этот код независим уже или все-таки управляется докером?
Как это работает с распределенной сложной системой? Типа удаленной загрузки?softaria
09.09.2016 17:38Докер запускает не образ системы с изменениями, а просто образ. Что там в нём будет определяется вашим Dockerfile.
Из конфига для контейнера берутся переменные окружения и некоторые параметры определяющие, как именно стартовать контейнер.
Код независим. Но процесс является child-ом от докеровского демона.
Докер может этот процесс остановить (послав ему SIGTERM, а если не реагирует то просто убить)
Если докеровский демон умрёт, контейнеры станут сиротами (orphan) со всеми вытекающими.
softaria
09.09.2016 17:39Как это работает с распределенной сложной системой? Типа удаленной загрузки?
А вот это поясните, пожалуйста. На первый взгляд кажется, что это вообще не относится к делу.ashvik
09.09.2016 17:55Сформулирую по другому — существует ли у докера возможность работать с несколькими физическими серверами — т.е. своя система репликации образов систем и контейнеров? Или все ограничивается одним сервером с его ФС?
softaria
09.09.2016 17:58существует ли у докера возможность работать с несколькими физическими серверами
Существует. Но это — самостоятельный продукт. Docker swarm
Обычный докер работает в рамках одного физического сервера.
f0rk
09.09.2016 18:10Далее — что произойдет если докер упадет?
Насчет падения не уверен, на моей практике он ни разу не падал, но скорее всего если его получится сразу рестартануть, ничего плохого не случится, хотя могут быть и траблы с доступом к контейнерам по сети. Если контейнеры запущены с --net=host и работают с сетевыми интерфейсами хоста, то вероятность проблем меньше. Но это мои предположения, их нужно проверять. Просто рестарт демона контейнеры переживают без проблем, по сути, контейнеризованные процессы — такие же полноценные процесы в рамках ОС, просто разбитые по namespace.
докер посредством cgroups запускает на исполнение образ системы
Не совсем понятно, что вы имеете в виду под «образом системы». Докер запускает процесс в хост системе, этот процесс использует ядро хост системы для системных вызовов, по сути разница с обычным процессом в том, что он не видит файловую систему хоста и не видит остальные процессы запущенные вне его контейнера.
с изменениями взятыми из конфига для контейнера
Эту часть не понял, что вы подразумеваете под «конфигом для контейнера»?
Этот код независим уже или все-таки управляется докером?
Процесс в контейнере независим настолько, насколько независим любой дочерний процесс.
Как это работает с распределенной сложной системой?
На каждом хосте должен быть свой демон, контейнеры могут общаться через overlay network, можете тут почитать
f0rk
09.09.2016 16:36И про гипервизоры — ну хоть википедию почитайте внимательнее что-ли
Вот картинка из Википедии:
невозможности аргументировать свою точку зрения
То что вы абсолютно не разбираетесь в теме настолько очевидно, что у меня нет никакой необходимости что либо аргументировать, я кстати могу нести полнейшую чушь и все равно будет смешно :)Iora
09.09.2016 16:41Так если посмотреть, то в комментариях есть одна главная тема — вот эта и пара более мелких, где народ хоть как-то обсуждает докер.
ashvik
09.09.2016 17:10Хорошо. Признаю свою ограниченную точку зрения на виды гипервизоров. Хотя я пользовался другими статьями при определении виртуализации ОС.
я кстати могу нести полнейшую чушь и все равно будет смешно :)
я рад что Вы весело провели времяf0rk
09.09.2016 17:19я рад что Вы весело провели время
А я рад, что вы готовы расширять свой кругозор :)
ashvik
09.09.2016 16:07-1В таком же смысле можно сказать что любая ОС «хранит и использует разность кода от базового образа (свежеустановленного) как свои данные, которые передает на исполнение».
Ваше утверждение не верно.
Образ системы — это сохраненная копия кода и (возможно) данных на определенный момент времени. Как правило для его создания используются сторонние инструменты, т.к. обычно ОС имеет наивысший приоритет выполнения и не дает доступа к критическому коду.
Даже в обычном ПК (с х86 архитектурой) код ОС не изменяется произвольно. Я уж не говорю о других системах (ну навскидку были процессоры PowerMac или реализации суперЭВМ, встроенные системы) — для изменения кода требовался особый алгоритм и средства.
К тому что Вы описали больше подходят системы с произвольно изменяемой архитектурой к созданию которых только подошли, и в какой-то мере нейросистемы.Iora
09.09.2016 16:10были процессоры PowerMac
А можно подробнее про них? Я о таких к своему стыду не слышал.ashvik
09.09.2016 16:30-1Извините, ошибся — это были компьютеры от Apple на базе PowerPC ()
В данном контексте упомянул, т.к. в них аппаратно была разделена память программ (для кода) и память данных. (надо заметить что зависали они тоже довольно часто, но все же меньше чем с х86 архитектурой). В принципе подобных подход в архитектуре наблюдаем в микроконтроллерах.Iora
09.09.2016 16:35Это называется Гарвардская Архитектура.
надо заметить что зависали они тоже довольно часто, но все же меньше чем с х86 архитектурой
Чтож от них отказались, раз они так хороши?
Насколько я помню, кэш L1 в x86 тоже разделяет код и данные.ashvik
09.09.2016 16:50-1деньги направляют. В какой-то момент в Apple решили что свои процессоры выпускать — себе дороже и перешли на x86. Ну и Intel тоже давил конкурентов. Сейчас вот все больше начинают переходить на ARM, т.к. х86 уже не дает нужных результатов.
Насколько я помню, кэш L1 в x86 тоже разделяет код и данные.
Не совсем так. Он хранит их отдельно — соответственно к частоте обращений. Ну и при многоядерности и/или эмуляции многоядерности — это дает неплохой прирост производительности.
f0rk
09.09.2016 16:16Даже в обычном ПК (с х86 архитектурой) код ОС не изменяется произвольно.
Когда-то давно (я еще зеленым школьником был) у меня было хобби компилять ядро для слаки, так вот, что-то не припомню, чтоб мой пень (с х86 архитектурой) как-то противился таким экспериментам.ashvik
09.09.2016 16:33в данном случае Вы запускали минимальное ядро — производили компляцию кода под свое железо, и при перезагрузке уже запускали полученный код. Конечно все это вообще работало через BIOS — или его Вы тоже произвольно меняли? Прям во время работы системы?
f0rk
09.09.2016 12:55+2Что вы несете? Я ничего не понял…
Iora
09.09.2016 12:56Давайте коллективно выясним, о чем речь. Я тоже ничего не понял. Код, данные, два кода (почему не три?) свои не свои данные. Бред какой-то.
f0rk
09.09.2016 13:01Может я тут плохо понял
Я думаю, что предположение из первого коммента в ветке верное.Iora
09.09.2016 13:04Я вот это не могу осознать:
Поясняю — по статье выходит, что данная система по принципу построения мало отличается от принципа построения ОС от Майкрософт, т.е. у них — один программный код работает с раздельными данными и сбой в работе кода ведет к сбою работы со всеми данными. И в самом плачевном случае — сбою всей системы. Поэтому при установке ПО ОС надо перезагружать. Поэтому и вечные проблемы с надежностью работы.
В *nix-ах каждый код работает со своими данными — что и дает надежность.
Что понимается под кодом, работающим с «раздельными» данными, и что понимается под «своими» данными. И что понимается под кодом в данном случае. И как сбой в работе «кода» приводит к «сбою работы со всеми данными».
Iora
09.09.2016 12:53Что-то я ничего не понял.
у них — один программный код работает с раздельными данными и сбой в работе кода ведет к сбою работы со всеми данными
Что под этим понимается? Какой код, с какими данными? Что понимается под «раздельными» данными? Процессы изолированы друг от друга, в общем случае они друг на друга не влияют, поэтому падение одного никак не трогает другие. Синий экран — ошибка в ядре (или в драйвере, так как они работают в одном АП с ядром).
В *nix-ах каждый код работает со своими данными — что и дает надежность.
Что понимается под «своими» данными?
В докере идея в том, что каждый процесс считает, что он единственный запущен, хотя на самом деле их может быть много, точно также, как ОС в виртуальный машине считает, что она работает на голом железе и больше никто на этом железе не работает. Отличие в том, что докер «недо-виртуализует» окружение, все процессы работают на физическом процессоре и напрямую читают/пишут в физическую память, не обращаясь сначала к виртуальной машине. С точки зрения хостовой ОС — это просто процессы, которыми она управляет, как ей привычно.
jakshi
09.09.2016 10:53+2Любопытно, как люди обычно делают security update для OS которые используются как базовый образ для Docker?
т.е. есть у тебя ~100 контейнеров унаследованных от образа, к примеру Ubuntu LInux 16.04.
Тут появляется 0-day уязвимость, надо обновить образ операционной системы.
Правильно ли я понимаю что тогда будет нужно пересобрать все контейнеры Docker и перезапустить их все с пересобранного образа?softaria
09.09.2016 10:55Можно вставить какой-нибудь apt-get upgrade прямо в свой Dockerfile.
В случае уязвимости — просто пересобрать образ (он при этом обновится), перезалить его в регистри и, да, перезапустить все контейнеры.
Для этого, кстати, иногда настраивают крон, который периодически проверяет наличие новых версий образа в регистри и, если находит, то делает обновление самостоятельно. Так удобно делать, если серверов много.EvilShadow
13.09.2016 19:47> Можно вставить какой-нибудь apt-get upgrade прямо в свой Dockerfile.
Что не рекомендуется авторами докера: https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/#/apt-getsoftaria
13.09.2016 19:53Да, это так.
Авторы докера еще не рекомендуют запускать в контейнере более одного процесса.
А вот эти авторы очень популярного base image другого мнения.
У любого решения есть плюсы и минусы. Взвешивать их и принимать решения только тому, кто несёт ответствнность за результат.
hudson
09.09.2016 10:56Я тоже так понял. Пересобираешь — перезапускаешь… Ну и при сборке я делаю apt-get update / upgrade, хотя на этот счет есть мнение, что чем компактнее контейнер, там он эффективнее.
k3NGuru
09.09.2016 11:45Вот тут отличный разбор на Ваш вопрос. Тема поднята не раз и всех волнует
softaria
09.09.2016 11:48-1Докер — это отличная возможность переложить проблемы поддержания актуальных версий системных библиотек (того же самого libssl) с поставщиков ОС и сисадминов на никого
Разве это не организационный вопрос? Пусть тот же сисадмин следит за актуальностью образов.interrupt
09.09.2016 15:35+1В начале статьи вы писали, что докер решает проблему сложности установки программного обеспечения. Но оказывается что для секьюрити фиксов все таки нужен админ который обновит образ. А если в процессе apt-get upgrade в контейнере что то сломается, опять же нужно кому то чинить — опять же нужен админ.
Итого мы приходим что все таки нам нужен админ который теперь вместо того чтоб разбираться с правилами сборки пакетов под используемый дистрибутив и построения единообразной системы, будет заниматься изучением чьих то контейнеров.
Кроме того, если практически во всех дистрибутивах есть средства для мониторинга устаревшего/уязвимого ПО, как это делать в случае повсеместного использования контейнеров — не понятно, опять же доставлять нужное ПО в контейнеры? Или пересобирать все образы самому? Тогда в чем профит?
softaria
09.09.2016 15:38Профит в том, что теперь этот админ может сидеть у меня в офисе, а ранее он должен был иметь доступ на все физические сервера моих клиентов.
f0rk
09.09.2016 16:10Зачем apt-get upgrade в контейнере делать? Пакеты ставятся в процессе сборки имаджа, в контейнере запускается только то что нам нужно (например веб-сервер) и ничего более. Если в контейнере что-то сломалось, то его никто не чинит, его просто убивают и запускают новый, так же как с упавшим/зависшим процессом.
Кроме того, если практически во всех дистрибутивах есть средства для мониторинга устаревшего/уязвимого ПО, как это делать в случае повсеместного использования контейнеров — не понятно, опять же доставлять нужное ПО в контейнеры? Или пересобирать все образы самому?
Пересобирать самому. Это не сложнее чем просто поставить новый пакет на машине. В принципе можно использовать те же средства для автоматического мониторинга и внутри контейнера, но хз… я бы не хотел чтоб у меня на live машине что-то само переустанавливалось.
А админ нужен, да, куда без него…
hudson
09.09.2016 10:57Кстати наверняка тот же puppet или fabric можно подружить с докером и развёртывание проектов станет еще проще! =)
sainnr
09.09.2016 12:3914 сентября кстати будет meet up на тему Docker for developers от vJUG, детали: https://www.meetup.com/virtualJUG/events/232887371/
kolchan11
09.09.2016 16:00Кучу статей читал про докер, но так и не понял имеет ли смысл использовать его в продакшене? Не привнесет ли простота контейнирезации какие-то дополнительные проблемы администрирования и стабильности системы? Все очень часто пишут, как докер помогает им при тестировании или разработки, но очень редко кто-то пишет про то, как он использовал докер на продакшен серверах. А из того, что я видел, это были какие-то очень специфичные случаи с кучей костылей для нормальной работы.
softaria
09.09.2016 16:01Вот тут писали
kolchan11
09.09.2016 16:38Ну про это я как раз и говорил. Им там вроде пришлось очень много сделать поверх докера, чтобы действительно запустить его в продакшен. И если каждому, кто захочет использовать докер на боевых серверах, придется проходить через все это, то это звучит довольно пугающе.
softaria
09.09.2016 16:43Ну у них и масштабы серьезные. 300 миллионов конейнеров подразумевают какие-то дополнительные усилия.
imwode
09.09.2016 16:45+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 же контейнирезован?!?!?!
Поймите, простите за оффтоп, помогите.
Спасибо.softaria
09.09.2016 16:48+1Может имеется ввиду терминал в контейнере?
Обычно он открывается так:
docker exec -it {имя конейнера} bash
mgremlin
09.09.2016 19:36Насчет «плюс докера — нет vendor-lock-in»: никакого противоречия тут не замечаете? 8-)
Хотя лично мне докер очень нравится.
но вот этот самый vendor-lock-in…softaria
09.09.2016 19:44Vendor lock in обычно означает привязку к коммерческому продукту. Или к продукту, контролируемому узкой группой лиц.
Докер — бесплатный, с открытыми исходниками, предоставляется по лицензии Apache 2.
То есть vendor lock in здесь такой же, как при использовании Linux.
3al
09.09.2016 22:38А что насчёт kubernetes?
softaria
10.09.2016 07:55То же, что и насчет ansible или puppet.
Их проблема в исполнении кастомного кода во время установки.
Это — бОльшая хрупкость, по сравнению с докером у которого кастомный установочный код выполняется во время сборки образа.
В первом случае для устранения сбоев при установке нужен доступ на production.
Во втором сбои устраняются заранее во время сборки образа.
Другими словами, первая группа инструментов отправляет в продакшен код, который должен там исполниться в незнакомой среде хост системы.
Докер отправляет в продакшен заранее собранный процесс и требуемые ему данные. Здесь нет стадии исполнения кода во время установки. А нет исполнения — нет ошибок.
vsvasya
10.09.2016 05:45Если приложение упаковано в docker, насколько больше оперативки оно начинает потреблять?
Нужен ли будет более мощный сервер, или можно будет по-прежнему на крохотных vps-ках держать какие-то сервисы?
(У некоторых проектов, к примеру у sentry, рекомендуемый способ установки теперь уже через docker, а классический уже как бы почти deprecated)softaria
10.09.2016 07:38+1Не намного. Хотя вот сам докер демон тоже что-то съест.
Вот тут, например, обсуждают мажину с 12гб памяти 12 свопа, где запущено 183 контейнера и там докер съел 5гб виртуальной памяти.
Вообще, процесс докера работает через cgroups и использует системные вызовы ядра хост системы. Он не тащит с собой дополнительный линукс в свою память.
DmitryKoterov
11.09.2016 14:58+1Можно практический пример, как лучше всего быть, если хочется использовать docker для заворачивания в контейнер какой-нибудь СУБД (например, PostgreSQL)? Где в этом случае должны лежать файлы с данными базы? Если внутри контейнера, тогда теряются все преимущества легкого развертывания (потому что база же исчезнет). Если снаружи, тогда придется как-то ими управлять (и что делать в случае физической смерти железного сервера — неясно), т.е. теряются преимущества docker-а по масштабированию и обновлению.
Такое ощущение, что со stateless-сервисами (типа веб-серверов) сравнительно легко что с docker, что без docker. А вот что делать со stateful?softaria
11.09.2016 15:45+1У докера есть понятие томов (volumes). Вы можете объявить volume в докер файле.
Как то так:
VOLUME ["/opt/tomcat/logs"]
Данные, сохраненные контейнером в эту директорию не будут удалены вместе с контейнером.
Можно также мэпить тома на директории host системы.
nikolayvaganov
Даже если контейнер на сервере один docker-compose позволяет забыть про поиск параметров запуска текущего контейнера и отказаться от «history | grep docker».
Также я бы рекомендовал ( а может и посоветуют мне? =) ) отказаться от хранения рабочих файлов и конфигов внутри докер контейнеров и мапить их с самого сервера. Почему:
1. Чтобы изменить файл, нужно зайти сначала на сервер, потом сделать docker exec, изменить файл, выйти и закоммитить контейнер. А если у нас какой-нибудь легкий alpine образ, а не FROM: ubuntu:16.04, то это становится огромной проблемой.
2. При обновлении контейнера не нужно думать, что что-то в процессе обновления пойдет не так. Мы просто обновляем докер образ, убиваем контейнер, создаем заново из композа и вуаля, новый обновленный контейнер без лишних хлопот.
Deosis
В случае отдельного файла конфигурации контейнер придётся стартовать в среднем два раза, второй с мыслью «опять забыл конфиг добавить»
hudson
Я сейчас конфиги как volumes добавляю. Вроде жизнеспособный вариант:
volumes: - .:/opt/project - .docker/app/parameters.yml:/opt/project/app/config/parameters.ymldarken99
Обычно вопрос конфигурации решают через environment variables, особенно это актуально в облачных деплойментах, где смонтировать файл в контейнер может быть большой проблемой