Disculpas si esto ya se ha preguntado, busqué pero no vi el escenario exacto que estoy planeando (o me lo perdí, pero quiero asegurarme de hacerlo bien ya que nunca lo he hecho antes).
Todavía estoy en la 18 (que es donde empecé; nunca he actualizado el sistema operativo Linux, solo las actualizaciones de seguridad), así que en algún momento pronto pasaré a la 22. Todo lo que he leído aquí sugiere que migrar a una nueva instalación es mucho más inteligente que actualizar la existente porque potencialmente hay una multitud de problemas aleatorios que pueden o no ocurrir, pero no vale la pena el riesgo porque si ocurren, es solo una molestia inútil.
Leí esta guía Move your Discourse Instance to a Different Server pero se refiere a mover de un servidor a DigitalOcean (o viceversa) lo que hace que la instantánea no sea aplicable, mientras que yo planeo mover de una instancia existente de DigitalOcean Droplet a una nueva (lo cual he visto múltiples referencias de que funciona bien y es ideal para una actualización).
Entonces, mi pregunta para una transferencia de DO > DO es, ¿puedo simplemente apagar mi droplet, tomar una instantánea, iniciar un nuevo Droplet en Ubuntu actualizado que quiero, cargar la instantánea y listo (ajustar el registro DNS para el dominio, etc.)? Básicamente, ¿evitando la “reinstalación completa de Discourse” que detalla la guía? Entiendo que las instantáneas se supone que son una copia idéntica 1:1 de la instalación en el Droplet, a diferencia de la copia de seguridad que es específicamente de tu configuración de Discourse, que requiere una instalación completa para utilizarla realmente. ¿Entiendo esto correctamente? ¿Algún inconveniente aparte de un tiempo de inactividad más prolongado?
tl;dr: ¿puedo simplemente tomar una instantánea, hacer un nuevo droplet actualizado, cargar la instantánea y listo?
Espero no estar totalmente equivocado, pero restaurar una instantánea de la 18 en la 22 te revertirá a la 18, porque la instantánea es una copia 1:1 de todo el droplet.
Para mí, crear un droplet totalmente nuevo es siempre la última opción, porque necesito instalar todo lo que Ubuntu (o cualquier otro SO) necesita, incluido el sistema de correo, etc.
Estoy totalmente seguro de que es solo otra tarea trivial para quienes saben, pero después de 10 años nunca he aprendido a iniciar un droplet funcional nuevo fácilmente.
Simplemente haz una copia de seguridad de tu sitio y de app.yml, crea una nueva instancia (droplet) con la nueva versión del SO, reasigna la IP a tu nueva instancia (para que el dominio apunte al lugar correcto y nuevo), instala Discourse (puedes salir del asistente, actualizar app.yml y luego reconstruir) e importa tu copia de seguridad.
Todo este proceso debería tomar menos de una hora.
Este proceso nunca toca tu instancia existente, así que si todo falla, ¿es muy fácil revertir?
Si se pasa de una versión LTS del sistema operativo a la siguiente versión, esperaría un proceso bastante sencillo. Por lo tanto, podría hacer una copia de seguridad, por supuesto, y descargarla por seguridad, por supuesto, y luego intentar la actualización del sistema operativo. Si no funcionara, podría intentar un sistema operativo nuevo.
Pero al hacer esto, tendría más tiempo de inactividad del foro.
Soy un poco reacio a migrar a una instancia nueva, principalmente porque necesitaría actualizar el DNS y esperar a que se propague. Aunque veo que la publicación anterior dice que podría llevarme mi dirección IP conmigo, lo cual es bueno, y eso elimina esta reticencia.
De hecho, cambiando mi respuesta por completo, si puedo llevar mi dirección IP a una instancia nueva, eso sería preferible. Posiblemente no todos los proveedores lo permitan. Posiblemente para algunos proveedores se perdería una IP gratuita y se empezaría a pagar por la IP, porque se ha movido aunque no haya cambiado.
Una mitigación muy sencilla para esto es simplemente establecer un TTL muy bajo (o cambiar los servidores de nombres por uno que lo admita). De esa manera, los registros caducan en menos tiempo del que se tarda en reconstruir.
Puedes usar una IP estática (no recuerdo cómo la llama ahora DigitalOcean). En redes, puedes obtener una IP nueva y luego mapearla al droplet antiguo. Luego cambias el DNS y dejas que se propague. Cuando estés listo para moverte al nuevo servidor, simplemente cambias la IP para que apunte al nuevo servidor. Sucede inmediatamente y si algo sale mal, puedes simplemente volver a cambiarla.
Tiene sentido, ni siquiera estaba pensando en que se transfiriera el SO.
Iniciar un nuevo droplet sería mi última opción también, ya que nunca he movido droplets antes (este es el primero que tengo) ni he actualizado el SO antes, pero todas las guías que veo aquí, en general, parecen recomendar hacerlo de esa manera en lugar de simplemente actualizar el droplet en el que estás, así que pensé que podría seguir a la mayoría si ambas formas tienen riesgos y no he hecho ninguna de las dos.
Mi pensamiento también es que si la actualización sale totalmente mal de alguna manera ahora tienes el tiempo de inactividad del intento, tienes el tiempo de inactividad mientras te ves obligado a intentar arreglar el problema (o rendirte y crear uno nuevo), en comparación con el nuevo que potencialmente no funciona mientras tu original permanece en funcionamiento e intacto. No sé por qué saldría mal, pero buscar en meta aquí tiene MUCHA gente diciendo que salió mal, o enlaces que dicen que nunca recomendarían esa forma (además de las guías oficiales aquí y DigitalOcean que lo sugieren).
Supongo que lo intentaré este fin de semana.
IPs reservadas (aparentemente antes llamadas Floating IPs).
Correcto: si creas un archivo app.yml vacío (por ejemplo, con touch app.yml en el directorio de contenedores) y pegas (¡con cuidado!) el contenido de tu otro servidor, no necesitas ejecutar ./discourse-setup en absoluto.
Un problema que me afectó esta semana fue la configuración de mi correo electrónico: asegúrate de que tu servicio de correo electrónico no requiera la IP exacta desde la que estás llamando. Si lo hace, asegúrate de actualizar esa configuración (en tu proveedor de servicios).
Es lo más seguro, sin embargo. Si lo rompes, tu sitio antiguo sigue funcionando. No hay riesgo alguno.
Hay un tema sobre eso. Puedes copiar tu archivo yml y las cosas de let’s encrypt e incluso ver que funciona cambiando tu DNS local para que apunte al nuevo servidor.
Y si tienes tus copias de seguridad en S3, puedes dormir tranquilo sabiendo que si algo sale muy mal, puedes lanzar un nuevo servidor y restaurar una copia de seguridad en unos 30 minutos.
Mi única preocupación real no era tanto moverlo, sino pasar por toda la configuración y de alguna manera estropear alguna configuración, ya sea el servicio de correo electrónico o letsencryp o lo que sea, y solo darme cuenta más adelante una vez que todo se desmorone. Lo que obviamente no es un problema si simplemente puede leer mi app.yml antiguo, así que eso está bien.
No estoy del todo seguro de lo que esto significa, pero no creo que lo haga… Tengo Mailgun y revisando todos los registros allí/DNS en GoDaddy, nada parece estar vinculado a ninguna IP específica.
De acuerdo, suena bastante fácil, lo intentaré esta semana. Quizás actualice a un Droplet mejor al mismo tiempo.
No puedo encontrar el tema que estoy seguro de que existe. En resumen, configura las copias de seguridad en s3 en la configuración de tu entorno, rsync sobre /var/discourse o tal vez solo los directorios ssl y letsencrypt y containers, y luego reconstruye.