Aws-cli: Разрешить развертывание облачной информации для принятия файла параметров

Просматривая код, кажется, что здесь что-то нужно

https://github.com/aws/aws-cli/blob/develop/awscli/customizations/cloudformation/deploy.py#L178

который читает в файле JSON, может быть, для быстрой проверки работоспособности, а затем передает его в deploy() .

Пометка как запрос функции для развертывания облачной информации.

@sanathkr мысли?

жду этой функции 👍

Мне также нужна функция для действий package . Спасибо! 👍

Передача файла параметров через что-то вроде --parameters как в командах create-stack и update-stack CF (и в идеале с использованием того же синтаксиса содержимого файла), сделает разработку шаблонов CF немного проще для меня. Хотел бы увидеть эту особенность.

+1 за эту функцию. Спасибо!

Доброе утро!

Мы закрываем эту проблему здесь, на GitHub, в рамках перехода на UserVoice для запросов функций с использованием интерфейса командной строки AWS.

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

В качестве краткого руководства по UserVoice (если вы еще не знакомы): после публикации идеи люди могут проголосовать за идеи, и команда продукта будет отвечать непосредственно на самые популярные предложения.

Мы импортировали существующие запросы функций из GitHub - поищите там эту проблему!

И не волнуйтесь, эта проблема все еще будет существовать на GitHub для будущих поколений. Поскольку это только текстовый импорт исходного сообщения в UserVoice, мы по-прежнему будем помнить о комментариях и обсуждениях, которые уже существуют здесь по проблеме GitHub.

GitHub останется каналом для сообщений об ошибках.

И снова эту проблему теперь можно найти, выполнив поиск по названию на: https://aws.uservoice.com/forums/598381-aws-command-line-interface.

-Команда разработчиков SDK и инструментов AWS

Эту запись, в частности, можно найти на UserVoice по адресу: https://aws.uservoice.com/forums/598381-aws-command-line-interface/suggestions/33168409-allow-cloudformation-deploy-to-accept-a-paramater

+1 за эту функцию. Спасибо!

Основываясь на отзывах сообщества, мы решили возвращать запросы функций в проблемы GitHub.

Если кто-то ищет обходной путь, вы можете попробовать использовать jq , например:
aws cloudformation deploy --parameter-overrides $(jq -r '.[] | [.ParameterKey, .ParameterValue] | join("=")' param.json) ...
В зависимости от значений параметров может потребоваться дальнейшее экранирование.

Я тоже собираюсь +1 к этой функции.

Я заменяю jq на jp везде, где это возможно. JMESPath стоит изучить.

$ jp \
  --unquoted \
  --filename example-app-params-staging.json  \
  "join(' ', @[].join('=', [ParameterKey, ParameterValue])[])"
HostedZone=example.com KeyName=example-ap-southeast-2 TargetPort=8080 VpcStackName=vpc-example

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

+1 за это. Я понимаю, что хочу сохранить простоту «развертывания облачной информации aws», но эта команда уже имеет отдельные флаги командной строки для возможностей, тегов и параметров (как и все другие команды облачной информации aws), но вы заставили их работать по-другому (только принятие списка строка = строка в командной строке, а не структура JSON в файле). Вы должны сделать так, чтобы все команды aws cloudformation работали согласованно (включая использование cli-input-json, как почти все команды CLI aws). Если вы хотите упростить конструкцию тегов для «развертывания aws cloudformation», вам следует ввести другой флаг командной строки, например --tags-overrides или --parameters-overrides.

👍 по запросу функции, было бы здорово, если бы это поддерживалось.

Это было бы здорово! Это значительно упростило бы идемпотентность при создании стеков cf с помощью cli 👍

+1

+1

+1

@ ColdFire87 @ dan-lind @mnwk , пожалуйста, просто 👍 первый выпуск и прекратите рассылать спам всем, кто подписан на этот выпуск? Каждый комментарий со знаком 👍 пингуется 20 человек ....
(Извините за других, но мы должны бороться с этим ...)

@pierreozoux Извините, я не хотел раздражать людей :)

Что сказал @cervantek . Я просто хочу добавить, что надеюсь, что этот билет отслеживает реализацию всех этих опций для согласованности с create-stack :

          [--template-body <value>]
          [--template-url <value>]
          [--parameters <value>]
          [--capabilities <value>]
          [--tags <value>]

