Archives de l’auteur : xavki

Les LiveKi semblent plaire ?

Comme je le disais lors du précédent article, le blog va s’orienter vers le backend de la chaine. C’est donc l’occasion de parler des évolutions de ce qui me trotte dans la tête.

Le premier live jusqu’à l’euphorie

Il y a bientôt un mois et demi je commençais avec un premier live. Et j’avoue que pour cette première je me demandais ce que j’allais pouvoir raconter. Car les lives youtube que je connais son souvent centré sur le youtubeur. Je voulais éviter cela mais je ne pense pas avoir réussi.

Néanmoins, cela a été pour moi une découverte, celui de l’intérêt que porte les gens à la chaîne à ce projet même si je le conçois pas comme tel. Et j’avoue que cela m’a donné un gros coup de boost. Se rendre compte à quel point les gens me considéraient et attendent beaucoup de choses tout en voulant faire partie d’une aventure.

Ce live a duré plus de 3h30, un truc de dingue sachant que j’étais tout seul devant l’écran. Mais je n’étais pas tout seul loin de là. Au bout de 3h30, 50 personnes étaient encore connectées au live !!! Je savais que le thème devops était à la mode mais là. J’ai fermé le live et je n’ai pas pu dormir, trop d’excitation. Une espèce de montée de joie en soit, comme si j’avais atteint un résultat que je ne m’aurais jamais cru capable de faire.

Après coup j’ai tenté d’analyser un peu la chose. Il y avait très certainement cet effet de la première du live. Votre volonté de vouloir en savoir plus sur moi, mes motivations, un peu d’échanges sur les technos. Néanmoins je me suis dit ne fait pas des lives tout seul, c’est un peu comme se centrer sur toi.

Et pour la deuxième ? le premier LiveKi

Pour le second j’avais plusieurs choses à valider :

  • mettre en place un rendez-vous régulier : chaque début de mois
  • un nom qui permet de rapidement identifier de quoi on parle
  • ne pas se centrer sur soi
  • pourquoi pas devenir une sorte de média et permettre encore plus d’échanges

La réponse a été le liveki, par son nom, par sa fréquence et surtout les invités. Et une fois de plus j’ai de la chance. La chaine m’a permis depuis un an et demi de me créer un petit réseau de connaissances très sympathiques et intéressantes.

Des passionnés avec chacun leurs spécificités et un point commun la gentillesse et le partage. Du coup la soirée a été dense une fois de plus avec plus de 4h de liveki. Je les remercie tous :

  • Steve Destivelle pour avoir participé à toute la soirée, pour son accompagnement. Bien sûr Steve est une personne à haute qualité technique autour du monitoring et principalement de Zabbix. Merci Steve !
  • François Mocq, la référence française en matière de raspberry avec des livres, son site framboise314 et nombreuses autres cartes dans sa poche. Passionnant tout simplement.
  • Christope Chaudier, alias monsieurs les Compagnons du devops. Formidable encore de pouvoir partager avec quelqu’un de passionner par cette thématique. Et on a pu apprécier son recul, sa franchise et sa volonté de défendre les valeurs nationales dans le domaine du numérique. Bravo Christophe.
  • Thomas alias Cocadmin. Youtubeur très connu avec ses vidéos qui partent très souvent d’une expérience vécue. Son partage d’expérience est très appréciée. Et on a pu apprécier sa décontraction et sa capacité à parler de sujets divers et variés.

Et pour le troisième ?

Cette page du deuxième liveki se tourne donc pour commencer à penser au troisième. Steve a proposé de monter un petit concours pour gagner une mug zabbix. Et je pense qu’il a peut être initié quelque chose.

L’idée de mettre en place des concours peut faire son chemin. Et peut être même un peu plus suivant l’engouement. Et pourquoi pas gagner des livres ??

