Quand le port 80 est-il disponible ?

Je suis un peu confus quant au moment où une nouvelle installation de Discourse basée sur Docker expose le port 80. Laissez-moi expliquer…

Lorsque j’exécute ./discourse-setup, je suppose que les questions initiales (nom d’hôte, adresse e-mail, etc.) sont toutes présentées AVANT la création du conteneur et donc avant que Discourse n’expose le port 80. Est-ce correct ?

Si oui, cela ne crée-t-il pas un peu de situation de catch-22 lors de la saisie du nom d’hôte ?

J’ai créé mon enregistrement A (et il est joignable par ping via le nom d’hôte). Mais le port 80 n’est pas ouvert. Je pense comprendre pourquoi, à savoir que le conteneur n’est pas encore créé.

Mais si c’est le cas, comment cette vérification initiale du nom d’hôte peut-elle fonctionner, si elle vérifie le nom avant que le conteneur ne soit créé ?

Évidemment, j’ai une mauvaise hypothèse ici, alors quelqu’un peut-il s’il vous plaît mettre fin à mes tourments ?

Merci.

discourse-setup exécute nc, ce qui ouvre le port pour le test.

Si vous utilisez un système d’exploitation qui n’a pas nc installé, ce test échouera en raison de cela. Vous pouvez soit confirmer si l’absence de nc est le problème, soit simplement supposer que vous savez ce que vous faites et que cela fonctionnera.

Ah, j’ai compris.

Présumer que je sais ce que je fais s’est généralement avéré être un mauvais choix ! Mais j’ignore l’avertissement pour l’instant et je continue.

Je crains de rencontrer un problème, car je suppose que nc devrait autoriser l’exposition du port 80 (je n’ai pas encore de pare-feu), mais je réglerai cela plus tard.

Merci encore.

Eh bien, c’est précisément pour cela que ces tests existent. Mais ils ne fonctionnent que pour la plupart des gens, la plupart du temps.

Si vous tapez nc à la ligne de commande et que vous obtenez un message « commande non trouvée », vous pouvez supposer que le test est défectueux (ce qui ne signifie pas que votre nom de domaine résout vers votre serveur et que le port est accessible).

J’ai rencontré ce problème lors de la configuration de mon premier serveur et, pour agacer, le problème s’est résolu de lui-même après quelques heures. Ce genre de problème indique souvent un problème de réplication DNS, mais j’utilise CloudFlare DNS (TTL faible) et je peux faire un ping via le nom d’hôte sans problème.

L’installation de Docker s’est déroulée correctement et nc est disponible.

docker ps indique que les ports 80 et 443 sont tous deux redirigés vers le conteneur.

sof -i -P -n rapporte que docker-pr écoute également les deux ports.

Je n’ai jamais compris pourquoi ce problème est survenu avec la première installation, mais comme il s’est reproduit, je vais approfondir et faire du dépannage. Je n’ai pas encore trouvé la solution, mais je soupçonne qu’il s’agit d’un problème de plomberie de base.

Merci encore.

Cela ressemble à un problème de propagation DNS.

Le nuage orange est-il activé ? Si Cloudflare est utilisé uniquement pour le DNS, vous êtes bon, mais s’il est interposé, vous ne pourrez pas faire fonctionner Let’s Encrypt, ce qui est l’objectif du test.

Le nuage orange est éteint. Je ne veux pas vous déranger davantage avec cela, Jay. C’est un petit défi de dépannage intéressant et je vais le résoudre.

Je suis presque certain qu’il ne s’agit pas d’une réplication DNS, car je peux accéder au site depuis de nombreux appareils par nom d’hôte (via le Wi-Fi, le réseau cellulaire, etc.). Je reviendrai vers vous ici si et quand cela sera résolu.