Archives mensuelles : février 2020

Ingénieur Devops : sa boite à outils

Difficile de dresser une liste complète des outils qu’un devops doit connaître. D’ailleurs on pourrait aussi graduer le niveau requis dans chaque outil. En effet, je pense qu’un devops doit être ce qu’il y a de plus polyvalent et avoir quelques domaines privilégiés.

Sur le papier, certains imaginent le devops comme un MacGyver qui va être capable de faire du dev et de l’ops. Concrètement et au vue des précédents articles et vidéos que j’ai publié vous pouvez vous douter que mon point de vue est un peu différent. En outre, le cloud fait partie e ces outils mais n’est pas impératif.

Rappelons-le, le devops est là pour automatiser et organiser les déploiements pour permettre d’itérer trsè facilement les nouvelles versions de vos services.

Les schedulers ou ordonnanceurs de tâches sont donc inévitables :

  • Jenkins : mon préféré car il repose sur la fondation Apache, possède une grande communauté et est totalement gratuit
  • Gitlab : allie à la fois l’organisation des équipes, les déploiements et le code, il n’y a pas plus complet sauf qu’une partie repose sur la version d’entreprise payante
  • Rundeck : outil gratuit mais moins complet et un peu moins adapté à l’élaboration de pipeline
  • CircleCI : très bon outil assez complet mais avec une version payant à partir d’un certain niveau d’utilisation

Les orchestrateurs pour compléter les ordonnanceurs de tâches :

  • Ansible : de loins mon préféré par sa simplicité et dans un contexte de pipeline de déploiement d’applicatif, simple en python à base de ssh
  • Puppet : plus adapté à de la gestion globale d’une infrastructure
  • Chef : un peu plus complexe et plus adapté à une gestion d’une infra

Les outils de tests :

  • Jmeter : là encore mon préféré issue de la fondation Apache avec une large communauté et gratuit surtout
  • Postman : idéal pour tester des API mais les fonctions les plus intéressantes sont dans la version payante
  • JUnit : pour les tests unitaires du langage Java il existe dans tous les langages ce genre de librairie

Le monitoring, la collecte de métriques ou de logs :

  • prometheus : une base de données timeseries qui scrappe les routes qui lui sont données. Peut être rendu dynamique avec Consul ou le DNS par exemple. N2cessite des exporter pour afficher les métriques sur des routes au format openmetrics.
  • influxdb : une autre base timeseries qui ne scrape pas mais permet une bonne rétention des métriques (sur la durée, à la différence de prometheus).
  • zabbix : très bon outil complet de monitoring et collecte de métriques, fonctionne avec des agents.
  • munin/nagios : solution similaire à zabbix
  • grafana : incontournable pour visualiser des métriques et créer des alertes
  • elasticsearch/logstash/kibana : la triplette la plus puissante en matière de cllecte de logs et de leur analyse sous différentes formes.
  • Netdata : pour disposer de la plupart des métriques de votre machines, s’installe en une simple ligne de commande.

En matière d’organisation de dépôt l’inévitable gitflow qui permet d’organiser ses branches git pour collaborer facilement en équipe tout en ayant une construction robuste d’outils de production.

Les bases de données, en avoir quelques notions :

  • postgresql
  • elasticsearch
  • cassandra
  • mariadb
  • sqlite

Raspberry et Ansible : gestion des clefs SSH et suppression du user par défaut

Précédemment, nous avions découvert comment créer nos users avec ansible. Mais nous avons quelques lacunes avec cette gestion minimaliste des users. En effet, d’une part la connexion ne se fait que par mot de passe (ce n’est pas pratique et très sécurisé). D’autre part, l’existence du user pi est une vraie faille de sécurité. Toute installation d’un raspbian dispose systématiquement de ce user et bien sûr avec le même mot de passe (pratique mais pas sécurisé tout ça).

Création de nos users

Pour cela nous allons industrialiser tout cela avec Ansible. Pour appel, nous avions nos mots de passe stockés sous les varaiables de group_vars/all/all.yml avec ceci :

