Por Mickaël D., experto en DevOps

El Paris Containers Day es un evento organizado por Wescale y Publicis Sapient (antes Xebia) desde 2016 y centrado en los contenedores y la orquestación. El evento finalmente se celebró en línea, al igual que otras conferencias como AWS Re:Invent, a pesar de que en un principio estaba previsto que se celebrara de forma presencial.

Además, a diferencia de las ediciones anteriores, que se celebraban en un solo día, esta se celebra a lo largo de dos tardes.

¿Qué conclusiones podemos sacar de este ciclo de conferencias? 

Que haya pocas inscripciones no es precisamente el objetivo que persiguen Wescale/Publicis Sapient y los distintos ponentes. Sin embargo, se han recibido numerosos comentarios sobre «temas» como los entornos de ejecución de contenedores, la seguridad aplicada a Kubernetes, Cloud Run o el desarrollo de complementos para Kubernetes.

1. Detección y respuesta ante amenazas en Kubernetes con Falco

Presentado por Thomas Labarussias, ingeniero de fiabilidad del sitio en Qonto, colaborador de Falco y creador de FalcoSidekick. 

El objetivo de esta sesión es explicar el funcionamiento de Falco, un proyecto relacionado con la seguridad de los entornos de ejecución y la detección de amenazas en Kubernetes, así como presentar FalcoSidekick y su funcionamiento. 

Falco es un agente de detección de comportamientos «exóticos» en tiempo de ejecución creado por Sysdig, que captura en tiempo real los registros, tanto del núcleo como de los contenedores o de Kubernetes. 

Mediante un motor de reglas relativamente sencillo (se trata de instrucciones en formato YAML) y configurable, Falco activa alertas en función del contenido de los registros capturados. Además, incluye más de un centenar de reglas predefinidas. 

Dado que la arquitectura predeterminada de Falco solo prevé cinco tipos de salidas diferentes (stdout, file, gRPC, shell y HTTP), FalcoSidekick permite ampliar estas posibilidades añadiendo además una interfaz de usuario.

No dudes en echar un vistazo a la página web oficial.

2. CloudRun: un producto gestionado de Google Cloud compatible con Knative

Presentado por Guillaume Blaquière, arquitecto de la nube en Sfeir. 

CloudRun es una solución sin servidor para el alojamiento de contenedores, a diferencia de Cloud Functions o App Engine, que están más orientadas al código fuente, lo que permite una mayor portabilidad. 

Entre las características de CloudRun se incluyen una escalabilidad automática basada en el número de solicitudes que debe procesar el contenedor, así como un modo gestionado basado en Knative y la posibilidad de aprovechar la potencia de Anthos en los clústeres de CloudRun. 

También ofrece demostraciones de Knative en AWS/EKS, GCP/GKE, en GCP/HKE + el complemento CloudRun y, por último, un CloudRun gestionado.

Más información en

• [CloudRun]
• [Knative]
• [Anthos]

3. Y por unos cuantos tiempos de ejecución más...

Presentado por Thomas Gérardin, Cloud Builder en Wescale

Esta ponencia comienza con una reseña histórica de la contenedorización: desde 1979, con Chroot, hasta la actualidad, con los distintos entornos de ejecución y la aparición de un estándar (Container Runtime Interface, CRI) propuesto por la OCI (Open Container Initiative).

A continuación se incluye una lista y algunos datos sobre diferentes entornos de ejecución: 

• **Docker**, que se basa en el entorno de ejecución **containerd**, 
• **containerd**, que a su vez se basa en **runc**, 
• **runc** o **crun**, que son entornos de ejecución de bajo nivel (cercanos al núcleo y escritos en Go y C, respectivamente), 
• **rkt** (cuyo proyecto se suspendió en febrero de 2020), 
• **cri-o**, que gestiona numerosas funciones, entre ellas las imágenes, la seguridad, las métricas, el sistema de archivos, etc. 
• **Kata-container**, que emprende un nuevo camino: el de las microvmáquinas virtuales (que hacen hincapié en un aislamiento más profundo). 

Nos recuerda que los entornos de ejecución ofrecen diferentes funcionalidades según su nivel y su «proximidad» al núcleo, y describe un ejemplo de pila con un orquestador de contenedores vinculado a uno o varios entornos de ejecución de contenedores (en función de las funcionalidades que se busquen).

Más información en:

• [Docker]
• [containerd]
• [runc]
• [cri-o]
• [kata-container]

4. Los contenedores reconvertidos

Presentado por Emmanuel Pluot y Olivier Cloirec, ingeniero de fiabilidad del sitio en Publicis Sapient.

Esta conferencia aborda temas muy variados, tales como: 

Builder: se centra en el lenguaje C++ y en la compilación durante la *compilación* de la imagen del contenedor. 

Intérprete: experiencia con el lenguaje Groovy durante la *compilación* del contenedor. El principio es bastante similar: se genera un ejecutable con el fin de probar un caso práctico, 

