Bueno, seamos honestos, no son 57, son solo 56 jajaja. Pero alguno se preguntará, ¿qué es Backstage? Voy a ser breve, “un portal para intentar de mejorar la experiencia de los desarrolladores… y más!”.

No suena ni complejo, hasta que empiezas a profundizar… Pero bueno, aquí no profundizaremos en exceso.

Vamos a comenzar con los requerimientos que necesitamos tener instalados en nuestro euqipo:

  • curl
  • Node.js (a la hora de escribir este artículo, yo estoy usando la v20.12.2)
  • yarn
  • docker

Una vez tengamos todo instalado, simplemente ejecutamos el comando para crear la aplicación y le indicamos un nombre.

npx @backstage/create-app@latest
? Enter a name for the app [required] mi-primer-backstage-portal
...
...
All set! Now you might want to:
  Run the app: cd mi-primer-backstage-portal && yarn dev
  Set up the software catalog: https://backstage.io/docs/features/software-catalog/configuration
  Add authentication: https://backstage.io/docs/auth/

Tras unos pocos minutos, tu IDP estará listo. Ejecutamos el comando que nos indica, “Run the app”, y se nos debería abrir automáticamente el navegador con la URL donde está Backstage. Si por algún casual no llega a abrirse el navegador con la URL de Backstage, busca en el log del comando que has ejecutado (yarn dev) la URL. Habitualmente es “localhost:3000”:

[0] <i> [webpack-dev-server] Project is running at:
[0] <i> [webpack-dev-server] Loopback: http://localhost:3000/, http://[::1]:3000/

Venga, te lo pongo fácil… haz clic aquí: localhost:3000

Backstage-Home

Y ya estaría, tenemos backstage corriendo en nuestra máquina de una forma muy, pero que muy, sencilla!! A que no han sido 56 pasos? Bueno, espera un poco porque no nos vamos a quedar aquí 😜.

Cambiar base de datos a PostgreSQL

Por defecto, Backstage utiliza una base de datos en memoria (SQLlite). Esto que quiere decir… que si hacemos cambios y reiniciamos Backstage, se nos va todo al garete. Hagamos una prueba sencilla.

Si no has sido Billy el Rápido, deberías tener aún corriendo Backstage. Si lo fuiste, vuelve a ejcutar “yarn dev” en el directorio donde tienes Backstage (no seas tan ansia!, que ahora se empieza a complicar un poco jaja).

Vamos a crear un nuevo componente, para ello pulsamos en “Create” en las opciones de la parte izquierda y posteriomente, en la nueva ventana, hacemos clic en “Register Existing Component”:

Backstage-Crear-Componente

Vamos a utilizar un ejemplo de Backstage, petstore-component, un ejemplo de API para ver las características de la especificación de OpenAPI. Copia la siguiente URL:

https://github.com/backstage/backstage/blob/master/packages/catalog-model/examples/components/petstore-component.yaml

NOTA: No os suena de algo la sintaxis del Yaml? La culpa del pete NO es siempre de Kubernetes 🤭.

Pegamos en el formulario la URL y hacemos clic en “Analyze”:

Backstage-Analizar-Componente

Te tiene que indicar que hay dos entidades, el componente petstore y una localización. Para finalizar hacemos click en “Import”.

A continuación nos iremos al Home de Backstage. Si seleccionamos en el formulario el tipo “Component”, debe aparecer nuestro nuevo componente.

Backstage-Lista-Componentes

Si quieres, puedes investigar un poco el objeto. Haz clic en el nombre y navega por los menús que aparecen en la nueva pantalla. Cuando ya estés aburrido de verlo, dirígete a la consola donde ejecutaste el comando “yarn dev” y pulsa CTRL+C. Lo mismo tarda un poco en terminar… si es así… ahorra un poco para comprar un nuevo PC (vivan los sobremesas!) o portátil, porque no debería!!

Ahora viene algo curioso. Vuelve al navegador y haz clic en refrescar. A que no se ve nada? Es normal cojones… si hemos apagado el servicio… Anda, vamos a arrancarlo de nuevo. Escribe “yarn dev” de nuevo en el terminal y ahora si, refresca el navegador.

UPS!! Ya no está petstore… Todo lo anterior que hemos hecho es para demostrar que, por defecto, Backstage viene con una base de datos en memoria y que cuando peres el servicio, todo lo que hubieras hecho lo pierdes.

Vamos a evitar esto utilizando PostgreSQL.

Instalación de PostgreSQL Server

Requerimientos para este bloque:

  • Docker
  • PosgreSQL Server

Quizás la forma más sencilla de tener un PostgreSQL corriendo sin ensuciar mucho tu equipo es con Docker/Podman. Un solo comando (asumiendo que ya tienes instalado Docker) y listo:

