Aller au contenu principal

Caddy - Un reverse proxy simple qui gere le SSL comme un chef

Dans ma courte vie d'informaticien, je n'ai toujours eu qu'une seule IP publique. Celle de mon serveur OVH sur lequel vous visualisez le site actuellement. Et en sachant que j'ai de nombreux services Web, il m'a rapidement été nécéssaire de chercher les différents solutions permettant d'installer un Reverse Proxy efficace qui servirait à rediriger mes utilisateurs vers l'application voulue en fonction du domaine.

Dans ma longue quête (qui n'est certainement pas achevée), j'ai eu l'occassion de tester de nombreuses solutions comme Haproxy, Apache2, Nginx et maintenant.. Caddy

Haproxy a été pour moi le plus facile et le plus pratique pour démarrer, bonne documentation, incorpore de nombreux outils permettant de vérifier la configuration, ou rajouter des authentifications. J'ai été satisfait durant quelques années.

(Je ne compte pas Apache2, qui a été pratique pour débuter sans installer un service dédié à mon besoin de redirection)

Ensuite, j'ai utilisé aaPanel (dont vous trouverez un article sur ce site) me permettant d'avoir une toute un panel web pour mes sites et mes redirections ! J'ai abandonné en sachant que c'était un système bien ficelé dans lequel j'avais peu de liberté en terme d'édition de config

Puis mon besoin inutile d'avoir une interface Web m'a mené vers NPM (Nginx Proxy Manager) dont vous trouverez plus d'information ici. Qui m'était très pratique en sachant qu'il était sous forme de conteneur Docker, et proposant une interface gérant la création de redirection ainsi que le SSL, toujours chez let's encrypt. Mais à chaque expiration de certificat, NPM m'obligeait à aller manuellement séléctionner un-par-un chaque certificat à update : et ça, c'était impensable en sachant le nombre de domaine que j'ai créé.

Aujourd'hui, mon attention se porte vers Caddy qui, pour l'instant, correspond exactement à ce que je souhaite, et avec une simplicité incroyable.

Caddy

Caddy est, comme vous l'aurez compris, un reverse-proxy assez polyvalent et très utilisé dans certains conteneurs Docker ! Celui-ci génère automatiquement vos certificats (et configure les redirections automatiquement) sans aucun soucis avec Let's Encrypt. Caddy est assez léger et vous évitera les configurations à ralonge, voici un exemple bête :

thoughtless.eu {
    reverse_proxy 192.168.5.125:8062
    log {
        output file /var/log/caddy/thoughtless.eu_access.log
    }
}

Cette ligne créera une redirection en reverse-proxy avec la configuration par défault :

  • Caddy updatera / generera des certificats chaque fois que c'est nécéssaire
  • Il redirigera automatiquement les requetes en http:// vers le https://
  • Il écriera des logs des accès dans un fichier

En apache2 / Haproxy, ça aurait pris un chouïa + de lignes.

Mais attendons de voir, Caddy est encore très neuf pour moi, et je suis sûr que mon prochain besoin m'orientera vers une autre solution telle que Traefik par exemple !

Bonne courage dans votre longue quête autour des reverse-proxy

Restic : Backuper.. Partout !

Une notion que j'utilise très rarement (et notamment sur ce blog) : c'est les backups. Il est important d'avoir cette sécurité, permettant d'avoir une sécurité en cas d'erreur humaine.. ou matérielle ! Depuis toujours, on me recommande BorgBackup qui est une solution suivant un mode client/server permettant d'avoir des dépots accueillant des sauvegardes venant de partout. Sauf que BorgBackup nécéssite un .. serveur ! Et dans mon cas : Mes sauvegardes sont principalement sur une Seedbox Externe dont je n'ai aucun droit administrateur (Je dois donc chiffrer !), donc impossible d'y installer un serveur BorgBackup. (Pas de Docker, Pas de droits roots)

Je suis donc parti sur Restic, qui est une solution permettant le backup avec de nombreux protocoles !

Voici les différentes manières d'envoyer ses sauvegardes :

  • Local
  • SFTP
  • REST Server
  • Amazon S3
  • Minio Server
  • Wasabi
  • Alibaba Cloud (Aliyun) Object Storage System (OSS)
  • OpenStack Swift
  • Backblaze B2
  • Microsoft Azure Blob Storage
  • Google Cloud Storage
  • d'autres protocoles via rclone

Dans mon cas, je suis clairement parti sur SFTP, puisque je me connecte à ma seedbox par SSH. Même si c'est peu rapide : ça n'est pas bien grave puisque je sauvegarde 1x par semaine;

voici la commande que j'execute pour sauvegarder (en sachant qu'il faut aupréalablement initialiser le repos via la commande "init")

restic -r sftp:USER@SERVEUR:/EMPLACEMENT backup ~/

Avec cette commande, je sauvegarde l'intégralité de mon dossier "home". Il m'est également possible de choisir des fichiers/pattern à exclure

--exclude="*.c" --exclude-file=excludes.txt

La documentation est assez complète, vous trouverez forcement des options qui vous satisfiront.

J'ai aussi trouvé Restatic ( lien : ici) qui permet d'obtenir une interface GUI permettant de simplifier les longues commandes.

En bref : Restic est très polyvalent et peut être adapté pour de nombreux cas. Il est également possible de configurer restic avec des variables d'environnements et d'automatiser le backup assez facilement !

Merci d'avoir lu

Jenkins et l'integration continue

Cet article est encore en brouillon !

1. Introduction

En développement, il y a un certain fantasme qu'on aimerait tous avoir sans trop d'effort : c'est lorsqu'une fois la compilation terminée, le programme se déploie seul sur un serveur de test. Je garantie pas que ça se fasse sans effort, mais c'est possible, avec Jenkins !

1.1 Qu'est ce que Jenkins ?

