La lliçó anterior va acabar amb una limitació concreta: red-mercadofresco.yaml descriu sis subxarxes gairebé idèntiques escrites a mà, una darrere l'altra, perquè YAML no té bucles. Tampoc no té funcions, ni tipus, ni cap manera d'encapsular «la xarxa estàndard de MercadoFresco» en alguna cosa que es reutilitzi en tres entorns. I no hi ha manera d'escriure una prova que verifiqui que cap plantilla no obre el port 22 al món. L'AWS Cloud Development Kit resol les quatre coses d'una sola manera: deixant que la infraestructura s'escrigui en un llenguatge de programació de veritat.

El més important des del primer minut és que el CDK no substitueix CloudFormation. Tot el de 09-01 —piles, conjunts de canvis, deriva, DeletionPolicy, ROLLBACK_COMPLETE— continua sent exactament igual de cert. El CDK escriu les plantilles per tu.

Avís de cost. El CDK és gratuït; pagues els recursos que crea. cdk bootstrap crea un bucket d'S3, un repositori d'ECR i cinc rols d'IAM per compte i regió: cèntims al mes mentre estiguin buits. Els exemples d'aquesta lliçó despleguen una VPC amb NAT (uns 0,045 USD/hora cadascun) i un ALB (uns 0,025 USD/hora): si segueixes els exercicis, destrueix les piles en acabar amb l'ordre de l'apartat de neteja. Dades fictícies.

1. Què és el CDK i quina relació té amb CloudFormation
2. Per què compensa, i quan CloudFormation pur continua sent millor
3. Instal·lació, cdk init i estructura del projecte
4. App, Stack, Construct i els tres nivells de constructes
5. La xarxa de MercadoFresco en CDK
6. Un constructe propi: MercadoFrescoVpc
7. Les capes d'aplicació i integració en Python
8. Actius: el codi de les Lambda dins de la pila
9. El cicle de vida: synth, diff, deploy, destroy i bootstrap
10. Context, entorns explícits i una pila per entorn
11. Aspectes: etiquetatge obligatori i regles d'auditoria
12. Proves d'infraestructura
13. Recursos amb estat, RemovalPolicy i el perill de cdk destroy
14. CDK Pipelines: el pipeline que es desplega a si mateix
15. Terraform, CDK for Terraform i la comparació honesta
16. Cost i neteja
17. Errors habituals i consells
18. Exercicis
19. Conclusió

El CDK és una biblioteca de classes —disponible en TypeScript, JavaScript, Python, Java, C# i Go— amb la qual es descriu la infraestructura com a objectes. Quan executes cdk synth, aquests objectes es sintetitzen: produeixen una plantilla de CloudFormation, que després es desplega com una pila normal.

D'aquest flux en surten tres conseqüències pràctiques que convé interioritzar abans d'escriure una línia:

• L'artefacte de desplegament continua sent una plantilla. Pots llegir-la, versionar-la, revisar-la i desplegar-la sense el CDK. cdk.out/ conté el resultat exacte de la síntesi, i cdk synth > plantilla.yaml te'l deixa en un fitxer.
• Els errors de CloudFormation continuen passant. Un ROLLBACK_COMPLETE en una pila del CDK es diagnostica i es resol com a 09-01: mirant els esdeveniments de la pila.
• El codi no s'executa a AWS. S'executa al teu portàtil o a CodeBuild, i la seva única sortida és JSON. No hi ha res «viu» del CDK al compte tret del que crea el bootstrap.

El que aporta un llenguatge de programació no és una sintaxi més bonica: són cinc capacitats que YAML no té. Bucles, per a les sis subxarxes. Condicionals de veritat, avaluats en la síntesi i no en el desplegament, cosa que fa que la plantilla generada sigui més simple, no més complexa. Tipus, que converteixen un error de propietat en una fallada de compilació a l'editor, no en un CREATE_FAILED al cap de vuit minuts. Reutilització, encapsulant patrons en classes amb nom. I proves, executables al pipeline com les del codi d'aplicació.

Però el CDK no és la resposta correcta en tots els casos, i convé dir-ho sense adorns:

