¿Cómo hacen los desarrolladores posibles implementaciones de tiempo de inactividad cero?

Hay varias cosas involucradas en hacer que esto suceda. Algunas de las implementaciones requerirán una planificación cuidadosa y, por supuesto, la naturaleza de la base de datos de back-end puede complicar un poco las cosas.

En primer lugar, su arquitectura de software debe admitir múltiples servidores de aplicaciones que tengan un equilibrio de carga, de modo que las operaciones puedan eliminar un servidor de aplicaciones sin afectar la disponibilidad de los sitios y sin perder las sesiones de los usuarios. Obviamente. Esto significa que el estado de la sesión, la seguridad y el estado de la aplicación deben diseñarse para que funcionen de manera que los usuarios no se den cuenta cuando se retira brevemente un servidor.

La nueva versión del software se implementa en la aplicación fuera de línea y el servidor vuelve a funcionar mediante el equilibrador de carga. Cada servidor se actualiza a su vez.

Hay otras estrategias también. Por ejemplo, el uso de servidores SOLR con equilibrio de carga para mantener el estado de búsqueda y profundizar.

El personal de operaciones debe tener un buen procedimiento bien documentado para actualizar el software.

Puede surgir un problema cuando una base de datos de fondo tiene que cambiar y el código o esquema del cliente no está bien escrito. El código del cliente debe escribirse para que no sea sensible a los cambios de esquema. El esquema debe estar bien planeado. Debe haber vistas y procedimientos almacenados que actúen como una fachada para proteger el código de ser sensible a los cambios en la base de datos.

Bien hecho, no hay nada que impida a una tienda implementar un nuevo código todos los días sin tener ningún efecto en los clientes.

Si ya ha escrito su código y ahora está haciendo esta pregunta, entonces buena suerte.

En primer lugar, ninguna implementación de tiempo de inactividad en plataformas que no permita la conexión en caliente de archivos y componentes requeriría implementaciones de color verde azulado . Esto permite que el tráfico llegue a algunos servidores mientras que otros se actualizan con un nuevo código y luego se intercambian. Existen diferentes formas de esta implementación basadas en la arquitectura.

Sin embargo, si no está implementando código y todo lo que necesita hacer es migrar las bases de datos, dependiendo del tipo de base de datos, una característica que puede usarse es la replicación. Cree o copie su nueva instancia, active la replicación para que ambas bases de datos estén sincronizadas, actualice la configuración del código de su aplicación después de que se sincronicen. Una vez más, suponiendo que esté utilizando una de esas plataformas web típicas como dot net y creo que node, el servidor necesitará un reinicio y, por lo tanto, tendrá tiempo de inactividad, vuelva a visitarlo en azul y verde para solucionarlo.

Es sorprendente ver que la mayoría de las respuestas aquí ven un tiempo de inactividad cero como un problema de implementación o devops.

Sin embargo, es mucho más que un simple problema devops. Entremos en más detalles.

El reto

Es probable que la mayoría de las aplicaciones web actuales tengan 3 capas implementadas por separado.

IU, API y datos.

Ahora digamos que la versión implementada actualmente es 1.0 para todas las capas y la nueva versión será 2.0.

En otras palabras, necesitamos actualizar UI 1.0, API 1.0, Data 1.0 a UI 2.0, API 2.0 y Data 2.0.

Si UI 1.0 no es compatible con API 2.0 o API 1.0 no es compatible con Data 2.0, no hay forma de que pueda lograr un tiempo de inactividad cero con cualquier enfoque de implementación o desarrollo que adopte. ¿Por qué?

Digamos que algunos usuarios están utilizando su aplicación web en el momento en que intenta actualizar. Han abierto la aplicación web cuando era 1.0. Tienen UI1.0 abierto.

Ahora tiene API 1.0 ejecutándose y disponible y desea cambiar a API 2.0. Pero UI 1.0 no es compatible con API 2.0, por lo que UI 1.0 no puede usar API2.0.

Además, su API 2.0 no funcionará con Data 1.0, por lo que si necesita API 2.0, primero debe actualizar Data 1.0 a Data 2.0.

Creo que el desafío es claro. Sin lograr la compatibilidad con versiones anteriores entre algunas de las capas, la actualización en vivo es imposible . La compatibilidad con versiones anteriores entre capas es la clave para lograr un tiempo de inactividad cero.

Compatibilidad con la interfaz de usuario y la API : este problema se puede resolver con un equilibrador de carga configurado para enrutar todas las solicitudes de un solo cliente a un único servidor. Eso significaría que UI 1.0 sigue usando API 1.0 hasta que API1.0 esté disponible. Otra solución será respaldar siempre las API antiguas para la próxima versión. los soportes hacia atrás siempre tienen que ser para 1 lanzamiento. Puede marcar estas API en desuso y en la rama principal tan pronto como se realice el lanzamiento.

Compatibilidad con API y datos : esto se puede lograr haciendo que la API sea compatible con los datos anteriores o haciendo que los datos sean compatibles con los anteriores. En mi opinión, mantener los datos compatibles con versiones anteriores es una opción más simple.

Pronto trataré de compartir todos los detalles de cómo se pueden lograr.

Trabajo en ReactiveOps donde nos especializamos en DevOps-as-a-Service. Uno de nuestros ingenieros, Eric Malloy, recientemente abordó esto en una publicación de blog:

“Los equipos de ingenieros de operaciones solían manejar los esfuerzos de implementación manualmente o mediante secuencias de comandos, un proceso en vivo que podría llevar horas, si no toda la noche. El revolucionario objeto de implementación de Kubernetes, por otro lado, tiene características incorporadas que automatizan este esfuerzo de operaciones.

Con las aplicaciones de alto tráfico, no hay necesidad de preocuparse por mantener el tiempo de actividad durante una implementación. Los objetos de implementación pueden definir una estrategia de implementación donde .spec.strategy.type==RollingUpdate se especifica en el manifiesto. De manera predeterminada, .spec.strategy.rollingUpdate.maxUnavailable se establece en 1 para que no más de uno de los pods en el ‘ReplicaSet’ no esté disponible durante el ‘RollingUpdate’. Durante el cambio de una versión a otra, Kubernetes se asegura de que al menos una instancia esté disponible para recibir solicitudes.

¿Preocupado por un aumento en el tráfico durante el ‘RollingUpdate’? Tampoco es un problema ya que el objeto de implementación tiene .spec.strategy.rollingUpdate.maxSurge , un campo opcional que proporciona más que los pods predeterminados definidos en el conjunto de réplicas.

La implementación de tiempo de inactividad cero de Kubernetes alivia las preocupaciones sobre las ventanas de mantenimiento, haciendo que los retrasos de implementación y el tiempo de inactividad sean cosa del pasado, y ahorre dinero en el proceso “.

Espero que esto haya sido útil. Si desea obtener más información, puede leer la publicación completa del blog aquí: Kubernetes y la era de la implementación de tiempo de inactividad cero

He leído un documento técnico maravilloso, que proporciona información valiosa sobre el Contenedor Docker y cómo usarlo para la implementación de tiempo de inactividad cero o la implementación continua.

también le proporcionará conocimiento y claridad sobre cómo obtener una implementación de tiempo de inactividad cero con y sin contenedores. Puede registrarse aquí para obtener el documento técnico https://www.imaginea.com/zero-do …