Aws-cli: Cloudformation Deployment erlauben, eine Parameterdatei zu akzeptieren

Wenn man sich den Code ansieht, scheint es, als ob wir hier nur etwas brauchen würden

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

die eine JSON-Datei einliest, vielleicht eine schnelle Überprüfung der Gesundheit, dann übergibt sie an deploy() .

Kennzeichnung als Funktionsanforderung für die Bereitstellung von Cloudformation.

@sanathkr Gedanken?

warte auf diese Funktion 👍

Ich hätte auch gerne die Funktion für package Aktionen. Vielen Dank! 👍

Die Übergabe einer Parameterdatei über etwas wie --parameters wie in den create-stack und update-stack CF-Befehlen (und idealerweise unter Verwendung der gleichen Dateiinhaltssyntax) würde die Entwicklung von CF-Vorlagen ein wenig erleichtern mich. Würde diese Funktion gerne sehen.

+1 für diese Funktion. Vielen Dank!

Guten Morgen!

Wir schließen dieses Problem hier auf GitHub im Rahmen unserer Migration zu UserVoice für Funktionsanfragen, die die AWS CLI betreffen.

Auf diese Weise können wir Ihnen die wichtigsten Funktionen zur Verfügung stellen, indem wir Ihnen die Suche und Unterstützung für die Funktionen erleichtern, die Ihnen am wichtigsten sind, ohne die Konversation mit Fehlerberichten zu verwässern.

Als kurze Einführung in UserVoice (falls noch nicht bekannt): Nachdem eine Idee veröffentlicht wurde, können die Leute über die Ideen abstimmen und das Produktteam reagiert direkt auf die beliebtesten Vorschläge.

Wir haben vorhandene Funktionsanfragen von GitHub importiert – suchen Sie dort nach diesem Problem!

Und keine Sorge, dieses Problem wird der Nachwelt zuliebe weiterhin auf GitHub existieren. Da es sich um einen Nur-Text-Import des ursprünglichen Beitrags in UserVoice handelt, werden wir die Kommentare und Diskussionen, die bereits hier zur GitHub-Ausgabe existieren, im Hinterkopf behalten.

GitHub bleibt der Kanal zum Melden von Fehlern.

Auch diese Ausgabe kann nun wieder gefunden werden, indem Sie nach dem Titel suchen unter: https://aws.uservoice.com/forums/598381-aws-command-line-interface

-Das AWS SDKs & Tools-Team

Dieser Eintrag ist speziell auf UserVoice zu finden unter: https://aws.uservoice.com/forums/598381-aws-command-line-interface/suggestions/33168409-allow-cloudformation-deploy-to-accept-a-paramater

+1 für diese Funktion. Vielen Dank!

Basierend auf dem Feedback der Community haben wir uns entschieden, Funktionsanfragen an GitHub-Probleme zurückzugeben.

Falls jemand nach einer Problemumgehung sucht, können Sie versuchen, folgt zu verwenden :
aws cloudformation deploy --parameter-overrides $(jq -r '.[] | [.ParameterKey, .ParameterValue] | join("=")' param.json) ...
Basierend auf Ihren Parameterwerten kann weitere Escape-Operation erforderlich sein.

Ich werde dieser Funktion auch +1 geben.

Ich ersetze jq jp wo immer möglich durch JMESPath ist es wert, gelernt zu werden.

$ 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

Da die AWS CodePipeline CloudFormation-Bereitstellungsaktion ein bestimmtes Vorlagenkonfigurationsdateiformat erfordert, wäre es gut, wenn Sie auch dieses Format unterstützen könnten.