docker run --name posgresql -p 5432:5432 -e POSTGRES_PASSWORD=mipasswordsecreta -d postgres

Breve explicación. Arrancamos un contenedor (postgres), lo hemos llamado postgresql (la originalidad no ha llamado a mi puerta hoy jaja), exportamos el servicio por el puerto 5432 (es el que usa por defecto de PostgreSQL) y le pasamos la contraseña por una variable de entorno. Rápido y sencillo.

Ahora tienes dos opciones. Confías que el servicio está arrancado y continuas como si nada… o lo pruebas usando también Docker:

docker run -it --rm jbergknoff/postgresql-client postgresql://postgres:mipasswordsecreta@192.168.1.230:5432/postgres

Esto… lo mismo tengo que explicar este comando… Se ha creado un contenedor de una imagen que me encontré por docker-hub que tenía el cliente de PostgreSQL (jbergknoff/postgresql-client), de forma interactiva (it) para que nos salga la linea de comandos de PostgreSQL. Este contenedor, al finalizar la conexión, simplemente escribe “exit”, será borrado (rm). Como parámetro le hemos pasado la conexión con las credenciales de PostgreSQL. Esto último es peligroso, porque si alguien mira el history, ya sabes..

Hay un usuario por defecto que se llama postgres y que tiene como contraseña la que le pasamos al arrancar el servicio por variable de entorno. Como host he puesto la IP de mi red local, aquí tendréis que buscar la vuestra. El puerto, es el que expusimos en el comando anterior con la opción -p. Por último, le indicamos que la base de datos es “postgres”, que es la que viene por defecto al levantar el servicio.

Si todo ha ido bien, deberíamos ver la linea de comandos, en la que escribiremos “\l” para listar las bases de datos:

postgres=# \l
 postgres  | postgres | UTF8     | en_US.utf8 | en_US.utf8 | 
 template0 | postgres | UTF8     | en_US.utf8 | en_US.utf8 | =c/postgres          +
           |          |          |            |            | postgres=CTc/postgres
 template1 | postgres | UTF8     | en_US.utf8 | en_US.utf8 | =c/postgres          +
           |          |          |            |            | postgres=CTc/postgres

Ya tenemos corriendo la base de datos que vamos a usar en Backstage.

Configuración de Backstage para usar PostgreSQL

Lo primero que necesitamos es instalar el paquete de backend a nuestro proyecto. Para ello ejecutamos el siguiente comando en el directorio donde tenemos backstage, vamos donde has estado ejecutando “yarn dev”:

yarn add --cwd packages/backend pg

Es yarn, dale un rato… (a mí solo me tardó 6.43 segudos!).

A continuación, en nuestro app-config.yaml quitamos la configuración de SQLite y ponemos la de PostgreSQL:

backend:
  database:
    client: pg
    connection:
      host: ${POSTGRES_HOST}
      port: ${POSTGRES_PORT}
      user: ${POSTGRES_USER}
      password: ${POSTGRES_PASSWORD}

Como se puede observar, utilizamos variables de entorno del sistema para la conexión y las credenciales de PostgreSQL. Vamos a definirlas:

export POSTGRES_HOST=192.168.1.230
export POSTGRES_PORT=5432
export POSTGRES_USER=postgres
export POSTGRES_PASSWORD=mipasswordsecreta

Ojito con las variables de entorno. Las estamos definiendo simplemente con un export. Aquí hay dos opciones, o lo metes en tu archivo de configuración de bash, zsh, o el que uses… o lo defines en el mismo terminal que en el que vas a arrancar el servidor de Backstage, que es lo que hice yo. En este último caso, si reinicias el terminar, las perides 😃. Yo lo puse en el terminal porque habrá una segunda edición del post, desplegando Backstage en Kubernetes usando secretos.

Una vez realizados estos cambios, vamos a probar de nuevo el paso de agregar un componente. Arrancamos de nuevo el servidor, copiamos la url, hacemos click en create y en “Register existing component”:

yarn dev

https://github.com/backstage/backstage/blob/master/packages/catalog-model/examples/components/petstore-component.yaml

Una vez comprobemos que aparece de nuevo el componente petstore, volvemos a parar (ctrl+c) y a arrancar el servicio (yarn dev). Ahora tiene mejor pinta, no hemos perdido el trabajo que hemos hecho! Hemos obtenido un gallifante (para los viejunos del lugar jajaja).

Hasta ahora tenemos Backstage corriendo en nuestra máquina, que se conecta a un PostgreSQL que está corriendo en un contenedor en Docker. Os apetece que lo despleguemos en un Minikube o similar?

gl & hf!