Monta tu propio cluster Kubernetes

Llevo los últimos meses intentando aprender Kubernetes después de que la experiencia con Docker fuese tan satisfactoria en todos los aspectos. No obstante con Kubernetes caía una y otra vez en los problemas de la complejidad inherente a una plataforma tan adaptada para los pasos a producción de grandes aplicaciones. Muchos de los tutoriales (incluyendo los propios de kubernetes) te instaban a instalarte minikube o usar algunos playgrounds disponibles online como Katacoda o Play with kubernetes. Al final lo que era evidente es que necesitaba un cluster k8s para poder aprender un poco más de kubernetes.

Minikube tiene importantes restricciones y los otro playground son de usar y tirar, por lo que, al final, si quería aprender de verdad tenía que construirme mi propio cluster… Y ahora mismo no me apetece pagar por tener algo puramente experimental, así que aproveché y, dado que tengo dos sobremesa en casa, decidí instalar el cluster en mis propios ordenadores y poder disfrutar de toda la potencia de kubernetes. Aquí un resumen muy resumido de lo que hay que hacer en ubuntu 18.04 (que es lo que tenía en los dos):

Primer paso: instalar docker

Eso creo que ya lo hemos tratado aquí en algunas ocasiones, no obstante ha mejorado mucho la forma de instalarlo desde entonces (en todas las máquinas):

sudo apt install docker.io
sudo systemctl enable docker
sudo addgroup docker ${USER}

Paso 2: instalar kubernetes

Igualmente en todos los nodos:

curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add
sudo apt-add-repository "deb http://apt.kubernetes.io/ kubernetes-xenial main"
sudo apt-get install kubeadm kubelet kubectl
sudo apt-mark hold kubeadm kubelet kubectl

Si todo ha ido bien podemos ver la versión que hemos instalado:

kubeadm version

Paso 3: inicializar cluster

Para inicializar el cluster primero debemos asignar un nombre a cada nodo, además, previamente tendremos que desactivar el swap que no se lleva bien con este sistema, primero con el master y luego con el resto:

sudo swapoff -a
sudo hostnamectl set-hostname master-node

Y luego en el resto:

sudo hostnamectl set-hostname worker01

Con todos los nodos ya con nombre podemos inicializar en el maestro el cluster:

sudo kubeadm init --pod-network-cidr=10.244.0.0/16

Como resultado (y si todo va bien) el comando nos devolverá el comando a ejecutar en cada uno de los nodos, algo así como:

kubeadm join --discovery-token abcdef.1234567890abcdef --discovery-token-ca-cert-hash sha256:1234..cdef 1.2.3.4:6443

Debemos guardar ese comando ya que lo tendremos que ejecutar posteriormente en cualquier nodo que queramos unir al cluster

Para poder administrar con kubectl necesitamos guardar la configuración que acabamos de generar en el usuario que estemos usando… Dentro del master es sencillo:

kubernetes-master:~$ mkdir -p $HOME/.kube
kubernetes-master:~$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
kubernetes-master:~$ sudo chown $(id -u):$(id -g) $HOME/.kube/config

Con esto ya podremos lanzar nuestros comandos kubectl contra nuestro nuevo cluster

Paso 4: Desplegar red en el cluster

Tal como está configurado ahora mismo no hay forma de comunicarse entre los pods y el resto, vamos a instalar flannel como red virtual, para ello ejecutar:

sudo kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

Al cabo de un rato podremos ver si los pods están correctamente desplegados con:

kubectl get pods --all-namespaces

Paso 5: añadir nodos a la red

Como ya dijimos en el paso 3, tenemos un comando a ejecutar en cada nodo de la red para unirse al cluster que acabamos de crear. Ejecutamos ese comando en cada uno de los nodos que queremos unir y luego, dentro del master, podemos comprobar si están presentes todos los nodos y el estado en que están:

kubectl get nodes
NAME STATUS ROLES AGE VERSION
master-node Ready master 3d17h v1.18.5
worker01 Ready 3d17h v1.18.5
worker02 Ready 2d22h v1.18.5
worker03 Ready 2d17h v1.18.5

Si todos están en estado Ready hemos triunfado… Listos para desplegar lo que queramos en nuestro cluster casero… A ver si nos da tiempo a explorarlo con cierta extensión.

