Aws-cli: Permitir implantação de cloudformation para aceitar um arquivo de parâmetro

Olhando para o código, parece que só precisamos de algo por aqui

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

que lê um arquivo JSON, talvez uma verificação rápida de integridade, e o passa adiante para deploy() .

Marcando como uma solicitação de recurso para implantação de cloudformation.

pensamentos @sanathkr ?

esperando por este recurso 👍

Eu também gostaria do recurso para package ações. Obrigado! 👍

Passar um arquivo de parâmetros por meio de algo como --parameters como nos comandos create-stack e update-stack CF (e de preferência usando a mesma sintaxe de conteúdo de arquivo) tornaria o desenvolvimento de modelos CF um pouco mais fácil para mim. Adoraria ver esse recurso.

1 para este recurso. Obrigado!

Bom Dia!

Estamos encerrando esse problema aqui no GitHub, como parte de nossa migração para o UserVoice para solicitações de recursos envolvendo o AWS CLI.

Isso nos permitirá fornecer os recursos mais importantes para você, tornando mais fácil pesquisar e mostrar suporte para os recursos que você mais gosta, sem diluir a conversa com relatórios de bug.

Como uma cartilha rápida do UserVoice (se ainda não for familiar): depois que uma ideia é postada, as pessoas podem votar nas ideias e a equipe do produto responderá diretamente às sugestões mais populares.

Importamos solicitações de recursos existentes do GitHub - procure por este problema lá!

E não se preocupe, esse problema ainda existirá no GitHub para o bem da posteridade. Como é uma importação somente de texto da postagem original para o UserVoice, ainda teremos em mente os comentários e a discussão que já existem aqui sobre o problema do GitHub.

O GitHub continuará sendo o canal para relatar bugs.

Mais uma vez, esse problema agora pode ser encontrado pesquisando o título em: https://aws.uservoice.com/forums/598381-aws-command-line-interface

- A equipe de SDKs e ferramentas da AWS

Esta entrada pode ser encontrada especificamente no UserVoice em: https://aws.uservoice.com/forums/598381-aws-command-line-interface/suggestions/33168409-allow-cloudformation-deploy-to-accept-a-paramater

1 para este recurso. Obrigado!

Com base no feedback da comunidade, decidimos retornar as solicitações de recursos para os problemas do GitHub.

Caso alguém esteja procurando uma solução alternativa, você pode tentar usar jq , assim:
aws cloudformation deploy --parameter-overrides $(jq -r '.[] | [.ParameterKey, .ParameterValue] | join("=")' param.json) ...
Escape adicional pode ser necessário com base em seus valores de parâmetro.

Também vou marcar este recurso com +1.

Estou substituindo jq por jp sempre que possível. Vale a pena aprender

$ 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

Considerando que a ação de implantação do AWS CodePipeline CloudFormation requer um formato de arquivo de configuração de modelo específico , seria bom se você também pudesse oferecer suporte a esse formato.

1 para isso. Eu entendo querer manter "aws cloudformation deploy" simples, mas este comando já tem sinalizadores de linha de comando individuais para recursos, tags e parâmetros (como todos os outros comandos aws cloudformation), mas você os fez funcionar de maneira diferente (aceitando apenas a lista de string = string na linha de comando, em vez de uma estrutura JSON em um arquivo). Você deve fazer com que todos os comandos "aws cloudformation" funcionem de forma consistente (incluindo o uso de cli-input-json como quase todos os comandos aws CLI). se você quiser uma simplificação da construção de tags para "aws cloudformation deploy", deve introduzir um sinalizador de linha de comando diferente, como --tags-overrides ou --parameters-overrides.

👍 na solicitação de recurso, seria ótimo se isso fosse compatível.

Esse seria um ótimo recurso de se ter! Isso simplificaria muito a idempotência ao criar pilhas cf com o cli 👍

+1

+1

+1

@ ColdFire87 @ dan-lind @mnwk você pode, por favor, apenas 👍 a primeira edição e parar de enviar spam para quem está inscrito nesta edição? Cada comentário com 👍 está pingando 20 pessoas ....
(Desculpe pelos outros, mas temos que lutar contra isso ...)

@pierreozoux Desculpe, não tive a

O que @cervantek disse. Só quero acrescentar que espero que este tíquete acompanhe a implementação de todas essas opções para consistência com create-stack :

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

