Blog de Amazon Web Services (AWS)

Creación de portales para desarrolladores con los planos de Backstage y Amazon EKS

Por Riccardo Freschi, arquitecto sénior de soluciones en AWS.

Las complejidades de los entornos de desarrollo de software contemporáneos han llevado, en los últimos años, a la creación y adopción de Internal Developer Platforms (IDP). El objetivo de los IDP es reducir la carga cognitiva de los desarrolladores de software, que tienen que utilizar una gran cantidad de herramientas y productos para realizar su trabajo. Esta fragmentación provoca cambios de contexto que consumen mucho tiempo y agrava la curva de aprendizaje para los recién llegados. Los IDP abordan estos inconvenientes al proporcionar una interfaz unificada, en la que las diferentes herramientas y productos se agrupan y se ponen a disposición del desarrollador en un solo catálogo.

Backstage es un portal para desarrolladores (DP), creado en Spotify y de código abierto en marzo de 2020. Los DP sirven como interfaz de usuario para explorar las capacidades de los IdP y acceder a ellas. Como DP, Backstage centraliza los diferentes tipos de entidades de la empresa, por ejemplo: las API, los recursos, los usuarios, los equipos, la documentación, etc. También cuenta con una arquitectura ampliable en la que se pueden conectar y consumir componentes adicionales de terceros en el mismo contexto, como por ejemplo el complemento AWS Proton Los Blueprints de Amazon EKS para CDK (denominados Amazon EKS Blueprints, en el resto de la publicación) son un conjunto de módulos de infraestructura como código (IaC) que le ayudan a iniciar clústeres completos de Amazon Elastic Kubernetes Service (Amazon EKS) en todas las cuentas y regiones, de forma rápida y con un código mínimo. Desarrollado inicialmente en AWS, pasó a ser de código abierto en abril de 2022. Los complementos son diseños de Amazon EKS Blueprint, que le ayudan a administrar los complementos de Kubernetes, que se ejecutan en el contexto de un clúster.

En esta publicación, se muestra cómo instalar y configurar el complemento Backstage para Amazon EKS Blueprints con la ayuda de Amazon EKS Blueprints Patterns. El complemento le permitirá instalar de forma efectiva la aplicación Backstage en su clúster de Amazon EKS recién implementado. Podrá acceder a Backstage a través de un Amazon Elastic Load Balancer (Amazon ELB). Esta publicación no aborda una integración más estrecha entre Amazon EKS Blueprints y Backstage, por ejemplo, para mostrar y controlar los entornos, el estado de la canalización, la incorporación de equipos, etc., algo que será objeto de desarrollo futuro.

Descripción general de la solución

El siguiente diagrama muestra la solución completa que explicaré en esta publicación:

Necesitará una imagen de Docker prediseñada de Backstage, configurada como mejor le parezca, por ejemplo, con los complementos que elija. Puedes ver los detalles técnicos sobre cómo realizar este paso y los siguientes en la sección «Implementar Backstage» de esta publicación, que aparece más adelante.

El patrón Backstage permitirá entonces:

Requisitos previos

Necesitarás lo siguiente para completar los pasos de esta publicación:

También necesitará un nombre de dominio, que se encuentre en una de las zonas de alojamiento público de Amazon Route 53, similar al de la imagen de la consola de administración de AWS que se muestra aquí:

Clona patrones de planos de Amazon EKS

Abra su interfaz de línea de comandos (CLI) favorita y clone el repositorio de GitHub de EKS Blueprints Patterns:

$ git clone https://github.com/aws-samples/cdk-eks-blueprints-patterns.git

Implemente Backstage

Siga las instrucciones del archivo Backstage que se encuentra en la carpeta de documentos del repositorio EKS Blueprints Patterns. Este es un resumen de los pasos que debe seguir:

  1. Cree la aplicación Backstage y cree la imagen de Docker
  2. Cree un registro de Amazon Elastic Container (Amazon ECR) y un repositorio
  3. Cargue la imagen de Docker en el repositorio recién creado
  4. Configure la cuenta y la región como parte de su perfil de la CLI de AWS e introduzca los parámetros necesarios en el contexto de la CDK:
