Los pasos los adapté de esta guía de linuxtechi

El requisito previo es tener k3s y helm instalado en nuestra máquina, si no sabes como, me preguntas por X

Como primer paso agregamos el repositorio de awx-operator a helm:

helm repo add awx-operator https://ansible.github.io/awx-operator/

Luego, instalamos el operador en nuestro cluster k3s, utilizando helm

helm install ansible-awx-operator awx-operator/awx-operator -n awx --create-namespace

Validamos que el pod del operador (que luego nos instalará los componentes que necesitemos) se encuentre en estado Running:

pulpo@pop-os:~$ kubectl get pods -n awx | grep opera
awx-operator-controller-manager-6569d67f4c-x5dbp   2/2     Running   5 (72m ago)   24h

Dado que k3s ya viene con un storage class por defecto para crear volúmenes dentro de la máquina donde se esté ejecutando, el siguiente paso es simplemente definir un volume claim, y un custom resource definition (si queremos explorar la lista completa de los crds de awx instalados podemos ejecutar kubectl get crds awxs.awx.ansible.com -o yaml; para nuestro caso de uso vamos a crear un archivo yaml con el siguiente contenido:

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres-13-ansible-awx-postgres-13-0
  namespace: awx
spec:
  storageClassName: local-path
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
---
apiVersion: awx.ansible.com/v1beta1
kind: AWX
metadata:
  name: ansible-awx
  namespace: awx
spec:
  service_type: nodeport
  postgres_storage_class: local-path

En mi caso le di un nombre al yaml, y luego lo apliqué contra el cluster ejecutando kubectl apply -f awx_manifest_for_operator.yaml

Después de unos momentos, el namespace awx deberá tener los pods en ejecución:

pulpo@pop-os:~$ kubectl get pods -n awx
NAME                                               READY   STATUS    RESTARTS      AGE
awx-operator-controller-manager-6569d67f4c-x5dbp   2/2     Running   5 (79m ago)   24h
ansible-awx-postgres-13-0                          1/1     Running   0             55m
ansible-awx-task-6b4b565686-cbdg5                  4/4     Running   0             54m
ansible-awx-web-799c7f78b5-dwr7k                   3/3     Running   0             52m

Finalmente, exponemos el deployment de awx

kubectl expose deployment ansible-awx-web --name ansible-awx-web-svc --type NodePort -n awx

Obtenemos la password de admin que está guardada en un secreto de kubernetes:

kubectl get secret ansible-awx-admin-password -o jsonpath="{.data.password}" -n awx | base64 --decode ; echo

Y accedemos al puerto que haya creado el deployment (si no lo sabemos, lo obtenemos listando los svc):

pulpo@pop-os:~$ kubectl get svc -n awx ansible-awx-web-svc
NAME                  TYPE       CLUSTER-IP    EXTERNAL-IP   PORT(S)          AGE
ansible-awx-web-svc   NodePort   10.43.66.87   <none>        8052:30087/TCP   53m

Durante muchos años tuve este blog en linea corriendo en su propio hardware, en ese momento me parecía buena idea mantenerme con la arquitectura ARM v7 (32 bits) ya que era lo mas popular por fuera del mundo intel/amd, pero siendo que estamos en 2023, cobra sentido montar algo utilizando una arquitectura acorde a los tiempos que vivimos, y decidí armar una imagen ARM v8 (64 bits).

Hace varios años había armado con un gran amigo a Ñamandú, una solución que por lo divertido que estuvimos los últimos tres años no hemos vuelto a tocar, al medio era obvio que alguna solución iba a aparecer y que el costo de actualizar lo que habíamos hecho iba a ser superior a adaptar algo ya existente, es por eso que me puse a ver tekton y a retomar las pruebas de multiarch building en el universo de buildah.

Escapa al objetivo de este texto cubrir los fundamentos de tekton, que se pueden encontrar en la documentación oficial, me voy a enfocar en dejarme documentado para mi yo del futuro, las modificaciones que tuve que realizar sobre la task de buildah oficial

Lo primero fue entender cuáles eran los comandos necesarios para hacer un build con buildah, generando un manifiesto mutliarquitectura, subiéndolo luego junto con las imágenes resultantes a un registro.

Modificaciones en la task

Dentro del script de la task, lo primero que hice fue agregar una configuración en /etc/containers/registries.conf que permitiese buscar imágenes en el registry de docker (docker.io), de esta forma si queremos buildear imágenes con referencias del tipo FROM alpine:latest no tendremos que modificarlas a algo como FROM docker.io/alpine:latest, como la idea es buildear imágenes de terceros, esto nos puede ser de mucha utilidad.

echo 'unqualified-search-registries = ["docker.io"]' >> /etc/containers/registries.conf

Luego, le agrego al script la creación de un manifest, utilizando buildah manifest create multiarchmanifest (el nombre del manifest no me importa, ya que lo uso temporalmente durante el tiempo de vida de la ejecución del pipeline).

Posteriormente, modifico la linea de buildah bud para incluir el uso del manifest creado:

buildah ${CERT_DIR_FLAG} --storage-driver=$(params.STORAGE_DRIVER) bud \
      $(params.BUILD_EXTRA_ARGS) --format=$(params.FORMAT) --manifest multiarchmanifest \
        --tls-verify=$(params.TLSVERIFY) --no-cache \
      -f $(params.DOCKERFILE) -t $(params.IMAGE):$(params.TAG) $(params.CONTEXT)

Luego reemplazo la linea de push (en el archivo final dejo los comments para que se entienda dónde fue el reemplazo), por un buildah manifest push

buildah ${CERT_DIR_FLAG} --storage-driver=$(params.STORAGE_DRIVER) manifest push \
               $(params.PUSH_EXTRA_ARGS) --tls-verify=$(params.TLSVERIFY) \
               --digestfile /tmp/image-digest --rm multiarchmanifest \
               --format=$(params.FORMAT) docker://$(params.IMAGE):$(params.TAG) 

También agregué un parámetro TAG a la tarea, de forma tal de que pueda luego definir en el pipelinerun el tag multiarch que quiero construir.

El archivo resultante queda entonces definido como:

---
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: buildah
  labels:
    app.kubernetes.io/version: "0.5"
  annotations:
    tekton.dev/categories: Image Build
    tekton.dev/pipelines.minVersion: "0.17.0"
    tekton.dev/tags: image-build
    tekton.dev/platforms: "linux/amd64,linux/s390x,linux/ppc64le,linux/arm64"
spec:
  description: >-
    Buildah task builds source into a container image and
    then pushes it to a container registry.

    Buildah Task builds source into a container image using Project Atomic's
    Buildah build tool.It uses Buildah's support for building from Dockerfiles,
    using its buildah bud command.This command executes the directives in the
    Dockerfile to assemble a container image, then pushes that image to a
    container registry.

  params:
  - name: IMAGE
    description: Reference of the image buildah will produce.
  - name: BUILDER_IMAGE
    description: The location of the buildah builder image.
    default: quay.io/buildah/stable:v1.30.0
  - name: STORAGE_DRIVER
    description: Set buildah storage driver
    default: overlay
  - name: DOCKERFILE
    description: Path to the Dockerfile to build.
    default: ./Dockerfile
  - name: CONTEXT
    description: Path to the directory to use as context.
    default: .
  - name: TLSVERIFY
    description: Verify the TLS on the registry endpoint (for push/pull to a non-TLS registry)
    default: "true"
  - name: FORMAT
    description: The format of the built container, oci or docker
    default: "oci"
  - name: BUILD_EXTRA_ARGS
    description: Extra parameters passed for the build command when building images.
    default: ""
  - name: PUSH_EXTRA_ARGS
    description: Extra parameters passed for the push command when pushing images.
    type: string
    default: ""
  - name: SKIP_PUSH
    description: Skip pushing the built image
    default: "false"
  - name: TAG
    description: Image tag 
    default: "latest"
  workspaces:
  - name: source
  - name: sslcertdir
    optional: true
  - name: dockerconfig
    description: >-
      An optional workspace that allows providing a .docker/config.json file
      for Buildah to access the container registry.
      The file should be placed at the root of the Workspace with name config.json.
    optional: true
  results:
  - name: IMAGE_DIGEST
    description: Digest of the image just built.
  - name: IMAGE_URL
    description: Image repository where the built image would be pushed to
  steps:
  - name: build
    image: $(params.BUILDER_IMAGE)
    workingDir: $(workspaces.source.path)
    script: |
      # add some extra config to search on docker.io and don't broke already well knowed images
      echo 'unqualified-search-registries = ["docker.io"]' >> /etc/containers/registries.conf

      [[ "$(workspaces.sslcertdir.bound)" == "true" ]] && CERT_DIR_FLAG="--cert-dir $(workspaces.sslcertdir.path)"
      [[ "$(workspaces.dockerconfig.bound)" == "true" ]] && export DOCKER_CONFIG="$(workspaces.dockerconfig.path)"
      buildah manifest create multiarchmanifest 
      buildah ${CERT_DIR_FLAG} --storage-driver=$(params.STORAGE_DRIVER) bud \
      $(params.BUILD_EXTRA_ARGS) --format=$(params.FORMAT) --manifest multiarchmanifest \
        --tls-verify=$(params.TLSVERIFY) --no-cache \
      -f $(params.DOCKERFILE) -t $(params.IMAGE):$(params.TAG) $(params.CONTEXT)
      [[ "$(params.SKIP_PUSH)" == "true" ]] && echo "Push skipped" && exit 0
      #      buildah ${CERT_DIR_FLAG} --storage-driver=$(params.STORAGE_DRIVER) push \
      #        $(params.PUSH_EXTRA_ARGS) --tls-verify=$(params.TLSVERIFY) \
      #        --digestfile /tmp/image-digest $(params.IMAGE):$(params.IMAGE) \
      #        docker://$(params.IMAGE):$(params.IMAGE) 
      buildah ${CERT_DIR_FLAG} --storage-driver=$(params.STORAGE_DRIVER) manifest push \
               $(params.PUSH_EXTRA_ARGS) --tls-verify=$(params.TLSVERIFY) \
               --digestfile /tmp/image-digest --rm multiarchmanifest \
               --format=$(params.FORMAT) docker://$(params.IMAGE):$(params.TAG) 
 
      cat /tmp/image-digest | tee $(results.IMAGE_DIGEST.path)
      echo -n "$(params.IMAGE)" | tee $(results.IMAGE_URL.path)
    volumeMounts:
    - name: varlibcontainers
      mountPath: /var/lib/containers
    securityContext:
      privileged: true
  volumes:
  - name: varlibcontainers
    emptyDir: {}

Creando el pipeline

Vamos ahora a definir un archivo para alimentar tekton, para que este cree un pipelinerun. En el mismo llamamos a la tarea oficial de git-clone, con parámetros especifiando el repositorio de código que queremos construir, el nombre de la imagen (incluyendo el registry), y algunos parámetros adicionales para el build, y otros para el push.

Para el build vamos a agregarle --jobs 3 --platform linux/arm,linux/arm64,linux/amd64, esto define las plataformas para las que vamos a construir la imagen, y adicionalmente le paso la cantidad de jobs en paralelo que quiero que ejecute (3, por las 3 plataformas).

Para el caso del push, el parámetro --all permite que al hacer push del manifest, también se suban las imágenes contenidas en el índice de dicho manifesto.

apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  generateName: buildah-writefreely-pipeline-run-
spec:
  pipelineSpec:
    workspaces:
      - name: shared-workspace
      - name: sslcertdir
        optional: true
      - name: dockerconfig-ws
        optional: true
    tasks:
      - name: fetch-repository
        taskRef:
          name: git-clone
        workspaces:
          - name: output
            workspace: shared-workspace
        params:
          - name: url
            value: https://github.com/writefreely/writefreely.git 
          - name: subdirectory
            value: ""
          - name: deleteExisting
            value: "true"
      - name: buildah
        taskRef:
          name: buildah
        runAfter:
        - fetch-repository
        workspaces:
        - name: source
          workspace: shared-workspace
        - name: dockerconfig
          workspace: dockerconfig-ws
        params:
        - name: IMAGE
          value: docker.io/jinetessl/writefreely 
        - name: BUILD_EXTRA_ARGS
          value: --jobs 3 --platform linux/arm,linux/arm64,linux/amd64
        - name: PUSH_EXTRA_ARGS
          value: --all
        - name: SKIP_PUSH
          value: false 
        - name: FORMAT
          value: docker
  workspaces:
    - name: shared-workspace
      volumeClaimTemplate:
        spec:
          accessModes:
            - ReadWriteOnce
          resources:
            requests:
              storage: 1000Mi
    - name: dockerconfig-ws
      secret:
        secretName: dockerconfig-secret

Adicionalmente armé un secreto con las credenciales de auth para poder subir al registro de docker las imágenes resultantes:

apiVersion: v1
kind: Secret
metadata:
  name: dockerconfig-secret
stringData:
  config.json: |
    {
      "auths": {
        "docker.io": {
          "auth": "XXXXXXXXXXXXXXX=="
        }
      }
    }

Luego, tras realizar un kubectl create -f con el archivo del pipeline run, tras unos minutos tengo una imagen multiarchitectura subida en el repositorio de imágenes, un amor!

The equipment has an intel i7 10th generation, 16 GB of RAM, an nvidia rtx2060, an incredible screen, and a badass look.

When the equipment arrived, the first thing after unboxing it, was to try to install Manjaro on it. And this is how our journey starts.

Enabling more possibilities, disabling Optane Data Raid

To be able to let Manjaro recognize our hard disk, the first thing to do (and maybe the lazy path, because with researching maybe a better solution come up), it's to disable the Raid mode (useless in case you have one disk, and something that I prefer to solve by other ways if I need it in the future, for example, with LVM).

To do it, you need to enter to the Predator's bios (pressing F2 after power up the machine), and enable a secret feature pressing Ctrl+s at the Main tab of the bios (in advance mode). From there, you will see the option SATA Mode, with can now be changed to AHCI.

From there, you can advance into a standard installation, it's up to you to remove the windorch partition or resize it, and install our operative system.

Installing nvidia drivers, i32 libs and optimus-manager

After installing our system, we will need to install the nvidia's propietary drivers, they perfom really great with GNU/Linux.

See which kernel do you have

$ uname -a
Linux predatora 5.4.67-1-MANJARO #1 SMP PREEMPT Wed Sep 23 14:20:18 UTC 2020 x86_64 GNU/Linux

After that, install a matched driver

sudo pacman -Sy nvidia

And if it makes you any question, respond with something like linux54-rt-nvidia-450xx-450 that should match your kernel version and nvidia driver version (today, 450 was the latest).

Also you will need some libs from the AUR if you want to play games with 32bits support (I like to use pikaur, but yay, yaourt, or another AUR manager can be used):

pikaur lib32-nvidia-utils

You will need to install optimus-manager to controll which GPU use, you can use the intel one, the nvidia one, or both

pikaur optimus-manager

It has a nice UI to config, that you can launch with optimus-manager-qt, but you will need first to enable and start the service

sudo systemctl enable optimus-manager && sudo systemctl start optimus-manager

Enjoy

Now you can choose whatever you want to play, at the time of this writting I'm enjoying a lot to exlore a universe at No Man's Sky.

I wasn't comfortable with the idea of using someone's else container, so I got an autobuild system that I made with a friend some time ago, and put it to build and publish a fresh image which I'm more comfortable with, that you can find at the docker hub.

To lunch a scan, you only need to run

docker run --rm -it -v /:/target iotops/chkrootkit

You can find the source code here

Enjoy!

I've purchased an nvidia 1030 card to give some extra life to my old desktop (a 10 years old equipment that today belongs to my son, an 8 years old kid), I was surprised about the fact that the card was fully compatible with my hardware!

The problems came when my friends, the ones with whom I made my engineering career, wanted to remember the old times, when we made groups to study and get our first jobs (and instead of that were spent playing video games).

Some of those beloved friends (all were GNU/Linux users when they were young), now are using Mac, and for playing, Windows (except the aBatar, who still remain in the right path, and plays in a GNU/Linux box with an ati card).

One of them, asked us to move the Friday's match of Risk of Rain, to the brand new Risk of Rain 2, and guess what, I found no excuses, today is possible to play Windows games on GNU/Linux, wine has evolved a lot, and with the Steam's Proton everything should work out of the box... until you try it!

The problems started to appear, I was not even close to have the game working, and it were Thursday! I started to duckduckgo everything, but no clues were appearing.... until I read someone asking to someone else to run a vkcube, I tried at my system, and what I had was....

$ vkcube 
failed to initialize wayland, falling back to xcb
No Vulkan devices found.

Going a little dipper into the problem, someone pointed to someone else to check if vulkan files were in place, I made and ls and I got:

$ ls -l /usr/share/vulkan/icd.d/
total 12
-rwxr-xr-x 1 root root 126 ago  7 10:11 amd_icd32.json
-rwxr-xr-x 1 root root 124 ago  7 09:55 amd_icd64.json
-rw-r--r-- 1 root root 140 jul  9 13:06 nvidia_icd.json

I have another friend, that once told me that computers are not deterministic systems, besides his joke, what I think is that is because the variables that make a system to be deterministic, should be set up...

So, trying to kill the entropy of this old box, I found the missed variable:

export VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/nvidia_icd.json

And yes, the precious cube is at my screen! And it's not sucking at all!

So, time to load the configuration into the Steam's client has arrived:

My Fridays will be fun once again!

Dato adicional, si actualizan los paquetes y deja de funcionar, posiblemente actualizaron el kernel ;), hay que repetir los pasos.

