mcgrof.kdevops_vagrant

kdevops_vagrant

kdevops_vagrant est un rôle Ansible qui déploie un fichier Vagrant partagé par la communauté dans votre projet. Ce rôle Ansible copie le fichier Vagrant dans le répertoire de votre projet et peut également exécuter Vagrant pour vous.

L'objectif de ce rôle Ansible est de permettre le partage d'un même fichier Vagrant scalable facilement entre les projets, et d'offrir un espace pour que les contributeurs puissent l'améliorer et le documenter.

Répertoire de projet

Le répertoire de projet est le répertoire principal de votre projet, qui le définit. Par exemple, si vous avez un projet de développement appelé kdevops et que tous les fichiers sont stockés sous :

/home/user/devel/kdevops/

Dans ce cas, le répertoire de projet est kdevops. Par défaut, ce rôle Ansible déduit quel est votre répertoire de projet en utilisant le nom de base du répertoire où se trouve votre fichier playbook qui appelle ce rôle. Par exemple, si votre fichier playbook est stocké sous :

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

Vous pouvez remplacer des données dans un autre fichier :

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

Le répertoire où se trouve votre fichier playbook est :

/home/user/devel/kdevops/playbooks/

Le nom de base de ce répertoire est :

/home/user/devel/kdevops/

Ceci serait le répertoire de projet déduit pour ce projet. Vous pouvez le remplacer en utilisant la variable de rôle force_project_dir décrite ci-dessous.

Namespace de projet

Le namespace de projet est utilisé dans le Vagrantfile géré par ce rôle pour vous permettre de remplacer les valeurs par défaut utilisées par Vagrant via des variables d'environnement. Le namespace de projet est déduit du répertoire de projet décrit ci-dessus. Par exemple, dans le cas où le répertoire de projet est :

/home/user/devel/kdevops/

Le namespace de projet est déduit comme étant kdevops. La version en majuscules de cela est utilisée comme préfixe pour les variables d'environnement, donc KDEVOPS. Les tirets sont remplacés par des underscores car les variables shell ne peuvent pas contenir de tirets. Ainsi, si le répertoire de projet était :

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

Le namespace de projet serait : SOME_COOL_PROJECT

Exigences

Vous devez avoir Vagrant installé.

Vagrant est utilisé pour déployer facilement des machines virtuelles non-cloud. Voici la liste des fournisseurs supportés :

Virtualbox
libvirt (KVM)

Les systèmes d'exploitation suivants sont supportés :

OS X
Linux

Exécuter libvirt en tant qu'utilisateur régulier

Nous utilisons le rôle Ansible libvirt-user pour activer un utilisateur régulier. Lisez la documentation à ce sujet pour plus de détails.

Remplacer la configuration des nœuds avec un autre fichier

La meilleure façon de prendre en charge le remplacement des variables utilisées dans Vagrant est à travers le fichier $(project)_node_override.yaml. Par exemple, pour le projet kdevops, vous pouvez remplacer des données dans un autre fichier optionnel situé en dehors de git :

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

Variables d'environnement

Seulement si l'utilisation d'un fichier de remplacement ne fonctionne pas, vous pouvez utiliser des variables d'environnement. L'utilisation de variables d'environnement se fait au cas par cas, étant donné que nous devons mettre en œuvre un support pour chaque nouvelle variable ajoutée. En utilisant le fichier de remplacement, vous pouvez tout remplacer, dès qu'une nouvelle fonctionnalité est ajoutée.

Les variables d'environnement sont préfixées par la version en majuscules du namespace de projet, comme décrit ci-dessus. Appelons cela ${PN_U}. En tenant compte de ce préfixe, les variables d'environnement suivantes modifient le fonctionnement du Vagrantfile :

${PN_U}_VAGRANT_NODE_CONFIG: vous permet de remplacer le fichier de configuration par défaut utilisé
${PN_U}_VAGRANT_PROVIDER: vous permet de remplacer le fournisseur utilisé par Vagrant
${PN_U}_VAGRANT_LIMIT_BOXES: vous permet d'activer la limitation des boîtes
${PN_U}_VAGRANT_LIMIT_NUM_BOXES: nombre de boîtes à limiter
${PN_U}_VAGRANT_QEMU_GROUP: remplace l'utilisateur QEMU à utiliser

Limiter le nombre de boîtes de Vagrant

Par défaut, Vagrant essaiera de créer tous les nœuds spécifiés dans votre fichier de configuration des nœuds. En général, cela se trouve dans ${PN_L}_nodes.yml où $PN_L est la version en minuscules de votre namespace de projet. Par exemple, pour le projet kdevops, cela serait kdevops_nodes.yml.

Par exemple, si vous voulez limiter Vagrant à créer seulement une boîte pour le projet kdevops, vous utiliseriez :

export KDEVOPS_VAGRANT_LIMIT_BOXES="yes"
export KDEVOPS_VAGRANT_LIMIT_NUM_BOXES=1

Vous utiliseriez évidemment un préfixe différent pour des projets portant des noms différents.

