Вступ

Я не можу зрозуміти хорошого способу налаштування середовища розробки на OS X за допомогою Docker та Boot2Docker. Проблема, яку я вражаю, полягає в тому, як керувати вихідним кодом, щоб:

1. Я можу змінити код в OS X за допомогою інструментів (текстовий редактор, IDE, git тощо), які я вже встановив.
2. Ці зміни відображаються в контейнері Docker, тому, якщо я перезапущу тести чи оновлю веб-сторінку, я зможу негайно побачити свої зміни.

Теоретично це легко зробити, встановивши мій вихідний код як том:

docker run -it -v /path/to/my/source/code:/src some-docker-image

На жаль, це має дві основні проблеми, які роблять його абсолютно непридатним для використання в OS X:

Проблема №1: Вмонтовані томи на VirtualBox (які використовують vboxsf) надзвичайно повільні

Наприклад, ось скільки часу займає Jekyll для компіляції моєї домашньої сторінки, якщо вихідний код є частиною образу Docker:

> docker run -it brikis98/yevgeniy-brikman-homepage:v1 bash

root@7aaea30d98a1:/src# time bundle exec jekyll build

[...]

real    0m7.879s
user    0m7.360s
sys     0m0.600s

Ось саме те саме зображення Docker, за винятком цього разу, я монтую вихідний код з OS X:

> docker run -it -v $(pwd):/src brikis98/yevgeniy-brikman-homepage:v1 bash

root@1521b0b4ce6a:/src# time bundle exec jekyll build

[...]

real    1m14.701s
user    0m9.450s
sys     0m3.410s

Проблема №2: Перегляд файлів порушено

Механізми спостереження за замовчуванням у SBT, Jekyll та grunt використовують такі технології, як inotify, які не працюють, якщо вони запущені в контейнері Docker і зміни, внесені в OS X до змонтованої папки.

Вирішення, які я намагався

Я шукав рішення (включаючи всі на SO) і випробував кілька з них, але не знайшов успішного:

1. Я переключив Boot2Docker на використання NFS , але це було так само повільно.
2. Я спробував Vagrant + NFS , і це теж було так само повільно.
3. Я спробував монтування Samba , але папка завжди відображалася порожньою в контейнері Docker.
4. Я намагався використовувати файлову систему Unison , яка короткочасно працювала для синхронізації файлів, але потім постійно показувала помилки підключення .
5. Я увімкнув опитування в Jekyll , але це значно збільшило затримку, поки мої зміни не були взяті.
6. Я спробував Dinghy , "швидший, зручніший Docker для OS X з Vagrant" і отримав певне вдосконалення. Замість того, щоб компіляція Jekyll була в 10-15 разів повільнішою, вона була в 2-3 рази повільнішою. Це вже краще, але все одно не зовсім придатне для використання.

Хтось знайшов рішення, яке насправді працює та дозволяє продуктивно розробляти код за допомогою Docker та OS X?

Оновлення: нарешті рішення!

Нарешті я знайшов рішення, яке видається продуктивним, використовуючи Boot2Docker + rsync. Детальні відомості про те, як це налаштувати, я зафіксував у власній відповіді , а також у проекті з відкритим кодом, який називається docker-osx-dev .

Я вирішив додати власну відповідь із найкращим рішенням, яке я знайшов на сьогодні. Я оновлю це, якщо знайду кращі варіанти.

Наразі найкраще рішення

Найкращим рішенням, яке я знайшов для налаштування продуктивного середовища розробки за допомогою Docker в OS X, є: Boot2Docker + Rsync . За допомогою rsync, час збірки в контейнері Docker відповідає рівню запуску збірки безпосередньо на OSX! Більше того, код програми перегляду файлів не потребує опитування ( inotifyпрацює, оскільки rsync використовує звичайні папки), тому гаряче перезавантаження відбувається майже так само швидко.

Існує два способи його налаштування: автоматичне встановлення та встановлення вручну.

Автоматизована установка

Я упакував усі кроки для налаштування Boot2Docker за допомогою Rsync у проект з відкритим кодом, який називається docker-osx-dev . Код трохи грубий, але я успішно використовую його протягом декількох тижнів, щоб легко переключатися між 3 проектами з 3 різними стеками технологій. Спробуйте, повідомте про помилки та надішліть кілька PR! Також див. Мій допис у блозі «Продуктивне середовище розробки з Docker на OS X» для отримання додаткової інформації.

Налаштування вручну

