Esta es la guía para desarrolladores de AWS CDK v2. La primera versión del CDK pasó a la etapa de mantenimiento el 1.° de junio de 2022 y no cuenta con soporte desde el 1.° de junio de 2023. Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés. # Los identificadores y el AWS CDK Al crear aplicaciones de AWS Cloud Development Kit (AWS CDK), utilizará muchos tipos de identificadores y nombres. Para utilizar el AWS CDK de forma eficaz y evitar errores, es importante entender los tipos de identificadores. Los identificadores deben ser únicos dentro del ámbito en el que se crean; no es necesario que sean únicos a nivel mundial en su aplicación de AWS CDK. Si intenta crear un identificador con el mismo valor dentro del mismo ámbito, el AWS CDK generará una excepción. ## ID del constructo El identificador más común, `id`, es el identificador que se pasa como segundo argumento al crear una instancia de un objeto de constructo. Este identificador, como todos los identificadores, solo debe ser único dentro del ámbito en el que se creó, que es el primer argumento al crear una instancia un objeto de constructo. **nota** El `id` de una pila es también el identificador que se utiliza para hacer referencia a ella en la [referencia de la CLI de AWS CDK](cli.md). Veamos un ejemplo en el que tenemos dos constructos con el identificador `MyBucket` en nuestra aplicación. El primero se define en el ámbito de la pila con el identificador `Stack1`. El segundo se define en el ámbito de una pila con el identificador `Stack2`. Como se definen en ámbitos diferentes, esto no genera ningún conflicto y pueden coexistir en la misma aplicación sin problemas. **Example** ``` import { App, Stack, StackProps } from 'aws-cdk-lib'; import { Construct } from 'constructs'; import * as s3 from 'aws-cdk-lib/aws-s3'; class MyStack extends Stack { constructor(scope: Construct, id: string, props: StackProps = {}) { super(scope, id, props); new s3.Bucket(this, 'MyBucket'); } } const app = new App(); new MyStack(app, 'Stack1'); new MyStack(app, 'Stack2'); ``` ``` const { App , Stack } = require('aws-cdk-lib'); const s3 = require('aws-cdk-lib/aws-s3'); class MyStack extends Stack { constructor(scope, id, props = {}) { super(scope, id, props); new s3.Bucket(this, 'MyBucket'); } } const app = new App(); new MyStack(app, 'Stack1'); new MyStack(app, 'Stack2'); ``` ``` from aws_cdk import App, Construct, Stack, StackProps from constructs import Construct from aws_cdk import aws_s3 as s3 class MyStack(Stack): def __init__(self, scope: Construct, id: str, **kwargs): super().__init__(scope, id, **kwargs) s3.Bucket(self, "MyBucket") app = App() MyStack(app, 'Stack1') MyStack(app, 'Stack2') ``` ``` // MyStack.java package com.myorg; import software.amazon.awscdk.App; import software.amazon.awscdk.Stack; import software.amazon.awscdk.StackProps; import software.constructs.Construct; import software.amazon.awscdk.services.s3.Bucket; public class MyStack extends Stack { public MyStack(final Construct scope, final String id) { this(scope, id, null); } public MyStack(final Construct scope, final String id, final StackProps props) { super(scope, id, props); new Bucket(this, "MyBucket"); } } // Main.java package com.myorg; import software.amazon.awscdk.App; public class Main { public static void main(String[] args) { App app = new App(); new MyStack(app, "Stack1"); new MyStack(app, "Stack2"); } } ``` ``` using Amazon.CDK; using constructs; using Amazon.CDK.AWS.S3; public class MyStack : Stack { public MyStack(Construct scope, string id, IStackProps props) : base(scope, id, props) { new Bucket(this, "MyBucket"); } } class Program { static void Main(string[] args) { var app = new App(); new MyStack(app, "Stack1"); new MyStack(app, "Stack2"); } } ``` ## Rutas Los constructos de una aplicación de AWS CDK forman una jerarquía basada en la clase `App`. Nos referimos a la colección de ID de un constructo dado, su constructo principal, su abuelo y así sucesivamente hasta la raíz del árbol del constructo, como una *ruta*. Por lo general, el AWS CDK muestra las rutas de las plantillas en forma de cadena. Los ID de los niveles se separan mediante barras diagonales, empezando por el nodo situado inmediatamente debajo de la instancia `App` raíz, que suele ser una pila. Por ejemplo, las rutas de los dos recursos de bucket de Amazon S3 del ejemplo de código anterior son `Stack1/MyBucket` y `Stack2/MyBucket`. Puede proporcionar la ruta de cualquier constructo mediante programación, como se muestra en el siguiente ejemplo. Esto obtiene la ruta `myConstruct` (o `my_construct`, como lo escribirían los desarrolladores de Python). Como los ID deben ser únicos dentro del ámbito en el que se crean, sus rutas siempre son únicas dentro de una aplicación de AWS CDK. **Example** ``` const path: string = myConstruct.node.path; ``` ``` const path = myConstruct.node.path; ``` ``` path = my_construct.node.path ``` ``` String path = myConstruct.getNode().getPath(); ``` ``` string path = myConstruct.Node.Path; ``` ## ID únicos AWS CloudFormation requiere que todos los ID lógicos de una plantilla sean únicos. Por ello, AWS CDK debe poder generar un identificador único para cada constructo en una aplicación. Los recursos tienen rutas que son únicas a nivel mundial (los nombres de todos los ámbitos de la pila hasta un recurso específico). Por lo tanto, AWS CDK genera los identificadores únicos necesarios mediante la concatenación de los elementos de la ruta y la adición de un hash de 8 dígitos. (El hash es necesario para distinguir rutas distintas, como `A/B/C` y `A/BC`, que darían como resultado el mismo identificador de AWS CloudFormation. Los identificadores de AWS CloudFormation son alfanuméricos y no pueden contener barras diagonales ni otros caracteres separadores). El AWS CDK llama a esta cadena el *ID único* del constructo. En general, la aplicación de AWS CDK no debería necesitar conocer los ID únicos. Sin embargo, es posible acceder al ID único de cualquier constructo mediante programación, como se muestra en el ejemplo siguiente. **Example** ``` const uid: string = Names.uniqueId(myConstruct); ``` ``` const uid = Names.uniqueId(myConstruct); ``` ``` uid = Names.unique_id(my_construct) ``` ``` String uid = Names.uniqueId(myConstruct); ``` ``` string uid = Names.Uniqueid(myConstruct); ``` La *dirección* es otro tipo de identificador único que distingue de forma única los recursos de CDK. Derivado del hash SHA-1 de la ruta, no es legible por humanos. Sin embargo, su longitud constante y relativamente corta (siempre 42 caracteres hexadecimales) la hace útil en situaciones en las que el ID único “tradicional” puede ser demasiado largo. Algunos constructos pueden utilizar la dirección de la plantilla de AWS CloudFormation sintetizada en lugar del ID único. De nuevo, por lo general, la aplicación no debería necesitar conocer las direcciones de sus constructos, pero puede recuperar la dirección de un componente de la siguiente manera. **Example** ``` const addr: string = myConstruct.node.addr; ``` ``` const addr = myConstruct.node.addr; ``` ``` addr = my_construct.node.addr ``` ``` String addr = myConstruct.getNode().getAddr(); ``` ``` string addr = myConstruct.Node.Addr; ``` ## ID lógicos Los ID únicos sirven como *identificadores lógicos* (o *nombres lógicos*) de los recursos en las plantillas de AWS CloudFormation generadas para los constructos que representan recursos de AWS. Por ejemplo, el bucket de Amazon S3 del ejemplo anterior que se crea dentro de `Stack2` da como resultado un recurso de ` AWS::S3::Bucket`. El ID lógico del recurso es `Stack2MyBucket4DD88B4F` en la plantilla de AWS CloudFormation resultante. (Para obtener más información sobre cómo se genera este identificador, consulte [ID únicos](#identifiers-unique-ids)). ### Estabilidad de ID lógico Evite cambiar el ID lógico de un recurso después de su creación. AWS CloudFormation identifica los recursos por el ID lógico. Por lo tanto, si cambia el ID lógico de un recurso, AWS CloudFormation crea un nuevo recurso con el nuevo ID lógico y, a continuación, elimina el existente. Según el tipo de recurso, esto puede provocar la interrupción del servicio, la pérdida de datos o ambas cosas.