[CENTOS] Préparation à l'utilisation d'Ansible sur un serveur Linux existant

Aperçu

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)

Constitution

Il est basé sur CentOS.

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.

Installation et configuration

Corps Ansible

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é.

• Contrairement à la commande Linux 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 requise

Python

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.

• La prise en charge de la version 2 de Python prendra fin le 1er janvier 2020.

Accès SSH

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.

paramètres sudo

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

• Utilisez 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.

Construction initiale automatisée par Ansible

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.

supposition

--Installation d'Ansible sur le nœud de contrôle (manuel)

• L'utilisateur travaillant sur le nœud cible appartient au groupe wheel et peut être promu root avec sudo (cependant, mot de passe requis)
• Le nom d'utilisateur et le mot de passe de travail sont communs à tous les nœuds
• La connexion SSH est possible avec l'authentification par mot de passe et Python est déjà installé.

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

inventaire

inventory.ini

[nodes]
192.168.0.141
192.168.0.142

• Si vous souhaitez également créer le nœud de contrôle (192.168.0.140) qui exécute Ansible, ajoutez-le également.

Playbook

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.

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?

(Supplément) À propos du module openssh_keypair

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? ??

Résumé

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

• openssh_keypair - Générer des clés privées et publiques OpenSSH - Ansible Documentation * À partir de la version 2.8
• authorized_key – Adds or removes an SSH authorized key — Ansible Documentation
• OSS vole avec des ailes en aluminium: livre de jeu Monogusa
• Passer la clé_autorisée pour le moment avec Ansible --Qiita
• IT et bien plus encore: spécifiez le nom d'utilisateur comme variable lors de l'utilisation du plugin de recherche avec le module authorized_key d'Ansible