Forem: victorargento

¡Como utilizar javascript en Github Actions y hacer un cocktail!

victorargento — Thu, 15 Sep 2022 18:51:15 +0000

Hace tiempo que venía pensado en como podría ejecutar un bloque de código de Javascript en un step de Github Actions, ya que muchas veces se me hace incómodo tratar datos con comandos de Bash. Cuando me veo en estos casos, siempre digo: ¡Qué fácil sería hacer esto con Javascript! Una tarde me puse a ver si esto era capaz, tras varias pruebas me di cuenta de que sí que era posible.

Gracias a que los Runners de Github nativamente contienen Node.js podemos ejecutar los scripts sin problema, e incluso si utilizamos la versión v18 de Node.js podremos hacer uso de node-fetch para hacer peticiones dentro de nuestros scripts.

Para llamar a las variables que tenemos dentro del script desde otro step, deberemos hacer console.logs de los valores de la siguiente forma:

console.log(::set-output name=NOMBRE_VARIABLE_GITHUB_ACTION::${nombreVariableJavascript})

Después añadiremos al mismo step un campo llamado id con el valor que identifique al script. El valor lo podremos llamar tal que así.

echo ${{ steps.id_step.outputs.NOMBRE_VARIABLE_GITHUB_ACTION }}

Para pasar inputs al script de Javascript, deberá ser a base de variables de entorno dentro del step, ya que pasárselas como argumentos no funciona correctamente.

Aquí se puede ver un breve ejemplo de como se haría.

name: Greet myself
on:
  push:
jobs:
  greet:
    runs-on: ubuntu-latest
    steps:
      - name: Get name
        run: |
          console.log(`::set-output name=name::${process.env.ENV_NAME}`)
        shell: node {0}
        id: greet
        env:
          ENV_NAME: victor

      - name: Hello Victor
        run: echo hello ${{ steps.greet.outputs.name }}

En mi repositorio de Github he subido una action que nos devuelve la receta para hacer un cocktail y hacemos uso de un script de Javascript.

Despliega tu aplicación NodeJS o Typescript con PM2

victorargento — Thu, 02 Jun 2022 17:39:27 +0000

¿Qué es PM2?

PM2 es un gestor de procesos que te ayuda a gestionar y mantener tu aplicación en línea y con Github Actions podremos desplegar nuestra aplicación totalmente gratis y manera sencilla.

Uniendo estas dos herramientas crearemos una pipeline con la cual desplegaremos nuestra aplicación. Para ello, tendremos que configurar nuestro repositorio con los siguientes pasos:

Creamos la carpeta github/workflows
Dentro generaremos el archivo action.yml (El nombre no tiene importancia). A continuación, dejaré una muestra de una action en la que comprobamos primero nuestro código con la ejecución de unos test unitarios, y si hemos tenido éxito desplegaremos nuestro código en el servidor.
Lo más seguro es que tengamos que generar unos secrets en Github para no comprometer información vulnerable como pueden ser usuario o contraseñas.

name: Test & Deploy
  push:
    branches:
      - main
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '16'
      - run: npm install
      - run: npm run test
  deploy:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Deploy app
        uses: victorargento/pm2-deployment@main
        with:
          remote-path: "/deployment/api"
          host: 12.34.56.78
          username: ${{ secrets.prod-user }}
          port: 2080
          password: ${{ secrets.prod-password }}
          pm2-id: "api"
          build : "true"

PM2 Deployment

La action que utilizamos para desplegar es un fork de Node VPS Deployment, a la cual he añadido funcionalidades para que se pueda hacer una build de Typescript y utilice reload en vez de restart.

Emplear reload en vez de restart en una aplicación que es un servidor web, es mucho mejor, ya que restart es una forma más agresiva de reiniciar nuestra aplicación. Aquí puedes consultar más información acerca de ello.

Puedes darle una estrella a mi proyecto aquí ✌.

Como crear imágenes Distroless para Node.js y Go

victorargento — Tue, 11 Jan 2022 21:56:55 +0000

¿Qué es una imagen Distroless?

Las imágenes distroless están basadas en imágenes Debian, pero son muy diferentes a las de Ubuntu. En primer lugar, Google gestiona estos contenedores, y nos da la confianza de que van a estar preparadas para no tener ningún problema.