Parâmetro Descrição
backstage.namespace.name Espacio de nombres de Kubernetes para implementar Backstage, por ejemplo, «backstage»
backstage.image.registry.name Su registro de imágenes, por ejemplo, Amazon Elastic Container Registry (ECR): «{account} .dkr.ecr. {region} .amazonaws.com»,
backstage.image.repository.name El repositorio del registro anterior, por ejemplo: «backstage»
backstage.image.tag.name La tag de tu imagen de Backstage, por ejemplo: «última»
backstage.parent.domain.name Su nombre de dominio, con el que se creará un subdominio y un certificado relacionado, por ejemplo: «example.com»
backstage.subdomain.label La tag que se utilizará para crear el subdominio que se asignará a Backstage, por ejemplo: «backstage»; el subdominio final será, por ejemplo: «backstage.example.com»
backstage.hosted.zone.id La cadena de 20 caracteres, que representa la zona alojada en Route 53 y contiene su nombre de dominio
backstage.certificate.resource.name El nombre que se va a asignar a su recurso de certificados, por ejemplo: «backstage-certificate»
backstage.database.resource.name El nombre que se va a asignar al recurso de su base de datos, por ejemplo: «backstage-database»
backstage.database.instance.port El puerto que se va a asignar a la nueva base de datos de Backstage, por ejemplo: 5432
backstage.database.secret.resource.name El nombre que se va a asignar al recurso secreto (se utiliza como referencia en el CDK), por ejemplo: «backstage-database-credentials»
backstage.database.username El nombre de usuario de la base de datos, por ejemplo: «postgres»
backstage.database.secret.target.name El nombre que se asignará al secreto en el manifiesto de Kubernetes, por ejemplo: «backstage-database-secret»
  1. Implemente tal y como se explica en la documentación de Amazon EKS Blueprints Patterns.
$ make deps 
$ npm i
$ make build
$ make pattern backstage deploy
Bash

Por último, en un navegador web, navegue hasta {"parent.domain.name"}. {"subdomain.label"}. Aparecerá una pantalla similar a la siguiente, en función de la configuración de la aplicación Backstage:

Análisis de código

Es importante tener en cuenta que el complemento Backstage propiamente dicho se aloja en el repositorio Amazon EKS Blueprints, mientras que el patrón Backstage, que muestra cómo configurar el complemento y desplegar los recursos necesarios, se aloja en el repositorio Amazon EKS Blueprints Patterns.

El complemento se basa en el Backstage Helm Chart, alojado públicamente en GitHub, donde puede encontrar una explicación detallada de los valores del gráfico.

A través de los valores, necesitamos configurar el Helm Chart de la siguiente manera:

  • Establezca los parámetros de ingreso
  • Proporcione las coordenadas de la imagen de Docker de la aplicación Backstage
  • Pase a la aplicación Backstage:
    • El subdominio que pretendemos asignar
    • El punto final de la base de datos y las variables de entorno, que luego se establecerán en los valores de las credenciales de la base de datos
    • El nombre secreto, que contiene los valores reales de las credenciales de la base de datos

La configuración más destacada de Ingress es el nombre de recurso de Amazon (ARN) del certificado.

Utilizamos PostgreSQL, a diferencia de la base de datos SQLite integrada por defecto en la memoria, para lograr una mejor escalabilidad, simultaneidad, centralización y control (consulte la guía de Backstage para obtener más información). Sus credenciales se introducen en los módulos de aplicaciones de Backstage mediante variables de entorno extraídas de The Secret. El gráfico obtiene la información sobre el nombre secreto del valor Backstage.extraEnvVarsSecrets y la coloca en la sección envFrom del manifiesto de despliegue de Kubernetes:

kind: Deployment 
… 
containers:envFrom: 
       {{- range .Values.backstage.extraEnvVarsSecrets }}
YAML

Portanto, os parâmetros esperados pelo Add-on são:

subdomain: string,
certificateResourceName: string,
imageRegistry: string,
imageRepository: string,
imageTag?: string,
databaseResourceName: string,
databaseSecretTargetName: string
YAML

El patrón proporciona las dependencias del complemento.

Un proveedor de recursos (DatabaseInstanceCredentialsProvider) crea y almacena las credenciales de la base de datos en AWS Secrets Manager (ASM).

Un segundo proveedor de recursos (DatabaseInstanceProvider) crea una instancia de base de datos de Amazon RDS para PostgreSQL dentro de la VPC del clúster, toma el nombre secreto del ASM del contexto y lo pasa a la base de datos al crearlo.

Un complemento (BackstageSecretAddon),, que aprovecha el complemento External Secrets, crea un objeto ClusterSecretStore, que apunta a ASM, y un ExternalSecret, que extrae las credenciales de ASM y las inyecta en un nuevo Kubernetes Secret, con las claves POSTGRES_USER y POSTGRES_PASSWORD:

data: [
    {
        secretKey: "POSTGRES_PASSWORD",
        remoteRef: {
            key: databaseInstanceCredentialsSecretName,
            property:  "password"
        }
    },
    {
        secretKey: "POSTGRES_USER",
        remoteRef: {
            key: databaseInstanceCredentialsSecretName,
            property:  "username"
        }
    },
],
YAML

Como explicamos anteriormente, las credenciales contenidas en el secreto se pasan luego a los pods como variables de entorno $POSTGRES_USER y $POSTGRES_PASSWORD.

