How does hot deployment exactly work


#1

Hi,

I have a Zato 3 instance, where the <zato>/server1/pickup/incoming/services directory is a git checkout.
During a zato servers restart, my services got restored to older version on one of the 2 zato servers.
On the filesystem in <zato>/server2/work/hot-deploy/current/*.py, I found outdated versions of the services.

How exactly is Zato hot-deploy working? I know that in ODB there is a copy of the services. So, what is the order of events during restart (and during hot-deploy)? Is the code in ODB in some way involved during this process?

Regards, Jan


#2

Hi @jjmurre,

when a server is running and you place a file into ./pickup/incoming/services, this file will be saved to ODB and all servers (including the current one) are notified of a new Python module that can be possibly deployed.

Each server then takes this package from ODB and saves it to ./work/hot-deploy/current, having first backed up the contents of that directory.

Then, the file/module is imported from ./work/hot-deploy/current - if it contains services, all the relevant internal server in-RAM structures are updated and the services can be used.

For that to work the server must be running - only then is it able to notice that a file/module changed, only then does it receive events about a changed file in ./pickup/incoming/services.

If a server is stopped, a git update made, then the starting server does not know anything about the new files, no events are fired towards it because it is not running, so it continues to use the previously deployed files/modules.


#3

Hi @dsuch,

Tx. for the clear explanation, good to know how this works! Esp. that is first goes into ODB and then will be picked up by the zato servers.

Regards, Jan


#4

One thing that also occurred to me is that you may want to try out the service-sources.txt file which contains directories in which the server may find services to be deployed.

You could perhaps devise configuration, possibly with some symlinks to your repository, that will let the server cover both of your cases - hot-deployment and regular static deployment of files from a well-known location.


#5

That’s a good idea. I wanted to try out this feature for a while, this is a nice occasion :slight_smile:

Regards, Jan


#6

Hi @jjmurre,

one of the benefits of current works on Python 3 support is that it will be possible to create symlinks pointing to actual code repositories from Zato pickup directories.

This will let you edit your code directly in the source code checkout and servers will hot-deploy it via the said symlinks instead of requiring you to maintain two copies of the same source code files.

Another change is that there will be an internal mechanism to allow for nested hot-deployment directories, e.g. merely letting Zato know what the top-level directory of your git repository clone is will suffice for hot-deployment to observe changes to any of the Python files below it. It will not be enabled for now but eventually, this will be possible too.


#7

This is good hear. We would immediately start using the sylink to repo approach…