AWS CDK referênciaCLI - AWS Cloud Development Kit (AWS CDK) v2

Este é o Guia do Desenvolvedor AWS CDK v2. A versão CDK 1 mais antiga entrou em manutenção em 1º de junho de 2022 e encerrou o suporte em 1º de junho de 2023.

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

AWS CDK referênciaCLI

A interface de linha de AWS Cloud Development Kit (AWS CDK) comando (AWS CDK CLI), também conhecida como CDKToolkit, é a principal ferramenta para interagir com seu AWS CDK aplicativo. Ele executa seu aplicativo, interroga o modelo de aplicativo que você definiu e produz e implanta os AWS CloudFormation modelos gerados pelo. AWS CDK Ele também fornece outros recursos úteis para criar e trabalhar com AWS CDK projetos. Este tópico contém informações sobre casos de uso comuns do CDKCLI.

O CDK CLI é instalado com o Node Package Manager. Na maioria dos casos, recomendamos instalá-lo globalmente.

npm install -g aws-cdk # install latest version npm install -g aws-cdk@X.YY.Z # install specific version
dica

Se você trabalha regularmente com várias versões do AWS CDK, considere instalar uma versão correspondente do CDK CLI em CDK projetos individuais. Para fazer isso, omita -g do npm install comando. Em seguida, use npx aws-cdk para invocá-lo. Isso executa a versão local, se houver, voltando para uma versão global, se não existir.

CDKCLIcomandos

Todos os CDK CLI comandos começam comcdk, que é seguido por um subcomando (list,, synthesizedeploy, etc.). Alguns subcomandos têm uma versão mais curta (ls,synth, etc.) que é equivalente. As opções e os argumentos seguem o subcomando em qualquer ordem.

Para obter uma descrição de todos os subcomandos, opções e argumentos, consulteAWS CDKCLIReferência de comando.

Especifique as opções e seus valores

As opções da linha de comando começam com dois hífens ()--. Algumas opções usadas com frequência têm sinônimos de uma única letra que começam com um único hífen (por exemplo, --app tem um sinônimo-a). A ordem das opções em um CDK CLI comando não é importante.

Todas as opções aceitam um valor, que deve seguir o nome da opção. O valor pode ser separado do nome por espaço em branco ou por um sinal de igual. = As duas opções a seguir são equivalentes.

--toolkit-stack-name MyBootstrapStack --toolkit-stack-name=MyBootstrapStack

Algumas opções são bandeiras (booleanos). Você pode especificar true ou false como seu valor. Se você não fornecer um valor, o valor será consideradotrue. Você também pode prefixar o nome da opção com um prefixo no- para false implicar.

# sets staging flag to true --staging --staging=true --staging true # sets staging flag to false --no-staging --staging=false --staging false

Algumas opções, a saber--context,--parameters,--plugin, e --tags--trust, podem ser especificadas mais de uma vez para especificar vários valores. Eles são indicados como tendo a CDK CLI ajuda [array] digitada. Por exemplo:

cdk bootstrap --tags costCenter=0123 --tags responsibleParty=jdoe

Ajuda integrada

CDKCLITem ajuda integrada. Você pode ver a ajuda geral sobre o utilitário e uma lista dos subcomandos fornecidos emitindo:

cdk --help

Para ver a ajuda de um subcomando específico, por exemplodeploy, especifique-o antes do --help sinalizador.

cdk deploy --help

Problema cdk version para exibir a versão do CDKCLI. Forneça essas informações ao solicitar suporte.

Relatórios de versão

Para obter informações sobre como o AWS CDK é usado, as construções usadas pelos AWS CDK aplicativos são coletadas e relatadas usando um recurso identificado comoAWS::CDK::Metadata. Esse recurso é adicionado aos AWS CloudFormation modelos e pode ser facilmente revisado. Essas informações também podem ser usadas AWS para identificar pilhas usando uma construção com problemas conhecidos de segurança ou confiabilidade. Também pode ser usado para contatar seus usuários com informações importantes.

nota

Antes da versão 1.93.0, eles AWS CDK relatavam os nomes e versões dos módulos carregados durante a síntese, em vez das construções usadas na pilha.

Por padrão, ele AWS CDK relata o uso de construções nos seguintes NPM módulos que são usados na pilha:

  • AWS CDK módulo principal

  • AWS Construir módulos de biblioteca

  • AWS Módulo Solutions Constructs

  • AWS Módulo do kit de implantação do Render Farm

O AWS::CDK::Metadata recurso se parece com o seguinte.

CDKMetadata:
  Type: "AWS::CDK::Metadata"
  Properties:
    Analytics: "v2:deflate64:H4sIAND9SGAAAzXKSw5AMBAA0L1b2PdzBYnEAdio3RglglY60zQi7u6TWL/XKmNUlxeQSOKwaPTBqrNhwEWU3hGHiCzK0dWWfAxoL/Fd8mvk+QkS/0X6BdjnCdgmOOQKWz+AqqLDt2Y3YMnLYWwAAAA="

