Tutorial de autohospedaje instantáneo: Docker, SQLite/Postgres, Caddy HTTPS y copia de seguridad

Guía práctica de autohospedaje instantáneo, que presenta la implementación de Docker/VPS, la selección de SQLite y Postgres, Caddy HTTPS, volúmenes persistentes, copia de seguridad y recuperación, y aceptación en línea.

Este tutorial de Instatic se centra en la tarea específica del título. Instatic autohospedado incluye aplicaciones, bases de datos, archivos cargados y servidores proxy inversos; Las copias de seguridad que solo cubren la base de datos dejarán archivos adjuntos y espacios en la configuración que no se pueden recuperar.

A continuación se muestra una demostración utilizando un entorno de prueba y datos revocables. Cuando se trate de cuentas, claves, control de máquinas, inversiones o comunicaciones de emergencia, se deberá realizar la confirmación manual.

Decide primero si SQLite o Postgres

Esta sección sólo trata sobre “Decidir primero entre SQLite o Postgres”. Guarde primero el estado actual y luego ejecute la prueba mínima. No cambie varias condiciones al mismo tiempo.

1
docker version

Para Instatic, se debe considerar este límite al juzgar los resultados: Instatic autohospedado involucra aplicaciones, bases de datos, archivos cargados y servidores proxy inversos; Las copias de seguridad que solo cubren la base de datos dejarán archivos adjuntos y espacios en la configuración que no se pueden recuperar.

Si los resultados no son repetibles, registre la versión, la entrada y los registros y luego limite el alcance de la prueba.

¿Por qué puedes elegir SQLite para una prueba independiente?

Se recomienda ejecutar en el siguiente orden:

  1. Verifique la versión y la fuente reales.
  2. Utilice una cuenta de prueba, un directorio de prueba o un dispositivo de prueba.
  3. Realizar una acción que se pueda deshacer.
  4. Guarde el resultado, el código de salida o la captura de pantalla.
  5. Revierta los cambios y vuelva a verificar.
1
Get-ChildItem -Force .

El estándar de finalización es “¿Por qué se puede elegir SQLite para una prueba en una sola máquina?” para obtener resultados verificables, en lugar de que el comando simplemente no informe un error.

¿Por qué evaluar Postgres para uso a largo plazo por parte de muchas personas?

Consultar artículos Criterios de aprobación Señal de parada
¿Por qué evaluar Postgres después de un uso prolongado por parte de muchas personas? Borrar el alcance de entrada, salida y permisos Herramienta amplía automáticamente el alcance de las operaciones
Fuente Puede devolverse al almacén oficial o datos originales Confíe en espejos desconocidos o en conclusiones de segunda mano
Seguridad No hay valor secreto en el registro Token, cookie o datos privados presentes
Recuperación Posibilidad de volver al estado anterior a la ejecución Sin métodos de copia de seguridad ni deshacer
1
docker volume ls

Cuando aparezca una señal de alto, reanude primero y no continúe con el siguiente paso.

Verifique las variables de entorno antes de iniciar Docker Compose

Esta sección solo trata sobre “Verificar las variables de entorno antes de iniciar Docker Compose”. Guarde primero el estado actual y luego ejecute la prueba mínima. No cambie varias condiciones al mismo tiempo.

1
git grep -n -I 'SECRET\|PASSWORD\|DATABASE_URL' -- .

Para Instatic, se debe considerar este límite al juzgar los resultados: Instatic autohospedado involucra aplicaciones, bases de datos, archivos cargados y servidores proxy inversos; Las copias de seguridad que solo cubren la base de datos dejarán archivos adjuntos y espacios en la configuración que no se pueden recuperar.

Si los resultados no son repetibles, registre la versión, la entrada y los registros y luego limite el alcance de la prueba.

Vincular solo el puerto de la aplicación a la dirección de loopback

Se recomienda ejecutar en el siguiente orden:

  1. Verifique la versión y la fuente reales.
  2. Utilice una cuenta de prueba, un directorio de prueba o un dispositivo de prueba.
  3. Realizar una acción que se pueda deshacer.
  4. Guarde el resultado, el código de salida o la captura de pantalla.
  5. Revierta los cambios y vuelva a verificar.
1
netstat -ano

El estándar de finalización es “vincular únicamente el puerto de la aplicación a la dirección de loopback” para obtener un resultado verificable, en lugar de que el comando simplemente no informe un error.

Verifique el registro de migración después del primer inicio

Consultar artículos Criterios de aprobación Señal de parada
Verifique el registro de migración después del primer inicio Borrar el alcance de entrada, salida y permisos La herramienta amplía automáticamente el alcance de las operaciones
Fuente Puede devolverse al almacén oficial o datos originales Confíe en espejos desconocidos o en conclusiones de segunda mano
Seguridad No hay valor secreto en el registro Token, cookie o datos privados presentes
Recuperación Posibilidad de volver al estado anterior a la ejecución Sin métodos de copia de seguridad ni deshacer
1
docker compose logs --tail 100

