Hoy vamos a ver como desplegar un clúster de Kubernetes, con sistema operativo CoreOS (orientado a contenedores Docker) en Amazon Web Services (AWS). Para todo ello vamos a basarnos en la documentación propia de CoreOS para desplegar un clúster de Kubernetes.

Primero necesitamos configurar la API de AWS para poder atacar los servicios con el CLI.

Seguidamente nos hace falta una clave de acceso a la API, la crearemos desde: IAM – Users – admsistemas – Security Credentials – Create Access Key
Guardaremos en un sitio seguro la contraseña, no será posible visualizarla desde la GUI de AWS.

Podemos proceder a configurar nuestras credenciales del CLI.

Continuamos descargando las claves PGP y el binario kube-aws que nos ayudará a desplegar el clúster.

Vamos a descargar el binario kube-aws de aquí: https://github.com/coreos/coreos-kubernetes/releases

Hasta aquí los preparativos iniciales, acceso por API con el CLI y binario kube-aws para el despliegue del clúster Kubernetes.

Para continuar, nos hará falta un par de claves, para conectarnos remotamente a las instáncias que se vayan a crear y además se van a usar para realizar la instalación del Kubernetes una vez el sistema operativo CoreOS este en marcha.

El par de claves las vamos a crear desde la GUI de AWS: EC2 – Network & Security – Key Pairs – Create Key Pair

También hace falta una clave KMS, la vamos a crear desde aquí: IAM – Encryption Keys – {escoger región de trabajo} – Create Key
Deberemos apuntarnos el string ARN de la clave KMS, entrando dentro de la que hayamos creado la vamos a obtener.

Esto nos creará un archivo cluster.yaml con las configuraciones de nuestro clúster de K8S. Podemos modificar los parámetros que queramos.

Ahora vamos a crear el archivo que se utilizará para enviar al CloudFormation de AWS la infraestructura definida en el archivo cluster.yaml.

Validamos que el formato y demás valores sean correctos.

Si todo ha ido bien, podemos levantar el clúster, se realizará mediante el envío de los datos al CloudFormation de AWS.

Si permitimos que se creará el registro DNS automáticamente podremos atacar al clúster directamente, sino habrá que añadir la entrada k8s.administrosistemas.com a la IP asignada al controlador.

Ahora solo hace falta esperar que el despliegue finalice correctamente, sabremos que ha finalizado cuando los nodos estén listos.

Una vez finalizadas las pruebas o si ya no deseamos el clúster de K8S, podemos eliminarlo un simple comando.

 

Hoy vamos a ver como podemos descargar imágenes de Docker que tenemos en el hub.docker.com, pero están en un repositorio privado bajo nuestro control. Si estuvieran en un repositorio público no habría problema, pero al ser privado cambia un poco las cosas.

En caso que fuéramos a levantar un contenedor con Kubernetes desde un repositorio público haríamos algo similar a lo siguiente:

Y ahora para poder descargar imágenes de un repositorio privado, añadiremos un Secret de Kubernetes.

Por último debemos añadir la etiqueta imagePullSecrets en todos los archivos YAML de los PODS que vayamos a desplegar.

El ejemplo anterior quedaría de la siguiente forma:

 

Docker es un excelente software que está moviendo los entornos de desarrollo a su terreno.

Una de las cosas mas utilizadas es el repositorio público hub.docker.com, donde los usuarios contribuyen con sus imágenes personalizadas o también imágenes oficiales de software como PHP, Apache, Nginx, etc…

Hoy vamos a ver como subir una imagen personalizada de PHP con alguna extensión añadida por nosotros.

Es importante primero haber realizado el build en nuestro entorno Docker y guardarlo con el siguiente formato de nombre: [nombre_usuario]/[mi_imagen]:[mi_version]

En esta entrada podéis ver como personalizar una imagen de Docker.

Antes de poder subir una imagen, debemos tener un usuario y un repositorio creado en el hub.docker.com, puede ser público o privado según nos convenga.

En este ejemplo usaremos: admsistemas/custom_php:1.1

Primero de todo, vamos a identificarnos (login) desde nuestro Docker en el hub.docker.com con nuestros datos de acceso. Sin esto no podremos realizar un push de la imagen personalizada.

Ahora debemos buscar cual es nuestra imagen de Docker personalizada, en nuestro caso hemos dicho custom_php.

Por último, dado que coincide el nombre de nuestra imagen personalizada con nuestro usuario y repositorio del hub.docker.com, ya podemos hacer un push y subirla al repositorio.

Una vez finalizado el proceso ya tendremos disponible nuestra imagen personalizada de Docker. Podremos realizar un «docker pull» de nuestra imagen PHP con las extensiones añadidas.