users_password_xavki: "{{ vault_users_password_xavki }}"
users_password_xavier: "{{ vault_users_password_xavier }}"

Et ces variables faisaient appel à un fichier vault situé au même endroit dans group_vars/all/vault.yml mais chiffré par un mot de passe :

$ANSIBLE_VAULT;1.1;AES256
613362633865666266653364373533323263663137623536316431313933653331336239623437613232343965386434353761386436333663303533653862350a333939363463653663656563643966653035353666623165323434613434616334313163616663643763396635313636323666356437393665366339636561650a623032376634633634353132343539613962306132373230343232306234346664336231343866326532363930303566313262376264383231306664386462303461646432646433386535333432643337613138653365396132386261373362366463646564373830656265613239366334636361336462313039323064666432646161326463666635366663313539303136313965623430386435303466386634663161393438363134376138393137373033323565353065383465356638

Maintenant créons un répertoire dédié au stockage de nos clefs publiques (PUBLIQUES j’insiste) : files. Il s’agit des clefs que nous allons diffuser et installer dans la home de nos users. S’agissant de clefs publiques, un chiffrement n’est pas nécessaire, seule la clef privée est d’une importance capitale.

Maintenant modifions notre playbook de création des users :

- name: deploy users
  hosts: all
  become: yes
  vars:
    users_admin:
    - { name: "xavki", password: "{{ vault_users_password_xavki }}" }
    users_no_admin:
    - { name: "xavier", password: "{{ vault_users_password_xavier }}" }
  tasks:
  - name: create group admin
    group:
      name: "admin"
      state: present

  - name: create admin user accounts
    user:
      name: "{{ item.name }}"
      password: "{{ item.password | password_hash('sha512')}}"
      groups: "admin"
    with_items:
    - "{{ users_admin }}"
    no_log: true
 
  - name: create standard user accounts
    user:
      name: "{{ item.name }}"
      password: "{{ item.password | password_hash('sha512')}}"
    with_items:
    - "{{ users_no_admin }}"
    no_log: true

  - name: add authorized keys
    authorized_key:
      user: "{{ item.name }}"
      key: "{{ lookup('file', 'files/'+ item.name + '.key.pub') }}"
    with_items: 
    - "{{ users_admin }}"
    - "{{ users_no_admin }}"
 
  - name: "Allow admin users to sudo without a password"
    lineinfile:
      dest: "/etc/sudoers"
      state: "present"
      regexp: "^%sudo"
      line: "%admin ALL=(ALL) NOPASSWD: ALL"

La tâche « add authorized keys » nous permet donc de récupérer ces clefs et de les placer par défaut dans la hoem de chaque users et selon la bonne pratique avec un répertoire « .ssh ».

Voici donc pour le déploiement de nos clefs correspondantes pour chaque utilisateurs.

Retrouvez les fichiers ici.

Suppression du user PI

Pour supprimer un utilisateur, la démarche est très simple, il suffit d’ajouter la tâches suivante :

- name: remove pi user
  user:
    name: "pi"
    state: absent

Profitons-en pour faire un peu d’organisation et de bonnes pratiques ansible. Pour cela nous allons utliser le principe de rôle. Un rôle est une sorte de module/librairie/fonction qui peut être appelé autant que nécessaire.

Pour cela nous allon créer un répertoire « roles » à la racine de notre ansible et taper la commande :

mkdir roles && cd roles
ansible-galaxy init users

Cette commande créée toute la structure nécessaire pour créer le contenu d’un rôle. A l’heure actuelle ce qui nous intéresse c’est uniquement le répertoire task et son fichier main.yml. C’ets la première chose qui est appelé quand on lance un rôle. Donc dans ce fichier nous recopions le conteneur de notre users.yml.

Ensuite il nous faut modifier notre playbook pour appeler le rôle et non plus les tâches une à une :

- name: deploy users
  become: yes
  hosts: all
  roles:
  - users

Et voilà le tour est joué. il ne reste plus qu’à jouer le playbook :

ansible-playbook -i list_servers.yml -u xavki users.yml

Retrouvez les fichiers ici.

Le déploiement applicatif qui se reconstruit

