IaaC : Infrastructure as a code.

Si vous êtes sys/netadmin, cette expression vous est peut-être apparue ces dernières années : L’Ia(a)S ou Infrastructure as (a) code. De quoi parle-t-on ? C’est Amazon Web Services qui, le premier a lancé ce terme lié à l’automatisation de l’infra. Dans la logique Devops qui veut que les équipes devs et les équipes ops se rapprochent, il s’agit de mettre en place des infrastructures (systèmes, réseaux, virtualisation, etc.) qui se manipulent comme du code. »

Gestion des équipements Cisco avec Ansible

Il y a quelque temps j’avais écris un script pour envoyer des commandes sur une flotte de switches Cisco. Il fonctionne toujours et se trouve sur mon serveur Git. Depuis sa version 2.3, Ansible a fait de gros efforts pour pouvoir gérer les équipements réseaux des principaux constructeurs. C’est tout bénéfice : un outil pour les gouverner tous.   Les modules sont documentés sur cette page.   Enjoy ! »

Ansible Playbook #2 : Post-install des VMs KVM

Quand vous faites de la virtualisation, il y a toujours quelques tâches à faire pour optimiser les VMs. Ce playbook ansible tout simple permet d’ajouter les drivers de virtualisation qu’utilise KVM. Les variables sont déclarées en tête de playbook et appelées par les deux tâches par la suite (ou comment faire une boucle Ansible).   --- - hosts: vms remote_user: superman sudo: yes vars: - drivers: [ 'acpiphp' , 'virtio' , 'virtio_ring' , 'virtio_balloon' , 'virtio_net' , 'virtio-rng' , 'virtio_blk' , 'virtio_pci', 'virtio_scsi'] tasks: - name: VM's drivers in /etc/modules lineinfile: dest=/etc/modules line={{item}} with_items: drivers - name: Enable VM's drivers now! »

Ansible Playbook #1 : Changer un mot de passe

Aujourd’hui, je démarre une série d’articles sur quelques playbooks Ansible, simples et indispensables.   Changer le mot de passe d’un utilisateur   Qu’est ce qui se passe si votre collègue a laissé traîner son mot de passe sur un post-it que vous avez retrouvé à la machine à café (non, ce n’est pas du vécu). Pour changer le mot de passe d’un utilisateur avec Ansible il faut d’abord générer un mot de passe au format SHA-512 (pour éviter de faire transiter le mot de passe en clair). »

Ils tournent tous, tes serveurs ?

Et soudain, paf ! Coupure électrique. Bon d’accord, les switchs sont ondulés, les serveurs double-alimentés. Mais quand même, loi de Murphy oblige, je sens que ce matin, les coups de fils vont être plus nombreux et plus affolés que d’ordinaire. Que nenni, Ansible va me permettre de prendre mon café tranquillement : Dans le fichier /etc/ansible/playbooks/ping-all.yml : --- - hosts: all vars: remote_user: admin tasks: - name: Ping the world ping: Et c’est parti pour un tour : »

Post-installation de Debian avec Ansible

Un petit fichier Ansible qui permet la post installation de Debian. Pour l’utiliser, il vous faut avoir installé Ansible et configuré les postes à administrer et connaître l’utilisation de base d’Ansible. Pas grand chose de particulier dans ce fichier : J’utilise une variable nommée soft pour l’installation des logiciels : apt: name={{item.soft}} J’utilise les modules apt pour l’installation de logiciels, lineinfile pour modifier des fichiers de conf, service pour redémarrer des services C’est simple et ça marche. »

Les premiers playbooks Ansible

Si vous suivez mon blog, vous savez pourquoi Ansible, c’est bien, comment l’installer et le tester. Maintenant on va passer aux choses sérieuses : Utiliser les playbooks.   Playbooks ???   Les playbooks sont des scénarii dans lesquels sont décrits des actions que les « agents » doivent réaliser. Ces playbooks sont écrits en YAML, donc ils sont très lisibles.   Réparer Shellshock   Sur le « serveur » Ansible créer un fichier /etc/ansible/playbooks/shellshock-patch. »

Installation et configuration basique d'Ansible

J’ai présenté l’autre jour Ansible comme une très bonne solution d’automatisation. Ansible fonctionne par SSH avec des scripts écrits en Python. Il n’y a pas d’installation d’agent. J’utilise quand même le terme « serveur » pour la machine sur laquelle Ansible est installée et « agents » pour les machines à automatiser par Ansible.   Installation du « serveur » Ansible :   apt-get install python-pip sudo pip install ansible adduser ansible adduser ansible sudo su - ansible   »

Ca y est, c'est Ansible qui fait le boulot

C’est fait, mes serveurs sont administrés avec Ansible. Pour ceux qui ne le connaisse pas, Ansible est un outil d’automatisation de serveurs. Logiciel libre, écrit en Python, à destination des serveurs sous Unix/Linux et maintenant également sous Windows. Ansible est très bien documenté. Ça sert typiquement quand on veut éviter de mettre à jour bash tous les 3 jours sur 50 serveurs d’O.S. variés ! – 1ère faille dans Bash : « Arghhhh, il faut remettre à jour tous les serveurs » (1 journée de travail de cheval de trait) »

Ah si j'avais eu Ansible

Comme certains d’entre vous, j’ai passé une partie de mon jeudi à mettre à jour des bash dans mes différents Linux (et je vous passe les BSD, HP-UX et autres joyeusetés). Sur les matériels réseau, j’avais déjà parlé d’expect, une librairie Python qui permet d’administrer en masse. En administration système, Ansible est tout à fait adapté. Bien configuré, on peut faire ça, juste en appuyant sur entrée. Vous aussi, armez vous pour la prochaine fois (d’autant qu’en ce moment, ça y va les grosses failles). »