nsenter: piratear la máquina host robando los espacios de nombres de un proceso del host mediante el PID de un proceso. Esto parece una vulnerabilidad de seguridad y puede mitigarse mediante un controlador de acceso, 

LogForwarder: cómo redirigir los registros a la salida **stdout** utilizando **Fluentbit**, 

X11 / IDE: Redirigir e iniciar una aplicación gráfica en un contenedor.

La presentación se centra principalmente en Visual Studio Code, pero, a juzgar por los paquetes instalados, se puede instalar cualquier aplicación gráfica. Esta aplicación de las funciones relacionadas con los contenedores es una de las menos conocidas y menos útiles.

5.    Crear y distribuir un complemento para Kubernetes

Presentado por Aurélie Vache —desarrolladora de aplicaciones en la nube en StackLabs— y Gaëlle Acas —ingeniera de fiabilidad de sistemas en StackLabs—.

Aurelie Vache, ya muy conocida por su labor de divulgación sobre Kubernetes y el ecosistema de contenedores en general, comenzó explicando el principio de **kubectl** y su funcionamiento *ultrasencillo*. Sin embargo, dado que la incorporación de complementos está vinculada al núcleo de **Kubernetes**, el ciclo de *lanzamiento* puede ser relativamente largo.

Sin embargo, la parte más larga de la intervención está relacionada con la creación del complemento, que se divide en: 

• En primer lugar, crea un archivo llamado *kubectl-myplugin*, 
• Hacerlo ejecutable, 
• Añádelo a la **PATH** (por ejemplo, /usr/local/bin), 
• Ejecuta el complemento. 

Todo ello con lenguajes relativamente fáciles de usar, como Python, Bash, Go, Rust o Quarkus (con los que podemos programar una interfaz de línea de comandos).

Una vez desarrollado y probado el complemento, queda por empaquetarlo, y es ahí donde entra en escena Krew, el gestor de paquetes de complementos para Kubernetes.

Más información sobre Krew

6. Contenedores dentro de contenedores (marítimos)

Presentado por Guilhem Lettron, ingeniero de fiabilidad de sitios web autónomo, y Barthelemy Vessemont, jefe de Infraestructura en Storelift.

El objetivo de la presentación es crear una tienda autónoma sin cajas registradoras utilizando contenedores marítimos, gestionando la heterogeneidad de diversos aspectos, como el hardware (Raspberry, Arduino, GPU para el aprendizaje automático) y el software en contenedores.

Además, gracias al uso de numerosos marcos de trabajo de visión artificial, es perfectamente posible realizar un seguimiento de los clientes dentro de las tiendas.

Con ese fin, se organizaron de la siguiente manera: 

- Creación de contenedores: imágenes de entre diez y doce gigabytes de tamaño que contienen todos los marcos de trabajo necesarios y se dividen en tres etapas. Además, gracias al uso de Docker-in-Docker, la carga de trabajo en los servidores es mucho más configurable y supone un menor impacto económico (sobre todo en el caso del uso de la nube, donde las instancias disponen de recursos bastante importantes). 

- En cuanto a la parte física, fue más complicado, ya que la decisión técnica inicial fue utilizar máquinas Raspberry.

La pila final, más allá de Kubernetes, reúne numerosas tecnologías, tales como:

• Observabilidad: Thanos, Prometheus, Fluentd, Fluentbit y cAdvisor,
• Red: Tras probar ROS, Flannel y otras opciones, finalmente se decidieron por Host-Network debido a ciertas limitaciones técnicas de los complementos CNI mencionados,
• Implementación: Empezaron probando Ansible y acabaron optando por Kubernetes por su carácter modular

Más información sobre Boxy

7. K3S, la versión ligera de Kubernetes, crea mis imágenes sin Docker

Presentado por Romain Boulanger, ingeniero de nube en Sfeir

Nos presenta el caso práctico ideal de un cliente que desea migrar sus aplicaciones a Kubernetes utilizando sus propios servidores, sin descuidar la seguridad.

Creado por Rancher (que ya trabaja en el conocido orquestador de clústeres Kubernetes), K3S es una versión de Kubernetes simplificada, que se instala muy rápidamente y se presenta como un simple ejecutable, y... se recomienda para todo lo relacionado con el IoT, la integración continua o las arquitecturas RAM.

K3S se presenta como una versión «aligerada», ya que las siguientes funcionalidades difieren de las de Kubernetes:

• Legacy, alpha, no predeterminado y los complementos,
• Uso de sqlite3,
• Gestión automática de TLS,
• Pocas dependencias
• No hay ningún puerto que exponer para la API.

Además, Docker (al igual que ETCD) es opcional.

Más información sobre K3S

Puedes ver las sesiones de la edición de 2021 del Paris Container Day (así como las anteriores) aquí: Paris Container Day - YouTube