Aws-cli: Permitir que la implementación de cloudformation acepte un archivo de parámetro

Mirando el código, parece que solo necesitamos algo por aquí.

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

que se lee en un archivo JSON, tal vez una verificación rápida de cordura, luego lo pasa a deploy() .

Marcado como una solicitud de función para la implementación de formación en la nube.

@sanathkr pensamientos?

esperando esta característica 👍

También me gustaría la función para acciones package . ¡Gracias! 👍

Pasar un archivo de parámetros a través de algo como --parameters como en los comandos create-stack y update-stack CF (e idealmente usar la misma sintaxis de contenido de archivo) facilitaría un poco el desarrollo de plantillas CF me. Me encantaría ver esa característica.

+1 para esta función. ¡Gracias!

¡Buenos días!

Cerramos este problema aquí en GitHub, como parte de nuestra migración a UserVoice para solicitudes de funciones relacionadas con la AWS CLI.

Esto nos permitirá ofrecerle las funciones más importantes, al facilitar la búsqueda y mostrar soporte para las funciones que más le interesan, sin diluir la conversación con informes de errores.

Como introducción rápida a UserVoice (si no está familiarizado): después de que se publica una idea, la gente puede votar sobre las ideas y el equipo de producto responderá directamente a las sugerencias más populares.

Hemos importado solicitudes de funciones existentes desde GitHub: busque este problema allí.

Y no se preocupe, este problema seguirá existiendo en GitHub por el bien de la posteridad. Como es una importación de solo texto de la publicación original en UserVoice, seguiremos teniendo en cuenta los comentarios y la discusión que ya existen aquí sobre el problema de GitHub.

GitHub seguirá siendo el canal para informar errores.

Una vez más, este problema ahora se puede encontrar buscando el título en: https://aws.uservoice.com/forums/598381-aws-command-line-interface

-El equipo de herramientas y SDK de AWS

Esta entrada se puede encontrar específicamente en UserVoice en: https://aws.uservoice.com/forums/598381-aws-command-line-interface/suggestions/33168409-allow-cloudformation-deploy-to-accept-a-paramater

+1 para esta función. ¡Gracias!

Según los comentarios de la comunidad, hemos decidido devolver las solicitudes de funciones a los problemas de GitHub.

En caso de que alguien esté buscando una solución alternativa, puede intentar usar jq , así:
aws cloudformation deploy --parameter-overrides $(jq -r '.[] | [.ParameterKey, .ParameterValue] | join("=")' param.json) ...
Es posible que sea necesario escapar más en función de los valores de sus parámetros.

También voy a hacer +1 en esta función.

Reemplazo jq con jp siempre que sea posible. Vale la pena aprender sobre

$ 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

Dado que la acción de implementación de AWS CodePipeline CloudFormation requiere un formato de archivo de configuración de plantilla específico , sería bueno si también pudiera admitir este formato.

+1 para esto. Entiendo que desee mantener la "implementación de aws cloudformation" simple, pero este comando ya tiene indicadores de línea de comando individuales para capacidades, etiquetas y parámetros (como todos los demás comandos de aws cloudformation), pero ha hecho que funcionen de manera diferente (solo acepta la lista de string = string en la línea de comando, en lugar de una estructura JSON en un archivo). Debe hacer que todos los comandos de "aws cloudformation" funcionen de manera coherente (incluido el uso de cli-input-json como casi todos los comandos de la CLI de aws). si desea una simplificación de la construcción de etiquetas para "aws cloudformation deploy", debe introducir una marca de línea de comando diferente, como --tags-overrides o --parameters-overrides.

👍 en la solicitud de función, sería genial si esto fuera compatible.

¡Esta sería una gran característica para tener! Simplificaría enormemente Idempotency al crear pilas de cf con cli 👍

+1

+1

+1

@ ColdFire87 @ dan-lind @mnwk, ¿ podría, por favor, enviar el primer número y dejar de enviar spam a quien esté suscrito a este número? Cada comentario con 👍 hace ping a 20 personas ...
(Lo siento por los demás, pero tenemos que luchar contra eso ...)

@pierreozoux Lo siento, no quise molestar a la gente :)

Lo que dijo @cervantek . Solo quiero agregar que espero que este ticket rastree la implementación de todas estas opciones para mantener la coherencia con create-stack :

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

