24 марта 2015 в 15:22

Понимая Docker из песочницы

Уже несколько месяцев использую docker для структуризации процесса разработки/доставки веб-проектов. Предлагаю читателям «Хабрахабра» перевод вводной статьи о docker — «Understanding docker».

Что такое докер?


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

В своем ядре docker позволяет запускать практически любое приложение, безопасно изолированное в контейнере. Безопасная изоляция позволяет вам запускать на одном хосте много контейнеров одновременно. Легковесная природа контейнера, который запускается без дополнительной нагрузки гипервизора, позволяет вам добиваться больше от вашего железа.

Платформа и средства контейнерной виртуализации могут быть полезны в следующих случаях:
  • упаковывание вашего приложения (и так же используемых компонент) в docker контейнеры;
  • раздача и доставка этих контейнеров вашим командам для разработки и тестирования;
  • выкладывания этих контейнеров на ваши продакшены, как в дата центры так и в облака.

Для чего я могу использовать docker?


Быстрое выкладывание ваших приложений


Docker прекрасно подходит для организации цикла разработки. Docker позволяет разработчикам использовать локальные контейнеры с приложениями и сервисами. Что в последствии позволяет интегрироваться с процессом постоянной интеграции и выкладывания (continuous integration and deployment workflow).

Например, ваши разработчики пишут код локально и делятся своим стеком разработки (набором docker образов) с коллегами. Когда они готовы, отравляют код и контейнеры на тестовую площадку и запускают любые необходимые тесты. С тестовой площадки они могут оправить код и образы на продакшен.

Более простое выкладывание и разворачивание


Основанная на контейнерах docker платформа позволят легко портировать вашу полезную нагрузку. Docker контейнеры могут работать на вашей локальной машине, как реальной так и на виртуальной машине в дата центре, так и в облаке.

Портируемость и легковесная природа docker позволяет легко динамически управлять вашей нагрузкой. Вы можете использовать docker, чтобы развернуть или погасить ваше приложение или сервисы. Скорость docker позволяет делать это почти в режиме реального времени.

Высокие нагрузки и больше полезных нагрузок


Docker легковесен и быстр. Он предоставляет устойчивую, рентабельную альтернативу виртуальным машинам на основе гипервизора. Он особенно полезен в условиях высоких нагрузок, например, при создания собственного облака или платформа-как-сервис (platform-as-service). Но он так же полезен для маленьких и средних приложений, когда вам хочется получать больше из имеющихся ресурсов.

Главные компоненты Docker


Docker состоит из двух главных компонент:
  • Docker: платформа виртуализации с открытым кодом;
  • Docker Hub: наша платформа-как-сервис для распространения и управления docker контейнерами.

Примечание! Docker распространяется по Apache 2.0 лицензии.

Архитектура Docker


Docker использует архитектуру клиент-сервер. Docker клиент общается с демоном Docker, который берет на себя тяжесть создания, запуска, распределения ваших контейнеров. Оба, клиент и сервер могут работать на одной системе, вы можете подключить клиент к удаленному демону docker. Клиент и сервер общаются через сокет или через RESTful API.





Docker-демон


Как показано на диаграмме, демон за пускается на хост-машине. Пользователь не взаимодействует с сервером на прямую, а использует для этого клиент.

Docker-клиент


Docker-клиент, программа docker — главный интерфейс к Docker. Она получает команды от пользователя и взаимодействует с docker-демоном.

Внутри docker-а


Чтобы понимать, из чего состоит docker, вам нужно знать о трех компонентах:
  • образы (images)
  • реестр (registries)
  • контейнеры


Образы


Docker-образ — это read-only шаблон. Например, образ может содержать операционку Ubuntu c Apache и приложением на ней. Образы используются для создания контейнеров. Docker позволяет легко создавать новые образы, обновлять существующие, или вы можете скачать образы созданные другими людьми. Образы — это компонента сборки docker-а.

Реестр


