Gracias, así que ./launcher rebuild web_only (o rebuild data) en lugar de ./launcher rebuild app, y necesitaría leer atentamente las actualizaciones para ver cuándo se actualizan postgres o redis para actualizarlos manualmente también. Y la principal ventaja sobre la instalación independiente es que las reconstrucciones no necesitan esperar a que la base de datos se apague y luego se reinicie, revirtiendo transacciones si se interrumpió.
Pero con los últimos cambios de Falco, la base de datos nunca debería interrumpirse a menos que tarde más de 10 minutos en apagarse, lo cual ciertamente no sucederá a menos que tengamos muchísimos más usuarios. Por lo tanto, las actualizaciones no fallarán debido a ese problema, y el principal impacto es simplemente hacer que las actualizaciones tarden un par de minutos más.
Mi interpretación es que, en última instancia, el cambio agrega una gran cantidad de complejidad y carga mental por muy poca ganancia. Por favor, corríjame si me equivoco, no pretendo ser sarcástico/etc.
Solo como un poco de contexto, el cambio tendría que ofrecer beneficios sustanciales para valer la pena esa carga, porque todo esto es un favor no remunerado de mi parte (uno que ahora se extiende por más de 15 años, pero aun así), no es mi trabajo. Allí la situación es muy variable.
Mucha gente comparte esa opinión, lo cual sigo encontrando sorprendente. Las actualizaciones de Postgres ocurren menos de una vez al año, y generalmente no hay penalización por retrasarlas durante meses después del cambio inicial. Tener una configuración de 2 contenedores significa que puedes retrasar la actualización de postgres más fácilmente que si tienes un solo contenedor, lo que me parece otra ventaja.
Retrasar las actualizaciones de postgres históricamente ha significado un simple cambio en el archivo yaml de configuración, a menos que ustedes planeen dejar de admitir eso. Podemos manejar un par de minutos adicionales de inactividad para las actualizaciones y, a mi parecer, eso representa menos riesgo que depender de una persona (¡esa soy yo!) para mantener adecuadamente una configuración menos estándar y más compleja.
Desde mi punto de vista, la principal ventaja de dos contenedores es la reducción del tiempo de inactividad; como tú, creo que estoy de acuerdo con 20-30 minutos de inactividad cada par de meses. Pero es fácil ver que para algunos foros eso es demasiado.
Totalmente. Incluso si estuviéramos hablando de 90 minutos de inactividad independiente frente a 5 minutos separados, todavía probablemente no pensaría que el cambio valiera la pena, aunque probablemente haría las actualizaciones a última hora de la noche en lugar de convenientemente a la mitad del día si tomara tanto tiempo. No somos una plataforma de negociación de acciones en tiempo real, somos un foro gratuito sobre videojuegos.
Con la configuración de 2 contenedores, significa que ni siquiera necesitas saber que debes hacer ese cambio simple. Y habría cero posibilidades de que comenzaras una actualización y luego te enteraras de que ya habías comenzado a actualizar postgres.
Pero he pasado cerca de 35 años viviendo en una shell.
Y ahora tengo un panel que automatiza esas actualizaciones de línea de comandos (y maneja las actualizaciones de postgres y un montón de otras cosas).
Pero no arregles lo que no está roto, y entiendo que mover cosas y potencialmente romper cosas da miedo.
Yo mismo empecé con Slackware, simplemente no veo el mantenimiento del foro como un proyecto divertido y quiero que desaparezca para poder seguir dándome cabezazos contra la pared intentando que Google Home se integre con Home Assistant (o cualquier otra cosa que me apetezca esa semana).