Многие люди, подобные мне, будут иметь устаревший код, написанный с использованием create-stack и update-stack и они захотят переписать его, чтобы использовать deploy . Это не должно быть так сложно.

+1 к --parameters поддерживает файл JSON.

Наша команда недавно начала создавать шаблоны облачной информации, которые были достаточно большими, чтобы потребовать загрузки в корзину S3, поэтому сейчас мы переходим от create-stack и update-stack к развертыванию ... и сталкиваемся с той же проблемой миграции наших файл параметров для работы с этой новой командой. +1 за эту функцию

+1 за эту функцию

+1

+1

+1

+1

@ olivier-schmitt-sonarsource @ anshul0915 @lmunro @ MiMo42 @markusbecker @ benjammin12 и другие в будущем, пожалуйста, просто 👍 родительскую проблему вместо того, чтобы рассылать спам тем из нас, кто подписался на ветку с комментариями, если вы просто хотите +1 к проблеме. Спасибо.

👍

другой обходной путь для этого - использование файла .ini со списком пар параметров key=value и развертывание с использованием:
aws cloudformation deploy --parameter-overrides $(cat parameters.ini)
то же самое можно сделать и с тегами.

другой обходной путь для этого - использование файла .ini со списком пар параметров key=value и развертывание с использованием:
aws cloudformation deploy --parameter-overrides $(cat parameters.ini)
то же самое можно сделать и с тегами.

Такой подход хорош и работает! Тем не менее, чтобы сохранить согласованность со всеми другими командами (которые поддерживают ввод json), рекомендуется сохранять параметры в формате файла json и специально манипулировать файлом, прежде чем использовать его в качестве ввода для "развертывания". команда. Это можно сделать с помощью команды jq, которая доступна для всех наиболее распространенных платформ .

Преобразование может быть легко выполнено с помощью:

cat parameters.json | jq -r '.[] | .ParameterKey + "=" + .ParameterValue'

Более того, его можно преобразовать на лету и использовать непосредственно в качестве входных данных для команды развертывания :

aws cloudformation deploy --template-file ./sample-template.yaml --stack-name sample-stack --parameter-overrides $(cat parameters.json | jq -r '.[] | .ParameterKey + "=" + .ParameterValue')

Надеюсь, это поможет!

К счастью, CDK полностью решает эту проблему. Я двинулся дальше.

Я пытался перейти к методу развертывания из create-stack / update-stack и получаю это плюс другие проблемы - я удивлен, что спустя 3 года он все еще не имеет паритета с этими старыми методами.

У меня возникают проблемы с использованием описанного выше обходного пути для файлов тегов, в которых значения некоторых тегов содержат пробелы. Я уверен, что это разрешимо, но моя другая проблема более фундаментальна - вывод этой команды неструктурирован, поэтому для получения идентификатора набора изменений мне нужно проанализировать неструктурированную текстовую строку. Я считаю это очень хитрым (!) Тем более, что метод create-change-set возвращает идентификатор в json.

Ссылка на проблему с голосом пользователя в более раннем сообщении в этой ветке мертва - знает ли кто-нибудь, где эта проблема отслеживается в настоящее время или над ней все еще работают?

Ребята, рассмотрите возможность реализации этой функции. Использование трюков с cat или передача параметров через SSM в качестве обходного пути - это ненужное усложнение по сравнению с очень базовой функциональностью, и такая функциональность поддерживается практически всеми другими альтернативами CFN .

Я наткнулся на эту ветку, когда искал решение для передачи параметров в create-stack и update-stack , но я тоже дам свой 👍, но добавив к запросу, что у нас есть возможность передать файл, соответствующий формату JSON, который CodePipeline принимает для CloudFormation.

Если вы активно пользуетесь CodePipeline для развертывания CloudFormation, уже принято, чтобы ваши файлы CloudFormation в формате CodePipeline фиксировались в ваших репозиториях.

Это отлично работает, когда вы запускаете полный цикл CI / CD через конвейер, но это очень утомительно для локальной разработки. У меня есть несколько скриптов, которые могут переводить CodePipeline JSON в JSON, который aws cloudformation create-stack и update-stack принимают через --parameters file://params.json , и с некоторой дополнительной работой, вероятно, могут работать в некоторых из хаков. люди выше упомянули jq и тому подобное, но это похоже на взлом.