En récupérant la définition, voici ce que nous dit Wikipedia :

Jenkins est un outil open source d'intégration continue, fork de l'outil Hudson après les différends entre son auteur, Kohsuke Kawaguchi, et Oracle. Écrit en Java, Jenkins fonctionne dans un conteneur de servlets tel quApache Tomcat, ou en mode autonome avec son propre serveur Web embarqué.

Jenkins est donc un outil permettant de faire des tests unitaires, des tests de compilations ainsi que du déploiement automatique en fonction des résultats précédents. Celui-ci s'interface très bien avec Git, et permet une gestion avancée de la planification et du déploiement sur machine distante.

Il va créer son propre serveur web pour donner accès à une interface sur laquelle la plupart des options seront assez accessible.

Une image docker est disponible ici : https://hub.docker.com/_/jenkins/ (C'est d'ailleurs celle que j'utilise)

1.2 Qu'est ce que le CICD

Voici une image provenant du site officiel de redhat

à partir de cette image, on peut comprendre les 2 étapes du CICD :

  • CI - la validation du code via des tests
  • CD - Le déploiement automatique du code testé

1.3 Notre système

Nous allons donc utiliser Jenkins et Docker pour créer un système autour du CICD, permettant de tester et déployer un programme automatiquement.

Voici le schéma global montrant les liens entre nos services:

Si on décortique les étapes de ce système, voici ce que cela donne :

  1. Utilisateur push sur Gitea
  2. Gitea envoie une notification à Jenkins via un Webhook
  3. Jenkins récupère les taches à executer en CI (Jenkinsfile ou dans le projet Jenkins)
  4. Jenkins exécute les taches dans des conteneurs sur une seconde machine
    1. Si la tache est défectueuse, on s’arrête là
    2. Si le test est concluant, on passe à l'étape 5.
  5. Jenkins va contrôler la machine de production, et va déployer le programme.

2. Installation de Jenkins

L'installation de ce service peut se faire assez facilement, la seule dépendance étant Java-8 ou Java-11. La documentation d'installation est disponible ici : https://www.jenkins.io/doc/book/installing/linux/

Dans mon cas, j'utilise le conteneur Docker officiel, voici mon docker-compose.

version: '3.3'
services:
    jenkins:
        ports:
            - '2080:8080'
            - '50000:50000'
        volumes:
            - './data:/var/jenkins_home'
        image: 'jenkins/jenkins:lts-jdk11'

Jenkins sera disponible sur une interface web dont le port est 8080 si vous ne passez pas par Docker.

3. Configuration basique

3.1 Plugins nécessaires

Dans notre système, il sera indispensable d'avoir le plugin Docker de la catégorie Cloud. Celui-ci permettra de lancer des conteneurs docker qui serviront à exécuter les étapes de déploiements et d'intégration continue.

3.1.1 Définitions

"Cloud" est le mot désignant les systèmes pouvant générer des "Node" (ex: AWS, AZURE.. ou Docker). Un "Node" est une machine sur laquelle Jenkins va exécuter ses actions, comme par exemple le CI/CD.

3.1.2 Ajout du plugin Docker

Dans la partie Administrer Jenkins, puis Gestion des plugins. Dans la catégorie "Disponible", cherchez "Docker".

3.1.3 Ajout du plugin Generic-Webhook

Pour pouvoir déclencher l'execution d'un pipeline automatiquement, il est nécéssaire de passer par les webhooks. Nous allons donc ajouter le plugin (par la même démarche que la partie 3.1.3)

3.1.4 Ajout du plugin node-label-parameter

Pour choisir les nodes sur lesquels nous allons executer certaines actions, nous allons installer le plugin nodelabelparameter

3.2 Désactiver les actions sur Jenkins directement

Il est possible d'utiliser la machine hébergeant Jenkins, dans mon cas : je préfère séparer les taches. Jenkins enverra les actions sur une machine dédiée à ça (et qui aura un peu plus de ressources).

Retournez dans Administrer Jenkins, Gérer les nodes, puis vous devriez voir votre machine Jenkins. Cliquez sur Configurer, et changez son utilisation :

