Reduce Repo Traffic - Pre Deploy-Build and Offline Execution¶

As a principle, a z2 installation is made to check for updates at startup and on-demand. After installation of the core however initial repository access may overwhelm the repository infrastructure leading to reduced scale out performance. In other cases repository access from a live installation is not desired.

Example Problems¶

• You have large Git Repos and initial cloning by the system takes long
• You use the Maven Component Repository and do not want live-systems to download from a public maven repo
• You want to use z2 in a docker image for scale out in e.g. Kubernetes and want to avoid lengthy initialization times
• You want to always run live systems in offline mode, and rather than having z2 fetch updates, build a complete z2 installation for distribution

All of these cases are made up from a mix of the following concerns:

a) Initialization time and network usage of a fresh core instance
b) Avoiding access to remote systems at runtime

Reduce Initialization Time and Network Usage of a Clean Z2-Home Installation¶

Pre-Deploy Build¶

Assuming you want to quickly scale out and start up instances without requiring downloading of resources it is simplest to actually build a "warm" z2-core by retrieving all component resources and possibly even prebuilding all Java components. For example, this could be the last step of preparation of a docker image for distribution.

See below Appendix 1 for a code sample.

Pros:

• Simple to implement and fits nicely to a docker setup

Cons:

• Image could still be large, if repos hold a lot of unused content/history

Hub CR¶

Another way of generally reducing and optimizing resource retrieval for a larger distributed system is to use the Hub Component Repository (see How_to_use_the_hub_cr). In essence, your system will have different target states depending on whether it is used on a development scenario or for production. In the latter case, the Hub CR would be used and otherwise regular source code repositories would be used - controlled by e.g. environment vars. This approach can be combined with the Pre-Deploy Build.

Pros:

• Only what is needed is retrieved - optionally pre-compiled

Cons:

• Non-Trivial repo or target state configuration depending on scenarios
• Requires a Hub setup and installation. Another central piece of infrastructure.

SFTPSSH Repo¶

Finally, another approach would be to use the SFTPSSH_Component_Repository (that has not been implemented as of now).

Pros:

• Nodes only download what is needed - in pre-packaged form
• Simple to setup and maintain. No active infrastructure besides some SFTP location.

Cons:

• Non-Trivial repo or target state configuration depending on scenarios