kdevops_vagrant

kdevops_vagrant es un rol de Ansible que despliega un archivo Vagrant compartido por la comunidad en tu proyecto. Este rol de Ansible copia el directorio Vagrantfile del espacio de nombres del proyecto y puede, opcionalmente, ejecutar Vagrant por ti.

El objetivo de este rol de Ansible es permitir la capacidad de compartir el mismo Vagrantfile escalable fácilmente entre proyectos, y le da a Vagrantfile un hogar para que los colaboradores puedan mejorarlo y documentarlo.

Directorio del espacio de nombres del proyecto

El directorio del espacio de nombres del proyecto es el directorio de nivel superior de tu proyecto, que define tu proyecto. Por ejemplo, supongamos que tienes un proyecto de desarrollo llamado kdevops, y tienes todos los archivos guardados en:

/home/user/devel/kdevops/

En este caso, el directorio del espacio de nombres del proyecto es kdevops. Por defecto, este rol de Ansible infiere cuál es tu directorio del espacio de nombres del proyecto usando el nombre de base del directorio donde se encuentra tu archivo de playbook que llama a este rol. Por ejemplo, si tu archivo de playbook está almacenado en:

/home/user/devel/kdevops/playbooks/kdevops_vagrant_nodes.yml

Puedes sobreescribir datos en otro archivo:

/home/user/devel/kdevops/playbooks/kdevops_vagrant_nodes_override.yaml

El directorio donde se almacena tu archivo de playbook es:

/home/user/devel/kdevops/playbooks/

El nombre de base de ese directorio es:

/home/user/devel/kdevops/

Este sería el directorio del espacio de nombres del proyecto inferido para este proyecto. Puedes sobreescribir esto usando la variable de rol force_project_dir que se describe a continuación.

Espacio de nombres del proyecto

El espacio de nombres del proyecto se utiliza dentro del Vagrantfile que lleva este rol para permitirte sobreescribir los valores predeterminados usados para vagrant a través de variables de entorno. El espacio de nombres del proyecto se infiere del directorio del espacio de nombres del proyecto descrito anteriormente. Por ejemplo, en el caso anterior donde el directorio del espacio de nombres del proyecto es:

/home/user/devel/kdevops/

Se infiere que el espacio de nombres del proyecto es kdevops. La versión en mayúsculas de esto se usa como un prefijo para las variables de entorno, por lo que sería KDEVOPS. Los guiones se sustituyen por guiones bajos ya que las variables de shell no pueden contener guiones. Así que si el directorio del espacio de nombres del proyecto fuera:

/home/user/devel/some-cool-project/

El espacio de nombres del proyecto sería: SOME_COOL_PROJECT

Requisitos

Debes tener instalado Vagrant.

Vagrant se utiliza para desplegar fácilmente máquinas virtuales no en la nube. A continuación se presenta la lista de proveedores compatibles:

• Virtualbox
• libvirt (KVM)

Los siguientes sistemas operativos son compatibles:

• OS X
• Linux

Ejecutando libvirt como un usuario regular

Utilizamos el rol de Ansible https://github.com/mcgrof/libvirt-user para habilitar a un usuario regular. Lee la documentación allí para conocer la lógica detrás de eso.

Sobrescribir la configuración del nodo con un archivo diferente

