TOC

Comment utiliser un proxy pour les espaces DigitalOcean avec Nginx sur Ubuntu 16.04

introduction

DigitalOcean Spaces est un service object storage compatible avec l’API S3. Dans ce didacticiel, nous allons vous montrer comment utiliser Nginx pour adresser des requêtes à des objets sur votre espace. Nginx recevra les demandes HTTP (S) de vos utilisateurs et les transmettra au service Spaces, qui renverra les résultats via Nginx.

Certaines des raisons pour lesquelles vous pouvez placer un proxy Nginx devant Spaces sont les suivantes:

  • ajouter un domaine personnalisé

  • ajoutez votre propre cache

  • utilisez votre propre certificat SSL

  • utiliser différents mécanismes de contrôle d’accès

  • mettre en cache des ressources dans un centre de données plus proche de vos utilisateurs

Dans ce didacticiel, nous allons configurer Nginx pour répondre aux requêtes de notre propre domaine (avec les certificats optionnels Let Encrypt SSL) et les transférer à un espace doté de public assets. Nous ajouterons ensuite la mise en cache pour accélérer les réponses ultérieures des objets fréquemment consultés.

Conditions préalables

Pour compléter ce tutoriel, vous devriez avoir les éléments suivants:

  • Un serveur Ubuntu 16.04 sur lequel Nginx est installé, comme expliqué dans notre tutoriel Comment installer Nginx sur Ubuntu 16.04

  • Un nom de domaine pointant vers votre serveur, selon Comment définir un nom d’hôte avec DigitalOcean. Nous allons utiliser * assets.example.com * tout au long de ce tutoriel.

  • Un espace DigitalOcean. Vous pouvez apprendre à créer un nouvel espace en lisant An Introduction aux espaces DigitalOcean. + Vous devez connaître l’URL de votre espace individuel. Vous pouvez le trouver en accédant à votre espace dans le panneau de configuration de DigitalOcean. L’URL est directement sous le nom de l’espace dans l’interface utilisateur. Ceci est mis en évidence dans la capture d’écran ci-dessous: + image: https: //assets.digitalocean.com/articles/proxy-spaces/space-shot.png [Interface utilisateur de DigitalOcean Spaces avec l’URL de l’espace en surbrillance. L’URL se trouve directement sous le nom de l’espace dans l’en-tête de l’interface utilisateur] + Vous aurez également besoin d’un fichier téléchargé sur votre espace pour tester votre matériel. L’article susmentionné de Spaces explique comment vous pouvez télécharger des fichiers à l’aide de l’interface graphique Web Spaces. Nous allons utiliser + example.png + pour ce tutoriel.

Configuration du proxy

Une installation par défaut de Nginx sur Ubuntu renverra une page réservée * Welcome to Nginx * pour toutes les demandes. Nous devons ajouter une nouvelle configuration pour dire à Nginx de faire autre chose avec les demandes adressées à notre domaine.

Pour ce faire, ouvrez un nouveau fichier de configuration dans + / etc / nginx / sites-available +:

sudo nano /etc/nginx/sites-available/

Cela ouvrira un fichier vierge dans l’éditeur de texte + nano +. Collez la configuration suivante en veillant à remplacer les parties en surbrillance par votre propre nom de domaine et votre URL Spaces:

/etc/nginx/sites-available/assets.example.com

server {
   listen 80;
   listen [::]:80;
   server_name ;

   location / {
       proxy_pass ;
       proxy_hide_header      Strict-Transport-Security;
   }
}

Enregistrez le fichier et quittez l’éditeur lorsque vous avez terminé. Ceci est un bloc standard Nginx + server. Premièrement, nous lui demandons d’écouter le port + 80 + sur IPv4 et IPv6, puis nous spécifions le + nom_serveur + auquel Nginx doit répondre.

Ensuite, nous créons un bloc + location +. Toute directive de configuration dans ce bloc (entre les accolades + {+ et +} +) ne s’appliquera qu’à des URL spécifiques. Dans ce cas, nous spécifions + / +, l’URL racine, afin que tous les emplacements soient mis en correspondance par ce bloc.

La directive + proxy_pass + indique à Nginx de transmettre les demandes au serveur spécifié. La ligne + proxy_hide_header supprime l’en-tête` + Strict-Transport-Security` avant de renvoyer la réponse au client. Spaces utilise cet en-tête pour forcer toutes les connexions vers HTTPS. La transmission de cet en-tête à vos utilisateurs pourrait avoir des conséquences inattendues si votre site est accessible à la fois par les connexions HTTP et HTTPS.

Maintenant que notre configuration est définie, nous devons l’activer. Cela se fait en créant un lien vers le fichier de configuration dans le répertoire + / etc / nginx / sites-enabled / +:

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

Pour vérifier notre syntaxe de configuration, lancez + nginx -t + en tant que root:

sudo nginx -t
Outputnginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Enfin, rechargez Nginx pour récupérer la nouvelle configuration:

sudo systemctl reload nginx

Avec notre fichier de configuration configuré, testons le proxy.

Tester le proxy

