La narrativa del taller

Una sola historia a lo largo de cuatro semanas:

CodeCommit → CodeBuild → ECR → ECS → CloudWatch

Objetivos de la sesión

1. Crear el repositorio, clonarlo desde su origen y subir el código a CodeCommit
2. Construir la imagen con CodeBuild
3. Publicar la imagen en ECR
4. Desplegar el template de CloudFormation para el despliegue inicial

Cada ejercicio incluye su solución oculta — botón Ver solución en la guía.

¿Qué es DevOps?

Una combinación de prácticas culturales, servicios y herramientas que aumentan la capacidad de entregar software a alta velocidad.

El objetivo es unificar las áreas de desarrollo y operaciones, las cuales comúnmente suelen estar completamente separadas, para conseguir un mejor flujo desde el código a la aplicación desplegada.

Contrato de Despliegue

%%{init: {"flowchart": {"defaultRenderer": "elk", "nodeSpacing": 30, "rankSpacing": 40, "padding": 8}, "themeVariables": {"clusterBkg": "#fffbeb", "clusterBorder": "#d97706"}}}%%
flowchart TD
    DCORE["Desarrollo · Núcleo<br/>Código · lógica de negocio · pruebas"]
    DSHELL["Desarrollo · Interfaz exterior<br/>Empaquetado · requisitos · instrumentación"]
    DCORE <--> DSHELL

    OCORE["Operaciones · Núcleo<br/>Infraestructura · seguridad · observabilidad · día 2"]
    OSHELL["Operaciones · Interfaz exterior<br/>Plataforma · políticas · capacidad · retroalimentación"]
    OCORE <--> OSHELL

    subgraph CONTRACT["Contrato de despliegue · interfaz compartida"]
        direction TB
        ART["Artefacto desplegable"]
        CFG["Configuración<br/>Argumentos · variables · secretos"]
        DEP["Dependencias<br/>Entorno de ejecución · bibliotecas · servicios"]
        EXP["Exposición<br/>Protocolos · puertos · cifrado · chequeos de salud"]

        ART ~~~ DEP
        CFG ~~~ EXP
    end

    DSHELL <-->|"Definición conjunta"| CONTRACT
    OSHELL <-->|"Validación operativa"| CONTRACT

    CONTRACT --> PIPELINE["Pipeline CI/CD"]
    PIPELINE --> PROD["Aplicación en producción"]

    DSHELL <-.-|"Retroalimentación de producción"| PROD
    OSHELL <-.-|"Métricas · logs · incidentes"| PROD

    classDef core fill:#dbeafe,stroke:#2563eb,color:#172554;
    classDef shell fill:#e0e7ff,stroke:#4f46e5,color:#1e1b4b;
    classDef contract fill:#fef3c7,stroke:#d97706,color:#451a03;
    classDef runtime fill:#dcfce7,stroke:#16a34a,color:#052e16;

    class DCORE,OCORE core;
    class DSHELL,OSHELL shell;
    class ART,CFG,DEP,EXP contract;
    class PIPELINE,PROD runtime;

    linkStyle 2,3 stroke:none;
    linkStyle 8,9 stroke-dasharray:5 4;

Pipeline de entrega continua (CI/CD)

Busca automatizar el flujo desde los últimos cambios realizados a la aplicación hasta su despliegue en producción, asegurando que cumple con los requisitos básicos de calidad, así como con el contexto necesario para su monitoreo continuo en día 2.

+-------------------------+     +-------------------+
|           CI            |     |        CD         |
| Código -> Build -> Test | --> | Deploy -> Monitor |
|          Day 1          |     |       Day 2       |
+-------------------------+     +-------------------+

Pre-requisitos

Por favor, utilicen aquella que se adapta a su usuario.

1. Cuenta con usuario IAM: Acceso HTTPS o SSH
2. Cuenta con SSO y IAM Identity Center: git-remote-codecommit

Capacidades de la consola de CodeCommit

1. Code

Permite explorar los archivos y las carpetas de una rama, abrir su contenido y copiar la URL para clonar el repositorio.

2. Pull requests

Permite proponer la fusión de una rama en otra, revisar los cambios y registrar la discusión antes de integrar el trabajo.

3. Commits

Muestra el historial de cambios de la rama seleccionada. Cada commit identifica quién hizo el cambio, cuándo lo realizó y qué archivos modificó.

4. Branches

Lista las líneas de desarrollo del repositorio y permite crear una rama a partir de otra, por ejemplo dev desde main.

5. Git tags

Permite identificar un commit con un nombre estable, como v1.0.0, para señalar una versión, una entrega o un punto importante del historial.

6. Settings

Centraliza la configuración del repositorio, como los disparadores (triggers), las reglas de aprobación y las notificaciones. Las opciones disponibles dependen de los permisos de IAM.

