Pour faire en sorte que les applications PHP prennent en charge HTTPS dans Docker, le noyau consiste à configurer le certificat SSL et la clé dans les conteneurs Nginx ou Apache et s'assurer qu'ils fonctionnent en conjonction avec les conteneurs PHP-FPM. 1. Créez un certificat auto-signé à utiliser dans l'environnement de développement; 2. écrivez un dockerfile pour php-fpm et nginx; 3. Configurez Nginx pour activer HTTPS et transférer les demandes PHP à PHP-FPM; 4. Utilisez Docker-Compose pour orchestrer le service et monter le répertoire du certificat et du code; 5. Modifiez le fichier Hosts local pour résoudre le nom de domaine à 127.0.0.1. Si HTTPS est inaccessible ou que l'erreur de certificat se produit, les raisons courantes incluent: Erreur de chemin de certificat, port non exposé ou occupé, erreur de syntaxe de configuration NGINX, restrictions de pare-feu, certificat auto-signé non fiducie, problèmes de contenu mixte ou erreurs de résolution DNS. Les points clés de la création rapide de HTTPS dans l'environnement de développement sont: Utiliser OpenSSL pour générer des certificats, un répertoire Unified CERTS, des certificats de montage Docker-Compose, une configuration Nginx Correct chemin et définir des fichiers h?tes. L'environnement de production doit utiliser Let’s Encrypt et CERTBOT pour gérer automatiquement les certificats, obtenir des certificats via des conteneurs CERTBOT indépendants en conjonction avec les défis HTTP ou DNS, et configurer un mécanisme de renouvellement automatique pour garantir que les certificats sont valides pendant longtemps; Dans le même temps, faites attention aux mesures de sécurité telles que le contr?le de l'autorisation, la sauvegarde et les notifications par e-mail.

Pour le dire franchement, laissez votre application PHP s'exécuter sur HTTPS dans Docker, il est nécessaire d'installer correctement votre certificat SSL et votre clé dans un conteneur sur un serveur Web (tel que Nginx ou Apache), puis configurez-le pour écouter le port 443, et utilisez ces certificats pour crypter la communication. Dans le même temps, assurez-vous que le serveur Web et les conteneurs PHP-FPM peuvent fonctionner de manière transparente pour permettre l'exécution de votre code PHP dans un environnement sécurisé.

Solution

Pour ce faire, nous utilisons généralement docker-compose pour orchestrer les deux services de base de Nginx (ou Apache) et PHP-FPM. L'idée principale est: Nginx est responsable de la réception des demandes HTTPS, du traitement des poignées de main SSL, puis de la transmission des demandes liées à PHP au conteneur PHP-FPM pour le traitement.

Nous préparons d'abord un certificat SSL auto-signé, ce qui est particulièrement pratique dans l'environnement de développement et permet d'économiser les tracas de demander un certificat formel. Créez un dossier certs dans le répertoire racine de votre projet et exécutez:

 CERTS MKDIR -P
OpenSSL REQ -X509 -NODES -DAYS 365 -NEWKEY RSA: 2048 -KeyOut CERTS / NGINX.KEY -out CERTS / NGINX.CRT -SUBJ "/cn=yourdomain.local"

Ici, yourdomain.local peut être n'importe quel nom de domaine pointant vers 127.0.0.1 dans votre fichier d'h?tes locaux, tels que app.local .

Ensuite, nous avons besoin d'un Dockerfile pour créer notre service PHP-FPM et un fichier de configuration NGINX.