A Analytics propriedade é uma lista compactada com gzip, codificada em base64 e codificada por prefixo das construções na pilha.

Para optar por não receber relatórios de versão, use um dos seguintes métodos:

  • Use o cdk comando com o --no-version-reporting argumento para optar por não receber um único comando.

    cdk --no-version-reporting synth

    Lembre-se de que ele CDK CLI sintetiza novos modelos antes da implantação, portanto, você também deve adicionar aos --no-version-reporting comandos. cdk deploy

  • versionReportingDefina como false em ./cdk.json ou~/.cdk.json. Isso é desativado, a menos que você opte por meio de uma especificação --version-reporting em um comando individual.

    { "app": "...", "versionReporting": false }

Autenticação com AWS

Há diferentes maneiras de configurar o acesso programático aos AWS recursos, dependendo do ambiente e do AWS acesso disponível para você.

Para escolher seu método de autenticação e configurá-lo para o CDKCLI, consulteConfigure as credenciais de segurança para o AWS CDKCLI.

A abordagem recomendada para novos usuários que se desenvolvem localmente, que não recebem um método de autenticação do empregador, é configurar AWS IAM Identity Center. Esse método inclui a instalação do AWS CLI para facilitar a configuração e entrar regularmente no portal de AWS acesso. Se você escolher esse método, seu ambiente deverá conter os seguintes elementos depois de concluir o procedimento de autenticação do IAM Identity Center no Guia de Referência de Ferramentas AWS SDKs e Ferramentas:

  • O AWS CLI, que você usa para iniciar uma sessão do portal de AWS acesso antes de executar seu aplicativo.

  • Um AWSconfigarquivo compartilhado com um [default] perfil com um conjunto de valores de configuração que podem ser referenciados a AWS CDK partir do. Para encontrar a localização desse arquivo, consulte Localização dos arquivos compartilhados no Guia de referência de ferramentas AWS SDKs e ferramentas.

  • O arquivo config compartilhado define a configuração do region. Isso define o CDK CLI uso padrão Região da AWS de AWS CDK e para AWS solicitações.

  • O CDK CLI usa a configuração do provedor de SSO token do perfil para adquirir credenciais antes de enviar solicitações para AWS. O sso_role_name valor, que é uma IAM função conectada a um conjunto de permissões do IAM Identity Center, deve permitir o acesso ao Serviços da AWS usado em seu aplicativo.

    O config arquivo de exemplo a seguir mostra um perfil padrão configurado com a configuração SSO do provedor de token. A configuração sso_session do perfil se refere à seção do sso-session. A sso-session seção contém configurações para iniciar uma sessão do portal de AWS acesso.

    [default] sso_session = my-sso sso_account_id = 111122223333 sso_role_name = SampleRole region = us-east-1 output = json [sso-session my-sso] sso_region = us-east-1 sso_start_url = https://provided-domain.awsapps.com/start sso_registration_scopes = sso:account:access

Iniciar uma sessão do portal de AWS acesso

Antes de acessar Serviços da AWS, você precisa de uma sessão ativa do portal de AWS acesso para usar CDK CLI a autenticação do IAM Identity Center para resolver as credenciais. Dependendo da duração da sessão configurada, seu acesso acabará expirando e CDK CLI ocorrerá um erro de autenticação. Execute o comando a seguir no AWS CLI para entrar no portal de AWS acesso.

aws sso login

Se a configuração do seu provedor de SSO token estiver usando um perfil nomeado em vez do perfil padrão, o comando seráaws sso login --profile NAME. Especifique também esse perfil ao emitir cdk comandos usando a --profile opção ou a variável de AWS_PROFILE ambiente.

Para testar se você já tem uma sessão ativa, execute o AWS CLI comando a seguir.

aws sts get-caller-identity

A resposta a esse comando deve relatar a conta e o conjunto de permissões do IAM Identity Center configurados no config arquivo compartilhado.

nota

Se você já tiver uma sessão ativa do portal de AWS acesso e executá-laaws sso login, não será necessário fornecer credenciais.

O processo de login pode solicitar que você permita o AWS CLI acesso aos seus dados. Como o AWS CLI é construído em cima do SDK for Python, as mensagens de permissão podem conter variações do botocore nome.

Especificar região e outra configuração

É CDK CLI necessário conhecer a AWS região em que você está implantando e como se autenticar. AWS Isso é necessário para operações de implantação e para recuperar valores de contexto durante a síntese. Juntas, sua conta e sua região compõem o ambiente.

A região pode ser especificada usando variáveis de ambiente ou em arquivos de configuração. Essas são as mesmas variáveis e arquivos usados por outras AWS ferramentas, como a AWS CLI e as várias AWS SDKs. O CDK CLI procura essas informações na seguinte ordem.

  • A variável de ambiente AWS_DEFAULT_REGION.

  • Um perfil nomeado definido no AWS config arquivo padrão e especificado usando a --profile opção nos cdk comandos.

  • A [default] seção do AWS config arquivo padrão.