Jenkins (ou plutôt la machine qui l'héberge) ne sera pas utilisée si on ne lui indique pas de l'être.

3.3 Configurer Docker (sur le Slave)

Sur votre machine servant au CI, Il faut que l'API Rest de Docker soit accessible via notre Jenkins, il faut configurer l'écoute du port.

Dans le fichier /lib/systemd/system/docker.service J'ai modifié la ligne "ExecStart" par celle-ci :

ExecStart=/usr/bin/dockerd -H tcp://0.0.0.0:4243 -H fd:// --containerd=/run/containerd/containerd.sock

Comme nous venons de modifier un service Systemd, il faut recharge la liste via la commande systemctl daemon-reload.

en redémarrant le daemon Dockerd, via systemctl restart docker.service, et en vérifiant les logs, on remarque maintenant que Docker écoute bien via le port 4243

Attention ! L'API n'est disponible qu'en HTTP ! Un simple MITM pourra récupérer les informations essentielles.

Il est également recommander de bloquer l'accès au port. Sinon, n'importe qui pourra lancer des conteneurs Docker en ayant le port :

iptables -A INPUT -p tcp --dport 4243 ! -s IP_JENKINS -j DROP

3.4 Configurer le Cloud Docker

Sur Jenkins, aller dans Configurer Jenkins, Gérer les noeuds, Configure Cloud. Puis nommez et ajouter votre cloud comme ceci : 10.164.0.36 étant l'IP de la machine nommée JBuilder qui s'occupera des tests.

Pensez quand même à utiliser le bouton Test Connection.

Descendez un peu plus bas dans Docker Agent Template, et ajoutez cette ligne : Cela permettra d'utiliser mon image (Debian) pour déployer vos machines. Il existe de nombreux templates en ligne, j'en ai également utilisé une pour mon image.

Si vous souhaitez utiliser votre propre image, lisez la prochaine étape.

3.5 (Optionnel)Créer l'image pour le CI

Voici le code source de l'image que j'ai proposé au point précédent : https://git.thoughtless.eu/CICD-Jenkins/Jenkins-Slave

Dockerfile :

#FROM jenkins/inbound-agent
FROM debian
LABEL maintainer="Kiko@thoughtless.eu"
# Install Essentials
RUN apt update 
# Install Packages
RUN apt install -y git && \
    apt install -y wget curl && \
    apt install -y sudo && \
    apt install -y software-properties-common dirmngr && \
    apt install -y python3 python3-pip
RUN apt install -y docker-compose
RUN cat /etc/apt/sources.list
RUN apt install -y default-jre && \
        apt install -y java-common
RUN java --version
RUN wget https://gist.githubusercontent.com/paulosalgado/91bd74c284e262a4806524b0dde126ba/raw/5e352a73626615888f5bb6fb1df4b98deecfb354/check_docker_container.sh -O /usr/bin/docker-check
RUN chmod +x /usr/bin/docker-check
# Si vous souhaitez executer les programmes via un utilisateur non-root
ARG user=jenkins
ARG group=jenkins
ARG uid=1000
ARG gid=1000
ENV JENKINS_HOME /home/${user}
RUN groupadd -g ${gid} ${group} \
    && useradd -d "$JENKINS_HOME" -u ${uid} -g ${gid} -m -s /bin/bash ${user}
RUN chown -R ${user}:${user} /home/${user}
# Supprimez cette ligne pour ne pas donner l'accès à "Sudo" à l'utilisateur Jenkins
RUN echo "${user}    ALL=(ALL)    ALL" >> etc/sudoers

Vous pouvez utiliser cette base pour ajouter vos dépendances ou les programmes que vous utilisez. J'y ai ajouté Docker-compose pour pouvoir également tester des programmes Docker.

Précision sur votre propre image

Il faudra absolument que cette image soit disponible sur un registre Docker.

Si vous ne souhaitez pas utiliser un registre public, il faudra faire votre propre registre. Voici le compose que j'utilise (Le serveur de registre est sur la machine jBuilder dans mon cas)

version: '3.3'
services:
    registry:
        ports:
            - '5000:5000'
        restart: always
        container_name: registry
        volumes:
            - '/mnt/registry:/var/lib/registry'
        image: 'registry:2'

Créer votre premier Projet Jenkins

CI

Notre premier projet sera la partie CI (Continuous Integration), celle-ci permettra de compiler votre programme et de le tester avant de passer au second projet qui sera le déploiement. Pour cela, il faudra aller sur Jenkins, et cliquer sur "Nouvel Item" pour démarrer un projet, et choisir "Multi-Configuration". C'est le projet possédant le plus de possibilité et notamment dans les étapes à suivre.

L'idée est aussi de ne PAS utiliser les JenkinsFile qui permettent d'executer automatiquement les commandes depuis un fichier sur le git. (Si le Gitea se fait pirater, il sera malheureusement possible d'executer n'importe quel script aisément, nous allons donc écrire la procédure de déploiement directement sur le Jenkins).

Si vous souhaitez créer un projet à l'échelle d'une organisation, il devient important d'automatiser la création d'un projet. Il existe donc un plugin Gitea permettant de gérer toute une organisation / utilisateur.

Dans Source Code Management, mettez bien votre repo. S'il n'est pas public, il faudra que l'utilisateur que Jenkins utilise ait un accès en lecture (Sinon, cliquez sur "Add Credential" et ajoutez un utilisateur qui sera utilisé uniquement par Jenkins)

Définition des étapes

Comme nous nous passons de Jenkinsfile, nous allons détailler les étapes dans la catégorie "Build" de notre projet. (Tout en se rappelant qu'elles seront executées dans un conteneur Docker, donc il faut également penser à installer les dépendances. Comme j'ai configuré un volume permettant à mon conteneur de controler Docker sur la machine hote, je travaille beaucoup avec docker compose.

Voici certaines de mes actions :

Ajout d'un Webhook !

Sur votre projet Jenkins, allez dans la catégorie "Build Trigger", et sélectionnez "Generic Webhook Trigger. Dans la partie "Token", il faudra en ajouter une qui ne sera utiliser que dans ce projet. Si jamais 2 projets possèdent le même Token, les deux seront triggered durant un push, ce qui n'est pas ce que nous souhaitons. J'utilise Bitwarden qui va me générer un mot de passe, qui sera le Token du webhook. P'tite astuce ;-)

Sur Gitea, Allez dans les paramètres de votre dépot -> Déclencheurs Web -> Ajoutez un déclencheur Web

Voici comment sera votre webhook :

https://URL_DE_JENKINS/generic-webhook-trigger/invoke?token=VOTRE_TOKEN_ICI

Une fois ajouté, vous pourrez essayer de cliquer sur "Tester la version" pour que Gitea simule un Push, vous pourrez voir sur votre interface si le CI est lancé ! Il sera très probablement nécéssaire de réaliser de nombreux ajustements dans le CI, ne vous découragez pas, car le résultat est très satisfaisant.

Partie CD

La partie CD est censé être la plus simple vu qu'elle ne nécéssite ni Docker, ni de réaliser les tests barbants de la partie en CI. C'est d'ailleurs à ce moment là que l'on va utiliser le plugin node-label-parameter. Celui-ci va permettre de forcer l'utilisation d'un agent en particulier, et non pas de choisir aléatoirement.

Mais avant-tout, vous devez ajouter un agent dans Jenkins, qui sera le serveur de production. (Privilégiez l'ajout d'un agent par SSH). Créez un projet multi-configuration, comme pour la partie en CI.

Pensez aussi à avoir configurer votre agent (serveur prod) en Réserver ce noeud pour les jobs qui lui sont attachés

Démarrage automatique du projet

Le premier projet, concernant le CI, avait pour objectif d'être démarré à chaque push (via un webhook). Dans notre : ce n'est pas possible puisque le CD intervient uniquement quand le CI est stable. C'est pourquoi nous avons une option, présente nativement dans Jenkins, nous permettant de démarrer le CD uniquement si un autre projet est stable.

Cette option nous facilite grandement le travail, et permettra de démarrer le CD automatiquement après le CI.

Forcer le projet sur une machine

Pour l'instant, nous avons 2 agents (dont 1 en mode "Cloud") : - Le Cloud Docker (JBuilder) - Le serveur Prod

Par défaut, Jenkins va utiliser le Cloud Docker que nous avons configuré plus tôt. Il faut donc indiquer à Jenkins que notre serveur de prod sera la machine à controler durant ce projet.

C'est pourquoi le plugin node-label-parameter va nous aider à forcer l'utilisation d'un agent particulier.

Il suffira de cocher "Ce Build a des paramètres" dans le projet Jenkins qui concerne le CD pour dérouler un menu permettant de séléctionner les agents à utiliser dans ce projet.

Mon serveur de déploiement se nomme "CD", voici comment j'ai rempli les paramètres :

Avant de passer à la suite, lancez le projet de CI pour bien voir que le CD se lance sur le serveur de Prod. La procédure de CD est encore vide, donc aucun risque d'endommager l'environnement propre.

On peut donc aller directement sur notre projet de CI et cliquer sur 'Démarrage manuel' pour que Jenkins démarre automatiquement notre projet, suivi du projet de CD ! (Si jamais vous avez bien respecté les étapes, dans tout les cas : Jenkins affichera une erreur assez facile à comprendre permettant un debuggage facile... Qu'il est gentil ce Jenkins ;) )

La suite de cet article se repose sur des souvenirs, j'ai élaboré ce système dans un environnement professionnel dans lequel je ne travaille plus actuellement, je vais essayer d'être le plus précis possible. Désolé d'avance pour les quelques erreurs qui se glisseront :)

Si vous êtes arrivés jusque là : Fé-li-ci-ta-tion ! Vous venez de battre Jenkins en créant un projet entier promettant un CICD simple.. mais efficace et fonctionnel ! (evidemment, vous pourrez toujours allé + loin en étant curieux et en fouillant les paramètres)

Mais .. vous venez de configurer votre CI(et CD) en tant qu'administrateur du Jenkins, il existe une solution permettant également de fournir une solution adaptée aux utilisateurs sans forcement avoir accès à l'interface de Jenkins

Permettre aux utilisateurs de faire un CI

Cette méthode est valide dans le cas où vous utilisez Gitea comme serveur Git principal. Comme c'est mon cas, j'ai trouvé cette méthode bien avant la création manuelle de projet Jenkins, et il faut dire qu'elle m'ait plutôt efficace.

Il vous faudra installer le plugin "Gitea" permettant à Jenkins de se connecter à un serveur Gitea et de réaliser le CI automatique des projets répondant à certains critères.

Je vais rapidement m'expliquer :

Explication rapide concernant le plugin Gitea

Le plugin vous permettra de créer un projet d'organisation, C.A.D. que l'on va créer un utilisateur lié à Jenkins qui sera apte à (en lecture seule) accéder aux projets pour en faire le CI.

Et si le plugin parle d'organisaiton, c'est parce qu'un dépot Git se repose sous cette forme :

    https://URL_GIT/USER/DEPOT

Cet "User" est également une organisation à lui seul, chaque utilisateur est comme une organisation personnelle, et là où le mot "Organisation" prend son sens dans le cas du plugin sur Jenkins, c'est parce que l'on va donner une organisation à Jenkins qui va automatiquement récupérer les dépots auquels il a accès.

Par exemple, si je donne mon utilisateur "toto" : Jenkins va essayer de récupérer l'intégralité des projets dont il a accès dans l'organisation "toto".

C'est peut-être assez contraignant (car Jenkins ne va pas surveiller un dépot d'un nouvel utilisateur) mais dans mon cas : c'est précisement ce dont j'avais besoin. (Les utilisateurs étaient administrés par des équipes et il était important que les chefs d'équipes gardent un controle sur les organisations. )

Mise en place du Plugin Gitea

la première étape est d'aller dans les paramètres de Jenkins (Paramètre --> administrer Jenkins, Paramètre généraux) et de chercher la catégorie liée à Gitea. Vous pourrez renseigner votre serveur (URL que Jenkins utilisera) ainsi que l'utilisateur que Jenkins utilisera pour lire vos dépots.

Vous pourrez difficilement rater l'erreur si jamais vos paramètres ne sont pas bons

L'étape suivante est donc de créer un projet d'organisation Gitea sur le menu d'accueil de Jenkins. le "Owner" sera l'organisation que vous ajouterez. (à ne pas rater donc!)

En donnant les permissions de lecture-seule à l'utilisateur Jenkins, et de lancer le scan d'organisation, vous verrez les projets dont Jenkins a accès.

Mais maintenant : il reste à configurer le CI (puisque c'est quand même la fonctionnalité donc l'utilisateur veut l'accès), pour cela : il faut ajouter un fichier nommé "Jenkinsfile" au dépot Git. Vous en trouverez un exemple ici

---- Ajoute un exemple de Jenkinsfile, oublie pas avant de Commit !

Docker-Swarm, Orchestrateur de conteneur

Docker Swarm

Introduction

Le monde de la conteneurisation a apporté de nombreuses choses dans l'administration système, et a actualisé le concept de DevOps. Mais une des choses principales que nous apporte les conteneurs (et particulièrement Docker), c'est l'automatisation.

Et bien que Docker soit déjà complet avec le déploiement de service, on peut aller un peu plus loin en automatisant la gestion des conteneurs ! Et pour répondre à ça : Docker Inc. propose un outil adapté pour l'orchestration automatique d'instance : Docker Swarm.

Qu'est ce que Docker Swarm ?

Comme dit précédemment : Docker Swarm est un outil d'orchestration. Avec cet outil, on peut gérer automatiquement nos conteneurs avec des règles favorisant la Haute-disponibilité, et l'évolutivité (Scalability) de vos services. On peut donc imaginer 2 scénarios qui sont entièrement compatibles : - Votre site a un pic de charge et nécéssite plusieurs conteneurs : Docker Swarm gère la replication et l'équilibrage des charges - Une machine hébergeant vos Dockers est en panne : Docker Swarm réplique vos conteneurs sur d'autres machines.

Nous allons donc voir comment configurer ça, et faire un p'tit état des lieux des fonctionnalités proposées.

Créer un cluster Swarm

Pour les tests, j'utiliserai PWD (Play With Docker) pour m'éviter de monter ça sur mon infra :)

Je dispose donc de 4 machines sous Alpine sur lesquelles je vais lancer démarrer un cluster Swarm.

La première étape est de définir un Manager, celui-ci sera la tête du cluster, ainsi que le points d'accès vers les différentes machines. Dans notre cas, on va faire très simple, le manager sera Node1.

Pour lancer le Swarm sur le manager, il suffit d'utiliser la commande docker swarm init. Mais, si votre système possède un nombre de carte réseau supérieur à 1 (Assez facile sur un serveur), il faut donner l'IP d'écoute. Dans mon cas, l'IP de l'interface du réseau local (dans lequel les VMs communiquent) est 192.168.0.8. Donc la commande que je vais lancer est

docker swarm init --advertise-addr 192.168.0.8

Docker me répond ceci :

Swarm initialized: current node (cdbgbq3q4jp1e6espusj48qm3) is now a manager.
To add a worker to this swarm, run the following command:
    docker swarm join --token SWMTKN-1-5od5zuquln0kgkxpjybvcd45pctp4cp0l12srhdqe178ly8s2m-046hmuczuim8oddmk08gjd1fp 192.168.0.8:2377
To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.`

En résumé : Le cluster est bien lancé, et Il nous donne la commande exacte pour rejoindre le cluster depuis d'autres machines ! la Node1 étant le manager, il me suffit d'executer la commande docker swarm join sur les node2-4.

docker swarm join --token SWMTKN-1-5od5zuquln0kgkxpjybvcd45pctp4cp0l12srhdqe178ly8s2m-046hmuczuim8oddmk08gjd1fp 192.168.0.8:2377

Une fois terminé, on peut regarder le résultat sur le manageur avec la commande docker node ls

Déployer un service simple

Si vous êtes adepte de la commande docker run et que vous refusez docker-compose, sachez une chose : je ne vous aime pas. Comme vous m'êtes sympatique, voici une info qui ne servira pas : l'équivalent de docker run en Swarm est docker service. Mais nous n'allons pas aborder ce sujet dans cet article.

On va plutot utiliser l'équivalent de docker-compose, qui est docker stack. Donc avant-tout, voici le fichier .yml

version: "3"
services:
  viz:
    image: dockersamples/visualizer
    volumes:
       - "/var/run/docker.sock:/var/run/docker.sock"
    ports:
       - "8080:8080"
    deploy:
      replicas: 1
      placement:
        constraints:
          - node.role == manager

Avant de le démarrer, vous remarquerez surement la partie deploy qui permet de donner des indications à Swarm. On peut donc rajouter des contraintes pour deployer ça sur le/les managers, demander à l'hote de limiter l'utilisation des ressources, ou gérer des répliques pour l'équilibrage des charges.

Ce premier conteneur servira à avoir un dashboard simple pour voir où se positionnent les Dashboard, et éviter de passer uniquement en CLI pour cette fonction.

On va donc déployer ce compose avec la commande suivante:

docker stack deploy --compose-file docker-compose.yml swarm-visualiser

Une fois la commande terminée, il suffit d'ouvrir le serveur web du manager au port 8080.

On a donc maintenant un panel Web pour suivre les mises à jour des conteneurs.

Gestion (simplifiée) des replicas

Lorsque l'on accède à un conteneur, on passe obligatoirement par le manager. Mais rien n'empeche d'être rediriger vers le noeud 3-4 en passant par le manager. C'est pourquoi il est possible de répartir la charge (Load Balancing) avec un système similaire à HAProxy, c.a.d. en redirigeant les utilisateurs sur un autre conteneur à chaque chargement d'un page.

Voici un docker-compose créant automatiquement des replicas :

version: '3.3'
services:
    hello-world:
        container_name: web-test
        ports:
            - '80:8000'
        image: crccheck/hello-world
        deploy:
          replicas: 4

Et le résultat est supprenant :

Nous pouvons également adapter le nombre de replica.. En le diminuant:

docker service scale hello-world_hello-world=2

Ou en l'augmentant:

docker service scale hello-world_hello-world=20

Et la Haute-disponibilité, alors?

J'ai accès cet article dans les fonctions de Swarm, et comment les utiliser. Et si je n'ai abordé ce point en priorité, c'est parce que chaque conteneur créé dans ce post est gérer en HA ! Je vais, par exemple, stopper de force la 10eme réplique du conteneur "Hello world", qui se trouve sur Node1. Et Celui-ci sera directement relancé,

Okay, Mais docker pouvait déjà relancer automatiquement les conteneurs en cas de problème, en quoi swarm est différent?

Et pour répondre à ça, je vais me permettre de stopper le node4

On remarque que les autres noeuds se répartissent automatiquement, (et sans aucune intervention) les conteneurs stoppés. Et comme nous accedons aux services uniquement via les manageurs, ceux-ci ne redirigeront plus que vers les conteneurs démarrés. Un des serveurs peut donc prendre feu, le service sera toujours redondé, équilibré, et accessible.

Conclusion

Docker-Swarm est un point d'entré vers les Clusters d'applications qui sont d'une complexité incroyable sans un outil adapté. Swarm permet facilement de répondre à des besoins particuliers, sans aucune compétence technique. Dans un environnement de production, il est conseillé de s'orienter vers Kubernetes ou Nomad qui sont des alternatives bien plus complètes et puissantes.

Je vous encourage à essayer ce genre de technologie qui gouverneront notre monde de demain !

Merci d'avoir lu

WireGuard - Le Nouveau OpenVPN

WireGuard - Le Nouveau OpenVPN

Qu'est ce qu'un VPN ?

Si le grand public pense qu'un VPN est uniquement pour cacher son adresse IP publique, la fonction première d'un VPN est d'accéder depuis Internet à un réseau privé.

Admettons que vous ayez une imprimante WiFi, un Plex, ou un téléphone connecté dans votre réseau local, que vous soyez en déplacement et dans l'incapacité absolue d'accéder à l'un de ces appareils. Grace à un VPN, le problème est résolu ! Explication Réseau Rien ne vous oblige à utiliser un VPN pour accéder à d'autres sites sur internet mais si tel est votre désir, cela changera votre IP visible.

Mon Besoin

Dans mon cas, l'usage d'un VPN n'est pas pour accéder à des services dans mon réseau local. Mais plutôt pour chiffrer mon trafic si je suis dans un réseau inconnu ainsi que pour jouer à des jeux en LAN avec des amis, depuis Internet. (Parce que oui, tout ne se fait pas depuis Internet !)

Quels solutions pour faire son VPN

Le principale système est OpenVPN qui est le moyen le plus fiable et sécurisé de faire un VPN. Mais de l'autre coté du ring, nous avons WireGuard qui est un moyen plus simple mais plus rapide.

Ayant eu, jusqu'à maintenant, toujours des OpenVPN, j'ai décidé de m'orienter vers WireGuard. Et même si je suis pas compliqué avec la vitesse de débit (J'ai déjà pas la fibre, alors un peu plus ou un peu moins)

Sécurité ?

Bien que je sois mal placé pour parler sécurité au niveau chiffrement, d'un point de vu utilisation. Il suffit de générer ses clés privés/publiques, d'ajouter la clé publique du serveur VPN sur le client, et d'être sûr que sa clé publique est ajoutée à la configuration de WireGuard et la magie opère.

Vitesse de débit

En sachant que la vitesse varie énormément en fonction de pleins de facteurs difficiles à prendre en compte, voici les 2 speedtests que j'obtiens sur un serveur chez OVH (Client) et un serveur chez FirstHeberg (Serveur) (Les tests sont réalisés avec speedtest-cli) Sans VPN : Avant VPN

Avec VPN: Avec VPN La différence est présente, mais pas si flagrante. Dans mon petit réseau de campagne, je ne perd que 1Mo/s (sur mes 5Mo/s habituels).

Conclusion

Wireguard semble être une excellente alternative à OpenVPN, j'aurai adoré faire des tests + poussés en installant également un serveur OpenVPN mais le temps que cela prend ainsi que mon envie sont des obstacles auxquels je vais me plier. J'envisage cette solution au long-terme, et j'espère que ce système va se développer de plus en plus.

Controler la musique de son PC sur son smartphone

Depuis que j'ai réinstallé un ordinateur sur KUbuntu, j'ai découvert KDE Connect. Une application "compagnon" permettant de lier votre smartphone Android à votre Linux avec notamment la partie qui m’intéresse : le contrôle de la musique.

Mais bien que je sois régulièrement sur Linux durant le travail, je passe clairement la majeure partie du temps sur Windows, sur lequel il n'y a des programmes que je ne peux utiliser que sur cet OS, ou bien des jeux dont les développeurs n'ont pas jugé intéressant de se tourner vers Linux.

C'est pourquoi, durant une soirée sans occupation particulière, j'ai décidé de développer "Song-WebController".

L'idée derrière est de pouvoir, tout comme KDE-Connect, contrôler sa musique depuis son smartphone via une interface facile d'utilisation. Interface du site J'ai eu l'idée de créer ce programme en découvrant la librairie PyAutoGUI qui permet de contrôler la souris / clavier sur Windows. Dans notre cas, on utilise donc les touches permettant la gestion des médias/son

Aussi, n'utilisez pas ce programme sur un réseau qui ne vous appartient pas. Même si les risques ne sont pas très grands, un collègue de travail pourrait s'amuser à réactiver votre son au pire moment, ou à vous jouer des tours

Mango - Se faire sa propre bibliothèque de Manga/BD

Un univers que je trouve sous-exploité est l’univers des scans. En France, dans le domaine du téléchargement, on trouve très peu de fichiers numérisés contenant des BDs, ou des mangas.

(Note : Il est totalement illégal de partager des scans de livres (avec ou sans images) si vous ne possédez pas l’original. Ne prenez pas de risque pour savoir que le One-Piece n’existe pas)

Ayant un abonnement à CrunchyRoll, j’ai aussi accès à la catégorie « Manga » du site (site pc : ici , application android : ici ). Et sincèrement, pour quelque chose qui ne rajoute pas quelques euros sur la facture, c’est un service plutôt bien, et vraiment pratique lorsqu’on souhaite découvrir de nouvelles séries par exemple, Talentless nana, une tuerie ! )

Mais CrunchyRoll possède très peu de grosses licences, et il arrive à un moment où l’on voudrait un site pour lire ses scans _(Toujours dans la légalité) _avec nos propres fichiers, et la possibilité d’ajouter les séries que l’on voudrait.

Et c’est là qu’intervient Mango !

Mango, un site auto-hébergeable pour lire des BDs/Mangas

Pour les gens qui lisent des livres sur Calibre-Web, vous connaissez déjà le principe !

Mangos, c’est un site qui permet de lire vos fichiers de scans, de nombreux formats sont compatibles (.cbz, .zip, .cbr et .rar). Au premier lancement, vous aurez un mot de passe admin pour vous connecter et commencer à configurer le service.

« Dois-je donc scanner chacun de mes mangas en avance pour pouvoir les lire quand je ne suis pas chez moi? »

et la réponse est … Non.

On en vient donc à une fonctionnalité incroyable de Mangos, c’est une option qui permet de télécharger vos mangas directement sur MangaDex.

Il suffit donc d’aller sur Mangadex, et de récupérer l’ID du manga à télécharger.

Exemple : J’ai les 3 premiers tomes de Jojolion, et j’aimerai les lire durant mes pauses au travail

Il me suffit de récupérer l’ID du manga sur Mangadex (Lien ici) et de le donner à Mango.

 

En sélectionnant les 3 premiers tomes, il va automatiquement les télécharger et les ajouter à la librairie.

Le lecteur de Mango

 

Vous pouvez donc reprendre à la page même où vous vous êtes arrêté.

Conclusion

Mangos est donc un service très facile à installer, il suffit de 30Mo pour pouvoir démarrer votre propre instance. Le site est très léger, et facile d’utilisation, n’importe quel machine Linux pourrait se permettre d’héberger Mango.

La fonction permettant de télécharger les mangas sur MangaDex est incroyable et bien que le téléchargement soit un peu long (MangaDex est un site gratuit, on va pas s’en plaindre), le site trie seul les pages, et générer des couvertures seuls.

Seul bémol, pas d’application Android ou Ios

 

Installation

Sur n’importe quel Linux, il vous suffit de récupérer l’executable sur la page Github du projet : ici et de l’executer

#Récupérez le bon lien sur le Github dans la section "Releases"
wget https://github.com/hkalexling/Mango/releases/download/v0.15.1/mango
#On donne les permissions d'execution
chmod +x mango 
#On execute le fichier
./mango

 

 

 

 

 

 

N8N - un IFTTT Selfhost

Il m’arrive parfois de me balader sur l’incroyable liste de selfhosted (Lien ici), et en cherchant à relier des services publiques sans trop de difficultés (et sans me casser la tête à apprendre comment fonctionne chaque API), j’ai découvert N8N.

C’est une sorte de IFTTT en mode selfhost.

(Pour rappel, IFTTT est un site permettant d’automatiser certaines actions sur des réseaux comme Facebook, Twitter, Instagram. Le service est très complet et permet de faire beaucoup de chose … mais on est très rapidement limité. Il est par exemple impossible de relier 3 sites entre eux, ce que permet N8N)

 

Qu’est ce que N8N ?

Si vous avez lu l’introduction, vous savez donc que N8N est un clone de IFTTT, mais pourquoi passer sur ce ‘clone’ et pas sur l’original ?

Déjà N8N est beaucoup plus libre et permet l’utilisation de services auto-hébergés. (Ce que IFTTT ne fait pas !) , vous pourrez donc utilisez vos propres adresses mails, votre propre Gotify, Telegram, Wekan, ou simplement un Nextcloud.

N8N permet aussi un contrôle assez poussé au niveau des Webhook, permettant donc de recevoir des données depuis un formulaire sans aucun traitement au préalable.

Interface de N8N

 

L’interface de N8N est le plus gros point fort ainsi que le plus gros point faible de ce service. Agréable, épuré et légère, « coder » dessus est presque relaxant. On pourrait oublier le code et les tests unitaires qui agissent derrière les blocks.

Ce qui me dérange dans cet interface, c’est qu’on ne peut pas y mettre de reverse proxy (un reverse proxy est un programme qui permet d’avoir plusieurs serveurs web avec une seul IP. En fonction du domaine entré par l’utilisateur, le reverse proxy redirige le traffic vers le serveur adéquat).

Si jamais j’utilise un reverse proxy, j’obtiens cette erreur :

Ce qui est franchement désagréable. Je suis condamné à utiliser le port pour accéder au WebGUI.

et oui, j’ai essayé de changer l’URL des webhook, ils fonctionnent correctement mais je ne peux toujours pas lancer de ‘code’ à travers le reverse proxy.

 

Conclusion

N8N est un excellent service qui pourrait bel et bien me dépanner lorsque je dois relier 2-3 sites entre eux. C’est une excellente alternative à IFTTT ou ZAPIER qui ne proposent pas des solutions libres et selfhostés.

Après quelques heures de prise en main_(et quand même quelques connaissances en code concernant les variables) , on peut aisément réaliser des scripts assez complexes. (Exemple plus bas)_

 

(Explication rapide de l’algorithme : avec Office365, je sauvegarde les entêtes de mes mails reçus dans un fichier accessible sur un serveur SFTP. Je récupère ce fichier au début de l’algo toutes les 5minutes. Ensuite je le sauvegarde et je le converti en JSON (Pour du traitement) et je compare avec le dernier mail reçu (Permet de ne pas agir si je récupère 2 fois le même mail). Si le mail est en effet unique et pas sauvegardé, alors on le sauvegarde à son tour (pour comparaison avec le prochain mail) et on envoie une notification concernant la réception d’un mail)

 

L’algorithme n’est pas optimisé et sera amélioré, mais c’est un bel exemple de ce qu’on peut faire sans trop se casser la tête.

 

On peut aussi créer de petits programmes sympa et amusant :

Cet algorithme permet de récupérer une image et d’y ajouter un texte. Le résultat est envoyer sur un serveur SFTP. On passe donc de cette image :

 

à cette image :

Je n’accepterai aucune remarque concernant mes compétences à incruster un texte dans une image

Et ça sans aucune programmation en code !

Pour rajouter cet algorithme sur votre propre n8n, il suffit de coller ce code n’importe ou

 

Installation

Concernant l’installation de n8n, il est possible d’en faire une manuellement, mais comme on est en 2020 : je suis passé par Docker. Le site officiel vous donne directement la commande sans paramètre, mais comme ils sont essentiels à la sécurité et au bon-fonctionnement du service, voici un docker-compose avec les différentes valeurs à configurer (Ne me remerciez surtout pas)

version: '3.3'
services:
    n8n:
        container_name: n8n
        ports:
            - '5678:5678'
        environment:
            - N8N_BASIC_AUTH_ACTIVE=true
            - N8N_BASIC_AUTH_USER=username
            - N8N_BASIC_AUTH_PASSWORD=password
            - N8N_HOST=localhost
            - 'WEBHOOK_TUNNEL_URL=https://n8n.website.fr/'
            - 'VUE_APP_URL_BASE_API=https://n8n.website.fr/'
        volumes:
            - '~/.n8n:/root/.n8n'
        image: n8nio/n8n

 

aaPanel - Une alternative gratuite et open-source à cPanel

Pourquoi avoir besoin d’un panel-web ?

Lorsque nous devons gérer un ou deux sites webs, Apache2 et Nginx font très bien l’affaire et il n’est pas non-plus nécessaire de devoir gérer vos sites avec un GUI.

Mais lorsque le nombre de sites hébergés dépasse la dizaine, il faut un moyen de pouvoir administrer le tout sans se casser la tête. cPanel est d’ailleurs le panel-web le plus connu et utilisé sur le web.

Qu’est ce que aaPanel ?

aaPanel est une alternative open-source (Voici le lien Github) permettant d’avoir des fonctionnalités similaires à cPanel en dehors des plugins ajoutés. (_Bien que de nombreux plugins soient accessibles, on en reviendra après) _

Vous aurez donc une interface (plutôt esthétique, bien que ça ne soit pas l’essentiel) _permettant de voir la charge utilisée du serveur web, et d’administrer les différents outils (PHP, FTP, PHPMYADMIN, MySQL)._

Chaque page est très bien détaillée et si vous avez besoin de fonctionnalités générales, aaPanel est fait pour vous.

View post on imgur.com

Sécurité?

C’est un terme.. compliqué ! Disons qu’aucune faille pure et dure n’a été trouvée, et c’est plutôt une bonne nouvelle pour le moment  ! aaPanel fait attention aux attaques de type Bruteforce, aux cookies-stealer et vous aurez accès à de nombreuses fonctionnalités pour n’accepter les accès au panel qu’à certains domaines ou certaines IP.

Chaque action peut se retrouver dans le gestionnaire de log, et un Firewall interne est même configurable.

En configurant l’accès correctement, il est possible de :

  • Limiter l’accès en fonction du domaine entré
  • N’autoriser que certaines IP
  • Seule une URL ne permet d’avoir l’écran de connexion

 

Modularité

 

https://i.imgur.com/kMWyYzy.png

Il y a des fonctionnalités permettant d’ajouter ses propres plugins sur aaPanel, je ne trouve aucun plugin sur Internet qui s’installe sur le panel, mais la fonctionnalité est là.

Conclusion

aaPanel est pour moi la meilleure alternative à cPanel. Et je ne me vois pas gérer mes sites sans un panel aussi complet que celui-ci . De plus, aaPanel possède de nombreuses fonctionnalités comme par exemple un terminal sur navigateur très performant que j’utilise au quotidien. aaPanel permet aussi de faire du reverse proxy, j’accède à mes différents services (Plex, Containers, pastebin) directement depuis mon domaine.

De plus, déployer un certificat SSL se fait en seulement 2-3 clics avec Let’s Encrypt.

aaPanel a changé ma manière de gérer mes sites avec un Gui performant et rapide et je ne saurais assez recommander ce service.

 

Installation

Pour Debian/Ubuntu, une seule commande :

wget -O install.sh http://www.aapanel.com/script/install-ubuntu_6.0_en.sh && bash install.sh

Pour d’autres distributions, (comme CentOS), je vous donne rendez-vous sur aapanel.com

 

 

 

 

Un bot Telegram pour Betaseries

Betaseries est surement le site le plus complet permettant de gérer ses séries en cours. On trouve vraiment tout ce que l’on cherche, Anime, Series, Films etc.. Il manquerait plus que les livres/Mangas !

 

 

La première chose que je peux vous conseiller est de me suivre sur Betaseries ! Cliquez ici pour voir mon profil 

 

J’utilise Telegram au quotidien avec ma compagne, ainsi que pour bavarder avec quelques barbus accros aux lignes de commandes. En plus d’avoir une API très complète, c’est une application cross-plateform que je peux utiliser n’importe ou ! _(Puis question vie privée, c’est du propre) _

Les fonctions du bot

Il faut d’abord savoir que mon programme se sépare en 2 parties :

  • Partie Notif : Permet de checker si un nouveau épisode sort et si jamais il n’est pas déjà vu. Si le résultat est positif, on envoie une notification sur Telegram
  • Partie Bot : Permet à l’utilisateur de montrer les séries surveillés (pour les notifications), de montrer les épisodes à voir et de les marquer comme ‘vu’

Résultat de /watched

En cas de nouvel épisode disponible

Démarrer le bot

Pour démarrer les scripts, j’ai réalisé ce guide permettant de le faire sans trop de problème.

Lien vers le Wiki

N’hésitez surtout pas à me contacter sur la page contact en cas de problème