Find out how to simply transfer modernization resources when Green Screens Terminal Service is running in cloud environment and developer access is limited.
Green Screens Terminal (GST further in text) support screen and spool modernization through html templates and custom scripts.
When GST is used in internal company network it is not a problem. There are few approaches available.
- Web Admin console simple resource web explorer to transfer file by file which is not the best optimal way to do it.
- Another option is to give resources to the system admins to deploy them on GST resource directory. But that is also not the best approach. It really depends on security policy, responsibility policy etc.
- GST resources directory can be shared inside local network no matter if GST is running on Windows or Linux machine. So, anyone with directory credentials can change modernization resources.
The question is how to do it when GS service is running in Cloud Environment?!
Syncthing is royalty free opensource directory syncing tool written in GO with support for multiple platforms. It is just a single exe file which once started will run as a syncing service. There is embedded web-based administration console running on localhost used instead of desktop gui. Admin console is used for all setups including option for joining other computers to the running service based on unique ID.
Basic principle is very simple. Upon installation, Syncthing will create unique ID which should be exchanged between two remote instances to mutually authorize them for automatic synchronization. System works in various networks without too much hassle as it use auto-discovery service through STUN and TUN server protocols. Next step is to declare shared folder and that's it.
In cloud environment, GST use Docker Named Volume for data storage. That allows data to be accessed from host machine. We can install Syncthing as a secondary Docker image also attached to the same named volume and just leave it running.
Once, Syncthing instances are paired, every change in local directory will propagate to remote server. Every developer will run its own Syncthing service and use unique ID to be authenticated on remote server.
Another approach is to use Git and Git Server. Easiest install is again through Docker. Use one of many available Dockerfiles which has support for Docker Volumes. By starting Dockerized Git Server, remote user will be able to use remote modernization resource directory in a similar manner as with GitHub.
Developer will clone repository to local disk, and alter sync and commit local changes to remote repository.
Main difference between Syncthing and GitServer is that Syncthing is fully automatic, but does not support versioning. While Git server requires manual update but has versioning. To overcome shortcomings, both solutions can be mixed or used separately. For example, use Syncthing for automatic remote syncing, and local Git client (without server) for tracking changes (block syncing. git directory).
Booth options (Syncthing and GitServer) requires some setups on server side to enable security. Which approach to use depends on preference. Bottom line is that there is no limitation. Remote developers can easily change modernization resources and use available open-source versioning and synchronization tools.
GST has one more interesting feature - cluster mode. When cluster mode is enabled, all GST nodes in the same group will me auto-discovered and linked. Any change in one node will automatically reflect in other nodes. Thus, changing modernization template on one node will propagate to all other nodes.
Having this in mind, it is enough to setup Syncthing or GitServer on just one node in cluster to receive changes for modernization resources, and all other nodes will be updated automatically.