GitOps

Del cambio al despliegue controlado

1. Branches definen dónde se integra y prueba el código.
2. PRs hacen visible la revisión y la aprobación.
3. Tags identifican una versión concreta que se puede desplegar.
4. Eventos conectan los cambios con los pipelines y los controles operativos.

Flujos de Aprobación

gitGraph
    commit id: "base"
    branch dev
    checkout dev
    commit id: "D1"
    branch feature-work
    checkout feature-work
    commit id: "F1"
    commit id: "F2"
    checkout dev
    merge feature-work id: "PR #42"
    branch staging
    checkout staging
    commit id: "release candidate" tag: "v1.4.0-rc.1"
    checkout dev
    branch production
    checkout production
    merge staging id: "PR #43" tag: "v1.4.0"

Trunk-based development

gitGraph
    commit id: "base"
    commit id: "M1"
    branch feature-search
    checkout feature-search
    commit id: "F1"
    commit id: "F2"
    checkout main
    merge feature-search id: "PR #51"
    commit id: "M2"
    branch release-1-4
    checkout release-1-4
    commit id: "release candidate" tag: "v1.4.0-rc.1"
    checkout main
    merge release-1-4 id: "PR #52" tag: "v1.4.0"

Ambientes efímeros por PR

gitGraph
    commit id: "base"
    branch feature-search
    checkout feature-search
    commit id: "S1"
    commit id: "preview PR #57 listo"
    checkout main
    branch feature-profile
    checkout feature-profile
    commit id: "P1"
    commit id: "preview PR #58 listo"
    checkout main
    merge feature-search id: "PR #57"
    merge feature-profile id: "PR #58"

Gestión de datos

Los datos y las dependencias externas determinan qué tan fiel puede ser cada ambiente de prueba, especialmente cuando el ambiente nace para un PR y desaparece al terminar.

Consola

1. Iniciar sesión en la consola de AWS en console.aws.amazon.com.
2. Abrir CodeCommit.
3. Confirmar que la región seleccionada (esquina superior derecha) es la misma que indicó el instructor. El taller usa una única región para todos los recursos.

Crear el repositorio

1. Pulsar Create repository.
2. En Repository name, escribir taller-aws-<su-nombre>. Usar el primer nombre en minúsculas y sin acentos (por ejemplo: taller-aws-carlos).
3. En Description (opcional), escribir una descripción breve, por ejemplo: Repositorio del taller AWS DevOps — Semana 1.
4. Dejar las demás opciones con sus valores predeterminados y pulsar Create.

Respuesta en AWS: CodeBuild y Amazon ECR

¿Qué es Amazon ECR?

Amazon Elastic Container Registry (ECR) es el registro de imágenes de contenedores de AWS. Como DockerHub

Una vez construida la imagen Docker, hay que guardarla en algún lugar. Amazon ECR (Elastic Container Registry) es el servicio de AWS para almacenar imágenes Docker de forma privada y segura. Cuando ECS necesite lanzar el contenedor en la Semana 3, irá a buscar la imagen directamente a ECR.

Artefactos desplegables: construir una vez, promover muchas veces

El objetivo es solo producir el artefacto a desplegar una vez, para luego promoverlo entre ambientes.

Del código a la imagen publicada

Ahora que tenemos el código en un lugar que controlamos, tenemos que producir el artefacto desplegable de este proyecto: una imagen de contenedor.

%%{init: {"flowchart": {"defaultRenderer": "elk", "nodeSpacing": 40, "rankSpacing": 55, "padding": 12}, "themeVariables": {"clusterBkg": "#fdf4ff", "clusterBorder": "#c925d1", "surface0": "#fdf4ff", "border0": "#c925d1", "edgeLabelBackground": "#ffffff"}}}%%
flowchart LR
    subgraph repo["<img src='/static/aws-codecommit.svg' width='40' height='40' /> CodeCommit"]
        direction TB
        source["Código fuente"]
        spec["buildspec.yml"]
    end

    subgraph cb["<img src='/static/aws-codebuild.svg' width='40' height='40' /> CodeBuild"]
        direction LR
        dbuild["<img src='/static/docker.svg' width='42' /><br/>docker build"]
        image[["Imagen Docker"]]
        dpush["<img src='/static/docker.svg' width='42' /><br/>docker push"]
        dbuild ==> image ==> dpush
    end

    ecr[("<img src='/static/aws-ecr.svg' width='44' height='44' /><br/>Amazon ECR")]

    source --> dbuild
    spec -.->|"fases y comandos"| dbuild
    dpush ==> ecr

    classDef repoNode fill:#ffffff,stroke:#c925d1,color:#4a044e
    classDef dockerNode fill:#eff8ff,stroke:#2396ed,color:#0c4a6e
    classDef artifactNode fill:#f1f5f9,stroke:#475569,color:#0f172a
    classDef ecrNode fill:#fff7ed,stroke:#ed7100,stroke-width:2px,color:#7c2d12
    class source,spec repoNode
    class dbuild,dpush dockerNode
    class image artifactNode
    class ecr ecrNode

