Archives de l’auteur : xavki

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

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

Formez vous et créez votre propre pipeline devops !!!

Devops, je vous propose de vous lancer dans une nouvelle playlist qui vous guidera petit à petit vers ce que doit savoir faire un ingénieur devops : déployer automatiquement une application ou un service. Bien sûr cette série sera assez longue mais progressive, elle vous permettra de toucher du doigt un grand nombre de technologies. Mais nul besoin de cloud comme le propose un grand nombre de démo. Tout cela sera fait sur votre laptop en toute simplicité.

Voici donc quelques technologies de l’ingénieur devops que vous allez découvrir et utiliser dans cette série :

  • vagrant
  • virtualbox
  • jenkins
  • ansible
  • jenkins
  • docker
  • gitlab
  • gitflow

Cet ensemble de technologies va vous plaire j’en suis sûr. Et surtout vous n’aurez nul besoin d’internet pour lancer votre infrastructure.

Voici donc la présentation de ce projet en vidéo.

Bien sûr abonnez vous à la chaîne et/ou au blog pour ne pas manquer les prochaines présentations.