MercadoFresco tria CDK per dues raons concretes de la seva situació: té tres entorns que han de ser idèntics i un equip de dues persones que ja programen cada dia. Si l'equip fos de sistemes purs i la infraestructura portés dos anys sense tocar-se, la resposta correcta seria quedar-se en YAML.

El CDK s'instal·la amb npm, fins i tot per a projectes en Python: l'eina de línia d'ordres és Node.

cdk init genera un projecte executable. El més important de la seva estructura:

Un advertiment sobre cdk.json: la secció context inclou banderes de funcionalitat (@aws-cdk/aws-*:featureFlag) que canvien el comportament per omissió dels constructes. Es generen amb la versió del CDK que va crear el projecte i no s'han de tocar a mà: modificar-les pot canviar l'ARN o el nom de recursos ja desplegats, amb reemplaçament inclòs.

Al repositori mercadofresco-infra, el projecte viu a infra-cdk/ al costat de les plantilles de 09-01, que es mantenen mentre dura la migració.

Tres conceptes, i tota la resta se'n dedueix:

• App: l'aplicació CDK completa, arrel de l'arbre. Una App conté piles.
• Stack: la unitat de desplegament, que correspon 1:1 amb una pila de CloudFormation. Els límits de 09-01 —500 recursos— continuen aplicant-se.
• Construct: qualsevol node de l'arbre. Un recurs, un grup de recursos o una pila sencera són constructes. Tots reben els mateixos tres arguments: scope (el pare), id (únic entre germans) i props.

L'id és l'equivalent del nom lògic de 09-01, i n'hereta la regla més important: canviar l'id d'un constructe desplegat destrueix i recrea el recurs. El CDK compon els identificadors lògics concatenant el camí de l'arbre i afegint-hi un sufix, així que moure un constructe de lloc també el recrea.

Els constructes tenen tres nivells d'abstracció, i el mateix bucket il·lustra la diferència:

Dos avisos. De l'L2 sempre pots baixar a l'L1 amb recurso.node.defaultChild as s3.CfnBucket per tocar una propietat que l'API no exposa; és la vàlvula d'escapament que evita quedar-se bloquejat. I els L3 són còmodes i opacs: creen més recursos dels que esperes i la seva configuració fina costa més que escriure-la a mà, així que MercadoFresco els fa servir per prototipar i després baixa a L2.

Una altra peça que estalvia molt de temps són els mètodes grant*: cola.grantConsumeMessages(rol) genera la política d'IAM correcta —inclosos els permisos sobre la clau de KMS— sense que ningú escrigui un JSON. És, a la pràctica, el mínim privilegi de 04-01 per defecte.

Les 190 línies de YAML de 09-01 es converteixen en això:

Vint-i-vuit línies contra cent noranta, i el resultat sintetitzat és equivalent: la mateixa VPC, sis subxarxes (tres configuracions × dues AZ), la passarel·la d'internet, els NAT, quatre taules de rutes amb les seves associacions i l'endpoint d'S3. El que ha desaparegut no és la infraestructura, és la repetició mecànica.

Val la pena aturar-se en tres detalls:

• subnetConfiguration és el bucle. Declares tres tipus de subxarxa i el CDK en crea una per AZ, calculant els CIDR automàticament a partir del bloc de la VPC i de cidrMask. Afegir una tercera AZ és canviar maxAzs: 2 per 3.
• SubnetType codifica la intenció, no la implementació: PRIVATE_WITH_EGRESS significa «privada amb sortida per NAT» i PRIVATE_ISOLATED, «sense sortida a internet». Les subxarxes de dades de MercadoFresco són exactament això segon, i el CDK no els crea ruta cap a 0.0.0.0/0 perquè el tipus ho prohibeix.
• El condicional del NAT es resol en la síntesi. A 09-01 calia un Mappings, una Condition i un Fn::If; aquí és un operador ternari de TypeScript i la plantilla resultant no té cap condició. Aquesta és la diferència entre avaluar en temps de síntesi i avaluar en temps de desplegament, i és la raó per la qual les plantilles generades solen ser més simples que les escrites a mà.

Un matís honest: aquesta concisió té un preu. L'L2 d'ec2.Vpc pren decisions per tu —el repartiment de CIDR, els noms, el nombre de taules de rutes— i per saber exactament què ha creat cal mirar la plantilla sintetitzada. Per això cdk synth no és una ordre de depuració ocasional: és part del flux normal.

