Unha das nosas tarefas nun proxecto de software é actualizalo en produción de cando en vez — o deployment, que se di en inglés.
Cando escribiamos software que se distribuía en discos, o proceso de actualización era moi simple: gravabamos o programa nun disquete, mandabámolo a duplicar, e despois distribuíase ás tendas ou aos usuarios. Hoxe en día, porén, case todo o software traballa en Internet ou nun teléfono móbil, así que as estratexias son diferentes. Nesta Folla heivos citar varias maneiras de publicar unha nova versión dun sistema que traballa na nube.
“Estou seguro de que imos rematar a construción antes do solpor!”
A primeira maneira consiste en deter completamente o servizo, poñer un letreiriño que di que «o sistema está desactivado por mantemento ata as seis da tarde» e despois ter un imprevisto e tardar dúas semanas en activar o sistema novo. Esta é a estratexia que un usa cando odia aos usuarios e non ten especial interese en que ninguén use o servizo. As súas desvantaxes son tan obvias que só vou dicir que facelo así hoxe en día é ridículo e propio de xente ridícula. Non me sexades ridículos.
Neste ano no que estamos, a maneira correcta de actualizar un servizo é facelo sen paralo, evitando o downtime, e as infraestruturas modernas fan que isto sexa moi doado de acadar.
O requisito indispensable é ter o servizo replicado entre varios servidores detrás dun balanceador de carga. Isto non só axuda a publicar novas versións senón que aumenta a fiabilidade e capacidade de carga do servizo. Xa hai anos que non temos “o servidor”: hoxe en día incluso «Conxelados Suárez» ten redundancia N+2 e vós, expertos profesionais da informática, non debiades ser menos ca «Conxelados Suárez».
Tendo un servizo replicado, a estratexia para actualizalo sen paralo completamente é obvia: actualizade unha réplica de cada vez mentres o resto segue a funcionar. Para acadar isto é necesario que usedes formatos de almacenamento e protocolos de comunicación compatibles para adiante e para atrás, co obxectivo de que dúas versións consecutivas do voso programa se poidan comunicar.
A maneira máis simple de actualizar os vosos servidores un a un é, simplemente, facelo. Actualizades unha réplica e ollades a monitorización de maneira obsesiva a ver se hai erros. Despois dun tempo indo todo ben actualizades unhas poucas réplicas máis e volvedes ollar, e así ata que todas elas estean actualizadas.
Esta é unha maneira perfectamente aceptable de facelo se só tedes recursos dabondo para servir en produción. Se podedes permitirvos ter unhas poucas réplicas adicionais, podedes facer un ambiente de preprodución que actualizades primeiro, despois botades un tempo probándoo e tratando de rompelo e, se funciona ben, pasades a actualizar a produción.
Se vos sobran moitos servidores podedes facer unha cousa moi xeitosa: ambiente verde e ambiente azul. A idea é que non tedes un ambiente de precualificación separado senón que os vosos servidores están divididos entre dous ambientes (un “verde” e outro “azul”) e só un deses ambientes está a servir tráfico de produción.
Cando queredes actualizar o voso servizo, primeiro instalades a actualización no ambiente que non está a servir produción (por exemplo, se o ambiente activo é o verde, actualizades o azul). Nese momento podedes usar o ambiente azul para as probas de preprodución.
Se todo vai ben, podedes configurar os balanceadores de carga para transferir o tráfico do ambiente verde ao azul, pero paseniñamente, co ollo sempre posto na monitorización. Se hai un problema podedes desfacer a migración moi doadamente pasando todo o tráfico outra vez ao ambiente verde.
Se todo vai ben, cando completedes a migración, o ambiente azul será o ambiente activo e o verde estará listo para aceptar a seguinte versión cando a queirades actualizar.
Espero que nunca poñades un letreiro de «este servizo ha regresar axiña»!
A ilustración desta Folla foi producida mediante intelixencia artificial.
1 comentario