Nous pouvons tester la connexion proxy en utilisant + curl + sur la ligne de commande. + curl -I + renverra uniquement les en-têtes HTTP d’une réponse. C’est suffisant pour déterminer que les choses fonctionnent bien.

Commencez par récupérer un objet directement dans votre espace à l’aide de l’URL * digitaloceanspaces.com *. Nous allons utiliser notre fichier + example.png +:

curl -I
OutputHTTP/1.1 200 OK
Content-Length: 81173
Accept-Ranges: bytes
Last-Modified: Tue, 28 Nov 2017 21:19:37 GMT
ETag: "7b2d05a5bd1bfeebcac62990daeafd14"
x-amz-request-id: tx000000000000000002398-005a1edfcd-afba2-nyc3a
Content-Type: image/png
Date: Wed, 29 Nov 2017 16:26:53 GMT
Strict-Transport-Security: max-age=15552000; includeSubDomains; preload

Le signe +200 OK + sur la première ligne de la sortie indique que la requête a abouti. Le serveur a renvoyé la taille du fichier (+ Content-Length +), le type de fichier (+ Content-Type +) et d’autres informations liées à la date et au cache.

Maintenant, récupérez le même fichier via le proxy:

curl -I
OutputHTTP/1.1 200 OK

Date: Wed, 29 Nov 2017 16:27:24 GMT
Content-Type: image/png
Content-Length: 81173
Connection: keep-alive
Accept-Ranges: bytes
Last-Modified: Tue, 28 Nov 2017 21:19:37 GMT
ETag: "7b2d05a5bd1bfeebcac62990daeafd14"
x-amz-request-id: tx00000000000000000a045-005a1edfec-a89a3-nyc3a

La réponse est essentiellement la même. Le changement majeur est un en-tête + Server + qui identifie Nginx. Si votre sortie est similaire, votre proxy fonctionne correctement!

Dans l’étape suivante, nous allons configurer la mise en cache afin de réduire l’utilisation de la bande passante entre le proxy et les espaces et d’accélérer les temps de réponse.

Mise en cache

Pour mettre en cache les réponses, Nginx a besoin d’un emplacement pour stocker les clés, les métadonnées et le contenu de la réponse. Nous allons créer un répertoire de cache dans le répertoire + / tmp + du système. Pour ce faire, nous allons ajouter un extrait de configuration à un nouveau fichier dans + / etc / nginx / conf.d / +. Ouvrez ce fichier maintenant:

sudo nano /etc/nginx/conf.d/example-cache.conf

Collez la ligne suivante, puis enregistrez et fermez le fichier:

/etc/nginx/conf.d/example-cache.conf

proxy_cache_path /tmp/example-cache/ levels=1:2 keys_zone=example-cache:16m max_size=10g inactive=60m use_temp_path=off;

Cette ligne définit quelques caractéristiques du cache. Passons en revue les options:

  • + / tmp / example-cache / + est le chemin d’accès au cache.

  • + levels = 1: 2 + définit une hiérarchie de répertoires à deux niveaux pour stocker le contenu mis en cache. Placer trop de fichiers dans un seul répertoire peut entraîner des problèmes de rapidité et de fiabilité. Nginx va donc scinder les fichiers entre plusieurs répertoires en fonction de cette option.

  • + keys_zone = example-cache: 16m + nomme notre cache et configure 16 mégaoctets de mémoire pour stocker les clés. Cela devrait être assez de mémoire pour stocker des données pour plus de 100 000 clés.

  • + max_size = 10g + limite la taille du cache à 10 gigaoctets. Vous pouvez ajuster cela en fonction de vos besoins de stockage et d’utilisation.

  • + inactive = 60m + signifie que Nginx supprimera les fichiers mis en cache après 60 minutes s’ils ne sont pas consultés à ce moment-là (même si le fichier est toujours valide et qu’il n’a pas expiré). Si vous avez beaucoup d’objets auxquels on accède rarement, essayez d’augmenter ce nombre.

  • + use_temp_path = off + indique à Nginx d’écrire des fichiers temporaires dans le répertoire cache, évitant ainsi potentiellement de copier des fichiers entre systèmes de fichiers, ce qui pourrait nuire aux performances.

Maintenant que nous avons défini un cache, nous devons l’activer dans notre bloc serveur et définir des options supplémentaires. Ouvrez à nouveau le fichier de configuration de votre site:

sudo nano /etc/nginx/sites-available/