1. Встановити Boot2Docker : brew install boot2docker.
2. Run Boot2Docker, але з VirtualBox загальних папок відключені: boot2docker init && boot2docker start --vbox-share=disable.
3. Запустіть boot2docker shellinitі скопіюйте змінні середовища, які вони роздруковують, у ваш ~/.bash_profileфайл.
4. Встановіть Rsync на Boot2Docker VM: boot2docker ssh "tce-load -wi rsync".
5. Створіть необхідні базові папки на віртуальній машині Boot2Docker та встановіть для них дозволи правильно. Наприклад, якщо ви будете синхронізуватися в /foo/barпапку OS X, вам потрібно створити /foo/barна Boot2Docker VM: boot2docker ssh "mkdir -p /foo/bar && chown -R docker /foo/bar".
6. Запуск Rsync для синхронізації файлів на Boot2Docker VM: rsync --archive --rsh="ssh -i $HOME/.ssh/id_boot2docker -o StrictHostKeyChecking=no" /foo/bar docker@dockerhost:/foo. Перевірте rsync docs на наявність різних налаштувань, які ви можете увімкнути, наприклад, використання --exclude .gitдля виключення .gitпапки під час синхронізації.
7. Використовуйте програму перегляду файлів, щоб синхронізувати файли. Наприклад, ви можете використати fswatch ( brew install fswatch), перекладений у rsync.
8. На даний момент, ви повинні бути в змозі використати , docker runщоб запустити свій контейнер Докер і використовувати -vпрапор для монтування папки ви синхронізуєте: docker run -v /foo/bar:/src some-docker-image.
9. Оновіть код на OS X як зазвичай. Зміни повинні розповсюджуватися дуже швидко, використовуючи rsync, звичайний код програми перегляду файлів повинен вносити зміни як завжди (тобто, використовуючи inotify), а збірка повинна виконуватися швидко, оскільки всі файли є "локальними" для контейнера.
10. Якщо вам потрібно протестувати запущений веб-сайт, запустіть boot2docker ipкоманду, щоб дізнатись, на якій IP-адресі він.

Оновлення : Тепер, коли docker для mac перебуває в бета-версії з функцією, яка не зломлюється, проходження цим маршрутом може бути набагато розумнішим для місцевої розробки без використання есею хак та обхідних шляхів.

Не варто . Я знаю, що це не відповідь, на який ви, напевно, сподіваєтесь, але чесно оцініть вартість / вигоду від спроби отримати локальний вихідний код + докерізоване виконання порівняно з просто виконанням локальної розробки на OSX.

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

Проблема №1: Вмонтовані томи у Virtual Box (які використовують vboxfs) надзвичайно повільні

Зачекайте трохи, і це майже напевно покращиться.

Проблема №2: Перегляд файлів порушено

Я не впевнений, що це виправлення найближчим часом. Якщо цей тип функціональних можливостей є ключовим для вашого робочого процесу розробки, я вважав би це тимчасовим порушенням. Не варто великих зусиль щодо досліджень та розробок, якщо порівнювати лише використання rbenv / bundler для керування вашими встановленнями jekyll / ruby ​​та їх локального запуску на OSX, як це робили люди успішно протягом останнього десятиліття +.

Подібно до того, як "хмара" не бере участі в моїй локальній програмі розробки, на даний момент docker - це виграш для тестування / індексування / розгортання, а також для запуску баз даних та інших сторонніх компонентів, але програми, які я фактично кодую, запускаються прямо на OSX.

Docker для Mac і Windows повинен бути остаточним способом розробки за допомогою Docker на OS X (і Windows). Продукт Docker - це «інтегрована, проста в розгортанні середовище для створення, збірки та доставки додатків з Mac або Windows». Це передбачає можливість вирішення питань, представлених ОП. З моменту оголошення від 24 березня 2016 року :

• Швидше і надійніше: більше немає VirtualBox! Механізм Docker працює в дистрибутиві Alpine Linux поверх віртуальної машини xhyve в Mac OS X або на віртуальній машині Hyper-V в Windows, і керуванням цією віртуальною машиною здійснює програма Docker. Вам не потрібна машина-докер для запуску Docker для Mac і Windows.
• Інтеграція інструментів: Docker для Mac - це програма для Mac, а Docker для Windows - це програма для Windows, включаючи власний користувальницький інтерфейс та можливість автоматичного оновлення. Набір інструментів Docker постачається в комплекті з ним: командний рядок Docker, Docker Compose та командний рядок Docker Notary.
• Монтаж томів для вашого коду та даних: доступ до даних до об’єму працює коректно, включаючи сповіщення про зміну файлів (на Mac inotify тепер працює безперебійно всередині контейнерів для монтованих каталогів). Це дозволяє цикли редагування / тестування для розробки “в контейнері”.
• Простий доступ до запущених контейнерів у локальній хост-мережі: Docker для Mac та Windows включає DNS-сервер для контейнерів та інтегрований із мережевою системою Mac OS X та Windows. На Mac Docker можна використовувати навіть тоді, коли він підключений до дуже обмеженої корпоративної VPN.
• Docker для Mac був створений з нуля, щоб мати змогу відповідати моделі безпеки пісочниці OS X, і ми працюємо в тісному співробітництві з Apple, щоб досягти цього.

Застереження: Я можу бути упередженим, оскільки я є автором docker-sync.

