![\"CDK](\"https:\/\/geko.cloud\/wp-content\/uploads\/2022\/04\/image-13.png\")
<\/p>\n
Estas propiedades se utilizar\u00e1n dentro de la aplicaci\u00f3n tal y como se muestra en el siguiente c\u00f3digo de ejemplo que consiste en un stack que crea una instancia EC2 con una AMI Amazon Linux:<\/p>\n
![\"CDK](\"https:\/\/geko.cloud\/wp-content\/uploads\/2022\/04\/image-14.png\")
<\/p>\n
La propiedad stage, que determina las propiedades de que entorno usar a la hora de desplegar, se define de la siguiente forma:<\/p>\n
![\"\"](\"https:\/\/geko.cloud\/wp-content\/uploads\/2022\/04\/Captura-2.jpg\")
<\/p>\n
<\/p>\n
Es posible pasar propiedades por l\u00ednea de comandos utilizando el flag -c. De esta forma es posible desplegar en cualquier entorno cambiando solamente el valor de la key stage.<\/p>\n
Es un buen m\u00e9todo, sin embargo, si consideramos que una de las ventajas de CDK es poder utilizar las herramientas orientadas al desarrollo de aplicaciones tambi\u00e9n a la hora de provisionar infraestructura, \u00bfpor qu\u00e9 no utilizar un framework de gesti\u00f3n de propiedades conocido y que sea de confianza? O si en vuestra compa\u00f1\u00eda utilizais archivos YAML para configurar vuestras aplicaciones, si ya hab\u00e9is definido un ciclo de vida para las propiedades de vuestra aplicaciones, ten\u00e9is definido un conjunto de herramientas e incluso hab\u00e9is creado pipelines de CI-CD que gestionan dichas propiedades, \u00bfpor qu\u00e9 no reutilizar todos esos recursos ya disponibles ya probados y que cumplen con el compliance de la compa\u00f1\u00eda? Por un lado se reutiliza c\u00f3digo ya creado y por otro se adapta el c\u00f3digo a los procesos ya establecidos en los equipos de desarrollo de la empresa.<\/p>\n
Pero adem\u00e1s existe otra ventaja, supongamos que est\u00e1s provisionando infraestructura en CDK y necesitas definir secretos. Definir todas las propiedades en el archivo context.json es un problema porque si un usuario malicioso consigue acceder al archivo podr\u00e1 ver todos los secretos de todos los entornos. Si ya te has enfrentado con anterioridad a este problema y lo hab\u00e9is resuelto en vuestras pipelines de CD, \u00bfpor qu\u00e9 definir secretos en el contexto de CDK? Reutiliza tus pipelines y gestiona los secretos como lo haces para el resto de vuestras aplicaciones.<\/p>\n
<\/p>\n
En caso de que no sepas c\u00f3mo gestionar secretos o te est\u00e9s planteando nuevos m\u00e9todos, nuestra sugerencia es que utilices el servicio AWS System parameter store<\/a><\/strong>.\u00a0 Por si no lo sabias, parameter store permite guardar secretos de forma segura y tambi\u00e9n informaci\u00f3n de configuraci\u00f3n que tu aplicaci\u00f3n pueda necesitar, no solamente secretos y todo por un precio asequible<\/a><\/strong>. Recuperar los valores guardados en parameter store desde CDK, en tiempo de s\u00edntesi es bastante simple como se puede ver en la documentaci\u00f3n de CDK<\/a><\/strong>, a continuaci\u00f3n puedes ver un peque\u00f1o snippet de c\u00f3digo en el cual se recupera un secreto almacenado en Parameter Store:<\/p>\n <\/p>\n En esta segunda parte de \u00abConsejos para sacar mayor provecho a CDK\u00bb encontrar\u00e1s que en nuestra experiencia trabajando con CDK hemos notado que hay bastante confusi\u00f3n respecto a cu\u00e1ndo y c\u00f3mo usar stacks. Una duda muy t\u00edpica es definir el n\u00famero de stacks que tendr\u00e1 mi aplicaci\u00f3n de CDK. Como siempre, depende de varios factores, vamos a ver algunas pautas que te ayudar\u00e1n estructurar tu c\u00f3digo pero no son leyes grabadas en piedra y como siempre, todo depender\u00e1 de tu caso de uso.<\/p>\n Respecto al n\u00famero de stacks, lo importante es tener en cuenta que recursos que necesitas crear y si tiene sentido agruparlos todos dentro de un stack o no. Por ejemplo, si necesitas crear una infraestructura para una nueva aplicaci\u00f3n software que se debe desplegar en producci\u00f3n, llamemos a esta hipot\u00e9tica aplicaci\u00f3n app-A, lo ideal ser\u00eda crear un stack con todos los recursos que app-A usar\u00e1. Si necesitas un ASG, un Security Groups, y un ALB, crea un stack con todos estos recursos porque todos guardan relaci\u00f3n, todos estos recursos son utilizados por la aplicaci\u00f3n app-A. Al concentrar los recursos dentro del mismo stack se reduce el overhead de gestionar varios stacks y queda un c\u00f3digo m\u00e1s limpio.<\/p>\n Sin embargo, si tienes que crear una VPC u otro recurso susceptible de ser usado por otras aplicaciones aparte de app-A, te sugerimos separar los recursos en stacks diferentes. Por un lado un stack para los recursos que necesita app-A y por otro lado stacks para los recursos globales..<\/p>\n En resumen, agrupa recursos que est\u00e1n relacionados entre s\u00ed de alguna forma, bien porque son necesarios para que una aplicaci\u00f3n funcione o bien porque son elementos que trabajan juntos, como por ejemplo una VPC con sus respectivas subnets y networks ACL. La \u00fanica excepci\u00f3n que merece la pena considerar es crear un stack para gestionar elementos que son extremadamente importantes o cr\u00edticos como por ejemplo una instancia RDS. Si la instancia RDS se encuentra en un stack separado, se aumenta el overhead de gesti\u00f3n pero reduce el riesgo de actualizar el stack por accidente.<\/p>\n <\/p>\n Los constructs<\/a><\/strong> son la unidad base a partir de la cual se crean recursos en CDK. Todo recurso es generado por un construct. Existen diferentes tipos de constructs, Level 1 (L1), Level 2 (L2) y Level 3 (L3). Los constructs L1 hacen match 1 a 1 con los resources de Cloudformation. Es decir, para cada recurso de Cloudformation en CDK existe un construct con un prefijo CFN, que es capaz de crear dicho recurso. Adem\u00e1s los constructs L1 tendr\u00e1n los mismo atributos que su equivalente en Cloudformation. Los L2 son la versi\u00f3n \u201ccurated\u201d con valores por defecto y m\u00e1s sencillos de utilizar, pero tambi\u00e9n menos flexibles. Por \u00faltimo los L3 corresponden a patterns que est\u00e1n dise\u00f1ados para resolver problemas comunes dentro de AWS, como por ejemplo un API Gateway con una Lambda y una BD Dynamo como soluci\u00f3n serverless para una API.<\/p>\n Todos los constructs est\u00e1n mantenidos por el equipo de CDK, sin embargo, en caso de necesidad siempre puedes crear tu propio construct y personalizarlo, adapt\u00e1ndolo a tus necesidades. La verdad es que no es una pr\u00e1ctica recomendada\u00a0 pero a veces es \u00fatil en determinados casos, sobre todo cuando usas un construct de tipo L2 que tiene unos valores por defecto que no encajan con tus necesidades. En todo caso, te recomendamos que no abuses de esta pr\u00e1ctica. Intenta crear el menor n\u00famero de constructs custom posible.<\/p>\n Supongamos que el compliance de la compa\u00f1\u00eda es que los buckets no pueden ser accesibles de forma p\u00fablica y adem\u00e1s todos los objetos almacenados deben estar encriptados at rest. Una forma de satisfacer todos estos requisitos consistir\u00eda en crear tu propio construct custom y pedir al equipo de DevOps que utilicen este construct en lugar del construct L2 de la librer\u00eda de CDK. M\u00e1s abajo podemos ver una posible implementaci\u00f3n para nuestro construct custom. En el ejemplo se puede ver que el construct hereda de la clase Construct en lugar de la clase Bucket. Te aconsejamos hacerlo as\u00ed porque de esta forma puedes dise\u00f1ar constructs con un mayor grado de personalizaci\u00f3n.<\/p>\n <\/p>\n Si buscas una forma alternativa de vigilar el compliance de tu c\u00f3digo sin tener que crear tu propia librer\u00eda, te recomendamos utilizar Aspects.<\/a><\/strong> Los Aspects son la forma de aplicar operaciones a todos los constructs de un determinado scope. Con un Aspect se puede comprobar que un determinado recurso sea privado, o que est\u00e9 encriptado.<\/p>\n En la siguiente imagen, podemos ver un stack que crea un bucket S3 privado usando el custom construct del ejemplo anterior:<\/p>\n El atributo kms_key est\u00e1 vac\u00edo, por lo tanto, los objetos que se almacenen dentro del bucket no se encriptar\u00e1n. Por ello, hemos creado un Aspect llamado BucketChecker que comprueba que los buckets de la clase GekoPrivateBucket tengan definido el atributo encryption_key. En caso de que no lo tengan definido saltar\u00e1 una excepci\u00f3n:<\/p>\n De esta forma, hacer comprobaciones sobre los recursos creados es f\u00e1cil y liviano.<\/p>\n <\/p>\n Hemos llegado al fin de los \u00abConsejos para sacar mayor provecho a CDK\u00bb que quer\u00edamos compartir con vosotros. Tanto en el primer como en el segundo post, hemos tratado varios temas, sin embargo, hemos dado prioridad a dos conceptos clave. El primer concepto clave es c\u00f3mo estructurar el c\u00f3digo de una aplicaci\u00f3n CDK, es decir, n\u00famero de stacks que deber\u00eda tener una aplicaci\u00f3n, cuando y como crear un construct custom, c\u00f3mo deber\u00edan ser los test o c\u00f3mo lidiar con los identificadores de CDK.\u00a0 Una buena estructura ayuda a ahorrar deuda t\u00e9cnica y mejora la calidad del c\u00f3digo entregado.<\/p>\n El segundo concepto clave es el de compliance. A lo largo de ambos posts, hemos aportado ideas de c\u00f3mo cumplir los hipot\u00e9ticos requisitos de un compliance. Una de las lecciones m\u00e1s importantes que hemos aprendido gestionando la infraestructura de nuestros clientes es que el compliance es un concepto realmente importante, si bien es cierto que implantarlo en una organizaci\u00f3n puede ser doloroso al principio. El compliance permite reducir riesgos, mejora el governance de la infraestructura y crea un marco de trabajo que ayuda a los diferentes equipos de una empresa (SRE, Development, SecOps, …) a relacionarse y llegar a acuerdos. Por esa raz\u00f3n el c\u00f3digo que generes en CDK deber\u00eda siempre tener en mente c\u00f3mo satisfacer el compliance de tu compa\u00f1\u00eda.<\/p>\n Desde\u00a0Geko Consultor\u00eda Cloud,<\/strong> esperamos que ambos posts te hayan gustado y sobre todo que te resulten \u00fatiles, nada nos alegrar\u00eda m\u00e1s. Te invitamos a que si necesitas informaci\u00f3n sobre el mundo Cloud y DevOps<\/strong><\/a>,\u00a0nos contactes<\/a>\u00a0<\/strong>y sigas revisando\u00a0nuestro blog<\/a><\/strong>\u00a0para encontrar otras publicaciones \u00fatiles.<\/p>\n![\"CDK](\"https:\/\/geko.cloud\/wp-content\/uploads\/2022\/04\/Captura-3.jpg\")
<\/p>\n<\/h2>\n
Stacks<\/h2>\n
Constructs<\/h2>\n
![\"CDK](\"https:\/\/geko.cloud\/wp-content\/uploads\/2022\/04\/image-15.png\")
<\/p>\n![\"CDK](\"https:\/\/geko.cloud\/wp-content\/uploads\/2022\/04\/image-16.png\")
<\/p>\n![\"\"](\"https:\/\/geko.cloud\/wp-content\/uploads\/2022\/04\/image-17.png\")
<\/p>\n<\/h2>\n
Resumen sobre los \u00abConsejos para sacar mayor provecho a CDK\u00bb<\/h2>\n