Hoy hablamos de seccomProfile, (acrónimo elegido de Secure Computing), que implementa parte de la seguridad  de los procesos Linux, para filtrar las llamadas al sistema de los contenedores en función de las reglas definidas. Se introdujo en la versión v1.19 a través de la definición de los securityContext, desactivado por defecto para dar compatibilidad a versiones anteriores.

Los tipos de profiles disponibles son:

• Unconfined (por defecto): seccomp desactivado.
• RuntimeDefault: seccomp activado con opciones por defecto.
• Localhost: seccomp en modo local indicando el path a utilizar <kubelet-root-dir>/seccomp en kubelet.

En esta tercera parte de nuestra serie sobre la alta disponibilidad en PostgreSQL con Patroni, vamos a ver cómo configurar un servicio de HAproxy para acceder al cluster de Patroni y a obtener más información sobre su API y patronictl.

Si no has visto la primera y la segunda parte de esta serie, te recomendamos que lo hagas para ver por qué estamos utilizando Patroni, y cómo hemos configurado el servicio.

Al finalizar el anterior artículo ya contábamos con un cluster funcional de Patroni, pero para conectar al servicio, lo teníamos que hacer nodo a nodo. Esto no es funcional ya que en caso de fallo de alguno de los nodos, deberíamos elegir el nuevo leader para conectar.

En el anterior artículo de esta serie, describimos nuestra solución de Patroni con etcd y haproxy para desplegar un servicio de PostgreSQL en alta disponibilidad.

Ha llegado el momento de configurar los servicios planificados. En este artículo configuraremos todo lo relacionado con el cluster de PostgreSQL y, en el próximo, finalizaremos con la configuración de HAproxy para acceder al cluster de forma transparente.

PostgreSQL es el segundo sistema de gestión de base de datos más popular y el más querido por los desarrolladores según la encuesta anual de StackOverflow en 2022. Además está muy vinculado con el desarrollo en python.

En este artículo vamos a configurar un cluster de PostgreSQL con alta disponibilidad.

Para contar con alta disponibilidad en un sistema de base de datos son necesarios dos puntos: replicación entre instancias y un failover automático.

En su momento, cuando comenzamos a trabajar con Ansible como una de nuestras herramientas principales para la gestión de los sistemas y configuraciones de nuestros clientes, también implementamos el uso de repositorios para contener esta información. Así, nuestro equipo podría trabajar de forma dinámica con Ansible teniendo un control de versiones de los diferentes cambios que se iban realizando.

A pesar de ello, una parte importante de la información con la que trabajamos en nuestro día a día es delicada, ya sean contraseñas, certificados o ficheros con datos sensibles, y no podrían tratarse de cualquier forma.

A todos nos ha pasado que levantamos un pod y, cuando revisamos su estado en el dashboard de Kubernetes, vemos que tanto el liveness probe como el readiness probe están fallando:

Y ahora, ¿qué?

Esta semana hemos cerrado definitivamente nuestra tercera, y de momento, última oficina. Un espacio que tenía más de punto de encuentro social, que de lugar de trabajo.

Antes de fundar STR Sistemas, estuvimos trabajando para una empresa cuya directiva nos permitió conocer las bondades y ventajas del teletrabajo puntual. Nos quedábamos en casa todos los viernes, los días intermedios entre festivos, o si un día alguien tenía una necesidad personal.

Como fruto de aquella experiencia, en STR fuimos pioneros, sin saberlo, de lo que hoy conocemos como cultura de trabajo remoto. 

No es ningún secreto que en nuestro día a día trabajamos con Ansible e intentamos automatizar el 100% de todos los sistemas. Dentro de nuestra metodología, en muchas ocasiones, utilizamos listas para invocar reiteradamente una tarea, un role, etc.