Есть ли причина использовать Кукольный рядом с Докером?

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

Я вышел с Docker, который отлично подходит для меня. Но некоторое время назад я пытался Кукольный, так что вопрос пришел мне на ум: «Есть ли какая-нибудь причина использовать Кукольный с Докером?». Докер, похоже, делает все, что сделал Кукольный, но более простым способом.

PS Некоторое время назад в HN не было консула, который хорошо разбирается и обнаруживает сервис, поэтому даже конфигурация может быть решена (и я тоже думаю об этом).

  • Докер не может вытащить изображения
  • 2 Solutions collect form web for “Есть ли причина использовать Кукольный рядом с Докером?”

    Кукольный и докер может делать многие из тех же вещей, однако они подходят к ним по-другому.

    Кукольный управляет файлами + пакеты + услуги. (Вызывается trifecta). Docker инкапсулирует двоичные файлы и файлы конфигурации внутри контейнера.

    На момент написания этой статьи докер все еще нестабилен и не должен использоваться в производстве. Многие из API, вероятно, будут изменены до версии 1.0.

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

    Кукла с другой стороны является стабильным продуктом и поставляется со всей экосистемой инструментов (heira, mcollective, facter, бритва). Эти инструменты могут быть быстро реализованы и не беспокоятся о разрыве вещей.

    Я бы очень хотел предложить следующие ресурсы.

    Видео о том, как управлять стеками приложений с марионеткой
    https://www.youtube.com/watch?v=KSo_mcJxFIA

    Подкаст о том, как докер и марионетка могут работать вместе
    http://devopscafe.org/show/2014/1/23/devops-cafe-episode-46.html

    Марионеточная статья блога о том, как интегрироваться с докером
    http://puppetlabs.com/blog/building-puppet-based-applications-inside-docker

    Еще одна статья в блоге о кукольном и докерном сосуществовании
    http://puppetlabs.com/blog/can-containers-and-configuration-management-co-exist

    Марионеточный модуль для взаимодействия с докером
    http://docs.docker.io/use/puppet/

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

    Обновить

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

    https://puppetlabs.com/presentations/using-docker-puppet-james-turnbull-kickstarter

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

    https://sysadmincasts.com/episodes/31-introduction-to-docker

    Докер Плюсы:

    • Быстрое ускорение экземпляра
    • Легче учиться, чем марионетка
    • Легко сделать 0 простоя

    Докер Минусы:

    • Контейнеры имеют ограничение 10 ГБ при использовании бэкэнда devicemapper
    • Небольшие изменения конфигурации требуют много времени для восстановления контейнера
    • Затраты на использование реестров докеров, таких как hub.docker.com, quay.io (Самостоятельный реестр докеров крайне неэффективен и не имеет gui)
    • Нет правильной системы инициализации. Некоторые приложения не играют хорошо.
    • Отсутствие мелкомасштабного контроля над сетью
    • Приложения, для которых требуются подоболочки (смотрящие на вас RVM + ruby), очень сложны, чтобы нормально работать
    • Не удается управлять хостами Windows, без SLES или других менее популярных операционных систем
    • В настоящее время оркестровка докеров очень молода.
    • В настоящее время не удается установить ваш /etc/resolv.conf во время сборки
    • Различные ошибки, которые мы должны установить / etc / localtime и / dev / urandom, чтобы сопоставлять локальные и хост-каталоги хостов.
    • Производительность не такая высокая (несмотря на все претензии, что докер должен составлять 99% скорости голого металла, он иногда на 30% медленнее, чем другие машины).
    • Маленькие контейнеры по-прежнему имеют сотни мегабайт накладных расходов. Наши контейнеры имеют несколько гигабайт.

    Кукловоды:

    • Простота масштабирования
    • Работает с существующими серверами (windows, linux, sles)
    • Быстро делать небольшие изменения
    • Сильное сообщество других марионеточных пользователей и модулей
    • Стандартный API для установки пакетов на всех платформах

    Кукольные мины:

    • Крупные инфраструктуры очень сложны
    • Условные зависимости модулей создают код спагетти
    • Более тяжелый вес

    В настоящее время мы используем марионетку для предоставления наших докерных контейнеров. Контейнеры-докеры используются для сборки дженкинсов и уничтожаются после каждой сборки. Он работает хорошо и дает нам согласованную среду. Это означает, что нам нужно только написать код один раз, а затем перестроить обе машины ubuntu, sles и centos. Восстановление контейнеров занимает от 15 до 30 минут и по-прежнему является ручным процессом. Docker отлично подходит для быстрого тестирования vm's,

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

    Docker помогает вам создавать и изначально настраивать контейнеры, но он запускает одноразовые команды при инициализации контейнера.

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

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

    Он также позволяет вам абстрагироваться и параметризовать конфигурации, и вы можете экспортировать параметры, созданные на одном сервере или в контейнере, и использовать их в другом (например, сбор списка узлов имен хостов для приложения мониторинга).

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

    Interesting Posts
    Давайте будем гением компьютера.