Si el párrafo anterior te identifica en alguna forma, voy a mostrar cómo solucioné esto con dos herramientas, keybase y kubie.

Keybase

Si no conoces keybase quizás te estés perdiendo de una de las mejores soluciones de mensajería segura y servicio de intercambio de archivos, todo basado en PGP. Puntualmente de este sevicio lo que más interés me despierta es la posibilidad de poder contar con un disco de 250GB, encriptado, que puedo montar en la terminal que esté usando.

Kubie

Kubie es una alternativa a kubectx y kubens, y como indica su README, nos permite cambiar de contexto, namespace, y lo mejor, soporta archivos de configuración separados, es decir, puedo tener un archivo KUBECONFIG para cada uno de mis clusters, todos en diferentes locaciones.

Cómo utilizo lo anterior

El esquema que utilizo es bastante simple, considerando que keybase me da un filesystem privado en /run/user/1000/keybase/kbfs/private/${USER}, dentro creo un directorio donde coloco todas las configuraciones:

$ ls -l /run/user/1000/keybase/kbfs/private/pulpo/configs/
total 25
-rw------- 1 pulpo root 1052 may 17 15:07 config_brawne.yaml
-rw------- 1 pulpo root 1057 mar 11 11:27 config_cerebro.yaml
-rw------- 1 pulpo root 1050 mar  5 12:51 config_pinky.yaml
-rw------- 1 pulpo root 1055 may 31 11:03 config_pita.yaml
-rw------- 1 pulpo root 1052 abr 21 16:00 config_wendy.yaml