+1 dafür. Ich verstehe, dass Sie "aws cloudformation deploy" einfach halten möchten, aber dieser Befehl verfügt bereits über individuelle Befehlszeilen-Flags für Funktionen, Tags und Parameter (wie alle anderen aws-cloudformation-Befehle), aber Sie haben sie anders funktionieren lassen (nur eine Liste von akzeptieren) string=string in der Befehlszeile statt einer JSON-Struktur in einer Datei). Sie sollten dafür sorgen, dass alle "aws cloudformation"-Befehle konsistent funktionieren (einschließlich der Verwendung von cli-input-json wie fast allen aws-CLI-Befehlen). Wenn Sie eine Vereinfachung des Tag-Konstrukts für "aws cloudformation deploy" wünschen, sollten Sie ein anderes Befehlszeilen-Flag wie --tags-overrides oder --parameters-overrides einführen.

👍 auf die Feature-Anfrage, wäre toll, wenn dies unterstützt würde.

Das wäre ein tolles Feature! Es würde Idempotency beim Erstellen von cf-Stacks mit dem cli erheblich vereinfachen 👍

+1

+1

+1

@ColdFire87 @dan-lind @mnwk kannst du bitte nur die erste Ausgabe und aufhören, denjenigen zu spammen, der diese Ausgabe abonniert hat? Jeder Kommentar mit 👍 pingt 20 Personen....
(Entschuldigung für andere, aber das müssen wir bekämpfen...)

@pierreozoux Tut

Was @cervantek sagte. Ich möchte nur hinzufügen, dass ich hoffe, dass dieses Ticket die Implementierung all dieser Optionen aus Konsistenzgründen mit create-stack :

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

Viele Leute wie ich haben Legacy-Code, der mit create-stack und update-stack und sie werden ihn umschreiben wollen, um deploy . Es sollte nicht so schwer sein.

+1 bis --parameters unterstützt die JSON-Datei.

Unser Team hat vor kurzem damit begonnen, Cloudformation-Vorlagen zu generieren, die groß genug waren, um einen Upload in einen S3-Bucket zu erfordern Parameterdatei, um mit diesem neuen Befehl zu arbeiten. +1 für diese Funktion

+1 für diese Funktion

+1

+1

+1

+1

@olivier-schmitt-sonarsource @anshul0915 @lmunro @MiMo42 @markusbecker @benjammin12 und anderen in Zukunft bitte nur 👍 das übergeordnete Thema, anstatt diejenigen von uns, die den Thread abonniert haben, mit Kommentaren zu spammen, wenn Sie dem Thema nur +1 geben möchten. Vielen Dank.

👍

Eine andere Problemumgehung hierfür besteht darin, eine .ini-Datei mit einer Liste von key=value Parameterpaaren zu verwenden und die Bereitstellung mithilfe von:
aws cloudformation deploy --parameter-overrides $(cat parameters.ini)
das gleiche kann für Tags gemacht werden.

Eine andere Problemumgehung hierfür besteht darin, eine .ini-Datei mit einer Liste von key=value Parameterpaaren zu verwenden und die Bereitstellung mithilfe von:
aws cloudformation deploy --parameter-overrides $(cat parameters.ini)
das gleiche kann für Tags gemacht werden.

Dieser Ansatz ist schön und funktioniert! Um jedoch die Konsistenz mit allen anderen Befehlen zu wahren (die die Eingabe von 'json' unterstützen), wird empfohlen, die Parameter im Dateiformat 'json' zu belassen und die Datei speziell zu bearbeiten, bevor sie als Eingabe für das 'Bereitstellen' verwendet wird. Befehl. Dies kann mit dem Befehl 'jq' erreicht werden, der für alle gängigen Plattformen verfügbar ist .

Die Umrechnung kann ganz einfach erreicht werden mit:

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

Darüber hinaus kann es im laufenden Betrieb konvertiert und direkt als Eingabe für den Deploy-Befehl verwendet werden :

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

Ich hoffe es hilft!

Glücklicherweise wird dieses ganze Problem von CDK vollständig umgangen. Ich bin weitergezogen.

Ich habe versucht, von Create-Stack/Update-Stack auf die Bereitstellungsmethode umzusteigen, und habe dieses und andere Probleme bekommen - ich bin überrascht, dass es nach 3 Jahren immer noch nicht mit diesen alten Methoden übereinstimmt.