Docker-реестр хранит образы. Есть публичные и приватные реестры, из которых можно скачать либо загрузить образы. Публичный Docker-реестр — это Docker Hub. Там хранится огромная коллекция образов. Как вы знаете, образы могут быть созданы вами или вы можете использовать образы созданные другими. Реестры — это компонента распространения.

Контейнеры


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

Так как же работает Docker?


Пока мы знаем, что:
  • можем создавать образы, в которых находятся наши приложения;
  • можем создавать контейнеры из образов, для запуска приложений;
  • можем распространять образы через Docker Hub или другой реестр образов.

Давайте посмотрим, как эти компоненты сочетаются.

Как работает образ?


Мы уже знаем, что образ — это read-only шаблон, из которого создается контейнер. Каждый образ состоит из набора уровней. Docker использует union file system для сочетания этих уровней в один образ. Union file system позволяет файлам и директориями из разных файловых систем (разным ветвям) прозрачно накладываться, создавая когерентную файловую систему.

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

В основе каждого образа находится базовый образ. Например, ubuntu, базовый образ Ubuntu, или fedora, базовый образ дистрибутива Fedora. Так же вы можете использовать образы как базу для создания новых образов. Например, если у вас есть образ apache, вы можете использовать его как базовый образ для ваших веб-приложений.

Примечание! Docker обычно берет образы из реестра Docker Hub.

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


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


Эти инструкции хранятся в файле Dockerfile. Docker считывает это Dockerfile, когда вы собираете образ, выполняет эти инструкции, и возвращает конечный образ.

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


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

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

Docker Hub предоставляет публичные и приватные хранилища образов. Поиск и скачивание образов из публичных хранилищ доступно для всех. Содержимое приватных хранилищ не попадает в результат поиска. И только вы и ваши пользователи могут получать эти образы и создавать из них контейнеры.

Как работает контейнер?


Контейнер состоит из операционной системы, пользовательских файлов и метаданных. Как мы знаем, каждый контейнер создается из образа. Этот образ говорит docker-у, что находится в контейнере, какой процесс запустить, когда запускается контейнер и другие конфигурационные данные. Docker образ доступен только для чтения. Когда docker запускает контейнер, он создает уровень для чтения/записи сверху образа (используя union file system, как было указано раньше), в котором может быть запущено приложение.

Что происходит, когда запускается контейнер?


Или с помощью программы docker, или с помощью RESTful API, docker клиент говорит docker демону запустить контейнер.

$ sudo docker run -i -t ubuntu /bin/bash

Давайте разберемся с этой командой. Клиент запускается с помощью команды docker, с опцией run, которая говорит, что будет запущен новый контейнер. Минимальными требованиями для запуска контейнера являются следующие атрибуты:
  • какой образ использовать для создания контейнера. В нашем случае ubuntu
  • команду которую вы хотите запустить когда контейнер будет запущен. В нашем случае /bin/bash


Что же происходит под капотом, когда мы запускаем эту команду?

Docker, по порядку, делает следующее:
  • скачивает образ ubuntu: docker проверяет наличие образа ubuntu на локальной машине, и если его нет — то скачивает его с Docker Hub. Если же образ есть, то использует его для создания контейнера;
  • создает контейнер: когда образ получен, docker использует его для создания контейнера;
  • инициализирует файловую систему и монтирует read-only уровень: контейнер создан в файловой системе и read-only уровень добавлен образ;
  • инициализирует сеть/мост: создает сетевой интерфейс, который позволяет docker-у общаться хост машиной;
  • Установка IP адреса: находит и задает адрес;
  • Запускает указанный процесс: запускает ваше приложение;
  • Обрабатывает и выдает вывод вашего приложения: подключается и логирует стандартный вход, вывод и поток ошибок вашего приложения, что бы вы могли отслеживать как работает ваше приложение.

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

Используемые технологии


Докер написан на Go и использует некоторые возможности ядра Linux, чтобы реализовать приведенный выше функционал.

Пространство имен(namespaces)


