Excellent. Nope that will be perfect. Thanks again! Very much appreciated.
1 « J'aime »
The command is now ./discourse-setup --two-container
worked as expected just now 
2 « J'aime »
Good catch! Did it print a message that made it easy to figure that out?
I’ve been meaning to clean up this topic since they change.
1 « J'aime »
Yes, very helpful thanks.
2 « J'aime »
Are there any plans to migrate from the old “container links” thing to proper setup with a custom network with two containers being connected to it?
“Links” are legacy and may be removed in the future according to Docker docs
1 « J'aime »
That sounds like a good idea.
Unless someone beats me to it, I’ll see about subunits /creating a PR to switch to networks and /or sockets (which some prefer anyway) and creating a howto to convert an existing setup to the new configuration.
5 « J'aime »
@pfaffman Je ne sais pas si vous avez eu le temps de le faire, mais si c’est le cas, voulez-vous y mettre un lien ici ? 
3 « J'aime »
Devrions-nous ajouter un && ./launcher cleanup à la fin de ces commandes ?
J’ai constaté qu’après être passé à une installation à deux conteneurs, il ne faut pas longtemps pour que le stockage disponible soit rempli d’anciennes images.
1 « J'aime »
Je le recommande absolument dans mon guide… Beaucoup de gens déploient sur des systèmes assez petits comme les droplets DO et je sais que j’ai aidé d’autres personnes qui ne réalisaient pas tout à fait où allait leur espace.
2 « J'aime »
@pfaffman, Salut,
Il y a quelques jours, j’ai installé AWS EC2 avec un seul conteneur et tout a fonctionné correctement. Mais j’ai besoin exactement de la configuration à deux conteneurs, web_only sur EC2 et data sur AWS RDS (PostgreSQL 15.3 sur le port 5432 => Je ne peux pas choisir une autre version, et la base de données n’a pas de paramètre DB_NAME). En tant que cluster Redis, j’ai essayé d’utiliser AWS ElastiCache, mais j’ai ensuite laissé un lien dans data.yml vers le modèle existant :
#- "templates/postgres.template.yml"
- "templates/redis.template.yml"
Après avoir réussi le bootstrapping de data et web_only, je ne peux pas ouvrir la page web. “Ce site est inaccessible”
Je n’ai apporté aucune modification aux enregistrements DNS ni changé les paramètres d’accès dans les groupes de sécurité AWS (pare-feu pour le web et la base de données).
Bootstrapping réussi, pour démarrer utilisez ./launcher start data
root@ip-172-31-3-68:/var/discourse# ./launcher start data
Architecture x86_64 détectée.
+ /usr/bin/docker run --shm-size=512m -d --restart=always -e LANG=en_US.UTF-8 -e LC_ALL=en_US.UTF-8 -e LANGUAGE=en_US.UTF-8 -h ip-172-31-3-68-data -e DOCKER_HOST_IP=172.17.0.1 --name data -t -v /var/discourse/shared/data:/shared -v /var/discourse/shared/data/log/var-log:/var/log --mac-address <...> local_discourse/data /sbin/boot
27b66e577d250e4178f5e145c9962be7b5f2d905cfacd233d3d2278e7b83aa93
Bootstrapping réussi, pour démarrer utilisez ./launcher start web_only
root@ip-172-31-3-68:/var/discourse# ./launcher start web_only
Architecture x86_64 détectée.
+ /usr/bin/docker run --shm-size=512m --link data:data -d --restart=always -e LANG=en_US.UTF-8 -e RAILS_ENV=production -e UNICORN_WORKERS=2 -e UNICORN_SIDEKIQS=1 -e RUBY_GC_HEAP_GROWTH_MAX_SLOTS=40000 -e RUBY_GC_HEAP_INIT_SLOTS=400000 -e RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR=1.5 -e DISCOURSE_DB_SOCKET= -e DISCOURSE_DB_HOST=database-discourse.<...>.rds.amazonaws.com -e DISCOURSE_DB_PORT= -e LETSENCRYPT_DIR=/shared/letsencrypt -e DISCOURSE_FORCE_HTTPS=true -e LC_ALL=en_US.UTF-8 -e LANGUAGE=en_US.UTF-8 -e DISCOURSE_HOSTNAME=talk.furtherium.com -e DISCOURSE_DEVELOPER_EMAILS=hello@furtherium.com -e DISCOURSE_SMTP_ADDRESS=email-smtp.us-east-2.amazonaws.com -e DISCOURSE_SMTP_PORT=587 -e DISCOURSE_SMTP_USER_NAME=A<...>S -e DISCOURSE_SMTP_PASSWORD=B<...>M -e DISCOURSE_NOTIFICATION_EMAIL=noreply@talk.furtherium.com -e LETSENCRYPT_ACCOUNT_EMAIL=me@example.com -e DISCOURSE_DB_NAME= -e DISCOURSE_DB_USERNAME=postgres -e DISCOURSE_DB_PASSWORD=7<...>1 -e DISCOURSE_REDIS_HOST=data -h ip-172-31-3-68-web-only -e DOCKER_HOST_IP=172.17.0.1 --name web_only -t -p 80:80 -p 443:443 -v /var/discourse/shared/web-only:/shared -v /var/discourse/shared/web-only/log/var-log:/var/log --mac-address <...> local_discourse/web_only /sbin/boot
1233f1c660eb7cecc48d2a840aae037b46ecfd7afe029ef89b2e686b136b9886
- J’ai vérifié la connexion à la base de données depuis SSH en utilisant telnet - OK
- Je peux voir les connexions à la base de données dans le tableau de bord AWS RDS
- J’ai redémarré les instances 3 fois
- J’ai exécuté rebuild 3-4 fois sans erreurs
- J’ai vérifié la liste des conteneurs et images actifs, nettoyé ceux qui étaient inutiles
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
1233f1c660eb local_discourse/web_only "/sbin/boot" 18 minutes ago Up 18 minutes 0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp web_only
27b66e577d25 local_discourse/data "/sbin/boot" 47 minutes ago Up 47 minutes data
Que puis-je faire d’autre ? Merci pour vos efforts et votre temps !
Vous n’en avez pas besoin. Vous avez seulement besoin du conteneur web et de supprimer les modèles Postgres et Redis. Elasticache est, à mon avis, ridiculement cher, vous pourriez donc l’exécuter sur votre EC2 si vous utilisez un seul hôte.
Ajoutez simplement les variables d’environnement à votre app.yml existant et supprimez les modèles inutiles. J’ai entendu dire récemment que ce site fonctionne sur PG15, donc cela devrait aller.
Merci pour votre réponse, Jay (@pfaffman). Je souhaite juste clarifier :
- dois-je utiliser l’installation
app.ymlavec un seul conteneur et commenter les lignes concernant la base de données et Redis ? et aussi dans le champ ENV deapp.yml, puis ajouter les lignes pour la base de données distante dans AWS (DB_USER, etc. - à partir deweb_onlycomme maintenant) ? - ou dois-je le laisser tel quel, mais arrêter le conteneur de données et ne laisser que
web-only? - Si je n’utilise pas ElastiCache, dois-je laisser la ligne
"templates/redis.template.yml"?
Le passage du mode standard à deux conteneurs s’est presque déroulé sans problème. J’ai perdu pas mal de temps à cause d’espaces manquants dans le fichier yml, qui essayaient de me convaincre que j’avais des problèmes de localisation (pas du tout), mais c’était une erreur de l’utilisateur.
Mais quand j’ai mis le forum en ligne, j’avais un forum vierge. C’était assez facile à résoudre, car j’avais une sauvegarde à jour dans S3, mais je me demande maintenant pourquoi c’est arrivé en premier lieu - des suppositions ?
Je veux dire que prendre la route où j’installerais une configuration totalement nouvelle de deux conteneurs, puis la restaurerais à partir des sauvegardes pourrait faire gagner du temps. Ou pas, car j’éditerais toujours le yml, au moins pour ajouter des plugins, corriger les paramètres de messagerie, maxmind, etc.
1 « J'aime »
[Pas lié au message ci-dessus]
Je me demande quel est l’avantage d’utiliser une configuration à deux conteneurs ? Pourquoi pas le conteneur unique normal ?
Je pense que c’est pour ne pas avoir votre forum hors ligne lorsque vous effectuez une reconstruction pour des mises à niveau/l’installation d’un plugin.
2 « J'aime »
Pour moi, une courte interruption est déjà mentionnée. De plus, je mets à jour souvent, au moins une fois par semaine, donc ma configuration est susceptible de rencontrer des bugs — pas si souvent, je dois dire, mais de temps en temps quand même.
Les fois où la raison est un plugin — pas souvent, la plupart du temps c’est un composant — il me faut trois à quatre essais pour identifier celui qui pose problème. Et quand chaque essai prend environ 30 minutes, mon forum serait indisponible un peu trop longtemps, même s’il est petit et basé sur un hobby.
Et la troisième raison est parce que je le peux.
2 « J'aime »
Je trouve extrêmement stressant qu’une reconstruction échoue et que mon site tombe en panne. Essentiellement, cela exige mon attention immédiate (et parfois prolongée) pour trier / trouver une solution de contournement. Pas amusant du tout !!!
L’installation à deux conteneurs transforme cela en une simple gêne, et le problème sous-jacent peut généralement être traité à un moment qui me convient. De plus, le problème qui a causé le problème a souvent été résolu à ce stade.
Si j’utilisais stable, je ne me donnerais probablement pas la peine. Mais en vivant plus près du bord en utilisant tests-passed, c’est inestimable pour la résilience qu’il accorde lors des reconstructions / mises à jour.
2 « J'aime »
Ah, je vois. Merci pour l’explication !
J’avais complètement oublié que j’avais posté ça !
1 « J'aime »
Bon tuto. Cela me prend 5 minutes, avec un nouveau serveur, créer et restaurer la sauvegarde puis `./discourse-setup --two-container’.
Merci
2 « J'aime »
Quelqu’un peut-il expliquer pourquoi, si vous convertissez un serveur existant avec une base de données saine, cette étape est nécessaire ?
Je comprends que créer une sauvegarde hors site sûre juste avant la migration est une bonne pratique, mais pourquoi le téléchargement ?
2 « J'aime »