In this scenario TESK and a workflow engine are deployed together in one K8s cluster and exchange input/output/intermediate files via shared file system and not FTP. In this setting TESK is an internal service and is not exposed at a boundary of the system.
Example deployment descriptors for the use case reside in wes-tes directory.
WES and TESK exchange files over ReadWriteMany PVC. An example descriptor assumes the existence of a default storage class supporting Read Write Many PVCs.
The workflow engine that was used is this fork of WES-ELIXIR adapted for the use case. It consists of 2 services: API - exposed externally via Ingress definition and a celery worker. Both use the same image. WES-ELIXIR has a requirement of MongoDB and RabbitMQ. In the example we assumed both are available, under mongo and rabbitmq URLs accordingly. We deployed both inside the same cluster, but that is not a requirement.
TESK is an internal service in this scenario. Newly introduced environment variables describe, how the shared PVC is visible to different components of the system:
TESK_API_TASKMASTER_ENVIRONMENT_HOST_BASE_PATH- the path, where the shared PVC is mounted at WES sideTESK_API_TASKMASTER_ENVIRONMENT_CONTAINER_BASE_PATH- the path, where the shared PVC will be dynamically mounted in filer containers.TESK_API_TASKMASTER_ENVIRONMENT_TRANSFER_PVC_NAME- the name of the shared PVC.
In this use case - as usually - TESK requires a dynamic storage class (not necessarily the same that was used for producing shared storage, but we assumed so).
In our PoC Caddy server plays a role of both user and site storage. We used this image with an additional upload plugin. When used as a User Workspace Caddy is exposed externally via Ingress, serves files from the shared storage and lets users upload files therein. When used as Site Storage, it has a separate file storage attached and the service is visible only internally.