L’utilité de CDK.JSON dans un projet CDK #
Lorsque nous initialisons une nouvelle application CDK avec l’option cdk init le CDK CLI
démarre une cdk.json dans le répertoire racine.
Par exemple :
mkdir cdk-app
cd cdk-app
npx aws-cdk init app --language=typescript
Le contenu du fichier cdk.json ressemble à quelque chose comme :
{
"app": "npx ts-node --prefer-ts-exts bin/cdk-app.ts",
"context": {
"@aws-cdk/aws-apigateway:usagePlanKeyOrderInsensitiveId": true,
}
}
Tout d’abord, nous avons le app qui pointe vers une commande indiquant à l’interface
CDK CLI comment exécuter notre
code CDK.
npx ts-node --prefer-ts-exts bin/cdk-app.ts
Le site bin/cdk-app.ts est l’endroit où notre application CDK et nos piles sont instanciées.
le point d’entrée de notre application CDK :
const app = new cdk.App();
new CdkAppStack(app, 'cdk-stack', {
env: {
account: process.env.CDK_DEFAULT_ACCOUNT,
region: process.env.CDK_DEFAULT_REGION,
},
});
Cet exemple a été initialisé en utilisant TypeScript, donc notre code doit être compilé en JavaScript avant d’être exécuté.
en JavaScript avant de pouvoir être exécuté. C’est exactement ce que le ts-node
fait.
La valeur de l’option app va être spécifique au langage de programmation.
Ensuite, nous avons le context clé.
Le contexte est une
combinaison de paires clé-valeur que nous pouvons définir dans notre application CDK.
CDK utilise le contexte pour garder la trace de ce qu’on appelle le feature flags. Drapeaux de fonctionnalités
permettent à l’équipe CDK de pousser de nouvelles fonctionnalités qui introduisent des changements de rupture,
en dehors des versions majeures.
Le site feature flags pointe vers une valeur booléenne, c’est-à-dire :
{
"context": {
"@aws-cdk/aws-apigateway:usagePlanKeyOrderInsensitiveId": true,
}
}
Le nom de l’indicateur de fonctionnalité commence par le nom du paquet qui
introduit le changement de rupture.
Pour les nouveaux projets, initialisés avec l’option cdk init la valeur de tous les drapeaux de
drapeaux de caractéristiques est fixée à true. Cependant, si nous travaillons sur un projet existant
nous pouvons décider par nous-mêmes, si nous voulons participer, après avoir recherché si
cette fonctionnalité ou cette correction de bogue pourrait entraîner des modifications importantes dans notre application CDK.
Une autre propriété qui est disponible dans le cdk.json est la propriété
versionReporting propriété :
{
"versionReporting": false,
"app": "npx ts-node --prefer-ts-exts infra/app.ts",
"context": {
"@aws-cdk/core:enableStackNameDuplicates": "true",
}
}
Le site versionReporting nous permet de
désactiver les rapports sur les métadonnées dans CDK.
En bref, Les métadonnées sont une fonctionnalité de CloudFormation qui nous permet de spécifier
des détails supplémentaires sur notre modèle.
L’équipe CDK utilise les métadonnées pour collecter des données analytiques sur la manière dont les développeurs utilisent
le service CDK.
Je n’ai rien contre cela, cependant, je n’aime pas avoir des choses supplémentaires dans mes
modèles CloudFormation.
Lorsque nous exécutons le cdk synth l’interface CLI de CDK génère un modèle CloudFormation
dans le dossier cdk.out répertoire.
C’est une question de préférence personnelle, jugez par vous-même.
Modèle avec métadonnées :
Modèle sans métadonnées :
Résumé #
Les deux principaux objectifs de la cdk.json sont :
- pour indiquer au CDK CLI comment exécuter notre code CDK
- et de garder la trace de
feature flagsqui permettent à l’équipe CDK de déployer en toute sécurité
de nouvelles fonctionnalités et de corrections de bogues qui entraînent des changements de rupture.