Используем Docker и не волнуемся о vendor-lock

    Docker в значительной мере изменил подход к настройке серверов, поддержке и доставке приложений. Разработчики начинают задумываться о том, можно ли архитектуру их приложений разделить на более мелкие компоненты, которые будут запускаться в изолированных контейнерах, что позволит достичь большего ускорения, параллелизации исполнения и надежности. Также Docker решает важную проблему снятия облачного vendor–lock и позволяет легко мигрировать настроенные приложения между собственными серверами и облаками. Все что требуется от сервера, чтобы запустить Docker – более-менее современная ОС Linux с ядром не ниже 3.8.

    В этой статье мы расскажем о том, как просто использовать Docker и какие преимущества он даст сисадмину и разработчику. Забудьте про проблемы с зависимостями, запускайте на одном сервере софт, требующий разные дистрибутивы Linux, не бойтесь «загрязнить» систему неправильными действиями. И делитесь наработками с сообществом. Docker решает множество актуальных проблем и помогает сделать IaaS гораздо более похожими на PaaS, без vendor-lock.

    InfoboxCloud Docker

    На облачных VPS от Infobox мы сделали готовый образ Ubuntu 14.04 с Docker. Получите бесплатную пробную версию (кнопка «Тестировать 10 дней») и начните использовать Docker прямо сейчас! Не забудьте поставить галочку «Разрешить управление ядром ОС» при создании сервера, это требуется для работы Docker. В самое ближайшее время у нас появятся и другие ОС с Docker внутри.

    Под катом вы узнаете, что же в Docker настолько воодушевило автора статьи, что за пару дней он перевел свои облачные сервера, автоматизирующие части процесса разработки, в контейнеры Docker.

    Что же такое Docker


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

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

    Основные способы использования Docker:
    • Автоматизация упаковки и развертывания приложений
    • Создание собственных легковесных PaaS окружений
    • Автоматизация тестирования и непрерывной интеграции/развертывания
    • Развертывание и масштабирование веб-приложений, баз данных и сервисов бекенда

    Пятнадцать лет назад практически все приложения разрабатывались на хорошо известных стеках технологий и развертывались в единый, монолитный, проприетарный сервер. Сегодня разработчики создают и распространяют приложения с использованием лучших доступных сервисов и технологий и должны подготовить приложения для развертывания в самые различные места: на физические серверы, в публичные и приватные облака. Критерием выбора облака становится качество сервиса, безопасность, надежность и доступность, в то время как vendor–lock уходит в прошлое.

    Можно провести неплохую аналогию из области грузоперевозок. До 1960х большинство грузов перевозились вперемешку. Перевозчикам нужно было заботиться о воздействии одного типа груза на другой (например, если наковальни внезапно положили на мешки с бананами). Смена транспорта, например с поезда на корабль, для груза тоже было испытанием. До половины времени поездки занимала погрузка, разгрузка и перегрузка. Были большие потери в процессе поездки из-за повреждения груза.

    Решением проблемы стал стандартный контейнер для перевозки. Теперь любые типы грузов (от помидоров до автомобилей) могли быть упакованы в контейнеры. Контейнеры не открывались до окончания поездки. Легко было эффективно расположить контейнеры на транспорте и перегружать автоматическими кранами при необходимости, без разгрузки самого контейнера. Контейнеры изменили мир грузоперевозок. Сегодня 18 миллионов перевозимых стандартных контейнеров составляют 90% мировой торговли.


    Контейнеры для морских грузовых перевозок в порту Циндао, Китай.

    Docker можно представить именно как такие контейнеры в коде компьютера. Практически любое приложение может быть упаковано в легковесный контейнер, позволяющий автоматизацию. Такие контейнеры спроектированы, чтобы запускаться виртуально на любом Linux–сервере (с ядром 3.8 и выше).

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

    Компоненты Docker


    Клиент и сервер

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

    Образы Docker

    Свои контейнеры пользователь запускает из образов, которые являются частью процесса построения контейнера. Образ использует AuFS для прозрачного монтирования файловых систем. С помощью bootfs загружается контейнер в память. Затем bootfs отмонтируется, освобождая память. Далее работает rootfs (от Debian, Ubuntu и т.д.). В Docker rootfs монтируется в режиме «только для чтения». Когда контейнер запущен из образа, монтируется файловая система на запись поверх необходимого слоя ниже.



    Реестры

    Docker хранит созданные вами образы в реестрах. Существует два типа реестров: публичные и приватные. Официальный реестр называется Docker Hub. Создав в нем аккаунт, можно сохранять свои образы в нем и делиться ими с другими пользователями.

    В Docker Hub уже более 10 000 образов с различными ОС и программным обеспечением. Также можно сохранять приватные образы в Docker Hub и использовать их в рамках вашей организации. Использование Docker Hub необязательно. Возможно создание собственных репозиториев вне инфраструктуры Docker (например на ваших корпоративных облачных серверах).

    Контейнеры

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

    Когда Docker запускает контейнер, слой для записи пуст. При изменениях они записываются в этот слой. Например при изменении файла он копируется в слой, доступный для записи (copy on write). Копия «только для чтения» по-прежнему существует, но скрывается. После создания контейнера Docker выстраивает набор read–only образов и подключает слой для записи.

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


    После создания виртуальной машины с Docker можно приступать к созданию контейнеров. Получить базовую информацию об инсталляции можно командой docker info.


    Полный список доступных команд можно получить командой docker help.

    Давайте построим контейнер с Ubuntu.
    sudo docker run -i -t ubuntu /bin/bash
    

    Флаг -i оставляет STDIN открытым, даже, когда вы не присоединены к контейнеру. Флаг -t назначает псевдо-tty контейнеру. Таким образом создается интерактивный интерфейс к контейнеру. Так же мы указываем название образа (ubuntu — базовый образ) и шелл /bin/bash.

    Давайте установим nano в контейнер.
    apt-get update
    apt-get install -y nano
    

    Выйти из контейнера можно командой exit.

    Команда docker ps показывает список всех запущенных контейнеров, а docker ps -a – список всех, включая остановленные.


    В списке запущенных контейнеров нет. Когда вы вышли из контейнера, он остановился. На скриншоте выше (docker ps -a) видно имя контейнера. Когда вы создаете контейнер, имя генерируется автоматически. Вы можете указать другое имя при создании контейнера:
    docker run --name habrahabr -t -i ubuntu
    

    Обращаться к контейнеру можно не только по ID, но и по имени.
    Давайте запустим контейнер:
    docker start stupefied_lovelace
    

    Для подключения к контейнеру необходимо использовать команду attach:
    docker attach stupefied_lovelace
    

    (может понадобиться нажатие Enter до появления приглашения).

    Создаем контейнер-демон


    Конечно, можно создавать и долгоживущие контейнеры, подходящие для запусков приложений и сервисов. Такие контейнеры не имеют интерактивной сессии.
    docker run --name city -d ubuntu /bin/bash -c "while true; do echo hello world; sleep 1; done"
    
    , где city – имя контейнера.
    Посмотреть, что происходит внутри контейнера можно командой docker logs <имя контейнера>.
    Остановить контейнер можно командой docker stop <имя контейнера>. Если после этого запустить контейнер снова docker start <имя контейнера>, выполнение цикла while продолжится в контейнере.

    Увидеть детали контейнера можно командой docker inspect <имя контейнера>.
    Чтобы удалить контейнер, используйте docker rm <имя контейнера>.

    Как достать и положить данные?


    Для того, чтобы скопировать данные в контейнер или вынуть из него, необходимо воспользоваться командой
    docker cp <путь к данным на хосте> <имя контейнера>:<путь>
    

    Можно подмонтировать папку хоста в контейнер при создании:
    docker run -v /tmp:/root -t -i <имя образа>
    
    ,
    где /tmp – путь к папке на хосте, а /root – путь к папке на сервере. Таким образом можно работать из контейнера с данными на хосте и исключить необходимость копирования данных в обе стороны.

    Работаем с образами


    Давайте посмотрим список всех наших образов docker images



    Изменения в существующем контейнере можно закоммитить в образ для дальнейшего использования.
    docker commit <id контейнера> <имя образа>
    
    .

    Перенос образа на другой хост


    Наконец-то о главном. Допустим, вы настроили свое приложение в Docker и закоммитили в образ. Теперь можно сохранить образ в файл
    docker save имя_образа > ~/transfer.tar
    

    Копируем этот образ на другой хост например с помощью scp и импортируем его в Docker.
    docker load < /tmp/transfer.tar
    

    Вот и все, можно легко переносить свои приложения между хостами, облаками и собственными серверами. Никакого vendor–lock. Только ради этого стоит использовать Docker! (если вы сохраняли данные на примонтированную файловую систему, не забудьте перенести и их).

    Устанавливаем nginx в Docker


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

    Создайте чистый контейнер с Ubuntu 14.04 с открытыми 80 и 443 портами:
    docker run -i -t -p 80:80 -p 443:443 --name nginx ubuntu:trusty
    

    Добавьте в /etc/apt/sources.list официальный репозиторий стабильной версии nginx:
    deb http://nginx.org/packages/ubuntu/ trusty nginx
    deb-src http://nginx.org/packages/ubuntu/ trusty nginx
    


    Установите nginx:
    apt-key update
    apt-get update
    apt-get install nginx
    


    Можно проверить, что nginx запускается, выполнив:
    /etc/init.d/nginx start
    

    Мы увидим страницу приветствия, зайдя на ip сервера на порт 80:


    Для различных применений настройки nginx могут отличаться, имеет смысл сохранить контейнер с nginx в образ <ваш логин на hub.docker.com>/nginx:
    docker commit nginx trukhinyuri/nginx
    

    Здесь мы впервые встретились с Docker Hub. Время создать аккаунт в этом сервисе и залогиниться с помощью команды docker login.

    Теперь вы можете поделиться образом с другими пользователями или просто сохранить образ для повторного использования на других хостах. Мы не просто так сохраняли образ в формате <имя пользователя>:<тэг образа>. Попытка отправить образ, именнованный в другом формате будет неуспешной. Например если вы попробуете отправить образ, просто названный nginx, вам вежливо сообщат, что в root репозиторий сохранять образы могут только избранные.

    Отправим наш образ trukhinyuri/nginx на docker hub для повторного использования на других серверах в будущем. (здесь trukhinyuri – имя репозитория автора):
    docker push trukhinyuri/nginx
    

    Для того, чтобы nginx стартовал при запуске хоста, добавим скрипт инициализации upstart по адресу /etc/init/nginx.conf:
    description "Nginx"
    author "Me"
    start on filesystem and started docker
    stop on runlevel [!2345]
    respawn
    script
      /usr/bin/docker start -a nginx
    end script
    

    Заключение


    В этой статье вы смогли попробовать Docker и оценить, как просто упаковывать приложение и мигрировать между различными хостами. Это только вершина айсберга, очень многое осталось за кадром и будет рассмотрено в будущем. Для дополнительного чтения рекомендуем книгу The Docker Book.

    Попробовать образ с Docker в на облачных VPS от Infobox в Амстердаме можно, получив пробную версию бесплатно (кнопка «Тестировать 10 дней»).

    UPD: Доступ в пробную версию облачных VPS временно ограничен. Заказ по-прежнему доступен. Мы тестируем новую технологию, позволяющую сделать сервис еще быстрее. Следите за новостями.

    Если вы обнаружили ошибку в статье, автор ее с удовольствием исправит. Пожалуйста напишите в ЛС или на почту о ней.
    В случае, если вы не можете оставлять комментарии на Хабре — напишите комментарий к статье в Сообществе InfoboxCloud.

    Успешного использования!
    Метки:
    Infobox 41,08
    Компания
    Поделиться публикацией
    Комментарии 90
    • +1
      А можно хоть какое-то сравнение с Vagrant привести?
      • +7
        Vagrant — менеджер виртуальных машин, который может использовать VirtualBox, Parallels, VMWare и даже Docker. Docker запускает Linux-контейнеры и может нативно работать только под Linux. Vagrant предназначен для целей разработки и тестирования, а Docker подходит для продакшна. Более детально тут и тут.
        • +2
          Если вы работаете в Linux Docker вам очевидно будет приятнее. Он не требует тяжелых VirtualBox.

          Особенностью докера является то, что докер-контейнер ориентирован на запуск внутри себя одного процесса. Если вы привыкли создавать образы виртуалок в Vagrant с Mysql, Nginx, Redis, etc, то в случае с докером, вам скорее всего понадобится создавать свой контейнер на сервис и затем линковать их вместе. Почему так? С одной стороны, так проще переключаться между сервисами — в секунды можно поменять MySQL на Percona или Maria. С другой — докер контейнер не совсем предназначен для того, в него заходили через ssh, как это происходит в вагранте. Такая возможность есть, но зачем ходить в запущенный контейнер через ssh, если можно просто запустить контейнер с интерактивной bash сессией?

          Т.е. если вы хотите использовать докер для виртуализации, вам придется чуть поменять подход к созданию среды. Кроме того, для запуске на на Windows, Mac докер всё равно потребует от вас наличия VirtualBox.
          • +1
            Вот насчет одного процесса на контейнер вы ошибаетесь. Главная идея докера — сделать контейнер самодостаточным. Вас никто не ограничивает в запуске процессов внутри контейнера — вот наглядное подтверждение phusion.github.io/baseimage-docker/.
            Ssh внутри контейнера — это перебор, конечно, я не спорю. Но в остальном — в конейнере может сидеть все, что вам там может понадобиться.
            • 0
              Тоже использую этот образ как базовый, очень удобно.
              А SSH внутри всё же использую, как-то не получается к рабочему запущенному контейнеру подключиться к интерактивной bash сессии, поэтому в некоторых контейнерах работает SSH.
              • +3
                Вот это пробовали? github.com/jpetazzo/nsenter
                • 0
                  Нет, по-моему docker-enter абсолютно шикарная вещь, обязательно попробую, спасибо!
              • –1
                да, я знаю, про baseimage, но с ним получается какая-то обрезання виртуалка.
                Его один процесс это runit, хотя конечно было б намного удобнее, если б это был upstart. И если запущен контейнер с upstart, вам ssh становится просто необходим, чтобы войти в этот контейнер. Потому, оценив плюсы-минусы решил всё-таки использовать несколько контейнеров.
                • +1
                  Чем вам upstart мешает зайти в контейнер? 0_о
            • +1
              А виртуализация там как реализована? OpenVZ, kvm, xen? Или что-то свое похожее на openvz?
              • +1
                Там нет виртуализации. Там аналог lxc — микс из cgroups и namespaces. github.com/docker/libcontainer
                • 0
                  Что-то похожее на openvz. Есть низкоуровневые LXC, работающие на основе cgroups и namespaces. Docker работает поверх LXC. Openvz тоже постепенно вроде на LXC переходит, что позволяет сильно уменьшить размер патча ядра и даже, теоретически, в итоге перейти на работу поверх ванильного ядра.
                  • +2
                    Докер решил отказаться от LXC. Последние версии используют libcontainer для контейнеризации. Та же хрень, на самом деле, но реализация другая.
                    • +2
                      Если я правильно понял, то раньше поддерживались три типа контейнеров — lxc, libvirt и systemd-nspawn и все они были внешние. А теперь в дополнение к этим они решили в сотрудничестве с parallels запилить свою вариацию на тему lxc, чтобы иметь больше свободы и не возиться с различными версиями библиотек. При этом у parallels есть свой libct со схожими задачей и подходами. Зоопарк получается… Надеюсь, придёт всё к единому знаменателю.
                      • 0
                        собственная реализация libcontainer уж несколько версий дефолтом
            • +7
              Может кому-то пригодится — Docker — краткое практическое руководство
              • –1
                Лаконично, но доходчиво. Можно рекомендовать материал для быстрого понимания, что такое Docker. Несмотря на то что новой технической информации лично для себя нашел не очень много, зато узнал что такое «vendor–lock».
                • +2
                  Допустим, у меня есть DB которая работает на отдельном хосте и есть несколько приложений, которые работают с этой DB. Как мне мигрировать все это на компьютер разработчика и обратно?

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

                  У кого есть опыт работы со сложными конфигурациями, пожалуйста, поделитесь им?
                  • 0
                    Создаете из запущенных контейнеров с базой и приложениями образ, экспортируете в файлы, копируете на компьютер разработчика, импортируете образы, создаете контейнеры и запускаете. Обратно так же.
                    • 0
                      Они на разных хостах. У них разные настройки подключения к БД. Мне кажется, с ходу так не получится.
                      • 0
                        Перенастроить подключения на другие адреса придется, но обычно это не большая проблема.
                        • 0
                          В обратную сторону опять надо перенастраивать. В общем просто докером тут не обойтись. Нужно делать большую обвязку, как мне кажется.
                          • 0
                            У Docker есть инструменты для связывания, например, ключик --link. Плюс в инфраструктуре Docker есть уже свои новые инструменты для облегчения связывания. Вот статья на Хабре: habrahabr.ru/post/215653/
                            • 0
                              Но это все работает только в пределах одного хоста?
                              • 0
                                Связывание по --link? Да. Связывание через другие инструменты, типа SkyDNS? Полагаю, что нет, хотя на этот счёт ещё подробно не разбирался, только начинаю изучать межконтейнерное взаимодействие.
                                • 0
                                  если верить документации, то линк работает только между контейнерами в рамках одного хоста. Еще есть вариант когда в связанных контейнерах выставляются нужные ENV переменные.

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

                                    Я так и писал — «да, связывание только в пределах хоста».

                                    >А я говорю о другом, когда хостов несколько

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

                                    >Плюс когда нужно перемещать конейнеры из одной сложной среды в другую сложную среду. И тут уже непонятно, зачем нужен докер.

                                    Так, вроде бы Docker и имеет что-то на тему переноса контейнеров между хостами. Тоже не разбирался, мне пока хватает задач в рамках хоста, но в анонсах про CoreOS слышал, что там механизм переноса контейнеров с одного хоста кластера на другой из коробки есть. Хотя, может, это и не средствами Docker.
                                    • 0
                                      Я об этом и говорю, как только мы выходим за рамки одного хоста — начинается серьезная доработка и подключение сторонних инструментов.

                                      Чем в таком сценарии помогает докер, мне до сих пор не понятно. Все что я видел кажется сложнее связки API облака + Puppet + Git

                                      • +1
                                        Docker в этом случае остаётся тем же, чем и был — удобным гибким инструментом для развёртывания легковесный контейнеров :) Сам по себе он не панацея ни в каком из вариантов. Это просто полезный инструмент.
                                        • 0
                                          Вот, ещё одно отличное и простое решение попалось:

                                          github.com/zettio/weave

                                          Качаем один скриптик, запускаем docker-контейнеры через него и… они все объединяются в единую сеть (с указанными при запуске IP) с прозрачным доступом друг к другу, даже при расположении в разных сетях.
                                          • 0
                                            презжде всего Docker обеспечивает Immutable Server Pattern.
                                            Тоесть с точки зрения девелопера вся его аппликация собирается в контейнер один раз.
                                            Со всей конфигой, деревом зависимостей, утилит если надо. и бежит как на его ноуте, как в различных тестовых стендах, так и в облаке одинаково… Не зависомо от того что преустановленно на этих машинах.
                                            В этом бонус…
                                            А поскольку сам Docker инструмент в линуксовой парадигме ( один интрумент решает одну задачу — но хорошо) Docker не занимается оркестрацией…
                                            Но есть целый зоопракр на эту тему…
                                            — SmartStack’s components – Nerve and Synapse
                                            — Kubernetes (google)
                                            — попуряные решения на etcd, Serf, Zookeeper с разной степенью необходимости прикладывания ручек.

                                            IMHO Очень интересно выглядит CoreOs. Пока мне хватает одного хоста… Но смотрю уже на них. Немног сыроваты еще.
                          • +2
                            Как шарить Hostname, username и пароли к БД?
                            У Amazon Beanstalk все происходит через переменные окружения, в них хранится все это дело
                          • +1
                            Вы правы совершенно, к докеру осознанно надо подходить. Вокруг него слишком много маркетингового буллшита, хотя технология сама по себе внимания, безусловно, заслуживает. И про сущности вы правы, ментальный оверхед там некислый получается. А выносить все процессы в отдельные докеры, не группируя их по ролям, как на мой взгляд — так полный бред.

                            Почитайте вот:

                            devopsu.com/blog/docker-misconceptions/
                            news.ycombinator.com/item?id=7868791
                            www.infoworld.com/article/2607966/application-virtualization/4-reasons-why-docker-s-libcontainer-is-a-big-deal.html

                            Я его собираюсь использовать группируя процессы по задачам (вебсервер, например — ngnix, php5-fpm, ssh обязательно потому что в гробу я видел «свой особый подход» и т.д.), и фактически получая более удобный в управлении lxc, не более. Основная идея состоит в том, чтобы уменьшить количество магии до минимума, магия до добра доводит редко.
                            • 0
                              Из того что я узнал я сделал вывод, что докеру явно не хватает возможностей по конфигурации профилей «из коробки». Приходится использовать внешний инструмент для конфигураций, но тогда в облачной среде выгоды от использования докера нет. Тот же puppet позволяет накатить любую конфигурацию на шаблонный инстанс по иерархии роль_сервера/fqdn.

                              А вот для работы внутри отдела разработки штука стоящая и я пожалуй буду ее внедрять.
                          • 0
                            >архитектуру их приложений разделить на более мелкие компоненты, которые будут запускаться в изолированных контейнерах, что позволит достичь большего ускорения, параллелизации исполнения и надежности.

                            А можно поподробнее, как именно размазывание компонентов по контейнерам позволит достичь большего ускорения и параллелизации по сравнению с ситуацией, когда это просто отдельные процессы?
                            Я тут предполагаю, что количество и производительность физических серверов не меняется
                            • 0
                              Разбив сложную систему на составляющие проще определить, в какой возникают проблемы производительности и починить.
                              • –2
                                Мониторить виртуальные инстансы в облаке или виртуальные инстансы в виртуальных инстансах в облаке?

                                Мне кажется, первый вариант проще. Меньше прослоек, меньше глюков.
                                • 0
                                  Образ докера — НЕ виртуальный инстанс. Это просто слепок уже настроенного и отлаженного сервиса со всеми зависимостями. Мониторинг — и там, и там — одинаковый. Однако, в случае докера резко упрощается настройка (ей, по-сути, занимаются девелоперы), доставка контейнера на целевую машину и развертывание.
                                  • 0
                                    Давайте проще, образ — это read-only шаблон. Его мониторить не нужно. Нужно мониторить контейнеры, которые мы получаем из образов.

                                    А вот упрощается ли задача мониторинга нескольких контейнеров на одном виртуальном хосте? Не думаю.
                                    • +1
                                      А в чем разница между тем, чтобы мониторить несколько сервисов на одном инстансе, или несколько контейнеров с сервисами на одном инстансе?
                                      Я, право, не вижу разницы. У нас, например, каждый конейтнер содержит внутри себя все неодходимое для его мониторинга — информацию о метриках, которые генерирует, проверки, которые на нем нужно производить, и т. д. При старте он просто добавляется в систему мониторинга на основе информации, которая уже зашита в него.
                                      • –1
                                        Мне кажется, что отдельный сервисы лучше запускать в отдельных виртуальных машинах. Чем мешать туда еще и второй слой виртуализации.
                                        • +1
                                          Да ну нет там второго слоя виртуализации. Там просто разграничение ресурсов. И железобетонная стена между процессами. Ну и не факт, что лучше так, как вы сказали. Когда количество сервисов (и хостов) растет, выгодно перейти к host-agnostic схеме, когда при каждом новом деплое вам просто без разницы, на каком хосте запустится новый сервис. Вот, например, эти ребята могут много сказать по теме mesosphere.io/
                                          Так, то гораздо проще добиваться отказоустойчивости и масштабироваться. Так гораздо проще поддерживать несколько разных версий кластеров. Ну и куча других преимуществ, на самом деле.
                                          • –1
                                            Можно назвать это разграничением ресурсов, если хотите. Но я простоты не вижу. Сейчас любой более-менее продвинутый облачный хостер позволяет через api создавать инстансы, в которые можно разворачивать образы, которые могут отлично конфигурировать себя через puppet.

                                            И на мой взгляд такая схема проще. Хотя, пойду еще почитаю.
                                            • 0
                                              У докера есть один несравненный плюс — проще реализовывать HA. У нас много серверов, на котором вертится Proxmox VE — это Debian + OpenVZ. Как системный администратор, начинаю изучать вопрос с докером, так как развернуть HA-класер на докере гораздо проще, чем на OpenVZ. В теории)

                                              Изучу вопрос, посмотрим затраты и плюсы при переходе ан новую платформу и, возможно, переедем.
                                              • –1
                                                Кстати вариант, но я бы еще посмотрел в сторону Promox API + Puppet. С докером (если я правильно понимаю) начнется развесистая конфигурация сети, например, если вдруг окажется, что разные части HA находятся на разных хостах. Да и вопрос конфигурации сервисов докер не отменяет, опять же придется использовать какой-нибудь инструмент. Но тогда появится вопрос, зачем в этом всем нужен докер.
                                    • 0
                                      еще 10 лет назад мы создавали «виртуальный и защищенный» образ просто используя Linux команду chroot, после чего мы получали абсолютно изолированную оболочку на базе основного ядра, ставь себе что угодно, любые пакеты, на функционал основной системы это не влияло.
                                      Docker делает тоже самое, только легче?
                                      • +2
                                        Только тяжелее. LXC, лежащий в основе docker часто называют chroot на стероидах. Chroot, например, не обеспечивает изолированного сетевого стека, пространства процессов, пространства монтирования и т. п. Всё это, по умолчанию, включено в docker.

                                        Запуская приложение в docker-контейнере вы получаете для этого приложения более высокий уровень изоляции. Например, можно запустить для разных приложений копии БД, которые биндятся на один и тот же порт не мешая друг другу (и, соответственно, разворачиваются из одного образа, т. к. конфигурацию необходимости изменять нет) дав каждому приложению доступ к своей БД.
                                        • +1
                                          Dcoker это гораздо больше чем chroot.
                                          — Aufs,
                                          — Repo,
                                          — API
                                          — Лучшая изоляция
                                          — сетеые интерефейсы
                                          — и т.д.
                                          Все что нужно для того что бы это полюбили девелоперы не только опсы.
                                          • 0
                                            Все-таки можно уточнить. Мы говорим девелоперам, что теперь они могут запаковать со своим приложением половину системы (библиотеки, системные тулы нужных версий) и это в таком же виде будет установлено на DEV, QA, PROD? Так?

                                            Или это что-то другое?
                                            • 0
                                              Ну если упростить да. Только не все что запаковано переносится… между системами… только недостаающие слои
                                              • 0
                                                Ну вот. Опять стало менее понятно. Недостающие слои — это что? Можете привести пример, пожалуйста?
                                                • +1
                                                  Не ну как-бы сложно в каменте обьяснить что такое Докер и с чем его едят…
                                                  Читайте разбирайтесь. Про слои наглядно тут…
                                                  docs.docker.com/terms/layer/
                                                  ну и вот на вскидку пример с консолью
                                                  tuhrig.de/layering-of-docker-images/
                                      • 0
                                        > Мониторить виртуальные инстансы в облаке или виртуальные инстансы в виртуальных инстансах в облаке?

                                        Тут в одном блоге одного чувака про CoreOS/Docker проскакивала вот такая картинка

                                        • 0
                                          Докер стартует процес на ядре виртуалки… Как если бы это был процесс вашего сервиса. Нет никакого дополуительного «бут-тайм».
                                  • 0
                                    Интересно, как такое можно применять, например, в классическом шаредхостинге.
                                    и как ведется контроль за ресурсами этого «контейнера», раз уже мы заговорили про проблемы производительности
                                    • 0
                                      Насчет шаред-хостинга не готов сказать — просто никогда не пользовался такими. Совсем не про то, но можете поглядеть AWS Elastic Beanstalk. С недавних пор оно умеет запускать докер-образы.
                                      Насчет контроля за ресурсами — докер для этого использует линуксовый механизм cgroups. Можно ограничить размер используемой памяти, CPU, использование блочных устройств. Есть свои заморочки, конечно. Но в целом, если довести до ума, работает, как часы.
                                      • 0
                                        не, мне интересно понять, может ли эта фиговина не дать одному проломанному сайту нагадить остальным и хост машине и не даст ли она запустить стопицот тыщ процессов php/сендмыла, которые сожрут все что можно и что нельзя по ресурсам и укладут с la=~1500 хостовый сервер.
                                        не городить же openvz или еще что ради такого.
                                        • 0
                                          А что там с openvz? Оно же на lxc работает? По уровню изоляции, libcontainer (на котором работает докер) и lxc — близнецы-братья. Механизмы изоляции совершенно одни и те же. Просто разная реализация. Для контейнера создаются свои неймспейсы. Для каждого из них задается свой лимит памяти (на уровне cgroups, опять же). Для каждого из конейнеров, по сути, работает свой менеджер ресурсов. OOM-killer приходит вовремя.
                                          Короче, оно спроектированно так, чтобы его можно было использовать в описанном Вами случае. Вопрос в радиусе кривизны рук админа =)
                                          • 0
                                            Так. Возникает вопрос. Если это аналогичная OpenVZ штуковина, то из-под OpenVZ контейнера его запустить не получится, так?
                                            • 0
                                              Я, честно говоря, не работал с openvz, поэтому уведу тему чуть-чуть в другое русло =)
                                              Внутри докер-контейнера можно запустить еще один демон докера. Правда, для этого корневому контейнеру (где крутится демон докера) надо выдать соответствующий набор привелегий (который, разумеется, делает этот корневой контейнер крайне небезопасным). Что произойдет с лимитами cgroups — не могу сказать, к сожалению.
                                              Учитывая, что мехинизмы изоляции openvz и докер почти идентичны, может быть чего-то подобного можно добиться и от openvz. Но смысла в таких манипуляциях не очень много.
                                              • 0
                                                Ну смысл — разворачивать готовый контейнер на виртуалках у хостера.
                                                • 0
                                                  Не, цель я понял. Я чуть другое имел в виду. Демону докера нужна привелегия CAP_SYS_ADMIN. Если openvz позволяет выдвать специфичные привелегии своим контейнерам, то уверен, что никакой хостер не даст CAP_SYS_ADMIN. Потому как если его дать, то какой вообще толк от такой изоляции?
                                                  • 0
                                                    Ну т.е. теоритически может быть и возможно, но практически — нет.
                                          • 0
                                            демон докера запускается от рута, поэтому если какое-либо сервис в докере тоже запущен от рута (например, апач), то это потенциально небезопасно.
                                            • +2
                                              Это заблуждение.
                                              • 0
                                                лол это не заблуждение.

                                                This means that in most cases, containers will not need «real» root privileges at all. And therefore, containers can run with a reduced capability set; meaning that «root» within a container has much less privileges than the real «root».
                                                This means that even if an intruder manages to escalate to root within a container, it will be much harder to do serious damage, or to escalate to the host.
                                                docs.docker.com/articles/security/

                                                Much harder, но не impossible.
                                                • +2
                                                  Пожалуйста, покажите, как вы перевели этот фрагмент. Мне кажется, вы неправильно его поняли. Ну, либо поправьте меня, если не прав я.
                                                  Здесь говорится о том, что если злоумышленник сможет получить привелегии рута внутри конейнера, хостовой системе будет по-барабану на это. Единственное, что злоумышленник сможет повредить — содержимое контейнера. Рут внутри контейнера и хостовый рут — две большие разницы.
                                                  Для того, чтобы выйти на хост, содержимое контейнера должно выбраться из неймспейсов, в которых запущено. Разумеется, механизм неймспейсов этого не предусматривает. Конечно, если в неймспейсах найдется баг и Вы сможете его эксплуатрировать — хост ваш. Но при чем тут докер? Архитектурных способов покинуть контейнер не существует. А баги — они могут быть везде.
                                                  • 0
                                                    >This means that even if an intruder manages to escalate to root within a container, it will be much harder to do serious damage, or to escalate to the host.
                                                    Это значит, что если атакующий получит рут в контейнере, для него будет гораздно сложнее нанести ущерб системе, или получить доступ к хосту.

                                                    Я еще в другом месте читал, что угрозы есть, хотя может о них и неизвестно. Но если вы, например, поставите --net=«host» ('host': use the host network stack inside the container. Note: the host mode gives the container full access to local system services such as D-bus and is therefore considered insecure.), то получив рут, злоумышленник получит доступ к системе. Или например если поставлен маунт папки на хосте к папке докера, то к ней тоже будет получен доступ. Я согласен, это не «прямая уязвимость», а скорее второстепенная, но она существует, и поэтому нужно думать, когда настраиваешь контейнеры. «Архитектурных способов покинуть контейнер не существует. » — шифрование тоже невозможно было взломать, до баги в OpenSSL.
                                                    • +1
                                                      Ну, начнем с конца. Баг в OpenSSL (мы же про heartbead сейчас, да?) — не является ни уязвимостью алгоритма шифрования, ни протокола. Это баг в библиотеке. Но вернемся к контейнерам. Опция --net=host тупо не создает сетевой неймспейс для контейнера. Т.е., с точки зрения сетевого уровня, содержимое контейнера запущено на хосте. Разумеется, это небезопасно. Аналогично и с маунтами — нефиг монтировать в контейнер то, к чему у контейнера не должно быть доступа. В этом плане Вы, вроде как, все правильно говорите. Но все это не имеет никакого отношения ни к контейнерам, ни к докеру. От докера можно добиться безопасности, действуя на него только снаружи — внутри контейнера можно запускать все что угодно, и вероятность того, что это «что угодно» навредит хосту, стремится к нулю. Сложность преодоления неймспейсов, которыми ограничен докер, по сути такая же, как сложность покинуть гипервизор виртуальной машины.
                                                    • –1
                                                      К тому же, мы говорим не просто о контейнерах, а о Докер контейнерах, а это немного больше чем просто контейнеры. Они запускаются и управляются через димон докера, который требует рута. Так что если найти способ эксплуатировать уязвимость в димоне, то можно получить доступ к системе. Поэтому имея рут в контейнере, можно выйти на димон (не уверен как, правда, я не супер спец), и скомпрометировать хост.
                                                      • +2
                                                        Вот именно в последнем утверждении вы и ошибаетесь. «Выйти на демон» из контейрена уже нельзя. При запуске процесса в новых неймспейсах, его связь с хостом теряется.
                                                        Начните отсюда. Тут все достаточно просто и неплохо описано blog.dotcloud.com/under-the-hood-linux-kernels-on-dotcloud-part
                                                • 0
                                                  Какой-нить апач тоже запускается от root'а, но его child'ы запускаются уже как httpd/apache/www пользователь в зависимости от дистрибутива. Так что это не показатель
                                                  • 0
                                                    я к примеру апач привел.
                                          • +1
                                            Мне вот любопытно… сделали мы сегодня кучу контейнеров с разными приложениями, таскаем их туда-сюда, запускаем, останавливаем, никакого вендор-лока и прочее масштабирование — в общем, мечта. А что мы будем делать через полтора года, когда обнаружится, что используемые сто контейнеров (с кучей уникальных отличий, накопившихся за это время) мало-мало устарели, heartbleed там очередной или что ещё — и их все нужно регулярно поддерживать и обновлять?

                                            Сейчас у нас 3 сервера/ОС и на них 50 приложений/сервисов/сайтов, а с докером будет 53 ОС плюс те же 50 приложений.
                                            • +2
                                              По поводу устаревания ПО решает вопрос сборка образов на основе Dockerfile и необходимостью конфигурировать все свои образы каскадно для того, чтобы изменение одного из образов влияло на изменение этого слоя в других образах, например:

                                              — базовый образ ОС
                                              — — базовый набор LAMP (apache, mysql, php)
                                              — — — специфичный набор для приложения 1
                                              — — — — приложение 1
                                              — — — специфичный набор для приложения 2
                                              — — — — приложение 2

                                              — — — специфичный набор для приложения N
                                              — — — — приложение N
                                              • 0
                                                В теории. Вопрос в том, что будет на практике. Каскадные изменения имеют дурную привычку всё ломать в неожиданных местах — посмотрите например на CSS… интересно, как скоро придумают БЭМ для докера? :)
                                                • +1
                                                  Может стоит думать не только над обновлением системы, но и над обновлением собственных приложений запущенных в контейнере, тогда такого не случится.
                                                  • 0
                                                    В правильном направлении думаете. Заминусовали вас идиоты.
                                                    • +3
                                                      Я не минусовал, но в вопросе есть неправильная посылка. Docker не аналог CSS. В нём нельзя подменить один из базовых образов, таким образом поломав наследника. Образы Docker иммутабельны. Можно только сделать копию и поменять уже её. Но это не повлияет на наследников исходной копии.
                                                      • 0
                                                        В том то и дело! Поэтому например puppet нервно курит нынче ;))
                                                • +2
                                                  Сейчас как раз изучаю этот вопрос. Для себя пока грубо оцениваю ситуацию так:

                                                  — Минимум вмешательства в уже работающие контейнеры. «apt-get upgrade» хорош только при формировании базового образа, но не в регулярной работе, система начнёт засоряться и бонуса по сравнению с обычным LXC не будет. Если нужна полноценная развёрнутая навороченная гостевая система, то надо сразу настраивать LXC. Это и проще будет. Docker же не для систем, а для контейнеров — узкоспецифичных обработчиков.

                                                  — Все «вмешательства» должны быть максимально автоматизированы и по отношению к контейнеру внешними. Т.е. разворачиваем базовый образ контейнера, пушим туда наш проект и в таком виде запускаем. Тут, видимо, надо смотреть в стороны локалхостовых PaaS, типа Dokku. Пока этот вопрос не изучал.

                                                  — Объёмные персистентные данные лучше, наверное, хранить не в контейнерах, а контейнерно-независимых каталогах и томах.

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

                                                  В любом случае нужно помнить, что Docker удобен именно для контейнерного подхода. Когда крупный проект декомпозирован на много мелких независимых элементов. Если требуется (или не получается провести декомпозицию) всё использовать одной кучей, то это не контейнерный подход, тут проще сидеть в виртуальных машинах «чистого» LXC. Или вообще обходиться одной гостевой системой без всякой контейнеризации. Я до последнего времени поступал именно так (ещё весной писал на форумах, что не понимаю зачем нужен Docker). Но сейчас дозрел до понимания того, что большие задачи полезно дробить на мелкие, мелкие задачи удобно раскидывать по индивидуальным контейнерам, после чего и всплывает в поле внимания Docker…
                                                  • 0
                                                    В таком случае обновление будет заключаться только в организации нового контейнера и запихивании туда уже настроенной задачи.
                                                    Одна из причин использования докера — возможность организовать каждому приложению необходимую для его функционирования среду. Эта среда будет (разумеется) отличаться для большинства приложений. При обновлении системы зачастую не удастся ограничиться заменой базового образа с ОС, и нужно будет так же корректировать настройки среды.

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

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

                                                      Вот именно эта оценка меня и отталкивала от Docker до последнего времени. Под мои задачи он не давал ничего сверх LXC, но LXC проще поддерживать, меньше лишних сущностей. Docker был прекрасен, когда нужно запустить Hello world из контейнера, для этого буквально ничего ручками не нужно делать, но когда начинается вопрос персистентности, связывания контейнеров… Тут LXC, которая по сути представляет отдельный автономный виртуальный компьютер становится проще.

                                                      Но сейчас по мере развития проектов начинаю переходить на декомпозицию и разделение функционала и тут внезапно оказывается, что плодить LXC-контейнеры во множестве и поддерживать их индивидуально становится грустно. А вот Docker, наоборот, становится привлекательнее :) Но глобальных выводов пока не делаю, на продакшне Docker'а ещё нет, только экспериментирую. Более того, на одном из основных проектов стоит CentOS, а там ядро без поддержки aufs, так что Docker в пролёте…
                                                      • 0
                                                        Если у вас RHEL/CentOS 6.5 или выше, то докер на нем работает на ванильном ядре, используя device mapper в качестве дискового бекэнда (ещё умеет aufs, btrfz и zfs, как минимум). В 6.5 необходимо подключить EPEL, в 7 обещали в основных репозиториях (я не тестировал). В 6 пакет называется docker-io, в 7 — просто docker.
                                                      • 0
                                                        Можно через dockerfile или через chef автоматизировать тонкую настройку среды.
                                                  • 0
                                                    а внутри VMWare докер работает? Например, есть винда, на ней вмварь в которой крутится современный линукс. Можно ли внутри того линукса (который работает под вмварью) пускать докера?
                                                    • 0
                                                      Никаких проблем.
                                                      • 0
                                                        Работает. Единственное требование, чтобы у гостевой ОС Linux Kernel был не меньше 3.8.
                                                        • 0
                                                          Также подходят ядра RHEL/CentOS 6.5+ (хотя там 2.6.32-*).
                                                      • 0
                                                        Вообще несколько непонятен общий подход. Я попробую обрисовать применительно к Enterprise in-house development (на нашем примере).
                                                        Допустим, есть стандартный цикл Dev — Test — Acc — Prod. Поскольку приложения ноне многокомпонентные (БД + APP), то есть конфигурация, которая связывает их вместе. Теперь в случае с Docker, разработчик готовит среду (image) и приложение (app), скрипт установки APP в среду (deploy), скрипт конфигурирования (configure). Помимо этих объектов существует объект конфигурации на каждом этапе.
                                                        Соответственно, по этапам цикла редко ездят изменения всех этих объектов.
                                                        image — реже всех, но именно в этом и ценность — в одном месте собрано, во всех работает. По сути это материалиазация выбранного стека технологий.
                                                        deploy — чуть чаще, но неразличимо чаще. Зависит от выбранного стека технологий. Зависит от собственно требуемых настроек приложения.
                                                        configure — примерно одинаково с deploy, потому что так же зависит от стека технологий, но в тоже время больше зависит от приложения
                                                        app — чаще всех. по сути фиксирует изменения бизнес-процесса компании.
                                                        Для изменений configure необходимо также предусматривать изменение объекта конфигурации каждого этапа.

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

                                                        Самое читаемое