Além de especificar a AWS autenticação e uma região na [default] seção, você também pode adicionar uma ou mais [profile NAME] seções, onde NAME é o nome do perfil. Para obter mais informações sobre perfis nomeados, consulte Arquivos de configuração e credenciais compartilhados no Guia de referência de ferramentas AWS SDKs e ferramentas.

O AWS config arquivo padrão está localizado em ~/.aws/config (macOS/Linux) ou %USERPROFILE%\.aws\config (Windows). Para obter detalhes e localizações alternativas, consulte Localização dos arquivos compartilhados de configuração e credenciais no Guia de referência de ferramentas AWS SDKs e ferramentas

O ambiente que você especifica no seu AWS CDK aplicativo usando a env propriedade da pilha é usado durante a síntese. Ele é usado para gerar um AWS CloudFormation modelo específico do ambiente e, durante a implantação, substitui a conta ou a região especificada por um dos métodos anteriores. Para obter mais informações, consulte Ambientes para o AWS CDK.

nota

O AWS CDK usa credenciais dos mesmos arquivos de origem de outras AWS ferramentas eSDKs, incluindo o. AWS Command Line Interface No entanto, eles AWS CDK podem se comportar de forma um pouco diferente dessas ferramentas. Ele usa a parte de AWS SDK for JavaScript baixo do capô. Para obter detalhes completos sobre a configuração de credenciais para o AWS SDK for JavaScript, consulte Configuração de credenciais.

Opcionalmente, você pode usar a opção --role-arn (ou-r) para especificar uma IAM função que deve ser usada para implantação. ARN Essa função deve ser assumida pela AWS conta que está sendo usada.

Especifique o comando do aplicativo

Muitos recursos do CDK CLI exigem que um ou mais AWS CloudFormation modelos sejam sintetizados, o que, por sua vez, exige a execução do aplicativo. O AWS CDK suporta programas escritos em vários idiomas. Portanto, ele usa uma opção de configuração para especificar o comando exato necessário para executar seu aplicativo. Essa opção pode ser especificada de duas maneiras.

Primeiro, e mais comumente, ele pode ser especificado usando a app chave dentro do arquivocdk.json. Isso está no diretório principal do seu AWS CDK projeto. O CDK CLI fornece um comando apropriado ao criar um novo projeto comcdk init. Aqui está o cdk.json de um novo TypeScript projeto, por exemplo.

{ "app": "npx ts-node bin/hello-cdk.ts" }

O CDK CLI procura cdk.json no diretório de trabalho atual ao tentar executar seu aplicativo. Por isso, você pode manter um shell aberto no diretório principal do seu projeto para emitir CDK CLI comandos.

Ele CDK CLI também procura a chave do aplicativo ~/.cdk.json (ou seja, no seu diretório inicial) se não conseguir encontrá-la./cdk.json. Adicionar o comando do aplicativo aqui pode ser útil se você costuma trabalhar com CDK código no mesmo idioma.

Se você estiver em algum outro diretório ou quiser executar seu aplicativo usando um comando diferente daquele emcdk.json, use a opção --app (ou-a) para especificá-lo.

cdk --app "npx ts-node bin/hello-cdk.ts" ls

Ao implantar, você também pode especificar um diretório contendo assemblies de nuvem sintetizados, comocdk.out, como o valor de. --app As pilhas especificadas são implantadas a partir desse diretório; o aplicativo não é sintetizado.

Especifique pilhas

Muitos CDK CLI comandos (por exemplo,cdk deploy) funcionam em pilhas definidas no seu aplicativo. Se seu aplicativo contiver apenas uma pilha, CDK CLI pressupõe que você se refira a essa pilha se não especificar uma pilha explicitamente.

Caso contrário, você deverá especificar a pilha ou pilhas com as quais deseja trabalhar. Você pode fazer isso especificando as pilhas desejadas por ID individualmente na linha de comando. Lembre-se de que o ID é o valor especificado pelo segundo argumento quando você instancia a pilha.

cdk synth PipelineStack LambdaStack

Você também pode usar curingas para especificar IDs que correspondem a um padrão.

  • ?corresponde a qualquer caractere único

  • *corresponde a qualquer número de caracteres (*sozinho corresponde a todas as pilhas)

  • **corresponde a tudo em uma hierarquia

Você também pode usar a --all opção para especificar todas as pilhas.

Se seu aplicativo usa CDKPipelines, CDK CLI ele entende suas pilhas e estágios como uma hierarquia. Além disso, a --all opção e o * curinga correspondem apenas às pilhas de nível superior. Para combinar todas as pilhas, use**. Use também ** para indicar todas as pilhas em uma determinada hierarquia.