Muchas personas como yo tendrán un código heredado que fue escrito usando create-stack y update-stack y querrán reescribirlo para usar deploy . No debería ser tan difícil.

+1 a --parameters admite archivos JSON.

Nuestro equipo comenzó recientemente a generar plantillas de formación en la nube que eran lo suficientemente grandes como para requerir una carga en un depósito de S3, por lo que ahora estamos haciendo la transición de create-stack y update-stack a deploy ... y nos encontramos con el mismo problema de migrar nuestro archivo de parámetros para trabajar con este nuevo comando. +1 para esta función

+1 para esta función

+1

+1

+1

+1

@ olivier-schmitt-sonarsource @ anshul0915 @lmunro @ MiMo42 @markusbecker @ benjammin12 y otros en el futuro, solo 👍 el problema principal en lugar de enviar spam a aquellos de nosotros suscritos al hilo con comentarios si solo quieres hacer +1 en el problema. Gracias.

👍

otra solución alternativa para esto es usar un archivo .ini con una lista de pares de parámetros key=value , e implementar usando:
aws cloudformation deploy --parameter-overrides $(cat parameters.ini)
se puede hacer lo mismo con las etiquetas.

otra solución alternativa para esto es usar un archivo .ini con una lista de pares de parámetros key=value , e implementar usando:
aws cloudformation deploy --parameter-overrides $(cat parameters.ini)
se puede hacer lo mismo con las etiquetas.

¡Este enfoque es bueno y funciona! Sin embargo, para mantener la coherencia con todos los demás comandos (que admiten la entrada 'json'), el consejo es mantener los parámetros en formato de archivo 'json' y manipular específicamente el archivo antes de usarlo como entrada para el 'despliegue' mando. Esto se puede lograr con el comando 'jq' que está disponible para todas las plataformas más comunes .

La conversión se puede lograr fácilmente con:

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

Además, se puede convertir sobre la marcha y utilizar directamente como entrada para el comando de implementación :

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

¡Espero eso ayude!

Afortunadamente, CDK evita por completo este problema. He seguido adelante.

He intentado pasar al método de implementación de create-stack / update-stack y he tenido este y otros problemas; me sorprende que después de 3 años todavía no tenga paridad con esos métodos antiguos.

Tengo problemas al usar la solución anterior para los archivos de etiquetas donde algunas etiquetas tienen espacios en sus valores. Estoy seguro de que esto se puede resolver, pero mi otro problema es más fundamental: la salida de este comando no está estructurada, por lo que para obtener la identificación del conjunto de cambios tengo que analizar una cadena de texto no estructurada. Considero que esto es muy dudoso (!) Especialmente porque el método create-change-set devuelve la identificación en json.

El enlace al problema en la voz del usuario en un mensaje anterior en este hilo está inactivo: ¿alguien sabe dónde se está rastreando este problema actualmente o si aún se está trabajando en él?

Chicos, consideren implementar esta función. Usar trucos con cat o pasar parámetros a través de SSM como solución alternativa: es una complicación innecesaria sobre una funcionalidad muy básica, y dicha funcionalidad es compatible con casi todas las demás alternativas a CFN .

Me encontré con este hilo mientras buscaba una solución para pasar parámetros a create-stack y update-stack , pero también daré mi 👍 aquí, pero agregando a la solicitud que tenemos una opción para pasar un archivo que sigue el formato JSON que CodePipeline acepta para CloudFormation.

Si es un gran usuario de CodePipeline para implementar CloudFormation, ya es costumbre tener sus archivos de CloudFormation en el formato CodePipeline comprometidos dentro de sus repositorios.

Esto funciona muy bien cuando está ejecutando una ejecución completa de CI / CD a través de la canalización, pero hace que el desarrollo local sea muy tedioso. Tengo algunos scripts que pueden traducir CodePipeline JSON en JSON que aws cloudformation create-stack y update-stack aceptan a través de --parameters file://params.json , y con un poco de trabajo adicional probablemente pueda funcionar en algunos de los trucos la gente de arriba ha mencionado con jq y similares, pero eso se siente como un truco.

¡Implementa esto!

¡Implemente esto! Vamos AWS, esto ha estado abierto durante casi 3 años.

Otra cosa que es extremadamente molesta y algo relacionada con el tema es la inconsistencia entre formatos para suministrar parámetros CFN a través de CLI .