Ich bekomme Probleme mit der obigen Problemumgehung für Tag-Dateien, bei denen einige Tags Leerzeichen in ihren Werten enthalten. Ich bin mir sicher, dass dies lösbar ist, aber mein anderes Problem ist grundlegender - die Ausgabe dieses Befehls ist unstrukturiert. Um die Changeset-ID zu erhalten, muss ich eine unstrukturierte Textzeichenfolge analysieren. Ich halte das für sehr zwielichtig (!), zumal die create-change-set-Methode die ID in json zurückgibt.

Der Link zum Problem auf Uservoice in einer früheren Nachricht in diesem Thread ist tot - weiß jemand, wo dieses Problem derzeit verfolgt wird oder ob es überhaupt noch bearbeitet wird?

Leute, bitte erwägt die Implementierung dieser Funktion. Tricks mit cat oder Parameter über SSM als Workaround zu übergeben - dies ist eine unnötige Komplikation gegenüber einer sehr grundlegenden Funktionalität, und diese Funktionalität wird von so ziemlich jeder anderen Alternative zu CFN .

Ich bin auf diesen Thread gestoßen, als ich nach einer Lösung für die Übergabe von Parametern an create-stack und update-stack gesucht habe, aber ich gebe hier auch mein 👍, aber füge der Anfrage hinzu, dass wir eine Option zum Übergeben haben eine Datei, die dem JSON-Format folgt, das CodePipeline für CloudFormation akzeptiert.

Wenn Sie CodePipeline häufig für die Bereitstellung von CloudFormation verwenden, ist es bereits üblich, dass Ihre CloudFormation-Dateien im CodePipeline-Format in Ihren Repositorys festgeschrieben werden.

Dies funktioniert hervorragend, wenn Sie einen vollständigen CI/CD-Lauf über die Pipeline ausführen, führt jedoch zu einer sehr mühsamen lokalen Entwicklung. Ich habe einige Skripte, die das CodePipeline JSON in das JSON übersetzen können, das aws cloudformation create-stack und update-stack über --parameters file://params.json akzeptieren, und mit etwas zusätzlichem Aufwand können wahrscheinlich einige der Hacks funktionieren Die Leute oben haben mit jq und dergleichen erwähnt, aber das fühlt sich einfach wie ein Hack an.

Bitte setzen Sie dies um!

Bitte implementieren Sie dies! Komm schon AWS, das ist seit fast 3 Jahren geöffnet.

Äußerst ärgerlich und etwas mit dem Thema zu tun hat auch die Inkonsistenz zwischen den Formaten bei der Übergabe von CFN-Parametern über CLI .

Ich bin im Moment ein deploy Benutzer und konnte bisher mit Inline-Parametern über Tricks mit cat - dh --parameter-overrides $(shell cat configs/${LNMS_ENV}.properties) - damit durchkommen.

Das Problem trat auf, als ich beschloss, etwas Ähnliches wie plan von Terraform mit den Change Sets von CFN zu implementieren. Es stellte sich heraus, dass aws cloudformation create-change-set Parameter überschreiben kann, aber erwartet, dass sie in einem anderen Format als deploy werden!

Laut CLI-Dokumentation für deploy es:

ParameterKey1=ParameterValue1

Laut CLI-Dokumentation für create-stack , update-stack und create-change-set es:

ParameterKey=string,ParameterValue=string

mit der Option, JSON bereitzustellen.

Ich verstehe wirklich nicht, warum sie unterschiedlich sind, warum deploy nicht das gleiche JSON-Format unterstützt und was soll ich tun - zwei im Wesentlichen die gleichen Parameterdateien für jede Umgebung beibehalten?

Dies ist ehrlich gesagt ein wirklich seltsames Design - keine Konsistenz und nicht zu rechtfertigende Motivation, die Verwendung von Parameterdateien zu vermeiden. Kleine (und es ist fraglich, ob sie klein sind) Dinge wie diese wirken sich wirklich auf die Produktivität aus.

PS Ich habe nicht bemerkt, dass

+1

Die Abenteuer von Captain Consistency gehen weiter.