Cuando aparezca una señal de alto, reanude primero y no continúe con el siguiente paso.

Crear contenido de prueba y cargar un archivo adjunto

Esta sección sólo trata de “crear contenido de prueba y cargar un archivo adjunto”. Guarde primero el estado actual y luego ejecute la prueba mínima. No cambie varias condiciones al mismo tiempo.

1
docker compose ps

Para Instatic, se debe considerar este límite al juzgar los resultados: Instatic autohospedado involucra aplicaciones, bases de datos, archivos cargados y servidores proxy inversos; Las copias de seguridad que solo cubren la base de datos dejarán archivos adjuntos y espacios en la configuración que no se pueden recuperar.

Si los resultados no son repetibles, registre la versión, la entrada y los registros y luego limite el alcance de la prueba.

Puertos de aplicaciones proxy solo Caddy

Se recomienda ejecutar en el siguiente orden:

  1. Verifique la versión y la fuente reales.
  2. Utilice una cuenta de prueba, un directorio de prueba o un dispositivo de prueba.
  3. Realizar una acción que se pueda deshacer.
  4. Guarde el resultado, el código de salida o la captura de pantalla.
  5. Revierta los cambios y vuelva a verificar.
1
caddy validate --config Caddyfile

El criterio de finalización es que “Caddy sólo actúa como proxy de los puertos de la aplicación” y obtiene resultados verificables, en lugar de que el comando no informe errores.

HTTPS normal no significa que la aplicación sea segura

Consultar artículos Criterios de aprobación Señal de parada
HTTPS normal no significa que la aplicación sea segura Los rangos de entrada, salida y permisos son claros Las herramientas amplían automáticamente el alcance de las operaciones
Fuente Puede devolverse al almacén oficial o datos originales Confíe en espejos desconocidos o en conclusiones de segunda mano
Seguridad No hay valor secreto en el registro Token, cookie o datos privados presentes
Recuperación Posibilidad de volver al estado anterior a la ejecución Sin métodos de copia de seguridad ni deshacer
1
curl.exe -I https://example.com

Cuando aparezca una señal de alto, reanude primero y no continúe con el siguiente paso.

La copia de seguridad de la base de datos y la copia de seguridad de archivos se realizan por separado.

Esta sección solo trata sobre la “ejecución separada de la copia de seguridad de la base de datos y la copia de seguridad de archivos”. Guarde primero el estado actual y luego ejecute la prueba mínima. No cambie varias condiciones al mismo tiempo.

1
docker volume ls

Para Instatic, se debe considerar este límite al juzgar los resultados: Instatic autohospedado involucra aplicaciones, bases de datos, archivos cargados y servidores proxy inversos; Las copias de seguridad que solo cubren la base de datos dejarán archivos adjuntos y espacios en la configuración que no se pueden recuperar.

Si los resultados no son repetibles, registre la versión, la entrada y los registros y luego limite el alcance de la prueba.

Realizar un simulacro de recuperación de directorio vacío

Se recomienda ejecutar en el siguiente orden:

  1. Verifique la versión y la fuente reales.
  2. Utilice una cuenta de prueba, un directorio de prueba o un dispositivo de prueba.
  3. Realizar una acción que se pueda deshacer.
  4. Guarde el resultado, el código de salida o la captura de pantalla.
  5. Revierta los cambios y vuelva a verificar.
1
docker compose config

El estándar de finalización es “realizar un simulacro de recuperación de directorio vacío” y obtener resultados verificables, en lugar de que el comando simplemente no informe un error.

Se corrigió la etiqueta actual antes de actualizar la imagen.

Consultar artículos Criterios de aprobación Señal de parada
Se corrigió la etiqueta actual antes de actualizar la imagen Borrar el alcance de entrada, salida y permisos La herramienta amplía automáticamente el alcance de operación
Fuente Puede devolverse al almacén oficial o datos originales Confíe en espejos desconocidos o en conclusiones de segunda mano
Seguridad No hay valor secreto en el registro Token, cookie o datos privados presentes
Recuperación Posibilidad de volver al estado anterior a la ejecución Sin métodos de copia de seguridad ni deshacer
1
docker compose images

Cuando aparezca una señal de alto, reanude primero y no continúe con el siguiente paso.

No reiniciar repetidamente cuando falla la migración

Esta sección solo trata sobre “No reiniciar repetidamente cuando falla la migración”. Guarde primero el estado actual y luego ejecute la prueba mínima. No cambie varias condiciones al mismo tiempo.

1
docker compose logs --since 10m

Para Instatic, se debe considerar este límite al juzgar los resultados: Instatic autohospedado involucra aplicaciones, bases de datos, archivos cargados y servidores proxy inversos; Las copias de seguridad que solo cubren la base de datos dejarán archivos adjuntos y espacios en la configuración que no se pueden recuperar.