Variables de entorno y docker

Después de un tiempo definiendo distintos contenedores docker y coordinando despliegues con docker compose me he encontrado con circunstancias que me obligaban a modificar los archivos de definición cada vez que necesitaba hacer un nuevo despliegue o paso a producción y eso, bueno, eso es un poco molesto. Así que sabiendo que la gente que ha desarrollado todo esto era más lista que yo me puse a buscar cómo proponen que lo hagamos.

Y la respuesta es… Mediante varibles de entorno (al menos una de ellas), así que vamos a ver cómo podemos, como ejercicio, poner el número de versión de nuestro despliegue como varible de entorno..

Uno de mis docker-composes tenía este aspecto:

    web-php:
        container_name: web-php
        build: .
        image: nexus.biblioetech.com/biblioeteca/nomorepass:1.0.0
        ports:
            - "80:80"
        environment: 
            DBHOST: "db"
        links:
            - "web-mysql:db"

Como véis el número de versión acompañaba al nombre de la imagen y esto es así para que al construirla ya llevase la etiqueta adecuada para subirla al repositorio privado. El problema era que cada vez que hacíamos una release nueva teníamos que tocar este archivo a mano… Si queremos no tener que tocar el archivo tenemos que poner algo así:

    web-php:
        container_name: web-php
        build: .
        image: nexus.biblioetech.com/biblioeteca/nomorepass:${VERSION}
        ports:
            - "80:80"
        environment: 
            DBHOST: "db"
        links:
            - "web-mysql:db"

De esta forma solo hay que definir la varible de entorno VERSION al valor que acabamos de generar. Ahora bien, es fácil que nos olvidemos de asignar esta variable de entorno si no está en ningún sitio del repositorio, así que lo más sencillo es incluirla en un archivo .env que será el que docker-compose cargue antes de ejectuar el build… Y quedaría así:

VERSION=1.0.0

En este archivo podemos incluir todas las variables que necesitemos y, lo que es más, podremos pasarselas al Dockerfile si lo necesitamos, eso si, el método es un poco más rebuscado (eso lo veremos un poco más adelante).

Mover el directorio docker en ubuntu

Usar docker es sencillo y rápido, pero, como todo, tienes que tener cuidado con todo lo que ocupa espacio ya que los discos y las particiones son finitas… Y los contendores docker ocupan espacio (bastante), así que aquí dejo el método para mover el directorio de datos de la partición por defecto a otra cualquiera que queramos y para la que tengamos espacio de sobra.

Docker y ubuntu

Lo primero que hay que saber es que el directorio por defecto donde docker guarda sus imágenes, contenedores y demás cosas que ocupan espacio es:

/var/lib/docker

Que, generalmente, está en la partición raiz (o la que tengamos para var) que no suele ser muy grande. Supongamos que queremos moverla a un disco de datos con capacidad suficiente como este:

/mnt/disks/data/docker

Para ello lo que tendremos que hacer es: parar el servicio docker

sudo service docker stop

Crear un archivo llamado daemon.json en el directorio /etc/docker con este contenido:

{ 
   "graph": "/path/to/your/docker" 
}

Copiamos el directorio original al nuevo y lo renombramos por seguridad (ya lo borraremos después)

sudo rsync -aP /var/lib/docker/ /path/to/your/docker
sudo mv /var/lib/docker /var/lib/docker.old

Reiniciamos el servicio docker y todo debería estar como antes del cambio (podéis comprobar con un docker ps si se ha levantado todo lo que teníais funcionando antes).

sudo service docker start

Después de comprobar que todo está ok, ya podemos borrar el original y habremos terminado con la operación del todo:

sudo rm -rf /var/lib/docker.old

Montar un wordpress con docker

Si, esta es una receta muy sencilla y muy rápida. Quizá no sea perfecta, pero en caso de que quieras montar un servidor wordpress sin preocuparte de instalaciones y milongas, este es el método.

Voy a suponer que ya sabes lo que es docker y docker-compose, es más, voy a dar por hecho que los tienes instalados en el servidor donde quieres instalar wordpress, si eso no es así vete disparado a google y búscalo (me lo agradecerás).