1. php/Dockerfile (en supposant qu'il est placé dans le dossier php dans le répertoire racine du projet):

 De PHP: 8,2-fpm-alpine

# Installez les extensions PHP couramment utilisées et ajoutez Run Docker-PhP-Extal-Istal PDO_MYSQL OPCACHE Selon les exigences de votre projet

Workdir / var / www / html

2. nginx/Dockerfile (en supposant qu'il est placé dans le dossier nginx dans le répertoire racine du projet):

 De Nginx: Alpine

# Copier la configuration de la configuration Nginx personnalisée Copier nginx.conf /etc/nginx/conf.d/default.conf

# Copiez le fichier de certificat, ici en supposant que le certificat se trouve dans le dossier des certificats du répertoire racine du projet # Mont à travers le volume dans docker-compose.yml est plus flexible, voici juste un exemple # copie ../certs/nginx.crt /etc/nginx/certs/nginx.crt
# Copier ../certs/nginx.key /etc/nginx/certs/nginx.key

Workdir / var / www / html

3. nginx/nginx.conf (configuration nginx https):

 serveur {
    écoutez 80;
    écoutez [::]: 80;
    server_name yourDomain.local; # Remplacez par votre nom de domaine Retour 301 https: // $ host $ request_uri; # Force HTTP à passer à HTTPS
}

serveur {
    écoutez 443 SSL HTTP2;
    écoutez [::]: 443 SSL HTTP2;
    server_name yourDomain.local; # Remplacez par votre nom de domaine # chemin de certificat SSL, ici, il sera monté via Docker-Compose Volumes SSL_CERTIFATE /ETC/NGINX/CERTS/NGINX.CRT;
    ssl_certificate_key /etc/nginx/certs/nginx.key;

    # Configuration SSL recommandée SSL_SESSION_CACHE partagée: SSL: 10m;
    ssl_session_timeout 10m;
    SSL_PROTOCOLS TLSV1.2 TLSV1.3;
    ssl_prefer_server_ciphers sur;
    SSL_CIPHERS ?Ecdhe-ECDSA-AES128-GCM-SHA256: ECDHE-RSA-AES128-GCM-SHA256: ECDHE-ECDA-AES256-GCM-SHA 384: ECDHE-RSA-AES256-GCM-SHA384: DHE-RSA-AES128-GCM-SHA256: DHE-RSA-AES256-GCM-SHA384 ';
    ssl_stapling sur;
    ssl_stapling_verify sur;
    Resolver 8.8.8.8 8.8.4.4 Valide = 300S;
    résolver_timeout 5s;

    add_header x-frame-options "Sameorigin";
    add_header x-content-type-options "nosniff";
    add_header x-xss-protection "1; mode = bloc";

    root / var / www / html / public; # Votre répertoire de portail d'application, comme le public de Laravel

    index index.php index.html index.htm;

    emplacement / {
        try_files $ uri $ uri / /index.php?$Query_string;
    }

    Emplacement ~ \ .php $ {
        FastCGI_PASS PHP: 9000; # PHP est le nom de service Docker-Compose, 9000 est le port par défaut de PHP-FPM FASTCGI_INDEX INDEX.PHP;
        FastCGI_BUFFERS 16 16K;
        fastcgi_buffer_size 32k;
        fastcgi_param script_filename $ document_root $ fastcgi_script_name;
        Inclure FastCGI_PARAMS;
    }

    # Masquer Nginx Version Information Server_Tokens OFF;
}

4. docker-compose.yml (service d'orchestration):

 Version: '3.8'

services:
  nginx:
    construire:
      Contexte: ./nginx # PORTS DOCKERFILE DOCKERFILE de Nginx:
      - "80:80"
      - "443: 443"
    Volumes:
      - ./src:/var/www/html # Moutez votre code de projet - ./certs:/etc/nginx/certs # Mount SSL Certificate and Key - ./nginx/nginx.conf:/etc/nginx/conf.d/default.conf:RO #
      - PHP
    redémarrer: sauf arrêt

  PHP:
    construire:
      Contexte: ./PHP # Volumes de chemin DockerFile de PHP:
      - ./src:/var/www/html # Montez votre code de projet Redémarrer: sauf si vous êtes arrêté
    # Si nécessaire, le port de PHP-FPM peut être exposé, mais généralement Nginx peut accéder aux ports en interne #:
    # - "9000: 9000"

5. src/public/index.php (un fichier de test simple):

 <? Php
Echo "Bonjour de Https PHP sur Docker!";
phpinfo ();
?>

Enfin, exécutez docker-compose up -d --build dans le répertoire racine de votre projet, puis modifiez votre fichier hosts locaux (Windows in C:\Windows\System32\drivers\etc\hosts , macOs / linux dans /etc/hosts ), et ajoutez une ligne:

 127.0.0.1 YourDomain.Local

Maintenant, visitez https://yourdomain.local , vous devriez pouvoir voir la sortie de PHP et le navigateur incitera le certificat à se méfier (car il est auto-signé), mais la connexion est cryptée.

Pourquoi mon HTTPS est-il toujours inaccessible après la configuration, ou j'obtiens une erreur de certificat?

Cette question est bonne. Chaque fois que je fais du SSL, je rencontre toujours des pièges étranges. Je pense personnellement que les plus courants ne sont que quelques-uns:

1. Le chemin ou le nom du certificat est mauvais: c'est l'erreur la plus probable pour les débutants à faire. Les chemins remplis ssl_certificate et ssl_certificate_key pointent vraiment vers le fichier correct à l'intérieur du conteneur? Vous pouvez être correct dans l'h?te, mais après l'avoir monté dans le conteneur, le chemin change. Vérifiez la configuration volumes dans docker-compose.yml pour vous assurer que le fichier de certificat est en effet monté sur le chemin spécifié dans nginx.conf à l'intérieur du conteneur nginx. Par exemple, dans mon exemple ci-dessus, le chemin de certificat à l'intérieur du conteneur Nginx est /etc/nginx/certs/nginx.crt , et l'h?te est ./certs/nginx.crt . Si le chemin est écrit de manière incorrecte, Nginx rapportera une erreur lors du démarrage, ou SSL sera directement refusé d'être chargé.
2. Le port n'est pas exposé ou occupé: assurez-vous que ports nginx dans docker-compose.yml a "443:443" , ce qui signifie que le port 443 de l'h?te sera mappé dans le port du conteneur Nginx 443. Si le port 443 de l'h?te a été occupé par d'autres services (tels que IIS, Apache ou d'autres instances Nginx), Docker ne peut pas être en train de se faire entendre et de faire défaut. à l'heure actuelle, vous pouvez essayer de mapper vers d'autres ports, tels que "8443:443" , puis visiter https://yourdomain.local:8443 .
3. Erreur de syntaxe de configuration Nginx: ne sous-estimez pas cela. L'absence d'un support ou d'un point-virgule peut faire une frappe Nginx directement. Vous pouvez entrer dans le conteneur Nginx et exécuter nginx -t pour vérifier la syntaxe du fichier de configuration. docker-compose exec nginx nginx -t est une bonne habitude.
4. Blocs de pare-feu: les règles du groupe de sécurité du port de bloc Host ou Cloud Server 443? Cela est particulièrement courant lors du déploiement dans un environnement de production, et les environnements de développement locaux sont relativement rares, mais pas impossibles.
5. Erreur "attendue" pour les certificats auto-signés: si vous utilisez un certificat auto-signé, le navigateur invitera certainement "une connexion dangereuse" ou "erreur de confidentialité". C'est en fait normal car le navigateur ne vous fait pas confiance en tant qu'émetteur privé. Ce n'est pas une erreur de configuration, mais un mécanisme de sécurité. Vous devez ajouter manuellement des exceptions dans votre navigateur ou faire confiance à ce certificat.
6. Avertissement de contenu mixte: votre page est chargée via HTTPS, mais la page fait référence à certaines ressources HTTP (telles que les images, les fichiers CSS, JS). Le navigateur considérera que cela est dangereux et peut empêcher le chargement de ces ressources HTTP, ou de donner un avertissement dans la console. La solution consiste à s'assurer que toutes les ressources sont chargées sur HTTPS.
7. Question de résolution DNS: Le nom de domaine que vous avez visité a visité correctement s'est résolu à l'adresse IP de l'h?te Docker? Surtout si vous configurez yourdomain.local dans le fichier hosts , mais le navigateur peut mettre en cache l'ancienne résolution, ou vous accédez au nom de domaine que vous avez configuré.

Lorsque vous rencontrez des problèmes, ne paniquez pas. Regardez d'abord les journaux du conteneur Docker ( docker-compose logs nginx ). Vous pouvez généralement trouver des indices.

Comment construire rapidement un conteneur PHP qui prend en charge les HTTPS dans un environnement de développement?

Dans l'environnement de développement, nos demandes de base sont "rapides" et "simples", et nous n'avons pas à nous soucier trop de l'autorité du certificat. Dans la solution ci-dessus, une méthode très rapide a été donnée, le noyau consiste aux certificats auto-signés .

Pour le dire franchement, vous n'avez pas besoin de postuler pour Let’s Encrypt, et vous n'avez pas besoin de dépenser de l'argent pour des certificats commerciaux. Utilisez simplement la commande openssl pour générer vous-même une paire de clés et de fichiers de certificat. Personnellement, je fais généralement ceci:

1. Répertoire Unified certs : Je vais mettre un dossier certs en dehors de tous mes projets Docker, ou dans le répertoire racine de chaque projet.
2. Commande simple openssl :

    CERTS MKDIR -P
   OpenSSL REQ -X509 -NODES -DAYS 365 -NEWKEY RSA: 2048 -Keyout Certs / Dev.Key -out Certs / Dev.Crt -Subj "/cn=*.LoCaldEv"

   Ici, j'ai utilisé *.localdev afin que je puisse utiliser plusieurs sous-domaines tels que app1.localdev , app2.localdev , etc., et je n'ai besoin que d'un seul certificat. Bien s?r, vous pouvez également utiliser yourdomain.local directement.

3. Montage dans docker-compose.yml : assurez-vous que dans votre docker-compose.yml , volumes du service Nginx a des montures similaires à ./certs:/etc/nginx/certs , et mappez le fichier de certificat de l'h?te dans le conteneur Nginx.
4. La configuration de Nginx pointe: ssl_certificate et ssl_certificate_key dans nginx.conf pointez le chemin de certificat à l'intérieur du conteneur.
5. hosts Fichier Configuration: la dernière étape, et l'étape la plus oubliable, consiste à pointer yourdomain.local (ou app.localdev , etc.) à 127.0.0.1 dans votre fichier hosts de système d'exploitation. De cette fa?on, lorsque vous accédez au nom de domaine, la demande sera frappée à votre conteneur Docker local.

Avec ce processus, vous pouvez essentiellement exécuter un environnement de développement local qui prend en charge HTTPS en cinq minutes. Bien que le navigateur invite à être dangereux, il est tout à fait correct en fonction et peut également simuler le comportement HTTPS dans l'environnement de production, tels que la manipulation des redirections, les attributs de sécurité des cookies ( Secure , HttpOnly ), etc. Il est également pratique pour déboguer car vous savez que le problème du certificat n'est pas le problème de certificat "réel" comme l'environnement de production.

Comment gérer et mettre à jour les certificats SSL en toute sécurité et efficacement dans un environnement de production?

L'environnement de production ne peut pas être aussi libre que l'environnement de développement. Ce que nous poursuivons ici, c'est l'automatisation, la sécurité et la fiabilité. Ma solution personnelle la plus recommandée est de combiner Let's Encrypt and Certbot , puis les capacités d'orchestration de Docker .

1. Let's Encrypt et CERTBOT: Let's Encrypt propose des certificats SSL / TLS gratuits, et CERTBOT est son outil client officiellement recommandé qui acquiert et renouvelle automatiquement les certificats. CERTBOT prend en charge une variété de serveurs Web et de modes de défi.

2. Stratégie d'intégration de CERTBOT dans Docker:

   • Conteneur de certificat autonome: c'est ma manière préférée. Vous pouvez exécuter un conteneur certificatif autonome qui est responsable de l'obtention et du renouvellement des certificats. Ce conteneur doit être en mesure d'accéder au chemin .well-known/acme-challenge (HTTP Challenge) du serveur Web, ou de pouvoir modifier l'enregistrement DNS (DNS Challenge).

     • HTTP Challenge: CERTBOT créera temporairement un fichier dans votre répertoire de racine Web, et le serveur Let's Encrypt accède à ce fichier via HTTP pour vérifier la propriété du nom de domaine. Cela signifie que votre conteneur Nginx doit exposer le port 80, et le conteneur CERTBOT doit être en mesure d'écrire des certificats à des volumes partagés auxquels le conteneur Nginx peut accéder.
     • DNS Challenge: CERTBOT vous permettra d'ajouter un enregistrement TXT à l'enregistrement DNS du nom de domaine. Cette méthode ne nécessite pas que le serveur Web exposait le port 80 et convient plus à des scénarios où le service Web n'est pas directement exposé, ou des scénarios où plusieurs services partagent un nom de domaine. De nombreux fournisseurs de services DNS disposent d'un plug-in CERTBOT pour automatiser ce processus.

   • Nginx est partagé en tant que proxy inversé et volume de certificat:

      Version: '3.8'
     services:
       nginx:
         Image: Nginx: Alpine
         PORTS:
           - "80:80"
           - "443: 443"
         Volumes:
           - ./src:/var/www/html
           - ./nginx/nginx.conf:/etc/nginx/conf.d/default.conf:ro
           - CERTBOT-WEB: / var / www / certbot # http Challenge pour certbot- Certbot-ETC: / etc / letSencrypt # Storage de certificat Detend_on:
           - PHP
         redémarrer: sauf arrêt
     
       PHP:
         # ... (similaire à ci-dessus)
     
       Certbot:
         Image: certbot / Certbot
         Volumes:
           - certbot-web: / var / www / certbot
           - Certbot-ETC: / etc / letSencrypt
         # Exemple de commande, Obtention du certificat pour la première fois # Commande: Certonly - webroot -w / var / www / certbot --email your_email@example.com -d yourDomain.com --Agree-Tos --no-eff-email
         # Exemple de commande, certificat de renouvellement (généralement exécuté via le travail Cron ou Docker-Compose Exec)
         # Commande: renouveler - webroot -w / var / www / certbot --v-hook "docker-compose exec nginx nginx -s reload"
         Entrée Point: "/ bin / sh -c 'Terme de sortie du piège; tandis que :; do certbot renouveau; sleep 12h & wait $!; Done;" # # Renewal Restart: On-Failure # Si il échoue, redémarrez les volumes:
       certbot-web:
       Certbot-ETC:

     Dans la configuration de Nginx, vous devez ajouter un bloc d'emplacement au chemin de vérification du CERTBOT:

      emplacement /.well-known/acme-challenge/ {{
         root / var / www / certbot;
     }

     Après avoir exécuté la commande certitbot pour la première fois pour obtenir le certificat, ssl_certificate et ssl_certificate_key dans la configuration nginx devraient pointer vers /etc/letsencrypt/live/yourdomain.com/fullchain.pem et /etc/letsencrypt/live/yourdomain.com/privkey.pem .

   • Renouvellement automatisé: le certificat de crypte est valable pour seulement 90 jours. Par conséquent, le renouvellement automatisé est un must. entrypoint du service certbot ci-dessus fournit un simple mécanisme de renouvellement automatique, qui tente de renouveler toutes les 12 heures. Après un renouvellement réussi, il est généralement nécessaire de redémarrer ou de recharger la configuration Nginx pour lui permettre de charger le nouveau certificat. --post-hook "docker-compose exec nginx nginx -s reload" fait cela.

   • Considérations de sécurité:

     • Autorisations: Assurez-vous que les autorisations du volume certbot-etc sont correctement définies et que seuls les processus nécessaires peuvent accéder à la clé privée.
     • Sauvegarde: sauvegarde le certificat et la clé dans certbot-etc au cas où.
     • Notifications par e-mail: CERTBOT peut configurer les notifications par e-mail et vous recevrez un rappel en cas d'échec du renouvellement du certificat.
     • Sécurité du défi DNS: Si vous utilisez DNS Challenge, assurez-vous que vos clés API DNS sont stockées en toute sécurité et ne les code pas dans votre code.

   • Outils plus avancés: pour des environnements de production plus complexes, envisagez d'utiliser des routeurs de bord / proxy inversé comme Trafik ou Caddy . Ils ont le support intégré de Let's Encrypt, qui peut gérer automatiquement l'acquisition et le renouvellement des certificats, simplifiant considérablement la configuration HTTPS. Vous n'avez qu'à configurer le nom de domaine et ils peuvent gérer automatiquement SSL, ce qui est très sans souci. Mais si vous êtes habitué à Nginx, la solution CERTBOT ci-dessus est également suffisamment puissante et flexible.

   En bref, le c?ur de la configuration SSL dans les environnements de production est l'automatisation et la fiabilité, garantissant que les certificats sont toujours valides et peuvent être automatiquement mis à jour pour éviter les interruptions de service en raison de l'expiration des certificats.

   Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!