Ao usar curingas, coloque o padrão entre aspas ou escape dos curingas com. \ Caso contrário, seu shell pode tentar expandir o padrão para os nomes dos arquivos no diretório atual. Na melhor das hipóteses, isso não fará o que você espera; na pior das hipóteses, você pode implantar pilhas que não pretendia. Isso não é estritamente necessário no Windows porque cmd.exe não expande os curingas, mas ainda assim é uma boa prática.

cdk synth "*Stack" # PipelineStack, LambdaStack, etc. cdk synth 'Stack?' # StackA, StackB, Stack1, etc. cdk synth \* # All stacks in the app, or all top-level stacks in a CDK Pipelines app cdk synth '**' # All stacks in a CDK Pipelines app cdk synth 'PipelineStack/Prod/**' # All stacks in Prod stage in a CDK Pipelines app
nota

A ordem na qual você especifica as pilhas não é necessariamente a ordem em que elas serão processadas. Ele CDK CLI contabiliza as dependências entre as pilhas ao decidir a ordem na qual processá-las. Por exemplo, digamos que uma pilha usa um valor produzido por outra (como o ARN de um recurso definido na segunda pilha). Nesse caso, a segunda pilha é sintetizada antes da primeira devido a essa dependência. Você pode adicionar dependências entre as pilhas manualmente usando o método da pilha. addDependency()

Inicialize seu ambiente AWS

A implantação de pilhas com o CDK exige que AWS CDK recursos especiais dedicados sejam provisionados. O cdk bootstrap comando cria os recursos necessários para você. Você só precisa inicializar se estiver implantando uma pilha que exija esses recursos dedicados. Para mais detalhes, consulte AWS CDK bootstrapping.

cdk bootstrap

Se emitido sem argumentos, conforme mostrado aqui, o cdk bootstrap comando sintetiza o aplicativo atual e inicializa os ambientes nos quais suas pilhas serão implantadas. Se o aplicativo contiver pilhas independentes do ambiente, que não especificam explicitamente um ambiente, a conta e a região padrão serão inicializadas ou o ambiente especificado será usado. --profile

Fora de um aplicativo, você deve especificar explicitamente o ambiente a ser inicializado. Você também pode fazer isso para inicializar um ambiente que não esteja especificado em seu aplicativo ou AWS perfil local. As credenciais devem ser configuradas (por exemplo, in~/.aws/credentials) para a conta e a região especificadas. Você pode especificar um perfil que contenha as credenciais necessárias.

cdk bootstrap ACCOUNT-NUMBER/REGION # e.g. cdk bootstrap 1111111111/us-east-1 cdk bootstrap --profile test 1111111111/us-east-1
Importante

Cada ambiente (combinação de conta/região) no qual você implanta essa pilha deve ser inicializado separadamente.

Você pode incorrer em AWS cobranças pelo que eles AWS CDK armazenam nos recursos inicializados. Além disso, se você usar-bootstrap-customer-key, uma AWS KMS chave será criada, o que também incorrerá em cobranças por ambiente.

nota

As versões anteriores do modelo de bootstrap criavam uma KMS chave por padrão. Para evitar cobranças, reinicialize usando. --no-bootstrap-customer-key

nota

CDKCLIA v2 não suporta o modelo de bootstrap original, apelidado de modelo legado, usado por padrão com a v1. CDK

Importante

O modelo de bootstrap moderno concede efetivamente as permissões implícitas no --cloudformation-execution-policies para qualquer AWS conta na --trust lista. Por padrão, isso estende as permissões de leitura e gravação em qualquer recurso na conta inicializada. Certifique-se de configurar a pilha de inicialização com políticas e contas confiáveis com as quais você se sinta confortável.

Crie um novo aplicativo

Para criar um novo aplicativo, crie um diretório para ele e, dentro do diretório, emitacdk init.

mkdir my-cdk-app cd my-cdk-app cdk init TEMPLATE --language LANGUAGE

Os idiomas suportados (LANGUAGE) são:

Código

Idioma

typescript

TypeScript

javascript

JavaScript

python

Python

java

Java

csharp

C#

TEMPLATE é um modelo opcional. Se o modelo desejado for app, o padrão, você poderá omiti-lo. Os modelos disponíveis são:

Modelo

Descrição

app(padrão)

Cria um AWS CDK aplicativo vazio.

sample-app

Cria um AWS CDK aplicativo com uma pilha contendo uma SQS fila da Amazon e um tópico da AmazonSNS.

Os modelos usam o nome da pasta do projeto para gerar nomes para arquivos e classes dentro do seu novo aplicativo.

Listar pilhas

Para ver uma lista IDs das pilhas em seu AWS CDK aplicativo, insira um dos seguintes comandos equivalentes:

cdk list cdk ls

Se seu aplicativo contiver pilhas de CDKpipelines, ele CDK CLI exibirá os nomes das pilhas como caminhos de acordo com sua localização na hierarquia do pipeline. (Por exemploPipelineStack,PipelineStack/Prod, PipelineStack/Prod/MyService e.)

