Cet article est l'article du 16ème jour du Calendrier de l'Avent Ansible 2019.
Découvrez la marche à suivre pour configurer Ansible Ready pour une machine Linux sans être conscient de l'utilisation d'Ansible.
Il existe une mine d'informations sur la construction de serveurs et de réseaux à l'aide d'Ansible, et je pense qu'il existe un environnement relativement vaste dans lequel vous pouvez exécuter Ansible immédiatement en utilisant cet environnement, mais "dans cet environnement actuel (en particulier sur site)" Je sentais (personnellement) que j'avais peu d'informations sur "comment démarrer avec Ansible", donc je l'ai résumé.
Par conséquent, cet article ne porte pas sur "comment commencer à étudier Ansible" mais "que dois-je préparer lorsque je commence à créer un serveur à l'aide d'Ansible".
――Pour ceux qui veulent étudier Ansible, cliquez ici: [Bienvenue aux débutants] Si vous voulez commencer avec Ansible, rejoignons Ansible Mokumokukai! --Si vous voulez un environnement Ansible qui peut être vérifié immédiatement, cliquez ici: [Construction de VM utilisant Vagrant spécialisé pour l'environnement de vérification Ansible --Ssh paramètre d'authentification par clé publique / dossier partagé entre plusieurs VM / VM](https: // qiita.com/zaki-lknr/items/cdf4eac2d2f2020ac7be)
Il est basé sur CentOS.
nom d'hôte | adresse IP | rôle |
---|---|---|
control-node | 192.168.0.140 | Noeud de contrôle |
target-node01 | 192.168.0.141 | Nœud cible |
target-node02 | 192.168.0.142 | Nœud cible |
L'hôte qui exécute les commandes Ansible (telles que ʻansible et ʻansible-playbook
) est appelé le nœud de contrôle, et l'hôte cible traité par le nœud de contrôle Ansible est appelé le nœud cible.
Ce dont vous avez besoin pour le nœud de contrôle
Ansible
Python
Ce dont vous avez besoin pour le nœud cible
Python
Serveur SSH --Promotion de root par sudo
En outre, dans cet article, il est supposé que le nom d'utilisateur de travail (non root) et le mot de passe d'authentification sont tous les mêmes pour chacun des nœuds de contrôle et des nœuds cibles.
Pour CentOS7, Ansible 2.4 est installé avec le référentiel Yum standard, mais il est un peu trop ancien (le dernier est 2.9 en décembre 2019).
$ yum info ansible
:
:
Forfaits disponibles
Nom: ansible
architecture: noarch
version: 2.4.2.0
Libération: 2.el7
capacité: 7.6 M
Dépôt: extras/7/x86_64
emballer: SSH-based configuration management, deployment, and task
:
:
Par conséquent, dans le cas de CentOS7, il est facile d'installer le package dans le référentiel EPEL.
$ sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
$ sudo yum install ansible
Vous devriez maintenant pouvoir installer le dernier stabilisateur. Pour vérifier la version, exécutez ʻansible --version`.
[zaki@control-node ~]$ ansible --version
ansible 2.9.1
config file = /etc/ansible/ansible.cfg
configured module search path = [u'/home/zaki/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
ansible python module location = /usr/lib/python2.7/site-packages/ansible
executable location = /usr/bin/ansible
python version = 2.7.5 (default, Aug 7 2019, 00:51:29) [GCC 4.8.5 20150623 (Red Hat 4.8.5-39)]
[zaki@control-node ~]$
Pour les autres plates-formes telles que RHEL et Debian / Ubuntu, consultez le guide d'installation d'Ansible (https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html).
Vous pouvez également l'installer en utilisant pip
.
En tant que simple contrôle d'opération après l'installation, essayez d'exécuter le module ping
sur localhost pour vérifier si Ansible peut être exécuté sur la cible.
$ ansible localhost -m ping
localhost | SUCCESS => {
"changed": false,
"ping": "pong"
}
C'est OK si «SUCCESS» est affiché.
ping
qui utilise ICMP, elle vérifie si Ansible peut être exécuté plutôt que de communiquer. De plus, pour localhost
, aucune connexion SSH n'est requisePython
Vous pouvez l'installer avec un gestionnaire de paquets tel que yum
... mais si vous avez une distribution populaire de nos jours, Python devrait être inclus dès le début.
De plus, Python est requis pour les exigences d'installation d'Ansible, donc si Ansible est déjà installé, Python doit déjà être installé.
$ python --version
Vous pouvez vérifier la version Python avec.
Si le serveur SSH est également une distribution majeure, il doit être exécuté immédiatement après l'installation du système d'exploitation. Pour pouvoir utiliser Ansible, vous avez besoin d'un accès SSH du nœud de contrôle au nœud cible. (Le serveur SSH s'exécute sur le nœud cible)
Pour l'authentification, l'authentification par mot de passe ou l'authentification par clé publique peut être exécutée, mais dans le cas de l'authentification par mot de passe ou de l'authentification par clé publique avec une phrase de passe, il est nécessaire de saisir le mot de passe / la phrase de passe à chaque exécution, donc la clé privée sans phrase de passe Le réglage est pratique car il n'y a pas de soucis lors de la construction.
$ ssh-keygen -t rsa -f $HOME/.ssh/id_rsa -N ""
Cela créera une clé publique sans phrase de passe dans ~ / .ssh / id_rsa
.
Après avoir créé la paire de clés, distribuez la clé publique à chaque nœud cible.
$ ssh-copy-id [email protected] #Nœud cible 1
$ ssh-copy-id [email protected] #Nœud cible 2
Vous devriez maintenant pouvoir accéder en SSH à chaque nœud cible sans authentification.
[zaki@control-node ~]$ ssh 192.168.0.141
[zaki@target-node01 ~]$
[zaki@control-node ~]$ ssh 192.168.0.142
[zaki@target-node02 ~]$
Avec cette configuration, vous devriez pouvoir accéder aux deux nœuds cibles avec le module ping
.
Créez un fichier d'inventaire avec le contenu suivant qui définit le nœud cible.
inventory.ini
[nodes]
192.168.0.141
192.168.0.142
Spécifiez ce fichier d'inventaire avec -i
et exécutez ʻansible`. À ce stade, spécifiez le nom du groupe «[nœuds]» écrit dans la première ligne de l'inventaire où vous avez spécifié «localhost» lors de l'exécution locale.
$ ansible nodes -i inventory.ini -m ping
192.168.0.142 | SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python"
},
"changed": false,
"ping": "pong"
}
192.168.0.141 | SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python"
},
"changed": false,
"ping": "pong"
}
Vous pouvez maintenant confirmer qu'Ansible peut être exécuté du nœud de contrôle vers le nœud cible.
Si vous ne souhaitez pas définir de clé publique sans phrase secrète, vous pouvez exécuter Ansible en procédant comme suit.
Méthode d'authentification | Opération Ansible |
---|---|
Authentification par mot de passe | -k を付与することでAuthentification par mot de passeのプロンプトを表示する |
Authentification par clé publique avec phrase de passe | L'invite de saisie de la phrase de passe s'affiche automatiquement |
Encore un point.
Lors de la construction d'un serveur avec Ansible, la plupart des tâches (telles que l'installation de packages avec yum
) nécessitent des privilèges root.
Si sudo
n'est pas disponible sur le nœud cible en premier lieu, configurez les sudoers (comme l'ajouter au groupe wheel
) pour l'utilisateur cible.
De plus, si vous le définissez de sorte qu'aucun mot de passe ne soit requis lors de l'exécution de sudo
, vous n'avez pas besoin de saisir le mot de passe lors de l'exécution d'Ansible, ce qui est pratique et sans tracas.
/etc/sudoers
%wheel ALL=(ALL) NOPASSWD: ALL
visudo
au lieu de vi
Ceci est fait sur tous les nœuds cibles. (Si le traitement est également effectué sur le nœud de contrôle, définissez-le également sur le nœud de contrôle)
Une fois définie, ajoutez l'option -b
(agissant comme racine par défaut) et exécutez Ansible.
$ ansible nodes -i inventory.ini -b -m ping
192.168.0.142 | SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python"
},
"changed": false,
"ping": "pong"
}
192.168.0.141 | SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python"
},
"changed": false,
"ping": "pong"
}
Si aucune erreur ne se produit, le processus sera exécuté avec les privilèges root sur le nœud cible.
Cependant, il est difficile de comprendre qu'il s'agit d'un module ping
, donc si vous pouvez yum update
sur tous les nœuds, essayez la commande suivante. Tous les packages seront mis à jour.
$ ansible nodes -i inventory.ini -b -m yum -a "name=* state=latest"
Si vous ne définissez pas sudo
sans mot de passe, vous pouvez exécuter Ansible avec les privilèges root en donnant -K
au moment de l'exécution.
Peut être utilisé avec -k
pour l'authentification par mot de passe.
Jusqu'à présent, j'ai expliqué l'installation d'Ansible et le paramétrage de SSH / sudo manuellement, mais depuis que j'installe Ansible, je peux l'automatiser pour ne pas me fâcher avec Jagaimo. Automatisons le lieu. En particulier, la distribution de la clé publique SSH à tous les nœuds cibles et la définition du sudo ne sont pas quelque chose qui se fait manuellement.
--Installation d'Ansible sur le nœud de contrôle (manuel)
wheel
et peut être promu root avec sudo (cependant, mot de passe requis)Les autres exigences, la configuration de la clé publique SSH sans phrase de passe et la configuration sudo sans mot de passe, sont effectuées avec Ansible.
ansible.cfg
Je ne l'ai pas expliqué jusqu'à présent, alors pensez-y comme une magie pour réduire le problème de l'exécution de SSH pour la première fois.
ansible.cfg
[defaults]
host_key_checking = False
[ssh_connection]
ssh_args -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null
inventory.ini
[nodes]
192.168.0.141
192.168.0.142
playbook.yml
---
- hosts: localhost
tasks:
- name: create directory for ssh keypair
file:
path: "{{ lookup('env','HOME') }}/.ssh/"
state: directory
mode: 0700
- name: create ssh privatekey
openssh_keypair:
path: "{{ lookup('env','HOME') }}/.ssh/id_rsa"
- hosts: all
tasks:
- name: publickey copy to target-nodes
authorized_key:
user: "{{ ansible_env.USER }}"
key: "{{ lookup('file', lookup('env', 'HOME') + '/.ssh/id_rsa.pub' )}}"
- hosts: all
become: True
tasks:
- name: configure non-password sudo
copy:
dest: /etc/sudoers.d/nopass
mode: 0600
content: |
%wheel ALL=(ALL) NOPASSWD: ALL
Placez ces trois fichiers dans le même répertoire et exécutez la commande suivante.
$ ansible-playbook -i inventory.ini playbook.yml -kK
N'oubliez pas que -k
est pour l'authentification par mot de passe et -K
est pour l'authentification par mot de passe de promotion sudo, qui n'a pas encore été définie (définie avec cet Ansible).
Les éléments suivants sont référencés en externe à l'aide du plug-in lookup
.
variable | Contenu |
---|---|
{{ lookup('env','HOME') }} | Chemin du répertoire de base de l'utilisateur d'exécution |
{{ ansible_env.USER }} | Nom d'utilisateur |
{{ lookup('file', lookup('env', 'HOME') + '/.ssh/id_rsa.pub' )}} | ~/.ssh/id_rsa.pub Contenu du fichier de |
Dans cet esprit, chaque tâche de ce guide effectue les opérations suivantes:
(Si vous avez déjà un paramètre tel que sudo
sans mot de passe, veuillez le supprimer)
--create répertoire pour ssh keypair (exécution locale)
--Créez un répertoire ~ / .ssh
--create ssh privatekey (exécution locale)
--Créez une paire de clés privées SSH dans ~ / .ssh / id_rsa
--publickey copie sur les nœuds cibles (accès distant)
--Copiez ~ / .ssh / id_rsa.pub
dans la clé_autorisée sur tous les nœuds cibles
--config non-password sudo (autorité root requise)
--Sudo NOPASSWD
paramètre pour tous les nœuds cibles
C’est facile, non?
Comme mentionné dans la Documentation (https://docs.ansible.com/ansible/latest/modules/openssh_keypair_module.html), ce module est un nouveau module disponible à partir de la version 2.8. Il ne peut pas être utilisé avec les versions antérieures d'Ansible.
Si vous utilisez une version antérieure, le module ne peut pas créer la clé, alors remplacez-la par la tâche créée par le module shell
.
playbook.yml
- name: check exists ssh privatekey
shell: test -f $HOME/.ssh/id_rsa
register: exist_key
ignore_errors: True
check_mode: False
changed_when: False
- name: create ssh privatekey
shell: ssh-keygen -t rsa -f $HOME/.ssh/id_rsa -N ""
when: exist_key.rc != 0
C'est un peu long, mais il y a deux étapes: "Vérifier s'il y a ~ / .ssh / id_rsa
" et "Sinon, ssh-keygen
".
Lors de la première exécution, un message d'erreur est émis car il n'y a pas de ~ / .ssh / id_rsa
, mais ʻignore_errors: True` l'ignore et continue le traitement.
… N'y a-t-il pas un mode d'écrasement forcé pour ssh-keygen
? ??
J'ai donc expliqué la procédure de travail spécifique (construction manuelle et automatique par Ansible) concernant la préparation à la construction d'un serveur à l'aide d'Ansible.
Si le nombre d'unités est limité, je pense que je peux faire de mon mieux sans erreur même à la main, mais quand il s'agit de 10 unités et 20 unités, il est certainement préférable de l'automatiser.
Je pense que cela changera un peu en matière d'automatisation du réseau et d'environnement cloud, mais je pense que l'automatisation de la construction de serveurs à l'aide d'Ansible sur site peut être démarrée avec cela.
En passant, l'installation d'Ansible peut-elle être automatisée avec Ansible? ..
référence
Recommended Posts