Un solo build, muchas etiquetas

• Mismo artefacto en local y en producción.
• Evitar reconstruir en cada fase (tiempo, y bytes distintos.)
• Busquemos re-etiquetar, guiados por tags, labels y el digest de ECR.

%%{init: {"flowchart": {"nodeSpacing": 25, "rankSpacing": 40}}}%%
flowchart LR
    build["docker build<br/>(una sola vez)"] ==> img[("Imagen<br/>sha256:9f2c…")]
    img -->|"pr-123"| pr["Ambiente efímero"]
    img -->|"staging"| stg["Staging"]
    img ==>|"v1.4.0"| prod["Producción"]
    classDef dockerNode fill:#eff8ff,stroke:#2396ed,color:#0c4a6e
    classDef artifactNode fill:#f1f5f9,stroke:#475569,color:#0f172a
    classDef envNode fill:#ffffff,stroke:#94a3b8,color:#0f172a
    classDef prodNode fill:#f0fdf4,stroke:#16a34a,stroke-width:2px,color:#14532d
    class build dockerNode
    class img artifactNode
    class pr,stg envNode
    class prod prodNode

Mono-repo: build único por servicio

• La identidad no es el commit: es el tree hash del contenido.
• ¿Ya existe en ECR? Re-etiquetar. ¿No existe? Construir.
• En el merge, solo se despliega lo que realmente cambió.

%%{init: {"flowchart": {"nodeSpacing": 25, "rankSpacing": 40}}}%%
flowchart LR
    push["push al PR"] --> hash["tree hash<br/>por servicio"]
    hash --> q{"¿existe<br/>en ECR?"}
    q -->|"sí"| retag["re-etiquetar<br/>(segundos)"]
    q -->|"no"| build["build + push"]
    retag ==> env["Ambiente efímero<br/>con los 3 servicios"]
    build ==> env
    classDef plainNode fill:#ffffff,stroke:#94a3b8,color:#0f172a
    classDef decisionNode fill:#fff7ed,stroke:#ed7100,color:#7c2d12
    classDef fastNode fill:#f0fdf4,stroke:#16a34a,color:#14532d
    classDef dockerNode fill:#eff8ff,stroke:#2396ed,color:#0c4a6e
    class push,hash,env plainNode
    class q decisionNode
    class retag fastNode
    class build dockerNode

Cache de build en CodeBuild

• Local: capas del host anterior — simple, pero best effort.
• S3: rutas del buildspec.yml — entre hosts, con transferencia.
• Registro: BuildKit publica el cache en ECR (:cache) — cualquier host.

%%{init: {"flowchart": {"nodeSpacing": 12, "rankSpacing": 40}}}%%
flowchart LR
    local["Cache local"] -.-> cb["CodeBuild"]
    s3[("Cache S3")] --> cb
    reg[("ECR :cache")] ==> cb
    cb ==> out[("Imagen publicada")]
    classDef plainNode fill:#ffffff,stroke:#94a3b8,color:#0f172a
    classDef s3Node fill:#f0fdf4,stroke:#16a34a,color:#14532d
    classDef ecrNode fill:#fff7ed,stroke:#ed7100,stroke-width:2px,color:#7c2d12
    classDef cbNode fill:#fdf4ff,stroke:#c925d1,color:#4a044e
    classDef artifactNode fill:#f1f5f9,stroke:#475569,color:#0f172a
    class local plainNode
    class s3 s3Node
    class reg ecrNode
    class cb cbNode
    class out artifactNode

ECR más allá del push: lifecycle

La retención de imágenes es una política de la empresa.

%%{init: {"flowchart": {"nodeSpacing": 25, "rankSpacing": 45}}}%%
flowchart LR
    ecr[("<img src='/static/aws-ecr.svg' width='40' height='40' /><br/>repositorio")]
    ecr --> q{"¿qué regla<br/>lo limpia?"}
    q -->|"por tiempo<br/>(&gt; 90 días)"| del["borra también la<br/>imagen en producción"]
    del --> fail["escalar → ✗ pull falla"]
    q -->|"últimas N, y<br/>release-* protegido"| keep["lo desplegado<br/>siempre existe"]
    keep --> ok["escalar → ✓ pull"]
    classDef ecrNode fill:#fff7ed,stroke:#ed7100,stroke-width:2px,color:#7c2d12
    classDef decisionNode fill:#fff7ed,stroke:#ed7100,color:#7c2d12
    classDef badNode fill:#fef2f2,stroke:#dc2626,color:#7f1d1d
    classDef fastNode fill:#f0fdf4,stroke:#16a34a,color:#14532d
    class ecr ecrNode
    class q decisionNode
    class del,fail badNode
    class keep,ok fastNode