Déployer et itérer c’est le leitmotiv actuel. De nombreuses sociétés éprouvent le besoin de pousser de nombreuses versions de microservices. Et c’est un des atouts des microservices, réduire l’étendu d’un code pour permettre son évolution plus rapide. Les microservices apportent en même temps des évolutions en terme d’organisation et plusieurs méthodes en sont le fruit : agile, scrum…

Eh oui le besoin actuel est de pousser le plus rapidement possible en production avec des risques limités. Mieux il s’agit de mettre en place des processus qui permettront de s’améliorer par l’erreur. Certaines sociétés comme Netflix ont même placé au cœur de leur infrastructure la nécessité de les éprouver fortement avec des chaos monkey. Il s’agit de fermé tomber des serveurs, des datacenters voir des zones entières à la manière où un singe arracherait les fils dans vos baies.

L’organisation est donc un point clef de la réussite en plus de la transformation technologique.

Pour revenir sur les microservices, ils permettent de passer d’une organisation horizontale à une organisation verticale. Le mode horizontal rassemblait dans une même équipe les sysadmin puis dans une autre les développeurs etc. Avec un système vertical par microservices une team est construite avec chaque corps de métier dont le but sera de produire une nouvelle version de l’application avec des évolutions courtes en terme de délais (les sprints).

Créez et automatiser son infrastructure sur Raspberry

Raspberry, ces micro-serveurs qui permettent de prendre de plus en plus de plaisir depuis la version 4 et ses 4 gigas de RAM. Pour un coût économique, vous pouvez vous faire plaisir et jouer les sysadmin à domicile. Un bon moyen d’apprendre quelques astuces et bonnes pratiques.

Alors certes, vous allez y passer du temps mais vous allez y prendre du plaisir. en plus pour une fois vous serrez le seul à décider de ce que vous faites et comment vous le faites.

Je vous propose donc une série dédiée à l’automatisation sur raspberry d’une petite infra web.

Les users pour commencer

Avant d’arriver sur un serveur, vous devez au moins y accéder en ssh. Mais pas question d’utiliser le user par défaut raspberry. Il est logique de se créer ses propres users et de supprimer ce user raspberry qui représente un grand risque de sécurité car présent sur tous les raspberry.

Mais on va quand même pas se palucher ça à la main ? et non ansible est là pour vous aider.

Ansible : l’automatisation

Très simplement ansible va vous permettre de mettre en place votre infrastructure. Et rien de tel que de créer des users pour le faire.

Pour débuter notre formation, nous allons découvrir l’inventory. Il s’agit de la liste de serveurs qui peut être décrite soit en yaml ou en json. Personnellement je préfère le format yaml que l’on retrouve dans tous les autres fichiers ansible.

Et voici ce que donne mon inventory :

all:
  children:
    door:
      hosts:
        192.168.1.31:
    back:
      hosts:
        192.168.1.41:
        192.168.1.42:

Notre fichier playbook va pour l’instant simplement décrire les tâches réalisées en appelant des modules.

- name: deploy users
  hosts: all
  become: yes
  vars:
    users_admin:
    - "xavki"
    users_no_admin:
    - "xavier"
  tasks:
  - name: create group admin
    group:
      name: "admin"
      state: present

  - name: create admin user accounts
    user:
      name: "{{ item }}"
      groups: "admin"
    with_items:
    - "{{ users_admin }}"
 
  - name: create standard user accounts
    user:
      name: "{{ item }}"
    with_items:
    - "{{ users_no_admin }}"

  - name: add authorized keys
    authorized_key:
      user: "{{ item }}"
      key: "{{ lookup('file', 'files/'+ item + '.key.pub') }}"
    with_items: 
    - "{{ users_admin }}"
    - "{{ users_no_admin }}"
 
  - name: "Allow admin users to sudo without a password"
    lineinfile:
      dest: "/etc/sudoers"
      state: "present"
      regexp: "^%sudo"
      line: "%admin ALL=(ALL) NOPASSWD: ALL"

Source : https://gitlab.com/xavki/raspberry-tricks/-/tree/master/1-create-users