Создание кроссплатформенной среды разработки Docker

Сколько раз вы читали это утверждение:

«Самое замечательное в Docker заключается в том, что ваши разработчики используют тот же контейнер, что и в производстве».

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

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

Как менеджер команды разработчиков, мне нравится использовать одни и те же процессы и технологии на протяжении всего жизненного цикла наших приложений. Когда мы запускали приложения в AWS OpsWorks, используя Chef для подготовки серверов и развертывания приложений, мы использовали Vagrant с Chef для локального запуска тех же рецептов для создания нашей среды разработки.

Проблемы со средой разработки Docker

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

В этой статье освещаются шесть основных проблем, с которыми мы столкнулись при попытке создать согласованную среду разработки Docker для Windows, Mac и Linux:

1. Запуск Docker на трех разных платформах
2. Docker Compose проблемы в Windows
3. Запуск минимальной ОС в vagrant (boot2docker не поддерживает гостевые дополнения)
4. Доступ на запись томов на Mac и Linux
5. Запуск нескольких контейнеров на одном хост-порту
6. Загрузка нескольких копий образов докера

Запуск Docker на нескольких операционных системах

Докер требует Linux. Если все работают под Linux, это действительно не проблема, но когда команда использует несколько ОС, это создает значительную разницу в процессах и технологиях. Разработчики в нашей команде используют Windows, Mac и Linux, поэтому нам нужно было решение, которое бы работало согласованно на этих трех платформах.

«Нам нужно было решение для среды разработки, которое бы работало согласованно на трех платформах». с помощью…

Нажмите, чтобы чирикать

Docker предоставляет решение для работы на Mac и Linux, называемое boot2docker . boot2docker — это минимальная виртуальная машина Linux, достаточно установленная для запуска Docker. Он также предоставляет сценарии инициализации оболочки, позволяющие использовать инструменты командной строки Docker из хост-ОС (Windows или Mac), сопоставляя их с хост-процессом Docker, работающим внутри виртуальной машины boot2docker. В сочетании с VirtualBox это обеспечивает простой способ запустить и запустить Docker на Windows или Mac.

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

Использование Docker Compose в Windows

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

Однако Compose все еще относительно нов, как и сам Docker, и в результате он еще не очень хорошо работает в Windows. На самом деле в Windows так много проблем, что в проекте есть эпос, посвященный их решению: https://github.com/docker/compose/issues/1085 . Однако есть и хорошие новости: Docker Toolbox утверждает, что поддержка Compose для Windows появится в ближайшее время.

(пере) Enter Vagrant

Ранее я упоминал, что boot2docker хорошо работает для создания виртуальной машины Linux для запуска Docker, но он работает не во всех условиях.

Vagrant был фантастическим инструментом для команд разработчиков в течение последних нескольких лет, и когда я начал работать с Docker, мне даже было немного грустно уходить от него. После нескольких месяцев борьбы за то, чтобы все работало с boot2docker, мы вернули Vagrant в уравнение.

Нам понравилось, насколько маленьким был boot2docker, поскольку нам не требовался полнофункциональный хост Docker, но, к сожалению, он не поддерживает гостевые дополнения VirtualBox, необходимые для синхронизированных папок. К счастью, мы нашли бродячую коробку AlbanMontaigu / boot2docker, которая была версией boot2docker с установленными гостевыми дополнениями и весила в 28M. Сравните это с минимальной коробкой Ubuntu 14.04 на 363M.

Доступ на запись по томам

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

В Windows VirtualBox синхронизируемые папки доступны для записи всем пользователям с разрешениями Linux 777. Поэтому в Windows доступ на запись не является проблемой. Однако в Linux и Mac есть владение файлами и разрешения для работы. Например, когда я пишу код на моем Mac, мое имя пользователя — shipley, а мой uid / gid — 1000. Однако в моем контейнере Apache работает как www-data с uid / gid, равным 33.