Se seu aplicativo contiver muitas pilhas, você poderá especificar a pilha total ou parcial IDs das pilhas a serem listadas. Para obter mais informações, consulte Especifique pilhas.

Adicione a --long bandeira para ver mais informações sobre as pilhas, incluindo os nomes das pilhas e seus ambientes (AWS conta e região).

Sintetizar pilhas

O cdk synthesize comando (quase sempre abreviadosynth) sintetiza uma pilha definida no seu aplicativo em um modelo. CloudFormation

cdk synth # if app contains only one stack cdk synth MyStack cdk synth Stack1 Stack2 cdk synth "*" # all stacks in app
nota

Na CDK CLI verdade, ele executa seu aplicativo e sintetiza novos modelos antes da maioria das operações (como ao implantar ou comparar pilhas). Esses modelos são armazenados por padrão no cdk.out diretório. O cdk synth comando simplesmente imprime os modelos gerados para uma ou mais pilhas especificadas.

Veja cdk synth --help todas as opções disponíveis. Algumas das opções usadas com mais frequência são abordadas na seção a seguir.

Especifique valores de contexto

Use a -c opção --context ou para passar valores de contexto de tempo de execução para seu CDK aplicativo.

# specify a single context value cdk synth --context key=value MyStack # specify multiple context values (any number) cdk synth --context key1=value1 --context key2=value2 MyStack

Ao implantar várias pilhas, os valores de contexto especificados normalmente são passados para todas elas. Se quiser, você pode especificar valores diferentes para cada pilha prefixando o nome da pilha no valor do contexto.

# different context values for each stack cdk synth --context Stack1:key=value Stack2:key=value Stack1 Stack2

Especifique o formato de exibição

Por padrão, o modelo sintetizado é exibido em YAML formato. Em vez disso, adicione a --json bandeira para exibi-la no JSON formato.

cdk synth --json MyStack

Especifique o diretório de saída

Adicione a opção --output (-o) para gravar os modelos sintetizados em um diretório diferente de. cdk.out

cdk synth --output=~/templates

Implante pilhas

O cdk deploy subcomando implanta uma ou mais pilhas especificadas em sua conta. AWS

cdk deploy # if app contains only one stack cdk deploy MyStack cdk deploy Stack1 Stack2 cdk deploy "*" # all stacks in app
nota

Ele CDK CLI executa seu aplicativo e sintetiza novos AWS CloudFormation modelos antes de implantar qualquer coisa. Portanto, a maioria das opções de linha de comando que você pode usar com cdk synth (por exemplo,--context) também pode ser usada comcdk deploy.

Veja cdk deploy --help todas as opções disponíveis. Algumas das opções mais úteis são abordadas na seção a seguir.

Ignorar a síntese

O cdk deploy comando normalmente sintetiza as pilhas do seu aplicativo antes da implantação para garantir que a implantação reflita a versão mais recente do seu aplicativo. Se você sabe que não alterou seu código desde a última vezcdk synth, você pode suprimir a etapa de síntese redundante durante a implantação. Para fazer isso, especifique o cdk.out diretório do seu projeto na --app opção.

cdk deploy --app cdk.out StackOne StackTwo

Desativar reversão

AWS CloudFormation tem a capacidade de reverter as alterações para que as implantações sejam atômicas. Isso significa que eles são bem-sucedidos ou fracassam como um todo. O AWS CDK herda esse recurso porque sintetiza e implanta modelos. AWS CloudFormation

A reversão garante que seus recursos estejam sempre em um estado consistente, o que é vital para as pilhas de produção. No entanto, enquanto você ainda está desenvolvendo sua infraestrutura, algumas falhas são inevitáveis, e reverter implantações malsucedidas pode atrasá-lo.

Por esse motivo, CDK CLI permite que você desative a reversão adicionando --no-rollback ao seu cdk deploy comando. Com esse sinalizador, implantações com falha não são revertidas. Em vez disso, os recursos implantados antes do recurso com falha permanecem em vigor e a próxima implantação começa com o recurso com falha. Você passará muito menos tempo esperando por implantações e muito mais tempo desenvolvendo sua infraestrutura.

Troca a quente

Use o --hotswap sinalizador with cdk deploy para tentar atualizar seus AWS recursos diretamente em vez de gerar um conjunto de AWS CloudFormation alterações e implantá-lo. A implantação volta à AWS CloudFormation implantação se a troca dinâmica não for possível.

Atualmente, o hot swapping suporta funções Lambda, máquinas de estado Step Functions e imagens de contêineres da Amazon. ECS O --hotswap sinalizador também desativa a reversão (ou seja, implica). --no-rollback

Importante

A troca dinâmica não é recomendada para implantações de produção.

Modo de relógio

O modo CDK CLI de observação (cdk deploy --watchou cdk watch abreviadamente) monitora continuamente os arquivos de origem e os ativos do seu CDK aplicativo em busca de alterações. Ele executa imediatamente uma implantação das pilhas especificadas quando uma alteração é detectada.