La reutilització de veritat arriba en encapsular el patró en una classe amb les decisions de MercadoFresco ja preses:

Fer-lo servir als tres entorns és una línia per entorn, i qualsevol millora del patró arriba als tres alhora: si demà es decideix activar els registres de flux també a preproducció, es canvia en un sol lloc. Això és el que a 09-01 no existia, perquè un Mappings amb tres columnes no és una abstracció: és una taula.

La convenció de MercadoFresco és que els constructes propis exposen el que els consumidors necessiten i res més —aquí, vpc i sgTienda—, per poder canviar l'interior sense trencar res a ningú. És encapsulació aplicada a infraestructura, i és exactament el motiu pel qual compensa un llenguatge de programació.

El CDK és multillenguatge de veritat: les biblioteques es generen amb jsii des de la mateixa font en TypeScript, així que l'API és idèntica tret de l'estil dels noms. El Luis prefereix Python per a la capa d'aplicació:

Aquí passen coses que en YAML costaven desenes de línies. add_listener i add_targets creen l'oient, el grup de destinació, el registre de l'ASG i les regles del grup de seguretat necessàries perquè l'ALB arribi a les instàncies: el SourceSecurityGroupId de 09-01 el dedueix el CDK del graf d'objectes. I scale_on_request_count crea la política d'escalat amb la seva alarma de CloudWatch associada.

La capa d'integració és igual de compacta, i mostra el patró de 07-05 amb la cua de missatges fallits:

add_subscription crea la subscripció i la política de la cua que permet a SNS escriure-hi, amb la condició aws:SourceArn inclosa. És el bloc de vint línies de la solució de l'exercici de 09-01, reduït a una crida i sense possibilitat d'oblidar-se'n.

Hi ha una cosa que CloudFormation no sap fer tota sola i que el CDK resol de manera gairebé invisible: pujar el codi. Una plantilla pot declarar una funció Lambda, però el seu codi ha de ser ja en un bucket, amb una clau que algú ha hagut d'omplir a mà o des d'un script. A 09-01 això quedava fora de la plantilla i ho feia el pipeline.

Els actius (assets) del CDK tanquen aquest forat: durant cdk deploy, l'eina empaqueta el directori indicat, en calcula l'empremta, el puja al bucket del bootstrap i substitueix la referència a la plantilla.

Tres conseqüències pràctiques. La primera: l'empremta del contingut forma part del nom de l'actiu, així que canviar el codi canvia l'actiu i cdk diff ho detecta; si no canvia, el desplegament no toca la funció. La segona: add_event_source crea el mapatge d'origen d'esdeveniments i els permisos de consum sobre la cua, inclosa la clau de KMS. I la tercera, que és un advertiment: els actius s'acumulen al bucket del bootstrap i ningú no els esborra, així que la regla de cicle de vida de l'apartat de neteja no és opcional al cap de sis mesos.

Un matís sobre el repartiment de responsabilitats. Que el CDK pugui desplegar el codi no vol dir que ho hagi de fer en producció: MercadoFresco manté la separació de 08-05 —l'artefacte de la botiga es construeix una vegada i el desplega CodeDeploy— i fa servir actius només per a les Lambda, el codi de les quals és petit i va acoblat a la seva infraestructura. Barrejar el cicle de vida del codi d'aplicació amb el de la infraestructura torna a ajuntar el que el mòdul 8 va separar.

cdk bootstrap es mereix una explicació, perquè és la part que més desconcerta. Crea una pila anomenada CDKToolkit amb: un bucket d'S3 per als artefactes (plantilles grans, codi de Lambda, actius), un repositori d'ECR per a imatges de contenidor, i cinc rols d'IAM —de desplegament, de publicació d'actius, de cerca, d'execució de CloudFormation i d'imatges—. Sense ella, cdk deploy falla amb un missatge explícit.

