Mejores prácticas para un servidor de almacenamiento de aplicaciones web (con un presupuesto)

Question

Me gustaría configurar un servidor de almacenamiento intermedio para una aplicación de Rails. Yo uso git & github, Cap, y tengo un VPS con Apache/Passenger. Tengo curiosidad sobre las mejores prácticas para una configuración de etapas, tanto en cuanto a la configuración del servidor de transición como a los procesos para interactuar con él. Sé que debería ser lo más idéntico posible al servidor de producción, pero restringir el acceso público limitará eso, por lo que me gustaría que me ofrezcan consejos sobre cómo protegerlo solo para mi uso.

Otra pregunta específica sería si podría simplemente crear un host virtual en el VPS, para que el servidor de transición pueda residir junto al de producción. Aunque tengo la sensación de que puede haber razones para evitar esto.

Answer 1

baratos y de fácil respuesta:

1) Punto staging.domainname.com en su VPS.

2) Agregue un host virtual para la puesta en escena, señalando la copia provisional de la aplicación.

3) Agregue una configuración de entorno provisional. (¿Sabía que podría definir nuevos entornos en Rails? Fun stuff!) Creo que esto es tan simple como copiar production.rb a staging.rb y ajustar según sea necesario, además de actualizar database.yml.

4) En ActionController, añadir en el código similar al siguiente

if (ENV["RAILS_ENV"] == "staging") 
    before_filter :verifies_admin 
    end 

Dónde verifies_admin puede ser cualquier cosa que desee. Sugiero usar autenticación básica HTTP, barata y fácil.

def verifies_admin 
    authenticate_or_request_with_http_basic do |username, password| 
    username == "foo" && password == "bar" 
    end 
end 

Tenga en cuenta que esto puede Bork su conexión a ese sitio de pago si están haciendo las peticiones entrantes a que, aunque eso es lo suficientemente simple para fijar (sólo tiene que desactivar la before_filter para los controladores y/o acciones apropiadas .)

Mejor respuesta:

1) comprar un segundo VPS configurados de la misma imagen que su VPS regular, y/o configurados de la misma instalación-de-la-bare metal guión (I como Capistrano & Deprec para esto).

2) Point staging.domainname.com en él.

3) De lo contrario, es lo mismo que la otra opción.

cosas en que pensar:

1) ¿Debo tener una base de datos provisional así? Probablemente, especialmente si va a probar cambios de esquema.

2) ¿Debo tener alguna facilidad para mover datos entre los sistemas de producción y etapas?

3) ¿Puede una falla catastrófica de mi aplicación de etapas eliminar la aplicación principal? La mejor esperanza es que la respuesta es no.

Answer 2

Supongo que depende de si el servidor provisional debe ser accesible por cualquier persona que no sea usted. Si otras personas necesitan poder acceder a él, entonces necesitaría otro pequeño segmento en alguna parte y luego puede usar htaccess o reglas de firewall para limitar quién tiene acceso a él. Si nadie más necesita acceder, le sugiero usar VMWare. Puede ejecutarlo en su propia máquina, o en una caja de repuesto que tenga, o en una PC muy económica. Utilizamos el VMWare Server 2 gratuito para nuestros servidores de pruebas de instalación y despliegue, y funciona de maravilla. También hace que sea muy fácil crear nuevos servidores de prueba simplemente duplicando la configuración de su VM base. Si está en una Mac puede usar VMWare Fusion, cuesta dinero, pero tengo que usarlo para probar IE.

Answer 3

Use dos servidores separados (VPS o lo que sea) tan similares como los puede hacer (hardware y software) en la imagen base. Automatice todos configuración de su entorno de producción para que nada se haga a mano. Use esa automatización para producir un servidor intermedio que sea idéntico a su entorno de producción. Mantenga la automatización para garantizar que ambos entornos permanezcan sincronizados y puedan replicarse bajo demanda.

Resuelve tanto su problema de puesta fuera de sincronía como su problema de escalado de primer orden.

En cuanto al costo, los VPS son baratos como chips. El número de fallas inductoras de tiempo de inactividad de producción que evitará al tener un servidor de etapas pagará por su entorno de ensayo en muy poco tiempo (a menos que realmente no gane dinero, en cuyo caso el tiempo de inactividad no es tanto problema y puedes volverte loco con la rotura).

Answer 4

Probablemente me peguen un tiro por decir esto, pero para sitios pequeños con presupuestos ajustados, no veo nada de malo en ejecutar el sitio de ensayo junto con el de producción.

Está utilizando Rails, Apache y Passenger. Configure diferentes configuraciones de Rails (y bases de datos), y configure cada uno como VirtualHost con nombre. Protege uno con htaccess. Cree un registro A de su dominio (montaje. *) Y apúntelo allí.

Claro, no están completamente aislados el uno del otro. Puede bloquear todo. Oops! Probablemente no importará. :)

Answer 5

Me gustaría añadir que Jamis Buck, quien creó Capistrano, también creó una joya específicamente para configurar entornos de varias etapas con Capistrano. Puedes hacerlo sin la gema, pero la gema lo hace aún más fácil. Puede encontrar su publicación en él con instrucciones aquí: http://weblog.jamisbuck.org/2007/7/23/capistrano-multistage

También hay un artículo muy útil en el libro de Programadores pragmáticos "Recetas de carriles avanzados" que le explica exactamente cómo configurarlo. Descubrí que las respuestas a esta publicación, combinadas con el libro Rails Recipes, hacen que sea increíblemente fácil de configurar.

StackOverflow no me deja agregar otro enlace, pero si busca en Google Advanced Rails Recipes, el libro es el primer resultado.