Während wir mit der Verwendung von cat davonkommen können, um Konfigurationen für deploy in einem Format zu speichern, das auch mit update-stack kompatibel ist:

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

Der Aktionstyp CodePipeline mit Deploy:CloudFormation verwendet ein anderes Dateiformat zur Übergabe an CFN:

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

Keine weiteren Kommentare... Wirklich müde, immer und immer wieder auf das gleiche Problem zu stoßen. Das ist schlecht.

Am Ende hatten wir nur einzeilige Shell-Skripte zum Aufrufen von aws cloudformation deploy die zusammen mit den Dateien für CodePipeline gepflegt wurden, anstatt cat oder jq Spielereien.

Ich denke, dies ist eines der Probleme, die sie nicht beheben werden, vielleicht weil ihr Fokus jetzt auf der CDK liegt?

Wie auch immer, ich habe es aufgegeben zu warten und zu versuchen, die Bereitstellung zu tun, um das zu tun, was ich dachte, es sollte tun, und am Ende tat ich das, was die meisten anderen meiner Meinung nach getan haben - mein eigenes "Upsert" -Bash-Skript mit den Befehlen zum Erstellen und Aktualisieren von Stack-Cli-Befehlen zu schreiben. 100 Zeilen lang, aber jetzt funktioniert es zumindest!

Hallo, ich brauche das wirklich. Ich bin wirklich enttäuscht, diese Situation zu sehen, in der Leute seit Jahren darum bitten, aber CloudFormation noch nicht bereitgestellt hat. Was für eine Idee das Team antreibt das ist akzeptabel.....

Hey, es tut uns wirklich leid, dass es so lange gedauert hat, bis dieses Problem gelöst wurde.

Könnten Sie bitte einen Blick auf die Beschreibung der PR werfen und uns Ihre Meinung zu einer solchen Lösung mitteilen.

Außerdem scheint es (zumindest in der Windows-Eingabeaufforderungs-CLI) keine einfache Möglichkeit zu geben, einen mehrzeiligen Parameter bereitzustellen.

Ich würde hoffen, dass mit der Implementierung dieser Parameterdateifunktion das Problem mit den mehrzeiligen Parametern vermieden wird.

Vielen Dank für die tolle Arbeit Jungs!

Hallo, dieser PR wurde zusammengeführt und in AWS CLI v.2.0.39 veröffentlicht.

@vz10 Danke für das Update.

Übrigens, wissen Sie zufällig, ob diese Implementierung (über eine Parameterdatei) mehrzeilige Parameter zulässt? Dies war eines der Dinge, die ich in der Windows-Batch-Umgebung mit AWS CLI nicht bewältigen konnte.

Vielen Dank für Ihre Hilfe im Voraus!

@bs-thomas Ich habe es nicht mit mehrzeiligen Parametern getestet. Aber ich glaube, wenn das JSON-Format es unterstützt, wird es gut funktionieren.

Es wäre toll, wenn Sie es ausprobieren und uns ein Feedback geben könnten.

Dankeschön.

@vz10 Mehrzeilig funktioniert tatsächlich. Mit \n . sieht es jedoch sehr hässlich aus

Eigentlich wäre es cool, wenn CLI das YAML-Format für die CLI-Parameter-Overrides unterstützen könnte ;-)

@bs-thomas es sieht aus wie eine weitere Funktionsanfrage.

Erstellen Sie es einfach und es ist die halbe Miete, Parameter-Overrides YAML verstehen zu lassen ;)

@vz10 Klar, das mache ich gleich.

Übrigens, mir ist beim JSON-Validator etwas Unangenehmes aufgefallen. Es akzeptiert keine ganzzahligen oder booleschen Werte. Wenn ich sie habe, muss sie als String angegeben werden, sonst bekomme ich diese Antwort:

Dann!

@bs-thomas ja, es ist ein bisschen seltsam, aber es ist das gleiche Verhalten, das cloudformation create-stack erwartet - alle Werte sind Strings und es analysiert sie danach und es hat keinen booleschen Parametertyp