Si los resultados no son repetibles, registre la versión, la entrada y los registros y luego limite el alcance de la prueba.

Cómo localizar la concurrencia en errores de bloqueo de SQLite

Se recomienda ejecutar en el siguiente orden:

  1. Verifique la versión y la fuente reales.
  2. Utilice una cuenta de prueba, un directorio de prueba o un dispositivo de prueba.
  3. Realizar una acción que se pueda deshacer.
  4. Guarde el resultado, el código de salida o la captura de pantalla.
  5. Revierta los cambios y vuelva a verificar.
1
docker compose logs | Select-String -Pattern 'locked'

El estándar de finalización es obtener resultados verificables sobre “Cómo localizar la concurrencia en errores de bloqueo de SQLite”, en lugar de que el comando no informe un error.

Solución de problemas jerárquicos de falla de conexión de Postgres

Consultar artículos Criterios de aprobación Señal de parada
Solución de problemas jerárquicos de fallas de conexión de Postgres Borrar rangos de entrada, salida y permisos La herramienta amplía automáticamente el alcance de las operaciones
Fuente Puede devolverse al almacén oficial o datos originales Confíe en espejos desconocidos o en conclusiones de segunda mano
Seguridad No hay valor secreto en el registro Token, cookie o datos privados presentes
Recuperación Posibilidad de volver al estado anterior a la ejecución Sin métodos de copia de seguridad ni deshacer
1
2
docker compose ps
docker compose logs --tail 50

Cuando aparezca una señal de alto, reanude primero y no continúe con el siguiente paso.

Lista de verificación de recuperación final después de conectarse

Esta sección sólo trata de la “lista de verificación de recuperación final después de la entrada en funcionamiento”. Guarde primero el estado actual y luego ejecute la prueba mínima. No cambie varias condiciones al mismo tiempo.

1
docker compose config --quiet

Para Instatic, se debe considerar este límite al juzgar los resultados: Instatic autohospedado involucra aplicaciones, bases de datos, archivos cargados y servidores proxy inversos; Las copias de seguridad que solo cubren la base de datos dejarán archivos adjuntos y espacios en la configuración que no se pueden recuperar.

Si los resultados no son repetibles, registre la versión, la entrada y los registros y luego limite el alcance de la prueba.

Cómo localizar errores de permisos en el directorio de carga

Se recomienda ejecutar en el siguiente orden:

  1. Verifique la versión y la fuente reales.
  2. Utilice una cuenta de prueba, un directorio de prueba o un dispositivo de prueba.
  3. Realizar una acción que se pueda deshacer.
  4. Guarde el resultado, el código de salida o la captura de pantalla.
  5. Revierta los cambios y vuelva a verificar.
1
docker compose exec app id

El estándar de finalización es “Cómo localizar el error de permiso del directorio de carga” para obtener un resultado verificable, en lugar de que el comando simplemente no informe un error.

¿Es creíble la IP real del cliente después de la generación inversa?

Consultar artículos Criterios de aprobación Señal de parada
¿Es confiable la IP del cliente real después de la generación inversa? Borrar rangos de entrada, salida y permisos La herramienta amplía automáticamente el alcance de las operaciones
Fuente Puede devolverse al almacén oficial o datos originales Confíe en espejos desconocidos o en conclusiones de segunda mano
Seguridad No hay valor secreto en el registro Token, cookie o datos privados presentes
Recuperación Posibilidad de volver al estado anterior a la ejecución Sin métodos de copia de seguridad ni deshacer
1
docker compose logs --tail 100

Cuando aparezca una señal de alto, reanude primero y no continúe con el siguiente paso.

Confirme que la copia de seguridad sea legible antes de eliminar la instancia de prueba

Esta sección solo trata de “confirmar que la copia de seguridad sea legible antes de eliminar la instancia de prueba”. Guarde primero el estado actual y luego ejecute la prueba mínima. No cambie varias condiciones al mismo tiempo.

1
Get-Item .\backup\* -ErrorAction SilentlyContinue

Para Instatic, se debe considerar este límite al juzgar los resultados: Instatic autohospedado involucra aplicaciones, bases de datos, archivos cargados y servidores proxy inversos; Las copias de seguridad que solo cubren la base de datos dejarán archivos adjuntos y espacios en la configuración que no se pueden recuperar.

Si los resultados no son repetibles, registre la versión, la entrada y los registros y luego limite el alcance de la prueba.

Comprobación final de Instatic

  • Se documentan las versiones y fuentes utilizadas.
  • Se han aislado las entradas de prueba y los datos formales.
  • Los comandos, configuraciones y salidas reales pueden corresponder.
  • La ruta fallida se probó activamente al menos una vez.
  • Las claves, cuentas y datos privados no ingresan a Git ni a logs.
  • Existen acciones claras para actualizar, detener y reanudar.

Si aún no puede explicar cómo se producen los resultados, continúe manteniendo Instatic en el entorno de prueba sin extender los permisos ni reemplazar el proceso estable existente.