One place for hosting & domains

      Applications

      Comment accéder à distance aux applications GUI en utilisant Docker et Caddy sur Ubuntu 18.04


      L’auteur a choisi le Free and Open Source Fund pour recevoir un don dans le cadre du programme Write for Donations.

      Introduction

      Même avec la popularité croissante des services cloud, le besoin d’exécuter des applications natives existe toujours.

      En utilisant noVNC et TigerVNC,vous pouvez exécuter des applications natives dans un conteneur Docker et y accéder à distance à l’aide d’un navigateur web. En outre, vous pouvez exécuter votre application sur un serveur disposant de plus de ressources système que celles dont vous disposez localement, ce qui peut offrir une plus grande flexibilité lors de l’exécution de grandes applications.

      Dans ce tutoriel, vous allez conteneuriser Mozilla Thunderbird, un client de messagerie électronique, en utilisant Docker. Ensuite, vous le sécuriserez et lui donnerez un accès à distance en utilisant le serveur web de Caddy.

      Lorsque vous aurez terminé, vous pourrez accéder à Thunderbird depuis n’importe quel appareil en utilisant simplement un navigateur web. En option, vous pourrez également accéder localement aux fichiers de ce site en utilisant WebDAV. Vous aurez également une image de Docker entièrement autonome que vous pourrez exécuter n’importe où.

      Conditions préalables

      Avant de commencer ce guide, vous aurez besoin de ce qui suit :

      Étape 1 &mdash ; Créer la Configuration de supervisord

      Maintenant que votre serveur fonctionne et que Docker est installé, vous êtes prêt à commencer à configurer le conteneur de votre application. Comme votre conteneur est constitué de plusieurs composants, vous devez utiliser un gestionnaire de processus pour les lancer et les surveiller. Ici, vous utiliserez supervisord. supervisord est un gestionnaire de processus écrit en Python qui est souvent utilisé pour orchestrer des conteneurs complexes. 

      Tout d’abord, créez et entrez un répertoire appelé thunderbird pour votre conteneur : 

      • mkdir ~/thunderbird
      • cd ~/thunderbird

      Maintenant, créez et ouvrez un fichier appelé supervisord.conf utilisant nano ou votre éditeur préféré :

      Ajoutez maintenant ce premier bloc de code dans supervisord.conf, qui définira les options globales de supervisord :

      ~/thunderbird/supervisord.conf

      [supervisord]
      nodaemon=true
      pidfile=/tmp/supervisord.pid
      logfile=/dev/fd/1
      logfile_maxbytes=0
      

      Dans ce bloc, vous configurez supervisord lui-même. Vous devez mettre nodaemon sur true parce qu’il sera placé à l’intérieur d’un conteneur Docker comme point d’entrée. Par conséquent, vous voulez qu’il reste au premier plan. Vous mettez également en place pidfile vers un chemin accessible par un non-root user (nous y reviendrons plus tard), et logfile vers stdout pour que vous puissiez voir les journaux. 

      Ensuite, ajoutez un autre petit bloc de code à supervisord.conf. Ce bloc démarre TigerVNC, qui est un serveur combiné VNC/X11 :

      ~/thunderbird/supervisord.conf

      ...
      [program:x11]
      priority=0
      command=/usr/bin/Xtigervnc -desktop "Thunderbird" -localhost -rfbport 5900 -SecurityTypes None -AlwaysShared -AcceptKeyEvents -AcceptPointerEvents -AcceptSetDesktopSize -SendCutText -AcceptCutText :0
      autorestart=true
      stdout_logfile=/dev/fd/1
      stdout_logfile_maxbytes=0
      redirect_stderr=true
      

      Dans ce bloc, vous configurez le serveur X11. X11 est un protocole de serveur d’affichage, qui permet aux applications graphiques de s’exécuter. Notez qu’à l’avenir il sera remplacé par Wayland, mais l’accès à distance est encore en développement.

      Pour ce conteneur, vous utilisez TigerVNC et son serveur VNC intégré. Cela présente un certain nombre d’avantages par rapport à l’utilisation d’un serveur X11 et VNC séparé :

      • Temps de réponse plus rapide, car le dessin de l’interface graphique est fait directement sur le serveur VNC plutôt que d’être fait sur un framebuffer intermédiaire (la mémoire qui stocke le contenu de l’écran).
      • Le redimensionnement automatique de l’écran, qui permet à l’application distante de se redimensionner automatiquement en fonction du client (dans ce cas, la fenêtre de votre navigateur web).

      Si vous le souhaitez, vous pouvez changer l’argument pour l’option -desktop de Thunderbird à quelque chose d’autre de votre choix. Le serveur affichera votre choix comme titre de la page web utilisée pour l’accès à votre application.

      Maintenant, ajoutons un troisième bloc de code à supervisord.conf pour démarrer easy-novnc : 

      ~/thunderbird/supervisord.conf

      ...
      [program:easy-novnc]
      priority=0
      command=/usr/local/bin/easy-novnc --addr :8080 --host localhost --port 5900 --no-url-password --novnc-params "resize=remote"
      autorestart=true
      stdout_logfile=/dev/fd/1
      stdout_logfile_maxbytes=0
      redirect_stderr=true
      

      Dans ce bloc, vous mettez en place easy-novncun serveur autonome qui fournit une wrapper autour de noVNC Ce serveur joue deux rôles. Tout d’abord, il fournit une page de connexion simple qui vous permet de configurer des options pour la connexion, et vous permet de définir des options par défaut. Deuxièmement, il permet à VNC de se substituer à WebSocket, qui permet d’y accéder au moyen d’un navigateur web ordinaire. 

      Habituellement, le redimensionnement se fait du côté client (c’est-à-dire la mise à l’échelle de l’image), mais vous utilisez l’option resize=remote pour profiter pleinement des ajustements de la résolution à distance de TigerVNC. Cela permet également de réduire la latence sur les appareils plus lents, tels que les Chromebooks bas de gamme :

      Note : Ce tutoriel utilise easy-novnc. Si vous le souhaitez, vous pouvez utiliser websockify et un serveur web séparé à la place. L’avantage d’easy-novnc est que l’utilisation de la mémoire et le temps de démarrage sont nettement plus faibles et que c’est autonome. easy-novnc fournit également une page de connexion plus propre que celle par défaut de noVNC et permet de définir des options par défaut qui sont utiles pour cette configuration (telles que resize=remote).

      Ajoutez maintenant le bloc suivant à votre configuration pour lancer OpenBox, le gestionnaire de fenêtres :

      ~/thunderbird/supervisord.conf

      ...
      [program:openbox]
      priority=1
      command=/usr/bin/openbox
      environment=DISPLAY=:0
      autorestart=true
      stdout_logfile=/dev/fd/1
      stdout_logfile_maxbytes=0
      redirect_stderr=true
      

      Dans ce bloc, vous mettez en place OpenBox, un gestionnaire léger de fenêtres X11. Vous pouvez sauter cette étape, mais sans elle, vous n’auriez pas de barres de titre ou ne pourriez pas redimensionner les fenêtres.

      Enfin, ajoutons le dernier bloc à supervisord.conf, qui lancera l’application principale : 

      ~/thunderbird/supervisord.conf

      ...
      [program:app]
      priority=1
      environment=DISPLAY=:0
      command=/usr/bin/thunderbird
      autorestart=true
      stdout_logfile=/dev/fd/1
      stdout_logfile_maxbytes=0
      redirect_stderr=true
      

      Dans ce dernier bloc, vous fixez la priorité à 1 pour s’assurer que Thunderbird se lance après TigerVNC, sinon il rencontrerait une condition de course et ne démarrerait pas au hasard. Nous avons également réglé autorestart=true pour rouvrir automatiquement l’application si elle se ferme par erreur. La variable d’environnement DISPLAY indique à l’application de s’afficher sur le serveur VNC que vous avez configuré précédemment.

      Voici ce à quoi votre supervisord.conf complété ressemblera : 

      ~/thunderbird/supervisord.conf

      [supervisord]
      nodaemon=true
      pidfile=/tmp/supervisord.pid
      logfile=/dev/fd/1
      logfile_maxbytes=0
      
      [program:x11]
      priority=0
      command=/usr/bin/Xtigervnc -desktop "Thunderbird" -localhost -rfbport 5900 -SecurityTypes None -AlwaysShared -AcceptKeyEvents -AcceptPointerEvents -AcceptSetDesktopSize -SendCutText -AcceptCutText :0
      autorestart=true
      stdout_logfile=/dev/fd/1
      stdout_logfile_maxbytes=0
      redirect_stderr=true
      
      [program:easy-novnc]
      priority=0
      command=/usr/local/bin/easy-novnc --addr :8080 --host localhost --port 5900 --no-url-password --novnc-params "resize=remote"
      autorestart=true
      stdout_logfile=/dev/fd/1
      stdout_logfile_maxbytes=0
      redirect_stderr=true
      
      [program:openbox]
      priority=1
      command=/usr/bin/openbox
      environment=DISPLAY=:0
      autorestart=true
      stdout_logfile=/dev/fd/1
      stdout_logfile_maxbytes=0
      redirect_stderr=true
      
      [program:app]
      priority=1
      environment=DISPLAY=:0
      command=/usr/bin/thunderbird
      autorestart=true
      stdout_logfile=/dev/fd/1
      stdout_logfile_maxbytes=0
      redirect_stderr=true
      

      Si vous voulez conteneuriser une autre demande, remplacez /usr/bin/thunderbird avec le chemin d’accès à l’exécutable de votre application. Sinon, vous êtes maintenant prêt à configurer le menu principal de votre interface graphique.

      Maintenant que votre gestionnaire de processus est configuré, mettons en place le menu de l’OpenBox. Ce menu nous permet de lancer des applications à l’intérieur du conteneur. Nous inclurons également un terminal et un moniteur de processus pour le débogage, si nécessaire.

      Dans le répertoire de votre candidature, utilisez nano ou votre éditeur de texte préféré pour créer et ouvrir un nouveau fichier appelé menu.xml: 

      • nano ~/thunderbird/menu.xml

      Ajoutez maintenant le code suivant à menu.xml:

      ~/thunderbird/menu.xml

      <?xml version="1.0" encoding="utf-8"?>
      <openbox_menu xmlns="http://openbox.org/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://openbox.org/ file:///usr/share/openbox/menu.xsd">
          <menu id="root-menu" label="Openbox 3">
              <item label="Thunderbird">
                  <action name="Execute">
                      <execute>/usr/bin/thunderbird</execute>
                  </action>
              </item>
              <item label="Terminal">
                  <action name="Execute">
                      <execute>/usr/bin/x-terminal-emulator</execute>
                  </action>
              </item>
              <item label="Htop">
                  <action name="Execute">
                      <execute>/usr/bin/x-terminal-emulator -e htop</execute>
                  </action>
              </item>
          </menu>
      </openbox_menu>
      

      Ce fichier XML contient les éléments de menu qui apparaîtront lorsque vous ferez un clic droit sur le bureau. Chaque élément est constitué d’une étiquette et d’une action.

      Si vous voulez conteneuriser une autre demande, remplacez /usr/bin/thunderbird avec le chemin d’accès à l’exécutable de votre application et modifiez le label de l’article. 

      Étape 3 &mdash ; Créer le Dockerfile

      Maintenant que l’OpenBox est configurée, vous allez créer le Dockerfile, qui relie tout.

      Créez un Dockerfile dans le répertoire de votre conteneur :

      • nano ~/thunderbird/Dockerfile

      Pour commencer, ajoutons un peu de code pour élaborer easy-novnc: 

      ~/thunderbird/Dockerfile

      FROM golang:1.14-buster AS easy-novnc-build
      WORKDIR /src
      RUN go mod init build && 
          go get github.com/geek1011/[email protected] && 
          go build -o /bin/easy-novnc github.com/geek1011/easy-novnc
      

      Dans un premier temps, vous construisez easy-novnc. Cela se fait dans une étape séparée pour des raisons de simplicité et de gain d’espace &mdash ; vous n’avez pas besoin de toute la chaîne d’outils Go dans votre image finale. Notez le @v1.1.0 dans la commande de construction. Cela garantit que le résultat est déterministe, ce qui est important car Docker met en cache le résultat de chaque étape. Si vous n’aviez pas spécifié de version explicite, Docker ferait référence à la dernière version d’easy-novnc au moment où l’image a été construite pour la première fois. En outre, vous voulez vous assurer que vous téléchargez une version spécifique de easy-novnc, au cas où des modifications de rupture seraient apportées à l’interface CLI. 

      Créons maintenant la deuxième étape, qui deviendra l’image finale. Ici, vous utiliserez Debian 10 (buster) comme image de base. Notez que, comme il s’exécute dans un conteneur, il fonctionnera quelle que soit la distribution que vous utilisez sur votre serveur.

      Ensuite, ajoutez le bloc suivant à votre Dockerfile: 

      ~/thunderbird/Dockerfile

      ...
      FROM debian:buster
      RUN apt-get update -y && 
          apt-get install -y --no-install-recommends openbox tigervnc-standalone-server supervisor gosu && 
          rm -rf /var/lib/apt/lists && 
          mkdir -p /usr/share/desktop-directories
      

      Dans cette instruction, vous installez Debian 10 comme image de base, puis vous installez le strict minimum requis pour exécuter des applications graphiques dans votre conteneur. Notez que vous exécutez apt-get update dans le cadre de la même instruction, pour éviter les problèmes de mise en cache de Docker. Pour gagner de la place, vous supprimez également les listes de paquets téléchargées par la suite (les paquets mis en cache sont eux-mêmes supprimé par défaut). Vous créez également /usr/share/desktop-directories car certaines applications dépendent du répertoire existant.

      Ajoutons un autre petit bloc de code :

      ~/thunderbird/Dockerfile

      ...
      RUN apt-get update -y && 
          apt-get install -y --no-install-recommends lxterminal nano wget openssh-client rsync ca-certificates xdg-utils htop tar xzip gzip bzip2 zip unzip && 
          rm -rf /var/lib/apt/lists
      

      Dans cette instruction, vous installez des utilitaires et des paquets utiles à usage général. Les points suivants présentent un intérêt particulier xdg-utils (qui fournit les commandes de base utilisées par les applications de bureau sous Linux) et ca-certificates (qui installe les certificats racine pour nous permettre d’accéder aux sites HTTPS). 

      Maintenant, nous pouvons ajouter les instructions pour la demande principale :

      ~/thunderbird/Dockerfile

      ...
      RUN apt-get update -y && 
          apt-get install -y --no-install-recommends thunderbird && 
          rm -rf /var/lib/apt/lists
      

      Comme auparavant, nous installons ici l’application. Si vous conteneurisez une autre application, vous pouvez remplacer ces commandes par celles nécessaires à l’installation de votre application spécifique. Certaines applications nécessiteront un peu plus de travail pour fonctionner dans Docker. Par exemple, si vous installez une application qui utilise Chrome, Chromium, ou QtWebEngine, vous devrez utiliser l’argument de la ligne de commande --no-sandbox parce qu’il ne sera pas soutenu au sein de Docker. 

      Ensuite, commençons à ajouter les instructions pour ajouter les derniers fichiers dans le conteneur :

      ~/thunderbird/Dockerfile

      ...
      COPY --from=easy-novnc-build /bin/easy-novnc /usr/local/bin/
      COPY menu.xml /etc/xdg/openbox/
      COPY supervisord.conf /etc/
      EXPOSE 8080
      

      Ici, vous ajoutez à l’image les fichiers de configuration que vous avez créés précédemment et vous copiez le binaire easy-novnc de la première étape.

      Le bloc de code suivant crée le répertoire de données et ajoute un utilisateur dédié à votre application. Ceci est important, car certaines applications refusent de s’exécuter en tant que root. Il est également bon de ne pas exécuter les applications en tant que root, même dans un conteneur.

      ~/thunderbird/Dockerfile

      ...
      RUN groupadd --gid 1000 app && 
          useradd --home-dir /data --shell /bin/bash --uid 1000 --gid 1000 app && 
          mkdir -p /data
      VOLUME /data
      

      Pour assurer la cohérence des UID/GID pour les fichiers, vous fixez explicitement les deux à 1000. Vous montez également un volume sur le répertoire de données pour vous assurer qu’il persiste entre les redémarrages.

      Enfin, ajoutons les instructions pour tout lancer :

      ~/thunderbird/Dockerfile

      ...
      CMD ["sh", "-c", "chown app:app /data /dev/stdout && exec gosu app supervisord"]
      

      En réglant la commande par défaut sur supervisord, le gestionnaire lancera les processus nécessaires à l’exécution de votre application. Dans ce cas, vous utilisez CMD plutôt qu’ENTRYPOINT. Dans la plupart des cas, cela ne ferait pas de différence, mais l’utilisation de CMD est plus adaptée à cette fin, pour plusieurs raisons. Premièrement, supervisord ne prend pas d’arguments qui seraient pertinents pour nous, et si vous fournissez des arguments au conteneur, ils remplacent CMD et sont annexés à ENTRYPOINT.  Deuxièmement, l’utilisation de CMD nous permet de fournir une commande entièrement différente (qui sera exécutée par /bin/sh -c) lors du passage des arguments au conteneur, ce qui rend le débogage plus facile.

      Et enfin, vous devez exécuterchown comme root avant de démarrer supervisord pour éviter les problèmes d’autorisation sur le volume de données et pour permettre aux processus enfant d’ouvrir stdout. Cela signifie également que vous devez utiliser gosu au lieu de l’instruction USER pour changer d’utilisateur. 

      Voici ce à quoi votre Dockerfile complété ressemblera :

      ~/thunderbird/Dockerfile

      FROM golang:1.14-buster AS easy-novnc-build
      WORKDIR /src
      RUN go mod init build && 
          go get github.com/geek1011/[email protected] && 
          go build -o /bin/easy-novnc github.com/geek1011/easy-novnc
      
      FROM debian:buster
      
      RUN apt-get update -y && 
          apt-get install -y --no-install-recommends openbox tigervnc-standalone-server supervisor gosu && 
          rm -rf /var/lib/apt/lists && 
          mkdir -p /usr/share/desktop-directories
      
      RUN apt-get update -y && 
          apt-get install -y --no-install-recommends lxterminal nano wget openssh-client rsync ca-certificates xdg-utils htop tar xzip gzip bzip2 zip unzip && 
          rm -rf /var/lib/apt/lists
      
      RUN apt-get update -y && 
          apt-get install -y --no-install-recommends thunderbird && 
          rm -rf /var/lib/apt/lists
      
      COPY --from=easy-novnc-build /bin/easy-novnc /usr/local/bin/
      COPY menu.xml /etc/xdg/openbox/
      COPY supervisord.conf /etc/
      EXPOSE 8080
      
      RUN groupadd --gid 1000 app && 
          useradd --home-dir /data --shell /bin/bash --uid 1000 --gid 1000 app && 
          mkdir -p /data
      VOLUME /data
      
      CMD ["sh", "-c", "chown app:app /data /dev/stdout && exec gosu app supervisord"]
      

      Sauvegardez et fermez votre Dockerfile. Nous sommes maintenant prêts à construire et à faire fonctionner notre conteneur, puis à accéder à Thunderbird &mdash, une application GUI.

      Étape 4 &mdash ; Création et utilisation du conteneur

      L’étape suivante consiste à construire votre conteneur et à le mettre en marche au démarrage. Vous mettrez également en place un volume pour préserver les données de l’application entre les redémarrages et les mises à jour.

      Construisez d’abord votre conteneur. Veillez à exécuter ces commandes dans le répertoire ~/thunderbird :

      • docker build -t thunderbird .

      Créez maintenant un nouveau réseau qui sera partagé entre les conteneurs de l’application :

      • docker network create thunderbird-net

      Créez ensuite un volume pour stocker les données de l’application :

      • docker volume create thunderbird-data

      Enfin, lancez-le et réglez-le pour qu’il redémarre automatiquement :

      • docker run --detach --restart=always --volume=thunderbird-data:/data --net=thunderbird-net --name=thunderbird-app thunderbird

      Notez que si vous le souhaitez, vous pouvez remplacer le thunderbird-app après l’option --name par un nom différent. Quel que soit votre choix, votre application est maintenant conteneurisée et en cours d’exécution. Utilisons maintenant le serveur web Caddy pour le sécuriser et nous y connecter à distance.

      Étape 5 &mdash ; Mise en place de Caddy

      Au cours de cette étape, vous configurerez le serveur web Caddy pour fournir une authentification et, éventuellement, un accès à distance aux fichiers via WebDAV. Par souci de simplicité, et pour vous permettre de l’utiliser avec votre proxy inverse existant, vous le ferez fonctionner dans un autre conteneur.

      Créez un nouveau répertoire et déplacez-vous à l’intérieur de celui-ci :

      Créez maintenant un nouveau Dockerfile en utilisant nano ou votre éditeur préféré :

      Ajoutez ensuite les directives suivantes :

      ~/caddy/Dockerfile

      FROM golang:1.14-buster AS caddy-build
      WORKDIR /src
      RUN echo 'module caddy' > go.mod && 
          echo 'require github.com/caddyserver/caddy/v2 v2.0.0' >> go.mod && 
          echo 'require github.com/mholt/caddy-webdav v0.0.0-20200523051447-bc5d19941ac3' >> go.mod
      RUN echo 'package main' > caddy.go && 
          echo 'import caddycmd "github.com/caddyserver/caddy/v2/cmd"' >> caddy.go && 
          echo 'import _ "github.com/caddyserver/caddy/v2/modules/standard"' >> caddy.go && 
          echo 'import _ "github.com/mholt/caddy-webdav"' >> caddy.go && 
          echo 'func main() { caddycmd.Main() }' >> caddy.go
      RUN go build -o /bin/caddy .
      
      FROM debian:buster
      
      RUN apt-get update -y && 
          apt-get install -y --no-install-recommends gosu && 
          rm -rf /var/lib/apt/lists
      
      COPY --from=caddy-build /bin/caddy /usr/local/bin/
      COPY Caddyfile /etc/
      EXPOSE 8080
      
      RUN groupadd --gid 1000 app && 
          useradd --home-dir /data --shell /bin/bash --uid 1000 --gid 1000 app && 
          mkdir -p /data
      VOLUME /data
      
      WORKDIR /data
      CMD ["sh", "-c", "chown app:app /data && exec gosu app /usr/local/bin/caddy run -adapter caddyfile -config /etc/Caddyfile"]
      

      Ce Dockerfile construit Caddy avec le plugin WebDAV activé, puis le lance sur le port 8080 avec le Caddyfile dans /etc/Caddyfile. Enregistrez et fermez le fichier.

      Ensuite, vous allez configurer le serveur web de Caddy. Créez un fichier nommé Caddyfile dans le répertoire que vous venez de créer :

      Ajoutez maintenant le bloc de code suivant à votre Caddyfile :

      ~/caddy/Caddyfile

      {
          order webdav last
      }
      :8080 {
          log
          root * /data
          reverse_proxy thunderbird-app:8080
      
          handle /files/* {
              uri strip_prefix /files
              file_server browse
          }
          redir /files /files/
      
          handle /webdav/* {
              uri strip_prefix /webdav
              webdav
          }
          redir /webdav /webdav/
      
          basicauth /* {
              {env.APP_USERNAME} {env.APP_PASSWORD_HASH}
          }
      }
      

      Ce Caddyfile est un proxy du répertoire root vers le conteneur thunderbird-app que vous avez créé à l’étape 4 (le Docker le résout en l’IP correcte). Il servira également de navigateur de fichiers en lecture seule sur /files et fera fonctionner un serveur WebDAV sur /webdav que vous pourrez monter localement pour accéder à vos fichiers. Le nom d’utilisateur et le mot de passe sont lus à partir des variables d’environnement APP_USERNAME et APP_PASSWORD_HASH. 

      Maintenant, construisez le conteneur :

      • docker build -t thunderbird-caddy .

      Caddy v.2 vous demande de hacher le mot de passe que vous souhaitez. Exécutez la commande suivante et n’oubliez pas de remplacer mypass avec un mot de passe fort de votre choix : 

      • docker run --rm -it thunderbird-caddy caddy hash-password -plaintext 'mypass'

      Cette commande produira une chaîne de caractères. Copiez ceci dans votre presse-papiers en préparation de l’exécution de la prochaine commande.

      Vous êtes maintenant prêt à faire fonctionner le conteneur. Veillez à remplacer myuser avec un nom d’utilisateur de votre choix, et remplacez mypass-hash par la sortie de la commande que vous avez exécutée à l’étape précédente. Vous pouvez également changer le port (8080 ici) pour accéder à votre serveur sur un port différent : 

      • docker run --detach --restart=always --volume=thunderbird-data:/data --net=thunderbird-net --name=thunderbird-web --env=APP_USERNAME="myuser" --env=APP_PASSWORD_HASH="mypass-hash" --publish=8080:8080 thunderbird-caddy

      Nous sommes maintenant prêts à accéder et à tester notre application.

      Étape 6 &mdash ; Tester et gérer l’application

      Accédez à votre application et assurez-vous qu’elle fonctionne.

      Ouvrez d’abord http://votre_serveur_ip:8080 dans un navigateur web, connectez-vous avec les identifiants que vous avez choisis auparavant, et cliquez sur Connect. 

      Page de connexion NoVNC 

      Vous devriez maintenant être en mesure d’interagir avec l’application, et celle-ci devrait automatiquement se redimensionner pour s’adapter à la fenêtre de votre navigateur.

      Menu principal de Thunderbird

      Si vous faites un clic droit sur le bureau noir, vous devriez voir un menu qui vous permet d’accéder à un terminal. Si vous cliquez avec le bouton du milieu de la souris, vous devriez voir une liste de fenêtres.

      Clic droit sur NoVNC

      Ouvrez maintenant http://votre_serveur_ip:8080/files/ dans un navigateur web. Vous devriez pouvoir accéder à vos fichiers.

      Accès au fichier NoVNC webdav

      En option, vous pouvez essayer de monter http://your_server_ip:8080/webdav/ dans un client WebDAV. Vous devez pouvoir accéder à vos fichiers et les modifier directement. Si vous utilisez l’option de carte lecteur réseau dans l’explorateur Windows, vous devrez soit utiliser un mandataire inverse pour ajouter le HTTPS, ou définir HKLMSYSTEMCurrentControlSetServicesClientWebParametersBasicAuthLevel à DWORD:2. 

      Dans les deux cas, votre application GUI native est maintenant prête à être utilisée à distance.

      Conclusion

      Vous avez maintenant configuré avec succès un conteneur Docker pour Thunderbird et ensuite, à l’aide de Caddy, vous avez configuré l’accès à ce conteneur via un navigateur web. Si jamais vous devez mettre à jour votre application, arrêtez les conteneurs, exécutez docker rm thunderbird-app thunderbird-web, reconstruisez les images, puis relancez les commandes d’exécution du docker à partir des étapes précédentes ci-dessus. Vos données seront toujours préservées puisqu’elles sont stockées dans un volume.

      Si vous voulez en savoir plus sur les commandes de base du Docker, vous pouvez lire ceci tutoriel ou cette fiche d’aide. Pour une utilisation à plus long terme, vous pouvez également envisager d’activer le HTTPS (qui nécessite un domaine) pour une sécurité supplémentaire.

      En outre, si vous déployez plus d’une application, vous pouvez utiliser Docker Compose ou Kubernetes au lieu de démarrer chaque conteneur manuellement. Et n’oubliez pas que ce tutoriel peut servir de base pour exécuter toute autre application Linux sur votre serveur, y compris :

      • Wine, une couche de compatibilité pour l’exécution d’applications Windows sous Linux.
      • GIMP, un éditeur d’images open-source.
      • Cutter, une plateforme de rétro-ingénierie open-source.

      Cette dernière option démontre le grand potentiel de la conteneurisation et de l’accès à distance aux applications GUI. Grâce à cette configuration, vous pouvez désormais utiliser un serveur doté d’une puissance de calcul considérablement plus importante que celle dont vous disposez localement pour faire fonctionner des outils gourmands en ressources comme Cutter.



      Source link

      Comment accéder à distance aux applications GUI en utilisant Docker et Caddy sur Ubuntu 20.04


      L’auteur a choisi le Free and Open Source Fund pour recevoir un don dans le cadre du programme Write for Donations.

      Introduction

      Même avec la popularité croissante des services en nuage, le besoin d’exécuter des applications natives existe toujours.

      En utilisant noVNC et TigerVNC,vous pouvez exécuter des applications natives dans un conteneur Docker et y accéder à distance à l’aide d’un navigateur web. En outre, vous pouvez exécuter votre application sur un serveur disposant de plus de ressources système que celles dont vous disposez localement, ce qui peut offrir une plus grande flexibilité lors de l’exécution de grandes applications.

      Dans ce tutoriel, vous allez conteneuriser Mozilla Thunderbird, un client de messagerie électronique, en utilisant Docker. Ensuite, vous le sécuriserez et lui donnerez un accès à distance en utilisant le serveur web de Caddy.

      Lorsque vous aurez terminé, vous pourrez accéder à Thunderbird depuis n’importe quel appareil en utilisant simplement un navigateur web. En option, vous pourrez également accéder localement aux fichiers de ce site en utilisant WebDAV. Vous aurez également une image de Docker entièrement autonome que vous pourrez exécuter n’importe où.

      Conditions préalables

      Avant de commencer ce guide, vous aurez besoin de ce qui suit :

      Étape 1 &mdash ; Créer la “Configuration de supervisord

      Maintenant que votre serveur fonctionne et que Docker est installé, vous êtes prêt à commencer à configurer le conteneur de votre application. Comme votre conteneur est constitué de plusieurs composants, vous devez utiliser un gestionnaire de processus pour les lancer et les surveiller. Ici, vous utiliserez supervisord. supervisord est un gestionnaire de processus écrit en Python qui est souvent utilisé pour orchestrer des conteneurs complexes.

      Tout d’abord, créez et entrez un répertoire appelé thunderbird pour votre conteneur :

      • mkdir ~/thunderbird
      • cd ~/thunderbird

      Maintenant, créez et ouvrez un fichier appelé supervisord.conf utilisant nano ou votre éditeur préféré :

      • nano ~/thunderbird/supervisord.conf

      Ajoutez maintenant ce premier bloc de code dans supervisord.conf, qui définira les options globales de supervisord :

      ~/thunderbird/supervisord.conf

      [supervisord]
      nodaemon=true
      pidfile=/tmp/supervisord.pid
      logfile=/dev/fd/1
      logfile_maxbytes=0
      

      Dans ce bloc, vous configurez supervisord lui-même. Vous devez mettre nodaemon à l'heure parce qu’il sera placé à l’intérieur d’un conteneur Docker comme point d’entrée. Par conséquent, vous voulez qu’il reste au premier plan. Vous mettez également en place pidfile vers un chemin accessible par un non-root user (nous y reviendrons plus tard), et logfile vers stdout pour que vous puissiez voir les journaux.

      Ensuite, ajoutez un autre petit bloc de code à supervisord.conf. Ce bloc démarre TigerVNC, qui est un serveur combiné VNC/X11 :

      ~/thunderbird/supervisord.conf

      ...
      [program:x11]
      priority=0
      command=/usr/bin/Xtigervnc -desktop "Thunderbird" -localhost -rfbport 5900 -SecurityTypes None -AlwaysShared -AcceptKeyEvents -AcceptPointerEvents -AcceptSetDesktopSize -SendCutText -AcceptCutText :0
      autorestart=true
      stdout_logfile=/dev/fd/1
      stdout_logfile_maxbytes=0
      redirect_stderr=true
      

      Dans ce bloc, vous configurez le serveur X11. X11 est un protocole de serveur d’affichage, qui permet aux applications graphiques de s’exécuter. Notez qu’à l’avenir il sera remplacé par Wayland, mais l’accès à distance est encore en développement.

      Pour ce conteneur, vous utilisez TigerVNC et son serveur VNC intégré. Cela présente un certain nombre d’avantages par rapport à l’utilisation d’un serveur X11 et VNC séparé :

      • Temps de réponse plus rapide, car le dessin de l’interface graphique est fait directement sur le serveur VNC plutôt que d’être fait sur un framebuffer intermédiaire (la mémoire qui stocke le contenu de l’écran).
      • Le redimensionnement automatique de l’écran, qui permet à l’application distante de se redimensionner automatiquement en fonction du client (dans ce cas, la fenêtre de votre navigateur web).

      Si vous le souhaitez, vous pouvez changer l’argument pour l’option -desktop de Thunderbird à quelque chose d’autre de votre choix. Le serveur affichera votre choix comme titre de la page web utilisée pour accéder à votre demande.

      Maintenant, ajoutons un troisième bloc de code à supervisord.conf pour démarrer easy-novnc :

      ~/thunderbird/supervisord.conf

      ...
      [program:easy-novnc]
      priority=0
      command=/usr/local/bin/easy-novnc --addr :8080 --host localhost --port 5900 --no-url-password --novnc-params "resize=remote"
      autorestart=true
      stdout_logfile=/dev/fd/1
      stdout_logfile_maxbytes=0
      redirect_stderr=true
      

      Dans ce bloc, vous mettez en place easy-novncun serveur autonome qui permet de faire le tour de noVNC. Ce serveur joue deux rôles. Tout d’abord, il fournit une page de connexion simple, qui vous permet de configurer des options pour la connexion et de définir des options par défaut. Deuxièmement, il utilise un proxy VNC sur WebSocket, qui permet d’y accéder au moyen d’un navigateur web ordinaire.

      Habituellement, le redimensionnement se fait du côté client (c’est-à-dire la mise à l’échelle de l’image), mais vous utilisez l’option resize=remote pour profiter pleinement des ajustements de la résolution à distance de TigerVNC. Cela permet également de réduire la latence sur les appareils plus lents, tels que les Chromebooks bas de gamme :

      Note : Ce tutoriel utilise easy-novnc. Si vous le souhaitez, vous pouvez utiliser websockify et un serveur web séparé à la place. L’avantage d’easy-novnc est que l’utilisation de la mémoire et le temps de démarrage sont nettement plus faibles et que c’est autonome. easy-novnc fournit également une page de connexion plus propre que celle par défaut de noVNC et permet de définir des options par défaut qui sont utiles pour cette configuration (telles que resize=remote).

      Ajoutez maintenant le bloc suivant à votre configuration pour lancer OpenBox, le gestionnaire de fenêtres :

      ~/thunderbird/supervisord.conf

      ...
      [program:openbox]
      priority=1
      command=/usr/bin/openbox
      environment=DISPLAY=:0
      autorestart=true
      stdout_logfile=/dev/fd/1
      stdout_logfile_maxbytes=0
      redirect_stderr=true
      

      Dans ce bloc, vous mettez en place OpenBox, un gestionnaire léger de fenêtres X11. Vous pouvez sauter cette étape, mais sans elle, vous n’auriez pas de barres de titre ou ne pourriez pas redimensionner les fenêtres.

      Enfin, ajoutons le dernier bloc à supervisord.conf, qui lancera l’application principale :

      ~/thunderbird/supervisord.conf

      ...
      [program:app]
      priority=1
      environment=DISPLAY=:0
      command=/usr/bin/thunderbird
      autorestart=true
      stdout_logfile=/dev/fd/1
      stdout_logfile_maxbytes=0
      redirect_stderr=true
      

      Dans ce dernier bloc, vous fixez la priority à 1 pour s’assurer que Thunderbird se lance après TigerVNC, sinon il rencontrerait une condition de course et ne démarrerait pas au hasard. Nous avons également réglé autorestart=true pour rouvrir automatiquement l’application si elle se ferme par erreur. La variable d’environnement DISPLAY indique à l’application de s’afficher sur le serveur VNC que vous avez configuré précédemment.

      Voici ce à quoi votre supervisord.conf complété ressemblera :

      ~/thunderbird/supervisord.conf

      [supervisord]
      nodaemon=true
      pidfile=/tmp/supervisord.pid
      logfile=/dev/fd/1
      logfile_maxbytes=0
      
      [program:x11]
      priority=0
      command=/usr/bin/Xtigervnc -desktop "Thunderbird" -localhost -rfbport 5900 -SecurityTypes None -AlwaysShared -AcceptKeyEvents -AcceptPointerEvents -AcceptSetDesktopSize -SendCutText -AcceptCutText :0
      autorestart=true
      stdout_logfile=/dev/fd/1
      stdout_logfile_maxbytes=0
      redirect_stderr=true
      
      [program:easy-novnc]
      priority=0
      command=/usr/local/bin/easy-novnc --addr :8080 --host localhost --port 5900 --no-url-password --novnc-params "resize=remote"
      autorestart=true
      stdout_logfile=/dev/fd/1
      stdout_logfile_maxbytes=0
      redirect_stderr=true
      
      [program:openbox]
      priority=1
      command=/usr/bin/openbox
      environment=DISPLAY=:0
      autorestart=true
      stdout_logfile=/dev/fd/1
      stdout_logfile_maxbytes=0
      redirect_stderr=true
      
      [program:app]
      priority=1
      environment=DISPLAY=:0
      command=/usr/bin/thunderbird
      autorestart=true
      stdout_logfile=/dev/fd/1
      stdout_logfile_maxbytes=0
      redirect_stderr=true
      

      Si vous voulez conteneuriser une autre demande, remplacez /usr/bin/thunderbird avec le chemin d’accès à l’exécutable de votre application. Sinon, vous êtes maintenant prêt à configurer le menu principal de votre interface graphique.

      Maintenant que votre gestionnaire de processus est configuré, mettons en place le menu de l’OpenBox. Ce menu nous permet de lancer des applications à l’intérieur du conteneur. Nous inclurons également un terminal et un moniteur de processus pour le débogage si nécessaire.

      Dans le répertoire de votre candidature, utilisez nano ou votre éditeur de texte préféré pour créer et ouvrir un nouveau fichier appelé menu.xml:

      • nano ~/thunderbird/menu.xml

      Ajoutez maintenant le code suivant à menu.xml:

      ~/thunderbird/menu.xml

      <?xml version="1.0" encoding="utf-8"?>
      <openbox_menu xmlns="http://openbox.org/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://openbox.org/ file:///usr/share/openbox/menu.xsd">
          <menu id="root-menu" label="Openbox 3">
              <item label="Thunderbird">
                  <action name="Execute">
                      <execute>/usr/bin/thunderbird</execute>
                  </action>
              </item>
              <item label="Terminal">
                  <action name="Execute">
                      <execute>/usr/bin/x-terminal-emulator</execute>
                  </action>
              </item>
              <item label="Htop">
                  <action name="Execute">
                      <execute>/usr/bin/x-terminal-emulator -e htop</execute>
                  </action>
              </item>
          </menu>
      </openbox_menu>
      

      Ce fichier XML contient les éléments de menu qui apparaîtront lorsque vous ferez un clic droit sur le bureau. Chaque élément est constitué d’une étiquette et d’une action.

      Si vous voulez conteneuriser une autre application, remplacez /usr/bin/thunderbird par le chemin d’accès à l’exécutable de votre application et modifiez le label de l’article.

      Étape 3 &mdash ; Créer le Dockerfile

      Maintenant que l’OpenBox est configurée, vous allez créer le Dockerfile, qui relie tout.

      Créez un Dockerfile dans le répertoire de votre conteneur :

      • nano ~/thunderbird/Dockerfile

      Pour commencer, ajoutons un peu de code pour élaborer easy-novnc:

      ~/thunderbird/Dockerfile

      FROM golang:1.14-buster AS easy-novnc-build
      WORKDIR /src
      RUN go mod init build && 
          go get github.com/geek1011/[email protected] && 
          go build -o /bin/easy-novnc github.com/geek1011/easy-novnc
      

      Dans un premier temps, vous construisez easy-novnc. Cela se fait dans une étape séparée pour des raisons de simplicité et de gain d’espace &mdash ; vous n’avez pas besoin de toute la chaîne d’outils Go dans votre image finale. Notez le @v1.1.0 dans la commande de construction. Cela garantit que le résultat est déterministe, ce qui est important car Docker met en cache le résultat de chaque étape. Si vous n’aviez pas spécifié de version explicite, Docker ferait référence à la dernière version d’easy-novnc au moment où l’image a été construite pour la première fois. En outre, vous voulez vous assurer que vous téléchargez une version spécifique de easy-novnc, au cas où des modifications de rupture seraient apportées à l’interface CLI.

      Créons maintenant le deuxième niveau, qui deviendra l’image finale. Ici, vous utiliserez Debian 10 (buster) comme image de base. Notez que, comme il s’exécute dans un conteneur, il fonctionnera quelle que soit la distribution que vous utilisez sur votre serveur.

      Ensuite, ajoutez le bloc suivant à votre Dockerfile:

      ~/thunderbird/Dockerfile

      ...
      FROM debian:buster
      RUN apt-get update -y && 
          apt-get install -y --no-install-recommends openbox tigervnc-standalone-server supervisor gosu && 
          rm -rf /var/lib/apt/lists && 
          mkdir -p /usr/share/desktop-directories
      

      Dans cette instruction, vous installez Debian 10 comme image de base, puis vous installez le strict minimum requis pour exécuter des applications graphiques dans votre conteneur. Notez que vous exécutez apt-get update dans le cadre de la même instruction pour éviter les problèmes de mise en cache de Docker. Pour gagner de la place, vous supprimez également les listes de paquets téléchargées par la suite (les paquets mis en cache sont eux-mêmes supprimé par défaut). Vous créez également /usr/share/desktop-directories car certaines applications dépendent du répertoire existant.

      Ajoutons un autre petit bloc de code :

      ~/thunderbird/Dockerfile

      ...
      RUN apt-get update -y && 
          apt-get install -y --no-install-recommends lxterminal nano wget openssh-client rsync ca-certificates xdg-utils htop tar xzip gzip bzip2 zip unzip && 
          rm -rf /var/lib/apt/lists
      

      Dans cette instruction, vous installez des utilitaires et des paquets utiles à usage général. Les points suivants présentent un intérêt particulier xdg-utils (qui fournit les commandes de base utilisées par les applications de bureau sous Linux) et ca-certificates (qui installe les certificats racine pour nous permettre d’accéder aux sites HTTPS).

      Maintenant, nous pouvons ajouter les instructions pour la demande principale :

      ~/thunderbird/Dockerfile

      ...
      RUN apt-get update -y && 
          apt-get install -y --no-install-recommends thunderbird && 
          rm -rf /var/lib/apt/lists
      

      Comme auparavant, nous installons ici l’application. Si vous conteneurisez une autre application, vous pouvez remplacer ces commandes par celles nécessaires à l’installation de votre app spécifique. Certaines applications nécessiteront un peu plus de travail pour fonctionner dans Docker. Par exemple, si vous installez une application qui utilise Chrome, Chromium, ou QtWebEngine, vous devrez utiliser l’argument de la ligne de commande --no-sandbox parce qu’il ne sera pas soutenu au sein de Docker.

      Ensuite, commençons à ajouter les instructions pour ajouter les derniers fichiers dans le conteneur :

      ~/thunderbird/Dockerfile

      ...
      COPY --from=easy-novnc-build /bin/easy-novnc /usr/local/bin/
      COPY menu.xml /etc/xdg/openbox/
      COPY supervisord.conf /etc/
      EXPOSE 8080
      

      Ici, vous ajoutez à l’image les fichiers de configuration que vous avez créés précédemment et vous copiez le binaire easy-novnc de la première étape.

      Le bloc de code suivant crée le répertoire de données et ajoute un utilisateur dédié à votre application. Ceci est important car certaines applications refusent de s’exécuter en tant que root. Il est également bon de ne pas exécuter les applications en tant que root, même dans un conteneur.

      ~/thunderbird/Dockerfile

      ...
      RUN groupadd --gid 1000 app && 
          useradd --home-dir /data --shell /bin/bash --uid 1000 --gid 1000 app && 
          mkdir -p /data
      VOLUME /data
      

      Pour assurer la cohérence des UID/GID pour les fichiers, vous fixez explicitement les deux à 1000. Vous montez également un volume sur le répertoire de données pour vous assurer qu’il persiste entre les redémarrages.

      Enfin, ajoutons les instructions pour tout lancer :

      ~/thunderbird/Dockerfile

      ...
      CMD ["sh", "-c", "chown app:app /data /dev/stdout && exec gosu app supervisord"]
      

      En réglant la commande par défaut sur supervisord, le gestionnaire lancera les processus nécessaires à l’exécution de votre demande. Dans ce cas, vous utilisez CMD plutôt qu’ENTRYPOINT. Dans la plupart des cas, cela ne ferait pas de différence, mais l’utilisation de CMD est mieux adapté à cette fin pour quelques raisons. Premièrement, supervisord ne prend pas d’arguments qui seraient pertinents pour nous, et si vous fournissez des arguments au conteneur, ils remplacent CMD et sont annexés à ENTRYPOINT. Deuxièmement, l’utilisation de CMD nous permet de fournir une commande entièrement différente (qui sera exécutée par /bin/sh -c) lors du passage des arguments au conteneur, ce qui rend le débogage plus facile.

      Et enfin, vous devez exécuterchown comme root avant de démarrer supervisord pour éviter les problèmes d’autorisation sur le volume de données et pour permettre aux processus enfant d’ouvrir stdout. Cela signifie également que vous devez utiliser gosu au lieu de l’instruction USER pour changer d’utilisateur.

      Voici ce à quoi votre Dockerfile complété ressemblera :

      ~/thunderbird/Dockerfile

      FROM golang:1.14-buster AS easy-novnc-build
      WORKDIR /src
      RUN go mod init build && 
          go get github.com/geek1011/[email protected] && 
          go build -o /bin/easy-novnc github.com/geek1011/easy-novnc
      
      FROM debian:buster
      
      RUN apt-get update -y && 
          apt-get install -y --no-install-recommends openbox tigervnc-standalone-server supervisor gosu && 
          rm -rf /var/lib/apt/lists && 
          mkdir -p /usr/share/desktop-directories
      
      RUN apt-get update -y && 
          apt-get install -y --no-install-recommends lxterminal nano wget openssh-client rsync ca-certificates xdg-utils htop tar xzip gzip bzip2 zip unzip && 
          rm -rf /var/lib/apt/lists
      
      RUN apt-get update -y && 
          apt-get install -y --no-install-recommends thunderbird && 
          rm -rf /var/lib/apt/lists
      
      COPY --from=easy-novnc-build /bin/easy-novnc /usr/local/bin/
      COPY menu.xml /etc/xdg/openbox/
      COPY supervisord.conf /etc/
      EXPOSE 8080
      
      RUN groupadd --gid 1000 app && 
          useradd --home-dir /data --shell /bin/bash --uid 1000 --gid 1000 app && 
          mkdir -p /data
      VOLUME /data
      
      CMD ["sh", "-c", "chown app:app /data /dev/stdout && exec gosu app supervisord"]
      

      Sauvegardez et fermez votre Dockerfile. Nous sommes maintenant prêts à construire et à faire fonctionner notre conteneur, puis à accéder à Thunderbird &mdash, une application GUI.

      Étape 4 &mdash ; Construire et faire marcher le conteneur

      L’étape suivante consiste à construire votre conteneur et à le mettre en marche au démarrage. Vous mettrez également en place un volume pour préserver les données de l’application entre les redémarrages et les mises à jour.

      Construisez d’abord votre conteneur. Veillez à exécuter ces commandes dans le répertoire ~/thunderbird :

      • docker build -t thunderbird .

      Créez maintenant un nouveau réseau qui sera partagé entre les conteneurs de l’application :

      • docker network create thunderbird-net

      Créez ensuite un volume pour stocker les données de l’application :

      • docker volume create thunderbird-data

      Enfin, lancez-le et réglez-le pour qu’il redémarre automatiquement :

      • docker run --detach --restart=always --volume=thunderbird-data:/data --net=thunderbird-net --name=thunderbird-app thunderbird

      Notez que si vous le souhaitez, vous pouvez remplacer le thunderbird-app après l’option --name avec un nom différent. Quel que soit votre choix, votre demande est maintenant conteneurisée et en cours d’exécution. Utilisons maintenant le serveur web Caddy pour le sécuriser et nous y connecter à distance.

      Étape 5 &mdash ; Mettre en place Caddy

      Au cours de cette étape, vous configurerez le serveur web Caddy pour fournir une authentification et, éventuellement, un accès à distance aux fichiers via WebDAV. Par souci de simplicité, et pour vous permettre de l’utiliser avec votre proxy inverse existant, vous le ferez fonctionner dans un autre conteneur.

      Créez un nouveau répertoire et déplacez-vous à l’intérieur de celui-ci :

      Créez maintenant un nouveau Dockerfile en utilisant nano ou votre éditeur préféré :

      Ajoutez ensuite les directives suivantes :

      ~/caddy/Dockerfile

      FROM golang:1.14-buster AS caddy-build
      WORKDIR /src
      RUN echo 'module caddy' > go.mod && 
          echo 'require github.com/caddyserver/caddy/v2 v2.0.0' >> go.mod && 
          echo 'require github.com/mholt/caddy-webdav v0.0.0-20200523051447-bc5d19941ac3' >> go.mod
      RUN echo 'package main' > caddy.go && 
          echo 'import caddycmd "github.com/caddyserver/caddy/v2/cmd"' >> caddy.go && 
          echo 'import _ "github.com/caddyserver/caddy/v2/modules/standard"' >> caddy.go && 
          echo 'import _ "github.com/mholt/caddy-webdav"' >> caddy.go && 
          echo 'func main() { caddycmd.Main() }' >> caddy.go
      RUN go build -o /bin/caddy .
      
      FROM debian:buster
      
      RUN apt-get update -y && 
          apt-get install -y --no-install-recommends gosu && 
          rm -rf /var/lib/apt/lists
      
      COPY --from=caddy-build /bin/caddy /usr/local/bin/
      COPY Caddyfile /etc/
      EXPOSE 8080
      
      RUN groupadd --gid 1000 app && 
          useradd --home-dir /data --shell /bin/bash --uid 1000 --gid 1000 app && 
          mkdir -p /data
      VOLUME /data
      
      WORKDIR /data
      CMD ["sh", "-c", "chown app:app /data && exec gosu app /usr/local/bin/caddy run -adapter caddyfile -config /etc/Caddyfile"]
      

      Ce Dockerfile construit Caddy avec le plugin WebDAV activé, puis le lance sur le port 8080 avec le Caddyfile à /etc/Caddyfile. Enregistrez et fermez le fichier.

      Ensuite, vous allez configurer le serveur web de Caddy. Créer un fichier nommé Caddyfile dans le répertoire que vous venez de créer :

      Ajoutez maintenant le bloc de code suivant à votre Caddyfile :

      ~/caddy/Caddyfile

      {
          order webdav last
      }
      :8080 {
          log
          root * /data
          reverse_proxy thunderbird-app:8080
      
          handle /files/* {
              uri strip_prefix /files
              file_server browse
          }
          redir /files /files/
      
          handle /webdav/* {
              uri strip_prefix /webdav
              webdav
          }
          redir /webdav /webdav/
      
          basicauth /* {
              {env.APP_USERNAME} {env.APP_PASSWORD_HASH}
          }
      }
      

      Ce Caddyfile est un proxy du répertoire root vers le conteneur thunderbird-app que vous avez créé à l’étape 4 (le Docker le résout dans l’IP correcte). Il servira également de navigateur de fichiers en lecture seule sur /files et fera fonctionner un serveur WebDAV sur /webdav que vous pourrez monter localement pour accéder à vos fichiers. Le nom d’utilisateur et le mot de passe sont lus à partir des variables d’environnement APP_USERNAME et APP_PASSWORD_HASH.

      Maintenant, construisez le conteneur :

      • docker build -t thunderbird-caddy .

      Caddy v.2 vous demande de hacher le mot de passe que vous souhaitez. Exécutez la commande suivante et n’oubliez pas de remplacer mypass avec un mot de passe fort de votre choix :

      • docker run --rm -it thunderbird-caddy caddy hash-password -plaintext 'mypass'

      Cette commande produira une chaîne de caractères. Copiez ceci dans votre presse-papiers en préparation de l’exécution de la prochaine commande.

      Vous êtes maintenant prêt à faire fonctionner le conteneur. Veillez à remplacer myuser par le nom d’utilisateur de votre choix, et remplacez <^>mypass-hash par la sortie de la commande que vous avez exécutée à l’étape précédente. Vous pouvez également changer le port (8080<^> ici) pour accéder à votre serveur sur un port différent :

      • docker run --detach --restart=always --volume=thunderbird-data:/data --net=thunderbird-net --name=thunderbird-web --env=APP_USERNAME="myuser" --env=APP_PASSWORD_HASH="mypass-hash" --publish=8080:8080 thunderbird-caddy

      Nous sommes maintenant prêts à accéder et à tester notre application.

      Étape 6 &mdash ; Tester et gérer l’application

      Accédez à votre application et assurez-vous qu’elle fonctionne.

      ouvrez d’abordhttp://votre_serveur_ip:8080 dans un navigateur web, connectez-vous avec les identifiants que vous avez choisis auparavant, et cliquez sur Connect.

      Page de connexion NoVNC

      Vous devriez maintenant être en mesure d’interagir avec l’application, et celle-ci devrait automatiquement se redimensionner pour s’adapter à la fenêtre de votre navigateur.

      Menu principal de Thunderbird

      Si vous faites un clic droit sur le bureau noir, vous devriez voir un menu qui vous permet d’accéder à un terminal. Si vous cliquez sur le milieu, vous devriez voir une liste de fenêtres.

      Clic droit sur NoVNC

      Ouvrez maintenant http://votre_serveur_ip:8080/files/ dans un navigateur web. Vous devriez pouvoir accéder à vos dossiers.

      Accès au fichier NoVNC webdav

      En option, vous pouvez essayer de monter http://votre_serveur_ip:8080/webdav/ dans un client WebDAV. Vous devriez pouvoir accéder et modifier vos fichiers directement. Si vous utilisez l’option de carte lecteur réseau dans l’explorateur Windows, vous devrez soit utiliser un proxy inverse pour ajouter le HTTPS, soit définir HKLMSYSTEMCurrentControlSetServicesClientWebParametersBasicAuthLevel à DWORD:2.

      Dans les deux cas, votre application GUI native est maintenant prête à être utilisée à distance.

      Conclusion

      Vous avez maintenant configuré avec succès un conteneur Docker pour Thunderbird et ensuite, à l’aide de Caddy, vous avez configuré l’accès à ce conteneur via un navigateur web. Si jamais vous devez mettre à jour votre application, arrêtez les conteneurs, exécutez docker rm thunderbird-app thunderbird-web, reconstruisez les images, puis relancez les commandes d’exécution du docker à partir des étapes précédentes ci-dessus. Vos données seront toujours préservées puisqu’elles sont stockées dans un volume.

      Si vous voulez en savoir plus sur les commandes de base du Docker, vous pouvez lire ce tutoriel ou cette fiche d’aide. Pour une utilisation à plus long terme, vous pouvez également envisager d’activer le HTTPS (qui nécessite un domaine) pour une sécurité supplémentaire.

      En outre, si vous déployez plusieurs applications, vous pouvez utiliser Docker Compose ou Kubernetes au lieu de démarrer chaque conteneur manuellement. Et n’oubliez pas que ce tutoriel peut servir de base pour exécuter toute autre application Linux sur votre serveur, y compris :

      • Wine, une couche de compatibilité pour l’exécution d’applications Windows sous Linux.
      • GIMP, un éditeur d’images open-source.
      • Cutter, une plateforme de rétro-ingénierie open-source.

      Cette dernière option démontre le grand potentiel de la conteneurisation et de l’accès à distance aux applications GUI. Grâce à cette configuration, vous pouvez désormais utiliser un serveur doté d’une puissance de calcul considérablement plus importante que celle dont vous disposez localement pour faire fonctionner des outils gourmands en ressources comme Cutter.



      Source link

      Comment servir des applications Flask avec Gunicorn et Nginx sur Ubuntu 20.04


      Introduction

      Dans ce guide, vous allez construire une application Python en utilisant le micro-framework Flask sur Ubuntu 20.04. L’essentiel de cet article portera sur la configuration du serveur d’application Gunicorn et sur la manière de lancer l’application et de configurer Nginx pour qu’il agisse comme un proxy inversé en amont.

      Conditions préalables

      Avant de démarrer ce guide, vous devriez avoir :

      • Un serveur avec Ubuntu 20.04 installé et un utilisateur non root avec des privilèges sudo. Suivez notre guide de configuration initiale du serveur pour vous aider.
      • Nginx installé, en suivant les étapes 1 et 2 de Comment installer Nginx sur Ubuntu 20.04.
      • Un nom de domaine configuré pour pointer vers votre serveur. Vous pouvez en acheter un sur Namecheap ou en obtenir un gratuitement sur Freenom.  Vous pouvez apprendre comment pointer des domaines vers DigitalOcean en suivant la documentation pertinente sur les domaines et le DNS. Veillez à créer les enregistrements DNS suivants :

        • Un enregistrement A avec your_domain pointant sur l’adresse IP publique de votre serveur.
        • Un enregistrement A avec www.your_domain​​​​​​ pointant à l’adresse IP publique de votre serveur.
      • Être familiarisé avec la spécification WSGI, que le serveur Gunicorn utilisera pour communiquer avec votre application Flask. Cette discussion couvre le WSGI plus en détail.

      Étape 1 — Installation des composants depuis les référentiels Ubuntu

      Notre première étape consistera à installer tous les éléments dont nous avons besoin depuis les référentiels Ubuntu. Cela inclut pip, le gestionnaire de paquets Python, qui gérera nos composants Python. Nous obtiendrons également les fichiers de développement Python nécessaires pour construire certains des composants de Gunicorn.

      Tout d’abord, nous allons mettre à jour l’index local des paquets et installer les paquets qui nous permettront de construire notre environnement Python. Ceux-ci comprendront python3-pip, ainsi que quelques autres paquets et outils de développement nécessaires pour un environnement de programmation robuste :

      • sudo apt update
      • sudo apt install python3-pip python3-dev build-essential libssl-dev libffi-dev python3-setuptools

      Une fois ces paquets en place, passons à la création d’un environnement virtuel pour notre projet.

      Étape 2 — Création d’un environnement virtuel Python

      Ensuite, nous allons configurer un environnement virtuel pour isoler notre application Flask des autres fichiers Python du système.

      Commencez par installer le paquet python3-venv, qui installera le module venv :

      • sudo apt install python3-venv

      Ensuite, créons un répertoire parent pour notre projet Flask. Déplacez-vous dans le répertoire après l’avoir créé :

      • mkdir ~/myproject
      • cd ~/myproject

      Créez un environnement virtuel pour stocker les exigences Python de votre projet Flask en tapant :

      • python3 -m venv myprojectenv

      Cela installera une copie locale de Python et pip dans un répertoire appelé myprojectenv dans le répertoire de votre projet.

      Avant d’installer des applications dans l’environnement virtuel, vous devez l’activer. Faites-le en tapant :

      • source myprojectenv/bin/activate

      Votre invite changera pour indiquer que vous travaillez maintenant dans l’environnement virtuel. Cela ressemblera à ce qui suit (myprojectenv)user@host:~/myproject$.

      Étape 3 — Configuration d’une application Flask

      Maintenant que vous êtes dans votre environnement virtuel, vous pouvez installer Flask et Gunicorn et commencer à concevoir votre application.

      Tout d’abord, installons wheel avec l’instance locale de pip pour nous assurer que nos paquets s’installeront même s’il leur manque des archives de wheel :

      Note


      Quelle que soit la version de Python que vous utilisez, lorsque l’environnement virtuel est activé, vous devez utiliser la commande pip (et non pip3).

      Ensuite, installons Flask et Gunicorn :

      • pip install gunicorn flask

      Création d’un exemple d’application

      Maintenant que vous disposez de Flask, vous pouvez créer une application simple. Flask est un microframework. Il n’inclut pas de nombreux outils que des frameworks plus complets pourraient inclure, et existe principalement sous la forme d’un module que vous pouvez importer dans vos projets pour vous aider à initialiser une application web.

      Bien que votre application puisse être plus complexe, nous allons créer notre app Flask dans un seul fichier, appelé myproject.py :

      • nano ~/myproject/myproject.py

      Le code de l’application se trouvera dans ce fichier. Il importera Flask et instanciera un objet Flask. Vous pouvez l’utiliser pour définir les fonctions qui doivent être exécutées lorsqu’un itinéraire spécifique est demandé :

      ~/myproject/myproject.py

      from flask import Flask
      app = Flask(__name__)
      
      @app.route("/")
      def hello():
          return "<h1 style="color:blue">Hello There!</h1>"
      
      if __name__ == "__main__":
          app.run(host="0.0.0.0")
      

      Cela définit essentiellement le contenu à présenter lors de l’accès au domaine racine. Enregistrez et fermez le fichier lorsque vous avez terminé.

      Si vous avez suivi le guide de configuration initiale du serveur, vous devriez disposer d’un pare-feu UFW activé. Pour tester l’application, vous devez autoriser l’accès au port 5000 :

      Vous pouvez maintenant tester votre application Flask en tapant :

      Vous obtiendrez un résultat comme suit, avec un avertissement utile vous rappelant de ne pas utiliser cette configuration de serveur en production :

      Output

      * Serving Flask app "myproject" (lazy loading) * Environment: production WARNING: Do not use the development server in a production environment. Use a production WSGI server instead. * Debug mode: off * Running on http://0.0.0.0:5000/ (Press CTRL+C to quit)

      Visitez l’adresse IP de votre serveur, suivie de:5000 dans votre navigateur web :

      http://your_server_ip:5000
      

      Vous devriez voir quelque chose comme ceci :

      Exemple d'application Flask

      Lorsque vous avez terminé, appuyez sur CTRL-C dans la fenêtre de votre terminal pour arrêter le serveur de développement Flask.

      Création du point d’entrée WSGI

      Ensuite, créons un fichier qui servira de point d’entrée pour notre application. Cela indiquera à notre serveur Gunicorn comment interagir avec l’application.

      Appelons le fichier wsgi.py :

      Dans ce fichier, importons l’instance Flask de notre application et exécutons-la :

      ~/myproject/wsgi.py

      from myproject import app
      
      if __name__ == "__main__":
          app.run()
      

      Enregistrez et fermez le fichier lorsque vous avez terminé.

      Étape 4 — Configuration de Gunicorn

      Votre application est maintenant écrite avec un point d’entrée établi. Nous pouvons maintenant passer à la configuration de Gunicorn.

      Avant de continuer, nous devrions vérifier que Gunicorn peut servir correctement l’application.

      Nous pouvons le faire en lui passant simplement le nom de notre point d’entrée. Celui-ci est construit comme le nom du module (moins l’extension .py), plus le nom de l’appelable dans l’application. Dans notre cas, il s’agit de wsgi:app.

      Nous spécifierons également l’interface et le port à utiliser pour que l’application soit lancée sur une interface accessible au public :

      • cd ~/myproject
      • gunicorn --bind 0.0.0.0:5000 wsgi:app

      Vous devriez voir une sortie similaire à la suivante :

      Output

      [2020-05-20 14:13:00 +0000] [46419] [INFO] Starting gunicorn 20.0.4 [2020-05-20 14:13:00 +0000] [46419] [INFO] Listening at: http://0.0.0.0:5000 (46419) [2020-05-20 14:13:00 +0000] [46419] [INFO] Using worker: sync [2020-05-20 14:13:00 +0000] [46421] [INFO] Booting worker with pid: 46421

      Visitez à nouveau dans votre navigateur web l’adresse IP de votre serveur avec :5000 ajouté à la fin :

      http://your_server_ip:5000
      

      Vous devriez voir la sortie de votre application :

      Exemple d'application Flask

      Lorsque vous avez la confirmation qu’il fonctionne correctement, appuyez sur CTRL-C dans la fenêtre de votre terminal.

      Nous en avons maintenant fini avec notre environnement virtuel, nous pouvons donc le désactiver :

      Toutes les commandes Python utiliseront à nouveau l’environnement Python du système.

      Ensuite, créons le fichier d’unité de service systemd. La création d’un fichier d’unité systemd permettra au système d’init d’Ubuntu de lancer automatiquement Gunicorn et de servir l’application Flask à chaque démarrage du serveur.

      Créez un fichier d’unité se terminant par .service dans le répertoire /etc/system/system pour commencer

      • sudo nano /etc/systemd/system/myproject.service

      Dans celui-ci, nous commencerons par la section [Unit], qui est utilisée pour spécifier les métadonnées et les dépendances. Ajoutons ici une description de notre service et disons au système d’initialisation de ne le lancer qu’une fois que l’objectif de mise en réseau a été atteint :

      /etc/systemd/system/myproject.service

      [Unit]
      Description=Gunicorn instance to serve myproject
      After=network.target
      

      Ensuite, ouvrons la section [Service]. Celle-ci indiquera l’utilisateur et le groupe sous lequel nous voulons que le processus s’exécute. Donnons à notre compte utilisateur habituel la propriété du processus puisqu’il possède tous les fichiers pertinents. Donnons également la propriété du groupe au groupe www-data afin que Nginx puisse facilement communiquer avec les processus Gunicorn.  N’oubliez pas de remplacer le nom d’utilisateur ici par votre nom d’utilisateur :

      /etc/systemd/system/myproject.service

      [Unit]
      Description=Gunicorn instance to serve myproject
      After=network.target
      
      [Service]
      User=sammy
      Group=www-data
      

      Ensuite, définissons le répertoire de travail et la variable d’environnement PATH afin que le système d’initialisation sache que les exécutables du processus sont situés dans notre environnement virtuel. Précisons également la commande de démarrage du service. Cette commande fera ce qui suit :

      • Démarrez 3 processus de travail (mais vous devez ajuster cela si nécessaire)
      • Créez et reliez à un fichier socket Unix, myproject.sock, dans notre répertoire de projet. Nous fixerons une valeur d’umask de 007 pour que le fichier socket soit créé en donnant l’accès au propriétaire et au groupe, tout en limitant tout autre accès
      • Précisez le nom du fichier du point d’entrée du WSGI, ainsi que le nom de l’appel Python dans ce fichier (wsgi:app)

      Systemd exige que nous donnons le chemin complet à l’exécutable Gunicorn, qui est installé dans notre environnement virtuel.

      N’oubliez pas de remplacer le nom d’utilisateur et les chemins du projet par vos propres informations :

      /etc/systemd/system/myproject.service

      [Unit]
      Description=Gunicorn instance to serve myproject
      After=network.target
      
      [Service]
      User=sammy
      Group=www-data
      WorkingDirectory=/home/sammy/myproject
      Environment="PATH=/home/sammy/myproject/myprojectenv/bin"
      ExecStart=/home/sammy/myproject/myprojectenv/bin/gunicorn --workers 3 --bind unix:myproject.sock -m 007 wsgi:app
      

      Enfin, ajoutons une section [Install]. Cela indiquera à systemd à quoi lier ce service si nous autorisons son démarrage au boot. Nous voulons que ce service démarre lorsque le système multi-utilisateurs normal est opérationnel :

      /etc/systemd/system/myproject.service

      [Unit]
      Description=Gunicorn instance to serve myproject
      After=network.target
      
      [Service]
      User=sammy
      Group=www-data
      WorkingDirectory=/home/sammy/myproject
      Environment="PATH=/home/sammy/myproject/myprojectenv/bin"
      ExecStart=/home/sammy/myproject/myprojectenv/bin/gunicorn --workers 3 --bind unix:myproject.sock -m 007 wsgi:app
      
      [Install]
      WantedBy=multi-user.target
      

      Avec cela, notre fichier de service systemd est terminé. Enregistrez-le et fermez-le maintenant.

      Nous pouvons maintenant démarrer le service Gunicorn que nous avons créé et l’activer afin qu’il démarre au boot :

      • sudo systemctl start myproject
      • sudo systemctl enable myproject

      Vérifions l’état :

      • sudo systemctl status myproject

      Vous devriez voir une sortie comme celle-ci :

      Output

      ● myproject.service - Gunicorn instance to serve myproject Loaded: loaded (/etc/systemd/system/myproject.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2020-05-20 14:15:18 UTC; 1s ago Main PID: 46430 (gunicorn) Tasks: 4 (limit: 2344) Memory: 51.3M CGroup: /system.slice/myproject.service ├─46430 /home/sammy/myproject/myprojectenv/bin/python3 /home/sammy/myproject/myprojectenv/bin/gunicorn --workers 3 --bind unix:myproject.sock -m 007 wsgi:app ├─46449 /home/sammy/myproject/myprojectenv/bin/python3 /home/sammy/myproject/myprojectenv/bin/gunicorn --workers 3 --bind unix:myproject.sock -m 007 wsgi:app ├─46450 /home/sammy/myproject/myprojectenv/bin/python3 /home/sammy/myproject/myprojectenv/bin/gunicorn --workers 3 --bind unix:myproject.sock -m 007 wsgi:app └─46451 /home/sammy/myproject/myprojectenv/bin/python3 /home/sammy/myproject/myprojectenv/bin/gunicorn --workers 3 --bind unix:myproject.sock -m 007 wsgi:app

      Si vous constatez des erreurs, veillez à les résoudre avant de poursuivre le tutoriel.

      Étape 5 — Configuration de Nginx pour les demandes de proxy

      Notre serveur d’application Gunicorn devrait maintenant être opérationnel, en attendant les requêtes sur le fichier socket dans le répertoire du projet. Configurons maintenant Nginx pour qu’il transmette les requêtes web à cette socket en effectuant quelques petits ajouts à son fichier de configuration.

      Commencez par créer un nouveau fichier de configuration du bloc serveur dans le répertoire sites-available de Nginx. Appelons cela myproject pour rester en phase avec le reste du guide :

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

      Ouvrez un bloc serveur et indiquez à Nginx d’écouter sur le port 80 par défaut. Demandons également à Nginx d’utiliser ce bloc pour les demandes de nom de domaine de notre serveur :

      /etc/nginx/sites-available/myproject

      server {
          listen 80;
          server_name your_domain www.your_domain;
      }
      

      Ensuite, ajoutons un bloc de localisation qui corresponde à chaque requête. Dans ce bloc, nous allons inclure le fichier proxy_params qui spécifie certains paramètres généraux de proxy devant être définis. Nous transmettrons ensuite les demandes à la socket que nous avons définie à l’aide de la directive proxy_pass :

      /etc/nginx/sites-available/myproject

      server {
          listen 80;
          server_name your_domain www.your_domain;
      
          location / {
              include proxy_params;
              proxy_pass http://unix:/home/sammy/myproject/myproject.sock;
          }
      }
      

      Enregistrez et fermez le fichier lorsque vous avez terminé.

      Pour activer la configuration du bloc serveur Nginx que vous venez de créer, reliez le fichier au répertoire sites-enabled :

      • sudo ln -s /etc/nginx/sites-available/myproject /etc/nginx/sites-enabled

      Avec le fichier dans ce répertoire, vous pouvez tester les erreurs de syntaxe :

      Si cela ne révèle aucun problème, relancez le processus Nginx pour lire la nouvelle configuration :

      • sudo systemctl restart nginx

      Enfin, ajustons à nouveau le pare-feu. Nous n’avons plus besoin d’un accès via le port 5000, nous pouvons donc supprimer cette règle. Nous pouvons alors autoriser l’accès complet au serveur Nginx :

      • sudo ufw delete allow 5000
      • sudo ufw allow 'Nginx Full'

      Vous devriez maintenant être en mesure de naviguer sur le nom de domaine de votre serveur dans votre navigateur web :

      http://your_domain
      

      Vous devriez voir la sortie de votre application :

      Exemple d'application Flask

      Si vous rencontrez des erreurs, essayez de vérifier les points suivants :

      • sudo less /var/log/nginx/error.log : vérifie les journaux d’erreurs de Nginx.
      • sudo less /var/log/nginx/access.log : vérifie les journaux d’accès Nginx.
      • sudo journalctl -u nginx : vérifie les journaux des processus Nginx.
      • sudo journalctl -u myproject : vérifie les journaux Gunicorn de votre application Flask.

      Étape 6 — Sécurisation de l’application

      Pour garantir que le trafic vers votre serveur reste sécurisé, obtenons un certificat SSL pour votre domaine. Il existe plusieurs façons de le faire, notamment en obtenant un certificat gratuit auprès de Let’s Encrypt, en générant un certificat auto-signé ou en en achetant un auprès d’un autre fournisseur et en configurant Nginx pour l’utiliser en suivant les étapes 2 à 6 de Comment créer un certificat SSL auto-signé pour Nginx dans Ubuntu 20.04. Nous allons choisir l’option 1 pour des raisons de commodité.

      Installez le paquet Nginx de Certbot avec apt :

      • sudo apt install python3-certbot-nginx

      Certbot propose différents moyens d’obtenir des certificats SSL par le biais de plugins. Le plugin Nginx se chargera de reconfigurer Nginx et de recharger la configuration chaque fois que nécessaire. Pour utiliser ce plugin, tapez ce qui suit :

      • sudo certbot --nginx -d your_domain -d www.your_domain

      Cela exécute certbot avec le plugin --nginx, en utilisant -d pour spécifier les noms pour lesquels nous aimerions que le certificat soit valide.

      Si vous utilisez certbot pour la première fois, vous serez invité à saisir une adresse électronique et à accepter les conditions régissant le service. Après avoir fait cela, certbot communiquera avec le serveur Let’s Encrypt, puis exécutera un défi pour vérifier que vous contrôlez le domaine pour lequel vous demandez un certificat.

      Si cela réussit, certbot demandera comment vous souhaitez configurer vos paramètres HTTPS :

      Output

      Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access. ------------------------------------------------------------------------------- 1: No redirect - Make no further changes to the webserver configuration. 2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for new sites, or if you're confident your site works on HTTPS. You can undo this change by editing your web server's configuration. ------------------------------------------------------------------------------- Select the appropriate number [1-2] then [enter] (press 'c' to cancel):

      Sélectionnez votre choix ensuite appuyez sur ENTER. La configuration sera mise à jour, et Nginx se rechargera pour récupérer les nouveaux paramètres. certbot terminera par un message vous indiquant que le processus a réussi et où sont stockés vos certificats :

      Output

      IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/your_domain/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/your_domain/privkey.pem Your cert will expire on 2020-08-18. To obtain a new or tweaked version of this certificate in the future, simply run certbot again with the "certonly" option. To non-interactively renew *all* of your certificates, run "certbot renew" - Your account credentials have been saved in your Certbot configuration directory at /etc/letsencrypt. You should make a secure backup of this folder now. This configuration directory will also contain certificates and private keys obtained by Certbot so making regular backups of this folder is ideal. - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le

      Si vous avez suivi les instructions d’installation Nginx dans les conditions préalables, vous n’aurez plus besoin de l’autorisation de profil HTTP redondant :

      • sudo ufw delete allow 'Nginx HTTP'

      Pour vérifier la configuration, naviguez à nouveau sur votre domaine, en utilisant https:// :

      https://your_domain
      

      Vous devriez voir à nouveau la sortie de votre application, ainsi que l’indicateur de sécurité de votre navigateur, qui devrait indiquer que le site est sécurisé.

      Conclusion

      Dans ce guide, vous avez créé et sécurisé une application Flask simple dans un environnement virtuel Python. Vous avez créé un point d’entrée WSGI afin que tout serveur d’application compatible WSGI puisse s’interfacer avec lui, puis vous avez configuré le serveur d’application Gunicorn pour qu’il assure cette fonction. Ensuite, vous avez créé un fichier de service systemd pour lancer automatiquement le serveur de l’application au démarrage. Vous avez également créé un bloc serveur Nginx qui transmet le trafic du client web au serveur d’applications, relayant les requêtes externes, et qui sécurise le trafic vers votre serveur avec Let’s Encrypt.

      Flask est un framework très simple, mais extrêmement flexible, destiné à fournir à vos applications des fonctionnalités sans être trop restrictif sur la structure et la conception. Vous pouvez utiliser la pile générale décrite dans ce guide pour servir les applications flask que vous concevez.



      Source link