Cet article décrit la capacité / idée / concept de modifier les paramètres globaux sur les serveurs de commande locaux dans une grande infrastructure à l'aide de Gitlab CI et Ansible.
Disons que vous avez 20 équipes de développement et 1 équipe admin / DevOps. Comment changer les mots de passe administrateur sur tous les serveurs? Comment ajouter un certificat racine d'entreprise à tous les serveurs? Etc.
Quel problème résout-il?
Situation typique:
Il existe des administrateurs / DevOps mondiaux.
Il existe des paramètres globaux (NTP, DNS, proxy, etc.)
Il existe des équipes de développement locales: TeamA, TeamB, TeamC, TeamD, etc.
Il y a des développeurs qui ne peuvent aller que sur les serveurs de leur équipe.
Comment ajouter / mettre à jour des administrateurs globaux, des paramètres globaux?
La tâche est compliquée par le fait que les paramètres globaux sont stockés séparément des paramètres de commande locaux dans des référentiels privés.
Si vous avez peu de serveurs dans toute l'entreprise, vous pouvez démarrer Ansible dans un mode simple - commencer à mettre à jour les administrateurs globaux et les paramètres globaux sur tous les serveurs à la fois.
Pour les grandes installations, les entreprises utilisent généralement Puppet, Chef.
Concept
Pour modifier les paramètres globaux des serveurs de commande locaux dans une grande infrastructure, je propose un mécanisme de sous-module git.
Le référentiel avec des paramètres locaux utilise des sous-modules git avec des paramètres globaux.
Vous trouverez ci-dessous un diagramme schématique de connexion d'un référentiel privé avec des paramètres globaux à des référentiels de commandes locaux.
Vous pouvez utiliser le concept de mise à jour des paramètres globaux à l'aide du sous-module git dans l'infrastructure avec Puppet, Chef, Salt, mais l'article fournit un exemple avec Ansible.
Par exemple, installez tomcat, mysql, nginx et appliquez-leur des paramètres globaux dans une équipe appelée team.
Il existe un groupe commun dans gitlab qui contient les paramètres généraux.
Dans le groupe commun, il existe un projet d'amorçage de base qui contient des administrateurs, des paramètres sysctl, etc.
Habituellement, dans une entreprise, il existe plusieurs départements de développement - plus souvent, ils sont appelés équipes.
Dans gitlab, créez un groupe d'équipe (vous aurez votre propre nom d'équipe).
Dans le groupe d'équipe, nous créons des projets: application, base de données, équilibreur de charge.
Capture d'écran de base-bootstrap, application, base de données, équilibreur de charge:
Le référentiel base-bootstrap est inclus en tant que sous-module git dans le référentiel d'application, de base de données et d'équilibrage de charge.
Chaque fois que l'application, la base de données et l'équilibreur de charge du référentiel commencent à mettre à jour le sous-module de démarrage de base.
Après cela, ansible-playbook de base-bootstrap et ansible-playbook de base-bootstrap sont appliqués aux serveurs d'applications, de bases de données et d'équilibreurs de charge.
Autrement dit, si vous ajoutez un nouvel administrateur à base-bootstrap ou modifiez les paramètres système dans base-bootstrap, puis avec l'application, la base de données, l'équilibreur de charge, les nouveaux paramètres de base-bootstrap sont appliqués à l'application, la base de données, l'équilibreur de charge.
La préparation
Vous devriez lire des articles sur Ansible pour les débutants:
# Impossible de commencer
# Guide Ansible
Vous devez avoir déployé gitlab et gitlab-runner avec docker installé.
L'exécuteur Docker est utilisé comme exemple ici - vous pouvez utiliser l'exécuteur Shell.
Comment déployer gitlab et gitlab-runner:
# Article de Southbridge Gitlab-CI
# Intégration et déploiement continus de Docker dans GitLab CI
Vous devez avoir 3 serveurs (par exemple, sur ubuntu): application, base de données, équilibreur de charge.
Application, base de données, équilibreur de charge sont des noms courants.
Tous les exemples peuvent être développés, améliorés, utilisés par d'autres logiciels - l'article montre le principe général.
Comment mettre en Ĺ“uvre
Les référentiels et tout le code du test peuvent être récupérés ici: https://github.com/patsevanton/ansible-gitlab-habr
Si vous allez sur le serveur en utilisant le nom d'utilisateur / mot de passe, alors dans le groupe souhaité (dans ce cas, l'équipe) créez la variable userpassword (lorsque vous changez, vous devez également changer la variable dans le code aussi) et spécifiez le mot de passe là (le mot de passe du mot de passe est utilisé dans le code)
N'oubliez pas de créer l'utilisateur nécessaire avec les droits sudo sur les serveurs finaux (le code utilisateur est utilisé dans le code).
Pour ceux qui se rendent sur le serveur à l'aide des clés SSH, vous devez créer la variable SSH_PRIVATE_KEY dans le groupe d'équipe et y ajouter la clé privée de l'utilisateur qui se connectera au serveur.
Il s'agit d'un exemple simple de connexion aux serveurs, les problèmes de sécurité ne sont donc pas traités dans cet article.
Dans chaque référentiel (application, base de données, équilibreur de charge) créez un sous-module git:
git submodule add git@gitlab.example.com:common/base-bootstrap.git git submodule add git@gitlab.example.com:team/team-users.git
Un sous-module est nécessaire pour accéder au référentiel privé partagé.
Dans notre cas, il s'agit du référentiel avec les paramètres généraux de base-bootstrap et du référentiel d'utilisateurs de l'équipe team-users.
OĂą gitlab.example.com est votre serveur gitlab.
Ensuite, dans .gitmodules, nous changeons le chemin d'accès au référentiel en relatif
Un exemple:
[submodule "team-users"] path = team-users url = ../team-users.git [submodule "base-bootstrap"] path = base-bootstrap url = ../../common/base-bootstrap.git
Dans chaque référentiel dans les hôtes, nous changeons l'IP en notre propre, dans ansible.cfg nous changeons remote_user en notre utilisateur.
Si vous n'avez effectué aucune validation au cours des dernières heures / jours et que vous devez déployer de nouvelles modifications générales sur les serveurs (par exemple, vous devez ajouter un nouvel administrateur) - pour de telles situations, il y a une suppression ansible.
Configurez ansible-pull pour télécharger le référentiel common / base-bootstrap.
Pour ce faire, ajoutez le référentiel de jetons de déploiement.
Accédez au référentiel common / base-bootstrap, puis accédez à settings / repository / Deploy Tokens.
Créez un jeton. Le nom d'utilisateur et le mot de passe résultants sont enregistrés dans base-bootstrap / vars / cron.yml.
Après avoir vérifié que tout fonctionne correctement, je pense que cela vaut la peine de changer l'heure de début du tirage ansible de "toutes les 2 minutes" à celle qui vous convient.
Si ansible-pull est tombé, cela signifie que l'IC de ce service va chuter, ce qui démarre chaque fois que vous vous engagez dans ce référentiel de service (disons que le service est appelé application)
VĂ©rifier
Créez un nouvel administrateur.
Essayez d'ajouter un nouvel administrateur Ă https://github.com/patsevanton/ansible-gitlab-habr/blob/master/commons/base-bootstrap/vars/users.yml
Changement de système
Essayez d'ajouter / de modifier les paramètres sysctl dans https://github.com/patsevanton/ansible-gitlab-habr/blob/master/commons/base-bootstrap/vars/sysctl.yml
Ajout d'entrées à cron
Essayez d'ajouter des entrées cron à https://github.com/patsevanton/ansible-gitlab-habr/blob/master/commons/base-bootstrap/vars/cron.yml
Extension ou installation de vos applications
Vous devez d'abord trouver un rĂ´le pour installer vos applications.
Accédez à https://galaxy.ansible.com/ et recherchez le rôle pour installer votre application.
Essayez d'installer votre application en utilisant le rôle à partir de la console sur vos serveurs. En règle générale, tous les rôles ont des instructions dans les descriptions.
Par exemple, essayez d'installer java à côté de tomcat. Installez d'abord le rôle geerlingguy.java
ansible-galaxy install geerlingguy.java
Créez le fichier ansible.cfg standard de la même manière que les référentiels.
Créez un inventaire:
[java] java ansible_host=IP-
Créer un playbook java.yml
- hosts: java become: yes vars_files: - vars/main.yml roles: - { role: geerlingguy.java }
Exécutez ansible-playbook java.yml
Si tout s'est bien passé, ajoutez au projet souhaité (dans ce cas l'application)
Le rôle de geerlingguy.java est ajouté après le rôle de robertdebock.tomcat https://github.com/patsevanton/ansible-gitlab-habr/blob/master/team/application/tomcat-app.yml#L11
Il en va de mĂŞme pour toutes les autres applications que vous devez installer sur le serveur.
Test et sécurité du Playbook
Pour simplifier l'article, le problème du stockage et du test des mots de passe n'est pas résolu.
Il y a des articles sur le test du playbook:
# Ansible: tester les playbooks (partie 1)
# Test et intégration continue pour les rôles Ansible avec Molecule et Jenkins
RĂ©ponses aux questions
1) Mentat: Et pourquoi, après tout, n'est-ce pas ainsi que c'est écrit dans le dock ansible, avec les environnements? Dès la première lecture, cela ressemble à une tentative de tout réinventer. Il est tout à fait pratique d'appliquer tout cela comme ansible-playbook -i env / teamA personalAPlaybook.yml
Réponse: ce schéma permet de modifier les paramètres globaux. Ce qui est décrit dans la question est la modification des paramètres locaux des commandes.
PS La même fonctionnalité est peut-être implémentée dans Ansible Tower. Mais je ne peux rien dire à ce sujet - je n'ai pas travaillé avec Ansible Tower.