One place for hosting & domains

      utilisant

      Comment héberger un site web en utilisant Cloudflare et Nginx sur Ubuntu 20.04


      L’auteur a choisi la Electronic Frontier Foundation comme récipiendaire d’un don dans le cadre du programme Write for DOnations.

      Introduction

      Cloudflare est un service qui se situe entre le visiteur et le serveur du propriétaire du site web, agissant comme un proxy inverse pour les sites web. Cloudflare fournit un Réseau de Diffusion de Contenu (CDN), ainsi que des services d’atténuation des DDoS et de serveurs de noms de domaine distribués.

      Nginx est un serveur web populaire qui héberge certains des sites les plus importants et les plus fréquentés d’Internet. Il est fréquent que des entreprises exploitent des sites web avec Nginx et utilisent Cloudflare comme fournisseur de CDN et de DNS.

      Dans ce tutoriel, vous allez sécuriser votre site web servi par Nginx avec un certificat Origin CA de Cloudflare et ensuite configurer Nginx pour utiliser des requêtes pull authentifiées. Les avantages de cette configuration tiennent au fait que vous bénéficiez du CDN et de la résolution DNS rapide de Cloudflare tout en vous assurant que toutes les connexions passent par Cloudflare. Cela empêche toute requête malveillante d’atteindre votre serveur.

      Conditions préalables

      Pour terminer ce tutoriel, vous aurez besoin des éléments suivants :

      Étape 1 – Génération d’un certificat Origin CA TLS

      L’Origin CA de Cloudflare vous permet de générer un certificat TLS gratuit signé par Cloudflare à installer sur votre serveur Nginx. En utilisant le certificat TLS généré par Cloudflare, vous pouvez sécuriser la connexion entre les serveurs de Cloudflare et votre serveur Nginx.

      Pour générer un certificat avec Origin CA, connectez-vous à votre compte Cloudflare dans un navigateur web. Sélectionnez le domaine que vous souhaitez sécuriser et naviguez jusqu’à la section SSL/TLS de votre tableau de bord Cloudflare. De là, naviguez jusqu’à l’onglet Origin Server (Serveur d’origine) et cliquez sur le bouton Create Certificate (Créer un certificat) :

      Option de création de certificat dans le tableau de bord de Cloudflare

      Laissez l’option par défaut de Let Cloudflare generate a private key and a CSR (Laisser Cloudflare générer une clé privée et une RSE) sélectionnée.

      Options de l'interface graphique d'Origin CA

      Cliquez sur Next (Suivant) et vous verrez un dialogue avec le Origin Certificate (certificat d’origine) et la Private key (clé privée). Vous devez transférer à la fois le certificat d’origine et la clé privée de Cloudflare vers votre serveur. Pour des raisons de sécurité, les informations relatives à la clé privée ne s’afficheront plus. Copiez donc la clé sur votre serveur avant de cliquer sur Ok.

      Dialogue montrant le certificat d'origine et la clé privée

      Vous utiliserez le répertoire /etc/ssl du serveur pour conserver les fichiers de certificat d’origine et la clé privée. Le dossier existe déjà sur le serveur.

      Tout d’abord, copiez le contenu du certificat d’origine affiché dans la boîte de dialogue de votre navigateur.

      Ensuite, sur votre serveur, ouvrez /etc/ssl/cert.pem dans votre éditeur de texte préféré :

      • sudo nano /etc/ssl/cert.pem

      Ajoutez le contenu du certificat dans le fichier. Ensuite, sauvegardez et quittez l’éditeur.

      Retournez ensuite à votre navigateur et copiez le contenu de la clé privée. Ouvrez le fichier /etc/ssl/key.pem pour le modifier :

      • sudo nano /etc/ssl/key.pem

      Collez la clé privée dans le fichier, enregistrez le fichier et quittez l’éditeur.

      Note : parfois, lorsque vous copiez le certificat et la clé à partir du tableau de bord Cloudflare et que vous les collez dans les fichiers correspondants sur le serveur, des lignes vierges sont insérées. Nginx considérera ces certificats et ces clés comme non valides. Par conséquent, veillez à ce qu’il n’y ait pas de lignes blanches dans vos fichiers.

      Attention : le certificat Origin CA de Cloudflare n’est fiable que sur Cloudflare et ne doit donc être utilisé que par les serveurs d’origine qui sont activement connectés à Cloudflare. Si, à un moment donné, vous mettez en pause ou désactivez Cloudflare, votre certificat Origin CA affichera une erreur de certificat non fiable.

      Maintenant que vous avez copié les fichiers de clés et de certificats sur votre serveur, vous devez mettre à jour la configuration de Nginx pour les utiliser.

      Étape 2 – Installation du certificat d’origine AC dans Nginx

      Dans la section précédente, vous avez généré un certificat d’origine et une clé privée en utilisant le tableau de bord de Cloudflare et avez enregistré les fichiers sur votre serveur. Vous allez maintenant mettre à jour la configuration de Nginx pour votre site afin d’utiliser le certificat d’origine et la clé privée pour sécuriser la connexion entre les serveurs de Cloudflare et votre serveur.

      Tout d’abord, assurez-vous que UFW autorisera le trafic HTTPS. Activez Nginx Full, qui ouvrira à la fois le port 80 (HTTP) et le port 443 (HTTPS) :

      • sudo ufw allow 'Nginx Full'

      Relancez maintenant UFW :

      Enfin, vérifiez que vos nouvelles règles sont autorisées et que UFW est actif :

      Vous verrez un résultat similaire à ce qui suit :

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere Nginx Full ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Nginx Full (v6) ALLOW Anywhere (v6)

      Vous êtes maintenant prêt à ajuster votre bloc serveur Nginx. Nginx crée un bloc serveur par défaut lors de l’installation. Supprimez-le s’il existe encore, car vous avez déjà configuré un bloc de serveur personnalisé pour votre domaine :

      • sudo rm /etc/nginx/sites-enabled/default

      Ensuite, ouvrez le fichier de configuration Nginx pour votre domaine :

      • sudo nano /etc/nginx/sites-available/your_domain

      Le dossier devrait ressembler à ceci :

      /etc/nginx/sites-available/your_domain

      server {
              listen 80;
              listen [::]:80;
      
              root /var/www/your_domain/html;
              index index.html index.htm index.nginx-debian.html;
      
              server_name your_domain www.your_domain;
      
              location / {
                      try_files $uri $uri/ =404;
              }
      }
      
      

      Vous allez modifier le fichier de configuration de Nginx pour faire ce qui suit :

      • Ecoutez sur le port 80 et redirigez toutes les requêtes pour utiliser le https.
      • Écoutez sur le port 443 et utilisez le certificat d’origine ainsi que la clé privée ajoutés dans la section précédente.

      Modifiez le fichier de manière à ce qu’il ressemble à ce qui suit :

      /etc/nginx/sites-available/your_domain

      server {
          listen 80;
          listen [::]:80;
          server_name your_domain www.your_domain;
          return 302 https://$server_name$request_uri;
      }
      
      server {
      
          # SSL configuration
      
          listen 443 ssl http2;
          listen [::]:443 ssl http2;
          ssl_certificate         /etc/ssl/cert.pem;
          ssl_certificate_key     /etc/ssl/key.pem;
      
          server_name your_domain www.your_domain;
      
          root /var/www/your_domain/html;
          index index.html index.htm index.nginx-debian.html;
      
      
          location / {
                  try_files $uri $uri/ =404;
          }
      }
      

      Enregistrez le fichier et quittez l’éditeur.

      Ensuite, vérifiez qu’il n’y a aucune erreur de syntaxe dans vos fichiers de configuration Nginx :

      Si vous ne trouvez aucun problème, redémarrez Nginx pour permettre vos modifications :

      • sudo systemctl restart nginx

      Allez maintenant dans la section SSL/TLS du tableau de bord Cloudflare, naviguez jusqu’à l’onglet Overview (Vue d’ensemble), et changez le mode de cryptage SSL/TLS en mode Full (strict). Ceci informe Cloudflare de toujours crypter la connexion entre Cloudflare et votre serveur Nginx d’origine.

      Activez le mode SSL Full(strict) dans le tableau de bord de Cloudflare

      Visitez maintenant votre site web à l’adresse https://your_domain pour vérifier qu’il est correctement configuré. Vous verrez votre page d’accueil s’afficher et le navigateur vous indiquera que le site est sécurisé.

      Dans la section suivante, vous allez mettre en place des Authenticated Origin Pulls (Extractions à l’Origine Authentifiée) pour vérifier que votre serveur d’origine parle bien à Cloudflare et non à un autre serveur. Ce faisant, Nginx sera configuré pour n’accepter que les requêtes qui utilisent un certificat client valide de Cloudflare ; toutes les requêtes qui ne sont pas passées par Cloudflare seront abandonnées.

      Le certificat Origin CA aidera Cloudflare à vérifier qu’il parle au bon serveur d’origine. Cette étape utilisera l’authentification du client TLS pour vérifier que votre serveur Nginx d’origine parle à Cloudflare.

      Dans une poignée de main TLS authentifiée par le client, les deux parties fournissent un certificat à vérifier. Le serveur d’origine est configuré pour n’accepter que les requêtes qui utilisent un certificat client valide de Cloudflare. Les requêtes qui ne sont pas passées par Cloudflare seront abandonnées car elles n’auront pas le certificat de Cloudflare. Cela signifie que les attaquants ne peuvent pas contourner les mesures de sécurité de Cloudflare et se connecter directement à votre serveur Nginx.

      Cloudflare présente des certificats signés par une autorité de certification (AC) avec le certificat suivant :

      -----BEGIN CERTIFICATE-----
      MIIGCjCCA/KgAwIBAgIIV5G6lVbCLmEwDQYJKoZIhvcNAQENBQAwgZAxCzAJBgNV
      BAYTAlVTMRkwFwYDVQQKExBDbG91ZEZsYXJlLCBJbmMuMRQwEgYDVQQLEwtPcmln
      aW4gUHVsbDEWMBQGA1UEBxMNU2FuIEZyYW5jaXNjbzETMBEGA1UECBMKQ2FsaWZv
      cm5pYTEjMCEGA1UEAxMab3JpZ2luLXB1bGwuY2xvdWRmbGFyZS5uZXQwHhcNMTkx
      MDEwMTg0NTAwWhcNMjkxMTAxMTcwMDAwWjCBkDELMAkGA1UEBhMCVVMxGTAXBgNV
      BAoTEENsb3VkRmxhcmUsIEluYy4xFDASBgNVBAsTC09yaWdpbiBQdWxsMRYwFAYD
      VQQHEw1TYW4gRnJhbmNpc2NvMRMwEQYDVQQIEwpDYWxpZm9ybmlhMSMwIQYDVQQD
      ExpvcmlnaW4tcHVsbC5jbG91ZGZsYXJlLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQAD
      ggIPADCCAgoCggIBAN2y2zojYfl0bKfhp0AJBFeV+jQqbCw3sHmvEPwLmqDLqynI
      42tZXR5y914ZB9ZrwbL/K5O46exd/LujJnV2b3dzcx5rtiQzso0xzljqbnbQT20e
      ihx/WrF4OkZKydZzsdaJsWAPuplDH5P7J82q3re88jQdgE5hqjqFZ3clCG7lxoBw
      hLaazm3NJJlUfzdk97ouRvnFGAuXd5cQVx8jYOOeU60sWqmMe4QHdOvpqB91bJoY
      QSKVFjUgHeTpN8tNpKJfb9LIn3pun3bC9NKNHtRKMNX3Kl/sAPq7q/AlndvA2Kw3
      Dkum2mHQUGdzVHqcOgea9BGjLK2h7SuX93zTWL02u799dr6Xkrad/WShHchfjjRn
      aL35niJUDr02YJtPgxWObsrfOU63B8juLUphW/4BOjjJyAG5l9j1//aUGEi/sEe5
      lqVv0P78QrxoxR+MMXiJwQab5FB8TG/ac6mRHgF9CmkX90uaRh+OC07XjTdfSKGR
      PpM9hB2ZhLol/nf8qmoLdoD5HvODZuKu2+muKeVHXgw2/A6wM7OwrinxZiyBk5Hh
      CvaADH7PZpU6z/zv5NU5HSvXiKtCzFuDu4/Zfi34RfHXeCUfHAb4KfNRXJwMsxUa
      +4ZpSAX2G6RnGU5meuXpU5/V+DQJp/e69XyyY6RXDoMywaEFlIlXBqjRRA2pAgMB
      AAGjZjBkMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMB0GA1Ud
      DgQWBBRDWUsraYuA4REzalfNVzjann3F6zAfBgNVHSMEGDAWgBRDWUsraYuA4REz
      alfNVzjann3F6zANBgkqhkiG9w0BAQ0FAAOCAgEAkQ+T9nqcSlAuW/90DeYmQOW1
      QhqOor5psBEGvxbNGV2hdLJY8h6QUq48BCevcMChg/L1CkznBNI40i3/6heDn3IS
      zVEwXKf34pPFCACWVMZxbQjkNRTiH8iRur9EsaNQ5oXCPJkhwg2+IFyoPAAYURoX
      VcI9SCDUa45clmYHJ/XYwV1icGVI8/9b2JUqklnOTa5tugwIUi5sTfipNcJXHhgz
      6BKYDl0/UP0lLKbsUETXeTGDiDpxZYIgbcFrRDDkHC6BSvdWVEiH5b9mH2BON60z
      0O0j8EEKTwi9jnafVtZQXP/D8yoVowdFDjXcKkOPF/1gIh9qrFR6GdoPVgB3SkLc
      5ulBqZaCHm563jsvWb/kXJnlFxW+1bsO9BDD6DweBcGdNurgmH625wBXksSdD7y/
      fakk8DagjbjKShYlPEFOAqEcliwjF45eabL0t27MJV61O/jHzHL3dknXeE4BDa2j
      bA+JbyJeUMtU7KMsxvx82RmhqBEJJDBCJ3scVptvhDMRrtqDBW5JShxoAOcpFQGm
      iYWicn46nPDjgTU0bX1ZPpTpryXbvciVL5RkVBuyX2ntcOLDPlZWgxZCBp96x07F
      AnOzKgZk4RzZPNAxCXERVxajn/FLcOhglVAKo5H0ac+AitlQ0ip55D2/mf8o72tM
      fVQ6VpyjEXdiIXWUq/o=
      -----END CERTIFICATE-----
      

      Vous pouvez également télécharger le certificat directement sur le site de Cloudflare ici.

      Copiez ce certificat.

      Puis, créez le fichier /etc/ssl/cloudflare.crt pour contenir le certificat de Cloudflare :

      • sudo nano /etc/ssl/cloudflare.crt

      Ajoutez le certificat au fichier. Ensuite, enregistrez le fichier et quittez l’éditeur.

      Mettez maintenant à jour votre configuration Nginx pour utiliser les Extractions d’Origine Authentifiée TLS. Ouvrez le fichier de configuration de votre domaine :

      • sudo nano /etc/nginx/sites-available/your_domain

      Ajoutez les directives ssl_client_certificate et ssl_verify_client, comme indiqué dans l’exemple suivant :

      /etc/nginx/sites-available/your_domain

      . . .
      
      server {
      
          # SSL configuration
      
          listen 443 ssl http2;
          listen [::]:443 ssl http2;
          ssl_certificate         /etc/ssl/cert.pem;
          ssl_certificate_key     /etc/ssl/key.pem;
          ssl_client_certificate /etc/ssl/cloudflare.crt;
          ssl_verify_client on;
      
          . . .
      

      Enregistrez le fichier et quittez l’éditeur.

      Ensuite, testez Nginx pour vous assurer qu’il n’y a pas d’erreurs de syntaxe dans votre configuration Nginx :

      Si aucun problème n’a été trouvé, redémarrez Nginx pour que vos modifications soient prises en compte :

      • sudo systemctl restart nginx

      Enfin, pour activer les Extractions Authentifiées, ouvrez la section SSL/TLS dans le tableau de bord Cloudflare, naviguez jusqu’à l’onglet Origin Server (Serveur d’Origine) et cochez l’option Authenticated Origin Pulls.

      Activez les Extractions d'Origine Authentifiée

      Visitez maintenant votre site web à l’adresse https://your_domain pour vérifier qu’il est correctement configuré. Comme auparavant, vous verrez s’afficher votre page d’accueil.

      Pour vérifier que votre serveur n’accepte que les demandes signées par l’AC de Cloudflare, basculez l’option Authenticated Origin Pulls pour la désactiver, puis rechargez votre site web. Le message d’erreur suivant devrait apparaître :

      Message d'erreur

      Votre serveur d’origine génère une erreur si l’AC de Cloudflare ne signe pas une requête.

      Remarque : la plupart des navigateurs mettent les requêtes en cache. Pour voir le changement ci-dessus, vous pouvez donc utiliser le mode de navigation Incognito/Privé dans votre navigateur. Pour éviter que Cloudflare ne mette les requêtes en cache pendant que vous configurez votre site web, naviguez jusqu’à l’aperçu dans le tableau de bord Cloudflare et basculez en Development Mode (Mode Développement).

      Maintenant que vous savez qu’il fonctionne correctement, retournez à la section SSL/TLS du tableau de bord Cloudflare, naviguez jusqu’à l’onglet Origin Server (Serveur d’origine) et activez à nouveau l’option Authenticated Origin Pulls pour l’activer.

      Conclusion

      Dans ce tutoriel, vous avez sécurisé votre site web alimenté par Nginx en cryptant le trafic entre Cloudflare et le serveur Nginx à l’aide d’un certificat Origin CA de Cloudflare. Vous avez ensuite configuré des Authenticated Origin Pulls (Extractions d’Origine Authentifiée) sur le serveur Nginx pour vous assurer qu’il n’accepte que les requêtes des serveurs Cloudflare, empêchant ainsi toute autre personne de se connecter directement au serveur Nginx.



      Source link

      Comment déployer Laravel 7 et MySQL sur Kubernetes en utilisant Helm


      L’auteur a choisi le Diversity in Tech Fund​​​​​ pour recevoir un don dans le cadre du programme Write for DOnations.

      Introduction

      Laravel est l’une des infrastructures d’application PHP les plus populaires aujourd’hui. Son déploiement se fait généralement avec une base de données MySQL, mais il peut être configuré pour utiliser une variété d’options de stockage de données de backend. Laravel est fier de profiter des nombreuses fonctionnalités modernes de PHP et de son vaste écosystème complet de package.

      Kubernetes est une plate-forme d’orchestration de conteneurs qui peut être hébergée sur des DigitalOcean Kubernetes clusters afin de simplifier la gestion et la configuration de conteneurs en production. Helm est un gestionnaire de packages Kubernetes qui facilite la configuration et l’installation des services et des pods sur Kubernetes.

      Dans ce guide, vous allez créer une application Laravel PHP, développer votre application dans une image Docker et déployer cette image dans un cluster DigitalOcean Kubernetes en utilisant le LAMP Helm chart​​​.​​ Ensuite, vous configurerez un contrôleur d’entrée pour ajouter SSL et un nom de domaine personnalisé à votre application. Une fois terminé, vous disposerez d’une application Laravel fonctionnelle connectée à une base de données MySQL qui s’exécute sur un cluster Kubernetes.

      Conditions préalables

      • Docker installé sur la machine à partir de laquelle vous accédez à votre cluster. Vous pouvez trouver des instructions détaillées sur l’installation de Docker pour la plupart des distributions Linux ici ou sur le site web de Docker pour d’autres systèmes d’exploitation.
      • Un compte sur Docker Hub pour stocker les images Docker que vous allez créer pendant ce tutoriel.
      • Un cluster DigitalOcean Kubernetes 1.17+ avec votre connexion configurée sur kubectl par défaut. Pour apprendre à créer un cluster Kubernetes sur DigitalOcean, voir notre Kubernetes Quickstart. Pour apprendre à se connecter au cluster, consultez Comment se connecter à un cluster DigitalOcean Kubernetes.
      • Le gestionnaire de paquets Helm 3 installé sur votre machine locale. Exécutez la première étape et ajoutez le référentiel stable à partir de la deuxième étape du tutoriel Comment installer un logiciel sur des clusters Kubernetes avec le Helm 3 Package Manager.
      • Un nom de domaine entièrement enregistré avec un enregistrement A disponible. Ce tutoriel utilisera your_domain. Vous pouvez acheter un nom de domaine sur Namecheap, en obtenir un gratuitement sur Freenom, ou utiliser le bureau d’enregistrement de domaine de votre choix. Pour le moment, ne vous souciez pas d’associer l’enregistrement A de votre domaine à un IP. Une fois que vous serez à l’étape 5 et que votre contrôleur Ingress est opérationnel, vous connecterez alors your_domain à l’IP qui convient.

      Étape 1 — Création d’une nouvelle application Laravel

      Au cours de cette étape, vous utiliserez Docker pour créer une nouvelle application Laravel 7. Cependant, vous devriez pouvoir suivre le même processus avec une application Laravel existante qui utilise MySQL comme base de données de sauvegarde. La nouvelle application que vous créez vérifiera que Laravel est bien connecté à la base de données et affichera le nom de la base de données.

      Tout d’abord, allez dans votre répertoire principal. Ensuite, créez une nouvelle application Laravel à l’aide d’un conteneur Docker composer :

      • cd ~
      • docker run --rm -v $(pwd):/app composer create-project --prefer-dist laravel/laravel laravel-kubernetes

      Une fois le conteneur créé et tous les paquets Composer installés, vous devriez voir une nouvelle installation de Laravel dans votre répertoire actuel sous le nom de laravel-kubernetes/. Allez dans ce dossier :

      Vous exécuterez le reste des commandes de ce tutoriel à partir de là.

      Cette application a pour rôle de tester votre connexion à la base de données et d’afficher son nom dans votre navigateur. Pour tester la connexion à la base de données, ouvrez le fichier ./resources/views/welcome.blade.php dans un éditeur de texte :

      • nano ./resources/views/welcome.blade.php

      Trouvez la section <div class="links">...</div> et remplacez son contenu par ce qui suit :

      ./resources/views/welcome.blade.php

      ...
      <div class="links">
         <strong>Database Connected: </strong>
          @php
              try {
                  DB::connection()->getPDO();
                  echo DB::connection()->getDatabaseName();
                  } catch (Exception $e) {
                  echo 'None';
              }
          @endphp
      </div>
      ...
      

      Enregistrez et fermez le fichier.

      Voilà l’intégralité de la personnalisation que vous devez apporter à l’application Laravel par défaut dans le cadre de ce tutoriel. Une fois terminé, ce bref extrait de PHP testera votre connexion à la base de données et affichera le nom de la base de données sur l’écran de démarrage de Laravel dans votre navigateur web.

      À l’étape suivante, vous utiliserez Docker pour créer une image contenant cette application Laravel et Docker Compose afin de tester son exécution locale et sa connexion à une base de données MySQL.

      Étape 2 — Conteneurisation de votre application Laravel

      Maintenant que vous avez créé une nouvelle application Laravel, vous devez créer votre code sur une image Docker, puis tester l’image avec Docker Compose. Bien que ce tutoriel ait pour objectif de vous apprendre à déployer votre application sur un cluster Kubernetes, Docker Compose est un moyen pratique de tester votre image et votre configuration Docker localement avant de l’exécuter dans le cloud. Cette boucle de rétroaction rapide peut s’avérer très utile pour effectuer et tester de petits changements.

      Tout d’abord, en utilisant nano ou votre éditeur de texte préféré, créez un fichier à la racine de votre application Laravel que vous appelerez Dockerfile :

      Ajoutez le contenu suivant. Docker utilisera ce fichier pour créer votre code dans une image :

      ./Dockerfile

      FROM php:7.4-apache
      
      # Install packages
      RUN apt-get update && apt-get install -y 
          git 
          zip 
          curl 
          sudo 
          unzip 
          libicu-dev 
          libbz2-dev 
          libpng-dev 
          libjpeg-dev 
          libmcrypt-dev 
          libreadline-dev 
          libfreetype6-dev 
          g++
      
      # Apache configuration
      ENV APACHE_DOCUMENT_ROOT=/var/www/html/public
      RUN sed -ri -e 's!/var/www/html!${APACHE_DOCUMENT_ROOT}!g' /etc/apache2/sites-available/*.conf
      RUN sed -ri -e 's!/var/www/!${APACHE_DOCUMENT_ROOT}!g' /etc/apache2/apache2.conf /etc/apache2/conf-available/*.conf
      RUN a2enmod rewrite headers
      
      # Common PHP Extensions
      RUN docker-php-ext-install 
          bz2 
          intl 
          iconv 
          bcmath 
          opcache 
          calendar 
          pdo_mysql
      
      # Ensure PHP logs are captured by the container
      ENV LOG_CHANNEL=stderr
      
      # Set a volume mount point for your code
      VOLUME /var/www/html
      
      # Copy code and run composer
      COPY --from=composer:latest /usr/bin/composer /usr/bin/composer
      COPY . /var/www/tmp
      RUN cd /var/www/tmp && composer install --no-dev
      
      # Ensure the entrypoint file can be run
      RUN chmod +x /var/www/tmp/docker-entrypoint.sh
      ENTRYPOINT ["/var/www/tmp/docker-entrypoint.sh"]
      
      # The default apache run command
      CMD ["apache2-foreground"]
      

      Enregistrez et fermez le fichier.

      Ce Dockerfile commence avec le PHP 7.4 Apache Docker Image que se trouve sur Docker Hub, puis installe plusieurs des paquets Linux qui sont généralement nécessaires aux applications Laravel. Ensuite, il crée des fichiers de configuration Apache et active les réécritures d’en-tête. Le Dockerfile installe plusieurs extensions PHP communes et ajoute une variable d’environnement afin que les journaux de Laravel soient bien acheminés vers le conteneur via stderr. Cela vous permettra de consulter les journaux Laravel en personnalisant vos journaux Docker Compose ou Kubernetes.

      Enfin, le Dockerfile copie tous les codes de votre application Laravel sur /var/www/tmp et installe les dépendances Composer. Il définit ensuite un ENTRYPOINT, mais vous aurez besoin de créer ce fichier, ce que nous allons faire ensuite.

      Dans le répertoire racine de votre projet, créez un nouveau fichier que vous appellerez docker-entrypoint.sh. Ce fichier s’exécutera lorsque votre conteneur sera exécuté localement ou dans le cluster Kubernetes. Il copiera ensuite votre code d’application Laravel du répertoire /var/www/tmp dans /var/www/html où Apache sera capable de le servir.

      • nano ./docker-entrypoint.sh

      Maintenant, ajoutez le script suivant :

      ./docker-entrypoint.sh

      #!/bin/bash
      
      cp -R /var/www/tmp/. /var/www/html/
      chown -R www-data:www-data /var/www/html
      
      exec "$@"
      

      La ligne finale, exec "$@" indique au shell d’exécuter toute commande ensuite passée à titre d’argument de l’entrée. Ceci est important car Docker doit continuer à exécuter la commande d’exécution d’Apache (apache2-foreground) une fois ce script exécuté. Enregistrez et fermez le fichier.

      Ensuite, créez un fichier .dockerignore dans le répertoire racine de votre application. Lors de la création de votre image Docker, ce fichier veillera à ce qu’elle ne soit pas polluée par des paquets ou des fichiers d’environnement qui ne devraient pas y être copiés :

      ./.dockerignore

      .env
      /vendor
      

      Enregistrez et fermez le fichier.

      Avant de pouvoir exécuter votre application localement avec Docker Compose, vous devez créer un dernier fichier nommé docker-compose.yml. Mais, lors de la configuration de ce fichier YAML, vous devez saisir la APP_KEY générée par Laravel lors de l’installation. Trouvez-la en ouvrant et en faisant une recherche dans le fichier . /.env ou en exécutant les commandes chat et grep suivantes :

      Vous verrez un résultat similaire à ce qui suit :

      Output

      APP_KEY=base64:0EHhVpgg ... UjGE=

      Copiez votre clé dans votre presse-papiers. Veillez à bien inclure le préfixe base64: Maintenant, créez le fichier docker-compose.yml dans le répertoire racine de votre application :

      • nano ./docker-compose.yml

      Ici, nous allons inclure l’image PHP de votre application Laravel ainsi qu’un conteneur MySQL pour exécuter votre base de données. Ajoutez le contenu suivant :

      ./docker-compose.yml

      version: '3.5'
      services:
        php:
          image: your_docker_hub_username/laravel-kubernetes:latest
          restart: always
          ports:
            - 8000:80
          environment:
            - APP_KEY="your_laravel_app_key"
            - APP_ENV=local
            - APP_DEBUG=true
            - DB_PORT=3306
            - DB_HOST=mysql
            - DB_DATABASE
            - DB_USERNAME
            - DB_PASSWORD
        mysql:
          image: mysql:5.7
          restart: always
          environment:
            - MYSQL_ROOT_PASSWORD=${DB_ROOT_PASSWORD}
            - MYSQL_DATABASE=${DB_DATABASE}
            - MYSQL_USER=${DB_USERNAME}
            - MYSQL_PASSWORD=${DB_PASSWORD}
      

      Utilisez la variable APP_KEY que vous avez copiée dans votre presse-papiers pour la variable your_laravel_app_key et utilisez votre nom d’utilisateur Docker Hub pour la variable your_docker_hub_username. Enregistrez et fermez le fichier.

      Vous allez créer la première image localement en utilisant docker build. La deuxième image est l’image officielle de MySQL Docker, disponible sur Docker Hub. Toutes deux nécessitent plusieurs variables d’environnement que vous allez inclure lors de l’exécution des conteneurs.

      Pour créer l’image Docker qui contient votre application Laravel, exécutez la commande suivante. Veillez à bien remplacer your_docker_hub_username par votre nom d’utilisateur ou le nom d’utilisateur de votre équipe dans Docker Hub où cette image sera sauvegardée :

      • docker build -t your_docker_hub_username/laravel-kubernetes:latest .

      Ensuite, vous pouvez exécuter les deux conteneurs avec Docker Compose et les identifiants de base de données nécessaires :

      • DB_ROOT_PASSWORD=rootpassword DB_DATABASE=local_db DB_USERNAME=admin DB_PASSWORD=password docker-compose up -d

      Au besoin, vous pouvez modifier les quatre variables d’environnement utilisées ici (DB_ROOT_PASSWORD, DB_DATABASE, DB_USERNAME, DB_PASSWORD). Cependant, étant donné vous testez votre application que localement, inutile de les sécuriser pour le moment.

      Il vous faudra près de 30 secondes pour que votre base de données MySQL soit initialisée et que vos conteneurs soient prêts. Une fois que cela est fait, vous pouvez consulter votre application Laravel sur votre machine sur localhost:8000.

      Exécution locale de l'application Laravel avec Docker Compose

      Votre application PHP se connectera à votre base de données MySQL. Une fois connecté, vous verrez apparaître le texte « Database Connected: local_db » apparaître sous le logo Laravel.

      Maintenant que vous avez testé votre image Docker localement avec Docker Compose, vous pouvez arrêter les conteneurs en exécutant docker-compose down :

      Dans la section suivante, vous allez pousser votre image Docker sur Docker Hub afin que votre chart Helm puisse l’utiliser et déployer votre application dans votre cluster Kubernetes.

      Étape 3 — Poussez votre image Docker dans Docker Hub

      Votre code doit être disponible dans un registre de conteneurs pour que le chart Helm LAMP que vous utiliserez puisse le déployer sur Kubernetes. Bien que vous puissiez pousser votre image dans un registre privé ou autohébergé, aux fins de ce tutoriel, vous utiliserez un registre Docker public et gratuit sur Docker Hub.

      Accédez à votre compte dans Docker Hub en utilisant votre navigateur web. Créez ensuite un nouveau référentiel nommé laravel-kubernetes.

      Création d'un nouveau référentiel dans Docker Hub

      Si vous n’êtes pas connecté à Docker Hub depuis votre machine locale, vous devez ensuite vous y connecter. Vous pouvez le faire grâce à la ligne de commande suivante :

      • docker login -u your_docker_hub_username

      Saisissez vos identifiants de connexion lorsque vous serez invité à le faire. Il est généralement nécessaire de le faire qu’une seule fois par machine. En effet, Docker enregistrera vos identifiants dans ~/.docker/config.json​​​ dans votre répertoire personnel.

      Enfin, poussez votre image dans Docker Hub :

      • docker push your_docker_hub_username/laravel-kubernetes:latest

      En fonction de la vitesse de votre connexion, le téléchargement de votre application peut prendre quelques minutes. Cependant, une fois Docker terminé, vous verrez un hachage cryptographique et la taille de votre image dans le terminal. Elle ressemblera à cela :

      Output

      latest: digest: sha256:df4bdeda91484c8c26a989b13b8f27ab14d93ab2e676e3c396714cb3811c4086 size: 4918

      Maintenant que votre application Laravel est conteneurisée et que vous avez poussé une image dans Docker Hub, vous pouvez utiliser l’image dans un déploiement de chart Helm ou Kubernetes. Au cours de la prochaine étape, vous allez configurer des valeurs personnalisées en fonction du chart LAMP Helm et le déployer dans votre cluster DigitalOcean Kubernetes.

      Étape 4 — Configuration et déploiement de l’application avec chart LAMP Helm

      Helm propose un certain nombre de Charts pour vous aider à configurer des applications Kubernetes en utilisant des combinaisons d’outils prédéfinies. Même si vous pouvez écrire vos propres fichiers de service Kubernetes pour effectuer un déploiement similaire, dans cette section vous verrez que l’utilisation d’un chart Helm nécessite beaucoup moins de configuration.

      Tout d’abord, vous aurez besoin d’un répertoire pour y stocker tous vos fichiers de configuration Helm. Créez un nouveau répertoire dans la racine de votre projet Laravel que vous nommerez helm/ :

      Dans le répertoire helm/, vous allez créer deux nouveaux fichiers : values.yml et secrets.yml. Commencez par créer et ouvrir values.yml :

      Le fichier values.yml comprendra des options de configuration non secrètes qui remplaceront les valeurs par défaut dans le chart LAMP Helm. Ajoutez les configurations suivantes, tout en veillant bien à remplacer your_docker_hub_username par votre nom d’utilisateur :

      ./helm/values.yml

      php:
        repository: "your_docker_hub_username/laravel-kubernetes"
        tag: "latest"
        fpmEnabled: false
        envVars:
          - name: APP_ENV
            value: production
          - name: APP_DEBUG
            value: false
          - name: DB_PORT
            value: 3306
          - name: DB_HOST
            value: localhost
      

      Enregistrez et fermez le fichier.

      Maintenant, créez un fichier secrets.yml :

      secrets.yml ne sera pas archivé dans le contrôle de version. Il contiendra des informations de configuration sensibles comme votre mot de passe et votre clé d’app Laravel. Ajoutez les configurations suivantes, en les ajustant au besoin pour qu’elles soient adaptées à vos identifiants :

      ./helm/secrets.yml

      mysql:
        rootPassword: "your_database_root_password"
        user: your_database_user
        password: "your_database_password"
        database: your_database_name
      
      php:
        envVars:
          - name: APP_KEY
            value: "your_laravel_app_key"
          - name: DB_DATABASE
            value: your_database_name
          - name: DB_USERNAME
            value: your_database_user
          - name: DB_PASSWORD
            value: "your_database_password"
      

      Veillez à utiliser des combinaisons de noms d’utilisateur et de mot de passe difficiles à trouver pour votre base de données de production. Utilisez la même your_laravel_app_key que celle indiquée ci-dessus. Sinon, ouvrez une nouvelle fenêtre et générez un nouveau fichier en exécutant la commande suivante. Vous pouvez ensuite copier la nouvelle valeur configurée par Laravel dans votre fichier .env :

      • docker run --rm -v $(pwd):/app php:cli php /app/artisan key:generate

      Sauvegardez et fermez secrets.yml​​​​.

      Ensuite, afin d’empêcher votre fichier secrets.yml d’être intégré à l’image Docker ou d’être sauvegardé dans le contrôle de version, veillez à bien ajouter la ligne suivante à la fois dans vos fichiers .dockerignore et .gitignore. Ouvrez et ajoutez /helm/secrets.yml dans chaque fichier, ou exécutez la commande suivante pour ajouter les deux :

      • echo '/helm/secrets.yml' >> ./.dockerignore && echo '/helm/secrets.yml' >> ./.gitignore

      Maintenant que vous avez créé les fichiers de configuration Helm pour votre application et l’image Docker, vous pouvez installer ce chart Helm comme une nouvelle version dans votre cluster Kubernetes. Installez votre chart dans le répertoire racine de votre application :

      • helm install laravel-kubernetes -f helm/values.yml -f helm/secrets.yml stable/lamp

      Vous verrez un résultat similaire à ce qui suit :

      Output

      NAME: laravel-kubernetes LAST DEPLOYED: Mon May 18 13:21:20 2020 NAMESPACE: default STATUS: deployed REVISION: 1

      Il faudra une à deux minutes pour que votre application soit disponible. Cependant, vous pouvez exécuter cette commande pour surveiller les services Kubernetes dans votre cluster :

      Recherchez le nom de votre application :

      Output

      NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) laravel-kubernetes-lamp LoadBalancer your_cluster_ip your_external_ip 80:32175/TCP,3306:32243/TCP

      Lorsque votre nouveau service laravel-kubernetes-lamp affiche une adresse IP sous EXTERNAL-IP, vous pouvez consulter your_external_ip pour voir l’application qui est exécutée dans votre cluster Kubernetes. Votre application se connectera à votre base de données. Vous verrez alors le nom de la base de données apparaître sous le logo Laravel, comme ce fut le cas lors de l’exécution locale de votre application dans Docker Compose.

      Exécution de l'application Laravel sous Kubernetes en utilisant le chart LAMP Helm

      L’exécution d’une application web sur une adresse IP non sécurisée est adaptée pour une démonstration de faisabilité. Cependant, votre site web n’est pas prêt à être publié sans certificat SSL et un nom de domaine personnalisé. Avant que vous configuriez cela à l’étape suivante, désinstallez votre version via la ligne de commande suivante :

      • helm delete laravel-kubernetes

      Au cours de la prochaine étape, vous allez étendre cette première configuration Helm pour ajouter un contrôleur Ingress, un certificat SSL et un domaine personnalisé à votre application Laravel.

      Étape 5 — Ajout d’un contrôleur Ingress et SSL à votre cluster Kubernetes

      Dans Kubernetes, un contrôleur Ingress est chargé d’exposer les services de votre application sur Internet. À l’étape précédente, le chart LAMP Helm a créé un équilibreur de charge DigitalOcean et a exposé votre application directement via l’adresse IP de l’équilibreur de charge.

      Vous pourriez résilier SSL et votre nom de domaine directement sur l’équilibreur de charge. Cependant, étant donné que vous travaillez dans Kubernetes, il serait plus pratique de gérer celà au même endroit. Pour plus d’informations sur les contrôleurs Ingress et des détails sur les étapes suivantes, consultez Comment configurer un Ingress Nginx sur DigitalOcean Kubernetes en utilisant Helm.

      Le chart LAMP Helm intègre une option de configuration pour prendre en charge Ingress. Ouvrez votre fichier helm/values.yml :

      Maintenant, ajoutez les lignes suivantes :

      ./helm/values.yml

      ...
      # Use Ingress Controller
      service:
        type: ClusterIP
        HTTPPort: 80
      ingress:
        enabled: true
        domain: your_domain
      

      Cela indique à votre déploiement de ne pas installer d’équilibreur de charge et d’exposer l’application dans le port 80 du cluster Kubernetes où le contrôleur Ingress l’exposera sur Internet. Sauvegardez et fermez values.yml​​​​.

      Maintenant, exécutez la commande helm install que vous avez exécutée précédemment pour que votre application Laravel s’exécute à nouveau. Veillez à exécuter la commande à partir du répertoire racine de votre application :

      • helm install laravel-kubernetes -f helm/values.yml -f helm/secrets.yml stable/lamp

      Ensuite, installez le contrôleur nginx-ingress sur votre cluster Kubernetes en utilisant le contrôleur Nginx Ingress maintenu sous Kubernetes :

      • helm install nginx-ingress stable/nginx-ingress --set controller.publishService.enabled=true

      Après l’installation, vous aurez un résultat similaire à ce qui suit :

      Output

      NAME: nginx-ingress LAST DEPLOYED: Mon May 18 13:28:34 2020 NAMESPACE: default STATUS: deployed REVISION: 1

      Vous avez également besoin d’une Ressource Ingress pour exposer le déploiement de votre application Laravel. Créez un nouveau fichier dans le répertoire racine de votre application que vous nommerez ingress.yml :

      Ce fichier définit l’hôte de votre application, le gestionnaire de certificat SSL, le service de backend et le nom de port de votre application. Ajoutez les configurations suivantes en remplacant your_domain avec le domaine de votre choix :

      ./ingress.yml

      apiVersion: networking.k8s.io/v1beta1
      kind: Ingress
      metadata:
        name: laravel-kubernetes-ingress
        annotations:
          kubernetes.io/ingress.class: nginx
          cert-manager.io/cluster-issuer: letsencrypt-prod
      spec:
        tls:
          - hosts:
              - your_domain
            secretName: laravel-kubernetes-tls
        rules:
          - host: your_domain
            http:
              paths:
                - backend:
                    serviceName: laravel-kubernetes-lamp
                    servicePort: 80
      

      Enregistrez et fermez le fichier.

      Ensuite, vous deviez installer Cert-Manager et créer un émetteur qui vous permettra de créer des certificats SSL de production en utilisant Let’s Encrypt. Cert-Manager nécessite des Custom Resource Definitions​​​ que vous pouvez appliquer à partir du Cert-Manager repository​​​ en utilisant la ligne de commande suivante :

      • kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v0.15.0/cert-manager.crds.yaml

      Cela créera un certain nombre de ressources Kubernetes qui s’afficheront dans la ligne de commande :

      Output

      customresourcedefinition.apiextensions.k8s.io/certificaterequests.cert-manager.io created customresourcedefinition.apiextensions.k8s.io/certificates.cert-manager.io created customresourcedefinition.apiextensions.k8s.io/challenges.acme.cert-manager.io created customresourcedefinition.apiextensions.k8s.io/clusterissuers.cert-manager.io created customresourcedefinition.apiextensions.k8s.io/issuers.cert-manager.io created customresourcedefinition.apiextensions.k8s.io/orders.acme.cert-manager.io create

      Cert-Manager a également besoin d’un namespace pour l’isoler dans votre cluster Kubernetes :

      • kubectl create namespace cert-manager

      Vous verrez ce résultat :

      Output

      namespace/cert-manager created

      Étant donné que le Cert-Manager de Jetstack ne fait pas partie des charts maintenus par Kubernetes, vous aurez également besoin d’ajouter le référentiel Helm Jetstack. Exécutez la commande suivante pour le rendre disponible dans Helm :

      • helm repo add jetstack https://charts.jetstack.io

      Si l’ajout est correctement effectué, vous obtiendrez le résultat suivant :

      Output

      "jetstack" has been added to your repositories

      Maintenant, vous êtes prêt à installer Cert-Manager dans l’espace de nommage cert-manager​​​ de votre cluster Kubernetes :

      • helm install cert-manager --version v0.15.0 --namespace cert-manager jetstack/cert-manager

      Une fois terminé, vous verrez apparaître un résumé du déploiement similaire à ce qui suit :

      Output

      NAME: cert-manager LAST DEPLOYED: Mon May 18 13:32:08 2020 NAMESPACE: cert-manager STATUS: deployed REVISION: 1

      Le dernier fichier que vous devez ajouter dans le répertoire racine de votre application Laravel est un fichier de configuration de Kubernetes production_issuer.yml. Créez le fichier :

      • nano ./production_issuer.yml

      Maintenant, ajoutez ce qui suit :

      apiVersion: cert-manager.io/v1alpha2
      kind: ClusterIssuer
      metadata:
        name: letsencrypt-prod
      spec:
        acme:
          # Email address used for ACME registration
          email: your_email_address
          server: https://acme-v02.api.letsencrypt.org/directory
          privateKeySecretRef:
            # Name of a secret used to store the ACME account private key
            name: letsencrypt-prod-private-key
          # Add a single challenge solver, HTTP01 using nginx
          solvers:
            - http01:
                ingress:
                  class: nginx
      

      Enregistrez et fermez le fichier.

      Let’s Encrypt enverra toutes les notifications importantes et tous les avertissements d’expiration à your_email_address. Veillez donc à bien ajouter une adresse que vous consultez régulièrement. Sauvegardez ce fichier et créez une nouvelle ressource à la fois pour votre ressource Ingress et votre émetteur de production dans votre cluster Kubernetes :

      • kubectl create -f ingress.yml
      • kubectl create -f production_issuer.yml

      Enfin, mettez à jour les enregistrements DNS de votre nom de domaine pour qu’un enregistrement A pointe vers l’adresse IP de votre équilibreur de charge. Pour trouver l’adresse IP de votre contrôleur Ingress, saisissez ce qui suit :

      • kubectl get service nginx-ingress-controller

      Output

      NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx-ingress-controller LoadBalancer your_cluster_ip your_external_ip 80:30187/TCP,443:31468/TCP 6m10s

      Utilisez l’adresse your_external_ip comme adresse IP de votre Enregistrement A de DNS. Le processus de mise à jour de vos enregistrements DNS varie en fonction de l’endroit où vous gérez vos noms de domaine et l’hébergement DNS. Cependant, si vous utilisez DigitalOcean, vous pouvez consulter notre guide Comment gérer vos enregistrements DNS.

      Une fois que vos enregistrements DNS sont mis à jour et votre certificat SSL est configuré, votre application sera disponible sur your_domain et SSL sera activée.

      L'application Laravel avec terminaison SSL et un nom de domaine personnalisé

      Même si votre application et votre base de données PHP sont déjà connectées, vous aurez encore besoin de migrer la base de données. Au cours de la dernière étape, vous verrez comment exécuter des Artisan commands sur votre pod Kubernetes pour migrer la base de données et effectuer d’autres tâches de maintenance communes.

      Étape 6 — Exécution de commandes à distance

      Même si votre application Laravel fonctionne et est connectée à la base de données MySQL dans Kubernetes, vous aurez besoin d’effectuer plusieurs opérations communes sur une nouvelle installation Laravel. Une de ces tâches communes est la migration de base de données.

      Avant que vous puissiez exécuter une commande Artisan sur votre application Laravel, vous devez connaître le nom du pod qui exécute votre conteneur d’application Laravel. En utilisant la ligne de commande suivante, vous pouvez consulter tous les pods de votre cluster Kubernetes :

      Vous verrez un résultat similaire à ce qui suit :

      Output

      NAME READY STATUS RESTARTS AGE laravel-kubernetes-lamp-77fb989b46-wczgb 2/2 Running 0 16m

      Sélectionnez le pod pour votre déploiement laravel-kubernetes-lamp-... Veillez à bien utiliser le nom dans votre résultat et non celui mentionné ci-dessus. Maintenant, vous pouvez y exécuter kubectl exec. Par exemple, exécutez une migration de base de données en utilisant la commande artisan migrate. Vous allez ajouter la balise --force car vous exécutez le pod en production :

      • kubectl exec laravel-kubernetes-lamp-77fb989b46-wczgb -- php artisan migrate --force

      Cette commande générera un résultat :

      Output

      Migration table created successfully. Migrating: 2014_10_12_000000_create_users_table Migrated: 2014_10_12_000000_create_users_table (0.16 seconds) Migrating: 2019_08_19_000000_create_failed_jobs_table Migrated: 2019_08_19_000000_create_failed_jobs_table (0.05 seconds)

      Vous avez maintenant déployé correctement Laravel 7 et MySQL dans Kubernetes et exécuté une tâche essentielle de maintenance de la base de données.

      Conclusion

      Dans ce tutoriel, vous avez appris à conteneuriser une application PHP Laravel, à la connecter à une base de données MySQL, à pousser une image Docker contenant votre code sur Docker Hub, puis à utiliser un chart Helm pour la déployer sur un cluster DigitalOcean Kubernetes. Enfin, vous avez ajouté un SSL et un nom de domaine personnalisé et appris à exécuter des outils de ligne de commande sur vos pods en cours d’exécution.

      Par rapport à l’hébergement traditionnel de pile LAMP, Kubernetes et Helm vous offrent un certain nombre d’avantages : extensibilité, échange de services sans connexion directe à votre serveur, outils de mises à jour en roulement et contrôle de votre environnement d’hébergement. Cela dit, la complexité initiale de la conteneurisation et de la configuration rendent le démarrage de votre application assez difficile. En utilisant ce guide comme point de départ, il est plus facile de déployer Laravel sur Kubernetes. À partir de là, vous pourriez envisager d’en apprendre plus sur la puissance de Laravel ou sur l’ajout d’outils de surveillance à Kubernetes (Linkerd, par exemple), que vous pouvez installer manuellement avec notre guide ou avec un DigitalOcean 1-Click​​​.



      Source link

      Comment créer un pool de stockage redondant en utilisant GlusterFS sur Ubuntu 20.04


      Une version antérieure de ce tutoriel a été écrite par Brennan Bearnes.

      Introduction

      Lorsque vous stockez des données critiques, avoir un seul point de défaillance est très risqué. Alors que beaucoup de bases de données et autres logiciels vous permettent de répartir les données dans le contexte d’une seule application, d’autres systèmes peuvent fonctionner au niveau du système de fichiers pour s’assurer que les données sont copiées à un autre endroit chaque fois qu’elles sont écrites sur le disque.

      GlusterFS est un système de fichiers de stockage connecté en réseau qui vous permet de mettre en commun les ressources de stockage de plusieurs machines. Cela vous permet de traiter plusieurs périphériques de stockage répartis sur plusieurs ordinateurs comme une seule unité plus puissante. GlusterFS vous donne également la liberté de créer différents types de configurations de stockage, dont beaucoup sont fonctionnellement similaires aux niveaux RAID. Par exemple, vous pouvez répartir les données sur différents nœuds du cluster, ou vous pouvez mettre en place une redondance pour une meilleure disponibilité des données.

      Objectifs

      Dans ce guide, vous créerez un tableau de stockage redondant en grappe, également connu sous le nom de système de fichiers distribués ou, comme il est mentionné dans la documentation GlusterFS, un pool de stockage fiable. Cela fournira des fonctionnalités similaires à une configuration RAID en miroir sur le réseau : chaque serveur indépendant contiendra sa propre copie des données, ce qui permettra à vos applications d’accéder à l’une ou l’autre des copies, contribuant ainsi à répartir votre charge de lecture.

      Ce cluster GlusterFS redondant sera composé de deux serveurs Ubuntu 20.04. I agira comme un serveur NAS avec RAID en miroir. Vous accéderez ensuite au cluster à partir d’un troisième serveur Ubuntu 20.04 configuré pour fonctionner comme client GlusterFS.

      Une note sur l’exécution sécurisée de GlusterFS

      Lorsque vous ajoutez des données à un volume GlusterFS, les données sont synchronisées à chaque machine du pool de stockage où le volume est hébergé. Ce trafic entre les nœuds n’est pas crypté par défaut, ce qui signifie qu’il y a un risque qu’il puisse être intercepté par des acteurs malveillants.

      Pour cette raison, si vous souhaitez utiliser GlusterFS en production, il est recommandé de l’exécuter sur un réseau isolé. Par exemple, vous pouvez le configurer pour qu’il fonctionne sur un nuage privé virtuel (VPC) ou avec un VPN fonctionnant entre chacun des nœuds.

      Si vous prévoyez de déployer GlusterFS sur DigitalOcean, vous pouvez le configurer comme un réseau isolé en ajoutant votre infrastructure de serveur à un nuage privé virtuel DigitalOcean. Pour plus de détails sur la manière de le mettre en place, consultez notre documentation sur les produits VPC.

      Conditions préalables

      Pour suivre ce tutoriel, vous aurez besoin de trois serveurs fonctionnant sous Ubuntu 20.04. Chaque serveur doit avoir un utilisateur non root avec des privilèges administratifs et un pare-feu configuré avec UFW. Pour le mettre en place, suivez notre guide de configuration initiale du serveur pour Ubuntu 20.04.

      Remarque : Comme mentionné à la section Objectifs, ce tutoriel vous guidera à travers la configuration de deux de vos serveurs Ubuntu pour qu’ils agissent comme des serveurs dans votre pool de stockage et le dernier pour qu’il agisse comme un client que vous utiliserez pour accéder à ces nœuds.

      Pour plus de clarté, ce tutoriel fera référence à ces machines avec les noms d’hôte suivants :

      Nom d’hôteRôle dans le pool de stockage
      gluster0Serveur
      gluster1Serveur
      gluster2Client

      Les commandes qui devraient être exécutées sur gluster0 ou gluster1 auront respectivement des arrière-plans bleu et rouge :

      Les commandes qui ne devraient être exécutées que sur le client (gluster2) auront un arrière-plan vert :

      Les commandes qui peuvent ou devraient être exécutées sur plusieurs machines auront un arrière-plan gris :

      Étape 1 – Configuration de la résolution DNS sur chaque machine

      La mise en place d’une sorte de résolution de nom d’hôte entre chaque ordinateur peut aider à gérer votre pool de stockage Gluster. De cette façon, chaque fois que vous devez référencer une de vos machines dans une commande gluster plus loin dans ce tutoriel, vous pourrez le faire avec un nom de domaine facile à mémoriser ou même un surnom au lieu de leurs adresses IP respectives.

      Si vous n’avez pas de nom de domaine de rechange, ou si vous souhaitez simplement configurer quelque chose rapidement, vous pouvez à la place modifier le fichier /etc/hosts sur chaque ordinateur. Il s’agit d’un fichier spécial sur les machines Linux où vous pouvez configurer le système de manière statique pour résoudre tous les noms d’hôte contenus dans le fichier en adresses IP statiques.

      Remarque : Si vous souhaitez configurer vos serveurs pour qu’ils s’authentifient avec un domaine qui vous appartient, vous devrez d’abord obtenir un nom de domaine à partir d’un registraire de domaine — comme Namecheap ou Enom — et configurer les enregistrements DNS appropriés.

      Une fois que vous avez configuré un enregistrement A pour chaque serveur, vous pouvez passer à l’étape 2. En suivant ce guide, assurez-vous de remplacer glusterN.example.com et gluster<^>N<^> par le nom de domaine qui se résout au serveur respectif référencé dans la commande example.

      Si vous avez obtenu votre infrastructure auprès de DigitalOcean, vous pouvez ajouter votre nom de domaine à DigitalOcean puis configurer un enregistrement A unique pour chacun de vos serveurs.

      À l’aide de votre éditeur de texte préféré, ouvrez ce fichier avec des privilèges root sur chacune de vos machines. Ici, nous utiliserons nano :

      Par défaut, le fichier ressemblera à quelque chose comme celui-ci avec les commentaires supprimés :

      /etc/hosts

      127.0.1.1 hostname hostname
      127.0.0.1 localhost
      
      ::1 ip6-localhost ip6-loopback
      fe00::0 ip6-localnet
      ff00::0 ip6-mcastprefix
      ff02::1 ip6-allnodes
      ff02::2 ip6-allrouters
      ff02::3 ip6-allhosts
      

      Sur l’un de vos serveurs Ubuntu, ajoutez l’adresse IP de chaque serveur, suivi des noms que vous souhaitez utiliser pour les référencer dans des commandes sous la définition de l’hôte locale.

      Dans l’exemple suivant, chaque serveur a un long nom d’hôte qui s’aligne sur glusterN.example.com et un nom court qui s’aligne sur glusterN. Vous pouvez changer les portions de glusterN.example.com et de glusterN de chaque ligne en n’importe quel nom — ou des noms séparés par des espaces uniques — que vous souhaitez utiliser pour accéder à chaque serveur. Notez, cependant, que ce tutoriel utilisera ces exemples tout au long :

      Remarque : Si vos serveurs font partie d’un pool d’infrastructure VPC, vous devez utiliser l’adresse IP privée de chaque serveur dans le fichier /etc/hosts plutôt que leurs IP publiques.

      /etc/hosts

      . . .
      127.0.0.1       localhost
      first_ip_address gluster0.example.com gluster0
      second_ip_address gluster1.example.com gluster1
      third_ip_address gluster2.example.com gluster2
      
      . . .
      

      Lorsque vous avez terminé d’ajouter ces nouvelles lignes au fichier /etc/hosts d'une machine, copiez-les et ajoutez-les aux fichiers /etc/hosts de vos autres machines. Chaque fichier /etc/hosts devrait contenir les mêmes lignes, reliant les adresses IP de vos serveurs aux noms que vous avez sélectionnés.

      Enregistrez et fermez chaque fichier lorsque vous avez terminé. Si vous avez utilisé nano, faites-le en appuyant sur CTRL+X, Y, puis ENTER.

      Maintenant que vous avez configuré la résolution de nom d’hôte entre chacun de vos serveurs, il sera plus facile d’exécuter des commandes plus tard lorsque vous configurez un pool de stockage et un volume. Ensuite, vous passerez par une autre étape qui doit être réalisée sur chacun de vos serveurs. À savoir, ajouter l’archive personnelle officielle des paquets du projet Gluster (PPA) à chacun de vos trois serveurs Ubuntu pour vous assurer que vous pouvez installer la dernière version de GlusterFS.

      Étape 2 – Configuration des sources logicielles sur chaque machine

      Bien que les référentiels Ubuntu 20.04 APT par défaut contiennent des paquets GlusterFS, au moment où nous écrivons ces lignes, ce ne sont pas les versions les plus récentes. Une façon d’installer la dernière version stable de GlusterFS (version 7.6 au moment où nous écrivons ces lignes) consiste à ajouter le PPA officiel du projet Gluster à chacun de vos trois serveurs Ubuntu.

      Ajoutez le PPA pour les paquets GlusterFS en exécutant la commande suivante sur chaque serveur :

      • sudo add-apt-repository ppa:gluster/glusterfs-7

      Appuyez sur ENTER lorsque vous êtes invité à confirmer que vous souhaitez réellement ajouter le PPA.

      Après avoir ajouté le PPA, actualisez l’index local des paquets de chaque serveur. Cela permettra à chaque serveur de prendre connaissance des nouveaux paquets disponibles :

      Après avoir ajouté le PPA officiel du projet Gluster sur chaque serveur et mis à jour l’index local des paquets, vous êtes prêt à installer les paquets GlusterFS nécessaires. Cependant, comme deux de vos trois machines agira comme serveurs Gluster et l’autre comme client, il existe deux procédures distinctes d’installation et de configuration. Tout d’abord, vous installerez et configurez les composants du serveur.

      Étape 3 – Installation des composants du serveur et création d’un pool de stockage de confiance

      Un pool de stockage est toute quantité de capacité de stockage agrégée à partir de plusieurs ressources de stockage. Au cours de cette étape, vous configurez deux de vos serveurs — gluster0 et gluster1 — comme les composants du cluster.

      Sur gluster0 et gluster1, installez le paquet de serveur GlusterFS en saisissant :

      • sudo apt install glusterfs-server

      Lorsque vous y êtes invité, appuyez sur Y et ensuite ENTER pour confirmer l’installation.

      Le processus d’installation configure automatiquement GlusterFS pour qu’il fonctionne comme un service systemd. Cependant, il ne démarre pas automatiquement le service ou ne lui permet pas de s’exécuter au démarrage.

      Pour démarrer glusterd, le service GlusterFS, exécutez la commande systemctl start suivante sur gluster0 et gluster1 :

      • sudo systemctl start glusterd.service

      Ensuite, lancez la commande suivante sur les deux serveurs. Cela permettra au service de démarrer chaque fois que le serveur démarre :

      • sudo systemctl enable glusterd.service

      Ensuite, vous pouvez vérifier l’état du service sur l’un ou les deux serveurs :

      • sudo systemctl status glusterd.service

      Si le service est opérationnel, vous recevrez un résultat comme celui-ci :

      Output

      ● glusterd.service - GlusterFS, a clustered file-system server Loaded: loaded (/lib/systemd/system/glusterd.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2020-06-02 21:32:21 UTC; 32s ago Docs: man:glusterd(8) Main PID: 14742 (glusterd) Tasks: 9 (limit: 2362) CGroup: /system.slice/glusterd.service └─14742 /usr/sbin/glusterd -p /var/run/glusterd.pid --log-level INFO

      En supposant que vous ayez suivi le guide initial des prérequis de configuration du serveur, vous aurez mis en place un pare-feu avec UFW sur chacune de vos machines. À cause de cela, vous devrez ouvrir le pare-feu sur chaque nœud avant de pouvoir établir des communications entre eux et créer un pool de stockage.

      Le démon Gluster utilise le port 24007, vous devrez donc autoriser chaque nœud à accéder à ce port à travers le pare-feu de chaque autres nœuds de votre pool de stockage. Pour ce faire, lancez la commande suivante sur gluster0. N’oubliez pas de remplacer gluster1_ip_address par l’adresse IP de gluster1 :

      • sudo ufw allow from gluster1_ip_address to any port 24007

      Et lancez la commande suivante sur gluster1. Encore une fois, veillez à remplacer gluster0_ip_address par l’adresse IP de gluster0 :

      • sudo ufw allow from gluster0_ip_address to any port 24007

      Vous devrez également autoriser votre machine client (gluster2) à accéder à ce port. Sinon, vous rencontrerez des problèmes plus tard lorsque vous essayerez de monter le volume. Exécutez la commande suivante sur gluster0 et gluster1 pour ouvrir ce port à votre machine cliente :

      • sudo ufw allow from gluster2_ip_address to any port 24007

      Ensuite, pour s’assurer qu’aucune autre machine ne soit puisse accéder au port de Gluster sur l’un ou l’autre des serveurs, ajoutez la règle deny absolue suivante à la fois à gluster0 et gluster1 :

      Vous êtes maintenant prêt à établir la communication entre gluster0 et gluster1. Pour ce faire, vous devrez exécuter la commande gluster peer probe sur l’un de vos nœuds. Peu importe le nœud que vous utilisez, mais l’exemple suivant montre la commande en cours sur gluster0 :

      • sudo gluster peer probe gluster1

      En gros, cette commande indique à gluster0 de faire confiance à gluster1 et de l’enregistrer comme faisant partie de son pool de stockage. Si le sondage est réussi, il renverra la sortie suivante :

      Output

      peer probe: success

      Vous pouvez vérifier que les nœuds communiquent à tout moment en exécutant la commande gluster peer status sur l’un ou l’autre . Dans cet exemple, il est exécuté sur gluster1 :

      Si vous lancez cette commande à partir de gluster1, il affichera la sortie suivante :

      Output

      Number of Peers: 1 Hostname: gluster0.example.com Uuid: a3fae496-c4eb-4b20-9ed2-7840230407be State: Peer in Cluster (Connected)

      À ce stade, vos deux serveurs communiquent et sont prêts à créer des volumes de stockage entre eux.

      Étape 4 – Créer un volume de stockage

      Rappelons que l’objectif principal de ce tutoriel est de créer un pool de stockage redondant. À cette fin, vous allez mettre en place un volume avec une fonctionnalité de réplication, vous permettant de conserver plusieurs copies de vos données et d’éviter à votre cluster d’avoir un seul point de défaillance.

      Pour créer un volume, vous utiliserez la commande gluster volume create avec cette syntaxe générale :

      sudo gluster volume create volume_name replica number_of_servers domain1.com:/path/to/data/directory domain2.com:/path/to/data/directory force
      

      Voici ce que ce signifient les arguments et les options cette commande gluster volume create signifient :

      • volume_name : C’est le nom que vous utiliserez pour faire référence au volume après sa création. L’exemple de commande suivant crée un volume nommé volume1.
      • réplica number_of_servers: : À la suite du nom du volume, vous pouvez définir le type de volume que vous souhaitez créer. Rappelons que l’objectif de ce tutoriel est de créer un pool de stockage redondant, nous utiliserons donc le type de volume replica. Cela exige un argument indiquant sur combien de serveurs les données du volume seront répliquées (2 dans le cas de ce tutoriel).
      • domain1.com:/… et domain2.com:/… : Ces éléments définissent les machines et l’emplacement du répertoire des briques — le terme de GlusterFS pour son unité de stockage de base, qui comprend tous les répertoires sur toutes les machines qui servent comme partie ou copie d’un volume plus important — qui constitueront le volume1. L’exemple suivant créera un répertoire nommé gluster-storage dans le répertoire racine des deux serveurs.
      • force : Cette option remplacera les avertissements ou les options qui autrement pourraient apparaître et arrêter la création du volume.

      En suivant les conventions établies précédemment dans ce tutoriel, vous pouvez exécuter cette commande pour créer un volume. Notez que vous pouvez l’exécuter à partir de gluster0 ou de gluster1 :

      • sudo gluster volume create volume1 replica 2 gluster0.example.com:/gluster-storage gluster1.example.com:/gluster-storage force

      Si le volume a été créé avec succès, vous recevrez la sortie suivante :

      Output

      volume create: volume1: success: please start the volume to access data

      À ce stade, votre volume a été créé, mais il n’est pas encore actif. Vous pouvez démarrer le volume et le rendre disponible pour l’utilisation en exécutant la commande suivante, toujours à partir de l’un de vos serveurs Gluster :

      • sudo gluster volume start volume1

      Vous recevrez cette sortie si le volume a été démarré correctement :

      Output

      volume start: volume1: success

      Ensuite, vérifiez que le volume est en ligne. Exécutez la commande suivante à partir de l’un de vos nœuds :

      • sudo gluster volume status

      Cela renverra la sortie semblable à celle-ci :

      Output

      Status of volume: volume1 Gluster process TCP Port RDMA Port Online Pid ------------------------------------------------------------------------------ Brick gluster0.example.com:/gluster-storage 49152 0 Y 18801 Brick gluster1.example.com:/gluster-storage 49152 0 Y 19028 Self-heal Daemon on localhost N/A N/A Y 19049 Self-heal Daemon on gluster0.example.com N/A N/A Y 18822 Task Status of Volume volume1 ------------------------------------------------------------------------------ There are no active volume tasks

      Sur la base de cette sortie, les briques sur les deux serveurs sont en ligne.

      En guise de dernière étape pour configurer votre volume, vous devrez ouvrir le pare-feu sur les deux serveurs pour que votre machine cliente puisse se connecter et monter le volume. Selon l’exemple de sortie de la commande précédente, volume1 tourne sur le port 49152 sur les deux machines. C’est le port par défaut de GlusterFS pour son volume initial, et le prochain volume que vous crérez utilisera le port 49153, puis 49154, etc.

      Exécutez la commande suivante sur gluster0 et gluster1 pour autoriser gluster2 à accéder à ce port à travers le pare-feu respectif de chacun :

      • sudo ufw allow from gluster2_ip_address to any port 49152

      Ensuite, pour une couche de sécurité supplémentaire, ajoutez une autre règle deny absolue pour le port du volume sur gluster0 et gluster1. Cela garantira qu’aucune machine autre que votre machine cliente ne puisse accéder au volume sur l’un ou l’autre des serveurs :

      Maintenant que votre volume est opérationnel, vous pouvez configurer votre machine cliente et commencer à l’utiliser à distance.

      Étape 5 — Installation et configuration des composants du client

      Votre volume est maintenant configuré et disponible pour être utilisé par votre machine cliente. Mais, avant de commencer, vous devez installer le paquet glusterfs-client à partir du PPA que vous avez mis en place à l’étape 1 sur votre machine cliente. Les dépendances de ce paquet comprennent certaines des bibliothèques et modules de traduction communs de GlusterFS, ainsi que les outils FUSE nécessaires à son fonctionnement.

      Exécutez la commande suivante sur gluster2 :

      • sudo apt install glusterfs-client

      Vous allez bientôt monter votre volume de stockage à distance sur votre ordinateur client. Cependant, avant de pouvoir le faire, vous devez créer un point de montage. Traditionnellement, cela se fait dans le répertoire /mnt, mais vous pouvez l’utiliser n’importe où.

      Pour plus de simplicité, créez un répertoire nommé /storage-pool sur votre machine cliente pour servir de point de montage. Ce nom de répertoire commence par une barre (/) oblique qui le place dans le répertoire racine, vous devrez donc le créer avec des privilèges sudo :

      Vous pouvez maintenant monter le volume distant. Cependant, consultez d’abord la syntaxe de la commande mount que vous utiliserez pour le faire :

      sudo mount -t glusterfs domain1.com:volume_name /path/to/mount/point
      

      mount est un utilitaire que l’on trouve dans plusieurs systèmes d’exploitation de type Unix. Il est utilisé pour monter des systèmes de fichiers — n’importe quoi depuis des périphériques de stockage externes, comme les cartes SD ou les clés USB, à du stockage connecté comme dans le cas de ce tutoriel — sur des répertoires du système de fichiers existant de la machine. La syntaxe de la commande mount que vous utiliserez comprend l’option -t, qui nécessite trois arguments : le type de système de fichiers à monter, le périphérique où le système de fichiers à monter peut être trouvé, et le répertoire sur le client où vous allez monter le volume.

      Notez que dans cet exemple, l’argument périphérique pointe vers un nom d’hôte suivi de deux points et ensuite le nom du volume. GlusterFS extrait les répertoires de stockage réels sur chaque hôte, ce qui signifie que cette commande ne cherche pas à monter le répertoire /gluster-storage, mais plutôt le volume volume1.

      Notez également que vous n’avez à spécifier qu’un seul membre du cluster de stockage. Cela peut être n’importe quel nœud, puisque le service GlusterFS les traite comme une seule machine.

      Exécutez la commande suivante sur votre machine cliente (gluster2) pour monter le volume sur le répertoire /storage-pool que vous avez créé :

      • sudo mount -t glusterfs gluster0.example.com:/volume1 /storage-pool

      Ensuite, exécutez la commande df. Cela affichera la quantité d’espace disque disponible pour les systèmes de fichiers auxquels l’utilisateur qui l’invoque a accès :

      Cette commande montrera que le volume GlusterFS est monté au bon endroit :

      Output

      Filesystem 1K-blocks Used Available Use% Mounted on . . . gluster0.example.com:/volume1 50633164 1938032 48695132 4% /storage-pool

      Vous pouvez maintenant passer au test pour vérifier que toutes les données que vous écrivez sur le volume de votre client sont répliquées sur les nœuds de votre serveur, comme prévu.

      Étape 6 — Tester les fonctionnalités de redondance

      Maintenant que vous avez mis en place votre client pour utiliser votre pool de stockage et votre volume, vous pouvez tester sa fonctionnalité.

      Sur votre machine cliente (gluster2), naviguez jusqu’au point de montage que vous avez défini à l’étape précédente :

      Ensuite, créez quelques fichiers de test. La commande suivante crée dix fichiers vides séparés dans votre pool de stockage :

      • sudo touch file_{0..9}.test

      Si vous examinez les répertoires de stockage que vous avez définis précédemment sur chaque hôte de stockage, vous découvrirez que tous ces fichiers sont présents sur chaque système.

      Sur gluster0 :

      Output

      file_0.test file_2.test file_4.test file_6.test file_8.test file_1.test file_3.test file_5.test file_7.test file_9.test

      De même, sur gluster1 :

      Output

      file_0.test file_2.test file_4.test file_6.test file_8.test file_1.test file_3.test file_5.test file_7.test file_9.test

      Comme ces sorties le montrent, les fichiers test que vous avez ajoutés au client ont également été écrits sur vos deux nœuds.

      S’il arrive jamais un moment où l’un des nœuds de votre cluster de stockage est hors service, il pourrait se désynchroniser avec le pool de stockage si des modifications sont apportées au système de fichiers. En effectuant une opération en lecture sur le point de montage du client après la remise en ligne du nœud, ce dernier sera avisé de récupérer les fichiers manquants :

      Maintenant que vous avez vérifié que votre volume de stockage est correctement monté et qu’il peut reproduire des données sur les deux machines du cluster, vous pouvez verrouiller l’accès au pool de stockage.

      Étape 7 — Restriction des fonctionnalités de redondance

      À ce stade, n’importe quel ordinateur peut se connecter à votre volume de stockage sans aucune restriction. Vous pouvez changer cela en réglant l’option auth.allow, qui définit les adresses IP de tous les clients qui devraient avoir accès au volume.

      Si vous utilisez la configuration /etc/hosts, les noms que vous avez définis pour chaque serveur ne seront pas acheminés correctement. Vous devez utiliser une adresse IP statique à la place. En revanche, si vous utilisez des enregistrements DNS, le nom de domaine que vous avez configuré fonctionnera ici.

      Sur l’un ou l’autre de vos nœuds de stockage (gluster0 ou gluster1), exécutez la commande suivante :

      • sudo gluster volume set volume1 auth.allow gluster2_ip_address

      Si la commande se termine avec succès, elle renverra cette sortie :

      Output

      volume set: success

      Si vous avez besoin de supprimer la restriction à n’importe quel moment, vous pouvez saisir :

      • sudo gluster volume set volume1 auth.allow *

      Cela permettra de se connecter à nouveau depuis n’importe quelle machine. C’est n’est pas sûr, mais peut être utile pour les problèmes de débogage.

      Si vous avez plusieurs clients, vous pouvez spécifier leurs adresses IP ou leurs noms de domaine en même temps (selon que vous utilisez /etc/hosts ou la résolution de noms d’hôtes DNS), séparés par des virgules :

      • sudo gluster volume set volume1 auth.allow gluster_client1_ip,gluster_client2_ip

      Votre pool de stockage est maintenant configuré, sécurisé, et prêt à être utilisé. Ensuite, vous allez apprendre quelques commandes qui vous aideront à obtenir des informations sur l’état de votre pool de stockage.

      Étape 8 — Obtenir des informations sur votre pool de stockage avec des commandes GlusterFS

      Lorsque vous commencez à changer certains des paramètres de votre stockage GlusterFS, vous pouvez être perdus concernant quelles options sont disponibles, quels volumes sont actifs, et quels nœuds sont associés à chaque volume.

      Plusieurs commandes différentes sont disponibles sur vos nœuds pour récupérer ces données et interagir avec votre pool de stockage.

      Si vous souhaitez des informations sur chacun de vos volumes, exécutez la commande gluster volume info :

      Output

      Volume Name: volume1 Type: Replicate Volume ID: a1e03075-a223-43ab-a0f6-612585940b0c Status: Started Snapshot Count: 0 Number of Bricks: 1 x 2 = 2 Transport-type: tcp Bricks: Brick1: gluster0.example.com:/gluster-storage Brick2: gluster1.example.com:/gluster-storage Options Reconfigured: auth.allow: gluster2_ip_address transport.address-family: inet storage.fips-mode-rchecksum: on nfs.disable: on performance.client-io-threads: off

      De même, pour obtenir des informations sur tous les pairs auxquels ce nœud est connecté, vous pouvez saisir :

      Number of Peers: 1
      
      Hostname: gluster0.example.com
      Uuid: cb00a2fc-2384-41ac-b2a8-e7a1793bb5a9
      State: Peer in Cluster (Connected)
      

      Si vous souhaitez des informations détaillées sur la performance de chaque nœud, vous pouvez établir le profile d’un volume en saisissant :

      • sudo gluster volume profile volume_name start

      Lorsque cette commande est terminée, vous pouvez obtenir les informations recueillies en saisissant :

      • sudo gluster volume profile volume_name info

      Output

      Brick: gluster0.example.com:/gluster-storage -------------------------------------------- Cumulative Stats: %-latency Avg-latency Min-Latency Max-Latency No. of calls Fop --------- ----------- ----------- ----------- ------------ ---- 0.00 0.00 us 0.00 us 0.00 us 30 FORGET 0.00 0.00 us 0.00 us 0.00 us 36 RELEASE 0.00 0.00 us 0.00 us 0.00 us 38 RELEASEDIR Duration: 5445 seconds Data Read: 0 bytes Data Written: 0 bytes Interval 0 Stats: %-latency Avg-latency Min-Latency Max-Latency No. of calls Fop --------- ----------- ----------- ----------- ------------ ---- 0.00 0.00 us 0.00 us 0.00 us 30 FORGET 0.00 0.00 us 0.00 us 0.00 us 36 RELEASE 0.00 0.00 us 0.00 us 0.00 us 38 RELEASEDIR Duration: 5445 seconds Data Read: 0 bytes Data Written: 0 bytes . . .

      Comme indiqué précédemment, pour obtenir la liste de tous les composants associés à GlusterFS fonctionnant sur chacun de vos nœuds, exécutez la commande gluster volume status :

      • sudo gluster volume status

      Output

      Status of volume: volume1 Gluster process TCP Port RDMA Port Online Pid ------------------------------------------------------------------------------ Brick gluster0.example.com:/gluster-storage 49152 0 Y 19003 Brick gluster1.example.com:/gluster-storage 49152 0 Y 19040 Self-heal Daemon on localhost N/A N/A Y 19061 Self-heal Daemon on gluster0.example.com N/A N/A Y 19836 Task Status of Volume volume1 ------------------------------------------------------------------------------ There are no active volume tasks

      Si vous comptez administrer vos volumes de stockage GlusterFS, il peut être judicieux de vous rendre dans la console GlusterFS. Cela vous permettra d’interagir avec votre environnement GlusterFS sans avoir besoin de saisir sudo gluster avant toute saisie :

      Cela vous donnera une invite où vous pouvez saisir vos commandes. help en est une bonne pour vous orienter :

      Output

      peer help - display help for peer commands volume help - display help for volume commands volume bitrot help - display help for volume bitrot commands volume quota help - display help for volume quota commands snapshot help - display help for snapshot commands global help - list global commands

      Lorsque vous avez terminé, exécutez exit pour quitter la console Gluster :

      Avec cela, vous êtes prêt à commencer à intégrer GlusterFS à votre prochaine application.

      Conclusion

      En suivant ce tutoriel, vous disposez d’un système de stockage redondant qui vous permettra d’écrire simultanément sur deux serveurs distincts. Cela peut être utile pour un certain nombre d’applications et peut garantir la disponibilité de vos données même en cas de panne d’un serveur.



      Source link