Hoy vamos a ver como Docker nos permite personalizar imágenes y adaptarlas a nuestras necesidades. Por ejemplo vamos a usar la imagen oficial de PHP y añadirle algunas extensiones de PHP extras.

Con todo eso podemos tener nuestros contenedores Docker a nuestro gusto con el software/arquitectura que nosotros deseemos.

Seguidamente adjuntamos un pequeño archivo Dockerfile de ejemplo. Los archivos Dockerfile se usan para personalizar nuestras imágenes. Leer referencias aquí.

Primero creamos un directorio de trabajo:

Aquí añadimos el siguiente contenido al archivo Dockerfile.

Como podemos ver, aparte de algunos pasos básicos e iniciales, al final del todo instalamos 4 extensiones de PHP haciendo uso del binario docker-php-ext-install que ya proporciona la imagen base oficial de PHP. Esta todo explicado en la documentación de la imagen en el hub.docker.com.

Una vez tenemos nuestro Dockerfile personalizado, podemos proceder a realizar el build, a construir nuestra nueva imagen personalizada con todos los cambios indicados en el Dockerfile.

Una vez finalizado el proceso, si todo ha ido bien ya tendremos nuestra imagen personalizada lista para lanzar contenedores con las 4 extensiones de PHP instaladas.

 

Hoy vamos a ver como usar un sistema de archivos (File system) en un clúster de storage distribuido con Ceph. Ya vimos anteriormente los procedimientos para su instalación. También vimos como usar un dispositivo por bloques RBD en Ceph.

Tal como vimos en el procedimiento de instalación, para usar este sistema se requiere un servidor de Metadatos instalado.

Ahora ya podemos crear un nuevo File system. Dependiendo de los OSD indicaremos un valor u otro de pg_num (Placement group), en nuestros ejemplos tenemos 4 OSD, con lo cual usaremos el valor 128.

Ahora ya tenemos un File system creado y nos queda montarlo desde una instancia cliente cualquiera para guardar los datos. Debemos obtener el usuario y clave para autenticarnos.

Ahora ya tenemos un recurso File system de Ceph por red. Seria parecido a un servidor NFS que exporta un directorio. Solo nos queda llenarlo con nuestros archivos y los tendremos almacenados en nuestro clúster de storage distribuido Ceph.

Hoy vamos a ver como usar un dispositivo por bloques (Block device) en un clúster de storage distribuido con Ceph. Ya vimos anteriormente los procedimientos para su instalación.

Para entenderlo fácilmente, un dispositivo por bloques es un disco duro. Pero en este caso vamos a usar un dispositivo por bloques del clúster Ceph distribuido. Todo ello lo haremos desde la instancia cliente preparada a tal efecto, cephcli que vinos en entradas anteriores.

Ya tenemos el dispositivo mapeado en /dev/rbd0.

Podemos ver mejor como es el mapeo por nombres aquí:

Ahora ya podemos formatear y montar el dispositivo por bloques, como si fuera una partición de un disco duro de toda la vida en Linux.

Ahora ya podemos empezar a usar nuestro dispositivo por bloques en el clúster Ceph. Por ejemplo añadiremos un archivo de 1G y vamos a ver qué información podemos ver fácilmente.

Tenemos muchas posibilidades con los dispositivos por bloques RBD. Para mas ayuda utilizar el «man rbd» del comando y «rbd -h«.

Otro ejemplo sencillo seria desmontar el dispositivo por bloques RBD y desmapearlo de la instancia cephcli, veamos como.

Recuerda que también puedes usar el recurso Ceph File system para almacenar datos sin usar un dispositivo por bloques.

Seguimos con la serie de entradas dedicadas al clúster Ceph. Anteriormente vimos una pequeña introducción para preparar el entorno de instalación.

Es importante tener los requisitos de la anterior entrada correctos para realizar una instalación satisfactoria y sin problemas. Empezamos la instalación con el ceph-deploy desde el nodo cephadm.

Ahora ya tenemos los paquetes de Ceph instalados en todos los nodos y el monitorizador preparado. Seguidamente vamos a añadir los discos extras (/dev/sdb) de cada nodo OSD al clúster.

Primero analizaremos los discos que hay en el nodo ceph1 donde veremos que el /dev/sda está particionado y corresponde al sistema operativo y /dev/sdb no contiene particiones y es el disco que vamos a utilizar para el clúster Ceph.

Ya podemos preparar y añadir los discos al clúster de Ceph. Lo haremos desde el nodo cephadm.

Seguimos, vamos a copiar los archivos de configuración en todos los nodos y poner los permisos correctos a la clave privada.

Solo si vamos a usar Ceph Filesystem necesitamos un servidor de Metadatos, para ello lo instalaremos en el mismo servidor de monitorización cephadm.