Por lo que edito el archivo ~/.kube/kubie.yaml, apuntando a dicho directorio.

configs:
    # Salida truncada para ejemplo
    # Include these globs.
    # Default: values listed below.
    include:
        - /run/user/1000/keybase/kbfs/private/pulpo/configs/*.yaml

    # Exclude these globs.
    # Default: values listed below.
    # Note: kubie's own config file is always excluded.
    exclude:
        - ~/.kube/kubie.yaml

Con esto, al ejecutar kubie ctx, puedo elegir sobre qué cluster trabajar.

Una aclaración, el nombre que se muestra es el del contexto dentro de cada archivo .yaml, por lo que al armar cada configuración, cambia el context name.

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://someip:6443
  name: default
contexts:
- context:
    cluster: default
    namespace: dns
    user: default
  name: pita #Este es el nombre de contexto que deberías modificar
current-context: pita
kind: Config
preferences: {}

Objetivo Principal

Crear una plataforma para que alumnas y alumnos de instituciones educativas puedan compartir cuentos con sus compañeros de forma audiovisual.

Objetivo Secundario

La institución debe ser la dueña del contenido, entendiendo como dueño a quien pueda:

• Subir material a la plataforma
• Compartir el material
• Limitar los grupos de exposición del mismo
• Destruir el material

El uso de la plataforma idealmente debe ser lo más parecido posible a plataformas como YouTube, para facilitar su adopción y consumo, pero removiendo los componentes de ludificación que posee la misma, a fin de evitar la manipulación en el comportamiento que dichos componentes generan (likes, dislikes, contador de vistas).

Motivación

La necesidad de distanciamiento físico necesaria para disminuir la propagación del virus COVID-19 ha obligado a las instituciones educativas a cambiar su modalidad de dictados de clases, y buscar por lo tanto nuevas herramientas que ofrezcan a los alumnos la motivación suficiente para estudiar desde sus hogares. En el marco de dicha situación, fue que en la Escuela Domingo Faustino Sarmiento, ubicada en el barrio Amuchástegui (La Quebrada) del Municipio de Río Ceballos, el curso de 2do grado, turno tarde, coordinado por la maestra María Laura, para fomentar la lectura de cuentos fue compartiendo mediante un grupo de WhatsApp videos de los alumnos realizando lecturas de textos a sus compañeros.

Dado el alcance que hoy tienen los videos de la plataforma YouTube, fue como Nati, madre de uno de los alumnos, propuso conjuntamente con la maestra de grado, el armado de una plataforma para que el alumnado pueda compartir dichos videos, teniendo en cuenta algunos puntos:

• No subir el material en una plataforma cuyo objetivo es la monetización de contenido
• Evitar técnicas de ludificación que destaquen cierto contenido sobre otro
• Permitir a la institución ser la efectiva dueña de sus datos, entendiendo que para ello se debe tener control de todo el ciclo de vida de la información, incluso de su destrucción
• Los cuentos estarán accesibles tanto de forma audiovisual (en diferentes resoluciones para permitir su consumo desde diversos dispositivos y con acceso limitado a internet) como así también solamente en audio (para aquellas familias que no cuenten con una conexión estable, y solamente puedan descargar audio)
• Se debe permitir la incrustación de subtítulos
• Se debe permitir realizar comentarios sobre los videos

Tecnologías utilizadas

Teniendo en cuenta los puntos de la sección Motivación, se armó una plataforma utilizando herramientas de Código Abierto, ya que quienes estamos colaborando en la creación de la misma la misma creemos en las libertades que garantiza el Software Libre:

1. La libertad de usar el programa, con cualquier propósito (uso)
2. La libertad de estudiar cómo funciona el programa y modificarlo, adaptándolo a las propias necesidades (estudio)
3. La libertad de distribuir copias del programa, con lo cual se puede ayudar a otros usuarios (distribución)
4. La libertad de mejorar el programa y hacer públicas esas mejoras a los demás, de modo que la comunidad se beneficie (mejora)

Requerimientos Software

A tal efecto utilizamos para dicho proyecto:

• Sistema Operativo: GNU/Linux
• Orquestación de contenedores: k3s
• Plataforma de video: PeerTube
• Sistema de Base de Datos: PostgreSQL
• Cache: Redis

Requerimientos Infraestructura

A nivel hardware, se necesita un servidor con 2 CPU Cores (1 CPU se dedicará a hacer transcode), 2 GB de RAM, y espacio de almacenamiento para los videos (esto determinará cuántos videos se podrán subir a la plataforma).

Según lo reportado en la página de PeerTube, la operación de la plataforma realiza el siguiente consumo:

CPU –> nginx ~ 20%, peertube ~ 10%, postgres ~ 1%, redis ~ 3% RAM –> nginx ~ 6MB, peertube ~ 120MB, postgres ~ 10MB, redis ~ 5MB

También se necesita contar con un dominio válido a fin de poder disponibilizar el sitio mediante una URL, y un certificado SSL para validar dicho dominio. El mecanismo de obtención y renovación de dicho certificado se automatizará utilizando cert-manager y letsencrypt.

Arquitectura

To add our repo to your helm, just type:

    helm repo add jinetes https://jsl3.gitlab.io/helmrepo

To add a new chart, add it like a git submodule.

Charts available

PeerTube

Peertube is an ActivityPub-federated video streaming platform using P2P directly in your web browser https://joinpeertube.org/

helm install jinetes/peertube

For customization see the chart at our Repository.

Writefreely

WriteFreely is free and open source software for building a writing space on the web — whether a publication, internal blog, or writing community in the fediverse.