Docker использует технологию namespaces для организации изолированных рабочих пространств, которые мы называем контейнерами. Когда мы запускаем контейнер, docker создает набор пространств имен для данного контейнера.

Это создает изолированный уровень, каждый аспект контейнера запущен в своем простанстве имен, и не имеет доступ к внешней системе.

Список некоторых пространств имен, которые использует docker:
  • pid: для изоляции процесса;
  • net: для управления сетевыми интерфейсами;
  • ipc: для управления IPC ресурсами. (ICP: InterProccess Communication);
  • mnt: для управления точками монтирования;
  • utc: для изолирования ядра и контроля генерации версий(UTC: Unix timesharing system).


Control groups (контрольные группы)


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

Union File System


Union File Sysem или UnionFS — это файловая система, которая работает создавая уровни, делая ее очень легковесной и быстрой. Docker использует UnionFS для создания блоков, из которых строится контейнер. Docker может использовать несколько вариантов UnionFS включая: AUFS, btrfs, vfs и DeviceMapper.

Форматы контейнеров


Docker сочетает эти компоненты в обертку, которую мы называем форматом контейнера. Формат, используемый по умолчанию, называется libcontainer. Так же docker поддерживает традиционный формат контейнеров в Linux c помощью LXC. В будущем Docker возможно будет поддерживать другие форматы контейнеров. Например, интегрируясь с BSD Jails или Solaris Zones.
@LiSiCin
карма
15,0
рейтинг 0,0
Похожие публикации
Самое читаемое Администрирование

