Network/Juniper/Survival guide
Sites Références
Notes
There are several acronyms for interface types and components:
* IFD – Interface Physical Device * IFL – Interface Logical Device * IFF – Address Family * IFA – Address Entry
Common interface names are:
* ge – Gigabit ethernet * xe – 10G ethernet * et – 100G ethernet * ae – aggregated ethernet (LAG/etherchannel) * vlan or irb – Logical interface based on VLAN
SFP’s can be of different speeds (eg, one may be 1G, and another may be 10G). So be aware that the interface names may change based on the SFP used.
The interface naming convention is type-x/y/z
Type is ge, xe, etc x – FPC (aka linecard) y – module or slot z – port number
There are several names for management interfaces. Each platform may use different names. These include fxp0, em0, me0, and vme0. Some of these are physical, and others are virtual.
Some interfaces, such as pimd, pime, dsc, ipip, and gre, are special interfaces that are used for special purposes.
An unnumbered interface does not have an IP address. This helps conserve IP addresses.
All interfaces are configured with a unit. This contains logical interface information, like addressing. Sometimes this is used to create sub-interfaces. Physical properties (duplex, link speed, etc) are not configured in the unit.
Each unit may have one or more family. This is where the address is applied. For example, the inet family is for IPv4 addressing.
Addresses can be primary, preferred, or secondary. Primary addresses are used for locally sourced (broadcast or multicast) traffic, destined to a remote subnet. Preferred addresses are for locally sourced traffic to the local subnet.
Configuring voice ports means three main steps:
* Configuring a voice VLAN * Configuring PoE * Configuring LLDP-MED
Junos supports regex during configuration.
[user@demo project2]$ tree -F group_vars
group_vars/
├── db_servers/
│ ├── 3.yml
│ ├── a.yml
│ └── myvars.yml
├── lb_servers/
│ ├── 2.yml
│ ├── b.yml
│ └── something.yml
└── web_servers/
└── nothing.yml
Command Summary
| Juniper OS Command summary | ||
|---|---|---|
| Command | Mode | Description |
show interfaces terse
|
operational | Get a simplified view of all interfaces on the system |
show interfaces [extensive]
|
operational | Get interface statistics |
ansible_port
|
Port utilisé par Ansible pour se connecter à l'hôte géré. Pour le plug-in de connexion par SSH (par défaut), la valeur par défaut est 22. | |
ansible_user
|
Utilisateur dont se sert Ansible pour se connecter à l'hôte géré. Le comportement par défaut d'Ansible est de se connecter à l'hôte géré à l'aide du même nom d'utilisateur que celui qui exécute le playbook Ansible sur le noeud de contrôle. | |
ansible_become_user
|
Une fois qu'Ansible s'est connecté à l'hôte géré, il bascule vers cet utilisateur en utilisant absible_become_method (qui est sudo par défaut). Il se peut que vous deviez vous procurer des informations d'identification d'authentification de quelque façon que ce soit.
| |
ansible_python_interpreter
|
Chemin d'accès à l'exécutable Python qu'Ansible doit utiliser sur l'hôte géré. Sur Ansible 2.8 et versions ultérieures, cette valeur par défaut est auto, qui sélectionne automatiquement un interpréteur Python sur l'hôte exécutant le playbook en fonction du système d'exploitation qu'il exécute. Ainsi, il n'est plus autant nécessaire d'utiliser ce paramètre que dans les versions antérieures d'Ansible.
| |
Variables utilisées lors d'exécution de playbooks
Lorsqu'un play est en cours d'exécution, un certain nombre de variables et de faits peuvent être utilisés pour identifier le nom de l'hôte géré actuel qui exécute une tâche :
| Variables Ansible spécifiques à l'exécution | |
|---|---|
| Variable | Description |
inventory_hostname
|
Nom de l'hôte géré en cours de traitement, extrait de l'inventaire. |
ansible_host
|
Adresse IP ou nom d'hôte réel qui a été utilisé pour se connecter à l'hôte géré, comme indiqué
précédemment. |
ansible_facts ['nom d'hôte']
|
Nom court (non qualifié) de l'hôte collecté comme un fait de l'hôte géré. |
ansible_facts ['fqdn']
|
Nom de domaine complet de l'hôte collecté comme un fait de l'hôte géré. |
ansible_play_hosts
|
liste de tous les hôtes qui n'ont pas encore échoué au cours du play actuel (et qui, par conséquent, sera utilisée
pour les tâches restantes du play).|} |
Penser ré-utilisabilité !
Les rôles permettent de créer des playbooks simples et de réutiliser du code commun à plusieurs projets. Un role doit porter sur un objectif ou une fonction spécifique.
Idéalement, il est préférable de créer des rôles génériques configurables par le biais de variables. Ces variables sont le plus souvent définies par défaut dans le fichier YAML roles/[nom_role]/default/main.yml
De cette façon, un rôle disposant de son propre paramétrage et ensemble de tâches peut facillement être intégré dans un autre playbook.
Si un playbook doit modifier le contenu d'une variable définie par un rôle, il suffit :
- soit inclure un fichier de définition de variables au niveau du playbook (cf
var_files) - soit définir une zone tasks
vars:qui remplace le contenu de cette variable. (cf Ordre de précédence des variables dans un playbook ansible)
Exemple
- hosts: webservers
vars:
apache2_config: true
apache2_default_port: 8000
roles:
ansible-apache2Ce playbook utilise le rôle ansible-apache2 en modifiant 2 variables utilisées par ce rôle : apache2_config & apache2_default_port.
A l'éxécution de ce playbook, le service apache2 sera installé sur les serveurs webservers pour écouter sur le port 8000/tcp.
Exécution centralisée des playbooks
Pour contrôler l'accès aux systèmes et auditer l'activité d'Ansible, il est nécessaire d'envisagez l'utilsiation d'un serveur de contrôle dédié à partir duquel tous les playbooks Ansible sont exécutés.
Les administrateurs système doivent toujours disposer de leurs propres comptes sur le système, ainsi que des informations d'identification permettant de se connecter aux hôtes gérés et d'augmenter les privilèges, si nécessaire.
Lorsqu'un administrateur système cesse de travailler sur le projet, sa clé SSH peut être supprimée du fichier authorized_keys de l'hôte géré et ses privilèges de commande sudo peuvent être révoqués, sans répercussion sur les autres administrateurs.
Ce serveur central peut avantageusement héberger les services awx ou la version supportée par Red Hat Ansible Tower
Tester régulièrement
Il est bien évident qu'il faut tester les playbooks aussi bien au cours de la phase de développement que pendant l'exécution des playbooks eux-même. En effet, Ansible offre cette possibilité de s'auto-valider en définissant des tâches spécifiques permettant de vérifier une étape précédente d'un playbook.
Test des résultats des tâches
Si on a besoin de confirmer la réussite d'une tâche, vérifiez le résultat de la tâche au lieu de faire confiance au code de retour du module. Il existe plusieurs moyens de valider une tâche, en fonction du module concerné.
Exemple :
- Start web server
service:
name: httpd
status: started
- name: Check web site from web server
uri:
url: http://{{ ansible_fqdn }}
return_content: yes
register: example_webpage
failed_when: example_webpage.status != 200
Utilisation de block/rescue pour effectuer une récupération ou une restauration
La directive block est utile pour regrouper des tâches ; lorsqu'elle est associée à la directive
rescue, elle est utile lorsqu'il s'agit d'effectuer une récupération après des erreurs ou des pannes.
Exemple :
- block:
- name: Check web site from web server
uri:
url: http://{{ ansible_fqdn }}
return_content: yes
register: example_webpage
failed_when: example_webpage.status != 200
rescue:
- name: Restart web server
service:
name: httpd
status: restarted
Outils de test
ansible-playbook --syntax-check: pour vérifier la syntaxe d'un playbook (sans l'exécuter)ansible-playbook --check: Exécute un playbook en mode "vérification"
|
|