Hi ha tres coses que cal saber sobre el bootstrap: és per compte i per regió, així que desplegar a us-east-1 per a un certificat de CloudFront exigeix fer-hi el bootstrap també; la versió importa, i una versió antiga provoca fallades críptiques que es resolen tornant-lo a executar; i els rols que crea són potents per omissió, amb AdministratorAccess al rol d'execució de CloudFormation, cosa que en un compte compartit és una decisió que cal prendre conscientment —--cloudformation-execution-policies permet acotar-ho—.

cdk diff és l'equivalent quotidià del conjunt de canvis de 09-01, i la seva sortida marca amb [-], [+] i [~] el que s'esborra, s'afegeix i es modifica, assenyalant a més els canvis que provoquen reemplaçament. La regla de MercadoFresco és la mateixa que allà: cap desplegament sense haver llegit el diff.

Aquí s'ataca de cara el problema que apareix a cada incident: que preproducció no és igual que producció. La solució del CDK és fer que les tres piles surtin del mateix codi, amb un fitxer de configuració per entorn com a única diferència.

Queden nou piles amb noms predictibles: MercadoFrescoRedProduccion, MercadoFrescoAplicacionPreproduccion, i així. I la diferència entre entorns ja no és un misteri arqueològic: és un fitxer de vint línies que es llegeix en deu segons. La primera vegada que es va generar, la Marta va descobrir tres divergències que feia mesos que hi eren: preproducció tenia un sol NAT declarat com si fos producció, la retenció de registres era de 7 dies als tres entorns i el CIDR de desenvolupament se solapava amb el de preproducció.

Dos conceptes importants d'aquest bloc:

Entorns explícits. Si omets env, la pila és agnòstica d'entorn i no pot fer servir informació real del compte: Vpc.fromLookup, el nombre d'AZ o els certificats existents. El CDK genera llavors plantilles amb dues AZ fictícies i sorpreses en desplegar. Declara sempre env amb compte i regió literals.

Context i cdk.context.json. Les cerques (fromLookup) consulten el compte durant la síntesi i en guarden el resultat a la memòria cau dins de cdk.context.json, que sí que es versiona: garanteix que la síntesi sigui reproduïble i que el pipeline no depengui de consultes en viu. Quan la realitat canvia, es refresca amb cdk context --clear. La regla pràctica: preferir referències explícites a cerques, perquè una cerca és una dependència oculta sobre l'estat del compte.

El pas de valors entre piles és més natural que a 09-01: passar xarxa.vpc a AplicacionStack fa que el CDK creï automàticament l'exportació i la importació de CloudFormation. És còmode i té el mateix parany que allà —una exportació en ús és un forrellat— amb un agreujant: el CDK la crea sense que la vegis. Si dues piles han d'evolucionar per separat, continua sent millor publicar a Parameter Store i llegir amb StringParameter.valueForStringParameter.

Un aspecte és un visitant que recorre tot l'arbre de constructes i actua sobre cada node. Serveix per a dues coses que en YAML eren impossibles: aplicar alguna cosa a tots els recursos de cop i auditar regles sobre el que es desplegarà.

L'etiquetatge obligatori de MercadoFresco és trivial amb Tags, que internament és un aspecte:

I una regla d'auditoria pròpia és una classe de vint línies:

Tres detalls que marquen la diferència entre que això funcioni i que doni falsos negatius. Els aspectes visiten constructes L1, així que cal comprovar CfnBucket i no Bucket: els L2 creen L1 per sota i és allà on hi ha les propietats reals. addError atura la síntesi, cosa que converteix la regla en una porta de qualitat de veritat i no en un avís que ningú no llegeix. I els aspectes s'executen després que l'arbre estigui construït però abans de sintetitzar, per la qual cosa també poden modificar recursos —afegir xifratge en comptes de fallar—, tot i que MercadoFresco prefereix fallar: una infraestructura que es corregeix sola amaga l'error en comptes d'arreglar-lo.

Això és el que a 09-01 feia cfn-guard amb un llenguatge a part. Aquí és el mateix llenguatge, amb el mateix editor, el mateix depurador i les mateixes proves.

La piràmide de proves de 08-05 tenia un forat evident: la infraestructura no es provava. Amb el CDK sí, perquè una plantilla sintetitzada és un objecte JSON contra el qual es poden fer assercions.

Hi ha dues famílies de proves i serveixen per a coses diferents:

MercadoFresco fa servir totes dues amb una regla estricta: les assercions cobreixen el que no pot fallar mai —sis subxarxes, dos NAT en producció, sense SSH obert, xifratge a tots els buckets— i les instantànies actuen de xarxa de seguretat. I una norma de revisió: una instantània actualitzada en una PR obliga a explicar el diff a la descripció. Sense aquesta norma, jest -u es converteix en un reflex i la prova deixa de valer res.

El guany real es veu en actualitzar aws-cdk-lib: la instantània mostra exactament què ha canviat a les plantilles generades abans de desplegar res. En una actualització menor de la biblioteca, MercadoFresco va descobrir així un canvi de comportament per omissió en el xifratge d'una cua que ningú no hauria notat.

La RemovalPolicy del CDK és la DeletionPolicy de 09-01, amb una diferència perillosa: els constructes L2 trien un valor per omissió, i no sempre el que esperes.

I aquí hi ha el perill real, que a MercadoFresco és concret perquè els tres entorns comparteixen el compte 111122223333: cdk destroy --all no pregunta a quin entorn pertany cada pila. Un --all llançat des del directori equivocat, o un cdk destroy MercadoFrescoRedProduccion amb un autocompletat desafortunat, toca producció. Tres mesures, en ordre d'eficàcia:

1. deletion_protection i termination_protection a les piles de producció, que fan que l'esborrat falli al servei, no a la bona voluntat de qui escriu l'ordre. cdk.Stack accepta terminationProtection: true.
2. Mai --all en un terminal humà. Els desplegaments de producció surten del pipeline; en local s'anomena la pila sencera.
3. Comptes separats, que és la solució de veritat i arriba a 09-04. Mentrestant, les dues anteriors són pedaços conscients.

Un últim matís: RemovalPolicy.RETAIN deixa el recurs orfe, i el següent cdk deploy intentarà crear-ne un altre amb el mateix nom físic i fallarà. És la contrapartida de la seguretat, i la raó per la qual els noms físics fixos —table_name, bucket_name— tenen cost, igual que a 09-01.

Queda l'última peça de l'asimetria del mòdul 8: el pipeline es va crear a mà. pipelines.CodePipeline ho resol amb una propietat anomenada autoactualització: el pipeline es defineix al mateix repositori que la infraestructura i, a cada execució, la seva primera etapa s'actualitza a si mateixa abans de desplegar res.

Un Stage és un grup de piles que es despleguen juntes —xarxa, dades, integració, aplicació i observabilitat d'un entorn— i el CDK dedueix l'ordre de desplegament del graf de dependències entre elles. npm test executa les proves de la secció anterior, així que una plantilla que violi una regla no arriba a desplegar-se.

Amb això, MercadoFresco tanca el cercle del mòdul 8: el pipeline-mercadofresco-tienda desplega l'aplicació i el pipeline-mercadofresco-infra desplega la infraestructura i a si mateix. Afegir una etapa nova és una PR, no un clic a la consola.

Dos advertiments. El primer: el pipeline autoactualitzable és potent i perillós —qui pugui fusionar a main pot canviar el mateix pipeline—, així que la protecció de branca de 08-01 i la revisió obligatòria deixen de ser bones pràctiques i passen a ser un control de seguretat. El segon: l'etapa de síntesi necessita els permisos de cerca, així que cdk.context.json versionat no és opcional si vols síntesis reproduïbles.

Terraform, de HashiCorp, és l'alternativa multiproveïdor més estesa: llenguatge declaratiu propi (HCL), estat en un fitxer que cal emmagatzemar i bloquejar, i proveïdors per a AWS, Azure, GCP, Datadog o GitHub. CDK for Terraform (CDKTF) permet escriure configuració de Terraform amb TypeScript o Python, igual que el CDK amb CloudFormation.

La recomanació és senzilla i no depèn de gustos. Si tot és a AWS, CloudFormation o CDK, perquè l'estat gestionat i la reversió automàtica són avantatges reals que es paguen cars amb Terraform. Si hi ha diversos proveïdors —AWS més Cloudflare, més GitHub, més Datadog— Terraform guanya, i el cost de mantenir l'estat es justifica. MercadoFresco és sencer a AWS i ja té el pipeline muntat sobre serveis natius: canviar seria feina sense retorn.

