Comment exécuter NGINX Inside Docker (pour une mise à l'échelle automatique facile)
L'une des charges de travail les plus courantes de Docker est de l'utiliser pour conteneuriser des serveurs Web tels que NGINX et Apache afin d'exécuter une flotte de diffusion de contenu haute performance qui peut être facilement mise à l'échelle et gérée automatiquement. Nous allons vous montrer comment le configurer avec NGINX.
Configuration de NGINX dans Docker
Docker est une plate-forme de conteneurisation, utilisée pour regrouper votre application et tout son code dans une seule image de conteneur facilement gérable. Le processus pour ce faire est assez similaire à la façon dont vous procéderiez pour configurer un nouveau serveur – le conteneur est une ardoise vierge, vous devrez donc installer des dépendances, créer votre code, copier les artefacts de construction et copier toute 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 entendu, en fonction de l'application que vous conteneurisez, cela peut être un peu plus complexe. 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.
Pour avoir quelque chose d'un peu plus complexe 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 en fonction du contenu que vous diffusez, mais l'idée générale est la même.
A la racine de votre projet, créez un nouveau fichier simplement nommé Dockerfile
sans extension. Cela servira de configuration de construction. Par défaut, le conteneur est vide et inclut uniquement les applications et les dépendances qui sont installées avec l'image de base. Vous devrez copier le code de votre application; si vous ne faites que diffuser 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.
La configuration suivante est assez basique. Comme 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 première ligne FROM
commande tire le node
conteneur de Docker Hub et crée un nouveau conteneur appelé build-stage
. Le suivant cd
Est dans ce répertoire et copie sur le package.json
. Ensuite, il court npm install
, puis copie le code de l'application et lance le processus de création. Si votre application doit être créée à partir des sources, vous souhaiterez faire quelque chose de similaire.
L'état suivant tire le nginx
conteneur pour servir de déploiement de production. Cela rend le src
répertoire puis copie, à partir du build-stage
conteneur, le /src/dist/
dossier contenant les artefacts de construction, vers le /src
dossier du conteneur de production. Il copie ensuite un fichier de configuration NGINX.
Vous souhaiterez également créer un nouveau fichier appelé .dockerignore
, lui dire d'ignorer node_modules
ainsi que tous les artefacts de build à partir de 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.
user nginx; worker_processes 1; error_log /var/log/nginx/error.log warn; pid /var/run/nginx.pid; events { worker_connections 1024; } http { include /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; sendfile on; keepalive_timeout 65; server { listen 80; server_name localhost; location / { root /src; index index.html; try_files $uri $uri/ /index.html; } error_page 500 502 503 504 /50x.html; location = /50x.html { root /usr/share/nginx/html; } } }
Ceci est juste un serveur Web HTTP. Le moyen le plus simple de configurer HTTPS serait d'exécuter le certbot de LetsEncrypt localement et de copier le certificat depuis /etc/letsencrypt/live/example.com/fullchain.pem
dans le conteneur de production. Ces certificats sont valides pendant 90 jours, vous devrez donc les renouveler régulièrement. Vous pouvez automatiser cela dans le cadre du processus de création du conteneur.
Une fois que tout est en ordre, vous pouvez exécuter la build Docker:
docker build . -t my-app
Cela construira le conteneur comme my-app
, après quoi vous êtes libre de le baliser et de l'envoyer à ECS ou à un registre de conteneurs pour un éventuel déploiement. Vous devriez, ou bien sûr, le tester d'abord localement avec docker run
contraignant localhost:8080
au port 80 de l'instance NGINX:
docker run -d -p 8080:80 my-app
Une fois que vous avez une image construite, la déployer en production est assez simple. Vous pouvez lire notre guide pour mettre en place un déploiement de conteneur à mise à l'échelle automatique sur AWS ECS pour en savoir plus, ou lisez notre guide sur mise en place d'un pipeline CI / CD avec des conteneurs pour gérer les builds et les déploiements automatisés.