D’ailleurs cela m’a donné des idées sur les modalités de tirage au sort. Avec dans un premier temps un simple script python… mais pourquoi pas joindre l’agréable et le pédagogique à cela ? du microservice ? même si c’est superflu cela permettrait d’aborder des sujets techniques et de les vulgariser en s’amusant.

Vers un média devops ?

L’évolution vers laquelle je veux aller est de maintenir l’aide à monter en compétence. Via les tutos c’est certains mais peut être évoluer avec d’autres contenus. C’est déjà le cas avec les vidéos de Kevin le créateur de Kaisen Linux et de Jérôme Bezet-Torres pour Active Directory et powershell.

Et on va continuer dans ce sens. Après avoir passé quelques entretiens de recrutement, je suis persuadé que ces rendez-vous ne sont pas toujours facile à vivre. On est technique mais on est pas forcément à l’aise pour raconter sa vie. Et pour cela j’ai pris contact avec des ami(e)s recuteurs et je pense que l’on pourra compiler des vidéos de conseils sans polluer la chaine. Au contraire cela sera le bon endroit pour distribuer des conseils avisés dans la gestion de carrière.

Voilà c’est sur toutes ces notes que je vous dis à très bientôt. Prenez soin de vous, de vos proches, prenez du plaisir à ce que vous faites.

Trop de technos pour être partout…

Aujourd’hui, c’est très compliqué de suivre les technologies. D’une part, certaines d’entre elles sont en pleine explosion (cloud, kubernetes). D’autre part, il y en a de tous les côtés. Difficile de savoir parfois d’ailleurs laquelle sera celle qui sera adoptée par tous demain.

Et ce blog est difficile à maintenir pour moi. Je ne parviens jamais à y mettre des tutos et autres notes que j’aimerais voir dedans.

Ainsi, je me suis demandé si je ne devais pas le réorienté. Et finalement c’est peut être la solution. En effet, la chaine youtube Xavki marche bien et finalement je m’y retrouve suffisament pour avoir besoin d’en rajouter à côté.

Du coup, je vais réorienter le blog vers… le blog de la chaine Xavki. A savoir les sujets qui me trottent dans la tête, les évolutions, mes interrogations etc… Bref plus les dessous de la chaine. Cela me semble sympa aussi de partager dessus.

Et c’est un bon début pour commencer d’expliquer pourquoi je propose à des personnes autres que moi d’intervenir sur la chaine. A cela plusieurs raisons :

  • je ne peux pas couvrir tous les sujets : c’est un fait et je dois l’intégrer dans ma petit tête lol
  • certains sujets ont besoin d’experts
  • plus d’auteurs = plus de diversité = élargir ses points de vues
  • plus d’auteurs = plus de contenus
  • faire connaître d’autres personnes par l’influence de la chaine

Ouverture des festivités donc avec l’interviex de Kevin Chevreuil le concepteur/créateur de Kaisen Linux, un OS basé sur debian.

Dans cette vidéo, vous pourrez découvrir comment Kevin a eu l’idée de créer son OS et vous le verrez c’est un vrai passionné, c’est le moins que l’on puisse dire.

Bien sûr nous reverrons Kevin pour de nombreuses vidéos.

Travailler son côté devops sur son laptop

Alors oui on peut aujourd’hui avec le cloud faire du devops un peu partout et de très nombreuses manières différentes. Là je vous propose de vous monter une infrastructure assez légère qui va vous permettre d’avoir en quelques secondes différents environnements, une registry docker, gitlab, jenkins et de la base de données.

Vagrant c’est l’outil que je vous invite de découvrir. Un très bon outil comme hashicorp sait le faire même si ce n’est pas son produit phare. Dans notre cas nous allons le coupler à virtualbox, un système de virtualisation assez commun à de nombreux systèmes d’exploitation.

Comment allons nous penser celà ? retrouvons cela en vidéo.

Un peu de gitflow dans votre CI/CD

