Currently viewing the category: "Virtualización"

Hace unos días vimos como desplegar un clúster de Kubernetes con el sistema operativo CoreOS en Amazon Web Services (AWS).

El despliegue lo hicimos con la herramienta kube-aws que nos facilita la tarea. Igualmente eso no nos impide a conectarnos por SSH a las instancias desplegadas y poder ver configuraciones o ajustar parámetros, etc.

En el archivo cluster.yaml configuramos el parámetro:

Esta clave será una de las que tenemos creadas en EC2 y será la que nos va a permitir conectarnos por SSH, bastará con hacerlo con la clave privada, usuario ‘core‘ y la IP pública:

 

Generalmente los contenedores Docker se usan para arrancar servicios como Nginx, Apache, PHP-FPM, Redis, etc. Estos servicios se basan en entornos Alpine Linux, Debian u otros.

Cuando el contenedor arrancar con un servicio, su PID será el 1, pero si queremos realizar pruebas con un Debian pelado sin servicios.
¿Como vamos a arrancarlo sin que se nos pare el contenedor Docker?

Muy fácil, vamos a arrancar un contenedor Docker de la imagen base de Debian, lanzando un terminal bash como proceso principal.

Ahora podemos ver como el PID número 1 corresponde a un terminal bash, pero si entramos dentro del contenedor vamos a abrir un bash independiente, con lo cual si salimos y entramos no se detendrá el contenedor al no finalizar el PID 1. Nuestro bash dentro del contenedor para trabajar y realizar pruebas será el que tiene PID 7.

 

El binario kubectl nos permite trabajar con un clúster de Kubernetes, ver PODs, RCs, SVC, crearlos, eliminarlos, ver logs u otras tareas.

Por otro lado solo nos permite trabajar con un clúster a la vez, es decir si queremos trabajar con otro clúster debemos cambiar de contexto.

Podemos ver las configuraciones con el propio binario o también en nuestro home:  ~/.kube/config

En este instante, el clúster de trabajo actual lo podemos ver reflejado aquí:

Y ahora cambiamos el clúster de trabajo actual para kubectl con el siguiente comando:

 

Este tema me ha llevado bastante quebraderos de cabeza y hoy voy a explicar qué pasa y como recibir en la cabecera HTTP el X-Forwarded-For.

El objetivo es obtener la IP real del cliente origen cuando tenemos un LoadBalancer de Google Cloud en su Kubernetes con Container Engine. Ya que sino es así todos los logs de Apache/Nginx del backend van a registrar la IP interna del LoadBalancer y no tendremos la IP real del cliente, haciendo imposible por ejemplo la generación de estadísticas reales de visitas.

Cuando levantamos un Service (SVC) de Kubernetes lo hacemos de la siguiente manera:

El «type: LoadBalancer» va aprovisionar un LoadBalancer de la plataforma de GCP directamente a nuestro ReplicationController asignado con el «selector».

Este LoadBalancer va a ser del tipo TCP y ese será el motivo real por el cual no vayamos a recibir la cabecera X-Forwarded-For.

Esto no sucede igual en AWS, que quizás por defecto levantan un LoadBalancer HTTP así que en GCP hay que hacerlo de otro modo.

Así que el objetivo será levantar un LoadBalancer HTTP de la plataforma de GCP, eso lo haremos con Ingress de Kubernetes.

Vamos a modificar nuestro SVC actual cambiando el «type: LoadBalancer» por «type: NodePort«, aplicamos las nuevas configuraciones.

Ahora ya tenemos un SVC nginx-back que va a ser únicamente accesible desde dentro del clúster de Kubernetes. No tendremos visibilidad desde el exterior.

Para ello vamos a crear un Ingress que va aprovisionar un LoadBalancer HTTP en GCP. Vamos a crear un YAML nuevo:  vi nginx-back-ing.yaml

Ahora debemos tener un poco de paciencia para que se aprovisione correctamente el LoadBalancer HTTP e ir observando los cambios.

Hasta que la línea «backends» de la sección «Annotations» no aparezca como HEALTHY no será 100% funcional nuestro LoadBalancer HTTP en GCP con Ingress de Kubernetes.

 

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.

 

Vamos a hacer lo mismo que en la entrada de augmentar el tamaño de un disco duro virtual VDI en Windows, pero esta vez para un Linux, mas concretamente un Debian.

El primer paso es igual, con VBoxManage hacemos un augmento del disco VDI. Pasamos de 15G a 20G.

Ahora hay que redimensionar la partición de datos, para ello vamos a usar el software GParted y lo podemos encontrar en la Live CD Knoppix. Entramos en modo gráfico con: knoppix64 lang=es

La tabla de particiones de la máquina virtual Debian es la siguiente:

Dado que los datos están en la partición 1, y no se puede redimensionar puesto que la partición 2 empieza donde termina la 1, el procedimiento será:

  • Desactivar la swap, partición 5, ya que Knoppix nos la montará y no permite eliminarla sin desmontarla.
  • Eliminar la partición 5 de la swap.
  • Eliminar la partición 2 extendida.
  • Redimensionar la partición 1, al tamaño máximo menos 1G para la swap.
  • Creamos una nueva partición primária con todo el tamaño restante (1G) para la swap.
  • Formateamos la nueva partición swap.
  • Aplicamos todos los cambios.
  • Una vez terminado reiniciamos y arrancamos con la máquina virtual Debian.

Adjunto las capturas de pantalla del procedimiento de redimensionado explicado antes paso a paso.

Gparted1 Gparted2 Gparted3 Gparted4 Gparted5 Gparted6 Gparted8 Gparted9 Gparted10

Por último, dado que hemos eliminado la partición swap, hace falta reconfigurarla en la máquina virtual Debian, ya que el UUID de la partición ha cambiado y si hacemos un free -m veremos que no hay swap.

 

Si queremos augmentar el tamaño de un disco virtual VDI en una máquina VirtualBox se hace de la siguiente manera, partiendo de un disco de 50G. El ejemplo está realizado con un Windows 7.

DiscoVDIWindows

Ahora desde consola con el VBoxManage vamos a incrementar el disco hasta 60G (+10G).

Una vez incrementado el espacio con VBoxManager, en la gestión de discos de máquinas virtuales nos aparece que ya es de 60G.

DiscoVDIWindows60

No obstante desde Mi Equipo de Windows el tamaño del disco sigue siguiendo de 50G. Eso sucede porqué hay que redimensionar la partición, ya que hasta este punto tenemos 10G mas de tamaño libre sin particionar. Se puede añadir a la partición C: de datos o crear una nueva partición.

Para añadir los 10G extras a la partición C: de datos haremos lo siguiente:

  • Abrimos Inicio y buscamos: Crear y formatear particiones del disco duro.
  • Veremos un espacio en negro de 10G extras con una etiqueta de No asignado.
  • Botón derecho sobre la partición C: y opción: Extender volumen…
  • Y el siguiente asistente ya nos ofrece añadir el tamaño máximo libre: Siguiente – Siguiente – Finalizar
  • Punto y final, ya tenemos nuestro disco virtual VDI en Windows incrementado.