Редко когда такое новое программное обеспечение, как Docker, с готовностью принимается стартапами вместе с огромными, хорошо известными компаниями . dotCloud , компания, которая создала и поддерживает Docker, недавно получила финансирование в размере 40 миллионов долларов . Microsoft также объявила 18/18 DoI CLI для Windows . Docker также будет играть центральную роль в Azure, а также в следующем выпуске Windows Server .
Так что же такое шумиха?
Docker решает две самые сложные проблемы в развертывании программного обеспечения: безболезненное раскручивание виртуальных машин и объединение кода приложения со средой развертывания.
Вращать новый, настраиваемый экземпляр так же просто, как нажать кнопку. Миграция кода между платформами тривиальна, потому что код нашего приложения упакован вместе со своей средой.
За последние несколько месяцев мы в Keyhole видели много тяги вокруг Docker. В настоящее время мы используем его в одном из наших приложений для управления процессом развертывания. Причины, по которым мы увидели шквал активности, станут ясны после того, как я пойду в то, что отличает Docker от других гипервизоров и инструментов развертывания.
ВМ на стероидах
Виртуальные машины (VM) — это удивительный инструмент, который помог еще больше отделить среду выполнения от физического оборудования. К сожалению, виртуальные машины поставляются с довольно резким снижением производительности при запуске и выполнении.
Причиной большинства проблем в виртуальных машинах является дублирование работы. Чтобы понять это дублирование, подумайте о структуре операционной системы Linux. Существует четкое разделение между ядром Linux , которое управляет задачами более высокого уровня, такими как работа в сети и потоки, и пользовательским пространством, которое находится за пределами ядра.
Традиционные виртуальные машины, такие как VirtualBox и VMWare, запускают свои виртуальные машины в пространстве пользователя. Когда традиционная виртуальная машина запускает экземпляр машины, она раскручивает ядро Linux и пространство пользователя внутри существующего пространства пользователя.
Это где дублирование вступает в игру. Почему ядро Linux должно находиться внутри пользовательского пространства, если для него уже есть ядро Linux? Это не так. Это то, что поняли создатели Docker. Пока ядро Linux виртуальной машины совпадает с ядром хост-машины, уже существует четкое разделение, которым может воспользоваться пространство пользователя виртуальной машины.
Когда виртуальная машина Docker запускается, она присоединяет пространство пользователя виртуальной машины к ядру Linux хоста. Это означает, что загрузка происходит за миллисекунды. Производительность составляет 97% программного обеспечения, запущенного на хост-компьютере. Docker обладает всеми преимуществами без каких-либо недостатков. Плюс …
Развертывание решено
Docker VM генерируется из четко определенного сценария, называемого Dockerfile . Dockerfile определяет, какой вариант и версию Linux использовать, какое программное обеспечение устанавливать, какие порты открывать, как загружать исходный код и т. Д. Все, что вам нужно, объединено в один файл. Вот пример Dockerfile из проекта, который я сделал несколько месяцев назад:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
|
FROM ubuntu:12.04MAINTAINER Zach Gardner <zgardner@keyholesoftware.com># Update apt-getRUN apt-get update# Create containerRUN mkdir /containerRUN mkdir /container/project# Install NodeJSRUN apt-get --yes install python g++ make checkinstall fakeroot wgetRUN src=$(mktemp -d) && cd $src && \ wget -N http://nodejs.org/dist/node-latest.tar.gz && \ tar xzvf node-latest.tar.gz && cd node-v* && \ ./configure && \ fakeroot checkinstall -y --install=no --pkgversion $(echo $(pwd) | sed -n -re"s/.+node-v(.+)$/\1/p") make -j$(($(nproc)+1)) install && \ dpkg -i node_* && \ rm -rf $src# Install NPMRUN apt-get --yes install curlRUN curl --no-check-certificate https://www.npmjs.org/install.sh | sh# Install Bower's dependenciesRUN apt-get install --yes git# Install PhantomJS dependenciesRUN apt-get install --yes freetype* fontconfig# Move source code to containerADD / /container/project# Install NPM dependenciesRUN cd /container/project/ && npm install# Install Project's Bower dependenciesRUN cd /container/project && (echo -e "n" | ./node_modules/bower/bin/bower install --allow-root)# Compile codeRUN cd /container/project && ./node_modules/grunt-cli/bin/grunt build# Start serverCMD /container/project/node_modules/grunt-cli/bin/grunt --gruntfile /container/project/Gruntfile.js prod |
Первое, что я делаю в этом сценарии, это определю, что я использую Ubuntu 12.04. Я устанавливаю NodeJS, NPM и git. Я копирую исходный код из своего репозитория, загружаю зависимости времени выполнения, компилирую код и запускаю свой сервер.
Когда вы передаете Dockerfile в Docker, он генерирует образ Docker. Лучший способ представить образ Docker — это автономный zip-файл, содержащий все, что нужно приложению для запуска.
Комбинирование исходного кода и среды выполнения является полным изменением парадигмы от традиционных методов развертывания. Вместо того, чтобы перемещать код, иметь сценарии оболочки, выполняемые человеком для обновления среды, и желать лучшего, вы можете вместо этого перенести свежие образы Docker на разные платформы. Практически не требуется вмешательство человека, что снижает вероятность ошибок. Лучше всего то, что после того, как QA завершили работу над определенной версией приложения, вы можете быть уверены, что приложение не изменится при переходе на другие платформы.
Интересно, что парадигма Docker по переносу изображений Docker согласуется с некоторыми исследованиями, проводимыми в программировании Reactive . Управление состоянием — одна из самых сложных вещей в приложении. Изменчивость делает создание поточно-ориентированного кода нетривиальной задачей. Смещая процесс обработки неизменяемых фрагментов данных, центральный процессор может оптимизировать потоки и операции намного проще, чем раньше. Docker следует этой парадигме, избавляясь от концепции обновлений программного обеспечения на платформах. Гораздо проще удалить работающий образ Docker и заменить его новым, чем беспокоиться о том, как обновить текущий работающий образ. Нет сценариев, необходимых для обновления таких вещей, как Java, если версия устарела, или других неприятных вещей, как это. Docker догадывается, какое программное обеспечение работает на ваших платформах: это то, что разработчик указал в Dockerfile.
Перенос изображения между платформами — тривиальная работа. Образы Docker могут быть переданы в реестр Docker ( публичный или частный ) и перенесены на нужную платформу. Синтаксис очень похож на Git:
На платформе разработки
|
1
|
docker push zgardner/myapp |
На производственной площадке
|
1
2
|
docker pull zgardner/myappdocker run -i -t zgardner/myapp |
В приведенном выше примере я сначала отправил myapp в реестр Docker. Затем я вытаскиваю его с более высокой платформы и запускаю.
Термин работающий образ Docker — это контейнер Docker. Есть некоторые шаги, которые я пропустил, чтобы показать закрытие существующего контейнера, как указать порт, через который должен взаимодействовать контейнер Docker, и т. Д. Это те вещи, которые организация, использующая Docker, может указать для себя.
Идея легко переносить код — это долгожданная революция по сравнению с любым внутренним, проприетарным, домашним решением, которое я когда-либо видел. Сочетание мощности виртуальной машины с Linux-ядром и упрощенного процесса миграции имеет несколько довольно сильных последствий. В Keyhole мы экспериментировали с CoreOS и Fleet для развертывания новых серверов, их настройки с помощью Docker и загрузки образов Docker с консоли Amazon AWS. Мы также начинаем экспериментировать с …
Сервис-ориентированная архитектура: простой как нарезанный
Docker — это первый настоящий инструмент DevOps . Это позволяет разработчикам легко определять среду, в которой должен выполняться их код. Это также снимает стресс от беспокойства по поводу обновления окружающей среды.
Изображения Docker, являющиеся статическими контейнерами, означают, что они должны выгружать постоянные данные за пределы самого приложения. Обычно это делается путем монтирования диска AWS при определении контейнера Docker. Это также означает, что код, содержащийся внутри приложения, должен быть небольшим, кратким и очень сфокусированным. Поскольку приложение будет работать в изолированной среде, его необходимо определить так, как если бы оно могло запускаться на острове самостоятельно.
Это очень хорошо подходит для SOA (сервис-ориентированной архитектуры) . SOA — это другой способ понимания API и того, как вообще создаются приложения. Традиционный подход к приложению заключается в том, что это система, состоящая из более мелких технических частей. Этими техническими деталями могут быть такие вещи, как Продукты или Клиенты, Фонды или рабочие места. Некоторые из этих технических частей могут понадобиться в других приложениях, написанных компанией-разработчиком программного обеспечения. Традиционный подход состоит в том, чтобы либо попытаться поделиться кодом, который часто не работает, потому что он был написан только с учетом оригинального приложения, либо скопировать весь код вместе, что на самом деле не работает.
Приложение, написанное с учетом SOA, разработано с совершенно другой целью. В SOA приложения объединяются путем объединения бизнес-потребностей и кода приложения. Некоторые из упомянутых выше технических частей на самом деле являются бизнес-потребностями. Они, как правило, одинаковы для разных приложений, хотя могут использоваться по-разному в зависимости от пользовательского интерфейса. Если каждая из этих бизнес-потребностей может быть объединена в четко определенный, согласованный интерфейс, их можно повторно использовать по своему дизайну.
Делая SOA основным направлением деятельности организации, можно быстро и эффективно объединять новые приложения. Amazon была одной из первых компаний, которая стала пионером такого подхода. SOA завоевывает популярность во многих других малых и крупных компаниях, потому что она так хорошо работает.
Docker очень хорошо подходит для SOA. Каждый сервис может быть задуман как отдельный Dockerfile. Перенос сервисов между платформами так же прост, как перетаскивание статического образа Docker и его перенос. Они изолированы по своей природе работы в независимой виртуальной машине. Использование инструментов документации API, таких как Swagger, поможет сделать сервис еще более четким.
Docker также используется такими компаниями, как Netflix, для реализации микро-сервисов . Эти сервисы отличаются от традиционных сервисов в SOA по объему. Традиционные услуги имеют много общего, и их часто трудно изолировать и содержать. Микро-сервисы ориентированы на очень маленькие, многократно используемые компоненты, которые настолько мало знают об окружающей среде, насколько это возможно. Изоляция, которую обеспечивает Docker, хорошо работает с применением крошечных микро-сервисов, которые можно развернуть где угодно.
В Keyhole мы работаем над тем, чтобы переписать нашу систему вопросов и ответов вместе с нашим приложением Timesheet для использования SOA с Docker. Результаты были очень многообещающими. У нас есть будущие посты в блоге, в которых будут подробно описаны разные вещи, которые мы обнаружили и испытали в ходе этого процесса.
Завернуть все это
Docker — очень мощный инструмент, который, по нашему мнению, станет отраслевым стандартом в ближайшие годы. Он переворачивает виртуальную машину и процесс миграции приложений с ног на голову. Нам будет интересно помочь клиентам реализовать его в своем стеке и увидеть серьезную экономию времени и энергии. Docker позволит разработчикам и системным инженерам перестать беспокоиться о проблемах сборки и развертывания и вместо этого сосредоточиться на том, что важно: создавать красивые приложения.
| Ссылка: | Докер: виртуальные машины, миграция кода и SOA Решено нашим партнером JCG Заком Гарднером в блоге |