El CDK és gratuït; el bootstrap deixa un bucket, un repositori d'ECR i cinc rols el cost dels quals és menyspreable mentre estiguin buits. Convé, això sí, posar una regla de cicle de vida al bucket d'actius, que creix a cada desplegament i no es neteja sol.

L'ordre importa per la mateixa raó que a 09-01: primer els consumidors, després la xarxa. Si una pila no es deixa esborrar, la causa sol ser una exportació en ús o un bucket amb objectes, i es diagnostica als esdeveniments de CloudFormation, no al CDK.

Error: canviar l'id d'un constructe desplegat. Reanomenar 'Vpc' per 'VpcPrincipal' recrea el recurs, igual que a 09-01. Consell: els id són immutables a la pràctica; si de debò cal reorganitzar, cdk diff avisa —llegeix-lo—, i overrideLogicalId permet conservar l'identificador anterior.

Error: desplegar sense cdk diff. El CDK fa tan fàcil desplegar que la gent es salta la vista prèvia. Consell: cdk diff a cada PR, publicat com a comentari, i --require-approval any-change en producció.

Error: piles sense env explícit. Produeixen plantilles amb dues AZ fictícies i fromLookup no funciona. Consell: declara env amb compte i regió literals a totes les piles.

Error: cdk destroy --all al compte compartit. És el risc concret de MercadoFresco fins a 09-04. Consell: terminationProtection: true a les piles de producció, anomenar sempre la pila, i mai --all fora d'un entorn de proves.

Error: actualitzar instantànies amb -u sense mirar. Converteix la prova en decoració. Consell: exigir en la revisió que tota instantània actualitzada vingui amb l'explicació del diff.

Error: creure que l'L2 fa el que tu faries. ec2.Vpc pren dotzenes de decisions per tu. Consell: cdk synth i llegir la plantilla la primera vegada que facis servir un constructe nou; és l'única manera de saber què has demanat de veritat.

Consell: fixa la versió d'aws-cdk-lib i actualitza-la a propòsit. Amb les proves d'instantània, cada actualització t'ensenya exactament què canvia a les plantilles abans de tocar res.

Consell: fes servir els mètodes grant* en comptes d'escriure polítiques. Generen el mínim privilegi real, inclosos els permisos sobre KMS que gairebé tothom oblida.

Consell: no fiquis lògica de negoci al codi d'infraestructura. El CDK convida a fer-ho per ser un llenguatge complet. Una pila que llegeix una base de dades durant la síntesi és una pila que no es pot sintetitzar al pipeline.

Escriu un constructe propi ColaMercadoFresco (TypeScript o Python) que encapsuli el patró de 07-05: una cua principal amb la seva cua de missatges fallits, xifratge amb alias/mercadofresco-datos, maxReceiveCount configurable amb valor per omissió de 5, retenció de 14 dies a la DLQ, i una alarma de CloudWatch que salti quan la DLQ tingui missatges. Ha d'exposar la cua principal, la DLQ i un mètode concederConsumo(rol). Fes-lo servir per crear les quatre cues de MercadoFresco. Indica quina RemovalPolicy poses a cada cua i per què.

Escriu quatre proves per a RedStack i AplicacionStack que verifiquin invariants que a MercadoFresco li importen de debò: (a) que en producció hi ha dos NAT i en desenvolupament un; (b) que cap subxarxa de dades no té ruta cap a un NAT; (c) que l'ALB només accepta HTTPS; (d) que tots els recursos etiquetables porten les cinc etiquetes obligatòries. Per a cadascuna, digues si la resoldries amb asserció o amb instantània i per què, i què caldria a més de la prova perquè la regla es compleixi sempre.

MercadoFresco ja té la pila mercadofresco-red-produccion desplegada amb la plantilla YAML de 09-01, amb la VPC i les sis subxarxes en producció. La Marta vol passar aquesta pila a CDK sense recrear res i sense tallar el servei. Descriu l'estratègia completa: quines opcions hi ha, quina tries i per què, quines ordres executes, com comproves que la migració no canviarà res, i què fas si cdk diff mostra diferències. Explica també quin risc concret té l'opció que descartes.