Ajoutez ce qui suit à la fin de votre bloc + location / + (après la directive + proxy_hide_header +, mais avant le crochet `` +} + `fermé):

/etc/nginx/sites-available/assets.example.com

. . .
       proxy_cache            example-cache;
       proxy_cache_valid      200 60m;
       proxy_cache_use_stale  error timeout updating http_500 http_502 http_503 http_504;
       proxy_cache_revalidate on;
       proxy_cache_lock       on;

       proxy_ignore_headers   Set-Cookie;
       add_header             X-Cache-Status $upstream_cache_status;
. . .

Enregistrez et fermez le fichier. Passons en revue ces options de configuration une par une:

  • + proxy_cache + indique à Nginx le cache à utiliser. Dans ce cas, nous spécifions + example-cache +, que nous venons de configurer dans le fichier + example-cache.conf +.

  • + proxy_cache_valid + indique à Nginx de prendre en considération toute réponse + 200 + valide pendant 60 minutes. Cela signifie qu’après que le proxy aura récupéré un fichier dans Spaces, Nginx utilisera la copie en cache pendant les 60 prochaines minutes sans jamais demander une mise à jour à Spaces. Notez que si vos objets ont un en-tête + Cache-Control, la valeur des en-têtes remplacera cette configuration.

  • + proxy_cache_use_stale + permet à Nginx de renvoyer une réponse périmée (expirée) si le serveur Spaces arrive à expiration, une erreur ou si la réponse en cache est en cours de mise à jour.

  • + proxy_cache_revalidate + permet au proxy de revalider les fichiers mis en cache à l’aide de requêtes GET_ _conditional. Cela signifie que lorsqu’un fichier en cache expire et que Nginx doit rechercher des modifications dans Spaces, Nginx utilisera les en-têtes + If-Modified-Since + ou + + If-None-Match + pour ne récupérer l’objet que s’il a effectivement été modifié. . S’il n’a pas été mis à jour, Spaces renverra une réponse +304 Not Modified + et Nginx marquera simplement la réponse existante en cache comme étant à nouveau valide.

  • + proxy_cache_lock + met en attente les demandes ultérieures adressées à un objet lorsque le proxy le récupère déjà à partir du serveur principal. Lorsque la première demande est terminée, les autres demandes sont ensuite traitées à partir du cache.

  • + proxy_ignore_headers Set-Cookie + ignore les cookies, qui peuvent interférer avec la mise en cache.

  • + add_header X-Cache-Status …​ + ajoute un en-tête indiquant si la requête a été servie à partir du cache (+ HIT +) ou non (+ MISS +). Si la demande était dans le cache mais a expiré, vous verrez à la place (+ REVALIDATED +).

Nous sommes maintenant prêts à vérifier que notre configuration ne contient aucune erreur et, si cela réussit, rechargez Nginx:

sudo nginx -t
sudo systemctl reload nginx

Avec la mise en cache mise en place, nous pouvons tester à nouveau pour nous assurer que le cache fonctionne comme prévu.

Tester le cache

Pour être sûr que le cache fonctionne, nous pouvons utiliser à nouveau + curl + et rechercher l’en-tête + X-Cache-Status +:

curl -I
OutputHTTP/1.1 200 OK
Server: nginx/1.10.3 (Ubuntu)
Date: Wed, 29 Nov 2017 18:40:28 GMT
Content-Type: image/png
Content-Length: 81173
Connection: keep-alive
Last-Modified: Tue, 28 Nov 2017 21:19:37 GMT
ETag: "7b2d05a5bd1bfeebcac62990daeafd14"
x-amz-request-id: tx000000000000000013841-005a1eff1b-a89e4-nyc3a

Accept-Ranges: bytes

La première requête devrait être un "+ MISS +". Essayez une seconde fois:

curl -I
OutputHTTP/1.1 200 OK
Server: nginx/1.10.3 (Ubuntu)
Date: Wed, 29 Nov 2017 18:40:53 GMT
Content-Type: image/png
Content-Length: 81173
Connection: keep-alive
Last-Modified: Tue, 28 Nov 2017 21:19:37 GMT
ETag: "7b2d05a5bd1bfeebcac62990daeafd14"
x-amz-request-id: tx000000000000000013841-005a1eff1b-a89e4-nyc3a

Accept-Ranges: bytes

Un + HIT +! Nous effectuons maintenant le proxy et la mise en cache des objets à partir d’espaces. Dans l’étape suivante, nous allons configurer des certificats SSL pour sécuriser la communication avec notre proxy.

Configuration de TLS / SSL

Bien que cette étape soit facultative, il est vivement recommandé que votre site Web et vos actifs soient disponibles via une connexion HTTPS sécurisée. Vous pouvez apprendre à télécharger et installer des certificats gratuits à partir de l’autorité de certification Let’s Encrypt en lisant notre tutoriel https://www.digitalocean.com/community/tutorials/how-to-set-up-let-s-encrypt-with- nginx-server-blocks-on-ubuntu-16-04 [Comment configurer l’encryptage avec des blocs de serveurs Nginx sur Ubuntu 16.04].

Conclusion

Dans ce didacticiel, nous avons créé une configuration Nginx pour les demandes proxy d’objets pour le service Spaces. Nous avons ensuite ajouté la mise en cache pour améliorer les performances et un certificat TLS / SSL pour améliorer la confidentialité et la sécurité.

Les paramètres illustrés ici constituent un bon point de départ, mais vous souhaiterez peut-être optimiser certains paramètres du cache en fonction de vos propres modèles de trafic et de vos besoins. La documentation Nginx, en particulier le ngxhttpproxy_module peut fournir des informations plus détaillées sur les options de configuration disponibles. .

Related