Vamos a hacer una instalación donde la base de datos y los archivos de wordpress estén en directorios de la misma máquina y no dentro del contenedor, de manera que podamos reiniciar y actualizar los contenedores preservando los datos. Para ello creamos una estructura haciendo algo similar a esto (pongo como se hace en linux):

mkdir wordpress
cd wordpress
mkdir db
mkdir archivos
mkdir docker
cd docker

Ahora viene lo bueno, creamos dentro del directorio docker el archivo docker-compose.yml con este contenido:

version: '2'
services:
  db:
    image: mysql:5.7
    volumes:
      - "../db:/var/lib/mysql"
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: wordpress
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wordpress
      MYSQL_PASSWORD: wordpress

  wordpress:
    depends_on:
      - db
    image: wordpress:latest
    links:
      - db
    ports:
      - "80:80"
    volumes:
      - ../archivos:/var/www/html
    restart: always
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_PASSWORD: wordpress

Y con esto ya tenemos todo el pescado vendido. Nos metemos en el directorio docker (donde está el docker-compose.yml) y ejecutamos:

docker-compose up -d

Puedes comprobar que todo está funcionando en cualquier momento con el comando docker ps

CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                 NAMES
 18b4c06458b7        wordpress:latest    "docker-entrypoint.s…"   36 seconds ago      Up 32 seconds       0.0.0.0:80->80/tcp    docker_wordpress_1
 211c0832d549        mysql:5.7           "docker-entrypoint.s…"   39 seconds ago      Up 35 seconds       3306/tcp, 33060/tcp   docker_db_1

Ahora, para instalar, de verdad, el wordpress debemos conectar a http://localhost y podremos comenzar la instalación:

Y después de poner todos los datos tendremos un wordpress funcional en el puerto 80, con el añadido de que para realizar un backup solo tenemos que parar los contenedores y copiar los directorios db y archivos (o llevárnoslos a otro servidor).

Hay muchas mejoras que hacer si queremos que esto esté listo para producción como, por ejemplo, hacer que vaya por https (para eso lo mejor es poner un proxy inverso), pero ya lo veremos un poco más adelante. Por ahora, si queréis parar los servicios solo tenéis que ejecutar, desde el directorio docker la instrucción:

docker-compose stop

Y, lo bueno, es que tu máquina no ha sufrido ningún cambio de configuración ni ha instalado ningún paquete de más… Todo ventajas.

Protege tu .git

Hasta hace poco en mi empresa utilizábamos subversion como repositorio, no somos un equipo grande y las funcionalidades que nos ofrecía el repositorio eran suficiente para nuestros proyectos.
Recientemente, debido a que un cliente nos ha impuesto utilizar git como repositorio principal y dado que nuestra relación con ellos es muy importante, decidimos mover todos nuestros repositorios a git. Tampoco es que vayamos a utilizar extensivamente las ventajas que nos ofrece, pero si que nos obligaría a funcionar de manera más fluida con una herramienta que vamos a necesitar si-o-si.

El caso es que, en nuestra anterior configuración, utilizábamos subversion para mantener el código de producción de algunas webs y al modificar el repositorio hicimos lo propio con git, teniendo una «feliz transición». El problema vino en que, realmente, no eramos conscientes de las diferencias reales que tenían los dos repositorios y dentro de los directorios servidos junto a la web en cuestión se encontraba el directorio .git.

¿Qué significa esto? Pues ni más ni menos que todo el mundo mundial tiene acceso a tu repositorio local y puede, entre otras cosas, acceder a todo el código de lo que hay allí publicado… Y eso no puede ser. ¿Qué hacemos para evitarlo?

Hay varias formas de hacerlo, dependiendo de si tienes o no un .htaccess en tu web o no y de la configuración de tu servidor, en mi caso la solución que implementamos fue añadir las siguientes líneas al archivo de configuración de cada web:

        <Directory /directorio.de.la.web/.git>
		Options FollowSymLinks
		AllowOverride All
		Require all denied
	</Directory>

Esto indica al servidor que todo lo que hay bajo el directorio .git no está autorizado para ser visto… Reiniciamos el servidor o recargamos la configuración y ya tendremos el problema resuelto.

Y con esto y un bizcocho… Podemos empezar nuestra semana.