Как осуществляется развертывание в производство из локальной среды разработки VirtualBox / Vagrant?

Недавно я начал читать о создании сред разработки с помощью программного обеспечения виртуализации (я новичок), и мне кажется, что "инфраструктура как код" - это действительно мощная концепция.

Мне очень нравится описанная здесь структура рабочего процесса :

  1. вокруг команды используется один и тот же базовый образ VirtualBox
  2. Vagrant используется для быстрого "наращивания" и "обеспечения" такого образа необходимой конфигурацией с помощью
  3. шеф-повар (или кукла) рецепты, которые являются единственным фрагментом кода, который необходимо поместить под контроль версий.
Однако я все еще не совсем понимаю, как код передается и развертывается на производственных серверах.

Как я понимаю, общий способ сохранить идентичность сред DEV и PROD заключается в управлении экземпляром рабочего сервера как еще одним виртуальным образом, который должен быть подготовлен с помощью Chef. У меня может быть точно такая же ОС, установленная на производственном сервере, как я (и команда) использую ежедневно с VirtualBox-Бродяга-Шеф.

Но рабочий сервер может иметь оборудование, которое отличается от оборудования виртуальной гостевой ОС, и это может снова привести к несоответствиям.

Итак, вот вопрос:

Каков известный и распространенный способ переноса и развертывания кода на рабочий сервер из среды разработки, управляемой с помощью цепочки инструментов VirtualBox-Vagrant-Chef? Допускает ли эта практика какое-либо непрерывное развертывание?

[Edit]: Примечание: Существует ли практика запуска одного и того же экземпляра виртуальной машины, подготовленного с помощью Chef/Vagrant на рабочем сервере, как это показано на этой диаграмме ?

2 34
chef continuous-deployment virtualbox vagrant puppet

2 ответа:

Я автор статьи, которую вы связали, поэтому мой 0.02

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

Используя vagrant, вы гарантируете, что ваши разработчики используют ту же ОС, что и ваши рабочие серверы, независимо от того, какую ОС они используют для разработки.

Используя куклу / шеф-повара вы гарантируйте, что ОС настроена одинаково, независимо от того, работает ли она в виртуальной машине с Vagrant, виртуальной машине в производстве, облачной виртуальной машине или голом металлическом оборудовании. Он не должен быть виртуальным.

22

В случае Puppet (шеф-повар, скорее всего, может сделать то же самое), вы можете построить манифест (рецепт) таким образом, чтобы они вели себя по-разному в вашей бродячей среде, например 

if $::virtual != "virtualbox" { # not in vagrant
    include sysctl_tuning
}

В этом контексте вопрос о непрерывных поставках является слишком широким. Я думаю, что ответ будет "да", чего бы это ни стоило.

1