Al hacer limpieza de uno de los clústers de desarrollo, he borrado dos namespaces y los dos se han quedado en estado Terminating
Eliminar namespace encallado en Terminating
- post
- Xavi Aznar
Photo by Mabel Amber
Al hacer limpieza de uno de los clústers de desarrollo, he borrado dos namespaces y los dos se han quedado en estado Terminating
En la entrada anterior KubeLinter: identifica malas configuraciones en los objetos de Kubernetes, KubeLinter identificaba dos errores que se solucionan usando las opciones: runAsUser y readOnlyRootFilesystem.
En esta entrada comparo los efectos de aplicar una u otra, así como qué pasa cuando se aplican las dos al mismo tiempo.
KubeLinter es un linter para los objetos de Kubernetes; es decir, KubeLinter comprueba configuraciones sospechosas en los ficheros de definición de los objetos de Kubernetes.
En la documentación oficial tienes una lista de las validaciones que realiza y cuáles vienen habilitadas por defecto: KubeLinter checks.
KubeLinter es una herramienta opensource desarrollada por StackRox, una empresa orientada a la seguridad que recientemente ha sido adquirida por Red Hat, precisamente, para mejorar la seguridad de OpenShift.
Las buenas prácticas (por ejemplo Version Control Best Practices) relacionadas con el control de versiones usando Git indican que hay que guardar (commit) los cambios de forma frecuente, conteniendo únicamente pequeños cambios.
Sin embargo, el desarrollo no se produce de una forma lineal, de principio a fin; a veces, lo que parece una buena idea que funciona al principio, más adelante es necesario cambiarla o modificarla…
Si guardamos todos los commits, la historia del repositorio quedará llena de estos cambios de dirección durante el desarrollo. Por este motivo, una de las opciones que tenemos es la de reescribir la historia del repositorio antes de, por ejemplo, hacer merge de la rama de feaure sobre la rama principal.
En este artículo vemos cómo conseguirlo usando git rebase.
Ya hace casi dos meses de la última entrada en el blog; en esta entrada explico en qué he estado trabajando y qué me ha mantenido apartado de la publicación en el blog.
Estos días he encontrado un extraño error a la hora de instalar MkDocs, pero por lo que parece, no es un problema específico ni de MkDocs ni de Alpine…
A continuación de la entrada anterior, Multi-stage builds con Docker, la idea es explicar cómo usar una imagen base de un registro diferente a Docker Hub, que es el registro por defecto para Docker.
Los multi-stage builds son una funcionalidad introducida en Docker en la versión 17.05 que proporciona importantes ventajas respecto a los builds “todo-en-uno”, principalmente en cuanto a seguridad y tamaño de la imagen resultante.
Uno de los problemas de los entornos de laboratorio es que son fungibles, casi de “usar y tirar”. Un efecto colateral es que cosas como las credenciales no se gestionan correctamente, se pone la primera que se nos ocurre y después… pues no hay manera de volver a acceder.
En mi caso me he encontrado en esta situación con Gitea y en esta entrada voy a documentar cómo establecer una nueva contraseña para el usuario administrador.
Para poder conectar a una máquina virtual conectada a la red mediante NAT (o NAT Service) es necesario habilitar port-forwarding.
En esta entrada indico cómo habilitar port-forwarding.