Archives de l’auteur : xavki

Trop de technos pour être partout…

Laisser un commentaire

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

Laisser un commentaire

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

Laisser un commentaire

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

Laisser un commentaire

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