Un tercer proveedor de recursos (CreateCertificateProvider) crea el subdominio en la zona alojada de Amazon Route 53 y el certificado correspondiente en AWS Certificate Manager (ACM):

blueprints.EksBlueprint.builder()

…

.resourceProvider(blueprints.GlobalResources.HostedZone, new blueprints.ImportHostedZoneProvider(props.hostedZoneId, props.parentDomain))

.resourceProvider(props.certificateResourceName, new blueprints.CreateCertificateProvider("elb-certificate", subdomain, blueprints.GlobalResources.HostedZone))
YAML

O certificado é então obtido pelo add-on do Backstage a partir do contexto, e seu ARN extraído…

const annotations = {"alb.ingress.kubernetes.io/certificate-arn": clusterInfo.getResource<ICertificate>(helmOptions.certificateResourceName)?.certificateArn
};
YAML

… y asignado al Ingress:

setPath(values, "ingress.annotations", annotations);

En la sección Route 53 de la consola de administración de AWS, se mostrarán los nuevos registros de subdominios, de forma similar a esta captura de pantalla:

El certificado aparecerá en la sección AWS Certificate Manager:

¿Qué puedo hacer ahora?

Backstage proporciona un panel único para ver los recursos de su organización, independientemente de su ubicación, así como una forma sencilla de incorporar y empezar a utilizar las herramientas de desarrollo. También le permite crear nuevos recursos, como aplicaciones de backend y frontend, con mayor facilidad, desde su portal.

Ahora que ha configurado su plataforma de desarrollador, puede aprovechar esas ventajas y empezar por crear un catálogo de software. Un catálogo de software le permite realizar un seguimiento de la propiedad y los metadatos de todo el software de su entorno (servicios, sitios web, bibliotecas, canalizaciones, etc.) en un lugar centralizado. El catálogo se crea a partir de archivos YAML de metadatos almacenados en el control de código fuente, que se registran en Backstage de diversas formas y se presentan al desarrollador de forma exhaustiva.

Otra característica que quizás te interese explorar son las plantillas de software, que permiten a los equipos de ingeniería crear componentes y crear rápidamente nuevos proyectos alineados con las mejores prácticas del equipo. Esto les ayuda a evitar tener que reinventar la rueda, tienen que tomar menos decisiones y les permite centrarse más en las actividades principales. Las plantillas de software son fundamentales para el concepto de Golden Paths, que son formas fundamentadas y fundamentadas de crear algo (por ejemplo, un servicio de backend, una aplicación web o una canalización de CI/CD). En lugar de legislar convenciones y estándares, con Golden Paths, puedes facilitar que los equipos comiencen nuevos proyectos con el pie derecho.

Otro ejemplo de lo que puede hacer es crear documentación con TechDocs. Esto le permite escribir archivos Markdown que se almacenan en la misma ubicación que el código con el que están relacionados. Luego, esos archivos se muestran de forma limpia y clara en Backstage.

Consulte el sitio web de Backstage para obtener documentación detallada y ejemplos de características y casos de uso.

¿Limpiando

Para evitar incurrir en cargos futuros, ejecuta el comando:

make pattern backstage destroy

Conclusión

En esta publicación, he mostrado cómo puede utilizar el complemento Backstage de Amazon EKS Blueprints y el patrón Backstage de Amazon EKS Blueprints Patterns para implementar una aplicación Backstage pre-diseñada y pre-configurada. He explicado los parámetros de configuración del patrón y cómo el patrón conecta a los proveedores de recursos y otros complementos para lograr una solución completa que ejecute Backstage con sus dependencias.

Este artículo fue originalmente publicado en inglés en el AWS Blog (enlace aquí).

Autores

      Ricardo Freschi es arquitecto sénior de soluciones en AWS, con foco en la modernización de aplicaciones. Trabaja en estrecha colaboración con socios y clientes para ayudarlos a transformar sus entornos de TI en su transición a la nube de AWS, mediante la refactorización de las aplicaciones existentes y la creación de otras nuevas de forma nativa en la nube.

Tradutores/Revisores

      Bruno Lopes es Sr. Specialist Solutions Architect en AWS LATAM. Con más de 17 años de experiencia en TI, es especialista en la modernización de aplicaciones heredadas. Su experiencia abarca ambientes híbridos y capacitación técnica como Technical Trainer y Evangelista. Como Arquitecto de Soluciones, simplifica la adopción de tecnologías avanzadas, ayudando a clientes a superar desafíos diarios con soluciones innovadoras.
JuanMa Silva es un arquitecto de soluciones en AWS con mas de 15 años de experiencia en la industria de TI ayudando a clientes a migrar a la nube y actualmente a modernizar sus cargas en AWS, mediante la adopción de tecnologías modernas como contenedores y serverless