Комментарии (62)

  • +1
    «Docker делает это с помощью легковесной платформы контейнерной виртуализации»
    Сложно назвать всё это «легковесным», когда ваш образ базируется на какой-нибудь убунте. Не всегда возможно использовать что-то лёгкое вроде busybox. Да даже с его использованием может статься, что сам контейнер использует намного больше ресурсов, нежели само приложение.

    p.s. для диплоя приложений/сервисов рекомендую пользоваться не голым докером, а чем-то поверх него. Kubernetes, например, или Apache mesos+марафон.
    • 0
      безусловно. Сам пользуюсь mcloud. Цель статьи введение в понятийный уровень.
    • 0
      Легковесность тут имемтся ввиду по отношению к виртуальныйм машинам.
      • 0
        И к весу клонирования. Каждый новый контейнер с Ubuntu будет отнимать совсем мало места.
  • +4
    Образ убунты для докера — 200 мегов.
    И в контейнере никакие сервисы сами по себе не стартуют, по сути ваше приложение — это init для контейнера.
    Так что не понятно, какие ресурсы может использовать контейнер сами по себе.

    Сложно назвать докер тяжелым если контейнер стартует меньше секунды.
    • 0
      команда докеру по созданию и запуску контейнера отрабатывает меньше секунды, подтверждаю, но сам контейнер (готовая виртуалочка) — в зависимости от бустрапа контейнера.
      • +5
        Все верно, но это же не относиться к контейнеру как к таковому!
        Это же ваше приложение, оно будет так-же стартовать и вне контейнера.

        Смысл «легкости» докера в том что оверхед минимален, в практической жизни — незаметен.

        • 0
          А я и не спорил с аргументом легкости )) вот прямо сейчас вожусь с ним
          Создаю из Dockerfile-а: дефолтовые настройки sshd + mysql + python = 360 MB.
          • 0
            Весь смысл в том, что это и так нужно в системе для работы приложения.

            А вот если контейнеры используют одну и ту-же начальную последовательность команд в Dockerfile то и получаемые в результате «слои» (т.е. по сути — файлы) будут одинаковые. Поэтому скажем контейнеры
            ubuntu + sshd + mysql и ubuntu + sshd + python (кстати полезно выносить базу в отдельный контейнер) будут отличаться только на последний слой, а слои ubuntu + sshd будут общими.

            Но опять-же это только особенности реализации, смысл легкости в том что в контейнере нет никаких системных служб, это практически ядро + ваше приложение.
            • 0
              Про БД согласен, но с одной поправкой — управлять связкой сервисов, который работает каждый в своем контейнере — это отдельная нетривиальная задача. ИМХО, поэтому, если количество сервисов ограничено — скажем в районе 5 — то отделять в индивидуальные контейнеры не обязательно. А если связка постоянно меняется и\или набор сервисов стабильно растет, то надо отдельно.
              • 0
                Все зависит не от количества сервисов, а от необходимости масштабирования (ну и изоляцию таки никто не отменял)

                Связка постоянно меняется — отлично — делаем кучу контейнеров и экспериментируем.

                Запуск пачки можно делать обычным bash-скриптом, что тут сложного — даже полезно.

                Ну и docker-compose (бывший fig) позволяет собирать связки легко и просто. Я лично использую make-файлы, make run и все :-)

          • +3
            В парадигме Докера было правильнее создать два контейнера мускул и питон.
            Вернее даже заюзать готовые из репы… А sshd вам не нужен в контехнерах.
            • 0
              Согласен
          • 0
            Я для себя вывел практическое правило (с редкими исключениями) — если мне хочется иметь ssh в Docker-контейнере, то я что-то делаю не так. И, скорее всего, мне нужен LXC :)

            Docker нужен чаще всего для массового запуска единообразных контейнеров. Которые хранят данные и настройки где-то снаружи. Иначе теряется эффективность, сильно усложняется массовое обновление и т.п. Если контейнер нужно настраивать индивидуально изнутри, то есть прекрасно заточенный под это дело LXC, работа с которым мало отличается от работы с отдельным компьютером.
            • +2
              Можно обойтись без ssh:

              docker exec -it some_runnig_container bash
              
              • 0
                Речь не о конкретном инструменте, а о подходе. Если хочется менять Docker-контейнер изнутри индивидуально, то с высокой вероятностью где-то в архитектуре проекта ошибка.
                • 0
                  а я использую exec для комманд, которые нужно исполнять в контейнере, очень удобно
    • 0
      Образ дэбиана 7.8 — вообще 120
      • +1
        Ну и что? это лишь место на диске…
        Выберете своим контейнерам базовый имидж и наследуйте от него и будут у вас эти 120 мб один раз на все контейнеры хоста на диске…
        Меняет погоду?
        • 0
          Чем больше образ => тем больше в нём файлов/пакетов => тем чаще они требуют обновлений => тем чаще вам нужно пересобирать свои образы.

          Используйте Alpine образ (недавно наконец его добавили в официальный) — 5МБ включает в себя busybox + apk пакетный менеджер. Так, например, dnsmasq образ, основанный на Alpine весит 6МБ. Вот это я понимаю, Докер-приложение, а когда для dnsmasq 100500 альтернативных образов лежит от убунты наследованных по 200МБ — это выше моего понимания. Другой пример: официальный образ python в Docker весит 750МБ(!), собранный мною из Alpine получается 46МБ со всеми потрохами.
          • +1
            Чем больше образ => тем больше в нём файлов/пакетов => тем чаще они требуют обновлений => тем чаще вам нужно пересобирать свои образы.

            Ну хорошо, в этом есть логика…
            Но только не совсем та что вы описываете…
            Нет Docker это не puppet — не нужно ему никаких обновлений часто… Вы любите докер за то что он позволяет вам выстроить ваш релизпайплан на базе Immutable images.
            Конечно у вас есть какая-то инфраструктура на которй бегут контейнеры, например кластер виртуальных машин. Вот там вы и беспокойтесь об очередном ssl heartbleed.
            А в контейнере вас совершенно не интересует, вышла ли новая версия vi или нет…
            Конечно и уровень приложений в контеэнре иноигда надфо обоновить иза внешних факторов… Но это как-бы не проблема размера имиджа…
            Если вы начинаете оптимировать размер базового имиджа, то значит можно позавидовать вашей прочей инфраструктуре ;)))
            • 0
              Я — перфекционист и это многое объясняет. На счëт обновлений — тем не менее базовые образы обновляются, хотим мы этого или нет и если не обновляться вслед за ними, то если у вас много своих образов наследованных от одного базового, но разного времени тухлости — докер вам никак место не сэкономит — вы вынуждены пересобирать свои образы. Обновления в LTS выходят только с исправлениями безопасности, например дырку в bash вы же захотите залатать?
              • 0
                Если перфекционист то, да начинайте оптимировать базовые имиджы ;)
                Я стараюсь прибывать в балансе между перфекционизмом и прагматизмом…
                Дырка в баше меня не интересует в контейнере в котором бежит какой-нибудь микросервис ничего не делающис с башем (у меня к примеру все такие ;))
                Но да если обновлять от разных базовых имиджей (и если вы подошли к вопросю серьезно то базовые имиджи ваши) вы имеете возможность ссылаться на конкретные весрии (это рекомендую)
                но даже если у вас будет на хосте рознящиеся aufs layers. Вы действительно беспокоитесь? Ну ок как перфекционист видимо да…
                Хорошо но это задача релизмэнедежмента а именно:
                1) с головой переезжать на новые версии
                2) чисть неиспользуемые имиджы на хостах… и что-бы ни гига лишнего не валялось ;)
                Вроде решаемо если так приспичило…
                Мне 1) важнее независимо от места на диске.
                • +1
                  А вот вам и статья для размышлений: Over 30% of Official Images in Docker Hub Contain High Priority Security Vulnerabilities. А вы говорите обновлять там нечего…

                  Просто если захотите посмотреть на мои поделки на Docker Hub: https://registry.hub.docker.com/repos/frolvlad/
                  • 0
                    Вы не понимаете…
                    Дело не в том что их нет.
                    А втом
                    Вам сравнительно пофиг на потенциальные nashvurnerabilities если ваш контейнер к примеру запускает маленький сервисе на яве.
    • 0
      Можно взять Ubuntu Core как базу, ну или самому debootstrap.

      У меня вот другой вопрос: Думаю уйти с openvz, насколько можно переползти с него в docker?
      Возникают вопросы с кластером :)
      • 0
        openvz это все-же больше «виртуалки» на базе контейнеров. А docker — это упаковка отдельных приложений и запуск их в контейнерах, причем с уклоном в immutable контейнеры.
      • 0
        Это инструменты под разные задачи, в общем-то.
        Можете посмотреть на CoreOS, в которой нет ничего кроме ssh и docker'а, все остальное только в docker контейнерах.

        в openvz — вы имеете нормальную виртуалку со всеми необходимыми процессами, в docker — вы имете один процесс с его детьми, например apache. докер — контейнер имени одного процесса, в отличие от полноценного lxc/openvz
        • 0
          Я прекрасно понимаю, что docker несколько иное чем openvz/lxc.
          Просто на текущий момент у меня все свелось к изоляции по процессам.
          Отдельно nginx, отдельно mysql, от дельно mongo итд.
          Просто например хотелось бы некоторых возможностей по миграции. Хотя вроде как все есть в монстре OpenStack.

          CoreOS отказалась кстати от Docker в пользу Rocket.
          • 0
            Да, я уже в курсе, спасибо
          • 0
            Docker — это не совсем «несколько иноче, чем LXC». Docker — это оберка над LXC для более удобной работы с ней
            • 0
              Docker начинал как обёртка над LXC, но уже год (?) как отвязался от последнего и работает с cgroups сам. Сейчас Docker и LXC — два независимых способа (разной идеологии) работать с cgroups-контейнерами.
  • +1
    регистр => реестр
    • 0
      спасибо. поправил.
  • –1
    Вижу много статей про докер, но пока не вижу применения докеру: простые приложения можно поднимать прямо на рабочей системе, благо префиксы к именам баз данных все cms ставить умеют. Если что-то сложное где требуется sphinx, mongo + опредленная верия php, то есть Vagrant. Если вы лепите сайты пачками поверх сложной конфигурации, то можно прикрутить Chef к вагранту. При этом у вас будет полноценная ВМ, которую можно будет передать разработчику с почти любой квалификацией. Буду рад, если кто-то доходчиво объяснит какие проблемы решает докер, которые не решает вагрант.
    • +1
      Предвидя ответ, что Vagrant это всё же полновесная виртуалка (против суперлегкого докера, который, к тому же, используется не для деплоя машины, но для деплоя конкретного приложения), все же присоединюсь к вопросу. Я как-то гуглил эту тему, пытаясь понять, а зачем мне, собственно, докер (есть стандартный набор, веб приложение + бд + кеш + нгинкс + job queue, поставил задачу задеплоить на staging/production и иметь похожую среду у всех разработчиков), и из-за малого количества конкретных примеров «как это делают профи и зачем это нужно» так на докере не остановился. Для моих задач хватило чистого Ansible'a, который разворачивает софт на удаленные машины без виртуализации и контейнеров. Собственно, вопрос в том, зачем нам, простым инженерам, это надо (и надо ли?) и как этот агрегат использовать в производстве. Кто-нибудь расскажет про use case?
      • 0
        Не то, чтобы я профи. Я определенно еще новичок в работе с докером, но… попробую ответить.

        Vagrant — управление конфигурациями + виртуализация, с 1.1 работает с докером тоже. То есть создание виртуалки по конфигу. Это конкретно обертка над управлением конфигурацией и виртуализацией. Можно использовать разные менеджеры конфигураций и разные системы виртуализаций. Причем системы виртуализаций могут быть разного типа.

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

        docker же вместе с docker-compose — это (опять же, как я это понимаю) аналого вагранта, но нативные инструменты (не обёртки как вагрант) для полного цикла виртуализации для приложений. Можно применять для разработки и для продакшена.

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

        > можно поднимать прямо на рабочей системе

        (Чото тэг цитирования не сработал)

        Конечно, можно, но уверен, что изолированное приложение и\или сервисы лучше чем неизолированные.

        Еще пример — использование одного и того же сервиса разных версий. в изолированном виде это в разы легче добавить и удалить.
        • 0
          >>Причем основной плюс докера в том, что он использует систему контроля версий для обновления виртуальной.

          По теории так же можно с гитом считать дельту и коммитить то что получилось от ОпенВЗ. Просто что в Докере — это одна из фишек, которая доведена до ума.
    • +2
      Докер — это больше про деплой, нежели про разработку. Очень удобно деплоить контейнеры на большое количество серверов
    • 0
      После использования докера, вагрант ужасно тяжелая и глючная вещь. контейнеры стартуют почти моментально, туда не нужно по ssh залазить, настраивать всякие tmux или screen, чтобы запускать несколько команд в контейнере. Почти нету разницы между приложением, установленным в систему и в контейнер. Но ты потушил контейнеры и все, в системе ничего лишнего + я могу ставить ограничения для контейнеров и если там внутри что-то грузить систему, я не замечаю этого на своем компе
      • 0
        Вы не могли бы описать чем вы занимаетесь? Как часто вы создаете контейнеры для чего-то по работе? Вы используете традиционные сервера для деплоя или что-то вроде AWS?
        • 0
          я работаю в оутсорсинговой компании, django(python) программист, время от времени я вынужден работать с несколькими проектами одновременно, иногда приходится скидывать проект коллегам, поэтому мне важно иметь возможность работать со всем этим одновременно, причем с разными базами и приложениями. Деплоем у нас занимается сис-админ, который собственно меня и убедил попробовать докер и изрядно упростил себе процесс деплоя. иногда дома еще хочется протестить какую-то идею, поднятие контейнера с проектом занимает несколько минут. я использую docker-compose для связки необходимых контейнеров, в основном это проект + база, иногда еще + редис или другая база.
    • +2
      Если вы хотите приблизится к теме Докера со стороны виртуалок я бы предложил вам почитать на
      начиная вот с это-го ответа:
      stackoverflow.com/questions/16047306/how-is-docker-io-different-from-a-normal-virtual-machine/25938347#25938347

      Это именно заче он нужен девелоперам.
      А выше про техническии отличия от виртуалок.
      • –1
        Я скорее хочу понять какой процент разработчиков и в какого типа конторах использует Docker. Чтобы знать насколько мне необходимо быть в курсе этой технологии.
    • 0
      За вагрант не скажу, но вот с докером например надо мне на сервер вордпрес — одна команда, надо могу — одна команда, надо vpn-server, почтовый сервер, блог на руби — «одна» команда, и все это будет работать на одном сервере без конфликтов, один контейнер — как один продукт(программа).
      А раньше без докера мне бы пришлось для каждого сервиса читать кучу манов, делать костыли, разруливать конфликты и т.д. и потом это не перенести на другой сервер если что.
      Хотите что-б у клиента запустился Ваш сервис — даете ему один докер-файл (по чату/почте/github...), и по одной команде у него все запускается.
      • 0
        даете ему один докер-файл
        даже файл давать не обязательно, можно просто сказать команду, все приедет из docker hub.
  • +1
    Открыл статью и ожидал почитать Минусы докера, отдельным пунктом. Где?
    Сколько можно клепать статьи «А что такое Докер?», без указания на его явные неудобства и недостатки.
    Хотелось бы видеть:
    «Что сейчас имеется у Докера, чего пока не хватает, для чего и как можно использовать уже сейчас, принимая во внимание его недостатки и чем можно помочь сообществу в развитии продукта»
    • 0
      А как можно написать о минусах не зная о контексте применения?
      Ведь докер это тут сам посебе и может быть применен для решения многих задач…
      Так что если вы опишите зачем он вам может вы сами и напишите что вам мешает в докере.
      Вот например ребята из CoreOS считают что докер и так уже слишком много задач начинает решать и предлагают сконцентрироваться на контейнерах предлагая свой вариант
      • 0
        Да, CoreOS и Docker жёстко разошлись во мнениях относительно недавно… Что конечно напугало, но говорит о том, что технологии управления контейнерами бурно развиваются и это хорошо, раньше никто особо не обращал внимания на lxc, jail и solaris zones.
        На счёт недостатков — уже описанная например «the PID 1 problem», управление init/логами/прочими процессами, некоторые разницы в версиях, большое количество велосипедов поверх вроде apache mesos и google Kubernetes — зачем вообще они нужны и почему они появляются? Чего не хватает нативному docker/docker-api/swarm/machine/compose? Почему разошлись во мнениях CoreOs/Docker команды? Почему не пилят дальше DockerUI? И т.д.
        Слишком много вопросов возникает :) Для тестирования всё конечно прекрасно, но для продакшена это страшно всё использовать, пока рано. Может через годик-два.
        • +1
          Ну что бы навести в этом порядок надо наверное определить задачи:
          Вот есть контейнер и самое важно в контейнере это то что он стандартизирован… Снаружи он выглядит одинакого независимо что внутри… конечно он кушает разные проперти и вест поразному но это не важно…
          Так вот если остаться в парадиогме архитектуры микросервисов (докер именно её упрощает прежде всего) то докер или Рокет в приницепе не вазно, свою задачу по запуску и мэнедзменту контейнеров они выполнят…
          Другое дело если мы рассматриваем аппликацию состоящую из контейнеров и тут уже какраз вся сложность распределенных приложений… И хорошо что там есть конкуренция…
          И что выбрать вопсро не легкий…
          У само-го руки не доходят…
          я в продукции пока польжусь ручными скриптами… но кошусь в сторону CoreOS и потом Kubernetes

          Почему разошлись во мнениях CoreOs/Docker команды?

          по моей ссылке сверху описано почему…
          видит семя на уровне оркестрации контейнерво и их устроил бы докер проект который занимается только контейнерами а экосистемой…
          Поэтому они видят опасность что Докер разрастется слишком. В принципе я сними даже согласен… Хорошо что есть конкуренция.
          DockerUI
          не нужно… Я один раз поставил и понял что я в консоли быстре… Она ничего не предвносит нового по функционалу

          the PID 1 problem

          Помоему докер со врменем сильно повлияет на архитектуру приложений… И в этой архитектуре совершенно не больно перестартануть контейнер.
  • 0
    а кто-нибудь использует докер для java?
    • 0
      Да, никаких особых проблем нет. Например, мои образы tomcat8 — github.com/grossws/docker-comp-tomcat8, solr4 — github.com/grossws/docker-comp-solr4 (на основе tomcat8, надо подкладывать конфиги, иначе не заработает).
      Можно попробовать с помощью docker pull grossws/tomcat8.
    • 0
      Да. Какие вопросы?
      Наследуйте ваш докерфайл от одного из базового (например мои: registry.hub.docker.com/u/shuron/java_8/ registry.hub.docker.com/u/shuron/debian-openjdk-7/ )
      и вперед…
      • –1
        вопрос — а есть ли смысл?

        когда томкат приложения в принципе поставляются сами в себе… и иногда даже просто в одном war.

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

        а вот с явой — появился вопрос. ведь ява — это микро виртуалка, насколько я знаю.
        • +1
          Лично моё ИМХО, Джаву тоже упаковывать нужно — уж больно большой зоопарк самих JVM и тот же Tomcat меня своими настройками прав доступа долго удивлял. (Я не пишу код на Java, но меня попросили развернуть один проектик у себя на сервере.)

          Ну и вообще, ввиду минимальных накладных расходов на Docker — я вижу только позитивные аспекты его применения (воспроизводимость, переносимость, изолированность и тд).
        • +1
          Как ответил frol смысл есть…
          Да конечно яву можно запокавать в джарчик и потом? Копировать руками везде? Можете rpm строить и деплоить… уже неплохо…
          Но саму яву с версиями тоже надо провизионировать… все это начинает разростатся…
          Вопрос не в яве… А скорее хотите вы связывайтся с контейнерами или нет…
          Помотрите немного вперед. Сегодня у вас ява а завтра nginx на fronend, послезавтра redis, потом
          экспериментальный сервис на Go и вообще вы решили предоставлять кластеру мэнеджмент контейнеров — где чему бежать и хотите чтоб все это работало в продакшн так-же как на вашем лэптопе…
          Вот в этом Докер вам поможет.
  • 0
    Господа.
    Присоединяюсь к заданным вопросам выше: как его использовать-то? Не, ну вот правда! Сколько раз хотел попробовать, но как-то не сложилось.
    Вот есть желающие, я так себе думаю, заработать +миллион в карму, а? (-:
    Вот взять и написать маленький туториал практического использования докера для продакшина…
    Предлагаю даже содержание того, что было бы лично мне интересно:
    1. на входе — nginx с sticky sessions в качестве балансировщика
    2. балансирует он это всё 3-4 копии node-приложения, разнесённых в разные дата-центры, для отказоустойчивости. Для интереса пусть приложения стартуют тоже в nginx+passanger…
    3. приложения имеют дело с кластером монги

    Вот как это делать без докера — я знаю, а как это всё сделать на докеровских контейнерах и предназначено ли всё это для такого типа задач.
    Ну вот честно, совсем без шуток, хочется такой туториал. Может есть что-то подобное в английской версии — буду признателен за ссылку.
    • 0
      Как-то так: habrahabr.ru/post/253999/
      • +1
        ИМХО, вредная статья для изучения, но полезная с точки зрения как делать не надо.
        • 0
          Ужас ужасный, да
      • +1
        Чуть позже в твитере проскочила вот такая статья blog.sunsama.com/meteor-docker-opsworks/
        Вот это туториал, вот это значительно лучше.
    • 0
      Ну смотрите, докер может использоваться по типу виртуализации любого типа. В контейнерной виртуализации меньше оверхед чем в полной, выше скорость работы и часто выше удобство администрирования. LXC в мейнлайне, не нужно тянуть отдельные ядра и т.д. (как в ОпенВЗ)

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

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