Devenir devops, cela passe par l’acquisition de nombreuses compétences. Il y en a tellement qu’il est bien difficile de se fiwer une liste. Au mieux on peut se fixer les grandes lignes et comme nous l’avons lors d’un précédent article, se fixer une liste de type d’outils.

Mais un devops doit aussi être adepte de certaines méthodes de travail (agile, scrum…). Gitflow fait partie des méthodes de développement à cheval entre l’utilisation d’un outil technique comme git et l’organisation d’une équipe (ou de plusieurs).

Avec GitFLow, vous organisez le travail en équipe pour développer et bien sûr en utilisant git. Le principe est simple, utiliser plusieurs branches pour symboliser les différentes étapes majeures du développement (que ce soit des outils applicatifs métiers ou encore des outils d’infrastructures).

Git flow est souvent représenté par le schéma suivant :

Chaque ligne représente une branche :

  • features : les branches de développement « individuelles »
  • develop : la branche dans laquelle les développeurs mergent leur travail quand il estime qu’il est réalisé (éventuellement via merge request)
  • release : il s’agit de la branche à partir de laquelle on va estimer si la version est bonne (à l’issue de tests…)
  • master : ou branche de production
  • hotfix : dans le cas d’une nécessité de correction rapide suite à incident

Gitflow consiste donc à organiser le processus de développement et avancer dans ce process via des merges.

Raspberry, déploiement de vos règles iptables avec Ansible

Lors d’un précédent article et d’une précédente vidéo, nous avions découvert comment commencer à sécuriser vos raspberry avec iptables. Ce firewall natif à Linux se configure très facilement et est d’une efficacité redoutable.

Néanmoins, déployer les règles à la main ce n’est pas pratique en cas de nécessité de reconfigurer vos serveurs. Mais pour éviter ce genre de problème nous allons continuer à développer nos rôles ansible. Notre objectif est de disposer d’une infrastructure de plusieurs raspberry. Pour cela, nous configurons un bastion qui servira comme point d’entrée ssh pour rebondir les autres serveurs de notre infra.

Si vous le souhaitez vous pouvez retrouver tous les éléments sur ce dépôt.

L’inventory

Peu d’évolution sur notre inventory qui permet de faire la dictinction entre bastion et serveurs simples.

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

Le rôle iptables : firewall

Notre rôle va servir à configurer simplement notre bastion. Nous verrons dans un prochain article comment configurer notre firewall pour les autres serveurs ?

- name: install iptables-persistent
  apt:
    name: iptables-persistent
    state: present

- name: only me
  iptables:
    chain: INPUT
    protocol: tcp
    destination_port: 22
    source: 192.168.1.1/24
    jump: ACCEPT

- name: specific
  iptables:
    chain: OUTPUT
    protocol: tcp
    destination_port: 22
    jump: ACCEPT

- name: icmp accept
  iptables:
    chain: INPUT
    protocol: icmp
    jump: ACCEPT

- name: icmp accept
  iptables:
    chain: OUTPUT
    protocol: icmp
    jump: ACCEPT

- name: Allow related and established connections
  iptables:
    chain: INPUT
    ctstate: ESTABLISHED,RELATED
    jump: ACCEPT

- name: Allow related and established connections
  iptables:
    chain: OUTPUT
    ctstate: ESTABLISHED,RELATED
    jump: ACCEPT

- name: Set the policy for the INPUT chain to DROP
  iptables:
    chain: OUTPUT
    policy: ACCEPT

- name: Set the policy for the INPUT chain to DROP
  iptables:
    chain: INPUT
    policy: DROP

- name: Set the policy for the INPUT chain to DROP
  iptables:
    chain: FORWARD
    policy: DROP

- name: persistent rules
  shell: iptables-save > /etc/iptables/rules.v4

