Избегайте повторного просмотра Vagrant VM, если он уже подготовлен - программирование
Подтвердить что ты не робот

Избегайте повторного просмотра Vagrant VM, если он уже подготовлен

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

Рассмотрим следующий файл Vagrant:

Vagrant::Config.run do |config|
  config.vm.define :minimal do |config|
    # Base image
    config.vm.box = "lucid32"
    config.vm.box_url = "http://files.vagrantup.com/lucid32.box"

    config.vm.provision :shell, :inline => "mkdir /tmp/foobar"
  end
end

Если вы запустите vagrant up minimal, он создаст поле и предоставит его на начальном этапе. Если вы запустите vagrant provision minimal, он попытается перепроверить окно, но не будет работать (поскольку каталог /tmp/foobar уже существует).

Есть ли способ заставить Вагранта помнить, предоставил ли он машину в прошлом и чтобы не повторять ее позже?

Больше контекста: если я запустил vagrant up minimal, перезагрузите мой хост-компьютер и снова запустите vagrant up minimal, он попытается перепроверить окно и выйти из строя. Это происходит довольно часто, поскольку VirtualBox часто вызывает панику ядра на моей главной машине.

4b9b3361

Ответ 1

Это может быть не тот ответ, который вы хотите, но если вы измените этот mkdir на mkdir -p, он будет работать;)

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

Возможно, сложно достичь истинной идемпотентности, в зависимости от того, что вы на самом деле делаете в своем обеспечении script, но mkdir -p - хорошее начало. Вы также можете создать файл флага в системе и проверить наличие этого файла флага в первую очередь; если он существует, просто exit 0.

Ответ 2

Если вы используете bash обеспечение script, вероятность того, что он не будет идемпотентным.

Вот пример с низким уровнем детализации, как избежать второго раза:

PROVISIONED="/some-app-dir/PROVISIONED";

if [[ -f $PROVISIONED ]]; then
  echo "Skipping provisioning";
  exit;
else
  echo "Provisioning";
fi

#...do provisioning things

touch $PROVISIONED;

Ответ 3

Вы изучили это?

vagrant up --no-provision

$ vagrant up --help
Usage: vagrant up [vm-name] [options] [-h]

    --[no-]provision             Enable or disable provisioning
    --provision-with x,y,z       Enable only certain provisioners, by type.
    --[no-]parallel              Enable or disable parallelism if provider supports it.
    --provider provider          Back the machine with a specific provider.
-h, --help                       Print this help

Ответ 4

Vagrant обычно запускает код инициализации только при первом vagrant up и когда вы специально говорите ему об этом, например, с vagrant provision или vagrant reload --provision. На самом деле нет необходимости уходить с пути, чтобы избежать повторного запуска сценариев подготовки. (Это возможно, не было случая, когда вы разместили вопрос, однако.

Если вы используете Chef или Puppet для подготовки, они уже созданы, чтобы сделать все idempotent, и я бы предположил, что это верно для Соля и Несвятого.

Если вы используете сценарии оболочки и хотите сделать их идемпотентными, вы можете проверить какое-либо условие (например, существование файла) в инструкции if:

if [[! -f "$HOME/bin/something.sh" ]]; then
  # install something.sh into ~/bin
fi

Я дал очень общий ответ, так как предполагаю, что mkdir /tmp/foobar на самом деле не то, чего вы пытаетесь достичь, но если это так, добавьте -p.

Ответ 5

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

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

Idempotence Рецепт может выполняться несколько раз в одной и той же системе, и результаты всегда будут одинаковыми. Ресурс определен в рецепт, который затем определяет действия, которые должны выполняться в системе. Шеф-клиент гарантирует, что действия не выполняются, если ресурсы не изменились и что любое действие, которое выполняется, выполняются одинаково каждый раз. Если рецепт повторно запущен, и ничто не изменен, тогда шеф-клиент ничего не сделает.

ref: https://docs.getchef.com/chef_why.html#idempotence