Hoy en día es obligatorio usar un gestor de contraseñas. En mi caso, uso Bitwarden (la edición Personal).
Como cada vez paso más tiempo en la línea de comandos, he decido probar la versión CLI de Bitwarden.
Photo by Mabel Amber
Hoy en día es obligatorio usar un gestor de contraseñas. En mi caso, uso Bitwarden (la edición Personal).
Como cada vez paso más tiempo en la línea de comandos, he decido probar la versión CLI de Bitwarden.
Terraform almacena el estado de la configuración en un fichero. Este fichero es crítico para que Terraform pueda mantener la coherencia entre el estado definido en los ficheros de configuración y el estado real de la infraestructura desplegada.
Por defecto, Terraform almacena el estado de forma local; para facilitar la colaboración entre diferentes miembros de un equipo -entre otros casos de uso-, Terraform ofrece la posibilidad de usar otras ubicaciones para guardar el estado. Estas ubicaciones reciben el nombre de backends en Terraform (y hay unos cuantos disponibles, como puedes observar desplegando la entrada Available Backends en la web de Terraform).
Una opción habitual es la de usar un bucket en un servicio como S3 de AWS como remote backend. Pero si no tienes acceso a una cuenta de AWS, puedes usar MinIO para trabajar con un backend de tipo S3 de forma completamente offline (por ejemplo, para aprender cómo funciona Terraform ;-D )
He estado buscando información sobre cuál es la manera correcta a la hora de definir los nombres de las variables en Bash… Y como en el caso de la eterna batalla entre espacios vs tabs o Vim vs Emacs, parece que no hay una solución definitiva (o seguida por todo el mundo de forma generalizada).
Las variables de entorno se definen para cada usuario; por tanto, para mi usuario xavi
, puedo configurar la variable https_proxy
mediante:
Revisando el feed del foro de Kubernetes discuss.kubernetes.io, me llamó la atención la pregunta de user2
Why deployment need replicaset, but daemonset and statefulset don’t need.
Respondí en el foro, pero quiero ampliar la respuesta aquí.
Oh My Zsh es un framework para gestionar la configuración de Zsh.
Zsh es un shell alternativo a BASH, el shell por defecto de la mayoría de distribuciones Linux. Sin embargo, desde Mac OS Catalina, Zsh se convirtió en el shell del terminal de los Mac. Este hecho, junto a la vistosidad de los temas que pueden aplicarse al prompt en Zsh (en especial, gracias a Oh My Zsh), ha convertido Zsh en un shell cada vez más popular.
Update : Joe Block ha sido tan amable de incluir mi tema de Oh My Zsh en la lista que mantiene en GitHub unixorn/awesome-zsh-plugins.
Longhorn es una solución de almacenamiento distribuido de bloques para Kubernetes. Recientemente ha sido incluido en la incubadora de la CNCF.
Longhorn proporciona métricas para Prometheus y es el complemento perfecto para proporcionar almacenamiento a las aplicaciones desplegadas sobre Kubernetes.
En esta entrada automatizamos las instrucciones oficiales de despliegue usando Helm para desplegarlo sobre Kubernetes.
k3sup es una herramienta que permite instalar clústers de Kubernetes basados en K3s en menos de un minuto. Pero acabo de descubrir que además, también permite actualizar el clúster.
El script automatiza el proceso completo de creación de un usuario en Kubernetes. Como el proceso es algo diferente en K3s, esta entrada se centra más en este caso especial.
En Kubernetes no existe el concepto de usuario; sólo se confía en quien presente un certificado firmado por la CA del clúster.
Para obtener los certificados de la CA, lo más sencillo es acceder a un nodo server; los certificados (ca.cert
y ca.key
) se encuentran en /etc/kubernetes/pki/
.
Existe otra opción que pasa por generar un objeto
CertificateSigningRequest
para firmar el certificado de usuario.
El proceso implica generar un certificado al usuario, solicitar que lo firme la Certificate Authority del clúster y después autenticarse con él.
Para poder autenticarse en el clúster, necesitamos configurar un cliente, por ejemplo creando un fichero kubeconfig
para kubectl.
Finalmente, el nuevo usuario debe estar autorizado a realizar algunas acciones en el clúster; para ello definiremos un conjunto de permisos en un Role o un ClusterRole y lo asociaremos al usuario mediante un RoleBinding (o un ClusterRoleBinding).