Etude

De TARENTINO
Aller à la navigationAller à la recherche

Cas pratique ANSIBLE

  • Bien entendu, aller choper des trucs sur internet et les réécrire simplement, friserait non seulement le plagia mais ça ne servirait à rien.
  • Je mettrai donc ce qui est très bien expliqué sur les vidéos en comparaison avec mon propre réseau, en expliquant les difficultés que j'ai rencontrées....
  • Je pars volontairement de zéro dans un apprentissage autodidacte.
  • Il y a des termes qui sont employés et dont je ne comprends pas la signification. Quelle est la différence entre module et role et playbook? Je ne captais rien avant de chercher....
  • Problème 01:
    • J'avais commencé en faisant comme décrit dans la partie <Installation> avec PIP, mais je ne sais pas pourquoi, ça a planté.
    • J'ai donc tout désinstallé et réinstallé avec apt-get install ansible. Et ça a fonctionné sauf que (problème 02)....
  • Problème 02:
    • Les fichiers de conf auraient du se trouver dans /etc/ansible, enfin normalement....
    • Je suis allé voir et, rien, aucun fichier ni répertoire. Il y a pourtant bien des fichiers de configuration à créer ce que j'ai compris en regardant <cette vidéo>
  • J'ai créé un petit réseau avec 3 machines virtuelles
    • 1) Node Manager (Ubuntu), appelée FAMILLE (192.168.0.60/24)
    • 2) Node (Ubuntu), appelée UBUNTU (192.168.0.61/24)
    • 3) Node (Kali Linux), appelée KALI (192.168.0.62/24)
  • Problème 03:
    • Bon, cette solution est très bien mais il faut entrer le mot de passe à chaque fois.
    • J'ai cherché sans vraiment trouver de solution. Elle existe sans doute mais à cet instant, je n'ai pas de réponse.
    • On continue...
    • La solution: clé SSH en utilisant un user avec pouvoir sudo, et il y a d'autres options mais je dois étudier les playbooks et les roles avant.
  • Les modules
  • Les roles
    • Les roles, un truc découvert en cherchant et qui est génial.
    • Ansible chez moi est installé sur un serveur à l'endroit suivant /etc/ansible
    • A l'installation, ce répertoire était vide, donc je me suis dit que j'allais tout stocker ici. Erreur ! Un role permet de hiérarchiser, d'ordonner, de structurer....
    • Exemple en créant un role qui permet de créer un user sur une machine distante. Mettre en dur le nom du user c'est bien, mais je voulais aussi savoir comment transférer en paramètre le nom du user et le groupe à la commande....
  • Problème 04:
    • Je l'appellerai l'expérience !
    • J'avais tout bien préparé, bien avancé dans les scripts ansible et je m'étais dit que j'allais faire une sauvegarde de la VM contenant ansible plus tard...
    • ERREUR !
    • En voulant sauvegarder cette VM, j'ai fait une erreur dans la commande TAR... J'ai tout perdu. Raison pour laquelle la mise à jour de cette doc a tardé.
    • J'ai reconstruit la VM, ré étudié tout ce que j'avais fait avec cette fois ci les bonnes procédures et mises en place de sauvegarde régulières par crontab. J'aurai du commencer par là.
    • J'ai donc tout reconstruit en me jurant de mettre régulièrement à jour cette doc.
    • J'ai tout reconstruit mais en mieux ;)

* Mon projet Ansible:

    • J'ai 3 VM, une Master qui contient Ansible <Famille>, deux autres Nodes de test <KALI> et <UBUNTU>.
    • Je veux que Ansible configure et mette à jour automatiquement les nodes, tout en ayant la possibilité de paramétrer d'autres PC que j’intégrerai sur mon réseau.
    • J'ai refait toutes les étapes précédentes jusqu'à la création des users distants.
  • Différentes étapes 
   Arborescence à créer

  ├── cmd
  ├── SAVE
  ├── mnt
  │   ├── baie
  │   │   └── Install
  │   ├── externe
  │   │   ├── Disque_USB
  │   │   └── CIFS
  │   │       ├── Samba_01
  │   │       └── Samba_02
  │   ├── interne
  │   │   ├── Disques_SD
  │   │   │   └── Disques_01
  │   │   ├── Disques_SCSI
  │   │   │   ├── Disque_01
  │   │   │   └── Disque_02
  │   │   ├── Disques_IDE
  │   │   │   └── Disques_01
  │   │   └── Disques_SATA
  │   │       ├── Disque_01
  │   │       ├── Disque_02
  │   │       └── Disque_03
  │   ├── RAM_disque
  │   ├── root
  │   │   ├── .config
  │   │   │   └── nautilus
  │   │   └── .Xauthority
  │   ├── sauvegardes
  │   │   └── messageries


A suivre....

Sommaire

Ansible

Introduction