La mejor manera de soportar la sobrescritura de variables usadas en vagrant es a través del archivo $(project)_node_override.yaml. Así que, por ejemplo, para el [https://github.com/mcgrof/kdevops](proyecto kdevops), puedes sobrescribir datos en otro archivo opcional mantenido fuera de git:

/home/user/devel/kdevops/playbooks/kdevops_vagrant_nodes_override.yaml

Variables de entorno

Solo si usar un archivo de sobrescritura no funciona, puedes usar variables de entorno. Pero usar variables de entorno se hace caso por caso, dado que tenemos que implementar soporte para cada nueva variable añadida. Usando el archivo de sobrescritura, puedes sobrescribir cualquier cosa, tan pronto como se añade una nueva característica.

Las variables de entorno están precedidas por la versión en mayúsculas del espacio de nombres del proyecto como se describió anteriormente. Llamaremos a esto ${PN_U}. Teniendo en cuenta este prefijo, las siguientes variables de entorno modifican la forma en que funciona el Vagrantfile:

• ${PN_U}_VAGRANT_NODE_CONFIG: te permite sobrescribir el archivo de configuración predeterminado utilizado.
• ${PN_U}_VAGRANT_PROVIDER: te permite sobrescribir el proveedor utilizado por Vagrant.
• ${PN_U}_VAGRANT_LIMIT_BOXES: te permite habilitar la limitación de cajas.
• ${PN_U}_VAGRANT_LIMIT_NUM_BOXES: número de cajas a limitar.
• ${PN_U}_VAGRANT_QEMU_GROUP: sobrescribe el usuario qemu a usar.

Limitar el número de cajas de Vagrant

Por defecto, Vagrant intentará crear todas las nodos especificados en tu archivo de configuración de nodos. Por defecto, esto es ${PN_L}_nodes.yml, donde $PN_L es la versión en minúsculas de tu espacio de nombres del proyecto descrito anteriormente. Por ejemplo, para el proyecto kdevops sería kdevops_nodes.yml.

Por ejemplo, si deseas limitar a Vagrant a que solo cree una caja en el proyecto kdevops, usarías:

export KDEVOPS_VAGRANT_LIMIT_BOXES="yes"
export KDEVOPS_VAGRANT_LIMIT_NUM_BOXES=1

Obviamente, usarías un prefijo diferente para proyectos con nombres diferentes.

Esto asegurará que solo el primer host, por ejemplo, se cree y se aprovisione. Esto puede ser útil si estás desarrollando en una laptop, por ejemplo, y quieres limitar la cantidad de recursos utilizados.

Ámbito de uso de Ansible

kdevops en su totalidad está diseñado para ser agnóstico a cómo configures un sistema, ya sea un sistema local virtualizado con libvirt / Virtualbox, un sistema de hardware físico o un entorno en la nube.

Debido a esto, hay 3 etapas para poner en marcha:

• Poner en marcha: virtual / nube / hardware.
• Configurar e instalar dependencias: añadir sistemas a ~/.ssh/config, e instalar scripts de bash preferidos del usuario, .gitconfig, y paquetes de desarrollo genéricos de elección. Esto se maneja a través de los http://github.com/mcgrof/update_ssh_config_vagrant y http://github.com/mcgrof/devconfig roles de Ansible.
• Hazlo funcionar: realiza tu trabajo, y esto normalmente se anima ahora a través de Ansible.

Nuestro uso de Vagrant con Ansible está limitado a las dos partes mencionadas anteriormente. Por lo tanto, usamos Ansible solo para usar los dos roles de Ansible:

• http://github.com/mcgrof/update_ssh_config_vagrant
• http://github.com/mcgrof/devconfig

No queremos extender esta práctica, y la razón es que queremos que los usuarios utilicen Ansible directamente para objetivos posteriores. El trabajo detrás de la puesta en marcha y la configuración, la instalación de dependencias de desarrollo debe ser manejado ya sea por Vagrant, Terraform, o el usuario que configuró los sistemas de hardware físico manualmente.

Debido a esto, no animamos a añadir más roles de Ansible para el uso de Vagrant. Estos dos roles deberían ser suficientes para configuraciones típicas, y el resto del uso de Ansible debería hacerse manualmente.

Intérprete de Python de Ansible

Ansible depende de Python en los sistemas remotos. Qué versión de Python se debe usar variará, pero por defecto Ansible intentará usar una versión antigua del intérprete de Python, para ayudar a soportar sistemas más antiguos. Esta decisión no es la mejor para sistemas más nuevos, por lo que se te anima a especificar el intérprete. Esto se debe establecer mejor en el archivo de inventario. El Vagrantfile supone que tienes un archivo de inventario llamado ../hosts, sin embargo, puedes sobreescribir esto en la configuración de Ansible de la siguiente manera:

ansible_playbooks:
  # Si este archivo existe, puedes sobrescribir cualquier variable de ansible allí.
  # Este archivo es opcional.
  extra_vars: "../extra_vars.yml"
  inventory: "../hosts"
  playbooks:
    - name: "../playbooks/update_ssh_config_vagrant.yml"
    - name: "../playbooks/devconfig.yml"

Tu archivo de hosts podría verse así:

[all]
newsystem1
oldsystem1
[all:vars]
ansible_python_interpreter =  "/usr/bin/python3"

[new]
newsystem1
[new:vars]
ansible_python_interpreter =  "/usr/bin/python3"

[old]
oldsystem1
[dev:vars]
ansible_python_interpreter =  "/usr/bin/python2"

En este caso, se establece el intérprete de Python para el grupo [all] a python3, sin embargo, la última entrada garantizará que el sistema antiguo use python2 en su lugar.

Uso de variables extra de Ansible con Vagrant

Ansible tiene su propia jerarquía de cómo las variables tienen prioridad, ya sea a través de la línea de comandos, o archivos de roles, etc., y esto está documentado en la [https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html](documentación de variables de playbooks de Ansible).

Si bien esto puede servir para la mayoría de los usos, realmente no ayuda a los proyectos que desean permitir a los usuarios especificar sus propias variaciones a los valores predeterminados en un archivo que no esté presente en el control de versiones y sin tener que extender la línea de comandos.

Como kdevops consiste en un conjunto unificado de roles de Ansible, apoyamos una forma unificada de definir las sobrescrituras de Ansible. Hacemos esto permitiendo que el usuario sobrescriba las variables de Ansible en el directorio raíz del proyecto en un archivo llamado:

• extra_vars.yml

Entonces, en el ejemplo del proyecto kdevops, esto sería:

/home/user/devel/kdevops/extra_vars.yml

Cuando este archivo está configurado, el complemento de Ansible para Vagrant asegurará que solo se pase el archivo directamente a Ansible en la línea de comandos a través de --extra-vars=@file. El prefijo @ es requerido al especificar un archivo. No necesitas proporcionar el @, lo hacemos por ti.

Todos los roles de Ansible utilizados con kdevops soportan buscar este archivo extra_vars.

Variables de rol de Ansible

• run_vagrant: por defecto es False, si se establece en True ejecutaremos Vagrant por ti.
• force_project_dir: si se establece, se usará como el directorio donde buscaremos el directorio de Vagrant, y eventualmente copiaremos el Vagrantfile. Por defecto, esto se establece en vacío, e inferimos tu directorio de proyecto como el directorio padre donde reside el archivo del playbook.

Dependencias

Ninguna.

Ejemplo de Playbook

A continuación se muestra un ejemplo de playbook, se utiliza en el proyecto kdevops, por lo que se encuentra en el archivo kdevops/playbooks/kdevops_vagrant.yml:

---
- hosts: localhost
  roles:
    - role: kdevops_vagrant

En este caso, nota cómo se utiliza localhost. Esto se debe a que estamos aprovisionando el Vagrantfile en el directorio kdevops/vagrant/ localmente. Obviamente podrías usar un host diferente.

Más información

Para más ejemplos, consulta uno de los usuarios de este rol, el [https://github.com/mcgrof/kdevops](proyecto kdevops) o el [https://github.com/mcgrof/oscheck](proyecto oscheck) de donde provino este código originalmente.

Licencia

GPLv2