Solució 1

Les polítiques d'esborrat. La DLQ sempre RETAIN, a tots els entorns: conté missatges que no es van processar i que algú haurà d'examinar; esborrar-la en destruir una pila destrueix l'evidència d'un incident. La cua principal, RETAIN en producció i DESTROY a la resta: en producció hi pot haver missatges en vol la pèrdua dels quals seria pèrdua de comandes, mentre que en desenvolupament un residu que impedeix recrear la pila costa més del que protegeix.

I un detall que es nota en fer-lo servir quatre vegades: el bucle de quatre línies substitueix cent vint línies de YAML amb dotze recursos, i garanteix que les quatre cues tinguin exactament la mateixa configuració —xifratge, reintents, alarma—, que és justament el que avui no es compleix a MercadoFresco.

Solució 2

(a) Asserció. És un invariant de negoci amb dos valors concrets, i la prova ho expressa millor que qualsevol instantània. A més sobreviu a refactoritzacions: si demà es reorganitzen els constructes, la prova continua valent.

(b) Asserció, però indirecta. Comprovar «cap subxarxa de dades no té ruta cap a un NAT» requereix seguir la relació entre RouteTable, Route i SubnetRouteTableAssociation a la plantilla, cosa que és tediosa. El que és pragmàtic és afirmar que no existeix cap AWS::EC2::Route amb NatGatewayId la taula de la qual estigui associada a una subxarxa datos, i recolzar-se en el fet que el CDK garanteix la propietat per construcció en fer servir PRIVATE_ISOLATED. La prova val com a xarxa de seguretat davant d'un canvi de tipus de subxarxa.

(c) Asserció, amb la part negativa inclosa. Comprovar que existeix un oient 443 no n'hi ha prou: el que importa és que no existeixi un al 80 sense redirecció. Les proves que només verifiquen presència deixen passar precisament els errors per addició, que són els que passen.

(d) Ni asserció ni instantània: un aspecte. Una prova que recorri tots els recursos comprovant etiquetes és fràgil, perquè molts tipus no les admeten i caldria mantenir la llista d'excepcions. El correcte és un aspecte que faci fallar la síntesi si falta una etiqueta obligatòria, més una prova que l'aspecte està registrat a l'App. Es prova el mecanisme, no cada instància.

Què cal a més de les proves. Res d'això no serveix si les proves no bloquegen: han d'executar-se a npm test dins de l'etapa de síntesi de CDK Pipelines, i la construcció ha de fallar, no avisar. És la mateixa conclusió de 08-02, aplicada a la infraestructura: una comprovació que no bloqueja és documentació.

Solució 3

Hi ha dues opcions i no són equivalents.

La primera és recrear la xarxa en CDK i migrar: desplegar una VPC nova al costat de la vella, moure les instàncies, la base de dades i l'ALB, i esborrar l'antiga. És neta conceptualment i és la que es descarta, perquè implica moure Aurora i l'ALB entre VPC: canvi d'endpoints, finestra de tall, risc sobre les dades de clients i, sobretot, un benefici nul —la xarxa resultant és idèntica—. Tot el risc, cap guany.

La segona, la triada, és fer que el CDK adopti la pila existent. La clau és que una pila de CloudFormation no sap si la seva plantilla l'ha escrita una persona o el CDK: només compara identificadors lògics. Si la plantilla sintetitzada és equivalent, l'actualització no toca cap recurs.

El procediment. S'escriu la pila CDK amb el mateix nom de pila, mercadofresco-red-produccion, i es forcen els identificadors lògics perquè coincideixin amb els de la plantilla YAML, fent servir overrideLogicalId recurs a recurs:

La comprovació, que és el cor de l'exercici:

Un cdk diff buit és la condició d'acceptació. Mentre mostri alguna cosa, no es desplega.

