Excellent. Nope that will be perfect. Thanks again! Very much appreciated.
1 me gusta
The command is now ./discourse-setup --two-container
worked as expected just now 
2 Me gusta
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 me gusta
Yes, very helpful thanks.
2 Me gusta
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 me gusta
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 Me gusta
@pfaffman No sé si lo has hecho, pero si lo has hecho, ¿quieres enlazarlo aquí? 
3 Me gusta
¿Deberíamos agregar un && ./launcher cleanup al final de estos comandos?
He descubierto que después de cambiar a una instalación de dos contenedores, no se tarda mucho en llenar el almacenamiento disponible con imágenes antiguas.
1 me gusta
Definitivamente lo recomiendo en mi guía… Mucha gente implementa en sistemas pequeños como las gotas de DO y sé que he ayudado a otros que no se dieron cuenta de dónde se iba su espacio.
2 Me gusta
@pfaffman, Hola,
Hace unos días instalé AWS EC2 con un solo contenedor y todo funcionó bien. Pero necesito exactamente la configuración de dos contenedores, web_only en EC2 y data en AWS RDS (PostgreSQL 15.3 en el puerto 5432 => No puedo elegir otra versión, y la base de datos no tiene el parámetro DB_NAME). Como clúster de Redis intenté usar AWS ElastiCache, pero luego dejé un enlace en data.yml a la plantilla existente:
#- "templates/postgres.template.yml"
- "templates/redis.template.yml"
Después de iniciar correctamente data y web_only, no puedo abrir la página web. “Este sitio no se puede alcanzar”
No he realizado ningún cambio en los registros DNS ni he modificado la configuración de acceso en los grupos de seguridad de AWS (firewall para web y base de datos).
Arranque exitoso, para iniciar usa ./launcher start data
root@ip-172-31-3-68:/var/discourse# ./launcher start data
Se detectó la arquitectura x86_64.
+ /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
Arranque exitoso, para iniciar usa ./launcher start web_only
root@ip-172-31-3-68:/var/discourse# ./launcher start web_only
Se detectó la arquitectura x86_64.
+ /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
- Comprobé la conexión a la base de datos desde SSH usando telnet - OK
- Puedo ver las conexiones de la base de datos en el panel de AWS RDS
- He reiniciado las instancias 3 veces
- He ejecutado la reconstrucción 3-4 veces sin errores
- Comprobé la lista de contenedores e imágenes activas, limpié las innecesarias
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
¿Qué más puedo hacer? ¡Gracias por tus esfuerzos y tiempo!
No es necesario. Solo necesitas el contenedor web y eliminar las plantillas de Postgres y Redis. Elasticache es, en mi opinión, absurdamente caro, por lo que podrías ejecutarlo en tu EC2 si estás utilizando un solo host.
Simplemente agrega las variables de entorno a tu app.yml existente y elimina las plantillas innecesarias. Escuché recientemente que este sitio se está ejecutando en PG15, por lo que eso debería estar bien.
Gracias por la respuesta, Jay (@pfaffman). Solo quiero aclarar:
- ¿debo usar la instalación de app.yml de un solo contenedor y comentar las líneas sobre la base de datos y redis? y también en el campo ENV de app.yml, luego agregar las líneas para la base de datos remota en AWS (DB_USER, etc. - desde web_only como ahora)?
- ¿o lo dejo como está, pero detengo el contenedor de datos y dejo solo web-only?
- Si no uso ElastiCache, ¿entonces necesito dejar la línea “templates/redis.template.yml”?
El cambio de estándar a dos contenedores fue casi sin problemas. Perdí bastante tiempo debido a algunos espacios faltantes en el archivo yml, que intentaron convencerme de que tenía problemas de localización (ni cerca), pero fue un error del usuario.
Pero cuando puse el foro en marcha, tenía un foro completamente nuevo. Fue bastante fácil de arreglar, porque tenía una copia de seguridad actualizada en S3, pero ahora me pregunto por qué sucedió en primer lugar, ¿alguna idea?
Quiero decir, tomar la ruta en la que instalaría una configuración totalmente nueva de dos contenedores y luego la restauraría a partir de copias de seguridad podría ahorrar algo de tiempo. O no, porque aún editaría el yml, al menos agregando complementos, arreglando la configuración de correo electrónico, maxmind, etc.
1 me gusta
[No relacionado con la publicación anterior]
Me pregunto, ¿cuál es la ventaja de usar una configuración de dos contenedores? ¿Por qué no el contenedor único normal?
Creo que es para no tener tu foro sin conexión cuando haces una reconstrucción para actualizar/instalar un plugin.
2 Me gusta
Para mí, ya se menciona un breve tiempo de inactividad. Además, actualizo a menudo, al menos una vez por semana, por lo que mi configuración es propensa a encontrar errores, no tan a menudo, debo decir, pero de vez en cuando todavía.
Esas veces en que la razón es un plugin, no a menudo, la mayoría de las veces es algún componente, necesito tres o cuatro rondas para resolver el problemático. Y cuando cada ronda toma algo así como 30 minutos, mi foro estaría inactivo un poco demasiado tiempo, incluso si es pequeño y basado en pasatiempos.
Y la tercera razón es porque puedo.
2 Me gusta
Me resulta extremadamente estresante si una reconstrucción falla y mi sitio se cae. Básicamente, exige mi atención inmediata (y a veces prolongada) para solucionar / encontrar una solución alternativa. ¡¡¡Nada divertido!!!
La instalación de dos contenedores convierte esto en una mera inconveniencia, y el problema subyacente generalmente se puede solucionar en un momento que me convenga. Además, el problema que causó el problema a menudo se ha resuelto en esa etapa.
Si usara stable, probablemente no me molestaría. Pero viviendo más cerca del borde usando tests-passed, es invaluable por la resiliencia que otorga durante las reconstrucciones / actualizaciones.
2 Me gusta
Ah, ya veo. ¡Gracias por la explicación!
¡Me olvidé por completo que había publicado eso!
1 me gusta
Buen tutorial. Me toma 5 minutos, con un servidor nuevo, crear y restaurar la copia de seguridad y luego `./discourse-setup --two-container’.
Gracias
2 Me gusta
¿Alguien puede explicar por qué, si estás convirtiendo un servidor existente con una base de datos en buen estado, este paso es necesario?
Entiendo que crear una copia de seguridad segura fuera del sitio justo antes de la migración es una buena práctica, pero ¿por qué la descarga?
2 Me gusta