OpenShift v3 – Ansible

Ansible es un motor de automatización IT radicalmente sencillo que automatiza el aprovisionamiento cloud, gestión de configuraciones, despliegue de aplicaciones, orquestación intra-servicios y muchas otras necesidades IT.

Diseñada para despliegues multi-capas desde el primer día, Ansible modela la infrastructura IT, describiendo cómo todos los sistemas se inter-relacionan, en lugar de gestionar un sistema cada vez.

No usa agentes ni infrastructuras de seguridad personalizadas, así que es simple de desplegar; y lo más importante, hace uso de un lenguaje sencillo, YAML, en la forma de Ansible Playbooks, que permiten describir los trabajos de automatización en una manera que se aproxima al Inglés.

Esta información está extraída de la documentación oficial de Ansible. Para más detalles docs.ansible.com.

Un poco de Ansible

Ansible es una herramienta que utiliza, principalmente, una conexión SSH entre el host Manager, el único host que tiene ansible instalado, y los host gestionados, para realizar las operaciones de despliegue y mantenimiento. Dispone de unos serie de módulos que definen la tarea y los diversos atributos que componen la tarea. Para minimizar los comandos a ejecutar se escriben unas “recetas” llamadas playbooks que definen las tareas. Al principio de cada playbook encontramos una serie de opciones que definirán cómo y dónde se realizarán las tareas. Estos playbooks se escriben utilizando el lenguaje YAML (acrónimo recursivo de”YAML Ain’t Another Markup Language”). Una de las características de Ansible es que es “idempotente”, lo que quiere decir que si una tarea ya ha sido realizada y se vuelve a lanzar el playbook, éste no modificará nada puesto que la tarea ya se ha ejecutado.

Otro elemento que necesita ansible es un fichero de inventario. Este fichero se encarga de definir los equipos que participarán en la ejecución de ansible, separarlos en grupos, etc… Por defecto, Ansible utiliza el fichero inventario que se encuentra en /etc/ansible/hosts

Podríamos tomar este ejemplo de inventario que crearé en /tmp/inventory:

[master]
master.osc.test

[nodes]
node-1.osc.test
node-2.osc.test

[all:children]
master
nodes

Tras ello podríamos utilizar el módulo ping que conectará con los host indicados, verificará que puede establecer la conexión y que python está disponible, si todo es correcto retornará un pong

[root@master tmp]# ansible -i inventory all -m ping
master.osc.test | SUCCESS => {
 "changed": false, 
 "ping": "pong"
}
node-1.osc.test | SUCCESS => {
 "changed": false, 
 "ping": "pong"
}
node-2.osc.test | SUCCESS => {
 "changed": false, 
 "ping": "pong"
}
[root@master tmp]# ansible -i inventory nodes -m ping
node-1.osc.test | SUCCESS => {
 "changed": false, 
 "ping": "pong"
}
node-2.osc.test | SUCCESS => {
 "changed": false, 
 "ping": "pong"
}

Ansible dispone de muchos módulos que podemos utilizar para realizar diferentes tareas. El módulo yum para gestionar paquetes en sistemas Red Hat y derivados, hostname para modificar el hostname de los sistemas o, por ejemplo, lineinfile que se asegura que exista una determinada línea en un fichero. Pero hay muchísimos más, incluso pueden crearse módulos a medida. Más información en la documentación de Ansible.

Preparando NFS para el registro interno

Para que podamos usar el registro interno de manera persistente, lo que voy a hacer es montar en Master un servidor NFS que exporte el segundo disco.

Lo primero será instalar el servidor NFS

 

yum install -y nfs-utils

Ahora crearé la partición en el segundo disco y la montaré en /exports/registry

 

cat <<EOF |fdisk /dev/vdb
n
p
1


w
EOF
mkdir -p /exports/registry
chown nfsnobody:nfsnobody /exports/registry
chmod 0770 /exports/registry
mkfs.ext4 /dev/vdb1
echo -e "/dev/vdb1\t/exports/registry\text4\tdefaults\t1\t2">>/etc/fstab
mount -a
cat <<EOF>/etc/exports
/exports/registry 127.0.0.1(rw,sync)
EOF
systemctl start nfs-server
systemctl enable nfs-server

 