Por padrão, essas implantações usam a --hotswap bandeira, que acelera a implantação de alterações nas funções do Lambda. Ele também volta à implantação AWS CloudFormation se você tiver alterado a configuração da infraestrutura. Para cdk watch sempre realizar AWS CloudFormation implantações completas, adicione o --no-hotswap sinalizador a. cdk watch

Todas as alterações feitas enquanto cdk watch você já está executando uma implantação são combinadas em uma única implantação, que começa assim que a implantação em andamento é concluída.

O modo de observação usa a "watch" tecla do projeto cdk.json para determinar quais arquivos monitorar. Por padrão, esses arquivos são os arquivos e ativos do seu aplicativo, mas isso pode ser alterado modificando as "exclude" entradas "include" e na "watch" chave. O cdk.json arquivo a seguir mostra um exemplo dessas entradas.

{ "app": "mvn -e -q compile exec:java", "watch": { "include": "src/main/**", "exclude": "target/*" } }

cdk watchexecuta o "build" comando de cdk.json para criar seu aplicativo antes da síntese. Se sua implantação exigir algum comando para criar ou empacotar seu código Lambda (ou qualquer outra coisa que não esteja em seu CDK aplicativo), adicione-o aqui.

Os curingas no estilo Git, tanto quanto * e**, podem ser usados nas teclas e. "watch" "build" Cada caminho é interpretado em relação ao diretório pai docdk.json. O valor padrão de include é**/*, ou seja, todos os arquivos e diretórios no diretório raiz do projeto. excludeé opcional.

Importante

O modo de observação não é recomendado para implantações de produção.

Especifique AWS CloudFormation os parâmetros

O CDK CLI suporta a especificação de AWS CloudFormation parâmetros na implantação. Você pode fornecê-los na linha de comando seguindo o --parameters sinalizador.

cdk deploy MyStack --parameters uploadBucketName=UploadBucket

Para definir vários parâmetros, use vários --parameters sinalizadores.

cdk deploy MyStack --parameters uploadBucketName=UpBucket --parameters downloadBucketName=DownBucket

Se você estiver implantando várias pilhas, poderá especificar um valor diferente de cada parâmetro para cada pilha. Para fazer isso, prefixe o nome do parâmetro com o nome da pilha e dois pontos. Caso contrário, o mesmo valor será passado para todas as pilhas.

cdk deploy MyStack YourStack --parameters MyStack:uploadBucketName=UploadBucket --parameters YourStack:uploadBucketName=UpBucket

Por padrão, o AWS CDK retém os valores dos parâmetros de implantações anteriores e os usa em implantações posteriores, caso não sejam especificados explicitamente. Use o --no-previous-parameters sinalizador para exigir que todos os parâmetros sejam especificados.

Especificar arquivo de saídas

Se sua pilha declarar AWS CloudFormation saídas, elas normalmente são exibidas na tela no final da implantação. Para gravá-los em um arquivo em JSON formato, use o --outputs-file sinalizador.

cdk deploy --outputs-file outputs.json MyStack

Aprovar alterações relacionadas à segurança

Para protegê-lo contra alterações não intencionais que afetam sua postura de segurança, ele CDK CLI solicita que você aprove as alterações relacionadas à segurança antes de implantá-las. Você pode especificar o nível de alteração que requer aprovação:

cdk deploy --require-approval LEVEL

LEVEL pode ser uma das seguintes:

Prazo

Significado

never

A aprovação nunca é necessária

any-change

Requer aprovação de qualquer security-group-related alteração IAM ou alteração

broadening(padrão)

Requer aprovação quando IAM declarações ou regras de trânsito são adicionadas; remoções não exigem aprovação

A configuração também pode ser definida no cdk.json arquivo.

{ "app": "...", "requireApproval": "never" }

Compare pilhas

O cdk diff comando compara a versão atual de uma pilha (e suas dependências) definida em seu aplicativo com as versões já implantadas ou com um AWS CloudFormation modelo salvo e exibe uma lista de alterações.

Stack HelloCdkStack
IAM Statement Changes
┌───┬──────────────────────────────┬────────┬──────────────────────────────┬──────────────────────────────┬───────────┐
│   │ Resource                     │ Effect │ Action                       │ Principal                    │ Condition │
├───┼──────────────────────────────┼────────┼──────────────────────────────┼──────────────────────────────┼───────────┤
│ + │ ${Custom::S3AutoDeleteObject │ Allow  │ sts:AssumeRole               │ Service:lambda.amazonaws.com │           │
│   │ sCustomResourceProvider/Role │        │                              │                              │           │
│   │ .Arn}                        │        │                              │                              │           │
├───┼──────────────────────────────┼────────┼──────────────────────────────┼──────────────────────────────┼───────────┤
│ + │ ${MyFirstBucket.Arn}         │ Allow  │ s3:DeleteObject*             │ AWS:${Custom::S3AutoDeleteOb │           │
│   │ ${MyFirstBucket.Arn}/*       │        │ s3:GetBucket*                │ jectsCustomResourceProvider/ │           │
│   │                              │        │ s3:GetObject*                │ Role.Arn}                    │           │
│   │                              │        │ s3:List*                     │                              │           │
└───┴──────────────────────────────┴────────┴──────────────────────────────┴──────────────────────────────┴───────────┘
IAM Policy Changes
┌───┬────────────────────────────────────────────────────────┬────────────────────────────────────────────────────────┐
│   │ Resource                                               │ Managed Policy ARN                                     │
├───┼────────────────────────────────────────────────────────┼────────────────────────────────────────────────────────┤
│ + │ ${Custom::S3AutoDeleteObjectsCustomResourceProvider/Ro │ {"Fn::Sub":"arn:${AWS::Partition}:iam::aws:policy/serv │
│   │ le}                                                    │ ice-role/AWSLambdaBasicExecutionRole"}                 │
└───┴────────────────────────────────────────────────────────┴────────────────────────────────────────────────────────┘
(NOTE: There may be security-related changes not in this list. See https://github.com/aws/aws-cdk/issues/1299)

Parameters
[+] Parameter AssetParameters/4cd61014b71160e8c66fe167e43710d5ba068b80b134e9bd84508cf9238b2392/S3Bucket AssetParameters4cd61014b71160e8c66fe167e43710d5ba068b80b134e9bd84508cf9238b2392S3BucketBF7A7F3F: {"Type":"String","Description":"S3 bucket for asset \"4cd61014b71160e8c66fe167e43710d5ba068b80b134e9bd84508cf9238b2392\""}
[+] Parameter AssetParameters/4cd61014b71160e8c66fe167e43710d5ba068b80b134e9bd84508cf9238b2392/S3VersionKey AssetParameters4cd61014b71160e8c66fe167e43710d5ba068b80b134e9bd84508cf9238b2392S3VersionKeyFAF93626: {"Type":"String","Description":"S3 key for asset version \"4cd61014b71160e8c66fe167e43710d5ba068b80b134e9bd84508cf9238b2392\""}
[+] Parameter AssetParameters/4cd61014b71160e8c66fe167e43710d5ba068b80b134e9bd84508cf9238b2392/ArtifactHash AssetParameters4cd61014b71160e8c66fe167e43710d5ba068b80b134e9bd84508cf9238b2392ArtifactHashE56CD69A: {"Type":"String","Description":"Artifact hash for asset \"4cd61014b71160e8c66fe167e43710d5ba068b80b134e9bd84508cf9238b2392\""}

Resources
[+] AWS::S3::BucketPolicy MyFirstBucket/Policy MyFirstBucketPolicy3243DEFD
[+] Custom::S3AutoDeleteObjects MyFirstBucket/AutoDeleteObjectsCustomResource MyFirstBucketAutoDeleteObjectsCustomResourceC52FCF6E
[+] AWS::IAM::Role Custom::S3AutoDeleteObjectsCustomResourceProvider/Role CustomS3AutoDeleteObjectsCustomResourceProviderRole3B1BD092
[+] AWS::Lambda::Function Custom::S3AutoDeleteObjectsCustomResourceProvider/Handler CustomS3AutoDeleteObjectsCustomResourceProviderHandler9D90184F
[~] AWS::S3::Bucket MyFirstBucket MyFirstBucketB8884501
 ├─ [~] DeletionPolicy
 │   ├─ [-] Retain
 │   └─ [+] Delete
 └─ [~] UpdateReplacePolicy
     ├─ [-] Retain
     └─ [+] Delete

Para comparar as pilhas do seu aplicativo com a implantação existente:

cdk diff MyStack

Para comparar as pilhas do seu aplicativo com um CloudFormation modelo salvo:

cdk diff --template ~/stacks/MyStack.old MyStack

Importar recursos existentes para uma pilha

Você pode usar o cdk import comando para colocar os recursos sob o gerenciamento CloudFormation de uma AWS CDK pilha específica. Isso é útil se você estiver migrando ou movendo recursos entre pilhas ou alterando sua identificação lógica. cdk import Usa importações de CloudFormation recursos. AWS CDK Veja a lista de recursos que podem ser importados aqui.

Para importar um recurso existente em uma AWS CDK pilha, siga as etapas a seguir:

  • Certifique-se de que o recurso não esteja sendo gerenciado atualmente por nenhuma outra CloudFormation pilha. Se estiver, primeiro defina a política de remoção para a pilha RemovalPolicy.RETAIN em que o recurso está atualmente e execute uma implantação. Em seguida, remova o recurso da pilha e execute outra implantação. Esse processo garantirá que o recurso não seja mais gerenciado CloudFormation , mas não o exclua.

  • Execute a cdk diff para garantir que não haja alterações pendentes na AWS CDK pilha para a qual você deseja importar recursos. As únicas alterações permitidas em uma operação de “importação” são a adição de novos recursos que você deseja importar.

  • Adicione construções para os recursos que você deseja importar para sua pilha. Por exemplo, se você quiser importar um bucket do Amazon S3, adicione algo como. new s3.Bucket(this, 'ImportedS3Bucket', {}); Não faça nenhuma modificação em nenhum outro recurso.

    Você também deve se certificar de modelar exatamente o estado que o recurso tem atualmente na definição. Para o exemplo do bucket, não se esqueça de incluir AWS KMS chaves, políticas de ciclo de vida e qualquer outra coisa que seja relevante sobre o bucket. Caso contrário, as operações de atualização subsequentes podem não fazer o que você espera.

    Você pode escolher se deseja ou não incluir o nome do bucket físico. Geralmente, recomendamos não incluir nomes de recursos em suas definições de AWS CDK recursos para que seja mais fácil implantá-los várias vezes.

  • Executar cdk import STACKNAME.

  • Se os nomes dos recursos não estiverem em seu modelo, CLI ele solicitará que você informe os nomes reais dos recursos que você está importando. Depois disso, a importação é iniciada.

  • Quando cdk import relata o sucesso, o recurso agora é gerenciado por AWS CDK CloudFormation e. Qualquer alteração subsequente que você fizer nas propriedades do recurso em seu AWS CDK aplicativo, a configuração de construção será aplicada na próxima implantação.

  • Para confirmar se a definição do recurso no seu AWS CDK aplicativo corresponde ao estado atual do recurso, você pode iniciar uma operação de detecção de CloudFormation desvios.

Atualmente, esse recurso não oferece suporte à importação de recursos para pilhas aninhadas.

Configuração (cdk.json)

Os valores padrão para muitos sinalizadores de linha de CDK CLI comando podem ser armazenados no cdk.json arquivo de um projeto ou no .cdk.json arquivo do seu diretório de usuário. A seguir está uma referência alfabética às configurações suportadas.

Chave Observações CDKCLIopção
app O comando que executa o CDK aplicativo. --app
assetMetadata Sefalse, CDK não adiciona metadados aos recursos que usam ativos. --no-asset-metadata
bootstrapKmsKeyId Substitui o ID da AWS KMS chave usada para criptografar o bucket de implantação do Amazon S3. --bootstrap-kms-key-id
build O comando que compila ou constrói o CDK aplicativo antes da síntese. Não é permitido entrar~/.cdk.json. --build
browser O comando para iniciar um navegador da Web para o cdk docs subcomando. --browser
context Consulte Valores de contexto e o AWS CDK. Os valores de contexto em um arquivo de configuração não serão apagados pelocdk context --clear. (Eles CDK CLI colocam os valores de contexto em cachecdk.context.json.) --context
debug Setrue, CDK CLI emite informações mais detalhadas úteis para depuração. --debug
language A linguagem a ser usada para inicializar novos projetos. --language
lookups Sefalse, nenhuma pesquisa de contexto for permitida. A síntese falhará se alguma pesquisa de contexto precisar ser realizada. --no-lookups
notices Sefalse, suprime a exibição de mensagens sobre vulnerabilidades de segurança, regressões e versões não suportadas. --no-notices
output O nome do diretório no qual o conjunto de nuvem sintetizado será emitido (padrão). "cdk.out" --output
outputsFile O arquivo no qual as AWS CloudFormation saídas das pilhas implantadas serão gravadas (em JSON formato). --outputs-file
pathMetadata Sefalse, os metadados do CDK caminho não forem adicionados aos modelos sintetizados. --no-path-metadata
plugin JSONmatriz especificando os nomes dos pacotes ou os caminhos locais dos pacotes que estendem o CDK --plugin
profile Nome do AWS perfil padrão usado para especificar as credenciais da região e da conta. --profile
progress Se definido como"events", CDK CLI exibe todos os AWS CloudFormation eventos durante a implantação, em vez de uma barra de progresso. --progress
requireApproval Nível de aprovação padrão para alterações de segurança. Consulte Aprovar alterações relacionadas à segurança --require-approval
rollback Sefalse, implantações com falha não serão revertidas. --no-rollback
staging Sefalse, os ativos não forem copiados para o diretório de saída (use para depuração local dos arquivos de origem com). AWS SAM --no-staging
tags JSONobjeto contendo tags (pares de valores-chave) para a pilha. --tags
toolkitBucketName O nome do bucket do Amazon S3 usado para implantar ativos como funções Lambda e imagens de contêineres (consulte. Inicialize seu ambiente AWS --toolkit-bucket-name
toolkitStackName O nome da pilha de bootstrap (consulte. Inicialize seu ambiente AWS --toolkit-stack-name
versionReporting Sefalse, opta por não receber relatórios de versão. --no-version-reporting
watch JSONobjeto contendo "include" "exclude" chaves que indicam quais arquivos devem (ou não) acionar uma reconstrução do projeto quando alterados. Consulte Modo de relógio. --watch