ECR más allá del push: replicación

Cada push a la región de origen se copia solo.

%%{init: {"flowchart": {"nodeSpacing": 30, "rankSpacing": 55}}}%%
flowchart LR
    push["<img src='/static/docker.svg' width='42' /><br/>docker push"]
    push ==> src[("<img src='/static/aws-ecr.svg' width='40' height='40' /><br/>us-east-2<br/>(origen)")]
    src -.->|"réplica automática"| west[("<img src='/static/aws-ecr.svg' width='40' height='40' /><br/>us-west-2")]
    src -.->|"réplica automática"| acct[("<img src='/static/aws-ecr.svg' width='40' height='40' /><br/>otra cuenta")]
    west --> dr["DR: recrear el ambiente<br/>sin la región caída"]
    classDef dockerNode fill:#eff8ff,stroke:#2396ed,color:#0c4a6e
    classDef ecrNode fill:#fff7ed,stroke:#ed7100,stroke-width:2px,color:#7c2d12
    classDef fastNode fill:#f0fdf4,stroke:#16a34a,color:#14532d
    class push dockerNode
    class src,west,acct ecrNode
    class dr fastNode

Se replican los pushes, no los borrados: cada destino define su propia lifecycle policy.

ECR más allá del push: acceso

En un pull entre cuentas deben abrirse dos puertas; lo público va por Amazon ECR Public.

%%{init: {"flowchart": {"nodeSpacing": 30, "rankSpacing": 50}, "themeVariables": {"clusterBkg": "#f8fafc", "clusterBorder": "#94a3b8", "edgeLabelBackground": "#ffffff"}}}%%
flowchart LR
    subgraph consumidora["cuenta consumidora"]
        ecs["servicio ECS"]
        iam["puerta 1: IAM del<br/>task execution role"]
        ecs --> iam
    end
    subgraph shared["cuenta shared services"]
        pol["puerta 2: repository policy<br/>solo pull + aws:PrincipalOrgID"]
        repo[("<img src='/static/aws-ecr.svg' width='40' height='40' /><br/>ECR privado")]
        pol --> repo
    end
    iam ==>|"pull"| pol
    pub[("<img src='/static/aws-ecr.svg' width='40' height='40' /><br/>ECR Public")] -->|"pull anónimo"| world["cualquiera, sin<br/>cuenta de AWS"]
    classDef plainNode fill:#ffffff,stroke:#94a3b8,color:#0f172a
    classDef gateNode fill:#fefce8,stroke:#ca8a04,color:#713f12
    classDef ecrNode fill:#fff7ed,stroke:#ed7100,stroke-width:2px,color:#7c2d12
    class ecs,world plainNode
    class iam,pol gateNode
    class repo,pub ecrNode

ECR más allá del push: escaneo

Búsqueda continua de CVEs conocidos (Amazon Inspector). Findings + agentes → remediaciones como PRs automatizadas, sobre el mismo CI/CD.

%%{init: {"flowchart": {"nodeSpacing": 25, "rankSpacing": 45}}}%%
flowchart LR
    ecr[("<img src='/static/aws-ecr.svg' width='40' height='40' /><br/>imagen")]
    ecr --> insp["Amazon Inspector<br/>escaneo continuo"]
    insp -->|"CVE nuevo"| finding["finding"]
    finding --> agent["agente"]
    agent -->|"PR automatizada"| cc["<img src='/static/aws-codecommit.svg' width='40' height='40' /><br/>repo"]
    cc --> cb["<img src='/static/aws-codebuild.svg' width='40' height='40' /><br/>build"]
    cb ==>|"imagen corregida"| ecr
    classDef ecrNode fill:#fff7ed,stroke:#ed7100,stroke-width:2px,color:#7c2d12
    classDef plainNode fill:#ffffff,stroke:#94a3b8,color:#0f172a
    classDef badNode fill:#fef2f2,stroke:#dc2626,color:#7f1d1d
    classDef agentNode fill:#faf5ff,stroke:#9333ea,color:#581c87
    classDef repoNode fill:#ffffff,stroke:#c925d1,color:#4a044e
    classDef fastNode fill:#f0fdf4,stroke:#16a34a,color:#14532d
    class ecr ecrNode
    class insp plainNode
    class finding badNode
    class agent agentNode
    class cc repoNode
    class cb fastNode