Я, мабуть, спробував усі наведені тут рішення, включаючи деякі інші (див. Компроміс https://github.com/EugenMayer/docker-sync/wiki/Alternatives-to-docker-sync ), але вони в основному або не спрацювали з боку продуктивність (більшість з них) або на док-машині (або жодної), що використовується / забезпечується.

http://docker-sync.io створений для об’єднання всіх рішень та забезпечення найкращих стратегій (реалізація декількох із них ви можете вибрати).

Його можна використовувати з rsync (одностороння синхронізація), включаючи виправлення дозволів для користувачів, та з унісоном (двостороння синхронізація). Він не примушує вас док-машину або певний гіпервізор, а також не вимагає наявності докера для Mac. Це працює з усіма ними.

На продуктивність EugenMayer / docker-sync / wiki / 4.-На продуктивність це не впливає, це як у вас взагалі немає спільних ресурсів.

docker-sync та його спостерігачі за змінами оптимізовані та без проблем працюють з проектами із 12k файлами.

Спробуйте, якщо хочете, я хотів би почути відгук!

Я тебе відчуваю! Я думаю, що я спробував майже все, що ви пробували, і, на жаль, це все ще було повільно. Потім я натрапив на цей коментар https://github.com/boot2docker/boot2docker/issues/64#issuecomment-70689254, який пропонує використовувати Vagrant та Parallels замість Virtualbox. Це дозволило мені використовувати nfs, і я справді побачив значний приріст продуктивності для свого проекту (Drupal).

Ось файл Vagrant. Все, що вам потрібно зробити, це встановити vagrant, скопіювати його у файл під назвою Vagrantfile і помістити в якусь папку. Перейдіть до цієї папки і просто виконайте vagrant upзамість звичайного завантажувача boot2docker.

Vagrant.configure(2) do |config|
  config.vm.box = "parallels/boot2docker"

  config.vm.network "forwarded_port", guest: 80, host: 80

  config.vm.synced_folder(
    "/Users/dicix/work/www", "/vagrant",
    type: 'nfs',
    nfs_udp: true,
    mount_options: %w[actimeo=2],
    bsd__nfs_options: %w[alldirs maproot=root:wheel]
  )
end

Я також використовую Vagrant з паралелями та boot2docker ( https://github.com/Parallels/boot2docker-vagrant-box ). Розвиток для мене ніколи не був легшим. Дуже добре працює з docker-composeвеликими установками. Я насправді не відчуваю затримки або масового споживання ресурсів.

Ось як Vagrantfileвиглядає моя :

Vagrant.configure(2) do |config|

  config.vm.network "private_network", ip: "192.168.33.10"
  config.vm.box = "parallels/boot2docker"

  config.vm.synced_folder "/Users", "/Users", type: "nfs", mount_options: ["nolock", "vers=3", "udp"], id: "nfs-sync"

end

Вже кілька тижнів я розробляю в середовищі OS X (середина 2011 року Macbook Air) + Boot2Docker + Docker-компонування. Не стикався з основними проблемами продуктивності, але я уникаю запуску будь-якої збірки під час розробки (чому б не використовувати щось на зразок jekyll serve --skip-initial-build?). Ось приклад docker-compose.ymlфайлу, який я використовую:

docker-compose.yml:

test:
  build: .
  volumes:
    - ./client:/src/client
    - ./server:/src/server
    - ./test:/src/test
  command: nodemon --exec jasmine-node -- test/ --verbose --autotest --captureExceptions --color
  environment:
    - DEBUG=*

Файл Docker:

FROM node:0.12

RUN mkdir -p /src
WORKDIR /src

ENV PATH=/src/node_modules/.bin:$PATH

# We add package.json first so that we the
# image build can use the cache as long as the
# contents of package.json hasn't changed.

COPY package.json /src/
RUN npm install --unsafe-perm

COPY . /src

CMD [ "npm", "start" ]
EXPOSE 3000

Я іноді використовую NFS ( http://syskall.com/using-boot2docker-using-nfs-instead-of-vboxsf/ ), але при цьому не помічав великої різниці в продуктивності.

Для мене зручність простого docker-compose up testзапуску мого середовища коштувала витрат на продуктивність (я регулярно працюю над кількома проектами з різними стеками).

PS: nodemonє одним з небагатьох спостерігачів за файлами, які працюють з vboxsf (див. Https://github.com/remy/nodemon/issues/419 ).

Docker Unison працює як шарм! https://github.com/leighmcculloch/docker-unison

Двонаправлена ​​синхронізація з дуже хорошою продуктивністю!

Примусити докер працювати як інструмент розробки можливо. Але це буде боляче. Я задокументував процес тут:

http://harmingcola.blogspot.com/2015/05/how-to-setup-docker-as-development-tool.html

Цей метод є останнім (вересень 2015 р.) Та найпростішим способом налаштування Docker на Mac: посилання тут:

Ви встановлюєте Docker за допомогою посилання Docker Toolbox на інструкції тут:

Це повний пакет налаштування Docker, який включає такі інструменти Docker:

Докер-машина для запуску двійкового файлу докер-машини

Docker Engine для запуску докерного двійкового файлу

Docker Compose для запуску бінарного файлу docker-compose

Kitematic, графічний інтерфейс Docker, оболонка, попередньо налаштована для середовища командного рядка Docker

Oracle VM VirtualBox

Що в наборі інструментів:

• Клієнт Docker
• Докер-машина
• Docker Compose (лише для Mac)
• Docker Kitematic
• VirtualBox