Soy un usuario de deploy en este momento, y hasta ahora había podido salirse con la suya usando parámetros en línea a través de trucos con cat , es decir, --parameter-overrides $(shell cat configs/${LNMS_ENV}.properties) .

El problema surgió cuando decidí implementar algo similar a plan de Terraform usando los conjuntos de cambios de CFN. Resulta que aws cloudformation create-change-set es capaz de anular los parámetros, ¡pero espera que se envíen en un formato diferente al de deploy !

Por documentación CLI por deploy es:

ParameterKey1=ParameterValue1

Por documentación CLI para create-stack , update-stack y create-change-set es:

ParameterKey=string,ParameterValue=string

con también una opción para suministrar JSON.

Realmente no entiendo por qué son diferentes, por qué deploy no admitirán el mismo formato JSON y qué se supone que debo hacer: mantener dos archivos de parámetros esencialmente iguales para cada entorno.

Honestamente, este es un diseño realmente extraño: no hay consistencia y una motivación injustificable para evitar el uso de archivos de parámetros. Pequeñas (y se puede argumentar que son pequeñas) cosas como esta realmente afectan la productividad.

PD: No me di cuenta de que sigue reinventando una rueda debido a la falta de funcionalidad básica :(

+1

Las aventuras de Captain Consistency continúan.

Si bien podemos salirse con la nuestra con el uso de cat para almacenar configuraciones para deploy en un formato que también es compatible con update-stack :

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

El tipo de acción CodePipeline con Deploy:CloudFormation usa otro formato de archivo para pasar a CFN:

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

No hay más comentarios ... Realmente cansado de enfrentar el mismo problema una y otra vez. Esto es malo.

terminamos teniendo scripts de shell de una línea para llamar a aws cloudformation deploy mantenidos junto con los archivos para CodePipeline, en lugar de cat o jq travesuras.

Creo que este es uno de esos problemas que no van a solucionar, ¿tal vez porque su enfoque ahora es el cdk?

de todos modos, dejé de esperar e intenté implementar calzador para hacer lo que pensé que debería hacer y terminé haciendo lo que creo que la mayoría de los demás han hecho: escribir mi propio script bash "upsert" usando los comandos create y update stack cli. ¡100 líneas de largo, pero al menos funciona ahora!

Hola, realmente necesito esto. Realmente me decepcionó ver esta situación, en la que las personas pidieron hacer esto durante años, pero CloudFormation aún no lo ha proporcionado. ¿Qué tipo de idea impulsa al equipo? Esto es aceptable ...

Oye, lamentamos mucho que haya tardado tanto en llegar a este problema.

¿Podría echar un vistazo a la descripción de las relaciones públicas y hacernos saber qué piensa acerca de dicha solución?

Además, parece que no hay una manera fácil (al menos en la CLI del símbolo del sistema de Windows) para proporcionar un parámetro de varias líneas.

Espero que con la implementación de esta función de archivo de parámetros, se guarde el problema de los parámetros de varias líneas.

¡Muchas gracias por el gran trabajo chicos!

Hola, este RP se fusionó y se lanzó en AWS CLI v.2.0.39.

@ vz10 Gracias por la actualización.

Por cierto, ¿sabe si esta implementación (a través de un archivo de parámetros) permite parámetros de varias líneas? Esta fue una de las cosas que no pude superar en el entorno por lotes de Windows que ejecuta AWS CLI.

¡Gracias por su ayuda de antemano!

@ bs-thomas No lo probé con parámetros de varias líneas. Pero creo que si el formato JSON lo admite, funcionará bien.

Sería genial si pudieras probarlo y darnos tu opinión.

Gracias.

@ vz10 Multi-line de hecho está funcionando. Sin embargo, se ve muy feo con \ n

En realidad, sería genial si CLI pudiera admitir el formato YAML para las invalidaciones de parámetros de CLI ;-)

@ bs-thomas parece otra solicitud de función.

Simplemente créelo y será la mitad de la batalla de hacer que las anulaciones de parámetros entiendan YAML;)

@ vz10 Seguro, lo haré de inmediato.

Por cierto, noté algo desagradable sobre el validador JSON. No acepta valores enteros ni booleanos. Entonces, si los tengo, debe especificarse como una cadena, de lo contrario obtendré esta respuesta:

¡Luego!

@ bs-thomas sí, es un poco extraño, pero es el mismo comportamiento que espera cloudformation create-stack : todos los valores son cadenas y las analiza después y no tiene un tipo de parámetro booleano