|
|
|
- |
|
|
\ No newline at end of file |
|
|
|
# Tabla de contenidos:
|
|
|
|
- [Introducción](#introducción)
|
|
|
|
- [Descargar las dependencias](#descargar-las-dependencias)
|
|
|
|
- [Cambiar versión de un role](#cambiar-versión-de-un-role)
|
|
|
|
- [Nuestra forma de importar roles](#nuestra-forma-de-importar-roles)
|
|
|
|
|
|
|
|
|
|
|
|
## Introducción
|
|
|
|
|
|
|
|
En la entrada [Versionado de roles](versionado-de-roles), se comentaba la dependencia de porciones de código externo, versionado independientemente y a veces desarrollado por terceros (*roles*) que presenta `config` y como llevar su desarrollo paralelamete sin perder funcionalidad.
|
|
|
|
|
|
|
|
Utilizar versionado en los *roles* de acuerdo a un criterio común, permite dar cierto entendimiento semántico y estabilidad al conjunto de proyecto mayor y sus módulos externos. **La idea de fondo en esto es: gestionar las dependencias que tiene el proyecto.**
|
|
|
|
|
|
|
|
En el caso de Ansible contamos con la herramienta `ansible-galaxy` que facilita la descarga y gestión de estas dependencias, siempre y cuando llevemos un listado rigurso y con la información necesaria.
|
|
|
|
|
|
|
|
Además, con `ansible-galaxy` podemos llevar todo un paso mas allá, convirtiendo ese listado en un insumo de código con el que poder automatizar la gestión de dependencias (fuente, versión, ubicación), al fin y al cabo trabajamos sobre el paradigma [IaC](https://en.wikipedia.org/wiki/Infrastructure_as_code). Este listado será confeccionado en el archivo `requirements.yml`, de acuerdo a [esta estructura específica:](https://galaxy.ansible.com/docs/using/installing.html#installing-multiple-roles-from-a-file)
|
|
|
|
|
|
|
|
* **src:** (requerido) La fuente u origen del role. Puede ser en formato `nombre_usuario_organización.nombre_role` desde *galaxy.ansible.com*, o una URL a un repositorio basado en **git**. Este segundo caso nos será de especial interés cuando estemos desarrollando un role en nuestro PC.
|
|
|
|
* **scm:** (opcional) Si el `src` es una URL, especifica el sistema de control de versiones a utilizar. Solo se admiten `git` o `hg`. El valor predeterminado es `git`.
|
|
|
|
* **version:** (opcional) La versión del role a descargar. Puede indicarse un ***tag***, ***hash commit*** o un **nombre de rama**. El valor predeterminado es `master`.
|
|
|
|
* **name:** (opcional) Descarga el role con un nombre específico. El nombre predeterminado será el de Galaxy cuando se descarga desde *galaxy.ansible.com*, o el nombre del repositorio cuando `src` es una URL.
|
|
|
|
|
|
|
|
Ejemplos de `requirements.yml`:
|
|
|
|
```yaml
|
|
|
|
# Desde Galaxy
|
|
|
|
- src: yatesr.timezone
|
|
|
|
|
|
|
|
# Desde GitHub
|
|
|
|
- src: https://github.com/bennojoy/nginx
|
|
|
|
|
|
|
|
# Desde GitHub, especificando versión y nombre
|
|
|
|
- src: https://github.com/bennojoy/nginx
|
|
|
|
version: master
|
|
|
|
name: nginx_role
|
|
|
|
```
|
|
|
|
|
|
|
|
Es **importante destacar** que se puede indicar la versión exacta utilizada al importar un role desde `requirements.yml` con:
|
|
|
|
* **tag** o **commit hash** si se importa desde un repositorio *Git*
|
|
|
|
* **tag** si se importa desde *galaxy.ansible.com*
|
|
|
|
|
|
|
|
En ambos casos también se puede indicar **nombre de rama** pero no será una versión exacta, ya que puede variar a futuro si se agregan commits en esa rama.
|
|
|
|
|
|
|
|
|
|
|
|
## Descargar las dependencias
|
|
|
|
|
|
|
|
Y te preguntarás, **¿cómo es que automatizamos la descarga de las "dependencias" con este archivo?** Bueno, simplemente con ejecutar en un terminal (desde la raíz del proyecto) lo siguiente:
|
|
|
|
```bash
|
|
|
|
$ ansible-galaxy install -r requirements.yml
|
|
|
|
```
|
|
|
|
Durante la ejecución podrás ir viendo los roles que se van descargando y en que versión.
|
|
|
|
|
|
|
|
Este utilitario es idempotente, una vez finalizada la descarga, si volvemos a ejecutar observaremos que se saltean todos los roles ya que se encuentran en la versión deseada.
|
|
|
|
|
|
|
|
Mas arriba se comentaba que la opción de utilizar un repositorio Git como fuente de los roles es de utilidad cuando se está en un entorno de desarrollo. Esto se debe a que agregando la opción `-g` en la ejecución de `ansible-galaxy`, también se estará descargando la metadata del sistema de versionado (el directorio `.git`). Se mentendrán entonces sus referencias al *remoto* y podremos trabajar cada role como un repositorio Git convencional. Pudiendo entonces actualizarlo (`git pull`), realizar aportes (`git commit` y `git push`) y navegar entre diferentes versiones del mismo (`git checkout`).
|
|
|
|
|
|
|
|
|
|
|
|
## Cambiar versión de un role
|
|
|
|
|
|
|
|
Tarde temprano, será necesario utilizar alguna versión más moderna o antigua de un role, sea por nuevas características o por retrocompatibilidad.
|
|
|
|
|
|
|
|
Para hacerlo, y llevar el registro correcto, lo ideal es editar la versión directamente en `requirements.yml` y ejecutar nuevamente `ansible-galaxy install -r requirements.yml`
|
|
|
|
|
|
|
|
**Pero cuidado**, si ese role ya se encontraba descargado, no se efectuarán cambios y en su lugar recibiremos una advertencia de que **será necesario también agregar el *flag* `--force`, con los peligros que esto implica si se estaba trabajando en el desarrollo de algún role. Usando `--force`, se eliminan por completo todos los roles antes de compezar la descarga nuevamente**
|
|
|
|
|
|
|
|
Del mismo modo, si algún compañero agregó nuevos roles al `requirements.yml` y deseas descargarlos con `ansible-galaxy`, puede que recibas algún error/advertencia que interrumpa la ejecución del utilitario; sea porque variaste la versión o estuviste trabajando en el desarrollo de alguno de los roles existentes. La solución práctica a este escenario, para no resignar funcionalidad (ya sabemos el por qué de los errores) es agregar a `ansible-galaxy install -r requirements.yml` el *flag* `--ignore-errors`. Este *flag*, a diferencia de `--force` no representa peligro alguno ya que no escribe absolutamente nada en los roles preexistentes.
|
|
|
|
|
|
|
|
|
|
|
|
## Nuestra forma de importar roles
|
|
|
|
|
|
|
|
Para la realidad del equipo *DevOps*, la forma mas práctica, robusta y consistente de utilizar el `requirements.yml` es **indicar siempre el `src` de *ansible.galaxy.com* y la versión del role que se está recuperando**, en lo posible mediante *tag* (sea un role propio o de terceros).
|
|
|
|
|
|
|
|
**La única excepción a esta regla será el/los role/s sobre el que se esté trabajando en el momento dado, para el que localmente se editará el `src` de la galaxia por el correspondiente al repositorio Git**
|
|
|
|
|
|
|
|
De este modo se garantiza que todos los miembos del equipo estén siempre en una versión consistente de cada role que no se actualizará por error. **Podrá ser actualizada solo usando `--force` a conciencia al ejecutar el utilitario `ansible-galaxy`**
|
|
|
|
|
|
|
|
> En las herramientas DevOps, el *playbook* [`actualizar_roles_github.yml`](https://git.interior.edu.uy/adminsys/config/blob/master/dev_ops/actualizar_roles_github.yml) solo realiza modificaciones sobre roles descargados con `src` desde repositorios Git, por lo tanto no tendrá efecto sobre todos los roles sino solo sobre los que se están desarrollando en el momento (por ello tendrán `src` desde repos Git). |
