DEV Community: Jonathan

Construir imágenes de Docker Multi-arch utilizando Manifest, Buildx y GitHub Actions

Jonathan — Sun, 14 Aug 2022 04:59:00 +0000

Cuando trabajas en entornos de arquitectura uniforme es bastante fácil lidiar con la construcción de imágenes de docker, todos trabajando bajo la misma arquitectura “amd64” por ejemplo.
Pero qué sucede cuando trabajas con una Macbook Air con un chip M1 que es “arm64”, y tiene que generar imágenes para “amd64”, o a la inversa, trabajas con un equipo “amd64” y tienes que levantar contenedores en un cluster de Raspberry PI o servidores ARM, que están ganando cada vez más popularidad entre los proveedores de cloud.

El objetivo de hoy es enseñar desde mi perspectiva y en español a generar imágenes docker multiarquitectura o multi-arch y publicarlas en el Docker Hub.

Lo primero es tener una aplicación en mi caso utilizaré un archivo simple de Python que nos obtenga información acerca del actual sistema. Para lo cual utilizaremos la librería platform

#main.py
import platform
platform_var = platform.uname()
print ("*"*30)
print (f'Machine:\t{platform_var.machine}')
print (f'System:\t\t{platform_var.system}')
print (f'Node:\t\t{platform_var.node}')
print (f'Release:\t{platform_var.release}')
print (f'Version:\t{platform_var.version}')
print (f'Processor:\t{platform_var.processor}')
print ("*"*30)

Lo siguiente es armar nuestro Dockerfile normalmente de la siguiente manera, esta es la versión inicial, más adelante le haremos pequeñas modificaciones para poder visualizar en qué arquitectura estamos construyendo

FROM python:alpine3.10
WORKDIR /app
COPY . .
CMD [ "python", "main.py" ]

Hasta este punto no tenemos nada del otro mundo podemos generar la imagen y hacerla correr.

docker build . -t jevillanueva/multiarch:latest
docker run jevillanueva/multiarch:latest

Donde tenemos una salida similar a esta:

Machine: x86_64
System: Linux
Node: 8ca0b41e5372
Release: 4.19.128-microsoft-standard
Version: #1 SMP Tue Jun 23 12:58:10 UTC 2020
Processor:

Hasta aquí ya sabemos que funciona lo siguiente es modificar el Dockerfile donde añadiremos un par de cosas para poder visualizar lo que pasa.

FROM  --platform=$TARGETPLATFORM python:alpine3.10
ARG TARGETPLATFORM
WORKDIR /app
RUN  echo "construyendo para $TARGETPLATFORM" > /log
COPY . .
CMD [ "python", "main.py" ]

Añadimos la opción platform y el argumento “TARGETPLATFORM”, en este caso

Existen dos caminos para realizar el proceso multi-arch, la primera la más antigua xD, la describiremos a continuación nos servirá para entender cómo funciona.

DOCKER MANIFEST

Todas las imágenes de docker cuentan con un manifest, un manifest contiene información acerca de la imagen, sus layers o capas, el tamaño y su digest que es un id inmutable para cada imagen, para nuestro caso de multi-arch esto es vital ya que en el manifiesto se encuentra detallado para imágenes con funcionalidades idénticas pero para diferentes sistemas operativos y arquitecturas. Puede ver mas de manifest

Vamos a inspeccionar el manifiesto de la imagen base que utilizamos que es “python:alpine3.10”

docker manifest inspect python:alpine3.10

Tendremos una salida similar a esta que nos muestra el tamaño, su digest, las plataformas, el sistema operativo y sus arquitecturas

