Currently viewing the category: "Software"

La configuración básica de HAProxy permite añadir el listado de usuarios que tendrá acceso al dashboard para ver el estado del servicio, los nodos del backend, estadísticas, etc.

Un ejemplo de configuración básico de usuarios para HAProxy:  vi /etc/haproxy/haproxy.cfg

Siguiendo la documentación propia de HAProxy para la versión 1.5.X, sección 3.4 «Userlists»:
http://www.haproxy.org/download/1.5/doc/configuration.txt

Ahora vamos a cifrar el anterior password con SHA-512.

Ahora cambiamos la configuración del haproxy.cfg fácilmente con:

Por último, no olvidar hacer un reload del servicio HAProxy para aplicar los cambios.

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:

 

Podemos trabajar con el servicio ProFTPD con el modulo mod_sql, para tener usuarios virtuales y obtener las credenciales de una base de datos. Este sistema será válido tanto para FTP como SFTP.

La estructura de las tablas SQL que nos proponen inicialmente no permite tener usuarios dados de alta, pero inactivos a nivel de servicio, sin permitir su autenticación.

Así que haremos unos pequeños cambios, primero modificando la tabla SQL:

Para acabar, debemos tener un archivo sql.conf similar a este:

Y añadiremos la línea SQLUserWhereClause, quedando así:

Ahora ya podemos desactivar cuentas FTP, cuando haga falta únicamente habrá que cambiar el campo LoginAllowed, por ejemplo así:

 

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:

 

Suponemos el caso que tenemos un clúster MariaDB Galera con 3 nodos en la misma infraestructura. Puede darse el caso que haya un problema de electricidad y se detengan todos los nodos de golpe.

Cuando vuelvan a arrancar los nodos, cada nodo intentará sincronizarse con los demás nodos que tampoco estarán levantados y no arrancará nuestro clúster.

En este instante es cuando tenemos que decidir cual es el nodo que ha realizado el último commit (INSERT / UPDATE) y tiene los datos mas actualizados.

Para ello basta con ejecutar el mismo binario en todos los nodos, este se encargará de buscar el número del último commit. De los 3 nodos, el que tenga el número mas alto debe ser el que haga el bootstrap para arrancar el clúster de MariaDB Galera.

El nodo1 es el que tiene el commit mas alto, 26289 y este es el candidato a levantar el clúster en primera instancia.

Bastará con realizar el bootstrap del nodo1 siguiendo estas indicaciones:

Por último, podemos arrancar los otros dos nodos de la forma habitual con systemd.

 

En versiones anteriores de Debian se utilizaba init como gestor de arranque de los procesos, pero a partir de Debian 8 Jessie se ha cambiado por el gestor systemd.

Eso ha hecho que cambiara el método para realizar el bootstrap (inicializar) un clúster de base de datos MariaDB Galera. Es decir, arrancar el primer nodo de una agrupación.

En versiones anteriores de Debian, bastaba con ejecutar en el primer nodo:

Pero con Debian 8 Jessie y la llegada de systemd eso ha dejado de funcionar.

La gente de MariaDB ha añadido un excelente binario que facilita la tarea y fácil de recordar: galera_new_cluster

 

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.