DEV Community: Alex Rodríguez

🤔AWS me está quitando el trabajo...😵

Alex Rodríguez — Wed, 04 Mar 2026 12:36:21 +0000

Cómo desplegar ArgoCD en EKS con SSO sin gestionar un solo pod

Después de bastante tiempo entre eventos, organizaciones y mucho trabajo, volvemos por aquí para hablar de uno de los últimos “avances” que AWS ha presentado.

Con todo el tema de la IA, parece que solo estemos hablando de modelos, agentes y prompts. Pero nada más lejos de la realidad, seguimos gestionando muchísima infraestructura, y AWS sigue lanzando cosas muy interesantes para simplificar esa parte. (menos mal, algún anuncio no relacionado con IA también nos gusta escuchar).

Sin intentar que esto tuviese algún sentido, hemos terminado cerrando una rueda interesante alrededor de EKS, ArgoCD y IAM Identity Center en nuestros posts de #awstwins. La verdad es que en este post he tirado un poco de clickbait, a lo influencer, pero en realidad volvemos al barro y con lo de siempre: Kubernetes y automatización.

En concreto, vamos a hablar de EKS Capabilities.

En posts anteriores como el de acontinuación instalábamos y gestionábamos Argo CD nosotros. Hoy toca darle otra vuelta. Que para eso estamos, ¿no?

argocd&terraform

¿Qué es EKS Capabilities?

EKS Capabilities es una nueva feature de AWS que permite utilizar herramientas del ecosistema Kubernetes gestionadas directamente por AWS.

Es decir,no tienes que instalar nada, mantener nada ni preocuparte de por qué algo está caído.

Básicamente nuestro estilo de vida, no?

Actualmente hay 3 capabilities disponibles:

ArgoCD
De este ya hemos hablado mucho en diferentes posts y es el que vamos a usar puesto que cerramos el circulo. Incluiremos la parte del SSO.
KRO (Kubernetes Resource Orchestrator)
Permite crear recursos de forma declarativa agrupando varios recursos en uno solo.
ACK (AWS Controllers for Kubernetes)
Permite gestionar recursos de AWS directamente desde Kubernetes.

¿La parte interesante de todo esto?

Estas capabilities operan en el control plane de EKS, no en tus nodos ni en tu cuenta.
Resultado: menos componentes que mantener y menos cosas que se rompan.

¿Qué hemos desplegado?

Para ir rápido y evitar mantener algo "custom", hemos hecho lo de siempre: usar módulos de la community.

En este caso:

Una VPC
Un cluster EKS
Karpenter para el autoscaling de nodos (no entraremos en detalle aquí)

Si queréis ver más sobre Karpenter, mi hermano ya publicó un post sobre esto, que siempre podéis dejar un Like!💕:

karpenter

Volvamos a "Capabilities" que es lo que nos interesa. Tal y como decíamos, para esta PoC, podéis encontrar el módulo de EKS Capabilities aquí con los ejemplos, ya sabéis "Copy & Paste" o si no, siempre podéis tirar de IA para un código rápido.

terraform-aws-modules

SSO con IAM Identity Center

Una de las partes más interesantes de usar EKS Capabilities con ArgoCD es que el SSO no requiere ninguna integración adicional.

No hay que tocar:

ConfigMap de ArgoCD
argocd-cm
configuración de OIDC

Simplemente le dices a AWS qué grupos de IAM Identity Center corresponden a qué roles dentro de ArgoCD, y a funcionar.

Ejemplo en Terraform:

module "argocd_eks_capability" {
  source = "terraform-aws-modules/eks/aws//modules/capability"

  type         = "ARGOCD"
  cluster_name = module.eks.cluster_name

  configuration = {
    argo_cd = {
      aws_idc = {
        idc_instance_arn = one(data.aws_ssoadmin_instances.this.arns)
      }

      namespace = "argocd"

      rbac_role_mapping = [{
        role = "ADMIN"

        identity = [{
          id   = data.aws_identitystore_group.aws_administrator.group_id
          type = "SSO_GROUP"
        }]
      }]
    }
  }
}

En mi caso, para ir rápido con la PoC:

He usado mi grupo Admin
He desplegado el cluster en la misma cuenta donde tengo IAM Identity Center

Si queréis hacerlo cross-account, tendrás que crear un Role que permita a Terraform leer los grupos de Identity Center.

Dicho esto, vamos a la práctica de cómo quedaría esta parte.

Una vez desplegado nuestro cluster con todos los requisitos, podemos observar que tenemos argocd funcionando en nuestra pestaña de Capabilities.

Nos conectamos a nuestro endpoint (Argo API endpoint).

Como hemos comentado, la integración con SSO es super rápida, solo indica qué roles quieres usar y el mapping y listo!

Introducimos nuestras credenciales de AWS.

Y ya tenemos argo cd funcionando.

Lo mejor de todo

Cuando lances el código:

Se desplegará ArgoCD como capability
Tendrás SSO funcionando
Podrás loguearte directamente
Y empezar a desplegar tus aplicaciones

Y ahora viene lo mejor:

kubectl get pods -A

No verás ni un solo pod de ArgoCD.

Porque ArgoCD está ejecutándose en el control plane de EKS, no dentro de tu cluster.

Llevamos varios posts hablando de ArgoCD, cual es el mejor diseño, como instalarlo, como configurarlo, como gestionarlo y de repente llega un update de AWS y nos dice y si lo hago por ti? Encima con SSO de serie que más podemos pedir? 😁

Cabe remarcar como siempre que el objetivo es simplemente una PoC, para PROD deberíamos de revisar el tema de dominio privado, clusters adicionales, AppProjects por equipo... pero de eso ya hemos hablado en varias otros posts que podéis recuperar desde #AWTwinS.

Como siempre, cualquier feedback es bienvenido! o por aquí, por LinkedIn o donde podáis encontrarnos! Nos vemos por los eventos!

Sandbox: tu Rent-a-Cloud en AWS y evita gastar 💸 sin sorpresas.

Alex Rodríguez — Wed, 25 Jun 2025 11:25:27 +0000

Y después de renovar por segundo año como Community Builders, de pasar por mil rachas, eventos y líos varios… volvemos a estar aquí con algo que durante años tuvimos que montar a mano, a base de herramientas sueltas, scripts y, por supuesto, discusiones con los solicitantes de cuentas temporales en AWS.

Hoy vuelve #awtwins a enseñarte una solución que automatiza por fin los entornos efímeros en AWS: cuentas temporales, controladas, limpias, y con presupuesto, como si alquilasemos un coche 🚗

💡 El clásico problema del entorno temporal

Pedir cuentas temporales en AWS suele implicar:

🧩 Mucha gestión manual
🔐 Poca trazabilidad
💸 Riesgo de gasto sin control
🧹 Y limpieza… si alguien del equipo se acuerda (ehem, ehem).

Antes usábamos Nuke (tenemos algún post sobre eso también) para limpiar las cuentas y reutilizarlas, pero…

Awtwins-nuke

¿Cómo garantizabas que no eliminabas algo que no debías?
¿Y si el developer necesitaba más tiempo con la cuenta?
¿O quería acceso a otros servicios no permitidos?

Innovation Sandbox on AWS

Amazon ha publicado una solución preconfigurada que automatiza y gestiona:

Creación y control de entornos efímeros
Asignación temporal de cuentas a usuarios
Aplicación de Service Control Policies
Presupuestos con alertas
Reciclaje automático de cuentas con AWS Nuke

Y aquí viene lo divertido: tenemos una UI propia para gestionar todo, inicio de sesión con SSO y posibilidad de extender la solución a medida.

⚙️ Cómo lo desplegamos

Como no podía ser de otra forma, dejamos la documentación por aquí (está bastante bien explicada, pero me gustaría remarcar un par de cositas).

Innovation-Sandbox

