Nano Hash - криптовалюты, майнинг, программирование

шаблоны упаковщиков и условные операторы

Я хотел бы использовать условные операторы в шаблоне упаковщика на этапе "provisioners".

  "provisioners": [
    {
      "execute_command": "echo 'vagrant'|sudo -S sh '{{.Path}}'",
      "override": {
        "virtualbox-iso": {
          "scripts": [
            "scripts/base.sh",
            "scripts/puppet.sh",
          ]
        }
      },
      "type": "shell",
    }
  ]

Например, если пользователь в командной строке «packer build» каким-то образом указывает параметр «puppet», тогда «scripts/puppet.sh» будет выполнен, иначе пропущен.

Как я могу это сделать?

17.11.2014

Ответы:


1

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

Идея

Самый простой способ — установить пользовательскую переменную из команды сборки и передать эти переменные от упаковщика. к сценарию инициализатора оболочки, который определяет значение пользовательской переменной и вызывает соответствующий скрипт инициализатора, например. марионетка, соль,...

Отказ от ответственности:

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

Подход к решению проблем

<сильный>1. Определите переменную, которая указывает используемый поставщик:

Существует несколько способов определения пользовательской переменной,

  • вызвав команду сборки упаковщика с флагом -var (см. конец ответа)

  • определить пользовательские переменные в файле шаблона коробки

    The packer box template file: **template.json**
    
         "variables": [
             "using_provision_system": "puppet"
         ]
         "provisioners": [
              {...}
    
  • определить файл определения переменной и указать путь к нему в команде сборки с -var-file

    The variable file: **variables.json**
    Is a great alternative if you want to define variables in a seperate file.
    
         {
            "using_provision_system": "puppet"
         }
    

<сильный>2. Вызов сценария оболочки, который вызывает сценарии поставщика:

Теперь измените команду execute_command таким образом, чтобы «главный» сценарий вызывался с определенной переменной в качестве аргумента.

"provisioners": [
    {
      "execute_command": "echo 'vagrant'|sudo -S sh '{{.Path}}' '{{user `using_provision_system`}}'",
      "override": {
        "virtualbox-iso": {
          "scripts": [
            call_provisioner_script.sh
          ]
        }
      },
      "type": "shell",
    }
  ]

Обратите внимание, нам нужно указать только один скрипт. Этот один «главный» сценарий принимает переданную переменную в качестве аргумента и сравнивает значение с некоторыми предопределенными именами поставщиков в условии переключения. (Коротко: он выбирает, какие сценарии подготовки будут выполняться.)

основной сценарий предоставления: call_provisioner_script.sh

case $1 in
    puppet*) sh puppet_provisioner.sh
    *) sh shell_provisioner.sh

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

<сильный>3. Последний шаг — собрать коробку :)

Вызов команды сборки упаковщиков:

#define variable in build command (first option from above)
$ packer build -var 'using_provision_system=puppet' template.json

#define variables in variable file and set path in build command
$ packer build -var-file=variables.json template.json

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

19.04.2015
  • Изменилось ли это теперь, когда у нас есть HCL2 для упаковщика? 02.03.2021
  • Я довольно давно не прикасался к упаковщику и не знаком с HCL, но похоже, что only/except может быть правильным. Тогда он должен быть похож на ответ @jeffreyveon. Например. создайте одну конфигурацию предоставления для базовых сценариев (имеет набор only=[base]), а другую — для марионетки с набором only=["base" "puppet"]. Затем запуск упаковщика с -only=base,puppet в качестве cli-аргумента должен выполнить шаги подготовки base и puppet. По крайней мере, я этого ожидал :) 21.05.2021
  • В качестве альтернативы установите only=["puppet" "salt"...] для базового поставщика и only=["puppet"] для марионеточного. Тогда должно быть достаточно запустить оба провайдера (базовый и марионеточный) с packer -only=puppet. 21.05.2021

  • 2

    Альтернативным способом является определение двух разных сборщиков одного типа, но с разными именами. Затем вы можете исключить шаг подготовки из конкретной сборки, используя поле only:

    {
      "source": "foo.txt",
      "destination": "/opt/foo.txt",
      "type": "file",
      "only": ["docker-local"]
    }
    
    07.12.2016
    Новые материалы

    Кластеризация: более глубокий взгляд
    Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..

    Как написать эффективное резюме
    Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..

    Частный метод Python: улучшение инкапсуляции и безопасности
    Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..

    Как я автоматизирую тестирование с помощью Jest
    Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..

    Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
    Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..

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

    Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
    В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..