Cela garantira que seule la première machine, par exemple, sera créée et provisionnée. Cela peut être utile si vous développez sur un ordinateur portable, par exemple, et que vous souhaitez limiter la quantité de ressources utilisées.

Portée d'utilisation d'Ansible

kdevops dans son ensemble est conçu pour être indépendant de la façon dont vous configurez un système, que ce soit un système local virtualisé avec libvirt / Virtualbox, un système bare metal, ou un environnement cloud.

Pour cela, il y a 3 étapes pour le déploiement :

Déploiement : virtuel / cloud / bare metal
Configuration et installation des dépendances : ajouter les systèmes à ~/.ssh/config, et installer les scripts bash, .gitconfig et les packages de développement de choix. Cela est géré par les rôles Ansible update_ssh_config_vagrant et devconfig.
Procéder : faites votre travail, et cela est maintenant généralement encouragé par Ansible.

Notre utilisation de Vagrant avec Ansible est limitée aux deux premières parties mentionnées ci-dessus. Ainsi, nous utilisons Ansible uniquement pour utiliser les deux rôles Ansible suivants :

Nous ne souhaitons pas étendre cette pratique, car nous voulons que les utilisateurs utilisent Ansible directement pour les objectifs ultérieurs. Le travail de déploiement et de configuration, d'installation des dépendances des développeurs doit être géré soit par Vagrant, Terraform, ou l'utilisateur qui configure manuellement les systèmes bare metal.

Pour cette raison, nous ne recommandons pas d'ajouter plus de rôles Ansible pour l'utilisation de Vagrant. Ces deux rôles devraient suffire pour les configurations typiques, et le reste de l'utilisation d'Ansible doit se faire manuellement.

Interpréteur Python d'Ansible

Ansible dépend de Python sur les systèmes distants. Quelle version de Python doit être utilisée peut varier, mais par défaut Ansible essaiera d'utiliser une ancienne version de l'interpréteur Python, afin d'aider à supporter les anciens systèmes. Cette décision n'est pas la meilleure pour les nouveaux systèmes ; il est donc recommandé de spécifier l'interpréteur. Cela doit être fait dans le fichier d'inventaire. Le Vagrantfile suppose que vous avez un fichier d'inventaire appelé ../hosts, vous pouvez cependant le remplacer dans la configuration d'Ansible comme suit :

ansible_playbooks:
  # Si ce fichier existe, vous pouvez remplacer n'importe quelle variable Ansible là-dedans.
  # Ce fichier est optionnel.
  extra_vars: "../extra_vars.yml"
  inventory: "../hosts"
  playbooks:
    - name: "../playbooks/update_ssh_config_vagrant.yml"
    - name: "../playbooks/devconfig.yml"

Votre fichier d'hôtes peut ressembler à quelque chose comme ceci :

[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"

Dans ce cas, tous les systèmes du groupe [all] utilisent l'interpréteur Python 3, mais la dernière entrée garantit que l'ancien système utilise Python 2 à la place.

Utilisation des variables supplémentaires d'Ansible avec Vagrant

Ansible a sa propre hiérarchie de priorité pour les variables, que ce soit à travers la ligne de commande ou les fichiers de rôle, etc., et cela est documenté sur la page de documentation des variables des playbooks d'Ansible.

Bien que cela convienne à la plupart des cas d'utilisation, cela ne vraiment pas aider les projets qui souhaitent permettre aux utilisateurs de spécifier leurs propres variations par rapport aux valeurs par défaut dans un fichier non présent dans le contrôle de version, et sans avoir à les développer sur la ligne de commande.

Étant donné que kdevops consiste en un ensemble unifié de rôles Ansible, nous soutenons une manière unifiée de définir les remplacements pour Ansible. Nous faisons cela en permettant à l'utilisateur de remplacer les variables Ansible dans le répertoire racine du projet dans un fichier appelé :

extra_vars.yml

Ainsi, dans l'exemple du projet kdevops, cela serait :

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

Lorsque ce fichier est défini, le plugin Ansible Vagrant s'assure que seul ce fichier est transmis directement à Ansible sur la ligne de commande via --extra-vars=@file. Le préfixe @ est requis lors de la spécification d'un fichier. Vous n'avez pas à fournir le @, nous le faisons pour vous.

Tous les rôles Ansible utilisés avec kdevops prennent en charge la recherche de ce fichier extra_vars.

Variables des rôles Ansible

run_vagrant: par défaut, c'est False, si c'est mis à True, nous exécuterons Vagrant pour vous
force_project_dir: si défini, cela sera utilisé comme le répertoire où nous rechercherons le répertoire Vagrant et éventuellement copier le Vagrantfile. Par défaut, c'est vide, et nous déduisons votre répertoire de projet comme étant le répertoire parent où se trouvait le fichier playbook.

Dépendances

Aucune.

Exemple de Playbook

Voici un exemple de playbook, utilisé dans le projet kdevops, donc dans le fichier kdevops/playbooks/kdevops_vagrant.yml :

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

Dans ce cas particulier, notez la façon dont localhost est utilisé. Cela est dû au fait que nous provisionnons le Vagrantfile dans le répertoire kdevops/vagrant/ localement. Vous pourriez évidemment utiliser un hôte différent.