🔸 Paso 1 – Cumplir con todos los pre-requisitos (IMPORTANTE).
🔸 Paso 2 – Lanzar stacks (AccountPool + IDC) en tu cuenta de management
🔸 Paso 3 – Lanzar stacks (Data + Compute) en tu cuenta de gestión de la solución.
🔸 Paso 4 – Completar Post-deployment Configuration
🔸 Paso 5 - Generar cuentas y añadirlas a la OU Active

🚨 Esta solución no genera las cuentas del Pool automáticamente.**

🚨 Aseguraros desplegar los stacks en las cuentas que toca, si no, deberéis de redesplegar toda la solución, ya que no funcionará.**

Una vez realizados estos pasos, podemos ir al stack de Compute (en la sección Outputs), copiar el endpoint, pegarlo en el navegador y ya tenemos nuestra solución funcionando.

Al acceder con nuestro usuario SSO con permisos de ADMIN, veremos el panel principal de la solución, desde donde podremos gestionar todo el entorno.

Una vez dentro, crearemos nuestro lease template, que define las condiciones de uso de las cuentas sandbox (duración, permisos, etc.).

Dentro de este template encontramos varias opciones muy interesantes.
Definimos un título para nuestro Lease.

Configuramos un presupuesto (budget) y definimos las acciones que queremos ejecutar cuando se supere el límite establecido.

Definimos cuánto tiempo estará activa la cuenta antes de ser reciclada y las acciones.

Con el template ya creado y usando un usuario Member, accedemos al endpoint de cloudfront para ver que ya podemos solicitar un nuevo lease utilizando las plantillas definidas desde el rol de administrador.

Una vez que el administrador haya aprobado la solicitud de cuenta, podremos ver nuestros leases (en mi caso, aparecen dos, por las pruebas que he realizado para este post).

En cuanto el administrador nos lo apruebe podremos acceder a nuestra cuenta desde el panel.

Ya podemos trabajar con nuestra cuenta, sin miedo a romper nada… ni a gastar de más y lo más importante de todo, una vez el tiempo o el budget definido expira, esta cuenta automáticamente vuelve al pool de cuentas disponibles, por lo que otro usuario puede solicitarla.

Os recomendamos revisar todo lo que ofrece AWS en su documentación (¡vale la pena!), y a curiosear cómo se pueden ajustar presupuestos, políticas y configuraciones usando AWS AppConfig de forma dinámica donde también se define el e-mail al que le llegarán las notificaciones.

Conclusión

Montar un entorno de sandbox temporal en AWS ya no tiene por qué ser una pesadilla de tools, correos, discusiones y gastos imprevistos.

Con la solución de Innovation Sandbox, podemos ofrecer cuentas aisladas, temporales y seguras, con:

Presupuestos controlados,
Restricciones automáticas,
Limpieza garantizada,
Y todo gestionado desde una interfaz, con posibilidad de customizar según nuestras necesidades

Como siempre, cualquier cosa nos podéis encontrar por Linkedin o incluso dejarnos vuestros comentarios por aquí! :)

https://docs.aws.amazon.com/solutions/latest/innovation-sandbox-on-aws/solution-overview.html

"Desplegando Apps con Argo CD: ¿Application o ApplicationSet?"

Alex Rodríguez — Tue, 25 Feb 2025 23:30:48 +0000

Bien, finalmente una serie de 3 capítulos, siendo este el último, donde hemos ido tratando diferentes cositas de como poder gestionar tus apps en EKS usando Argo CD, desde el inicio, hasta el "final", nos gusta dejar siempre el "final" entre comillas, porque como es obvio, quedan muchísimas cosas pendientes.

En este post, nos vamos a centrar en algunos de los recursos y estrategias básicas pero no menos importantes que ofrece Argo CD: Applications, ApplicationSets, Generators, Argo CD Projects y Sync Policies. Hemos elegido estos porque permiten una configuración bastante buena y flexible, manteniendo la simplicidad y accesibilidad para todos los usuarios, sin entrar en detalles complejos/avanzados, ya que nuestra idea no es dar un master sobre Argo CD. Sin embargo, es importante mencionar que Argo CD incluye muchas otras funcionalidades que amplían aún más su potencial, RBAC, Notificaciones, Webhooks, ConfigMaps, Secrets...

Application: unidad básica de gestión en Argo CD, representa una aplicación que se sincroniza desde un repositorio GIT hacia un clúster de Kubernetes.

ApplicationSet: Recurso avanzado que permite definir múltiples Applications a partir de un template y una fuente dinámica de datos, como una lista, clústeres, o un generador de combinaciones. Ideal para gestionar configuraciones repetitivas o despliegues multi entorno.

Generators: Herramientas que crean Applications automáticamente según entradas dinámicas. Un Matrix generator combina varias listas de datos para generar configs un poco complejas. Otras usan listas simples, clústeres registrados o consultas a archivos JSON o YAML.

ArgoCD Projects: Son una forma de agrupación y limitación de Applications en Argo CD.

Sync Policies: Controlan cómo y cuándo ArgoCD sincroniza los recursos en Kubernetes.

Como siempre... para entenderlo mejor, vamos con un ejemplo.

Antes de empezar a desplegar aplicaciones con Argo CD, necesitamos definir un Project. Un Project en Argo CD actúa como un espacio lógico que nos permite organizar y gestionar nuestras aplicaciones de manera más eficiente. Es una forma de limitar qué repositorios, clústeres, namespaces y tipos de recursos pueden usar las aplicaciones asociadas a este proyecto.

En este ejemplo, vamos a crear un proyecto llamado default que permite el acceso a cualquier repositorio Git y cualquier clúster Kubernetes. Esto nos servirá como base para gestionar nuestras aplicaciones sin restricciones iniciales, pero si vas a usarlo en PROD, no lo hagas!

projects/project.yaml

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: default
  namespace: argocd
spec:
  description: Default project for managing applications
  sourceRepos:
  - '*'
  destinations:
  - namespace: '*'
    server: '*'
  clusterResourceWhitelist:
  - group: '*'
    kind: '*'
  namespaceResourceWhitelist:
  - group: '*'
    kind: '*'

Para aplicarlo y no complicarnos ahora con temas de automatización (que ya tocaremos en futuros posts o proyectos), simplemente lo lanzaremos con un buen kubectl

kubectl apply -f projects/project.yaml

Bien, una vez tenemos el project necesitamos las apps, y como las configuramos? Pues definiendo un application, que no deja de ser otro yaml que define como se va a desplegar la aplicación desde un repo GIT en un cluster que tu indiques.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: test-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/tu-usuario/argocd-examples
    targetRevision: main
    path: apps/test
    helm:
      valueFiles:
      - envs/staging/staging-values.yaml
  destination:
    server: https://kubernetes.default.svc
    namespace: test-app
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Hasta ahora, hemos desplegado una aplicación utilizando un recurso de tipo Application, lo cual es bueno para proyectos pequeños o con pocas aplicaciones. Sin embargo, cuando necesitas gestionar muchas aplicaciones, o múltiples entornos para las mismas aplicaciones, este enfoque se vuelve poco práctico.

¿Te imaginas tener que crear y mantener 100 archivos YAML diferentes? Eso no solo genera complejidad, sino que aumenta el riesgo de errores y dificulta la escalabilidad del proyecto.

Aquí es donde el ApplicationSet gana puntos. Este recurso avanzado de Argo CD permite definir múltiples aplicaciones a partir de un único archivo YAML utilizando plantillas y fuentes de datos dinámicas. En lugar de definir manualmente cada aplicación, el ApplicationSet detecta cambios automáticamente en tu repositorio y genera las aplicaciones correspondientes, ahorrándote tiempo y esfuerzo.

¿Qué es un ApplicationSet y cómo funciona?

Un ApplicationSet es un recurso que combina:

Template: Define cómo debería ser cada aplicación generada (por ejemplo, configuración común para todas las aplicaciones en un entorno).
Generator: Proporciona los datos dinámicos para generar múltiples aplicaciones. Algunos generadores comunes son: Git: Detecta carpetas en un repositorio. List: Usa una lista fija de valores. Matrix: Combina múltiples listas para generar configuraciones más complejas.