{
   "schemaVersion": 2,
   "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
   "manifests": [
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 1368,
         "digest": "sha256:655edcda221823fcdb79b61095dd77e6c767bf1543505dcf078f6945497c7fcf",
         "platform": {
            "architecture": "amd64",
            "os": "linux"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 1368,
         "digest": "sha256:16779e4847cac747c0496fc56d0daa7c2090ea6cb2e4c9aa455672d6818d7179",
         "platform": {
            "architecture": "arm",
            "os": "linux",
            "variant": "v6"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 1368,
         "digest": "sha256:3dee5de82f12477d1f0a8ed0836181064863ba84cd8098b9c62c65f8347c656b",
         "platform": {
            "architecture": "arm",
            "os": "linux",
            "variant": "v7"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 1368,
         "digest": "sha256:001faf6c4b5e87a3a4b251e72bb9a9dd1a5ef93083fc3a42d54e8734dc76e1f5",
         "platform": {
            "architecture": "arm64",
            "os": "linux",
            "variant": "v8"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 1368,
         "digest": "sha256:42829bfc005ccdd282d82da1328c9a2511e20f09439c702311d30627c91c70ca",
         "platform": {
            "architecture": "386",
            "os": "linux"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 1368,
         "digest": "sha256:52e6ffac79478822ea62492d73c7aac3eca9a1cf41e8531899744e8e4958c236",
         "platform": {
            "architecture": "ppc64le",
            "os": "linux"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 1368,
         "digest": "sha256:90f421378ca9b94b071a20e7c4b2df746d9b4bc26dcbd85ea79f0db9322d330f",
         "platform": {
            "architecture": "s390x",
            "os": "linux"
         }
      }
   ]
}

Hasta aquí ya comprendemos a grandes rasgos qué papel importante juega manifest, ahora nos utilizaremos para crear las imágenes multi-arch así que manos a la obra, realizaremos para dos arquitecturas amd64 y arm64.

Imagenes usando manifest

Lo primero es construir las imágenes para cada arquitectura

# AMD64
docker build . -t jevillanueva/multiarch:manifest-amd64 --build-arg TARGETPLATFORM=amd64
docker push jevillanueva/multiarch:manifest-amd64

# ARM64
docker build . -t jevillanueva/multiarch:manifest-arm64 --build-arg TARGETPLATFORM=arm64
docker push jevillanueva/multiarch:manifest-arm64

Ya tenemos construidas nuestras dos imágenes para diferentes arquitecturas y publicadas en el Docker Hub puede verse algo así

Ahora creemos el manifiesto que listará estas dos imágenes con diferentes tags en una sola unidad.

docker manifest create jevillanueva/multiarch:manifest-latest --amend jevillanueva/multiarch:manifest-amd64 --amend jevillanueva/multiarch:manifest-arm64

Y Posterior a este realizamos el publicado del nuevo manifiesto

docker manifest push jevillanueva/multiarch:manifest-latest

Como se puede visualizar ahora en nuestro registry se encuentra un nuevo tag que hace referencia a las dos imágenes y sus respectivos sistemas operativos y arquitecturas

Podemos probar las imágenes basadas en manifest desde diferentes instancias para obtener los resultados de la arquitectura mediante python

docker run jevillanueva/multiarch:manifest-latest

He aquí el resultado desde mi máquina personal de amd64 y desde una máquina arm64

Hasta aquí es la forma clásica y detallada para comprender el porqué de las cosas xD ahora algo mucho más rápido actualmente existen una nueva herramienta desarrollada por Docker que podemos utilizar para estos escenarios llamada “Buildx”

DOCKER BUILDX

Docker buildx es una herramienta que nos permite acceder a las características de la herramienta de construcción moby buildkit, nos permite soportar multiples instancias asi que procedemos a crear nuestras imágenes para diferentes plataformas, creamos la instancia para buildx llamada “mybuild” y usamos esa instancia

docker buildx create --name mybuild
docker buildx use mybuild

docker buildx build . --push -t jevillanueva/multiarch:buildx-latest --platform linux/amd64,linux/arm64

Después de un proceso de descarga y compilación utilizando moby/buildkit se publica la imagen en el docker hub y se tiene un resultado similar que usando manifest

Del mismo modo procedemos a probar desde diferentes dispositivos con diferentes arquitecturas.

Como se puede ver existen varias maneras de realizar esto. Y para finalizar como un extra les dejo un modelo de para github actions para generar imágenes multiarch utilizando qemu para virtualizar las arquitecturas.

Github Actions

name: Docker Image CI

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

env:
  IMAGE_NAME: ${{ github.repository }}
  IMAGE_TAG: ${{ github.sha }}

jobs:

  build:

    runs-on: ubuntu-latest

    steps:
    - 
      name: Checkout
      uses: actions/checkout@v2
    -
      name: Set up QEMU
      uses: docker/setup-qemu-action@v2
    -
      name: Set up Docker Buildx
      uses: docker/setup-buildx-action@v2

    - name: Docker Login
      env:
        DOCKER_USER: ${{secrets.DOCKER_USER}}
        DOCKER_PASSWORD: ${{secrets.DOCKER_PASSWORD}}
      run: |
        docker login -u $DOCKER_USER -p $DOCKER_PASSWORD 
    -
      name: Build and push
      uses: docker/build-push-action@v3
      with:
        context: .
        platforms: linux/amd64,linux/arm64
        push: true
        tags: ${{ env.IMAGE_NAME }}:${{env.IMAGE_TAG}},${{ env.IMAGE_NAME }}:latest

Aquí encuentran el repositorio del proyecto

Enlaces utilizados:

https://docs.docker.com/registry/spec/manifest-v2-2/
https://docs.docker.com/engine/reference/commandline/manifest/
https://docs.docker.com/build/buildx/multiplatform-images/
https://github.com/docker/setup-buildx-action#with-qemu

Ahí les dejo mi página personal jevillanueva.dev

Crear una función en Python para desplegar en OpenFaas (2/2)

Jonathan — Sat, 06 Aug 2022 00:35:00 +0000

Lo primero que necesitamos es el cliente de Open Faas “faas-cli” para lo cual podemos escoger desde su página los diferentes binarios CLI Install

En mi caso y para este ejemplo lo realizaré en Windows, para descargar el cliente lo primero es obtener la versión última del cli:

$version = (Invoke-WebRequest "https://api.github.com/repos/openfaas/faas-cli/releases/latest" | ConvertFrom-Json)[0].tag_name

Y ahora descargamos el ejecutable de acuerdo a la última versión:

(New-Object System.Net.WebClient).DownloadFile("https://github.com/openfaas/faas-cli/releases/download/$version/faas-cli.exe", "faas-cli.exe")

Podríamos agregar como variable de entorno en la ruta PATH para poder acceder a él sin necesidad de invocar toda la ruta o sino utilizarlo mediante la ruta absoluta del ejecutable.

En el blog anterior hable sobre la instalación de OpenFaas en el cual al finalizar se obtiene el password del servidor para poder ingresar

https://dev.to/jevillanueva/openfaas-con-k3s-en-un-servidor-arm64-2ib2

Ese password guardaremos en un archivo para poder iniciar sesión llamado “password.txt” esta es una forma de realizar el login, posteriormente conectamos utilizando el archivo “password.txt” apuntando al gateway de openfaas

cat .\password.txt | faas-cli.exe login -s --gateway https://faas.jevillanueva.dev

Nos generará las credenciales para nuestro usuario almacenado en la carpeta de “usuarios/.openfaas”.

Fass cli, nos permite gestionar las imágenes de docker para ser cargadas a openfaas, utilizando build, push, deploy y up.

Existe muchas opciones para deployar cuenta con una variedad de templates

Para esta guía utilizaremos python

faas-cli new echo --lang python3

Genera una estructura de proyecto similar a esta

En el archivo handler.py se encuentra el request que se recibirá cuando esté en línea

def handle(req):
    """handle a request to the function
    Args:
        req (str): request body
    """
    return req

Modificaremos el archivo “echo.yml” con las características de nuestro servidor de openfaas

#echo.yml
version: 1.0
provider:
  name: openfaas
  gateway: https://faas.jevillanueva.dev/ #Dirección del servidor openfaas
functions:
  echo:
    lang: python3
    handler: ./echo
    image: jevillanueva/echo-openfaas:latest #nombre de la imagen de docker

Para estos ejemplos se esta utilizando imágenes públicas para que sea de fácil consumo y deploy utilizando Docker Hub como Container Registry

Realizamos el build

faas-cli build -f ./echo.yml

Subimos al docker hub

faas-cli push -f ./echo.yml

Una vez compilada y publicada la imagen en el docker hub ya podemos levantar la función en nuestro servidor openfaas

Levantamos la función utilizando

faas-cli deploy -f ./echo.yml

Podemos visualizar desde la página de administración la función e invocar.

Podemos probar nuestro endpoint utilizando postman o un curl

curl --request GET 'https://faas.jevillanueva.dev/function/echo' --header 'Content-Type: application/json' --data-raw '{"message": "Hola Mundo"}'

EXTRA

Como estamos trabajando sobre Windows en un equipo con Arquitectura de 64 Bits, y el servidor de OpenFaas está sobre ARM64 necesitaremos compilar las imágenes de docker de manera compatible para ARM utilizaremos para esto Buildx, donde nos permitirá otra forma de generar las imagenes y QEMU para virtualizar un entorno ARM. Para lo cual primero debemos descargar las herramientas de QEMU

docker run --rm --privileged  multiarch/qemu-user-static --reset -p yes

Una vez descargadas las herramientas se puede realizar el publish multiarch en docker hub

faas-cli publish -f ./echo.yml --platforms linux/arm64,linux/amd64

El proyecto implementado se encuentra en:
https://github.com/jevillanueva/echo-openfaas

https://hub.docker.com/r/jevillanueva/echo-openfaas

Recursos Utilizados:
https://docs.openfaas.com/cli/install/
https://docs.openfaas.com/cli/templates/
https://docs.docker.com/build/buildx/
https://www.qemu.org/

Para ver el post anterior de levantamiento de servidor de Open Faas pueden ver el post anterior
"OpenFaaS con K3S en un servidor ARM64 (1/2)"

Ahí les dejo mi página personal jevillanueva.dev

OpenFaaS con K3S en un servidor ARM64 (1/2)

Jonathan — Mon, 11 Jul 2022 23:09:00 +0000

En esta ocasión escribo acerca de mi experiencia levantando un servicio propio de funciones utilizando https://www.openfaas.com/

Antes que nada primero veremos los requisitos para esta tarea.

Primero fue levantado en un servidor Ampere A1 con 2 nucleos y 12 de Memoria y 100 GB de almacenamiento, se encuentra alojado en Oracle Cloud, cuenta con una IP pública.

Después para los certificados de seguridad y asegurado del sitio mediante SSL se necesita un dominio con el cual se pueda hacer pruebas y configurar el DNS. La forma más económica de obtener un dominio para mi fue comprarlo en namecheap, desde el cual voy a crear un subdominio para acceder al servicio de funciones.

Con estos requisitos podemos iniciar, lo primero que hice fue instalar K3S, nos permite instalar una versión “Lightweight Kubernetes”, una versión ligera y rápida para desarrollar y poner en producción un cluster de Kubernetes.

Para instalar el cluster usamos, en cual instalaremos el cluster de pruebas y su acceso a través del usuario actual que tenemos en el servidor, se podría implementar en un cluster con más nodos, en mi caso solo utilizaré uno.

$ curl -sfL https://get.k3s.io | sh -s - --write-kubeconfig-mode 644
$ kubectl config view --raw > ~/.kube/config

Podemos verificar el estado con

$ kubectl get nodes -o wide

Donde obtendremos una salida similar a esta:

La idea es siempre hacerlo simple entender que está sucediendo ya que son un conjunto de cosas que funcionan entre sí, para lo cual la solución pensada es similar a algo así:

Asi que bueno:

“Divide y vencerás”

Antes de iniciar con la instalación de los diferentes componentes utilizaremos dos gestores de paquetes para Kubernetes

Helm donde podemos instalarlo siguiendo la documentación Helm Install

$ curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
$ chmod 700 get_helm.sh
$ ./get_helm.sh

Podemos verificar la instalación utilizando

$ helm version

El segundo gestor de paquetes que utilizaremos es Arkade un gestor de paquetes que nos permite instalar charts con un solo comando de manera rápida
Podemos instalarla y verificar utilizando los siguientes comandos

$ curl -sLS https://get.arkade.dev | sudo sh
$ arkade --help

Ahora que ya están instalados podemos continuar con los despliegues.

Primero el Ingress, encargarnos del Ingress para lo cual primero nos asignaremos un subdominio a nuestra ip pública, algo así “openfaas.example.com” con la cual nos aseguraremos que todo funcione incluso la emisión de certificados SSL antes de instalar open faas, en caso de utilizar Namecheap para el dominio puede seguir el siguiente enlace que explica como crear un subdominio y apuntar a la IP que vayamos a utilizar, cuando se realiza el registro puede llevar un tiempo en reflejarse me ha pasado que a veces tarda unos 10 minutos en detectar el subdominio el DNS hasta un 1 dia entero asi a tener paciencia xD Crear Subdominio en Namecheap

En el ejemplo utilizamos dos subdominios uno de prueba para una aplicación de demostración y otra que nos permita acceder a openfaas.

Como vamos a utilizar Nginx-ingress, necesitamos también asegurar nuestros sitios para lo cual utilizaremos cert-manager. Puede leer más al respecto del cert-manager

Nginx Ingress

Lo primero vamos a instalar utilizando helm nuestro Nginx Ingress usando sus repositorios

$ helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
$ helm repo update
$ helm install nginxingress ingress-nginx/ingress-nginx

Podemos comprobar el estado del servicio usando

$ kubectl get svc

Donde tendremos una salida similar a la siguiente image

Donde en principio se encontrara pendiente hasta que se asocie a la IP pública, en caso de suceder puede realizarlo manualmente editando el servicio usando Kubernetes.

$ kubectl edit svc nginxingress-ingress-nginx-controller

Donde usaremos VIM para editar nuestro servicio añadiendo al nivel del type: LoadBalancer nuestra IP externa

…
  type: LoadBalancer
  externalIPs:
  - XXX.XXX.XXX.XXX
…

Para probar nuestro Ingress y Cert Manager utilizaremos un deploy de demostración llamado KUARD. Para lo cual crearemos los dos archivos del deploy y del ingress

# kuard-ingress.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: kuard
spec:
  selector:
    matchLabels:
      app: kuard
  replicas: 1
  template:
    metadata:
      labels:
        app: kuard
    spec:
      containers:
      - image: gcr.io/kuar-demo/kuard-arm64:1
        imagePullPolicy: Always
        name: kuard
        ports:
        - containerPort: 8080

Levantamos el deployment:

kubectl create -f kuard-deploy.yaml

Luego configuramos nuestro ingress para Kuard:

#kuard-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: kuard
  annotations:
    kubernetes.io/ingress.class: "nginx"
    # cert-manager.io/issuer: "letsencrypt-prod"

spec:
  tls:
  - hosts:
    - kuard.example.com # Dominio de prueba
    secretName: quickstart-example-tls # Nombre de nuestro Certificado
  rules:
  - host: kuard.example.com # Dominio de prueba
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: kuard
            port:
              number: 80

Levantamos el ingress:

kubectl create -f kuard-ingress.yaml

Podemos verificar el estado de nuestro deploy e ingres utilizando

$ kubectl get ingress,deploy -o wide
# probar el acceso a nuestro dominio de prueba usando su IP
$ curl -kivL -H 'Host: kuard.example.com' 'http://10.0.0.210'

Una vez levantado el deploy y el Ingress tenemos que configurar nuestro cert manager que se encargará de gestionar los certificados para nuestro sitio, para lo cual nos ayudará helm

$ helm repo add jetstack https://charts.jetstack.io
$ helm update
$  kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.8.2/cert-manager.crds.yaml 
$ helm install   cert-manager jetstack/cert-manager   --namespace cert-manager   --create-namespace   --version v1.8.2

Una vez instalado procedemos a crear nuestros issuers, que se encargaran de generar los certificados en nuestro caso usaremos letsencrypt creando los dos siguientes issuers:

# lets-staging.yaml
   apiVersion: cert-manager.io/v1
   kind: Issuer
   metadata:
     name: letsencrypt-staging
   spec:
     acme:
       # The ACME server URL
       server: https://acme-staging-v02.api.letsencrypt.org/directory
       # Email address used for ACME registration
       email: me@example.com
       # Name of a secret used to store the ACME account private key
       privateKeySecretRef:
         name: letsencrypt-staging
       # Enable the HTTP-01 challenge provider
       solvers:
       - http01:
           ingress:
             class:  nginx

Y el archivo para generar certificados en prod

# lets-prod.yaml
   apiVersion: cert-manager.io/v1
   kind: Issuer
   metadata:
     name: letsencrypt-prod
   spec:
     acme:
       # The ACME server URL
       server: https://acme-v02.api.letsencrypt.org/directory
       # Email address used for ACME registration
       email: me@example.com
       # Name of a secret used to store the ACME account private key
       privateKeySecretRef:
         name: letsencrypt-prod
       # Enable the HTTP-01 challenge provider
       solvers:
       - http01:
           ingress:
             class: nginx

Creamos ambos issuers.

$ kubectl create -f lets-staging.yaml
$ kubectl create -f lets-prod.yaml
$ kubectl get Issuers
$ kubectl describe issuer letsencrypt-staging

Hasta este punto ya tenemos el cert-manager con nuestros Issuers, ahora toca configurar nuestro Ingress que estamos probando, editamos nuestro kuard-ingress.yaml

#kuard-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: kuard
  annotations:
    kubernetes.io/ingress.class: "nginx"
    cert-manager.io/issuer: "letsencrypt-staging"

spec:
  tls:
  - hosts:
    - kuard.example.com # Dominio de prueba
    secretName: quickstart-example-tls # Nombre de nuestro Certificado
  rules:
  - host: kuard.example.com # Dominio de prueba
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: kuard
            port:
              number: 80

Y volvemos a levantar nuestro Ingress.

$ kubectl apply -f kuard-ingress.yaml

O sino eliminamos el Ingress y levantamos nuevamente.

$ kubectl delete -f kuard-ingress.yaml
$ kubectl create -f kuard-ingress.yaml

En este punto se creará el punto de ingreso y el certificado.

$ kubectl get certificate
NAME                     READY   SECRET                   AGE
quickstart-example-tls   True    quickstart-example-tls   16m

Podemos ver más detalles del mismo

$ kubectl describe certificate quickstart-example-tls
$ kubectl describe secret quickstart-example-tls

Una vez comprobado que existen los certificados podemos hacer la actualización a producción de nuestro Ingress.

#kuard-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: kuard
  annotations:
    kubernetes.io/ingress.class: "nginx"
    cert-manager.io/issuer: "letsencrypt-prod"

spec:
  tls:
  - hosts:
    - kuard.example.com # Dominio de prueba
    secretName: quickstart-example-tls # Nombre de nuestro Certificado
  rules:
  - host: kuard.example.com # Dominio de prueba
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: kuard
            port:
              number: 80

Y volvemos a levantar nuestro Ingress.

$ kubectl apply -f kuard-ingress.yaml

O sino eliminamos el Ingress y levantamos nuevamente.

$ kubectl delete -f kuard-ingress.yaml
$ kubectl create -f kuard-ingress.yaml

También es necesario eliminar el certificado en estado de staging para que se pueda generar el certificado en producción.

$  kubectl delete secret quickstart-example-tls

Una vez eliminado esperamos un poco hasta que se vuelva a generar un certificado esta vez apuntando al issuer de producción.
En este punto accediendo desde el navegador puede comprobar la validez del certificado accediendo a su dominio kuard.example.com.

En este punto terminamos la parte inicial de nuestro esquema, ya tenemos nuestro Ingress y Nuestro Cert Manager Funcionando correctamente ahora toca instalar OpenFaas para el servicio de Funciones.

Kuard muestra un poco de información sensible así que se recomienda eliminarlo cuando no se lo esté utilizando, puede eliminar el secret, el ingress y el deploy y eliminar el subdominio de prueba “kuard.example.com” para continuar con el servicio de OpenFaas

$  kubectl delete -f kuard-ingress.yaml
$  kubectl delete secret quickstart-example-tls
$  kubectl delete -f kuard-deploy.yaml

En caso de querer revisar los logs de nuestro ingress nginx podemos utilizar un comando similar a este:

kubectl logs -f $(kubectl get po -l "app.kubernetes.io/instance=nginxingress,app.kubernetes.io/component=controller" -o jsonpath="{.items[0].metadata.name}")

OpenFaas

Es un servicio de Funciones Self Hosted, que nos permite levantar e implementar funciones basados en eventos sobre Kubernetes, generando un endpoint, tal como Azure Functions o Amazon Lambda https://docs.openfaas.com/.

Puede leer más información sobre el proceso de instalación

Para instalar OpenFaas sobre nuestro Kubernetes utilizaremos arkade:

$ arkade install openfaas

Utilizando helm podemos ver todos nuestros charts instalados incluido openfaas

$ helm list --all-namespaces

Una vez instalado openfaas vamos a crear los issuers para su namespace openfaas en el cual estaran almacenados

# letsencrypt-issuer.yaml
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: letsencrypt-staging
  namespace: openfaas
spec:
  acme:
    email: me@example.com
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      name: staging-issuer-account-key
    solvers:
    - http01:
        ingress:
          class: nginx
---
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: letsencrypt-prod
  namespace: openfaas
spec:
  acme:
    email: me@example.com
    server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      name: prod-issuer-account-key
    solvers:
    - http01:
        ingress:
          class: nginx

Una vez creado nuestro archivo de Issuers levantamos el mismo

$ kubectl create -f letsencrypt-issuer.yaml

Ahora procedemos a configurar nuestro openfaas creando un archivo tls.yaml y actualizando con helm nuestro chart de faas

# tls.yaml
ingress:
  enabled: true
  annotations:
    kubernetes.io/ingress.class: "nginx"
    cert-manager.io/issuer: letsencrypt-staging # utilizaremos staging de pruebas
  tls:
    - hosts:
        - openfaas.example.com
      secretName: openfaas-crt
  hosts:
    - host: openfaas.example.com
      serviceName: gateway
      servicePort: 8080
      path: /

Actualizamos nuestro chart

$ helm upgrade openfaas --namespace openfaas --reuse-values --values tls.yaml openfaas/openfaas

Esperamos un poco a que se apliquen los cambios y genere el certificado en staging y podemos comprobarlo con

$ kubectl describe certificate   -n openfaas   openfaas-crt

Al poder comprobar que se encuentre creado podemos cambiar ahora a prod nuestro staging

# tls.yaml
ingress:
  enabled: true
  annotations:
    kubernetes.io/ingress.class: "nginx"
    cert-manager.io/issuer: letsencrypt-prod # Cambiamos a prod
  tls:
    - hosts:
        - openfaas.example.com
      secretName: openfaas-crt
  hosts:
    - host: openfaas.example.com
      serviceName: gateway
      servicePort: 8080
      path: /

Volvemos a actualizar nuestro chart con helm de openfaas

$ helm upgrade openfaas --namespace openfaas --reuse-values --values tls.yaml openfaas/openfaas

Si el certificado no se regenera con el Issuer de producción puede ser necesario eliminarlo.

$ kubectl -n openfaas delete secret  openfaas-crt

Ahora hay q descargar las credenciales auth del admin del open faas para poder acceder desde el cliente o la web

$ PASSWORD=$(kubectl get secret -n openfaas basic-auth -o jsonpath="{.data.basic-auth-password}" | base64 --decode; echo)
$ echo $PASSWORD

Este password guardalo con mucha seguridad ya que es la clave de acceso a su openfaas.

Una vez que se genera el certificado, ya se encuentra listo para acceder a su openfaas para lo cual puede realizarlo desde el navegador accediendo a su dominio openfaas.example.com

Como se puede observar se encuentra ya con https y está listo para poder empezar a deployar sus funciones, tanto desde la web como desde su cliente.

Para la instalación del cliente de openfaas

Recursos utilizados:

https://docs.oracle.com/iaas/Content/FreeTier/freetier_topic-Always_Free_Resources.htm
https://rancher.com/docs/k3s/latest/en/
https://helm.sh/docs/intro/install/
https://github.com/alexellis/arkade
https://cert-manager.io/docs/tutorials/acme/nginx-ingress/
https://docs.openfaas.com/deployment/kubernetes/
https://docs.openfaas.com/cli/install/

Aqui esta el siguiente POST de una función en Python con OpenFaas
"Crear una función en Python para desplegar en OpenFaas (2/2)"

Ahí les dejo mi página personal jevillanueva.dev

Automatizando lectura de mensajes de Discord con Python y Alexa Skills

Jonathan — Sun, 26 Dec 2021 10:15:16 +0000

Automatización

La automatización consiste en utilizar la tecnología para realizar tareas casi sin necesidad de realizar acciones humanas.

Alexa como asistente inteligente

Un asistente inteligente es un software que realiza tareas y ofrece servicios a un individuo, ayuda en las tareas en sistemas automatizando y realizando acciones con la mínima interacción hombre-máquina. Una persona se comunica usando la voz o texto y el asistente lo procesa, identifica, interpreta, ejecuta y responde utilizando la voz o medios visuales.

Alexa es el servicio de voz ubicado en la nube de Amazon disponible en dispositivos Amazon y dispositivos con Alexa integrada, se encuentran dispositivos con solo altavoces como Echo, Echo Dot, dispositivos con pantalla cómo Echo Show, Fire Stick TV y aplicaciones en Android, Windows, y muchos otros dispositivos más incluido televisores smart.

Skills de alexa y Rutinas

Una Skill son las habilidades que posee Alexa para realizar tareas, similar a una aplicación en un smartphone es una Skill de Alexa, a través de las Skills se permite realizar ciertas tareas, interactuar con otros dispositivos, estas habilidades son realizadas por desarrolladores y compañías para permitir a Alexa integrarse con otros Sistemas y dispositivos.

Son proyectos de software o funciones que se alojan en alguna nube y se ejecutan según la demanda de los usuarios, cada vez que se invoca la habilidad específica.

Las rutinas son un conjunto de reglas y ejecuciones que permiten ejecutar diferentes tareas que se programan a través de la Aplicación de Alexa, enlazando características de los diferentes dispositivos, skills, tiempo de ejecución de tareas, todas ellas permiten crear rutinas, tan simple como encender una alarma sonora a una hora específica, controlar la temperatura de un ambiente utilizando un termómetro y un ventilador, o recordarte comprar un objeto al llegar a un lugar, escuchar las noticias de diferentes proveedores con solo decirle “Quiero escuchar noticias”.

Las rutinas más las Skills permiten sacar gran parte del potencial del asistente inteligente, a tal punto de influir en la vida misma y las acciones del dia a dia de cada persona, facilitando el trabajo, ayudando a recordar o informar, ayudando a mantenerse en salud óptima, divertirse y disfrutar de un momento de ocio.

Serverless

La computación sin servidor o Serverless es un modelo en el cual los proveedores de cloud (AWS, Azure, GCP, etc.) son responsables de ejecutar un fragmento de código mediante la asignación dinámica de recursos. Cobrando solo por la cantidad de recursos utilizados para ejecutar el código. El código se envía al proveedor en la nube para ejecución en forma de una función, serverless puede ser denominado como “Funciones como servicio” o FaaS.

La computación sin servidor no significa que no hay un servidor en el cual se ejecuta sino que los proveedores se encargan del mantenimiento y solo se cobra por la ejecución de las funciones, tradicionalmente se suele pagar el mantenimiento de máquinas virtuales, plataformas como servicio aun cuando no se encuentran en uso por los clientes a través de solicitudes HTTP o Sockets y se encuentran en un estado Idle o de espera, con Serverless cuando no hay llamadas de ejecución, solicitudes HTTP o CRON, no hay recursos destinados a mantener activa la función en estado de espera, el costo se basa en la cantidad de recursos consumidos en cada ejecución por función.

Entre los más populares se encuentra:

Amazon Web Services: AWS Lambda
Microsoft Azure: Azure Functions
Google Cloud: Cloud Functions

AWS Lambda vs Azure Functions (Diferencias)

Configurabilidad AWS Lambda, necesita configurar la asignación máxima de memoria entre 128 mb a 3 GB, se ejecuta bajo Amazon Linux. Azure Functions, posee un plan único para todas las funciones, 1.5 GB de memoria, es posible ejecutar en Windows o Linux
Lenguajes AWS Lambda, permite JavaScript, Java, Python, C#, F#, PowerShell, Go y Ruby Azure Functions, permite JavaScript, Java, Python, C#, F#, y PowerShell, TypeScript
Costo El precio de ambos es de aproximada 0.20 USD por millón de solicitudes y 16 dólares por millón de GB/s AWS Lambda cobra por la capacidad total de memoria aprovisionada. Azure Functions mide el consumo de memoria promedio real de las ejecuciones.

Iniciando el proyecto

Crear el servidor de Discord (Si no se lo tiene)

Crear el canal de texto de noticias a utilizar, si no se tiene, puede ser público o privado.
Para el acceso al canal se tiene que obtener su ID del canal el cual se obtiene desde el Discord, este dato será nuestro DISCORD_CHANNEL_ID con el que accederemos a un canal en específico para noticias.

En caso de que no aparezca la opción para “Copiar ID” se debe activar desde Ajustes del Usuario > Avanzado > Modo Desarrollador

Se necesita crear una aplicación de discord para conectarse con el servidor, desde Discord Developer , en la cual crearemos una aplicación.

Una vez creada la aplicación debemos generar un bot dentro la aplicación el cual tendrá la capacidad de conectarse a los canales de Discord y obtener los mensajes.

Al generar el bot podemos obtener su Token de acceso con el cual podremos acceder mediante el bot, el cual lo utilizaremos más adelante.

Para agregar el bot de prueba a su servidor de Discord puede utilizar el siguiente enlace modificando los parámetros de acuerdo a los permisos que requiera.

https://discord.com/oauth2/authorize?client_id=APPLICATION_ID&permissions=PERMISSION_INTEGER&scope=bot

APPLICATION_ID lo podremos obtener de la información general de la Aplicación, reemplazamos en la URL de autorización.

PERMISSION_INTEGER es el número referencial a los permisos que tendrá el bot usamos el 66560 para la lectura de mensajes.

Para más información de los alcances existentes puede visitar: https://discord.com/developers/docs/topics/oauth2#shared-resources-oauth2-scopes

Una vez agregado el bot al Servidor ya podemos realizar la lectura de los mensajes, en caso de que se encuentre en un canal privado primero se debe agregar al bot al canal para poder acceder a los mensajes.

Consumo del API de Discord para obtención de los mensajes de un canal

Teniendo ya el bot configurado podemos realizar la lectura de los mensajes utilizando solicitudes HTTP para lo cual podemos realizar desde python de la siguiente manera.

import requests
url = "https://discordapp.com/api/channels/DISCORD_CHANNEL_ID/messages?limit=10"
payload={}
headers = {'Authorization': 'Bot BOT_TOKEN'}
response = requests.request("GET", url, headers=headers, data=payload)
print(response.text)

Crear la Skill

Ingresamos con nuestra cuenta a https://developer.amazon.com/alexa/console/ask desde el cual procederemos a crear nuestra Skill

Al crear nuestra Skill tenemos que configurar su nombre, el idioma primario para el que utilizaremos el Español, el modelo para el Skill será Custom ya que será proporcionado por nosotros, y la ubicación de nuestro backend que también la proporcionaremos nosotros mismos.

Para la demostración utilizaremos el Template inicial el cual contiene funcionalidades básicas

Una vez terminado de construir ya tenemos la Skill inicial en la cual nosotros podemos realizar la configuración de los Intents, Samples y Slots para que Alexa pueda entender nuestra Skill y realizar un correcto funcionamiento.

Nombre de Invocación

Lo primero que debemos revisar es el nombre de invocación de nuestra Skill, es el conjunto de palabras que permite a Alexa identificar y ejecutar nuestra Skill, ingresando a Skill Invocation Name cambiamos el nombre para la invocación, y guardamos nuestro modelo.

Definición de Intents, samples y slots

Los Intents representan a las acciones que cumplen con la solicitud hablada de un usuario, para lo cual crearemos nuestro Intent desde el menú de Intents y nuestro nuevo intent será “NoticiasIntent”.

De manera integrada en cada Skill tenemos 4 Intents que son para Cancelar, Ayuda, Detener ejecución y navegar entre nuestra Skill.

Posterior a crear nuestro intent debemos adicionar los Samples que representan la forma en la que los usuarios llaman a nuestro intent desde la Skill, y guardamos nuestro modelo

Los Slots son argumentos que nos permiten obtener parámetros del usuario que se extraen de los Intent y se envían como datos adicionales. En nuestro caso utilizaremos un slot para obtener un número y obtener un límite de mensajes de acuerdo a necesidad del usuario.

Una vez adicionado el Slot podemos agregar Samples que contengan nuestro Slot y tener llamadas con cantidades específicas de mensajes, quedándonos de la siguiente manera nuestro Intent con sus Samples y Slot!, y guardamos nuestro modelo Final

Hasta este punto ya tenemos la estructura que tendrá nuestra Skill y cómo será invocado mediante voz, ahora tenemos que construir nuestro Backend, una vez procesado y analizado la comunicación con el usuario se debe comunicar al Backend de la Skill que la tendremos alojada en Azure Functions

Creación de una Función con VS Code

Para crear el Backend primero abriremos VS Code e instalaremos la extensión de Azure Functions, esto para crear y publicar más fácilmente nuestras funciones https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-azurefunctions

Desde la pestaña de Azure se crea un nuevo Proyecto en la carpeta que contendrá nuestras Funciones.

Seleccionamos el Lenguaje “Python”

El entorno virtual a utilizar, se puede realizar un skip si no se utilizara entorno virtual, pero es recomendado siempre utilizar un entorno virtual.

Seleccionamos el tipo de Template de nuestro proyecto, al ser un Backend de la Skill tiene el formato de Solicitud HTTP Trigger

Como paso siguiente le proporcionamos el nombre a una función, en nuestro caso será “PotatoNoticiasTrigger”

Para este ejemplo utilizaremos un nivel de autorización anónimo

Por último lo abrimos en el mismo Workspace o en una nueva ventana

Con este último paso se realiza el generado del proyecto y tendremos una estructura similar de la siguiente forma:

.
├── .funcignore
├── .gitignore
├── host.json
├── local.settings.json
├── PotatoNoticiasTrigger
│   ├── function.json
│   ├── __init__.py
│   └── sample.dat
├── requirements.txt
└── .vscode
    ├── extensions.json
    ├── launch.json
    ├── settings.json
    └── tasks.json

Para probar podemos ejecutar desde el proyecto la función

func host start

Al momento de iniciar se levanta la instancia de Azure Functions Core Tools, puede suceder una excepción

Value cannot be null. Parameter name: Provider error on func start

Puede ser causada por la versión de la herramienta por lo cual una forma es verificar la versión en el archivo host.json
Para el proyecto actual se utiliza la version "[3.3.0, 4.0.0)",

"extensionBundle": {
    "id": "Microsoft.Azure.Functions.ExtensionBundle",
    "version": "[3.3.0, 4.0.0)"
  }

Adicionamos a las librerías de requerimientos los siguientes para el diseño de la Skill y consumo de solicitudes

requirements.txt

requests
ask-sdk-core
ask-sdk-webservice-support

Instalaremos las librerías utilizando

pip install -r requirements.txt

Ahora podemos implementar la lógica de nuestra Skill sobre la función. Para lo cual primero empezaremos por añadir un archivo de configuración, para obtener en formato de variables de entorno los Keys e ID’s para proteger esa información de publicarla libremente.

config.py

import os
ALEXA_SKILL_ID = os.getenv("ALEXA_SKILL_ID", "")
DISCORD_CHANNEL_ID = os.getenv("DISCORD_CHANNEL_ID", "")
DISCORD_BOT_TOKEN = os.getenv("DISCORD_BOT_TOKEN", "")

Estos 3 valores son los que usamos desde los distintos lugares para acceder a nuestros demás servicios.

ALEXA_SKILL_ID lo podemos obtener desde la consola de Alexa https://developer.amazon.com/alexa/console/ask en la cual podemos copiar nuestro Skill ID

DISCORD_CHANNEL_ID ya lo habíamos obtenido anteriormente de la creación del canal

DISCORD_BOT_TOKEN al igual lo obtuvimos con anterioridad al crear el BOT de Discord

Obtención de los N mensajes desde Discord

Ahora crearemos el método en python que nos permitirá obtener los “N” últimos mensajes de discord

discord.py

from typing import List
import requests
import json
from PotatoNoticiasTrigger.config import DISCORD_CHANNEL_ID, DISCORD_BOT_TOKEN
def get_n_messages(size: int = 5):
    # type: (int) -> List
    payload = {}
    url = "https://discordapp.com/api/channels/{0}/messages?limit={1}".format(
        DISCORD_CHANNEL_ID, size)
    headers = {
        'Authorization': 'Bot {0}'.format(DISCORD_BOT_TOKEN)
    }
    response = requests.request("GET", url, headers=headers, data=payload)
    if (response.status_code == 200):
        data = response.json()
        return data
    else:
        return None

Implementación de las funciones básicas para un Skill en Python

Ahora debemos implementar las funciones básicas de la Skill e incluir todos los Intents, el que vamos a implementar “NoticiasIntent” como los por defecto como de excepciones para poder responder a posibles fallas de ejecución.

Los Intents son manejados en formato de clase, en el cual definimos de tipo AbstractRequestHandler, un método “can_handle” con el nombre del Intent a manejar en esa clase, y un método “handle” en el cual se realiza la ejecución de la acción para ser devuelta a Alexa a través de la Skill ya sea en voz o en texto visual.

Invocación

default_intents.py

class LaunchRequestHandler(AbstractRequestHandler):
    def can_handle(self, handler_input):
        return is_request_type("LaunchRequest")(handler_input)

    def handle(self, handler_input):
        print("Ejecucion de la Skill.")
        speech_text  = "Bienvenido a Potato Noticias, puedes decir últimas noticias"
        handler_input.response_builder.speak(speech_text).set_card(
            SimpleCard("Potato Noticias", speech_text)).set_should_end_session(False)
        return handler_input.response_builder.response

Ayuda

default_intents.py

class HelpIntentHandler(AbstractRequestHandler):
    def can_handle(self, handler_input):
        # type: (HandlerInput) -> bool
        return is_intent_name("AMAZON.HelpIntent")(handler_input)

    def handle(self, handler_input):
        # type: (HandlerInput) -> Response
        print("Ejecucion Intent Ayuda")
        speech_text = "Puedes decir últimas noticias, últimos 2 mensajes"
        handler_input.response_builder.speak(speech_text).ask(speech_text).set_card(
            SimpleCard("Potato Noticias - Ayuda", speech_text))
        return handler_input.response_builder.response

Cancelar o Detener

default_intents.py

class CancelAndStopIntentHandler(AbstractRequestHandler):
    def can_handle(self, handler_input):
        # type: (HandlerInput) -> bool
        return is_intent_name("AMAZON.CancelIntent")(handler_input) or is_intent_name("AMAZON.StopIntent")(handler_input)

    def handle(self, handler_input):
        # type: (HandlerInput) -> Response
        print("Ejecución Intent Cancel o Stop")
        speech_text = "Hasta luego Atentamente Potato Noticias!"
        handler_input.response_builder.speak(speech_text).set_card(
            SimpleCard("Potato Noticias", speech_text)).set_should_end_session(True)
        return handler_input.response_builder.response

Terminar Sesión

default_intents.py

class SessionEndedRequestHandler(AbstractRequestHandler):
    def can_handle(self, handler_input):
        # type: (HandlerInput) -> bool
        return is_request_type("SessionEndedRequest")(handler_input)

    def handle(self, handler_input):
        # type: (HandlerInput) -> Response
        # any cleanup logic goes here
        return handler_input.response_builder.response

Manejo de Excepciones

default_intents.py

class AllExceptionHandler(AbstractExceptionHandler):
    def can_handle(self, handler_input, exception):
        # type: (HandlerInput, Exception) -> bool
        return True

    def handle(self, handler_input, exception):
        # type: (HandlerInput, Exception) -> Response
        print(exception)
        speech = "Lo siento, No pude procesarlo. Puedes intentarlo nuevamente o decir Ayuda"
        handler_input.response_builder.speak(speech).ask(speech)
        return handler_input.response_builder.response

El archivo final default_intents quedaria de la siguiente manera

from ask_sdk_core.dispatch_components import AbstractRequestHandler, AbstractExceptionHandler
from ask_sdk_core.utils import is_request_type, is_intent_name
from ask_sdk_core.handler_input import HandlerInput
from ask_sdk_model import Response
from ask_sdk_model.ui import SimpleCard


class LaunchRequestHandler(AbstractRequestHandler):
    def can_handle(self, handler_input):
        return is_request_type("LaunchRequest")(handler_input)

    def handle(self, handler_input):
        print("Ejecucion de la Skill.")
        speech_text = "Bienvenido a Potato Noticias, puedes decir últimas noticias"
        handler_input.response_builder.speak(speech_text).set_card(
            SimpleCard("Potato Noticias", speech_text)).set_should_end_session(False)
        return handler_input.response_builder.response


class HelpIntentHandler(AbstractRequestHandler):
    def can_handle(self, handler_input):
        # type: (HandlerInput) -> bool
        return is_intent_name("AMAZON.HelpIntent")(handler_input)

    def handle(self, handler_input):
        # type: (HandlerInput) -> Response
        print("Ejecucion Intent Ayuda")
        speech_text = "Puedes decir últimas noticias, últimos 2 mensajes"
        handler_input.response_builder.speak(speech_text).ask(speech_text).set_card(
            SimpleCard("Potato Noticias - Ayuda", speech_text))
        return handler_input.response_builder.response


class CancelAndStopIntentHandler(AbstractRequestHandler):
    def can_handle(self, handler_input):
        # type: (HandlerInput) -> bool
        return is_intent_name("AMAZON.CancelIntent")(handler_input) or is_intent_name("AMAZON.StopIntent")(handler_input)

    def handle(self, handler_input):
        # type: (HandlerInput) -> Response
        print("Ejecucion Intent Cancel o Stop")
        speech_text = "Hasta luego Atentamente Potato Noticias!"
        handler_input.response_builder.speak(speech_text).set_card(
            SimpleCard("Potato Noticias", speech_text)).set_should_end_session(True)
        return handler_input.response_builder.response


class SessionEndedRequestHandler(AbstractRequestHandler):
    def can_handle(self, handler_input):
        # type: (HandlerInput) -> bool
        return is_request_type("SessionEndedRequest")(handler_input)

    def handle(self, handler_input):
        # type: (HandlerInput) -> Response
        # any cleanup logic goes here
        return handler_input.response_builder.response


class AllExceptionHandler(AbstractExceptionHandler):
    def can_handle(self, handler_input, exception):
        # type: (HandlerInput, Exception) -> bool
        return True

    def handle(self, handler_input, exception):
        # type: (HandlerInput, Exception) -> Response
        print(exception)
        speech = "Lo siento, No pude procesarlo. Puedes intentarlo nuevamente o decir Ayuda"
        handler_input.response_builder.speak(speech).ask(speech)
        return handler_input.response_builder.response

Implementación de la lógica para el Intent de solicitud de N mensajes

Hasta este punto ya hemos implementado los Intents básicos que debe poseer una Skill para facilitar a los usuarios su administración y manejo, ahora nos toca implementar de la misma manera nuestro propio Intent :D

Primeramente definiremos un generate_reponse que recibe un array de mensajes y los convierte en texto para ser escuchado y texto para ser leído desde un dispositivo.

noticias_intent.py

def generate_response(messages):
    # type: (List) -> Tuple[str,str]
    speak_out = ""
    speak_out_visible = ""
    itemCount = 1
    for message in messages:
        speak_out += 'Mensaje {0}: <break time="0.5s"/> {1}. <break time="1s"/>'.format(
            itemCount, message.get("content", ""))
        speak_out_visible += '{0}: {1}.\n'.format(
            itemCount, message.get("content", ""))
        itemCount += 1
    return speak_out, speak_out_visible

En el caso de speak_out se añade la etiqueta break esto hace referencia al SSML (Speech Synthesis Markup Language), que es un estándar que permite a los asistentes de voz añadir pausas, efectos especiales de voz como susurro, o la pronunciación de palabras en un idioma extranjero de forma correcta

Después creamos el Handler para nuestro NoticiasIntent, en el cual accederemos a discord y obtendremos los mensajes les daremos un formato para ser escuchados y vistos y sean devueltos hacia el asistente.

noticias_intent.py

class NoticiasIntentHandler(AbstractRequestHandler):
    def can_handle(self, handler_input):
        # type: (HandlerInput) -> bool
        return is_intent_name("NoticiasIntent")(handler_input)

    def handle(self, handler_input):
        # type: (HandlerInput) -> Response
        cantidad = get_slot_value(handler_input, "cantidad")
        print(cantidad)
        if cantidad is not None:
            messages = get_n_messages(size=cantidad)
        else:
            messages = get_n_messages()
        if messages is None or len(messages) == 0:
            speak_output = "No se encontraron mensajes"
            visual_output = "No se encontraron mensajes :("
        else:
            speak_output,visual_output = generate_response(messages)
            speak_output += " Esos son todos los mensajes!."
            visual_output += " Esos son todos los mensajes!."
        handler_input.response_builder.speak(speak_output).set_card(
            SimpleCard("Potato Noticias", visual_output)).set_should_end_session(True)
        return handler_input.response_builder.response

Hasta este punto ya tenemos los intents y nos faltaria integrarlo en el init de la función y realizar pruebas :D

Integración de los intents en el init de la función

Reemplazamos todo el contenido de nuestro con lo siguiente, que integra tanto nuestros intents por defecto como el Intent custom para lectura de discord.

__ init __.py

import json
import azure.functions as func
from ask_sdk_core.skill_builder import SkillBuilder
from ask_sdk_webservice_support.webservice_handler import WebserviceSkillHandler
from PotatoNoticiasTrigger.default_intents import AllExceptionHandler, CancelAndStopIntentHandler, HelpIntentHandler, LaunchRequestHandler, SessionEndedRequestHandler
from PotatoNoticiasTrigger.noticias_intent import NoticiasIntentHandler
from PotatoNoticiasTrigger.config import ALEXA_SKILL_ID

def main(req: func.HttpRequest) -> func.HttpResponse:
    skill_builder = SkillBuilder()
    skill_builder.skill_id = ALEXA_SKILL_ID
    # Default Intents
    skill_builder.add_request_handler(LaunchRequestHandler())
    skill_builder.add_request_handler(HelpIntentHandler())
    skill_builder.add_request_handler(CancelAndStopIntentHandler())
    skill_builder.add_request_handler(SessionEndedRequestHandler())
    skill_builder.add_exception_handler(AllExceptionHandler())
    # Custom Intents
    skill_builder.add_request_handler(NoticiasIntentHandler())

    webservice_handler = WebserviceSkillHandler(skill=skill_builder.create())
    response = webservice_handler.verify_request_and_dispatch(req.headers, req.get_body().decode("utf-8"))
    return func.HttpResponse(json.dumps(response),mimetype="application/json")

Ahora podemos probar el Intent y conectarlo a la Skill a través de Ngrok :D

Primeramente ejecutamos nuestra Función utilizando:

func host start

Esta llamada nos genera una salida similar en la cual nos muestra la salida de nuestra Función en local similar a:

http://localhost:7071/api/PotatoNoticiasTrigger

Ahora gracias a la herramienta Ngrok que nos permite abrir tuneles publicos hacia nuestros Endpoints locales ejecutaremos en otra terminal

ngrok http 7071

Que nos generará una dirección temporal para que conectemos nuestro EndPoint de la siguiente manera:

Forwarding                    http://2dba-200-87-92-9.ngrok.io -> http://localhost:7071
Forwarding                    https://2dba-200-87-92-9.ngrok.io -> http://localhost:7071

Utilizando la dirección HTTPS volvemos a la consola de Amazon y nos dirigimos a la parte de Endpoint en Default Region y añadimos nuestra dirección Ngrok más la ruta del Trigger teniendo algo similar a:

https://2dba-200-87-92-9.ngrok.io/api/PotatoNoticiasTrigger

Seleccionamos la opción para el certificado SSL “My development endpoint is a sub-domain of a domain that has a wildcard certificate from a certificate authority”

Guardamos el Endpoint, ahora tenemos que compilar para lo cual nos dirigimos hacia el menú principal y seleccionamos la Opción Build Model para construir el modelo de la Skill.

Esperamos unos minutos a que termine la construcción del modelo.

Pruebas de funcionamiento de la Skill integrada con el Endpoint Local

Desde la pestaña de Test podemos probar nuestra Skill apuntando hacia el Backend local en nuestro equipo. Habilitamos la Skill en modo Development y ya podemos probar

Publicación en Azure del Backend de la Skill

Hemos logrado hacer funcionar la Skill y que nos responda desde Local ahora podemos publicarlo en Azure :D y actualizar el EndPoint y volver a compilar nuestro modelo.
Desde VS Code seleccionamos la Opción Deploy to Function App

Seleccionamos la Suscripción de Azure que tengamos disponible, para usuarios nuevos pueden habilitar una suscripción de prueba y para estudiantes habilitar una suscripción de tipo estudiantil si se los permite sus cuentas institucionales.

Seleccionar una nueva función en Azure

Ingresamos el nombre de nuestra nueva función

Seleccionamos la pila de ejecución que se recomienda que sea coincidente con la que tenemos en local

Seleccionamos la región donde se aloja nuestra función, en nuestro caso WEST US y se procede a crear nuestra función, esperamos unos minutos mientras se generan los servicios.

Tenemos que configurar nuestras variables de entorno con nuestros KEYS y ID Seleccionamos la función y abrimos en Portal

Desde las configuraciones en Azure Añadimos 3 Configuraciones de Aplicación con el mismo nombre de nuestras variables de entorno

Una vez adicionado nuestras variables de entorno procedemos a guardar donde se reiniciará la instancia de la función

Ahora desde la parte de funciones podemos obtener la URL de nuestro nuevo ENDPOINT similar a

https://potatonoticias.azurewebsites.net/api/PotatoNoticiasTrigger

el cual actualizaremos en el Endpoint en el portal de Alexa y volveremos a construir el modelo esperemos que termine y podemos probar nuestra Skill

De esta manera podemos concluir el contenido, consumir un canal de Discord, pasar por una Skill de Alexa y publicar el backend de nuestra función en Azure, todo un conjunto de elementos integrados para automatizar y permitir a las personas escuchar potato noticias desde cualquier dispositivo con Alexa.

Muchas gracias!!

Un agradecimiento a la comunidad de Python La Paz por permitirme dar una charla sobre esto, síganlos en sus redes sociales Facebook y Twitter y pregunten por su servidor de Discord, para conocer más sobre futuras charlas y eventos, también pueden ser expositores y enseñarnos su conocimiento para crecer con esta bonita comunidad.

El repositorio público en Github lo pueden encontrar aqui del proyecto Potato Noticias

La presentación se encuentra disponible en el siguiente enlace Presentación

Algunos enlaces en cuanto a contenido sobre todo lo expuesto.

Bibliografías

https://www.redhat.com/es/topics/automation
https://blog.grupocajamar.com/que-son-los-asistentes-virtuales-inteligentes/
https://developer.amazon.com/es-ES/alexa
https://alexaecho.es/las-mejores-ideas-de-rutina-y-habilidades-de-alexa-para-automatizar-tu-vida/
https://serverless-stack.com/chapters/es/what-is-serverless.html
https://es.wikipedia.org/wiki/Serverless_computing
https://iamondemand.com/blog/aws-lambda-vs-azure-functions-ten-major-differences