Поэтому, когда я хочу, чтобы Apache генерировал файлы, к которым у меня есть доступ на моем хост-компьютере, для продолжения разработки, Apache не разрешается писать в них, потому что он работает от имени другого пользователя. Я мог бы либо изменить владельца / права доступа к файлам в файловой системе Mac, либо изменить пользователя и uid / gid apache, как в контейнере, на shipley и 1000. Однако этот параметр довольно небрежный и не работает для групповой разработки. ,

С VirtualBox вы можете изменить пользователя / группу и разрешения, которые синхронизируются папки, как, но это не очень просто или удобно по умолчанию. Vagrant предоставляет очень удобный способ сделать это, хотя. Это было одним из главных мотивов для нас, чтобы вернуться в Vagrant. С Vagrant все, что нам нужно добавить в наш Vagrantfile:

С дополнительными mount_options он будет владеть папкой / data внутри vm под именем uid / gid 33, которая в контейнере Apache на основе Ubuntu будет отображаться в пользовательские / групповые www-данные.

Забавно, что, как я упоминал ранее, по умолчанию разрешения для файловой системы в Windows — 777. Так что доступ к записи не представляет проблемы. Однако мы обнаружили, что при использовании томов в Docker для монтирования пользовательского файла my.cnf в контейнер mariadb, mariadb не нравится, когда файл конфигурации доступен для записи во всем мире. Итак, еще раз, Vagrant помогает нам, упрощая также установку прав доступа к файлам в монтировании:

Запуск нескольких контейнеров, которые предоставляют один и тот же порт

Моя команда в первую очередь разрабатывает веб-приложения, поэтому для нас каждый из наших проектов / приложений предоставляет порт 80 для доступа HTTP во время разработки.

Хотя boot2docker для Windows / Mac и собственный Docker в Linux позволяют быстро и легко приступить к работе, к хосту можно привязать только один контейнер. Поэтому, когда мы разрабатываем несколько приложений или несколько компонентов приложения, которые предоставляют один и тот же порт, это не работает. Это действительно не ограничитель показа, но это неудобство, так как требует запуска приложений на нестандартных портах, с которыми просто неудобно работать и которые трудно запомнить.

Однако запуск каждого приложения на собственной виртуальной машине через vagrant решает эту проблему. Конечно, это вводит еще пару проблем; Как и сейчас, вы должны получить доступ к приложению через IP-адрес или сопоставить имя хоста с ним в файле hosts. Это на самом деле не так уж и плохо, так как вы должны делать это только один раз для каждого приложения.

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

Загрузка нескольких копий изображений Docker

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

Мы смогли проявить творческий подход, и при загрузке виртуальной машины мы проверяем папку хост-машины, определенную переменной окружения DOCKER_IMAGEDIR_PATH наличие любых образов Docker, и, если они найдены, они docker load их в Docker. Затем после завершения docker-compose up -d все новые загруженные образы копируются в папку DOCKER_IMAGEDIR_PATH .

Бинго, нужно загрузить каждое изображение только один раз.

Вывод

После решения всех этих проблем и поиска решений для них у нас теперь есть простой Vagrantfile, который мы можем скопировать в каждый из наших проектов, чтобы обеспечить согласованный опыт разработки независимо от того, какую операционную систему использует разработчик. Сегодня мы используем его в нескольких проектах и ​​даже достигли стадии непрерывной интеграции и сине-зеленого развертывания в Amazon Elastic Container Service в процессе производства (но это темы для другой статьи).

Я ожидаю, что с течением времени мы столкнемся с новыми проблемами, и наши проекты изменятся, и мы будем продолжать развивать наши решения, чтобы учесть их. Наш Vagrantfile является открытым исходным кодом, и мы приветствуем предложения и вклады.

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

Ресурсы

• докер
• Docker Compose
• Docker Toolbox
• VirtualBox
• бродяга
• boot2docker
• Пользовательский загрузочный ящик boot2docker с установленными гостевыми дополнениями
• Наш проект vagrant-boot2docker

«Создание согласованной кроссплатформенной среды разработки Docker» через @codeship

Нажмите, чтобы чирикать