2010-01-08 17 views
6

En un servidor de aplicaciones en el que algunos archivos de origen cambian con frecuencia, ¿Se recomienda el siguiente enfoque?AWS EC2- Sincronización de archivos de código fuente con S3: ¿es un enfoque adecuado?

Utilice un trabajo cron con S3tools para sincronizar los archivos fuente con el depósito privado S3 (cada 15 minutos, por ejemplo).

En el inicio del servidor: utilice la secuencia de comandos de datos de usuario para sincronizar con el depósito de orígenes para recuperar las últimas fuentes.

Ventajas: 1. No hay necesidad de conectar EBS para el servidor de aplicaciones sólo para ahorrar unos pocos archivos 2. configuración similar a todos los servidores de aplicaciones 3. Fuentes de copia de seguridad automática. 4. Como subproducto, distribuye código a múltiples servidores de aplicaciones automáticamente.

Desventajas: manteniendo el código fuente en S3 otro?

¿Qué opina de esta metodología? ¿Es esta la manera correcta de usar EC2 cuando el código fuente cambia con frecuencia (algunas veces al día) por favor, recomiende el mejor enfoque para ejecutar instancias EC2 donde las fuentes cambian a menudo.

Respuesta

2

Si va a ejecutar una gran cantidad de instancias de EC2, será menos esfuerzo sincronizarlas desde una ubicación central (es decir, sincronizar con un segmento privado, sincronizar servidores de aplicaciones desde ese segmento))

SIN EMBARGO, reconozca que las actualizaciones de un cubo S3 son atómicas solo en el nivel del objeto y, lo que es más importante, no se garantiza que sean consistentes inmediatamente (aunque recuerdo haber visto una nota reciente que el extremo consistencia después de la escritura).

Esto significa que los servidores de aplicaciones pueden cargar un conjunto de archivos nuevos que son internamente inconsistentes: algunos serán viejos, otros serán nuevos. Si esto es un problema para usted, entonces debe implementar un esquema que se cargue directamente a los servidores de la aplicación y asegure la coherencia del conjunto de cambios (tal vez al cargarlo en un directorio temporal que luego se renombra).

+0

Gracias, no estoy preocupado por la coherencia de lectura tras escritura. las escrituras en S3 ocurrirán solo después de que el archivo de código cambie durante la ejecución del cron, por lo que no es algo que ocurrirá al mismo tiempo que el servidor se reinicia y requiere sincronizar las fuentes de regreso al servidor. ¿Cuál es la mejor práctica para lograr la persistencia del código fuente en un servidor de aplicaciones en EC2? – Nir

4

Creo que es mejor utilizar un repositorio de código fuente adecuado, como Subversion o Git, en lugar de almacenar los archivos de origen en S3. De esta forma, puede tener una ubicación central para los archivos de origen y evitar los problemas de consistencia de actualización que kdgregory mencionó.

Puede colocar el repositorio fuente en uno de sus servidores fuera de EC2, o alojarlo en una instancia EC2 (asegúrese de que los archivos del repositorio estén en un volumen EBS en este último caso).

+0

No quiero involucrar a un servidor externo en la configuración. Quiero tener una configuración simple y confiable en la que el sistema vuelva a ponerse en forma automáticamente si algo sucede. Agregar un servidor externo pierde el encanto de la simplicidad y expone el sistema a la falla de un proveedor más. – Nir

+0

+1 para usar el control de fuente, en lugar de simplemente sobrescribir archivos en S3. ¿Qué sucede si desea retroceder a una versión anterior? Personalmente, no creo que almacenar el código fuente en un repositorio git privado (alojado en github, por ejemplo) tenga una mayor probabilidad de error que almacenarlo en un depósito de s3. Ningún servicio va a desaparecer en el corto plazo, y si lo hacen, seguramente lo sabrán. –

Cuestiones relacionadas