Пожалуйста, примените это!

Пожалуйста, реализуйте это! Давай, AWS, он открыт уже почти 3 года.

Еще одна вещь, которая крайне раздражает и отчасти связана с этой темой, - это несоответствие между форматами для предоставления параметров CFN через CLI .

На данный момент я являюсь пользователем deploy , и до сих пор мне удавалось избежать неприятностей, используя встроенные параметры с помощью трюков с cat то есть --parameter-overrides $(shell cat configs/${LNMS_ENV}.properties) .

Проблема возникла, когда я решил реализовать что-то похожее на plan Terraform, используя наборы изменений CFN. Оказывается, aws cloudformation create-change-set может переопределять параметры, но ожидает, что они будут отправлены в формате, отличном от deploy !

Согласно документации CLI для deploy это:

ParameterKey1=ParameterValue1

Согласно документации CLI для create-stack , update-stack и create-change-set это:

ParameterKey=string,ParameterValue=string

с возможностью предоставления JSON.

Я действительно не понимаю, почему они разные, почему deploy не поддерживает один и тот же формат JSON, и что мне делать - сохранять два практически одинаковых файла параметров для каждой среды?

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

PS Не заметил, что @ pablods90 взялся за это, но только доказывает, что люди продолжают изобретать колесо из-за отсутствия базовой функциональности :(

+1

Приключения Captain Consistency продолжаются.

Хотя мы можем обойтись без использования cat для хранения конфигураций deploy в формате, который также совместим с update-stack :

[
    {
        "ParameterKey": "ParamEnv",
        "ParameterValue": "prod"
    }
]

CodePipeline с типом действия Deploy:CloudFormation использует другой формат файла для передачи в CFN:

{ 
  "Parameters": {
     "ParamEnv": "prod"
  }
}

Никаких дальнейших комментариев ... Действительно устал повторять одну и ту же проблему снова и снова. Это плохо.

в итоге мы получили просто однострочные сценарии оболочки для вызова aws cloudformation deploy поддерживаемые вместе с файлами для CodePipeline, а не cat или jq shenanigans.

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

В любом случае, я перестал ждать и пытаться внедрить развертывание в то, что я думал, что он должен делать, и в конечном итоге сделал то, что, как я думаю, сделали большинство других - напишу свой собственный сценарий bash "upsert", используя команды cli создания и обновления стека. 100 строк, но, по крайней мере, теперь он выполняет свою работу!

Привет, мне это действительно нужно. Я действительно разочарован, увидев эту ситуацию, когда люди просят сделать это годами, но CloudFormation еще не предоставил. Какая идея движет командой, это приемлемо .....

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

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

Кроме того, похоже, что нет простого способа (по крайней мере, в CLI командной строки Windows) предоставить многострочный параметр.

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

Спасибо большое за отличную работу, ребята!

Привет, этот PR был объединен и выпущен в AWS CLI v.2.0.39.

@ vz10 Спасибо за обновление.

Кстати, вы случайно не знаете, допускает ли эта реализация (через файл параметров) многострочные параметры? Это была одна из тех вещей, с которыми я не мог справиться в пакетной среде Windows с AWS CLI.

Заранее благодарим за помощь!

@ bs-thomas Я не тестировал с многострочными параметрами. Но я считаю, что если формат JSON поддерживает его, он будет работать нормально.

Было бы здорово, если бы вы могли попробовать это и дать нам отзыв.

Спасибо.

@ vz10 Многострочный действительно работает. Однако это выглядит очень некрасиво с \ n

На самом деле, было бы здорово, если бы CLI мог поддерживать формат YAML для переопределения параметров CLI ;-)

@ bs-thomas похоже на еще один запрос функции.

Просто создайте его, и это будет полдела - заставить переопределения параметров понимать YAML;)

@ vz10 Конечно, я сделаю это прямо сейчас.

Кстати, я заметил кое-что неприятное в валидаторе JSON. Он не принимает целочисленные или логические значения. Поэтому, если они у меня есть, это нужно указать в виде строки, иначе я получу такой ответ:

Потом!

@ bs-thomas да, это немного странно, но это то же поведение, которое ожидает cloudformation create-stack - все значения являются строками, и он анализирует их после, и у него нет логического типа параметра