Si mostra diferències, hi ha tres casos. Si són només metadades del CDK (CDKMetadata, la versió de l'analitzador) s'accepten: no afecten cap recurs. Si són propietats cosmètiques —una descripció, una etiqueta— es decideix cas per cas i es documenta. I si hi ha algun [~] amb reemplaçament o qualsevol [-], s'atura: significa que la plantilla generada no és equivalent i cal ajustar el codi fins que ho sigui. Un [-] sobre una subxarxa en producció és exactament el desastre que aquesta migració existeix per evitar.

La xarxa de seguretat, en dos passos. Abans de res, --enable-termination-protection a la pila i DeletionPolicy: Retain als recursos crítics, perquè ni tan sols un error greu destrueixi res. I l'assaig complet primer en desenvolupament, després en preproducció i només llavors en producció, que és el mateix ordre de promoció de 08-04 aplicat a la infraestructura.

La mateixa infraestructura, en un llenguatge de programació. Les 190 línies de YAML de la xarxa s'han convertit en 28 línies de TypeScript que sintetitzen una plantilla equivalent, i les sis subxarxes gairebé idèntiques han desaparegut dins d'un subnetConfiguration de tres entrades que el CDK multiplica per AZ. El que no ha canviat és el que hi ha a sota: el CDK no substitueix CloudFormation, escriu les plantilles per tu, i els conjunts de canvis, la deriva, ROLLBACK_COMPLETE i les polítiques d'eliminació de 09-01 continuen governant el que passa de veritat.

Tens els tres nivells de constructes —l'L1 que calca CloudFormation, l'L2 amb valors per defecte segurs i mètodes grant* que generen el mínim privilegi, i l'L3 còmode i opac— amb la vàlvula d'escapament de node.defaultChild per baixar de nivell quan l'API es queda curta. Tens el constructe propi MercadoFrescoVpc, que és la diferència entre una taula de tres columnes i una abstracció de veritat: una millora del patró arriba als tres entorns alhora. I tens el cicle de vida complet, amb cdk bootstrap explicat —el bucket, el repositori d'ECR i els cinc rols, per compte i regió, amb permisos d'administració que cal acotar conscientment— i amb la regla que s'hereta de 09-01: cap desplegament sense haver llegit el diff.

Els tres entorns surten ara del mateix codi, i la diferència entre preproducció i producció ha deixat de ser arqueologia: és config/entornos.ts, vint línies llegibles en deu segons, que en escriure's per primera vegada va destapar tres divergències que feia mesos que hi eren. Amb entorns explícits a totes les piles —sense env no hi ha cerques i sí AZ fictícies— i cdk.context.json versionat perquè la síntesi sigui reproduïble al pipeline.

I la infraestructura entra per fi a la piràmide de proves de 08-05. Els aspectes apliquen l'etiquetatge obligatori de cop i auditen regles —buckets sense xifrar, el port 22 obert— amb addError, que atura la síntesi en comptes d'avisar; visitant sempre constructes L1, que és on hi ha les propietats reals. Les assercions cobreixen el que no pot fallar mai i les instantànies actuen de xarxa de seguretat, amb la norma de revisió que les manté vives: una instantània actualitzada obliga a explicar el diff. Més CDK Pipelines, que tanca l'asimetria del mòdul 8 desplegant la infraestructura i actualitzant-se a si mateix —i que converteix la protecció de branca de 08-01 en un control de seguretat, perquè qui fusiona a main canvia el pipeline—.

Queda un risc assenyalat tres vegades i no resolt: cdk destroy apuntant a producció. La protecció de terminació i la disciplina d'anomenar sempre la pila són pedaços conscients, no solucions, perquè el problema de fons és que els tres entorns comparteixen el compte 111122223333. Mentre això continuï sent cert, una ordre mal escrita, una variable d'entorn oblidada o un --all al directori equivocat poden arribar a la botiga en producció. I el radi d'explosió no és l'única cosa: les quotes es comparteixen, un desplegament de desenvolupament pot esgotar el límit d'adreces IP elàstiques de producció, la factura no se separa de veritat i cap política d'IAM no aïlla del tot algú que ja té permisos amplis al compte.

A 09-03, «AWS Elastic Beanstalk», fem un pas enrere per mirar l'alternativa gestionada: què fa per tu una plataforma com a servei, quan hauria estat la decisió correcta per a MercadoFresco —i per què avui ja no ho és—. Després, 09-04, «AWS Organizations», ataca el problema de fons: separar de veritat els entorns en comptes diferents, amb polítiques de control de serveis, facturació consolidada i una línia base que es desplega sola a cada compte nou.