Muitas pessoas como eu terão código legado que foi escrito usando create-stack e update-stack e eles vão querer reescrevê-lo para usar deploy . Não deveria ser tão difícil.

+1 para --parameters suporta arquivo JSON.

Nossa equipe recentemente começou a gerar modelos de cloudformation que eram grandes o suficiente para exigir um upload para um intervalo S3, então agora estamos fazendo a transição de create-stack e update-stack para implantar ... e estamos enfrentando o mesmo problema de migração de nosso arquivo de parâmetros para trabalhar com este novo comando. +1 para este recurso

+1 para este recurso

+1

+1

+1

+1

@ olivier-schmitt-sonarsource @ anshul0915 @lmunro @ MiMo42 @markusbecker @ benjammin12 e outros no futuro, apenas 👍 o problema pai em vez de enviar comentários para aqueles de nós inscritos no tópico, se você apenas quiser marcar o problema com +1. Obrigado.

👍

outra solução alternativa para isso é usar um arquivo .ini com uma lista de key=value pares de parâmetros e implantar usando:
aws cloudformation deploy --parameter-overrides $(cat parameters.ini)
o mesmo pode ser feito para tags.

outra solução alternativa para isso é usar um arquivo .ini com uma lista de key=value pares de parâmetros e implantar usando:
aws cloudformation deploy --parameter-overrides $(cat parameters.ini)
o mesmo pode ser feito para tags.

Essa abordagem é boa e funciona! No entanto, para manter a consistência com todos os outros comandos (que suportam a entrada 'json'), o conselho é manter os parâmetros no formato de arquivo 'json' e manipular especificamente o arquivo antes de usá-lo como entrada para o 'implantar' comando. Isso pode ser feito com o comando 'jq', que está disponível para todas as plataformas mais comuns .

A conversão pode ser facilmente alcançada com:

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

Além disso, pode ser convertido em tempo real e usado diretamente como entrada para o comando de implantação :

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

Espero que ajude!

Felizmente, todo esse problema é completamente evitado pelo CDK. Eu segui em frente.

Tenho tentado mudar para o método de implantação de create-stack / update-stack e tenho recebido esse e outros problemas - estou surpreso depois de 3 anos, ele ainda não tem paridade com os métodos antigos.

Estou tendo problemas ao usar a solução alternativa acima para arquivos de tags em que algumas tags têm espaços em seus valores. Tenho certeza de que isso pode ser resolvido, mas meu outro problema é mais fundamental - a saída desse comando não é estruturada, portanto, para obter a id do changeset, preciso analisar uma string de texto não estruturada. Eu considero isso muito duvidoso (!), Especialmente porque o método create-change-set retorna o id em json.

O link para o problema no uservoice em uma mensagem anterior neste tópico está morto - alguém sabe onde esse problema está sendo rastreado ou se ainda está sendo trabalhado?

Pessoal, por favor, considerem a implementação deste recurso. Usar truques com cat ou passar parâmetros por SSM como uma solução alternativa - é uma complicação desnecessária em relação a uma funcionalidade muito básica, e tal funcionalidade é suportada por praticamente todas as outras alternativas a CFN .

Me deparei com este tópico enquanto procurava uma solução para passar parâmetros para create-stack e update-stack , mas vou dar meu 👍 aqui também, mas adicionando à solicitação que temos uma opção de passar um arquivo que segue o formato JSON que CodePipeline aceita para CloudFormation.

Se você é um usuário frequente de CodePipeline para implantar CloudFormation, já é comum ter seus arquivos CloudFormation no formato CodePipeline confirmados em seus repositórios.

Isso funciona muito bem quando você está executando um CI / CD completo por meio do pipeline, mas torna o desenvolvimento local muito tedioso. Eu tenho alguns scripts que podem traduzir o CodePipeline JSON em JSON que aws cloudformation create-stack e update-stack aceitam via --parameters file://params.json , e com algum trabalho extra provavelmente pode funcionar em alguns dos hacks o pessoal acima mencionou jq e similares, mas isso parece um hack.

Por favor, implemente isso!

Por favor, implemente isso! Vamos AWS, isso está aberto há quase 3 anos.

Outra coisa extremamente incômoda e um tanto relacionada ao assunto é a inconsistência entre os formatos de fornecimento de parâmetros CFN via CLI .

Eu sou um usuário deploy no momento e até agora tinha conseguido me safar usando parâmetros inline por meio de truques com cat - ou seja, --parameter-overrides $(shell cat configs/${LNMS_ENV}.properties) .

