Separar el desarrollo y la producción

hace 3 años 2 minutos leídos

A medida que una organización se vuelve más dependiente de Rock para las operaciones diarias, es común crear un entorno de desarrollo (o algunos podrían decir "staging") para poder probar nuevas ideas y lanzamientos recientes.

Recientemente, estábamos trabajando con una iglesia en un nuevo sitio web y nos encontramos con una situación que no era óptima. Su infraestructura se había configurado originalmente para que su servidor web de desarrollo se encuentra en el mismo VM como su instancia de producción de Rock. Queríamos tomarnos un tiempo para discutir por qué esto no es una buena idea en caso de que alguien más se encuentre considerando el mismo patrón.

Las razones por las que querrías separar tus entornos de desarrollo y producción se dividen en dos categorías: recursos compartidos y configuración compleja. Veamos cada una de ellas en detalle.

Recursos compartidos
La principal preocupación de ejecutar tanto la producción como el desarrollo en un solo servidor se centra en los recursos del servidor. Los entornos de desarrollo se crean porque se quieren hacer cosas en ellos que no querría hacer en producción. Por otro lado, los entornos de producción son críticos para las operaciones diarias de su organización. Estas dos misiones son fundamentalmente opuestas.

Durante un proyecto de sitio web incluimos un paso para considerar si el entorno actual tiene suficiente capacidad para soportar la carga del nuevo sitio. Dado que su socio actual no mantiene un mapa de la arquitectura de la iglesia, no había ninguna indicación de que esta práctica estuviera en marcha. Sí supimos que había algunas preocupaciones actuales sobre el rendimiento del registro de fin de semana.

Considere este último punto: hay cuestiones de escalado centradas en el rendimiento de la facturación. La evaluación del estado actual y las posibles correcciones se hace mucho más difícil sabiendo que una VM está sirviendo dos roles. Si vuelve a los registros de rendimiento de Azure y mira el uso de la CPU y la memoria durante los períodos de registro, no hay forma de saber si la carga proviene de la instancia de IIS de producción o de la instancia de desarrollo. de la instancia de IIS de producción o de la instancia de desarrollo. Tal vez alguien estaba usando o probando algo en la máquina de desarrollo al mismo tiempo.

Configuración compleja
Si los recursos compartidos no fueran suficientes para considerar esto como una mala idea, también tenemos que ver la configuración necesaria para ejecutar dos instancias de Rock en la misma VM. Esto principalmente Esto se reduce principalmente a los enlaces IIS necesarios para separar el tráfico que entra en una dirección IP pero que es atendido por dos o más instancias IIS. En esta configuración, cada nombre de host necesita tener dos enlaces (uno para HTTP y otro para HTTPS).

Con una instalación normal de IIS todo el tráfico se envía a una sola instancia de IIS. Esto hace que añadir nuevos nombres de host (por ejemplo, para un nuevo micrositio que acabas de añadir) sea fácil. Sólo tiene que ajustar su DNS y ahora puede estar seguro de que Rock recibirá ese tráfico. Cuando se ejecutan múltiples instancias, ahora tendrá que añadir también dos nuevas reglas de enlace a la instancia de producción de IIS.

Si bien estos ajustes no son ciencia espacial, tampoco son esperados y representan otro punto de falla.

Conclusión:
Dividir los entornos de producción y de desarrollo es fundamental para un entorno de Rock estable y predecible. Esto es especialmente cierto cuando se considera que una VM bursátil de Azure capaz de ejecutar un entorno de desarrollo puede obtenerse por unos 30 dólares al mes.

En Triumph siempre nos apasiona hacer las cosas teniendo en cuenta las mejores prácticas. También nos apasiona compartir estas mejores prácticas con la comunidad rockera para para ayudar a educar y ayudar como una forma de retribución.

A trabajar

¿Listo para dar vida a tus ideas de Rock RMS?

Estamos aquí para ayudar.

Contacto