Instalando OpenShift

Para hacer más fácil su instalación OpenShift emplea Ansible. Dispone de una serie de roles (agrupaciones de tareas) que serán definidos por los diferentes playbooks que vienen preconfigurados. Dichos playbooks hacen uso de un fichero inventario que crearemos con los hosts sobre los que vamos a instalar OpenShift, así como una serie de opciones que configurarán el proceso de instalación.

Pues entonces nuestro primer paso para instalar OpenShift es crear nuestro fichero de inventario. Podemos editar el fichero por defecto de Ansible /etc/ansible/hosts o podemos crear el nuestro propio y apuntar a él. Esa será la opción que yo emplearé.

# Create an OSEv3 group that contains the masters and nodes groups
[OSEv3:children]
masters
nodes

# Set variables common for all OSEv3 hosts
[OSEv3:vars]
# SSH user, this user should allow ssh based auth without requiring a password
ansible_ssh_user=root

# OpenShift deployment type origin or enterprise
deployment_type=origin

# OpenShift applications subdomain
openshift_master_default_subdomain=apps.osc.test

# OpenShift persistent registry over NFS
openshift_hosted_registry_storage_kind=nfs
openshift_hosted_registry_storage_access_modes=['ReadWriteMany']
openshift_hosted_registry_storage_host=127.0.0.1
openshift_hosted_registry_storage_nfs_directory=/exports
openshift_hosted_registry_storage_volume_name=registry
openshift_hosted_registry_storage_volume_size=8Gi

# host group for masters
[masters]
master.osc.test

# host group for nodes, includes region info
[nodes]
master.osc.test openshift_node_labels="{'region': 'infra', 'zone': 'default'}" openshift_schedulable=True
node-1.osc.test openshift_node_labels="{'region': 'primary', 'zone': 'default'}"
node-2.osc.test openshift_node_labels="{'region': 'primary', 'zone': 'default'}"

La sección [OSEv3:children] es una agrupación de los bloques [masters] y [nodes], que, a su vez, continen los hosts relevantes a la arquitectura de OpenShift. La sección [OSEv3:vars] contine las variables que ansible convertirá en los diferentes playbooks que correspondan; he añadido una variable openshift_master_default_subdomain para establecer el valor que será empleado por el “router” que se creará en Master para redirigir las peticiones a las aplicaciones correspondientes. Además he incluido variables para configurar el registro interno con almacenamiento persistente. He marcado Master con la opción openshift_schedulable=True para poder desplegar de manera automática el router y el registro interno, cuando esté instalado marcaremos el Master como no schedulable. Por defecto cualquier nodo en el grupo [master] es marcado para que no se puedan desplegar pods en ellos. No es necesario que el master esté dentro del grupo [nodes], pero si queremos que pueda acceder a la SDN (Software Designed Network) de los pods, debería incluirse.

Hay ejemplos de configuración de inventario disponibles en openshift-ansible/inventory/byo.

 

Allá vamos

ansible-playbook -i openshift-inventory openshift-ansible/playbooks/byo/config.yml

Después de un rato de instalación acabaremos viendo algo así:

PLAY RECAP *********************************************************************
localhost : ok=12 changed=6 unreachable=0 failed=0 
master.osc.test : ok=414 changed=73 unreachable=0 failed=0 
node-1.osc.test : ok=144 changed=26 unreachable=0 failed=0 
node-2.osc.test : ok=144 changed=27 unreachable=0 failed=0 

Ahora verificamos que los pods del router y del registro interno están en ejecución

[root@master ~]# oc get pods
NAME                     READY    STATUS    RESTARTS    AGE
docker-registry-2-44zl6  1/1      Running   0           17m
router-1-t46tk           1/1      Running   0           17m

 

Marcamos Master como no programable

oadm manage-node master.osc.test --schedulable=false

Verificamos que están todos los nodos funcionales

oc get nodes

Y si aparecen los tres nodos, ya tenemos nuestro cluster de OpenShift listo para jugar con él.

 

En el próximo post veremos los clientes de línea de comandos, sus comandos más comunes, los ficheros de configuración del master y los nodos, y configuraremos el acceso a la consola Web. Nos vemos.

 

Tutorial OpenShift v3 – Parte 3