El cajón de Drazul

El lugar donde duerme el pequeño dragón

Pasando De Infraestructura De Testing a Infraestructura De Producción

En la entrada anterior hablé de cómo automatizar la creación y despliegue de nueva infraestructura con Vagrant y Ansible. Esto está muy bien para hacer pruebas rápidas sobre cómo se comporta la infraestructura o para refinar el proeso de creación y despliegue, por lo que son unas herramientas muy útiles para el testing.

En esta entrada hablaré sobre cómo pasar de un entorno de testing Vagrant + Ansible a un entorno de producción en el que sólo utilizamos Ansible.

Todo el mundo debe saber ya que no se deben aplicar cambios no probados en un entorno de producción, por eso es útil el entorno de testing, pero es demasiado caro mantener una infraestructura completa para este propósito, por lo que es habitual utilizar entornos virtuales en testing y físicos en producción (aunque también se utilizan entornos virtuales en producción, con los objetivos principales de consolidación de servidores y aislar servicios).

En mi caso utilizo mi portátil personal para el desarrollo con entornos virtuales Vagrant + Ansible y una vez probado que todo funciona bien paso a producción en el entorno físico.

¿Pero cómo hacer este cambio? Fácil. Ejecutando los playbooks de ansible, ya probados, sobre el entorno de producción.

Los requisitos necesarios en el entorno de producción sobre el que queremos realizar cambios son mínimos y suelen estar ya presentes: * Un servidor ssh.

Debido a estos complicados requisitos se puede utilizar Ansible para realizar cambios en entornos de producción sean máquinas físicas o virtuales sin necesitar para nada a Vagrant.

Recordemos ahora los dos principales archivos que necesita Ansible: * Inventory: archivo donde se especifican las máquinas que tenemos y los grupos a los que pertenecen. * Playbook: archivo YAML en el que se especifican las tareas a realizar

Como ejemplo voy a definir los archivos necesarios con la siguiente configuración:

Archivo inventory:

1
2
[main]
localhost

Archivo playbook.yml:

1
2
3
4
5
6
7
8
---
- hosts: main
  remote_user: drazul
  sudo: yes

  tasks:
    - name: ls
      shell: touch hola

Como podemos ver se defie el rol main con la máquina localhost y el usuario a utilizar drazul. Ya solo queda ejecutar las tareas que define el playbook. Se realiza de la siguiente forma:

1
$ ansible-playbook --inventory inventory --ask-pass --ask-sudo-pass playbook.yml

Como vemos debe recibir como argumentos –ask-pass debido a que la conexión ssh necesita una clave para conectarse. Si tenemos definida una clave ssh entonces no es necesario poner este comando.

El argumento –ask-sudo-pass se debe a que he configurado en el playbook que todas las tareas se ejecuten con permisos de superusuario.

Otros usos de Ansible

Ansible también sirve para ejecutar comandos en todas las máquinas que estén recogidas en el archivo de inventario, por ejemplo para ver de forma rápida el estado de las máquinas.

1
2
3
4
5
6
7
8
$ ansible main -i inventory --user drazul --ask-pass --args "df -h"
SSH password:
localhost | success | rc=0 >>
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda3       126G  7.5G  113G   7% /
udev            3.9G  4.0K  3.9G   1% /dev
tmpfs           783M  1.2M  782M   1% /run
/dev/sda2       317G   31G  271G  11% /home

Comments