Solo si vamos a usar Ceph Object Gateway necesitamos un RGW (Radow Geteway), para ello lo instalaremos en el mismo servidor de monitorización cephadm.

Ahora ya podemos ver desde el nodo monitorizador cephadm el estado del clúster.

Por último y en caso de reiniciarse un nodo OSD, añadimos los puntos de montaje en sus /etc/fstab para que al arrancar se vuelvan a conectar el clúster Ceph.

Ya tenemos el clúster de Ceph instalado y preparado para empezar a utilizarse. Veremos en la próxima entrada como empezar a trabajar con los datos del clúster.

Vamos a ver como instalar un clúster de storage distribuido con Ceph. Se trata de una guía para pruebas, jugar con él, familiarizarse y perder el miedo. No pretende ser una guía para sitios en producción de alto rendimiento.

Ceph permite trabajar con tres formatos de storage.

  • Block device: dispositivo por bloques, como tener un disco duro asignado pero distribuido
  • File system: disponer de un punto de montaje como si fuera un recurso NFS
  • Object Storage: almacenamiento de objectos como AWS S3

Vamos a utilizar las siguientes instancias.

cephadm 192.168.8.100 Nodo para hacer el deploy y ser el monitorizador del clúster
ceph1 192.168.8.101 Nodo de datos 1, llamado OSD
ceph2 192.168.8.102 Nodo de datos 2, llamado OSD
ceph3 192.168.8.103 Nodo de datos 3, llamado OSD
ceph4 192.168.8.104 Nodo de datos 4, llamado OSD
cephcli 192.168.8.105 Nodo cliente para acceder al storage proporcionado por el clúste

Destacar que cada nodo OSD, aparte de tener su disco para el sistema operativo, tienen un disco extra que vamos a dedicar al contenido de los datos distribuidos del clúster.

Para empezar, hay que añadir a todos los /etc/hosts de cada nodo la lista de hostnames e IPs para trabajar mas cómodamente. Eso en caso de no tener un servidor DNS interno.

Un detalle muy importante, el hostname del /etc/hosts que vamos a utilizar para realizar el ceph-deploy debe corresponder al hostname real de la instancia. De no ser así vamos a tener problemas con la instalación del clúster Ceph.

Ahora podemos empezar a preparar el entorno para el ceph-deploy. Lo vamos ha realizar en el nodo cephadm.

Seguimos la preparación añadiendo un usuario el cual utilizará el ceph-ceploy para conectarse a los otros nodos y realizar la instalación del clúster Ceph.

Otro detalle muy importante, no vamos a crear el usuario ceph, ya que entraría en conflicto con la instalación y volveríamos a tener problemas.

Vamos a realizar lo mismos pasos en todos los nodos.

Seguimos preparando el entorno para conectarnos remotamente con el ceph-deploy a través de SSH y con permisos de sudo en todos los nodos.

Los siguientes comandos únicamente los añadimos al nodo cephadm.

Ahora para evitar especificar el usuario cephadm en las conexiones SSH del ceph-deploy añadimos lo siguiente en el nodo cephadm.

Ya tenemos todos los nodos preparados y listos para empezar a instalar el clúster Ceph con la herramienta ceph-deploy. Veremos en la próxima entrada como realizar el procedimiento de instalación.

Hace unas semanas estoy empezando a pasar de Gnome a KDE con Kubuntu 16.04., con todos los cambios que supone y variar las costumbres de uso.

Hay muchos diferencias, pero la primera que me he encontrado era no encontrar en las configuraciones el poder visualizar desde el gestor de archivos Dolphin (Nautilus para Gnome) los archivos ocultos, por ejemplo el archivo: .htaccess

Para poder ver los archivos ocultos en Dolphin basta con presionar:  Alt + .  (punto)

Anteriormente vimos como realizar un backup o clonar un disco/dispositivo con “dd” al completo en Linux. Ahora toca hablar sobre como recuperar ese backup .img del disco, también con la herramienta dd de Linux.

Arrancamos el servidor donde queremos recuperar el backup de la imagen con la Live CD Knoppix. Lo haremos con las opciones cuando nos pida el boot: knoppix64 2 lang=es

Cuando tengamos la Knoppix en marcha, hay que hacer un par de cosas importantes, arrancar servidor SSH, establecer contraseña al usuario root y buscar la IP para conectarnos con SSH..

Ahora desde el servidor donde tenemos almacenado el backup .img del disco, lo enviamos al servidor con la Live CD Knoppix en marcha, hay que tener claro el dispositivo (/dev/sda) de destino correcto para no cometer errores graves.

Ya podemos iniciar la restauración del backup.

Nota: Recordad que podéis ver progreso de transferencia de datos con el comando “dd” de Linux.

Por último, si volvemos al servidor con la Knoppix, veremos como ahora si hay particiones creadas en el dispositivo /dev/sda