Ответ 1
В рабочем процессе Vagrant + Chef могут возникать следующие проблемы:
- Если вы помещаете каждый проект в свою собственную виртуальную машину, использование ресурсов (при работе над несколькими проектами) быстро становится непомерно высоким. Конечно, легко отключить и перезапустить виртуальные машины, но он все равно может быть немного громоздким (например, если вы первый дизайнер, который подбирает немного каждого проекта для раунда обновлений).
- Если вы поместите все проекты в одну виртуальную машину, управление будет ужасным, так как вам будет трудно, если вам нужны разные версии Python, Ruby и т.д. (конечно, вы можете использовать rvm или что-то подобное, но это будет много дополнительной работы только для локального dev env).
- Когда вам нужно построить или перестроить среду, это займет много времени, и частичные сборки или перестройки будут сложными: если вы явно не создадите моментальные снимки своих виртуальных машин на разных этапах, вы не сможете, скажем, сохраните дистрибутив, но переустановите код и библиотеки.
- Если вы полагаетесь на внешние зависимости (и давайте посмотрим правде в глаза: вы будете!), полные перестройки могут потерпеть неудачу, потому что одна из зависимостей сломана (вспомните проблему с параметрами setuptools/pip и колеса недавно?) или зеркало вниз.
- Если ваш стек имеет несколько компонентов (думаю, "веб", "db", "кеш",...), они, вероятно, будут установлены в Vagrant VM, а результирующая установка будет отличаться от производственной. Или вы можете использовать несколько виртуальных машин, но см. Проблему №1!
Теперь, с рабочим процессом Docker (с шефом или без него), вы помещаете все проекты в независимые контейнеры, решая проблемы №1 и №2. Вы можете иметь несколько проектов, работающих параллельно (или несколько версий одного и того же проекта) с умеренным использованием ресурсов. И даже если у вас много проектов, и они не могут/не могут поддерживать их все в одно и то же время, остановка и запуск намного быстрее, чем с виртуальными машинами.
Перестройки быстрее и извлекают выгоду из кеша сборки Docker: определите свою службу с помощью файла Docker, а когда вы измените строку в файле Docker, нужно только переустановить этот шаг и последующие шаги: это проблема с номером 3.
Docker смягчает проблему # 4 благодаря реестру. Вы можете подтолкнуть свои сборки к реестру (общедоступному или частному), и если перестройка завершится неудачей, просто вытащите предыдущую сборку; и ему не придется тянуть 5 ГБ изображения: благодаря системе слоев, будут загружены только необходимые файлы.
И последнее, но не менее важное: Docker помогает с проблемой №5, потому что вы можете запускать файлы dev и prod в контейнерах точно так же. Вместо "prod работает на связке виртуальных машин, а dev запускает все в одном", вы можете иметь как в контейнерах, так и уменьшать побочные эффекты, вызванные расхождениями между средами.
Шеф полностью ортогонален этому: вы можете использовать Chef (или Puppet, Anseible или Salt или...) в Docker просто отлично.
Каковы недостатки Docker? Хорошо, Docker - молодой продукт (почти 1 год, когда я печатаю эти строки!), поэтому Vagrant будет более отполирован и может иметь некоторые функции, которые вы (например, возможность перенаправить развертывание в EC2 или другую инфраструктуру с некоторыми дополнительными усилиями). Однако имейте в виду, что Докер имеет чрезвычайно активное сообщество; поэтому количество ресурсов и доступная помощь, вероятно, будут одинаковыми в обоих сценариях.
Но как насчет Vagrant + LXC + Chef? Вполне честно, варианты, доступные для Vagrant + LXC, не так удобны, как Docker. Они могут помочь с проблемами №1 и №2 (использование ресурсов и изоляция), но они не помогут С# 3 и # 4 (частичные перестройки и легкие push/pull изображений сборки). ИМХО, если вам нравится ценностное предложение Vagrant + LXC + Chef, у вас будут те же функции (и даже больше!) С Docker, с большим сообществом и поддержкой.
Мои 2 ¢!