Qu'est ce que Ansible?

  • Outil basé sur du Push
  • Pas d'agent à installer
  • Utilisation de modules (Ansible Galaxie)
  • Inventory / Playbook / Roles
    • Inventory (Vocation à avoir l'inventaire de toutes les machines)
    • Playbook (Faire l'articulation entre Inventory et Roles)
    • Roles (Pour une installation spécifique)
  • Type d'installations
    • Sources
    • Paquets
    • PIP (Librarie Python)
  • Sytème
    • Templating

Notions et définitions

Concepts de base de l'outil

  • Control Node
    • Noeud central contenant Ansible
    • Prérequis: Accès SSH aux autres machines
  • Managed Node
    • Serveurs cibles ayant SSH et Python installés
    • Dont un User avec privilèges Sudo
  • Inventory
    • Inventaire des machines (IP, ou DNS) sous forme de fichier
    • Format INI ou YAML
    • Egalement fichiers de variable (host_vars/group_vars)
    • Inventaire statique (fichiers) ou dynamique (API via scripts)
    • Utilisation de patterns façon Regex
  • Groupes
    • Machines regroupées et typées
      • Création de "boites" dans lesquelles seront classés les serveurs
      • Les boites peuvent être imbriquées et définir des groupes parent et enfant
      • Le groupe Racine (All) est le père de tous
    • Groupes VARS (9:28)
      • Répertoire contenant les variables d'un même groupe contenant un fichier YAML
      • Soit dans le fichier central d'inventory
    • Hosts VARS (10:51)
      • Variables spécifiques à un serveur en particulier
      • Surcharge d'autres variables
  • Exemple d'inventory (12:05)
  • Tasks (13:00)
    • Faire des actions ponctuelles.
      • Créer des users
      • Créer des groupes
      • Passer des commandes
      • Utiliser des modules
      • Copier des fichiers
      • Check de variables
      • etc....
    • Format YAML
  • Modules (13:49)
    • Permet de décrire des actions
    • Modules de base (natifs)
      • Templates
      • Copie de fichiers
      • Création de users
      • etc....
    • Chaque action de module est utilisable par des Tasks
      • Une Task = Une action
      • Une action appelle un module
    • Les actions des modules peuvent fournir des retours
  • Rôles (16:00)
    • Ensemble d'actions
    • L'idéal est de segmenter les rôles
    • Minimiser les rôles
    • Ils sont organisés avec une structure
      • Ils contiennent:
        • Tasks (actions à réaliser)
        • Templates (Fichiers mis à disposition dans les roles)
        • Handlers (Trigger qui va écouter les actions)
        • Variables
        • Meta (Pour le partage des Rôles)
  • Playbooks (19:13)
    • C'est un fichier
Inventory (liste des machines) >> playbook << Rôles à jouer
    • Le playbook fera la correspondance entre quelle machine sur quel groupe avec quelle variable, tel rôle s'appliquera
    • Peut contenir des variables mais à éviter.
    • Peut contenir des tasks mais à éviter.
    • Peut contenir des conditions mais à éviter.
  • Plugins (20:50)
    • Augmenter les capacités de Ansible

INSTALLATION

LES INSTALLATIONS (PIP, DEPOTS ET A SAVOIR)

Installation de Ansible

  • Machines
    • Controller Node
      • Python >= 2.7
      • Pas de Windows
      • SSH
    • Managed Node
      • Python >= 2.6
  • Installations (2:00)
    • Binaire
      • git clone https://github.com/ansible/ansible.git
      • cd ansible
      • source ./hacking/env-setup
      • sudo apt install python
      • pip install --user -r ./requirements.txt
      • echo "127.0.0.1" > ~/ansible_hosts
      • export ANSIBLE_INVENTORY=~/ansible_hosts
      • ansible all -m ping --ask-pass
    • PIP
      • sudo apt install python3-pip
      • pip3 install ansible (ou pip3 install ansible==2.2.9) (4:22)
    • Par la distribution (5:30)
      • sudo apt install ansible
  • Utilisation (5:00)
    • Se reconnecter
    • Versions
      • ansible --version
      • cat /etc/*ea* (6:32)
    • Précisions et configuration(6:54)
      • sudo launchctl limit maxfiles unlimited (sur MacOS)
      • Indiquer l'endroit de l'interpréteur Python3 (/usr/bin/python3)
      • Installer Python sur la machine distante
        • ansible myhost --become -m raw -a "yum install -y python3"

SSH : CLEFS ET ASTUCES

Permettre aux Nodes de communiquer

  • Clé privée et clé publique
    • La clé privée ne doit pas être diffusée
    • La clé publique a vocation à être déployée sur les serveurs distants
  • Générer les clefs
    • ssh-keygen -t ecdsa -b 521
      • va générer une clef privée et publiquesans extension ou .pem
      • droits en 600
  • Transférer la clé
    • ssh-copy-id $USER@$SERVEUR
    • Sécuriser éventuellement (5:45)
    • Création d'un .ssh/config (8:40)

FICHIER CFG : CONFIGURATION ET TUNING

Fichier de configuration de Ansible

  • hosts
    • Donne un détail des machines sur le réseau et paramètre leurs fonction
    • Contenu:

 1 [servers]
 2 FAMILLE ansible_host=192.168.0.60
 3 KALI ansible_host=192.168.0.61
 4 UBUNTU ansible_host=192.168.0.62
 5 
 6 [web_servers]
 7 FAMILLE ansible_host=192.168.0.60
 8 
 9 [multi]
10 FAMILLE ansible_host=192.168.0.60
11 
12 [all:vars]
13 ansible_python_interpreter=/usr/bin/python3

  • ansible.cfg
    • Permet de configurer la manière dont ansible va se jouer
    • Si le fichier ansible.cfg doit se trouver à un autre endroit, il faut l'indiquer dans la variable ANSIBLE_CONFIG
      • A l'endroit du playbook (4:16)
      • dans le HOME/.ansible/ansible.cfg
      • dans /etc/ansible/ansible.cfg
      • Contenu:

  1 # Example config file for ansible -- https://ansible.com/
  2 # =======================================================
  3 
  4 # Nearly all parameters can be overridden in ansible-playbook
  5 # or with command line flags. Ansible will read ANSIBLE_CONFIG,
  6 # ansible.cfg in the current working directory, .ansible.cfg in
  7 # the home directory, or /etc/ansible/ansible.cfg, whichever it
  8 # finds first
  9 
 10 # For a full list of available options, run ansible-config list or see the
 11 # documentation: https://docs.ansible.com/ansible/latest/reference_appendices/config.html.
 12 
 13 [defaults]
 14 #inventory       = /etc/ansible/hosts
 15 #library         = ~/.ansible/plugins/modules:/usr/share/ansible/plugins/modules
 16 #module_utils    = ~/.ansible/plugins/module_utils:/usr/share/ansible/plugins/module_utils
 17 #remote_tmp      = ~/.ansible/tmp
 18 #local_tmp       = ~/.ansible/tmp
 19 #forks           = 5
 20 #poll_interval   = 0.001
 21 #ask_pass        = False
 22 #transport       = smart
 23 
 24 # Plays will gather facts by default, which contain information about
 25 # the remote system.
 26 #
 27 # smart - gather by default, but don't regather if already gathered
 28 # implicit - gather by default, turn off with gather_facts: False
 29 # explicit - do not gather by default, must say gather_facts: True
 30 #gathering = implicit
 31 
 32 # This only affects the gathering done by a play's gather_facts directive,
 33 # by default gathering retrieves all facts subsets
 34 # all - gather all subsets
 35 # network - gather min and network facts
 36 # hardware - gather hardware facts (longest facts to retrieve)
 37 # virtual - gather min and virtual facts
 38 # facter - import facts from facter
 39 # ohai - import facts from ohai
 40 # You can combine them using comma (ex: network,virtual)
 41 # You can negate them using ! (ex: !hardware,!facter,!ohai)
 42 # A minimal set of facts is always gathered.
 43 #
 44 #gather_subset = all
 45 
 46 # some hardware related facts are collected
 47 # with a maximum timeout of 10 seconds. This
 48 # option lets you increase or decrease that
 49 # timeout to something more suitable for the
 50 # environment.
 51 #
 52 #gather_timeout = 10
 53 
 54 # Ansible facts are available inside the ansible_facts.* dictionary
 55 # namespace. This setting maintains the behaviour which was the default prior
 56 # to 2.5, duplicating these variables into the main namespace, each with a
 57 # prefix of 'ansible_'.
 58 # This variable is set to True by default for backwards compatibility. It
 59 # will be changed to a default of 'False' in a future release.
 60 #
 61 #inject_facts_as_vars = True
 62 
 63 # Paths to search for collections, colon separated
 64 # collections_paths = ~/.ansible/collections:/usr/share/ansible/collections
 65 
 66 # Paths to search for roles, colon separated
 67 #roles_path = ~/.ansible/roles:/usr/share/ansible/roles:/etc/ansible/roles
 68 
 69 # Host key checking is enabled by default
 70 #host_key_checking = True
 71 
 72 # You can only have one 'stdout' callback type enabled at a time. The default
 73 # is 'default'. The 'yaml' or 'debug' stdout callback plugins are easier to read.
 74 #
 75 #stdout_callback = default
 76 #stdout_callback = yaml
 77 #stdout_callback = debug
 78 
 79 
 80 # Ansible ships with some plugins that require enabling
 81 # this is done to avoid running all of a type by default.
 82 # These setting lists those that you want enabled for your system.
 83 # Custom plugins should not need this unless plugin author disables them
 84 # by default.
 85 #
 86 # Enable callback plugins, they can output to stdout but cannot be 'stdout' type.
 87 #callback_enabled = timer, mail
 88 
 89 # Determine whether includes in tasks and handlers are "static" by
 90 # default. As of 2.0, includes are dynamic by default. Setting these
 91 # values to True will make includes behave more like they did in the
 92 # 1.x versions.
 93 #
 94 #task_includes_static = False
 95 #handler_includes_static = False
 96 
 97 # Controls if a missing handler for a notification event is an error or a warning
 98 #error_on_missing_handler = True
 99 
100 # Default timeout for connection plugins
101 #timeout = 10
102 
103 # Default user to use for playbooks if user is not specified
104 # Uses the connection plugin's default, normally the user currently executing Ansible,
105 # unless a different user is specified here.
106 #
107 #remote_user = root
108 
109 # Logging is off by default unless this path is defined.
110 #log_path = /var/log/ansible.log
111 
112 # Default module to use when running ad-hoc commands
113 #module_name = command
114 
115 # Use this shell for commands executed under sudo.
116 # you may need to change this to /bin/bash in rare instances
117 # if sudo is constrained.
118 #
119 #executable = /bin/sh
120 
121 # By default, variables from roles will be visible in the global variable
122 # scope. To prevent this, set the following option to True, and only
123 # tasks and handlers within the role will see the variables there
124 #
125 #private_role_vars = False
126 
127 # List any Jinja2 extensions to enable here.
128 #jinja2_extensions = jinja2.ext.do,jinja2.ext.i18n
129 
130 # If set, always use this private key file for authentication, same as
131 # if passing --private-key to ansible or ansible-playbook
132 #
133 #private_key_file = /path/to/file
134 
135 # If set, configures the path to the Vault password file as an alternative to
136 # specifying --vault-password-file on the command line. This can also be
137 # an executable script that returns the vault password to stdout.
138 #
139 #vault_password_file = /path/to/vault_password_file
140 
141 # Format of string {{ ansible_managed }} available within Jinja2
142 # templates indicates to users editing templates files will be replaced.
143 # replacing {file}, {host} and {uid} and strftime codes with proper values.
144 #
145 #ansible_managed = Ansible managed: {file} modified on %Y-%m-%d %H:%M:%S by {uid} on {host}
146 
147 # {file}, {host}, {uid}, and the timestamp can all interfere with idempotence
148 # in some situations so the default is a static string:
149 #
150 #ansible_managed = Ansible managed
151 
152 # By default, ansible-playbook will display "Skipping [host]" if it determines a task
153 # should not be run on a host. Set this to "False" if you don't want to see these "Skipping"
154 # messages. NOTE: the task header will still be shown regardless of whether or not the
155 # task is skipped.
156 #
157 #display_skipped_hosts = True
158 
159 # By default, if a task in a playbook does not include a name: field then
160 # ansible-playbook will construct a header that includes the task's action but
161 # not the task's args. This is a security feature because ansible cannot know
162 # if the *module* considers an argument to be no_log at the time that the
163 # header is printed. If your environment doesn't have a problem securing
164 # stdout from ansible-playbook (or you have manually specified no_log in your
165 # playbook on all of the tasks where you have secret information) then you can
166 # safely set this to True to get more informative messages.
167 #
168 #display_args_to_stdout = False
169 
170 # Ansible will raise errors when attempting to dereference
171 # Jinja2 variables that are not set in templates or action lines. Uncomment this line
172 # to change this behavior.
173 #
174 #error_on_undefined_vars = False
175 
176 # Ansible may display warnings based on the configuration of the
177 # system running ansible itself. This may include warnings about 3rd party packages or
178 # other conditions that should be resolved if possible.
179 # To disable these warnings, set the following value to False:
180 #
181 #system_warnings = True
182 
183 # Ansible may display deprecation warnings for language
184 # features that should no longer be used and will be removed in future versions.
185 # To disable these warnings, set the following value to False:
186 #
187 #deprecation_warnings = True
188 
189 # Ansible can optionally warn when usage of the shell and
190 # command module appear to be simplified by using a default Ansible module
191 # instead. These warnings can be silenced by adjusting the following
192 # setting or adding warn=yes or warn=no to the end of the command line
193 # parameter string. This will for example suggest using the git module
194 # instead of shelling out to the git command.
195 #
196 #command_warnings = False
197 
198 # set plugin path directories here, separate with colons
199 #action_plugins     = /usr/share/ansible/plugins/action
200 #become_plugins     = /usr/share/ansible/plugins/become
201 #cache_plugins      = /usr/share/ansible/plugins/cache
202 #callback_plugins   = /usr/share/ansible/plugins/callback
203 #connection_plugins = /usr/share/ansible/plugins/connection
204 #lookup_plugins     = /usr/share/ansible/plugins/lookup
205 #inventory_plugins  = /usr/share/ansible/plugins/inventory
206 #vars_plugins       = /usr/share/ansible/plugins/vars
207 #filter_plugins     = /usr/share/ansible/plugins/filter
208 #test_plugins       = /usr/share/ansible/plugins/test
209 #terminal_plugins   = /usr/share/ansible/plugins/terminal
210 #strategy_plugins   = /usr/share/ansible/plugins/strategy
211 
212 # Ansible will use the 'linear' strategy but you may want to try another one.
213 #strategy = linear
214 # By default, callbacks are not loaded for /bin/ansible. Enable this if you
215 # want, for example, a notification or logging callback to also apply to
216 # /bin/ansible runs
217 #
218 #bin_ansible_callbacks = False
219 # Don't like cows?  that's unfortunate.
220 # set to 1 if you don't want cowsay support or export ANSIBLE_NOCOWS=1
221 #nocows = 1
222 # Set which cowsay stencil you'd like to use by default. When set to 'random',
223 # a random stencil will be selected for each task. The selection will be filtered
224 # against the `cow_enabled` option below.
225 #
226 #cow_selection = default
227 #cow_selection = random
228 # When using the 'random' option for cowsay, stencils will be restricted to this list.
229 # it should be formatted as a comma-separated list with no spaces between names.
230 # NOTE: line continuations here are for formatting purposes only, as the INI parser
231 #       in python does not support them.
232 #
233 #cowsay_enabled_stencils=bud-frogs,bunny,cheese,daemon,default,dragon,elephant-in-snake,elephant,eyes,\
234 #              hellokitty,kitty,luke-koala,meow,milk,moofasa,moose,ren,sheep,small,stegosaurus,\
235 #              stimpy,supermilker,three-eyes,turkey,turtle,tux,udder,vader-koala,vader,www
236 # Don't like colors either?
237 # set to 1 if you don't want colors, or export ANSIBLE_NOCOLOR=1
238 #
239 #nocolor = 1
240 # If set to a persistent type (not 'memory', for example 'redis') fact values
241 # from previous runs in Ansible will be stored. This may be useful when
242 # wanting to use, for example, IP information from one group of servers
243 # without having to talk to them in the same playbook run to get their
244 # current IP information.
245 #
246 #fact_caching = memory
247 # This option tells Ansible where to cache facts. The value is plugin dependent.
248 # For the jsonfile plugin, it should be a path to a local directory.
249 # For the redis plugin, the value is a host:port:database triplet: fact_caching_connection = localhost:6379:0
250 #
251 #fact_caching_connection=/tmp
252 # retry files
253 # When a playbook fails a .retry file can be created that will be placed in ~/
254 # You can enable this feature by setting retry_files_enabled to True
255 # and you can change the location of the files by setting retry_files_save_path
256 #
257 #retry_files_enabled = False
258 #retry_files_save_path = ~/.ansible-retry
259 # prevents logging of task data, off by default
260 #no_log = False
261 # prevents logging of tasks, but only on the targets, data is still logged on the master/controller
262 #no_target_syslog = False
263 # Controls whether Ansible will raise an error or warning if a task has no
264 # choice but to create world readable temporary files to execute a module on
265 # the remote machine. This option is False by default for security. Users may
266 # turn this on to have behaviour more like Ansible prior to 2.1.x. See
267 # https://docs.ansible.com/ansible/latest/user_guide/become.html#becoming-an-unprivileged-user
268 # for more secure ways to fix this than enabling this option.
269 #
270 #allow_world_readable_tmpfiles = False
271 # Controls what compression method is used for new-style ansible modules when
272 # they are sent to the remote system. The compression types depend on having
273 # support compiled into both the controller's python and the client's python.
274 # The names should match with the python Zipfile compression types:
275 # * ZIP_STORED (no compression. available everywhere)
276 # * ZIP_DEFLATED (uses zlib, the default)
277 # These values may be set per host via the ansible_module_compression inventory variable.
278 #
279 #module_compression = 'ZIP_DEFLATED'
280 # This controls the cutoff point (in bytes) on --diff for files
281 # set to 0 for unlimited (RAM may suffer!).
282 #
283 #max_diff_size = 104448
284 # Controls showing custom stats at the end, off by default
285 #show_custom_stats = False
286 # Controls which files to ignore when using a directory as inventory with
287 # possibly multiple sources (both static and dynamic)
288 #
289 #inventory_ignore_extensions = ~, .orig, .bak, .ini, .cfg, .retry, .pyc, .pyo
290 # This family of modules use an alternative execution path optimized for network appliances
291 # only update this setting if you know how this works, otherwise it can break module execution
292 #
293 #network_group_modules=eos, nxos, ios, iosxr, junos, vyos
294 # When enabled, this option allows lookups (via variables like {{lookup('foo')}} or when used as
295 # a loop with `with_foo`) to return data that is not marked "unsafe". This means the data may contain
296 # jinja2 templating language which will be run through the templating engine.
297 # ENABLING THIS COULD BE A SECURITY RISK
298 #
299 #allow_unsafe_lookups = False
300 # set default errors for all plays
301 #any_errors_fatal = False
302 
303 [inventory]
304 # List of enabled inventory plugins and the order in which they are used.
305 #enable_plugins = host_list, script, auto, yaml, ini, toml
306 # Ignore these extensions when parsing a directory as inventory source
307 #ignore_extensions = .pyc, .pyo, .swp, .bak, ~, .rpm, .md, .txt, ~, .orig, .ini, .cfg, .retry
308 # ignore files matching these patterns when parsing a directory as inventory source
309 #ignore_patterns=
310 # If 'True' unparsed inventory sources become fatal errors, otherwise they are warnings.
311 #unparsed_is_failed = False
312 
313 [privilege_escalation]
314 #become = False
315 #become_method = sudo
316 #become_ask_pass = False
317 ## Connection Plugins ##
318 # Settings for each connection plugin go under a section titled '[[plugin_name]_connection]'
319 # To view available connection plugins, run ansible-doc -t connection -l
320 # To view available options for a connection plugin, run ansible-doc -t connection [plugin_name]
321 # https://docs.ansible.com/ansible/latest/plugins/connection.html
322 
323 [paramiko_connection]
324 # uncomment this line to cause the paramiko connection plugin to not record new host
325 # keys encountered. Increases performance on new host additions. Setting works independently of the
326 # host key checking setting above.
327 #record_host_keys=False
328 # by default, Ansible requests a pseudo-terminal for commands executed under sudo. Uncomment this
329 # line to disable this behaviour.
330 #pty = False
331 # paramiko will default to looking for SSH keys initially when trying to
332 # authenticate to remote devices. This is a problem for some network devices
333 # that close the connection after a key failure. Uncomment this line to
334 # disable the Paramiko look for keys function
335 #look_for_keys = False
336 # When using persistent connections with Paramiko, the connection runs in a
337 # background process. If the host doesn't already have a valid SSH key, by
338 # default Ansible will prompt to add the host key. This will cause connections
339 # running in background processes to fail. Uncomment this line to have
340 # Paramiko automatically add host keys.
341 #host_key_auto_add = True
342 
343 [ssh_connection]
344 # ssh arguments to use
345 # Leaving off ControlPersist will result in poor performance, so use
346 # paramiko on older platforms rather than removing it, -C controls compression use
347 # ssh_args = -C -o ControlMaster=auto -o ControlPersist=60s
348 # The base directory for the ControlPath sockets.
349 # This is the "%(directory)s" in the control_path option
350 #
351 # Example:
352 # control_path_dir = /tmp/.ansible/cp
353 # control_path_dir = ~/.ansible/cp
354 # The path to use for the ControlPath sockets. This defaults to a hashed string of the hostname,
355 # port and username (empty string in the config). The hash mitigates a common problem users
356 # found with long hostnames and the conventional %(directory)s/ansible-ssh-%%h-%%p-%%r format.
357 # In those cases, a "too long for Unix domain socket" ssh error would occur.
358 #
359 # Example:
360 # control_path = %(directory)s/%%C
361 #control_path =
362 # Enabling pipelining reduces the number of SSH operations required to
363 # execute a module on the remote server. This can result in a significant
364 # performance improvement when enabled, however when using "sudo:" you must
365 # first disable 'requiretty' in /etc/sudoers
366 #
367 # By default, this option is disabled to preserve compatibility with
368 # sudoers configurations that have requiretty (the default on many distros).
369 #
370 #pipelining = False
371 # Control the mechanism for transferring files (old)
372 #   * smart = try sftp and then try scp [default]
373 #   * True = use scp only
374 #   * False = use sftp only
375 #scp_if_ssh = smart
376 # Control the mechanism for transferring files (new)
377 # If set, this will override the scp_if_ssh option
378 #   * sftp  = use sftp to transfer files
379 #   * scp   = use scp to transfer files
380 #   * piped = use 'dd' over SSH to transfer files
381 #   * smart = try sftp, scp, and piped, in that order [default]
382 #transfer_method = smart
383 # If False, sftp will not use batch mode to transfer files. This may cause some
384 # types of file transfer failures impossible to catch however, and should
385 # only be disabled if your sftp version has problems with batch mode
386 #sftp_batch_mode = False
387 # The -tt argument is passed to ssh when pipelining is not enabled because sudo
388 # requires a tty by default.
389 #usetty = True
390 # Number of times to retry an SSH connection to a host, in case of UNREACHABLE.
391 # For each retry attempt, there is an exponential backoff,
392 # so after the first attempt there is 1s wait, then 2s, 4s etc. up to 30s (max).
393 #retries = 3
394 
395 [persistent_connection]
396 # Configures the persistent connection timeout value in seconds. This value is
397 # how long the persistent connection will remain idle before it is destroyed.
398 # If the connection doesn't receive a request before the timeout value
399 # expires, the connection is shutdown. The default value is 30 seconds.
400 #connect_timeout = 30
401 # The command timeout value defines the amount of time to wait for a command
402 # or RPC call before timing out. The value for the command timeout must
403 # be less than the value of the persistent connection idle timeout (connect_timeout)
404 # The default value is 30 second.
405 #command_timeout = 30
406 ## Become Plugins ##
407 # Settings for become plugins go under a section named '[[plugin_name]_become_plugin]'
408 # To view available become plugins, run ansible-doc -t become -l
409 # To view available options for a specific plugin, run ansible-doc -t become [plugin_name]
410 # https://docs.ansible.com/ansible/latest/plugins/become.html
411 
412 [sudo_become_plugin]
413 #flags = -H -S -n
414 #user = root
415 
416 [selinux]
417 # file systems that require special treatment when dealing with security context
418 # the default behaviour that copies the existing context or uses the user default
419 # needs to be changed to use the file system dependent context.
420 #special_context_filesystems=fuse,nfs,vboxsf,ramfs,9p,vfat
421 # Set this to True to allow libvirt_lxc connections to work without SELinux.
422 #libvirt_lxc_noseclabel = False
423 
424 [colors]
425 #highlight = white
426 #verbose = blue
427 #warn = bright purple
428 #error = red
429 #debug = dark gray
430 #deprecate = purple
431 #skip = cyan
432 #unreachable = red
433 #ok = green
434 #changed = yellow
435 #diff_add = green
436 #diff_remove = red
437 #diff_lines = cyan
438 
439 [diff]
440 # Always print diff when running ( same as always running with -D/--diff )
441 #always = False
442 # Set how many context lines to show in diff
443 #context = 3
444 
445 [galaxy]
446 # Controls whether the display wheel is shown or not
447 #display_progress=
448 # Validate TLS certificates for Galaxy server
449 #ignore_certs = False
450 # Role or collection skeleton directory to use as a template for
451 # the init action in ansible-galaxy command
452 #role_skeleton=
453 # Patterns of files to ignore inside a Galaxy role or collection
454 # skeleton directory
455 #role_skeleton_ignore="^.git$", "^.*/.git_keep$"
456 # Galaxy Server URL
457 #server=https://galaxy.ansible.com
458 # A list of Galaxy servers to use when installing a collection.
459 #server_list=automation_hub, release_galaxy
460 # Server specific details which are mentioned in server_list
461 #[galaxy_server.automation_hub]
462 #url=https://cloud.redhat.com/api/automation-hub/
463 #auth_url=https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token
464 #token=my_ah_token
465 #
466 #[galaxy_server.release_galaxy]
467 #url=https://galaxy.ansible.com/
468 #token=my_token

  • cli (ligne de commande)
    • Il existe un binaire (ansible-config)
      • Arguments:
        • view (4:16)
          • Permet de voir les paramètres de configuration
        • list
          • Donne la liste de tous les paramètres ansible qu'on va pouvoir "seter"
  • Astuce
    • Dans le fichier ansible.cfg
      • host_key_checking = False
        • Empeche la validation par <YES>
      • callback_whitelist = profile_tasks
        • Permet d'avoir la durée de chaque task ansible
      • pipelining = True (12:07)
        • Permet de gagner du temps
      • sh_args = -C -o ControlMaster=auto -o ControlPersist=60s -o PreferredAuthentications=publickey
        • Permet de partager plusieurs sessions pour une même connexion
        • contrôler la persistance
        • Spécifier directement l'authentification
      • fork = 30 (15:25)
        • (parallélisme)
      • gather_fact: no
        • Pour jouer un Run Ansible, il va d'abord y avoir un check des informations système, avec cette ligne on annule cette collecte (peut poser des problèmes, time, interface, .....)
      • Voir plus tard Mitogen'

Au final

  • Clés SSH déployées

    • Sur le slave....
      • Configuration pour le passwd
        • ajouter la ligne ansible ALL=(ALL) NOPASSWD: ALL dans /etc/sudoers

    • Sur le master....
      • Création de la clé SSH :
1  ssh-keygen
      • Transfert de la clé SSH du master vers le slave
1  ssh-copy-id ansible@<slave>
      • Arborescence....
        • Répertoire sur le Node principal:
          • /etc/ansible
          • /etc/ansible/ansible.cfg
          • /etc/ansible/hosts
          • /etc/ansible/roles

UTILISATION

  • Il y a un utilisateur créé sur chaque machine esclave qui se nomme ansible.
  • Les clés SSH ont été propagées du node principal vers les nodes esclaves (user ansible -> user ansible).

Les outils Ansible

Outil Description
ansible Execution d’une tâche
ansible-playbook Executionde playbook (ensemble de tâches à effectuer)
ansible-doc Accès au listing + documentation des serveurs
ansible-vault Gestion de fichiers chiffrés (stockage variable -mot de passe)
ansible-galaxy Accès au dépôt des rôles d’ansible

Ansible en commandes directes

Syntaxe sans privilège

  • Il est aussi possible d'exécuter directement des commandes Linux sur Ansible, en utilisant l'option -a
ansible all -a "whereis python" -u ansible
  1. UBUNTU | CHANGED | rc=0 >>
  2. python: /usr/bin/python3.8 /usr/bin/python3.8-config /usr/lib/python2.7 /usr/lib/python3.8 /usr/lib/python3.9 /etc/python2.7 /etc/python3.8 /usr/local/lib/python3.8 /usr/include/python3.8
  3. KALI | CHANGED | rc=0 >>
  4. python: /usr/bin/python3.8 /usr/lib/python2.7 /usr/lib/python3.9 /usr/lib/python3.8 /etc/python3.8 /usr/local/lib/python3.8 /usr/include/python3.8
  5. FAMILLE | CHANGED | rc=0 >>
  6. python: /usr/bin/python3.8 /usr/bin/python /usr/bin/python2.7 /usr/bin/python3.8-config /usr/lib/python3.9 /usr/lib/python3.8 /usr/lib/python2.7 /etc/python3.8 /etc/python2.7 /usr/local/lib/python3.8 /usr/local/lib/python2.7 /usr/include/python3.8 /usr/share/python

Détail de la commande:

  • ansible all -m ping -u ansible
    • all: Toutes les machines de l'inventaire (host)
    • -a "whereis python": On envoie directement une commande
    • -u ansible: Avec le user ansible

Syntaxe avec privilèges

ansible all -a "grep ansible /etc/shadow" -u ansible --become -K

Envoyer un fichier

ansible <Node cible> -m copy -a 'src=<Fichier source> dest=<Répertoire destination> owner=root mode=0644' -u root [--become -K]

Supprimer un package

ansible <Node cible> -m apt -a 'name=<Package> state=absent purge=yes' --become

Démarrer un service

ansible <Node cible> -m service -a 'name=<Service> state=started enabled=yes' --become

Vérifier la disponibilité des Nodes

ansible all -a "uptime"

Donne les informations système

ansible all -m setup

Ansible et les modules

  • Aide Ansible
  • Qu'est-ce qu'un module ?
    • Les modules sont comme de petits programmes qu'Ansible pousse depuis une machine de contrôle vers tous les hôtes distants.
    • Un module Ansible est une fonction Python avec des paramètres en entrée qui sera exécutée sur les serveurs distants.
    • Les modules sont exécutés à l'aide de playbooks ou depuis la cli (lignes de commande) Ansible, et ils contrôlent des éléments tels que les services, les packages, les fichiers et bien plus.
  • La syntaxe est:
    • ansible (hote/groupe/all) –m MODULE [-a "arg1=val1"]
  • Liste de tous les modules ansible
  • ansible-doc - indique la documentation sur un module spécifique
    • Ex: ansible-doc shell
  • Vérifier la syntaxe:
    • ansible-playbook myfile.yml --syntax-check
    • ansible-playbook myfile.yml -check

Module Ping

ansible all -m ping -u ansible
  1. KALI | SUCCESS => {
  2. "changed": false,
  3. "ping": "pong"
  4. }
  5. UBUNTU | SUCCESS => {
  6. "changed": false,
  7. "ping": "pong"
  8. }
  9. FAMILLE | SUCCESS => {
  10. "changed": false,
  11. "ping": "pong"
  12. }
  • Les machines répondent bien.

Détail de la commande:

  • ansible all -m ping -u ansible
    • all: Toutes les machines de l'inventaire (host)
    • -m ping: On utilise le module ping (Tiens on parle de module?)
    • -u ansible: Utilisation du module depuis le user ansible

Module USERS/GROUPS

  • Ça, c'est la vidéo....

Module FILES

Exemple Module FILES - copy
Source FAMILLE contenant Ansible testf1
/tmp/testf2
Destination KALI Machine Cible /home/testf1
/home/testf2
  • Général
 1 ---
 2 - name: Module FILES - copy
 3   hosts: KALI
 4 
 5   tasks:
 6   - name: Copie du fichier
 7     copy: src={{ item.src }} dest={{ item.dest }}
 8     owner: "{{ ansible_user }}"
 9     group: "{{ ansible_user }}"
10     with_items:
11       - { src: "testf1", dest: "/home" }
12       - { src: "/tmp/testf2", dest: "/home" }
  • Copie en gardant le propriétaire et les permissions
1 - name: Copy file with owner and permissions
2   copy:
3     src: /srv/myfiles/foo.conf
4     dest: /etc/foo.conf
5     owner: "{{ ansible_user }}"
6     group: "{{ ansible_user }}"
7     mode: '0644'
  • Copier le fichier avec le propriétaire et l'autorisation
1 - name: Copy file with owner and permission, using symbolic representation
2   copy:
3     src: /srv/myfiles/foo.conf
4     dest: /etc/foo.conf
5     owner: "{{ ansible_user }}"
6     group: "{{ ansible_user }}"
7     mode: u=rw,g=r,o=r
  • Autre exemple, l'ajout de certaines autorisations et la suppression d'autres
1 - name: Another symbolic mode example, adding some permissions and removing others
2   copy:
3     src: /srv/myfiles/foo.conf
4     dest: /etc/foo.conf
5     owner: "{{ ansible_user }}"
6     group: "{{ ansible_user }}"
7     mode: u+rw,g-wx,o-rwx
  • Copier un nouveau fichier "ntp.conf" en place, en sauvegardant l'original s'il diffère de la version copiée
1 - name: Copy a new "ntp.conf" file into place, backing up the original if it differs from the copied version
2   copy:
3     src: /mine/ntp.conf
4     dest: /etc/ntp.conf
5     owner: "{{ ansible_user }}"
6     group: "{{ ansible_user }}"
7     mode: '0644'
8     backup: yes
  • Copier un nouveau fichier "sudoers" en place, après avoir passé la validation avec visudo
1 - name: Copy a new "sudoers" file into place, after passing validation with visudo
2   copy:
3     src: /mine/sudoers
4     dest: /etc/sudoers
5     validate: /usr/sbin/visudo -csf %s
  • Copier un fichier "sudoers" sur la machine distante pour l'éditer
1 - name: Copy a "sudoers" file on the remote machine for editing
2   copy:
3     src: /etc/sudoers
4     dest: /etc/sudoers.edit
5     remote_src: yes
6     validate: /usr/sbin/visudo -csf %s
  • Copie en utilisant le contenu en ligne
1 - name: Copy using inline content
2   copy:
3     content: '# This file was moved to /etc/other.conf'
4     dest: /etc/mine.conf
  • Si follow=yes, /path/to/file sera écrasé par le contenu de foo.conf
1 - name: If follow=yes, /path/to/file will be overwritten by contents of foo.conf
2   copy:
3     src: '''/etc/foo.conf'''
4     dest: '''/path/to/link'''  # link to /path/to/file
5     follow: yes
  • Si follow=no, /path/to/link deviendra un fichier et sera écrasé par le contenu de foo.conf
1 - name: If follow=no, /path/to/link will become a file and be overwritten by contents of foo.conf
2   copy:
3     src: '''/etc/foo.conf'''
4     dest: '''/path/to/link'''  # link to /path/to/file
5     follow: no
Exemple Module FILES - suppr
Destination KALI Machine Cible /home/testf2 
 1 --- 
 2 - name: Module file - Supprimer un fichier 
 3   hosts: KALI 
 4   vars: 
 5     fic: /home/testf2 
 6  
 7   tasks: 
 8   - name: Supprimer le fichier 
 9     file: 
10       state: absent 
11       path: "{{ fic }}"
Exemple Module LINEINFILE - Modifier une ligne dans un fichier
Créer un fichier sans lineinfile
1 --- 
2 - hosts: KALI
3   user: root
4  
5   tasks:
6   - name: créer un fichier vide
7     command: /usr/bin/touch /home/testf2
  • OK testé et fonctionnel.
Créer un fichier avec lineinfile
 1 --- 
 2 - hosts: KALI
 3   user: root
 4  
 5   tasks:
 6   - name: Créer un nouveau fichier avec lineinfile
 7     lineinfile: dest=/home/test_lineinfile 
 8                 regexp='^' line='Hello, World!'
 9                 state=present
10                 create=True
  • OK testé et fonctionnel.

cat test_lineinfile 

Hello, World!
  • Un fichier est créé et test est mis en première ligne.
Ajouter une sequence dans un nouveau fichier
 1 --- 
 2 - hosts: KALI
 3   user: root
 4  
 5   tasks:
 6   - name: Ajouter une sequence dans un nouveau fichier
 7     lineinfile: dest=/home/test_lineinfile
 8                 regexp='^'
 9                 line='Hello, World!'
10                 state=present
  • OK testé et fonctionnel.
  • Ajoute le contenu de "line" à la fin du fichier s'il n'y est pas
Ajouter une chaîne multiligne au fichier et supprimer la chaîne d'avant
 1 --- 
 2 - hosts: KALI
 3   user: root
 4  
 5   tasks:
 6   - name: Ajouter une chaîne multiligne au fichier et supprimer la chaîne d'avant
 7   # Attention, avec la regex donnée, la chaîne sera ajoutée à chaque fois que le playbook se déroule 
 8     lineinfile: dest=/home/test_lineinfile 
 9                 regexp='^'
10                 line='#Ceci est un commentaire\n#un autre commentaire\n#Encore un autre commentaire\n#Et encore\n#Le dernier commentaire'
11                 state=present
Ajouter une seule ligne, dans ce cas la même que le commentaire mais sans commentaire
 1 --- 
 2 - hosts: KALI
 3   user: root
 4  
 5   tasks:
 6   - name: Ajouter une seule ligne, dans ce cas la même que le commentaire mais sans commentaire
 7     lineinfile: dest=/home/test_lineinfile
 8                 regexp='^Autre'
 9                 insertafter='^#Autre'
10                 line='Un autre commentaire, qui n'est plus un commentaire'
11                 state=present
Enlever la ligne #Encore un autre commentaire
1 --- 
2 - hosts: KALI
3   user: root
4  
5   tasks:
6   - name: Enlever la ligne #Encore un autre commentaire
7     lineinfile: dest=/home/test_lineinfile
8                 regexp='^#Encore un autre commentaire'
9                 state=absent
Ajouter une nouvelle chaîne de caractères au début du fichier
 1 --- 
 2 - hosts: KALI
 3   user: root
 4  
 5   tasks:
 6   - name: Ajouter une nouvelle chaîne de caractères au début du fichier
 7     lineinfile: dest=/home/test_lineinfile
 8                 regexp='^This'
 9                 insertbefore=BOF
10                 line='This is no longer a comment'
Ajouter une nouvelle chaîne avant la séquence
 1 --- 
 2 - hosts: KALI
 3   user: root
 4  
 5   tasks:
 6   - name: Ajouter une nouvelle chaîne avant la séquence
 7     lineinfile: dest=/home/test_lineinfile 
 8                 regexp='^Another'
 9                 insertbefore='^#Another'
10                 line='Another comment, no longer'
Ajouter une nouvelle chaîne à la fin du fichier
 1 --- 
 2 - hosts: KALI
 3   user: root
 4  
 5   tasks:
 6   - name: Ajouter une nouvelle chaîne à la fin du fichier
 7     lineinfile: dest=/home/test_lineinfile 
 8                 regexp=''
 9                 insertafter=EOF
10                 line='The latest entry'


Exemple Module BLOCKINFILE - Modifier plusieurs ligne dans un fichier ou ajouter/modifier un bloc de lignes
Insérer/mettre à jour le bloc de configuration "Match User" dans /etc/ssh/sshd_config
 1 --- 
 2 - hosts: KALI
 3   user: root
 4  
 5   tasks:
 6   - name: Insert/Update "Match User" configuration block in /etc/ssh/sshd_config
 7     blockinfile:
 8       path: /etc/ssh/sshd_config
 9       block: |
10         Match User ansible-agent
11         PasswordAuthentication no
Insérer/mettre à jour la configuration eth0 dans /etc/network/interfaces
 1 --- 
 2 - hosts: KALI
 3   user: root
 4  
 5   tasks:
 6   - name: Insert/Update eth0 configuration stanza in /etc/network/interfaces
 7         (it might be better to copy files into /etc/network/interfaces.d/)
 8   blockinfile:
 9     path: /etc/network/interfaces
10     block: |
11       iface eth0 inet static
12           address 192.0.2.23
13           netmask 255.255.255.0
Insérer/mettre à jour la configuration à l'aide d'un fichier local et la valider
1 - name: Insert/Update configuration using a local file and validate it
2   blockinfile:
3     block: "{{ lookup('file', './local/sshd_config') }}"
4     path: /etc/ssh/sshd_config
5     backup: yes
6     validate: /usr/sbin/sshd -T -f %s
Insérer/mettre à jour le HTML entouré de marqueurs personnalisés après la ligne <body>.
1 - name: Insert/Update HTML surrounded by custom markers after <body> line
2   blockinfile:
3     path: /var/www/html/index.html
4     marker: "<!-- {mark} ANSIBLE MANAGED BLOCK -->"
5     insertafter: "<body>"
6     block: |
7       Welcome to {{ ansible_hostname }}
8       Last updated on {{ ansible_date_time.iso8601 }}
  • OK testé et fonctionnel.
Supprimer le HTML ainsi que les marqueurs environnants
1 - name: Remove HTML as well as surrounding markers
2   blockinfile:
3     path: /var/www/html/index.html
4     marker: "<!-- {mark} ANSIBLE MANAGED BLOCK -->"
5     block: ""
Ajouter des lignes à /etc/hosts
 1 - name: Add mappings to /etc/hosts
 2   blockinfile:
 3     path: /etc/hosts
 4     block: |
 5       {{ item.ip }} {{ item.name }}
 6     marker: "# {mark} ANSIBLE MANAGED BLOCK {{ item.name }}"
 7   loop:
 8     - { name: host1, ip: 10.10.1.10 }
 9     - { name: host2, ip: 10.10.1.11 }
10     - { name: host3, ip: 10.10.1.12 }
Exemple Module REPLACE - Modifier un ou plusieurs mots dans un fichier
Exemple sans REGEX
  • Enoncé
Destination KALI Machine Cible /home/testf1
Contenu cat /home/testf1 contenu LINE 1
ensuite 2 eme
contenu LINE 3
  • Code
1 --- 
2 - hosts: KALI 
3 
4   tasks: 
5   - name: remplacer 
6     replace: 
7     path: '/home/testf1'
8     regexp: "LINE 1"
9     replace: "LINE"
  • Résultat
Destination KALI Machine Cible /home/testf1
Contenu cat /home/testf1 contenu LINE
ensuite 2 eme
contenu LINE 3
Exemple avec REGEX

Avant la version 2.3, l'option "dest", "destfile" ou "name" était utilisée à la place de "path". 

1 - replace:
2     path: /etc/hosts
3     regexp: '(\s+)old\.host\.name(\s+.*)?$'
4     replace: '\1new.host.name\2'
5     backup: yes

Remplacer après l'expression jusqu'à la fin du fichier (nécessite >=2.4) 

1 - replace:
2     path: /etc/hosts
3     regexp: '(\s+)old\.host\.name(\s+.*)?$'
4     replace: '\1new.host.name\2'
5     after: 'Start after line.*'
6     backup: yes

Remplacer avant l'expression jusqu'au début du fichier (nécessite >=2.4) 

1 - replace:
2     path: /etc/hosts
3     regexp: '(\s+)old\.host\.name(\s+.*)?$'
4     replace: '\1new.host.name\2'
5     before: 'Start before line.*'
6     backup: yes

Remplacer entre les expressions (nécessite >=2.4) 

1 - replace:
2     path: /etc/hosts
3     regexp: '(\s+)old\.host\.name(\s+.*)?$'
4     replace: '\1new.host.name\2'
5     after: 'Start after line.*'
6     before: 'Start before line.*'
7     backup: yes


1 - replace:
2     path: /home/jdoe/.ssh/known_hosts
3     regexp: '^old\.host\.name[^\n]*\n'
4     owner: jdoe
5     group: jdoe
6     mode: 0644


1 - replace:
2     path: /etc/apache/ports
3     regexp: '^(NameVirtualHost|Listen)\s+80\s*$'
4     replace: '\1 127.0.0.1:8080'
5     validate: '/usr/sbin/apache2ctl -f %s -t'

la tâche de forme courte (dans l'ansible 2+) nécessite des séquences d'évitement du backslash 

1 - name: short form task
2   replace: dest=/etc/hosts regexp='\\b(localhost)(\\d*)\\b' replace='\\1\\2.localdomain\\2 \\1\\2'


1 - name: long form task does not
2   replace:
3     dest: /etc/hosts
4     regexp: '\b(localhost)(\d*)\b'
5     replace: '\1\2.localdomain\2 \1\2'

Module COMMAND

Exemple Module COMMAND - Move / Rename
Source KALI Machine Cible /home/testf2
Destination KALI Machine Cible /home/testf20 
 1 --- 
 2 - name: Module command - déplacer/renommer un fichier 
 3   hosts: KALI 
 4   vars: 
 5     fic_src: /home/testf2 
 6     fic_dest: /home/testf20 
 7  
 8   tasks: 
 9   - name: Fichier existe ou pas 
10     stat: 
11       path: "{{ fic_src }}" 
12     register: resultat 
13  
14   - name: deplacer fichier si existe 
15     command: mv "{{ fic_src }}" "{{ fic_dest }}" 
16     when: resultat.stat.exists == True

Ansible et les roles

  • Qu'est ce qu'un role?
    • Les rôles sont une caractéristique robuste d'Ansible qui facilitent la réutilisation, favorisent davantage la modularisation d'une configuration
      et simplifient l'écriture de Playbooks complexes en le divisant logiquement en composants réutilisables et en profiter par la même occasion pour le rendre plus facile à lire.

Création d'un role

ansible-galaxy init <Nom du ROLE>
  • Résultat:

├─── defaults (Contient les variables par défaut pour ce rôle.)
│ └──────── main.yml
├─── files (Contient les fichiers devant être déployés par ce rôle.)
├─── handlers (Contient les fonctions déclenchées par les tâches du rôle ou comme ici pour le rôle commun, dans n’importe quel rôle incluant ce pseudo rôle.)
│ └──────── main.yml
├─── meta (Contient les définitions des méta-données pour ce rôle, c’est à dire définir les dépendances du rôle.)
│ └──────── main.yml
├─── tasks (Contient la liste des tâches devant être effectuées pour ce rôle)
│ └──────── main.yml
├─── templates (Contient les fichiers modèles devant être déployés par ce rôle (interprétés par jinja2))
├─── tests (Contient des tests persos, pas nécessaire !)
│ ├──────── inventory
│ └──────── test.yml
└─── vars (Contient les variables pour ce rôle. Celles-ci sont prioritaire sur celles du répertoire default.)
│ └──────── main.yml
└─── README.md (Contient la liste des tâches devant être effectuées pour ce rôle)

Exemple de role pour créer un utilisateur sur une machine distante
  • Utilisateur test à créer sur la machine KALI avec des droits sudo
  • On appellera ce role create_user.yml
ansible-galaxy init create_user
  • J'ai ainsi ma petite arborescence qui va bien...
    • /etc/ansible
create_user.yml

├── roles

│   ├── create_user

│   │   └── tasks

│   │   │   └── main.yml
  • Fichiers

/etc/ansible/create_user.yml/etc/ansible/roles/create_user/tasks/main.yml

     ---
     - hosts: KALI
       remote_user: root
       become: true

       roles:
       - create_user

---
- name: Generer un mot de passe pour un nouvel utilisateur
  #shell: makepasswd --chars=20
  shell: echo "xxxx"
  register: user_password

- name: Generer un mot de passe crypté
  shell: mkpasswd --method=SHA-512 {{ user_password.stdout }}
  register: encrypted_user_password

- name: Creation du compte utilisateur
  user: name={{ new_user_name }}
  password={{ encrypted_user_password.stdout }}
  state=present
  append=yes
  shell="/bin/bash"
  update_password=on_create
  groups={{ new_user_group }}
  when: new_user_name is defined and new_user_group is defined
  register: user_created

- name: Forcer l'utilisateur à changer de mot de passe au login
  shell: chage -d 0 {{ new_user_name }}
  when: user_created.changed

- name: Utilisateur créé
  debug: msg="Password for {{ new_user_name }} is {{ user_password.stdout }}"
  when: user_created.changed

  • Et la commande qui va bien:
ansible-playbook -i hosts create_user.yml --extra-vars 'new_user_name=gerard new_user_group=sudo,wheel'
  • On créé sur la machine distante un utilisateur "gerard" qui va être dans le groupe "sudo" et "wheel"
Exemple de role pour créer une arborescence sur une machine distante

Ansible et les playbooks

  • Qu'est ce qu'un playbook?
    • Un playbook permet d’exécuter un ensemble de tâches à effectuer sur les machines esclaves de manière séquentielle sur tout ou partie de l’inventaire.
    • Chaque tâche utilise un module d'Ansible.
    • Le playbook est écrit en langage YAML et est constitué au minimum:
      • d'une variable Host qui détermine l'esclave.
      • d'une varible task qui désigne l'action à effectuer.
    • Le playbook peut aussi:
      • Emettre des notifications utiles pour déclencher une action dans certaines conditions.
      • Effectuer des actions conditionnelles selon leurs valeurs.
      • Utiliser des templates pour créer ou modifier des fichiers.

DEFINITIONS

Agent-less

  • On dit qu’Ansible est agent-less, c’est à dire qu’on n’a pas besoin d’installer un agent sur les machines que l’on veut gérer. Les connexions entre Ansible et les noeuds managés s’effectuent à travers SSH. Ansible réalise les tasks en exécutant des scripts Python. Du coup, les machines gérées doivent avoir SSH et Python.

Idempotence

  • Ansible et plus particulièrement ses modules sont idempotentes. Cela signifie qu’une opération donnera le même résultat qu’on l’exécute une ou plusieurs fois. Par exemple, on va vérifier si un utilisateur existe : si c’est le cas, on ne fera rien mais si l’utilisateur n’existe pas alors on viendra le créer.

Inventory

  • La liste des systèmes cibles gérés par Ansible sont appelé un inventaire. On distingue deux type d’inventaire : l’inventaire statique constitué d’un fichier décrivant la hiérarchie des serveurs et l’inventaire dynamique fourni par un système centralisé recensant tous les serveurs de l’infrastructure (ex NoCMDB)

Module

  • Les tâches et les rôles font appel à des modules mis à disposition avec Ansible. Je vous invite à consulter la liste sur le site d’Ansible.

Parallélisme

  • Lorsqu’il y a plusieurs machines à gérer, Ansible se connecte en SSH puis exécute les opérations en parallèle. Cela permet de gagner un temps considérable. Cependant, les tâches sont effectuées dans un ordre définit par l’utilisateur : Ansible attendra d’avoir finit une tâche (sur tous les hôtes) pour passer à la suivante.

Playbook

  • Un playbook est une une séquence de tâches ou de rôles décrits dans un fichier ou format yaml.

Push-based

  • Certains outils tels que Puppet ou Chef sont dits « pull-based« , c’est-à-dire que l’agent va se connecter régulièrement au service central pour vérifier si des modifications ont été apportées à la configuration. Si tel est le cas, ils vont récupérer ces modifications puis mettre à jour leur propre configuration.
  • Quant à Ansible, on dit qu’il est push-based. On sait qu’on n’a pas d’agent installé sur les machines managées donc aucun hôte se connecte au service central pour récupérer les modifications ; les interactions ont lieu dans le sens inverse, c’est-à-dire depuis Ansible vers les nœuds. Les changements sont apportées au niveau du playbook qu’on lance ensuite. Par la suite, Ansible va se connecter aux nœuds managés puis exécuter les opérations qui modifieront la configuration de la machine.
  • Cette approche présente de nombreux avantages : un parc de machines plus facile à gérer car on peut les ajouter/supprimer dynamiquement, pas besoin d’attendre que le nœud managé se connecte pour apporter les modifications.

Rôle

  • Afin d’éviter d’écrire encore et encore les mêmes playbooks, Ansible supporte le regroupement de fonctionnalités spécifiques dans ce qu’on appelle des rôles.

Template

  • Comme son nom l’indique, un template est un modèle permettant de générer un fichier cible. Ansible utilise Jinja2, un gestionnaire de modèles écrit pour Python. Les « Templates » Jinja2 permettent de gérer des boucles, des tests logiques, des listes ou des variable.

Ma config qui fonctionne

  • J'en ai fait des tests, des trucs qui marchaient, d'autres non. Je suis enfin arrivé à créer ce que je voulais.
  • C'est sûr, il y a certainement mieux, mais ça marche !

Rappel sur mon projet

  • J'ai 3 machines virtuelles:
1) Node Manager (Ubuntu), appelée FAMILLE (192.168.0.60/24)
2) Node (Ubuntu), appelée UBUNTU (192.168.0.61/24)
3) Node (Kali Linux), appelée KALI (192.168.0.62/24)
  • J'ai besoin d'envoyer des configurations spécifiques du node manager vers les deux autres nodes, et au besoin si je dois ajouter d'autres machines, je voudrai que leurs configurations soient automatiques et que je n'ai pas tout à me taper à la main.
  • J'ai vu qu'il y avait deux façons d'utiliser Ansible:
    • Sans playbook, en ligne de commande -> Exemple de création d'un user avec un rôle <cliquer ici>
    • Et... avec un playbook.
      • Le playbook, fichier Yaml, qui va appeler des rôles dont celui de création du user.
      • Il est possible de créer directement des fichiers Yaml qui vont installer ce que l'on voudra à la racine Ansible mais dans un but d'organisation et de clarté, il vaut mieux créer des roles indépendants qui auront une fonction et qui seront classés dans le répertoire "roles"
      • Je vais donc jouer avec les playbooks...
  • Postulat de départ:
    • Je considère que la racine de Ansible va se situer où je l'ai installé /etc/ansible

