L'une des charges de travail les plus courantes de Docker l'utilise pour conteneuriser des serveurs Web comme NGINX et Apache pour exécuter un flotte de diffusion de contenu haute performance qui peut être facilement dimensionnée et gérée automatiquement. Nous vous montrerons comment le configurer avec NGINX.
Configurer NGINX Inside Docker
Docker est une plate-forme de conteneurisation, utilisée pour empaqueter votre application et tout son code dans une image de conteneur facilement gérable. Le processus est assez similaire à la façon dont vous configurez un nouveau serveur, le conteneur est une ardoise vierge, vous devrez donc installer des dépendances, créer votre code, copier sur le créer des artefacts et copier n'importe quelle configuration. Heureusement, vous n'avez pas besoin d'automatiser autant. NGINX dispose déjà d'un conteneur Docker accessible au public, que vous pouvez utiliser comme point de départ pour votre application.
Bien sûr, selon l'application que vous conteneurisez, cela peut être un peu plus compliqué. Si vous déployez un CMS comme WordPress, vous aurez probablement besoin d'une base de données externe, car les conteneurs ne sont pas conçus pour être persistants. Un bon point de départ pour WordPress, en particulier, serait le conteneur Docker de WordPress.
Afin d'avoir quelque chose d'un peu plus impliqué qu'une simple page Web Hello World, nous allons créer un nouveau répertoire de projet et initialiser une application Vue.js de base. Votre configuration sera différente selon le contenu que vous diffusez, mais l'idée générale est la même.
À la racine de votre projet, créez un nouveau fichier simplement nommé Dockerfile sans extension. Cela agira comme la configuration de construction. Par défaut, le conteneur est vide et n'inclut que les applications et les dépendances installées avec l'image de base. Vous devrez copier le code de votre application ; si vous ne servez que du contenu statique, c'est facile, mais si vous travaillez avec des applications côté serveur comme WordPress, vous devrez peut-être installer des dépendances supplémentaires.
Publicité
La configuration suivante est assez basique. Étant donné qu'il s'agit d'une application de nœud, nous devons exécuter npm run build pour obtenir une version prête pour la distribution. Nous pouvons gérer tout cela dans le Dockerfile, en configurant une construction de conteneur en deux parties :
FROM node:latest as build-stage WORKDIR /src COPY package*.json ./RUN npm install COPY ./. RUN npm run build FROM nginx as production-stage RUN mkdir /src COPY –from=build-stage /src/dist /src COPY nginx.conf /etc/nginx/nginx.conf
La commande FROM de la première ligne extrait le conteneur de nœuds de Docker Hub et crée un nouveau conteneur appelé build-stage. Le prochain cd‘s dans ce répertoire et copie sur le package.json. Ensuite, il exécute npm install, puis copie le code de l'application et démarre le processus de génération. Si votre application doit être construite à partir des sources, vous voudrez faire quelque chose de similaire.
L'état suivant extrait le conteneur nginx pour servir de déploiement de production. Il crée le répertoire src, puis copie, à partir du conteneur de l'étape de compilation, le dossier /src/dist/ contenant les artefacts de compilation, vers le dossier /src du conteneur de production. Il copie ensuite un fichier de configuration NGINX.
Vous souhaiterez également créer un nouveau fichier appelé .dockerignore, pour lui dire d'ignorer node_modules ainsi que tous les artefacts de build des builds locaux.
**/node_modules **/dist
Le Dockerfile fait référence à un nginx.conf, que vous devrez également créer. Si vous exécutez une configuration plus complexe avec plusieurs configurations dans /sites-available, vous souhaiterez peut-être créer un nouveau dossier pour votre configuration NGINX et le copier.
utilisateur nginx; processus_travailleur 1 ; error_log /var/log/nginx/error.log avertir ; pid /var/run/nginx.pid; événements { worker_connections 1024; } http { inclure /etc/nginx/mime.types; default_type application/octet-stream ; log_format main '$remote_addr – $remote_user [$time_local] “$request” ' '$status $body_bytes_sent “$http_referer” ' '”$http_user_agent” “$http_x_forwarded_for”' ; access_log /var/log/nginx/access.log main; envoyer le fichier activé ; keepalive_timeout 65; serveur { écouter 80; server_name localhost; emplacement/{ racine /src; index index.html; try_files $uri $uri//index.html; } error_page 500 502 503 504 /50x.html; emplacement = /50x.html { racine /usr/share/nginx/html; } } }
C'est juste un serveur Web HTTP. Le moyen le plus simple de configurer HTTPS serait d'exécuter le certbot LetsEncrypt localement et de copier le certificat de /etc/letsencrypt/live/example.com/fullchain.pem dans le conteneur de production. Ces certificats sont valables 90 jours, vous devrez donc les renouveler régulièrement. Vous pouvez automatiser cela dans le cadre du processus de construction du conteneur.
Publicité
Une fois que tout est en ordre, vous pouvez exécuter la construction Docker :
docker build . -t my-app
Cela va créer le conteneur en tant que my-app, après quoi vous êtes libre de le marquer et de l'envoyer à ECS ou à un registre de conteneurs pour un déploiement éventuel. Vous devez, bien sûr, le tester localement d'abord avec docker run binding localhost:8080 to port 80 of the NGINX instance :
docker run -d -p 8080:80 my-app
Une fois que vous avez une image construite , le déployer en production est assez simple. Vous pouvez lire notre guide sur la configuration d'un déploiement de conteneur à mise à l'échelle automatique sur AWS ECS pour en savoir plus, ou lire notre guide sur la configuration d'un pipeline CI/CD avec des conteneurs pour gérer les builds et les déploiements automatisés.
< strong>CONNEXES : Qu'est-ce qu'un fichier PEM et comment l'utilisez-vous ?