O problema surgiu quando decidi implementar algo semelhante ao plan do Terraform usando os conjuntos de alterações do CFN. Acontece que aws cloudformation create-change-set é capaz de sobrescrever parâmetros, mas espera que eles sejam enviados em um formato diferente de deploy !

De acordo com a documentação CLI para deploy , é:

ParameterKey1=ParameterValue1

De acordo com a documentação CLI para create-stack , update-stack e create-change-set é:

ParameterKey=string,ParameterValue=string

com também a opção de fornecer JSON.

Eu realmente não entendo por que eles são diferentes, por que deploy não suportam o mesmo formato JSON, e o que devo fazer - manter dois arquivos essencialmente iguais para cada ambiente?

Este é um design realmente estranho - sem consistência e motivação injustificável para evitar o uso de arquivos de parâmetro. Coisas pequenas (e pode-se argumentar que são pequenas) coisas como essa realmente afetam a produtividade.

PS Não percebi que @ pablods90 assumiu isso, mas apenas prova que as pessoas continuam reinventando uma roda devido à falta de funcionalidade básica :(

+1

As aventuras do Capitão Consistência continuam.

Embora possamos usar cat para armazenar configurações de deploy em um formato que também seja compatível com update-stack :

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

O tipo de ação CodePipeline com Deploy:CloudFormation usa outro formato de arquivo para passar ao CFN:

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

Sem mais comentários ... Realmente cansado de ter o mesmo problema indefinidamente. Isto é mau.

acabamos tendo apenas scripts de shell de uma linha para chamar aws cloudformation deploy mantidos junto com os arquivos para CodePipeline, em vez de cat ou jq shenanigans.

Eu acho que esse é um daqueles problemas que eles não vão consertar, talvez porque o foco deles agora seja o cdk?

De qualquer forma, desisti de esperar e tentar implantar o trabalho para fazer o que pensei que deveria fazer e acabei fazendo o que acho que a maioria dos outros fez - escrever meu próprio script bash "upsert" usando os comandos create e update stack cli. 100 linhas, mas pelo menos faz o trabalho agora!

Oi, eu realmente preciso disso. Eu realmente fiquei desapontado em ver esta situação, onde as pessoas pedem para fazer isso há anos, mas o CloudFormation ainda não forneceu. Que tipo de ideia impulsiona a equipe, isso é aceitável ...

Ei, lamentamos muito que tenha demorado tanto para chegar a este problema.

Você poderia dar uma olhada na descrição do PR e nos dizer o que você acha dessa solução.

Além disso, parece que não há uma maneira fácil (pelo menos na CLI do prompt de comando do Windows) de fornecer um parâmetro de várias linhas.

Eu espero que com a implementação deste recurso de arquivo de parâmetro, isso evite o problema de parâmetro multilinha.

Muito obrigado pelo ótimo trabalho galera!

Olá, este PR foi mesclado e lançado no AWS CLI v.2.0.39.

@ vz10 Obrigado pela atualização.

A propósito, você sabe se esta implementação (por meio de um arquivo de parâmetro) permite parâmetros multilinhas? Essa foi uma das coisas que eu não consegui passar no ambiente de lote do Windows executando o AWS CLI.

Obrigado pela sua ajuda antecipadamente!

@ bs-thomas não testei com parâmetros multilinhas. Mas acredito que se o formato JSON for compatível, funcionará bem.

Seria ótimo se você pudesse experimentar e nos dar um feedback.

Obrigada.

@ vz10 Multi-line realmente está funcionando. No entanto, parece muito feio com \ n

Na verdade, seria legal se a CLI pudesse suportar o formato YAML para as substituições de parâmetros da CLI ;-)

@ bs-thomas, parece outra solicitação de recurso.

Basta criá-lo e será metade da batalha para fazer as substituições de parâmetros entenderem YAML;)

@ vz10 Claro, farei isso imediatamente.

Aliás, percebi algo desagradável sobre o validador JSON. Não aceita valores inteiros nem booleanos. Portanto, se eu os tiver, ele deve ser especificado como uma string, caso contrário, receberei esta resposta:

Então!

@ bs-thomas sim, é um pouco estranho, mas é o mesmo comportamento que cloudformation create-stack espera - todos os valores são strings e ele os analisa depois e não tem tipo de parâmetro booleano