Consejos para sacar mayor provecho a CDK [Parte 2]
Volvemos a la carga con nuestra lista de consejos prácticos para CDK. En el primer artículo hablamos de conceptos básicos, no de CDK sino de cualquier proyecto software, naming convention, testing y un tema muy relacionado con el cloud como es el tagging. Hoy hablaremos de gestión de propiedades pero, también hablaremos de temas que son puramente de CDK como constructs y CDK. Sin más dilación empezamos.
Gestión de propiedades
Una práctica muy habitual en cloudformation es añadir parámetros a una template para poder personalizarla y así usarla en diferentes entornos como desarrollo, preproducción o producción. En CDK también existen los parámetros tal y como están definidos en cloudformation. Sin embargo, no es buena práctica usarlos y así se recalca en la documentación oficial de CDK. AWS recomienda centralizar la gestión de propiedades en el contexto de CDK. Este método consiste en añadir en el archivo context.json todas las propiedades que necesito para ejecutar mi aplicación en todos los entornos. Así pues, volviendo al ejemplo anterior, dentro del archivo cdk.json definiremos propiedades para cada entorno de la siguiente manera:
Estas propiedades se utilizarán dentro de la aplicación tal y como se muestra en el siguiente código de ejemplo que consiste en un stack que crea una instancia EC2 con una AMI Amazon Linux:
La propiedad stage, que determina las propiedades de que entorno usar a la hora de desplegar, se define de la siguiente forma:
Es posible pasar propiedades por línea de comandos utilizando el flag -c. De esta forma es posible desplegar en cualquier entorno cambiando solamente el valor de la key stage.
Es un buen método, sin embargo, si consideramos que una de las ventajas de CDK es poder utilizar las herramientas orientadas al desarrollo de aplicaciones también a la hora de provisionar infraestructura, ¿por qué no utilizar un framework de gestión de propiedades conocido y que sea de confianza? O si en vuestra compañía utilizais archivos YAML para configurar vuestras aplicaciones, si ya habéis definido un ciclo de vida para las propiedades de vuestra aplicaciones, tenéis definido un conjunto de herramientas e incluso habéis creado pipelines de CI-CD que gestionan dichas propiedades, ¿por qué no reutilizar todos esos recursos ya disponibles ya probados y que cumplen con el compliance de la compañía? Por un lado se reutiliza código ya creado y por otro se adapta el código a los procesos ya establecidos en los equipos de desarrollo de la empresa.
Pero además existe otra ventaja, supongamos que estás 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á ver todos los secretos de todos los entornos. Si ya te has enfrentado con anterioridad a este problema y lo habéis resuelto en vuestras pipelines de CD, ¿por qué definir secretos en el contexto de CDK? Reutiliza tus pipelines y gestiona los secretos como lo haces para el resto de vuestras aplicaciones.
En caso de que no sepas cómo gestionar secretos o te estés planteando nuevos métodos, nuestra sugerencia es que utilices el servicio AWS System parameter store. Por si no lo sabias, parameter store permite guardar secretos de forma segura y también información de configuración que tu aplicación pueda necesitar, no solamente secretos y todo por un precio asequible. Recuperar los valores guardados en parameter store desde CDK, en tiempo de síntesi es bastante simple como se puede ver en la documentación de CDK, a continuación puedes ver un pequeño snippet de código en el cual se recupera un secreto almacenado en Parameter Store:
Stacks
En esta segunda parte de «Consejos para sacar mayor provecho a CDK» encontrarás que en nuestra experiencia trabajando con CDK hemos notado que hay bastante confusión respecto a cuándo y cómo usar stacks. Una duda muy típica es definir el número de stacks que tendrá mi aplicación de CDK. Como siempre, depende de varios factores, vamos a ver algunas pautas que te ayudarán estructurar tu código pero no son leyes grabadas en piedra y como siempre, todo dependerá de tu caso de uso.
Respecto al número 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ón software que se debe desplegar en producción, llamemos a esta hipotética aplicación app-A, lo ideal sería crear un stack con todos los recursos que app-A usará. Si necesitas un ASG, un Security Groups, y un ALB, crea un stack con todos estos recursos porque todos guardan relación, todos estos recursos son utilizados por la aplicación app-A. Al concentrar los recursos dentro del mismo stack se reduce el overhead de gestionar varios stacks y queda un código más limpio.
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..
En resumen, agrupa recursos que están relacionados entre sí de alguna forma, bien porque son necesarios para que una aplicación funcione o bien porque son elementos que trabajan juntos, como por ejemplo una VPC con sus respectivas subnets y networks ACL. La única excepción que merece la pena considerar es crear un stack para gestionar elementos que son extremadamente importantes o críticos como por ejemplo una instancia RDS. Si la instancia RDS se encuentra en un stack separado, se aumenta el overhead de gestión pero reduce el riesgo de actualizar el stack por accidente.
Constructs
Los constructs 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ás los constructs L1 tendrán los mismo atributos que su equivalente en Cloudformation. Los L2 son la versión “curated” con valores por defecto y más sencillos de utilizar, pero también menos flexibles. Por último los L3 corresponden a patterns que están diseñados para resolver problemas comunes dentro de AWS, como por ejemplo un API Gateway con una Lambda y una BD Dynamo como solución serverless para una API.
Todos los constructs están mantenidos por el equipo de CDK, sin embargo, en caso de necesidad siempre puedes crear tu propio construct y personalizarlo, adaptándolo a tus necesidades. La verdad es que no es una práctica recomendada pero a veces es útil 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áctica. Intenta crear el menor número de constructs custom posible.
Supongamos que el compliance de la compañía es que los buckets no pueden ser accesibles de forma pública y además todos los objetos almacenados deben estar encriptados at rest. Una forma de satisfacer todos estos requisitos consistiría en crear tu propio construct custom y pedir al equipo de DevOps que utilicen este construct en lugar del construct L2 de la librería de CDK. Más abajo podemos ver una posible implementación 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í porque de esta forma puedes diseñar constructs con un mayor grado de personalización.
Si buscas una forma alternativa de vigilar el compliance de tu código sin tener que crear tu propia librería, te recomendamos utilizar Aspects. 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é encriptado.
En la siguiente imagen, podemos ver un stack que crea un bucket S3 privado usando el custom construct del ejemplo anterior:
El atributo kms_key está vacío, por lo tanto, los objetos que se almacenen dentro del bucket no se encriptarán. 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á una excepción:
De esta forma, hacer comprobaciones sobre los recursos creados es fácil y liviano.
Resumen sobre los «Consejos para sacar mayor provecho a CDK»
Hemos llegado al fin de los «Consejos para sacar mayor provecho a CDK» que queríamos 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ómo estructurar el código de una aplicación CDK, es decir, número de stacks que debería tener una aplicación, cuando y como crear un construct custom, cómo deberían ser los test o cómo lidiar con los identificadores de CDK. Una buena estructura ayuda a ahorrar deuda técnica y mejora la calidad del código entregado.
El segundo concepto clave es el de compliance. A lo largo de ambos posts, hemos aportado ideas de cómo cumplir los hipotéticos requisitos de un compliance. Una de las lecciones más 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ón 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ón el código que generes en CDK debería siempre tener en mente cómo satisfacer el compliance de tu compañía.
Desde Geko Consultoría Cloud, esperamos que ambos posts te hayan gustado y sobre todo que te resulten útiles, nada nos alegraría más. Te invitamos a que si necesitas información sobre el mundo Cloud y DevOps, nos contactes y sigas revisando nuestro blog para encontrar otras publicaciones útiles.
Tenéis la primera parte sobre «Consejos para sacar mayor provecho a CDK» [Parte 1] publicada en nuestro Blog!
¡Hasta la próxima!