1ère étape : nous installons iptables-persistent qui nous permet de rendre nos règles durables dans le temps. De base, iptables ne garde pas ses règles en cas de reboot. C’est ballot mais c’est comme ça. Iptales-persistent va maintenir les règles présentes dans un fichier de configuration. Pour nous ce sera /etc/iptables/riles.v4. Npus l’alimentons dans la dernière ligne de notre rôle en utilisant le module shell et en lançant iptables-save.

2ème étapes : pour notre notre bastion, il est nécessaire d’accepter les entrées de notre réseau local sur le port 22 (ssh). Idem

3ème étape : on accepte la sortie de notre bastion avec le port 22

4ème étape : on accepte les entrées/sorties pour les ping (icmp)

5ème étape : toutes les connexions établies sont maintenues

6ème étape : on peut accepter toutes les sorties mais à ajuster avec l’étape précédente

7ème étape : on refuse toutes les autres entrées et les forward

Iptables pour sécuriser votre raspberry pi

Sécuriser… un sujet préoccupant et qui est important lorsque l’on dispose de son infrastructure locale. Un des outil sà utiliser pour mettre en place quelques règles de base c’est bien sûr le firewall. Pour cela nous allons utiliser iptables.

Iptables permet de définir un firewall local très facilement. De base, il est présent sur linux et ne nécessite pas d’installation particulière, Raspbian en dispose donc. Reste néanmoins à créer les règles qu’il faut pour sécuriser nos raspberry.

Localement, j’ai choisi de créer un bastion. Commençons par configurer celui-ci via la ligne de commande avant de passer dans une prochaine étape au déploiement automatique des règles.

Voici donc les règles que je vous propose et dans l’ordre que je vous propose :

  • accepter les connexions ssh (port 22) entrantes via notre réseau local 192.168.1.0/24
  • accepter les pings (icmp) entrants
  • toutes les connexions établies doivent être assurées (acceptation en entrées et sorties)
  • accepter de sortir via le ssh et les pings
  • enfin après ces règles, refuser toutes les entrées et les forwards mais accepter toutes les sorties

Cela se traduit par les commandes iptables :

iptables -A INPUT -s 192.168.1.0/24 -p tcp -m tcp --dport 22 -j ACCEPT
iptables -A INPUT -p icmp -j ACCEPT
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

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 de raspberry. 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

Définition du devops : entre technique et histoire

Mouvement, philosophie, initulé de poste… tout le monde y va de sa petite définition. Alors finalement pas de raison que je ne fasse pas la mienne après la lecture de plusieurs livres sur le sujet et pas mal de vidéos et autres articles en ligne.

En route vers le devops…

Avant le devops ?

Sysadmin versus developpeurs lol. C’est souvent le résumé qu’en font certaines personnes. Un clivage entre deux modes de pensées certes mais avec des raisons justifiées des deux côtés (il n’est pas question de jeter la pierre à l’un ou à l’autre) :

  • developpeur : on te demande de faire preuve d’innovation, d’aller toujours plus vite et d’inventer de nouvelles solutions
  • sysadmin : ta tâche est ardue pour permettre de maintenir une plateforme dans un état de production avec une stabilité infaillible bien souvent contre tous

Bref un problème que n’ont pas souvent réussis à résoudre les managers car finalement les objectifs doivent tous être réalisés. C’est ainsi qu’est né le devops mi-sysadmin mi-dev. Mais finalement est-ce vraiment bien cela dont on attend de lui ?

Automatiser les déploiements

En partie oui mais pas seulement. D’un point de vue organisation, il est là pour mettre de l’huile dans les rouages, établir des process pour accélérer les choses. En revanche d’un point de vue technique, il est là pour automatiser la mise en production des appplications ou services (micro souvent).

Dans ma vidéo, je fais le parallèle avec l’industrie automobile et ses chaînes de production. Pour l’informatique, c’est l’émergence du déploiement automatisé. L’objectif principal étant de livrer toujours plus vite en limitant les risques. C’est aussi ce que nous allons apprendre au fur et à mesure des vidéos.