El resultado es un conjunto de aplicaciones creadas automáticamente según las reglas definidas en el ApplicationSet.

Supongamos que queremos gestionar múltiples aplicaciones en un entorno production. Con un ApplicationSet, podemos definir un archivo que detecte todas las carpetas en apps/ y genere automáticamente aplicaciones para cada una de ellas.
Archivo YAML: prod-appset.yaml

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: prod-appset
  namespace: argocd
spec:
  generators:
  - git:
      repoURL: https://github.com/tu-usuario/argocd-examples
      revision: main
      directories:
      - path: apps/*
  template:
    metadata:
      name: '{{path.basename}}-prod'
    spec:
      project: default
      source:
        repoURL: https://github.com/tu-usuario/argocd-examples
        targetRevision: main
        path: '{{path}}/templates'
        helm:
          valueFiles:
          - '{{path}}/envs/production/values.yaml'
      destination:
        server: https://kubernetes.default.svc
        namespace: production
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

Cómo desplegar el ApplicationSet

Para aplicar este archivo y permitir que Argo CD genere automáticamente las aplicaciones, simplemente ejecuta:

kubectl apply -f appsets/prod-appset.yaml

Ahora que hemos desplegado tanto una Application como un ApplicationSet, es buen momento para comparar ambas opciones y entender sus diferencias clave.

Aspecto	Application	ApplicationSet
Definición	Un archivo por aplicación y entorno.	Un archivo por entorno que gestiona múltiples aplicaciones.
Automatización	No soporta detección dinámica.	Detecta automáticamente nuevas carpetas o entradas.
Configuración común	Requiere duplicación en YAML.	Centralizada en un único template.
Escenarios ideales	Proyectos pequeños con pocas apps.	Proyectos grandes o con entornos dinámicos.

Conclusión

Con ApplicationSets, puedes simplificar drásticamente la gestión de aplicaciones en proyectos grandes o dinámicos. Al reducir el esfuerzo manual y garantizar la consistencia entre aplicaciones, este enfoque no solo te ahorra tiempo, sino que también mejora la escalabilidad de tu proyecto.

Como hemos comentado, las applications son perfectas para casos simples pero los ApplicationSets son la herramienta perfecta para quienes buscan automatizar y facilitar la gestión de múltiples entornos y servicios.

PD: Como siempre, dependerá de las necesidades de tu proyecto.

Con esto, vamos a dejar esta mini serie aquí, una vez desplegadas las aplicaciones con Applications y ApplicationSets, porque si seguimos, ¡no acabaríamos nunca! Además, ya sabéis que la gente PRO de verdad tiene sus cursos y certificaciones, y nosotros necesitamos dedicar más tiempo a los recursos nuevos de AWS y las automatizaciones. 😊

Nota: No hemos profundizado mucho ni siquiera entrado a hablar del patrón App of Apps en este post, porque no queríamos extender esta serie en mil capítulos. Sin embargo, si os interesa y queréis profundizar más en estos temas más avanzados, desde Codefresh podéis acceder a sus cursos oficiales con certificación, donde se incluyen laboratorios prácticos para aprender en un entorno controlado. ¡Totalmente recomendados! 🚀

Y ahora sí, ¡a seguir desplegando con estilo! 😉

Dejamos el link por aquí: https://learning.codefresh.io/

🚀Gestiona tus aplicaciones en EKS con Argo CD 🚀

Alex Rodríguez — Thu, 26 Sep 2024 14:58:28 +0000

Como ya venimos avisando hace un tiempo #AwTwins nos lanzamos a crear una serie de como gestionar clústers EKS.

Si has trabajado en varias empresas, probablemente habrás notado que cada una gestiona las aplicaciones en los clústers a su manera, algunas utilizan unos con pipelines que hacen un kubectl apply, otros prefieren hacer un helm install a mano, actualizaciones manuales y un largo... Pero nosotros que somos fans de Gitops, siempre buscamos facilitarnos y dar más control y autonomía a los equipos y clústers. Por eso hoy venimos a hablarte de Argo CD.

¿Y qué es Argo CD?

Es una herramienta declarativa de Gitops hecha para gestionar aplicaciones en Kubernetes de forma continua. La idea es que Argocd se encargue de mantener sincronizado el estado real de las aplicaciones y recursos en el clúster con lo que existe en GIT.

Características principales:

Modelo GitOps: El estado de las aplicaciones se gestiona a través de repositorios GIT.
Automatización de despliegues: Despliegues automáticos o manuales,flexibilidad ante todo!
Rollbacks y sincronización automática: Argo cd puede identificar automáticamente las diferencias entre el estado real de los recursos en el clúster y el estado deseado en GIT y permite realizar rollbacks o sincronizaciones automáticas cuando sea necesario.
Control de acceso con RBAC: Argo CD ofrece un control granular de acceso, asegurando que diferentes equipos tengan acceso solo a las aplicaciones y entornos que les corresponden. En otras palabras, tocas lo que tienes que tocar.
Soporte multiple formato: Argo CD es compatible con Helm Charts, Kustomize,YAML, Jsonnet. Menos problemas!
Integración continua (CI/CD): Se integra fácilmente con pipelines CI/CD.
Interfaz gráfica: Permitiendo ver el estado de las aplicaciones en el cúster y su sincronización en el repositorio GIT en tiempo real.

Patrones de implementación de Argo CD en EKS

Dependiendo de la escala y la complejidad de tu infraestructura, puedes elegir diferentes patrones para implementar Argo CD en tu entorno de Amazon EKS.

1. Una instancia de Argo CD gestionando todos los clústers

Este patrón implica utilizar una sola instancia de Argo CD para gestionar múltiples clústers de Kubernetes. Instalas un argo cd en un clúster "master" y desde ahí te encargas de desplegar apps en todos los otros clústers.

Ventajas:

Centralización: Tienes una sola interfaz desde donde puedes gestionar múltiples clústers.
Menor trabajo operativo: Solo una instancia de Argo CD que mantener, lo que reduce costes operacionales.
Facilidad de monitoring: Todos los despliegues están visibles y accesibles desde un solo panel de control.

2. Una instancia de Argo CD por cada clúster

En este caso, cada clúster de Kubernetes tiene su propia instancia de Argo CD independiente. Esto es lo que podríamos llamar un patrón de Single-Tenant, ya que cada instancia está aislada y no interactúa con otras instancias de Argo CD.

Ventajas:

Aislamiento: Cada clúster y su Argo CD están completamente aislados, por lo que los problemas en un clúster no afectarán a los demás.
Escalabilidad: Cada clúster tiene su propia instancia de Argo CD, por lo que el crecimiento en el número de clústers o aplicaciones no impacta en el rendimiento de otras instancias.
Seguridad: Puedes aplicar configuraciones personalizadas de seguridad para cada clúster y su Argo CD.

3. Un Argo CD que despliega otros Argo CDs.

¿Que fué primero el huevo o la gallina? En este caso, un Argo CD "master" se encarga de gestionar y desplegar otras instancias de Argo CD en incluso en el mismo. Esta estrategia es útil cuando tienes un entorno altamente distribuido con múltiples clústers que necesitan su propia instancia de Argo CD, que deben ser gestionados desde un punto central.

Ventajas:

Escalabilidad: Permite gestionar y desplegar muchas instancias de Argo CD desde un único lugar, lo que es útil en grandes organizaciones con cientos de clústers.
Descentralización: Cada clúster tiene su propio Argo CD, pero puedes automatizar y coordinar su gestión desde el Argo CD maestro.
Facilita el gobierno: Puedes aplicar políticas globales desde el Argo CD "master" mientras permites personalización a nivel de clúster.

Conclusión:

Cada uno de estos patrones de implementación de Argo CD tiene ventajas y desventajas específicas, y la elección depende del tamaño de la infraestructura y los requisitos operativos de tu organización.

Próximo episodio: Implementaremos Argo CD en un clúster de Amazon EKS utilizando Terraform, lo que nos permitirá desplegar una primera versión funcional de Argo CD y comenzar a jugar con sus capacidades.

🚨 Aquí venimos a jugar, así que ¡Keep Ready! 🚨

🎵 Desplegando infraestructura en AWS desde Backstage 🎵

Alex Rodríguez — Tue, 13 Aug 2024 11:15:05 +0000

👋¡Estamos de vuelta! 👋 Después de algún otro tiempo desaparecidos y alguna que otra certificación en el bolsillo y algún que otro proyecto nuevo en mente. ¡Vamos a darle caña! 🚀

¿Cuántas veces hemos discutido sobre si la infraestructura debería gestionarse por un lado y la aplicación por otro, si todo en el mismo sitio, o en dos,tres, cuatro portales diferentes, hasta acabar volviéndote loco sin saber que usar. Vamos a simplificar las cosas y ver cómo podemos usar el mismo frontal que los desarrolladores para desplegar un "template" de Terraform recogiendo variables directamente desde allí. 🤯

En primer lugar me gustaría dar dos pinceladas sobre Backstage:

Si todavía no sabes que es, aún por todo lo que está siendo sonado, te estás perdiendo algo interesante. Backstage es una plataforma de desarrollo open-source creada por Spotify. Te permite hacer un montón de cosas diferentes, desde microservicios hasta documentación, e incluso gestionar infraestructura. En este post nos vamos a centrar en cómo usar Backstage para desplegar infraestructura en AWS con Terraform. ¡Al lio!

En este caso tal y cómo muchos ya sabéis, nosotros no somos desarrolladores al estilo, así que hemos necesitado alguna ayuda para poder configurar un backstage de TEST, ¡Y menuda ayuda! Aquí os dejamos una serie de tutoriales de [return(GIS)]-Gisela donde te explica una infinidad de cosas y os pueden ayudar con la configuración, personalización y despliegue de vuestro backstage. 💯¡Totalmente recomendado! 💯

Backstage - return(GIS)

En nuestro caso vamos a simplificar todo muchísimo para no extendernos una infinidad y asegurarnos de que realmente podemos lanzar nuestra infraestructura desde un portal como Backstage.

Estructura del Repositorio que contiene el template

s3-template/
├── terraform/
│   └── s3.yaml   
└── catalog-info.yaml

Estructura repositorio que contiene el terraform y la pipeline

apply-terraform/
├── .github/
│   └── workflows/
│       └── terraform-deploy.yml
└── backend.tf
└── main.tf
└── provider.tf

Vamos a explicar ahora que contiene cada uno de estas configuraciones:

Catalog-info.yaml: Este archivo básicamente es un mapa para Backstage, le indica donde dónde encontrar nuestro template en Github. Lo subes al repositorio, lo importas a Backstage, ¡y a funcionar! ¡Ya tienes tu template disponible para seleccionar en backstage!

apiVersion: backstage.io/v1alpha1
kind: Location
metadata:
  name: s3-template-location
  description: Repositorio en GitHub para el template de creación de buckets S3 con Terraform
  annotations:
    backstage.io/managed-by: backstage
spec:
  targets:
  - terraform/s3.yaml

Template: Este template básicamente le dice a Backstage cómo crear un bucket S3. Los usuarios entrarán, rellenarán un par de campos y backstage se encarga de todo lo demás!

apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: s3-bucket-terraform
  title: S3 Bucket con Terraform
  description: Crea un bucket S3 utilizando Terraform
spec:
  owner: user:guest
  type: service
  parameters:
  - title: configurar bucket s3
    required:
    - s3name
    - acl
    properties:
      s3name:
        title: s3name
        type: string
        description: Unique name of the component
        ui:autofocus: true
        ui:options:
          rows: 5
      acl:
        title: acl
        type: string
        description: private
        ui:autofocus: true
        ui:options:
          rows: 5

  steps:
  - id: github-action
    name: github-action
    action: github:actions:dispatch
    input:
      workflowId: terraform-deploy.yml
      repoUrl: 'github.com?repo=apply-terraform&owner=**YOURUSER**'
      branchOrTagName: "main"
      workflowInputs:
        s3name: ${{ parameters.s3name }}
        acl: ${{ parameters.acl }}

Bien, ya tendríamos la parte de backstage pura y dura, vamos a darle uso con una prueba concreta. En este caso, vamos a utilizar un bucket S3 para la PoC. Necesitamos definir algunos archivos de Terraform y una pipeline que los depliegue usando las variables que recogemos. Para ello, crearemos los siguientes archivos en nuestro segundo repositorio: apply-terraform

main.tf: por simplificar pondremos la creación usando el siguiente código:

resource "aws_s3_bucket" "example" {
  bucket = var.s3name
  acl    = var.acl
}

variable "s3name" {
  type = string
}

variable "acl" {
  type = string
}

backend.tf: definimos nuestro backend para el estado

terraform{
    backend "s3" {
        bucket = "yourbuckets3"
        encrypt = true
        region = "eu-west-1"
        key = "terraform.tfstate"
    }
}

provider.tf: provider a utilizar

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

# Configure the AWS Provider
provider "aws" {
  region = "eu-west-1"
}

Y por último la pipeline, la cuál hace exactamente lo que necesitamos: recoge los inputs (s3name y acl) que le pasamos desde Backstage y luego usa Terraform para crear el S3 s3 en AWS. 💥¡Magia! 💥

name: Terraform pipeline

on:
  workflow_dispatch: 
    inputs:
      s3name:
        description: 'Name of s3 bucket'
        required: true
      acl:
        description: 'ACL'
        required: true
env:
  AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
  AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
jobs:
  apply_s3:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout codigo
      uses: actions/checkout@v2

    - name: Setup Terraform
      uses: hashicorp/setup-terraform@v1

    - name: Terraform Init
      run: terraform init

    - name: Terraform apply
      run: terraform apply -auto-approve -var s3name=${{ github.event.inputs.s3name }} -var acl=${{ github.event.inputs.acl }}

En este caso muy concreto el template nos solicitará los dos parametros que queremos:

En esta PoC, como siempre, hemos ido por la vía rápida, pero es importante mencionar que solo hemos tocado un 1% de lo que Backstage puede ofrecer. Por ejemplo, no hemos integrado el registro de componentes en el catálogo de Backstage ni configurado pipelines CI/CD para monitorizar flujos directamente desde Backstage. Si quieres más información, te recomiendo que revises la documentación oficial de Backstage o le eches un vistazo a los videos mencionados anteriormente para llevar tu configuración de Backstage al siguiente nivel y personalizarlo a tu gusto.

Nosotros hemos usado la acción github:actions:dispatch, pero Backstage soporta un montón de otras acciones para poder hacer de tu infra algo mejor que lo que hace este post 🥵

Algunos links interesantes:

Documentación oficial
Actions
Generate Docs

👋 Como siempre, esperamos recibir comentarios, issues y sugerencias para seguir mejorando! 🫵

¡Nos vemos en el siguiente!

💸Ahorra en tus cuentas de AWS. usa 💥aws-nuke💥 para limpiar recursos.💸

Alex Rodríguez — Wed, 22 May 2024 06:56:44 +0000

Sí, lo sabemos, estos últimos meses hemos estado desaparecidos, pero con razón: ¡estábamos preparándonos para la certificación de AWS! ¡Y la aprobamos los dos a la primera! 🎉

Aunque no hemos estado completamente fuera del radar. Tenemos un montón de temas interesantes que queremos compartir con vosotros, y, claro, ¡nos veremos en el AWS Summit Madrid como todos los años! 🫵

Hemos estado en un montón de proyectos donde, ya sea por requisitos específicos o simplemente para seguir buenas prácticas de despliegue, siempre hacemos la PoC en la cuenta de PoC. Después, pasamos a dev, test, pre... y así seguimos el ritual de las cuentas.

El problema es que, muchas veces, nos olvidamos de eliminar los recursos en esas cuentas. ¿Y qué pasa después? ¡Exacto! Nos llega la factura y nos da un infarto al ver el palazo que nos meten. 💸😂

Para intentar no morir en el acto, podemos usar AWS-NUKE:

AWS-NUKE

REPO

Es cierto que podríamos descargar el binario directamente y ejecutarlo desde donde queramos, pero ya sabes, no somos muy de andar ejecutando cosas en local. Preferimos la opción mencionada arriba. Con un toque de CloudFormation, ¡voilà! Listo para hacer limpieza en AWS.

Como se puede ver en el repositorio, tenemos un ficherito llamado nuke-cfn-stack.yaml, el cual nos ayudará en nuestro despliegue. Así que, IDE en mano, ¡a darle caña! 📒 (Siento que salgan palabras con subrayado, pero, dados los mil plugins que tengo en este portátil, se me van subrayando).

⏳ Indicaremos en el CRON la hora a la que queremos que se ejecute nuestra limpieza. ⏳

📩 Indicaremos un e-mail al que queremos que nos lleguen las notificaciones, tanto de errores como de alegrías. 📩

Ahora, en este apartado, vamos a marcar las regiones que queremos "nukear". Sí, has oído bien, ¡"nukear" es la palabra! Así que selecciona tus regiones con cuidado, no te vayas a cargar lo que necesitas.

🚀 Una vez hayamos ajustado todo a nuestro gusto, es hora de desplegar la plantilla de CloudFormation. 🚀

¡Eh, 🚨🚨! Como podemos ver en la última imagen, siempre lanzamos el AWS-NUKE en modo DRY. ¿Por qué? Porque así evitamos cualquier desastre estilo "eliminar sin retorno". Pero, hey, a veces queremos ir al modo hardcore (como en esta PoC, que queremos testear que elimine cosas), entonces pondremos el valor a FALSE.

Una vez desplegado nuestro stack de CloudFormation, podremos ver un nuevo bucket S3. Por lo que toca subir los dos ficheros que se encuentran en el directorio config.

Config

¿Qué podemos hacer con ellos? Bueno, básicamente, ¡añadir restricciones o permitir lo que queramos!

En nuestro caso, hemos generado dos buckets, uno de ellos con un nombre totalmente RANDOM, el cual buscamos que sea destruido, y otro de ellos con el nombre bucket-no-nuke-alex, el cual queremos que no se destruya nunca. Por tanto, editamos los ficheros indicando nuestras necesidades.

Una vez modificados los ficheros, los subimos al bucket S3 y tocará esperar los resultados.

Y así llegamos al final de nuestra aventura con AWS-NUKE. Después de desplegar todo y hacer nuestras configuraciones, vemos los resultados: el bucket con la restricción sigue en pie, mientras que el que no tenía protección ha sido eliminado sin piedad. 🎯

👋 Como siempre, esperamos recibir comentarios, issues y sugerencias para seguir mejorando! 🫵 Si nos véis por Madrid, ¡decidnos algo!

AFT: tu asistente personal en tus cuentas de AWS 🥶

Alex Rodríguez — Fri, 15 Mar 2024 09:05:28 +0000

En nuestro último post de #AwtwinS, hablamos sobre ECS, Service Connect y GitHub. En este, nos vamos a desviar un poco; volvemos al inicio de nuestros recursos: nuestras cuentas y su gestión.

🚀 Esta vez vamos a intentar que gestionar las cuentas de AWS no sea una pesadilla y, ¿por qué no?, intentar automatizar al máximo tanto el despliegue como la personalización de las mismas.🚀

¡Para ello contamos con nuestro nuevo amigo, AFT! ¿Quién dijo que administrar las cuentas no podía ser divertido? 🥵

Como siempre, adjuntamos documentación extensa por parte de nuestros colegas de AWS donde explican qué es AFT, pero dejamos un pequeño resumen.

AFT-AWS

🫰 AFT te brinda una ventaja significativa de aprovisionamiento de cuentas basado en Terraform, al mismo tiempo que te permite gestionar las cuentas con AWS Control Tower. ¡Pim, Pam! 🫰

¿Qué nos permite AFT? Dejamos algunos beneficios a continuación:

Enviar solicitudes de nuevas cuentas y actualizar cuentas en nuestro modelo GitOps (¿no suena eso familiar?).
Almacenar los metadatos e historial en nuestro repositorio de código.
Aplicar etiquetas a nivel de cuenta.
Personalizar nuestras cuentas de forma individual o conjunta (hablaremos más sobre esto después).
Registro de eventos de datos de CloudTrail.
Inscribir nuestras cuentas en planes de soporte.
Eliminar la VPC predeterminada en nuestras cuentas.

Después de explicar las funcionalidades de AFT, se nos plantean muchas situaciones, pero me gustaría explicar una en particular.

Después de entender lo que nos puede aportar, agreguemos más valor al tema común en muchos equipos (pregunta de examen):

Toda nuestra infraestructura está definida con Terraform y sus pipelines, pero ¿quién crea el bucket S3? Es como preguntarse: 🐔'¿Qué va primero, el huevo o la gallina?'🥚

Siempre hay diferentes soluciones disponibles, como Service Catalog, plantillas de CloudFormation o incluso hacerlo de forma manual. Pero, ¿qué tal si lo incluimos en nuestros Terraform y separamos el proceso de arranque de la cuenta de la infraestructura? ¡Interesante, ¿verdad?! ¡Pues manos a la obra!👷

Requisitos:
Debemos de tener una Landing Zone creada con Control Tower.

Para no extender mucho el post, dejamos documentación que podéis seguir. No obstante, es como rellenar un formulario :)

Landing Zone

Crearemos una nueva cuenta de gestión AFT y la asociaremos a una nueva Organizational Unit (OU) llamada AFT Management. Utilizaremos Control Tower para generar la cuenta.

Esto como bien dice la documentación de AWS, puede tardar alrededor de unos 30 minutos aproximadamente.

Configuración AFT

Cierto, a veces con tanta información puedes ir un poco perdido, así que vayamos paso a paso.

En primer lugar AFT necesita disponer de 4 repositorios extras para su correcto funcionamiento. Recomendamos hacer un FORK desde el siguiente enlace, ya que deben seguir una estructura específica de directorios & archivos para funcionar correctamente.

Repos-AFT

Una vez que tengamos los repositorios en nuestro GitHub, vamos a explicar qué hace cada uno de ellos. Toda la información está detallada en los archivos Readme.md de cada repositorio.

aft-account-request: Este repositorio contiene las solicitudes de cuenta para AFT. Aquí es donde deberás añadir las cuentas que te gustaría desplegar con AFT.

aft-account-customizations: Este repositorio contiene los 'helpers' de Terraform y API para personalizar las cuentas. La personalización de las cuentas puede estar definida en Terraform o en Python aprovechando los 'helpers' de la API.

aft-account-provisioning-customizations: AFT nos brinda la oportunidad de personalizar el aprovisionamiento de nuevas cuentas e integrarlo con los sistemas antes de personalizar estas cuentas.

aft-global-customizations: Este repositorio contiene los 'helpers' de Terraform y API para las personalizaciones globales. Esto se puede utilizar para personalizar todas las cuentas con recursos definidos. Al igual que antes, se puede aprovisionar con Terraform o Python.

¡Guay! Ya tenemos nuestros 4 repositorios que AFT utilizará para el deploy de nuestras cuentas.

Deploy AFT
Una vez que hayamos creado nuestros repositorios, podemos proceder a desplegar AFT. Para ello, dejo otro ejemplo en el siguiente enlace:

Repositorio Principal AFT

Como podemos observar en dicho repositorio, tenemos muchos ejemplos de cómo hacer la llamada a dicho módulo. En nuestro caso, como nos interesa trabajar con GitHub, utilizaremos el ejemplo github+tf_oss.

Github+tf_oss

Que hace este módulo?

Configura la cuenta de Management AFT. Configura CodeStar para que cada vez que hagas un push en tu GitHub se lance la pipeline en CodePipeline, y configura los repositorios que AFT necesita para funcionar.

En primer lugar, comenzaremos realizando un terraform apply de nuestra llamada al módulo, modificando las variables con las ID de nuestras cuentas. Como hemos comentado en otras ocasiones, ¿podemos utilizar GitHub Actions y evitar el uso local? Luego sabemos lo que pasa... 🤫

👾Este deploy debe de ser en la cuenta de Control Tower👾

Main.tf

Recomendamos agregar estas líneas para no ocasionar gastos extras en vuestra PoC:


  aft_enable_vpc              = false
  aft_vpc_endpoints            = false

Una vez desplegado, deberemos de dirigirnos a nuestra cuenta de Control Tower y otorgar permisos al Role de AFT:

AWS Control Tower Account Factory Portfolio

Le damos permisos al Role:

Configuración CodeStar

De igual forma que explicamos con Apprunner, debemos aceptar la conexión pendiente en Codebuild - Settings en nuestra cuenta AFT:

Deberemos de darle permisos a la app de Github para que pueda conectar con los repositorios que necesita AFT. 🙃(Up to you! nosotros solo damos permisos a los repositorios necesarios).

Una vez conectados, deberemos relanzar las pipelines que veremos en nuestro Codepipeline:

Ahora que tenemos configurado nuestro AFT, podemos empezar a jugar con él. En primer lugar, vamos a provisionar una nueva cuenta de TEST. Para ello, iremos a nuestro repositorio de Github (aft-account-request) y modificaremos el archivo main.tf en la ruta aft-account-request/terraform/main.tf, modificando las variables como en el siguiente ejemplo:

module "sandbox5" {
  source = "./modules/aft-account-request"
  control_tower_parameters = {
    AccountEmail              = "email"
    AccountName               = "sandbox-aft5"
    ManagedOrganizationalUnit = "Sandbox (ou-xxxxxxx) " 
    SSOUserEmail              = "email"
    SSOUserFirstName          = "Sandbox"
    SSOUserLastName           = "AFT"
  }

  account_tags = {
    "Learn Tutorial" = "AFT"
  }

  change_management_parameters = {
    change_requested_by = "alex"
    change_reason       = "Learn AWS Control Tower Account Factory for Terraform"
  }

  #custom_fields = {
  #  group = "non-prod"
  #}
  account_customizations_name = "testing"
}

¡Lanzamos nuestra pipeline haciendo un push y 💥!Podremos ver en Control Tower cómo empieza a aparecer nuestra nueva cuenta "sandbox-aft5" en la OU que hemos seleccionado! 🥳

😎Por otro lado, pongamos atención a esta línea? 🕶️

account_customizations_name = "testing"

¡Bien, aquí es donde tenemos más juego!Como bien sabemos, tenemos otro repositorio llamado aft-customizations donde ocurrirá la magia. 🫣 Que empiece el juego!🫣¿Y si queremos crear un bucket S3 para que sea creado en el momento de crear la cuenta? Pues vamos allá!

💢 Atención! 💢
Es de vital importancia seguir la estructura indicada en los repositorios para que funcione correctamente.En este caso,lo haremos siguiendo la siguiente estructura:

Hacemos push a este repositorio y automáticamente se lanzará una nueva pipeline en nuestro CodeCommit, generando así nuestro Bucket S3 (podemos verlo en la cuenta de AFT).

Y como no, si accedemos a nuestra cuenta final (sandbox5), veremos nuestro bucket S3.

Como hemos visto, podemos personalizar nuestras cuentas desde el inicio, lo que nos permite generar recursos en las cuentas indicando si queremos que se apliquen en todas, solo en las seleccionadas y, lo más importante, ¡usando Terraform! 🚀

Para más información dejamos un link:

AFT

✌️ ¡Aviso Importante! Este post está creado con el propósito de compartir conocimientos y experiencias en el entorno de una Prueba de Concepto (PoC).

🚨¡Atención! 🚨 No fijar las versiones de Terraform como en la PoC puede causar graves problemas en tu entorno de producción. Recomendamos siempre indicar la versión del módulo usado y verificar las versiones de Terraform para no ocasionar ningún error.

🤑Por último, cabe señalar que aunque comenzamos experimentando con un bucket, ¡nos hemos vuelto locos probando otros servicios! Recomendamos también tener precaución con las configuraciones de AWS Config para evitar sorpresas desagradables 💸, al igual que con los recursos de networking.🤑

👋 Como siempre, esperamos recibir comentarios, issues y sugerencias para seguir mejorando! 🫵

PD: En los siguientes volvemos con EKS! 😱

Un cóctel perfecto 🍹 ECS Fargate, Service Connect,Terraform y Github Actions.

Alex Rodríguez — Mon, 12 Feb 2024 08:47:26 +0000

En nuestro último post de #AwtwinS comentamos un avance del Re:Invent donde utilizabamos EKS POD Identity para administrar las credenciales de aplicación 🔐 y como no, hablando de containers, como también comentamos la parte de AppRunner, EKS y ahora porque no... un poquito de ECS. 🚀

✌️En esta nueva Poc tenemos dos servicios en ECS Fargate✌️

Front: Usaremos un script en python que hará llamadas contra nuestro backend, como siempre. (dummy-dummy)
Backend: Servidor HTTP que escucha en un puerto especifico, este está en Nodejs. (otra dummy-dummy) ¡Prepárate para disfrutar de un cóctel!

No obstante cuando pensamos en servicios, debemos de pensar también en como vamos a conectar esos servicios y aquí en AWS surgen varias formas de conectarlos.🪢

En primera instancia pensamos en ELB por servicio, creando así un espectáculo de balanceadores. Sin embargo, cuanto nos cobran la entrada, el espectáculo deja de ser divertido, aquí es donde se complica.🤑 Y si tienes que luchar contra el Preserve IP? (Esta experiencia,que merecería otro post propio nos enseña que cada solución tiene sus desafios)🤯

En este caso vamos a hablar de Ecs Service Connect, baile de proxies 🕺 en perfecta coordinación 🕺. Service Connect despliega sus artes escenicas a través de un container Sidecar que se ejecuta a cada tarea del servicio. Este Sidecar actúa como proxy, gestionando las conexiones entre servicios. Pero aquí el paso brutal: Service connect registra los endpoints en Cloud Map por nosotros.

Para más información:
Service Connect

Tenemos dos subnets en la VPC con 2 servicios. Nuestro frontend es el encargado de hacerle peticiones a nuestro backend.

En este caso,la conexión se está usando con el nombre corto de ecs-backend en el puerto para nuestro backend, definiendo los puertos en el terraform de nuestra task definition.👏

Para entender mejor esto, el baile en el siguiente diagrama:

Comentada la teoría pasemos a la acción! Módulos de terraform de community 😶‍🌫️ Github Actions y Service Connect.😶‍🌫️

Para este caso los módulos que utilizaremos son los siguientes:

ECR
VPC
ECS

Cabe remarcar que añadiremos una parte de código (Service Discovery) en alguno de ellos para hacer nuestra PoC, no obstante,os dejamos nuestros repos públicos con la PoC. 💻

Terraform-ECS-PoC
Frontend Dummy
Backend Dummy

Al desplegar nuestro terraform desde el repositorio podremos ver el ECS con sus respectivos servicios.

Como decíamos, nuestro compi de baile se ejecuta a su lado como un Sidecar.

Una vez desplegado y configurado todo y al no tener endpoint público, usaremos cloudwatch para ver los registros y podemos ver que están conectando correctamente nuestras apps. 🥵

✌️ ¡Aviso Importante! Este post está creado con el propósito de compartir conocimientos y experiencias en el entorno de una Prueba de Concepto (PoC).

Etiqueta "latest" en Docker: ¡Atención! 🚨 (Puede ocasionar problemas en tus entornos)

Costos Asociados y Buenas Prácticas 📊: Además, en este entorno de Poc, hemos tomado decisiones que pueden tener implicaciones en términos de costes, VPC, Logs... En el mundo real, se recomienda seguiir unas buenas prácticas, optimizar costes y tener en cuenta la seguridad y eficiencia.

Por tanto, a testear con responsabilidad! 🔍

Esperamos vuestras reacciones y comentarios! 🎉

"Desplegar sin Miedo: Un Cuento Épico de App Runner, Terraform y GitHub Actions."

Alex Rodríguez — Mon, 15 Jan 2024 21:40:37 +0000

⏳¡Un mes más tarde del primer post volvemos a la carga!⏳ En el último post exploramos los Parches automáticos para liberar tu agenda y así no quedarte dormido el día siguiente. ¡Pero la aventura acaba de empezar!🪂
En esta tercera entrega, nos adentramos en tierras más actuales, donde los términos serverless, containers, devops y todo su séquito despliegan su magia. Sin embargo, hoy, decidimos darle un toque de luz a un servicio que no es ni ECS ni EKS.🫣 Aunque, ¡no te preocupes! Estos seguro que tendrán su propio espacio en futuras historias que ya estamos preparando... 🥵 ¡Que empiece la locura!🥵

✈️En este post nos surmergimos en un viaje donde desplegaremos nuestra magia utilizando múltiples servicios simultáneamente, todo orquestado para que la experiencia sea lo más automática posible.✈️ ¿El dúo protagonista de esta historia? Terraform, Github Actions y App Runner, dos de las herramientas que están en boca de todos y que liderarán este post. 💥

Antes de nada... 📚 un paso atrás para desvelar los misterios del servicio. El viaje inicial explorando sus rincones de manera manual y a través de la consola de AWS:

AppRunner

AWS App Runner es un servicio de aplicaciones completamente administrado que le permite crear, desplegar y ejecutar servicios de API y aplicaciones web en sin necesidad de experiencia previa en contenedores o infraestructuras.

Como se señala en la documentación, AppRunner es el héroe que llega para desplegar y ejecutar servicios APIS y aplicaciones web sin requerir conocimientos previos en contenedores o infraestructura. 🥱¡Adiós a las reuniones infinitas sobre configuraciones complejas!🥱 O como mínimo los “no me funciona” 🥴

Nos adentramos en el territorio de despliegue y tenemos dos caminos: uno desde Container registry y otro desde Source Code Repository. Ambos con sus cositas, así que vamos a adentrar un poco en cada uno de ellos y descubrir cuál se adapta mejor a nuestras necesidades.

Si optamos por el camino del Container Registry, podemos elegir entre ECR Private o ECR público , en este caso nuestra misión es desplegar usando el público con la siguiente imagen:

Hello-app-runner

⛔En el caso de utilizar ECR Public no es posible usar las actualizaciones automáticas pero no te preocupes, que pronto entramos a ver como desplegar con estilo pero sin actualizaciones automáticas.⛔

Configuraremos aquí los valores que necesitemos tales como VirtualCPU/Memory,si tenemos variables de entorno, en additional configuration podemos encontrar también el start command, por si necesitamos algún otro momento de magia.🚀

⚡En la parte de AutoScaling veremos el arte de la escalabilidad automática. Aquí configuraremos las solicitudes, establecer el máximo,el mínimo y dejar que AppRunner realice su propia magia basándose en métricas como las solicitudes y alguna que otra métrica interna, dejamos más información para los curiosos. ⚡

Autoscaling-apprunner

Tenemos la capacidad de modificar los Health Checks para asegurarnos que nuestras instancias siempre estén funcionando como deben. 👨‍🔬

Permisos, WAF y AWS MKS key No vamos a entrenar servicio por servicio puesto que cada uno debe de ser modificado en base a necesidades. Un consejo sabio: siempre activar WAF a todos aquellos que se aventuren a jugar en entornos productivos, que nos conocemos.🕵️

Como también nos puede interesar desplegarlo en privado, tenemos una opción para ello:

Cabe remarcar que para Private endpoint necesitaremos un VPC interface endpoint y un VPC connector. (si lo necesitáis, podemos subir a git un ejemplo, pero dependerá de las reacciones y comentarios así que...)🚀

🕵️Y por último la parte de monitoring que podemos cubrirla con X-RAY 🕵️

No obstante, también está integrado con Cloudwatch por lo que podremos ver los logs de nuestro service y de nuestra app en el mismo.

Con todos los valores revisados y afinados, el momento mágico ha llegado. Es hora de apretar el botón mágico ‘Create & Deploy’ y ver cómo nuestra app dummy cobra vida.

Un clic en default domain y ¡Voilà! ¡La magia funcionó y nuestro servicio se desplega! 🫡

¡Bien! Ya hemos dominado la magia de desplegar con Apprunner pero ahora, llevaremos el servicio a otro step. Como hemos visto nuestro servicio puede conectarse a nuestro repositorio de código, permitiendo así que cada push inicie automáticamente el despliegue de una nueva versión.

👋¡Adiós a las builds no funcionan! Desde ahora, cada modificación en nuestro código desencadenará una nueva versión de la aplicación, así, desplegando con su flow! 👋

Para poder testear este paso hemos generado un repositorio que contiene una app en python, como nos gusta decir, de las cutres, pero cutres...que lo único que hace es decir (“Hello from Flask in App Runner! ) donde podrás encontrar el DockerFile, app.py, apprunner.yaml y requirements.txt (Como siempre, si no queréis fracasar, ⛔no usar esto para producción)⛔ PD: No somos developers, no critiquéis mucho 🤭

Dejo el link a continuación:

frontend-app

Para dar inicio a esta odisea, elegiremos la opción ‘Source code repository’ al crear nuestro servicio. Pero antes de pasar al capitulo final tenemos que crear una conexión con nuestro repo.

En repository seleccionamos nuestro repository:

Para que cada vez que modifiquemos la imagen se apliquen los cambios debemos de seleccionar Automatic.

✌️ En el siguiente paso podremos configurar si deseamos configurar nuestros valores mediante consola o bien en el mismo repo con un fichero apprunner.yaml, ya que estamos, lo haremos por fichero para no volver a caer en lo manual. ✌️

👏 ¡Y así, aplauso y nuestro despliegue se completa! (Si todo va bien, si no, a mirar los logs!) 👏

¡Walaa! Nuestra aplicación se encuentra en todo su esplendor, lista y pública para todos!😋

Con la aplicación desplegada nos llega el momento de presenciar la magia de la automatización, Realizaremos un cambio en la aplicación, como por ejemplo añadir v1.0 y veremos que al hacer un push, despliega una nueva versión con un simple push.🕺

Como hemos comentado, estamos evitando huir de las cosas manuales, por lo que todo esta parte ha sido únicamente creada a mano para entenderlo, pero en realidad, al hacer la PoC hemos desplegado todo con terraform y GitHub actions. (Ya avisamos de qué son simples y una primera versión, otra vez más,😈 no deberemos usarlas para producción puesto que su única finalidad es la PoC). 😈

En nuestra búsqueda de eficiencia y simplicidad, hemos recurrido a herramientas proporcionadas por la comunidad.
En este caso, utilizamos terraform, aprovechando los módulos que nos brinda la comunidad, además para el despliegue confiamos en la magia de Github Actions, que se sincroniza perfectamente con nuestros repositorios de Github.

app-runner-module

En el directorio podéis ver la carpeta examples (dependiendo de vuestras necesidades).

No obstante, hemos generado un repositorio donde podréis encontrar todo “pre-configurado” y un Readme donde explica como desplegar: 🫣

app-runner-infra

Configuración de las Credenciales en GitHub:
- Configura las GitHub Secrets con las credenciales de AWS necesarias para la pipeline. En este caso deberás de configurarlas en tu repositorio.
Configuración de AWS App Runner:
- Ajusta el fichero provider.tf para indicar la region donde quieres desplegar tu infrastructura.(recomiendo dejar eu-west-1 puesto que el script consulta esa region, si no, deberás de modificarlo en script.sh)
- Modifica backend.tf para apuntar a tu bucket s3 para almacenar el estado de terraform.
- Ajusta las configuraciones necesarias en el fichero variables.tf según tus necesidades, en este caso indicar el repositorio de la app.
Despliegue Automático con GitHub Actions:
- Cada vez que realices un push a la rama main, la pipeline de GitHub Actions se activará automáticamente, desencadenando el despliegue de la infrastructura necesaria para poder deployar nuestra app en AppRunner.
Testear AppRunner en repositorio de código de la app:
- Cuando tengas desplegada la infra y todo funcional ya podrás ir al repositorio de código de tu app para lanzar nuevos deploys automáticos al modificar la app tal y como se explica en este mismo post.

frontend-app-runner

Una vez en el paso 4 lo que deberemos hacer es modificar nuestro texto de la app en nuestro repositorio de la app, en nuestro caso modificamos para que nos muestre la nueva versión en el texto, en este caso v2.0.

Pusheamos a nuestro repositorio.

Git add .
Git commit -m “update version app”
Git push

Accedemos al default domain:

🪄Ahora, con un cambio en la aplicación, hemos dado vida a una nueva versión, pero esta vez de forma automática con terraform + Github Actions. 🪄

En el mundo de apprunner las imágenes no se almacenan en un repositorio ECR. En lugar de eso, AppRunner controla sus propia magia 🪄 para gestionar las imágenes y permitirnos hacer rollback cuando sea necesario. Si necesitamos volver a una versión anterior, podemos recurrir a métodos como revertir el código de nuestro repositorio usando herramientas como ‘git reverse’. 🧙‍♂️¡Que la magia de GIT nos guíe!🧙‍♂️

Una importante aclaración: los AppRunner que hemos desplegado están configurados como endpoints públicos, facilitando así la realización de nuestra PoC. Sin embargo,si necesitamos elevar la seguridad y configurarlos como privados, podemos lograrlo ajustando los valores correspondientes en el módulo de Terraform.

Para poder complementar esta configuración, también podemos utilizar otro módulo de la comunidad para generar un VPC endpoint necesario. Con esa combinación de ajustes podemos crear un entorno más seguro y controlado, adecuado para aplicaciones que requieren una capa adicional de privacidad.

Y con esto acabamos nuestra travesía por AppRunner, desde luego un servicio como mínimo interesante, ¿Te ha parecido interesante? Esperamos vuestras reacciones y comentarios! :)

[Tutorial] IAM Identity Center - Deja de saltar entre roles y empieza a bailar con SSO

Alex Rodríguez — Mon, 18 Dec 2023 00:17:24 +0000

Buenas a tod@s! en primer lugar creemos que tenemos que presentarnos, somos @rager y @nanu, Ingenieros Cloud y gemelos ¿No querías caldo? 🥛¡Toma dos tazas! 🥛
Hemos pasado unos años peleando con los accesos a cuentas y como primer post creemos que tratar el topic de AWS SSO/Iam Idenfity Center podría ser interesante, tenemos que remarcar que iremos posteando una vez yo y otro él (puesto que lo creamos juntos) así que en todos hablaremos en plural 😜

Drama de los Roles en AWS:

Todos hemos pasado por allí... Intentando recordar roles específicos para cada cuenta, como tratando de seguir el ritmo en una coreografía pero sin ensayar... ¡Ahí va el rol de prod! Pues va a ser que no... ahora toca el de dev... o espera. ¿Tenemos problemas con el rol? ¿Puedes probar si puedes acceder? Ah no... será mi MFA… ¿Cómo accedíamos aquí? Dada la experiencia en estos casos, aprovechas y buscas algún tipo de solución que permita ir saltando de rol en rol, como puede ser AWS Extend Switch Roles (Web browser) (https://github.com/tilfinltd/aws-extend-switch-roles), que te permite añadir una serie de configuraciones en el plugin y una vez accedes a tu maravillosa cuenta de salto, ¡pum! 💥 ya puedes ir saltando a otras. Aunque... ¿qué sucede si alguien lo actualiza mal? (En caso de que esté compartido, claro...), ¿lo pierdes o se desconfigura? Volvemos al inicio... demasiados pasos para un único objetivo: "ACCEDER".🔑

Introducción al SSO (Iam Identity Center)

Bien, damos paso a nuestro coreógrafo oficial, Iam Identity Center, quién nos proporcionará facilidades para que podamos realizar nuestro baile de una manera mucho más sencilla. 🕺

¿Como lo configuramos?

Como todo en este sector, podemos hacerlo de muchas formas, es recomendable tener creada una organización (la cual debe estar definida y estandarizada... ehem... ehem...)🤷‍♂️ todo y que si no la tienes o estás en una cuenta de PoC como nosotros, quizá no es
necesario para testear, con solo acceder al Enable AWS SSO podremos crearla. ¡Easy! 👌

Seleccionamos “Finish enable” en IAM Identity Center y esperamos que se configure.
Una vez configurado podemos acceder a Identity Center y debajo del panel Settings Summary encontraremos nuestro AWS access portal URL:

https://[yourdirectory].awsapps.com/start

⚙ Empezamos a testear ⚙

Una vez tenemos habilitado IAM Identity Center empezamos a testear:
Generamos una cuenta desde AWS Organizations > AWS accounts

En nuestro caso, crearemos una dev-poc (por ejemplo...) y debemos añadir el email adress.
🚨 truquito 🚨 podemos usar alias para tener una gestión desde un mismo e-mail (email+dev@domain.com)

En este caso y puesto que se trata de una POC dejaremos el IAM role Name y los TAGS por defecto.
Una vez generada vamos a IAM Identity Center > Permission sets y generamos un nuevo “Permission set” que será el encargado de tener las políticas asociadas

Como podemos ver ya tenemos una serie de permissions sets definidos por AWS que nos van a facilitar realizar estas acciones, en caso de tener que montar una solución más customizada podemos optar por nuestros bailarines profesionales “Custom permissions set” 📕

Para la POC seleccionaremos ViewOnly Access

Una vez disponemos de nuestros permisos generados volvemos a “IAM Identity Center” para otorgar estos mismo, en este caso, siempre recomendamos generar grupos donde después colgarán nuestros usuarios.
Generamos los usuarios proporcionando la información necesaria.

Generamos el grupo donde estarán estos usuarios y los añadimos al grupo recien creado, en nuestro caso:

Grupo: ViewOnlyAccess
User: view-access

Una vez disponemos de los usuarios, grupos y cuenta, los relacionamos entre ellos.
Accedemos a IAM Identity Center > Multi-account permissions > AWS accounts marcamos el check de la cuenta y clicamos en Assign users or groups

Seleccionamos el grupo “ViewOnlyAccess”

Asignamos el permission Set creado, en nuestro caso el ViewOnlyAccess

🍾Y tenemos nuestro SSO🍾

Intentaremos acceder con nuestro usuario por consola mediante el link del Identity Iam Center

https://[yourdirectory].awsapps.com/start

🕺Accedemos mediante el usuario generado en el tutorial y ya podemos salir a la pista de baile!🕺

🤷Pero…y si necesitamos la AWSCLI?🤷

Podemos hacer lo siguiente!

aws configure sso
Este comando te solicitará configurar la siguiente información:
SSO sesion name: Nombre de la sesión SSO start URL: La URL de inicio de sesión de AWS SSO. SSO region: La región de AWS SSO. SSO client ID: El ID de cliente de AWS SSO. SSO output format: El formato de salida para el comando. Puede ser "json", "text", o "table". SSO profile name: El nombre del perfil que deseas configurar.
¿Como nos autenticamos?
Podemos usar el siguiente comando:
aws sso login --profile
Y 🧙‍♂Magia!🧙‍♂ se abrirá una nueva ventana solicitando que inicies sesión con tus credenciales de SSO.
Aprovechamos también la ocasión para compartir una tool que siempre nos ayudó con el tema de login en AWSCLI, la cual se puede integrar con SSO:
aws-vault
🚀Esperamos vuestras reacciones y comentarios.🚀