👋¡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! 💯
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
├── terraform/
│ └── s3.yaml
└── catalog-info.yaml
Estructura repositorio que contiene el terraform y la pipeline
├── .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!
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!
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:
bucket = var.s3name
acl = var.acl
}
variable “s3name” {
type = string
}
variable “acl” {
type = string
}
backend.tf: definimos nuestro backend para el estado
backend “s3” {
bucket = “yourbuckets3”
encrypt = true
region = “eu-west-1”
key = “terraform.tfstate”
}
}
provider.tf: provider a utilizar
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! 💥
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!