J’irai même plus loin. Cloud ou pas cloud, docker ou pas, le devops est omniprésent et ne dépend pas de ces technologies. Sa fonction est d’automatiser les mises en production peu importe le support. Une fois que l’on a compris cela on a déjà fait un grand pas.

Avec cette automatisation vient la standardisation. Et dans notre domaine cela ne fait pas de mal et donnera surement un bon coup de main aux administrateurs systèmes qui ont souvent perdus l’écoute et que l’on ne comprend plus dans leur posture.

Ainsi donc suivant les environnements, le devops pourra être une culture (certaines entreprises vont jusque changer tous les intitulés de leurs sysadmins en devops) ou un poste spécifique. Mais finalement, il faudra mettre tout le monde autour de la table pour parler de l’automatisation du déploiement des applicatifs.

HTTPS : c’est quoi ??

Vous travaillez dans l’IT ? peut être étes vous sysadmin, développeur ou encore devops et lors d’un entretien vous avez eu cette question ? Expliquez moi ce qu’est le protocole HTTPS ou encore comment fonctionne-t-il ?

Si vous êtes RH je pense que cet article pourra aussi vous aider à poser cette question et à mieux comprendre la réponse de vos candidats.

En tout cas, peu importe de quel côté de la barrière êtes vous, vous pourrez désormais savoir mieux appréhender cette question. Certes, je vulgarise la réponse et ne rentre pas dans tous les détails techniques (les détails du protocole, les chiffrements…).

HTTPS : résumé en vidéo

Histoire

HTTP pour HyperText Transfer Protocol, sans lui le web ne serait pas ce qu’il est. Peut être n’aurait-il pas existé ? Attention, ne pas confondre HTTP protocole d’échanges et HTML format ou plutôt language de développement web interprété par les navigateur internet.

Le protocole HTTP est donc un protocole d’échanges d’informations en deux machines client et serveur. Mais voilà comme tout échange, certaines personnes tentent de s’initier dan sle conversation de manière malveillante. Souvent considéré comme des hackers, ces personnes font usage de plusieurs méthodes pour capturer les paquets (informations) entre le client et le serveur. Le protocole HTTP peu sécurisé regorge de failles dans ce domaine (man in the middle, sniffing…).

Pour sécuriser, ce protocole a évolué vers les HTTPS ou HyperText Transfer Protocol Secure. Son principe ? permettre l’échange d’informations de manière sécurisée.

Pour réaliser ce chiffrement, il a été nécessaire d’utiliser un protocole. Et le premier a été SSL ou Secure Socket Layer. Il a bien vécu pourrait-on dir e:

  1. SSL 1.0 : jamais paru (Netscape)
  2. SSL 2.0 : 1995 – 2011
  3. SSL 3.0 : 1996 – 2015

Puis au fur et à mesure de la découverte de failles, une évolution plus substancielle a été nécessaire : le TLS ou Transport Layer Security.

Là encore avec des évolutions pour permettre de garantir la sécurité d’échanges des paquets mais également de permettre de servir les pages web toujours plus vites.

  1. TLS 1.1 : 2006 – 2020
  2. TLS 1.2 : 2008
  3. TLS 1.3 : 2018

Communication entre le client et le serveur

Mais du coup comment se passe cette communication sécuriser ? Voici un résumé du déroulement de cet échange :

  1. (préalable) Serveur : obtention d’un certificat auprès d’une authorité de certification (principe clefs publique/privé)
  2. Client : dit Hello au serveur et lui indique la version TLS et les suites cryptographiques supportées
  3. Serveur : répond Hello au client et indique les TLS et suite crypto utilisés + certificat et clef publique
  4. Client : vérifie la validité du certificat auprès de l’autorité de certification externe (différents niveaux de délégation)
  5. Client : Fourni une clef symétrique pour les prochains échanges (clef chiffrée avec la clef publique fourni par le serveur)
  6. Client/Serveur : échanges avec la clef symétrique