La segunda diferencia es que hay contenedores específicos para lenguajes concretos. ¿Por qué tener contenedores específicos para imágenes específicas? ¿Por qué no instalarlos todos en un solo contenedor? Además del problema del tamaño, Google ha eliminado el 90% del contenedor y ha mantenido únicamente lo que se requiere para ejecutar el lenguaje específico. Esto elimina en gran medida la cantidad de vulnerabilidades que se pueden encontrar en el contenedor. Por ejemplo, digamos que alguien es capaz y quiere ejecutar un comando en el contenedor dentro de tu cluster. ¿Sabes que pasaría? Nada, ya que estos contenedores no contienen ninguna shell. Pongamos que se ha encontrado una vulnerabilidad en un paquete de Debian. Lo más probable es que el paquete no exista en la imagen y no tengamos dicha vulnerabilidad.

¿Qué lenguajes se pueden utilizar?

A día hoy solo se pueden utilizar estos lenguajes y versiones:

Base
Static
Dotnet
CC
Java
Node.js
Python 2.7
Python 3

También puedes consultarlas en el repositorio de imágenes de Google en este enlace.

Diferencias entre la imagen static y base:

La imagen static contiene un sistema Linux basado en glibc que contiene certificados CA, tzdata, un directorio en /etc/passwd para un usuario root y un directorio temporal en /tmp.

La imagen base contiene los paquetes glibc, libssl, openssl y todo lo nombrado anteriormente en la imagen static. La mayoría de aplicaciones deberían usar base.

Ventajas de Distroless

En la imagen no hay nada más que tu aplicación, con lo cual si alguien tiene acceso a tu cluster no podrá ejecutar ningún tipo de programa en el contenedor.
Las imágenes tienden a ser más livianas.
A menos paquetes, menos posibilidades de tener vulnerabilidades.

Desventajas de Distroless

No es recomendable para desarrollar, ya que no puedes entrar al contenedor para debuggear el código.
Algunas veces tu aplicación necesitará alguna dependencia del sistema, esta al no tener shell no podremos lanzar ningún comando para instalar dependencias.
Solo puedes emplear un lenguaje en cada imagen.

Demo

A continuación explicaré como construir la imagen de un servidor web tanto en Node.js como en Go. También optimizaremos las imágenes haciendo uso de multi-stage.

Para ello clonaremos mi repositorio y nos situaremos en el directorio distroless:

git clone https://github.com/victorargento/victorargento.git && cd victorargento/distroless

Node.js

La imagen de Node.js tiene 3 fases: construcción de la aplicación para poder ser compilada, instalación solamente de las dependencias de producción y por último transferir la aplicación a la imagen distroless.

# Construimos la aplicación con las dependencias de desarrollo.
FROM node:16-alpine3.14 AS pre-build-env
WORKDIR /app
COPY package*.json ./

RUN npm install --only=development

COPY . .
RUN npm run build

# Instalamos solamente las dependencias necesarias para la ejecución de la aplicación.
FROM node:16-alpine3.14 AS build-env
WORKDIR /app
COPY package*.json ./

RUN npm install --only=production

# Copiamos la carpeta dist construida en la imagen PRE-BUILD-ENV.
COPY --from=pre-build-env /app/dist ./dist
# Este paso podemos omitirlo, ya que solamente necesitas la carpeta dist para ejecutar la aplicación,
# pero tal vez tu aplicación necesite algunos archivos que tienes en la raíz del proyecto, si ese es el caso, copia solamente archivos necesarios.
COPY . . 

# Volvemos a copiar la aplicación, pero esta vez en la imagen Distroless.
FROM gcr.io/distroless/nodejs:16
USER nonroot:nonroot
WORKDIR /app
COPY --from=build-env --chown=nonroot:nonroot /app /app
CMD ["dist/index.js"]

Para construir la imagen ejecutaremos el siguiente comando:

docker build -t hello-app:node ./hello-app-node

Go

La imagen de Go solamente tiene 2 fases: construcción del binario y transferir la aplicación a la imagen distroless.

# Construimos el binario en la imagen que contiene Go.
FROM golang:1.17 as build-env

WORKDIR /go/src/app
COPY *.go ./

RUN go mod init
RUN go get -d -v ./...
RUN go vet -v
RUN go test -v

RUN CGO_ENABLED=0 go build -o /go/bin/app

# Copiamos el binario desde BUILD-ENV a la imagen Distroless.
# En este caso utilizaremos la imagen static, que contiene las dependencias mínimas,
# si nuestra aplicación depende de paquetes como glibc, libssl o openssl utilizaremos la imagen base
# FROM gcr.io/distroless/base
FROM gcr.io/distroless/static
USER nonroot:nonroot

COPY --from=build-env --chown=nonroot:nonroot /go/bin/app /
CMD ["/app"]

Para construir la imagen ejecutaremos el siguiente comando:

docker build -t hello-app:go ./hello-app-go