Configuration Ansible

* Fichier Hosts

/etc/ansible/hosts

# This is the default ansible 'hosts' file.
#
# It should live in /etc/ansible/hosts
#
# - Comments begin with the '#' character
# - Blank lines are ignored
# - Groups of hosts are delimited by [header] elements
# - You can enter hostnames or ip addresses
# - A hostname/ip can be a member of multiple groups

# Ex 1: Ungrouped hosts, specify before any group headers.

#green.example.com
#blue.example.com
#192.168.100.1
#192.168.100.10

# Ex 2: A collection of hosts belonging to the 'webservers' group

#[webservers]
#alpha.example.org
#beta.example.org
#192.168.1.100
#192.168.1.110

# If you have multiple hosts following a pattern you can specify
# them like this:

#www[001:006].example.com

# Ex 3: A collection of database servers in the 'dbservers' group

#[dbservers]
#
#db01.intranet.mydomain.net
#db02.intranet.mydomain.net
#10.25.1.56
#10.25.1.57

# Here's another example of host ranges, this time there are no
# leading 0s:

#db-[99:101]-node.example.com

[servers]
FAMILLE ansible_host=192.168.0.60
KALI ansible_host=192.168.0.61
UBUNTU ansible_host=192.168.0.62
PAUL ansible_host=192.168.0.59

[web_servers]
FAMILLE ansible_host=192.168.0.60

[multi]
FAMILLE ansible_host=192.168.0.60

[all:vars]
ansible_python_interpreter=/usr/bin/python3

* Préparation des rôles

  • Aller dans le répertoire /etc/ansible/roles
    • ansible-galaxy init create_user
    • ansible-galaxy init create_repert_mnt
    • ansible-galaxy init fichiers_init
    • ansible-galaxy init host_modif
    • ansible-galaxy init install_progs
    • ansible-galaxy init install_repos
    • ansible-galaxy init modif_fstab
    • ansible-galaxy init modific

Programmation des rôles

Rôle création des utilisateurs

Rôle préparation des repositories

Rôle installation des packages supplémentaires

Rôle préparation des arborescences

Rôle installation des extensions (firefox/thunderbird)

Rôle configuration des fichiers système et environnement

Rôle désinstallation des programmes inutiles

Rôle mise à jour, nettoyage et purge

Programmation du playbook

Récupérée de « https://tarentino.fr/index.php?title=Etude&oldid=3259 »