SWARM: Untangle Filesystem Dependencies
Current Status
At the moment, Lakedrops depends on a strict filesystem structure to function or carry out CI tasks like database backups. In addition, environments have to be on the same node. This poses a problem in a cluster environment for several reasons:
- Endpoints of the filesystem, with a dedicated purpose, require special conditions. For example, assets need to be distributed across all cluster zones, but database dumps require a lot of space and have specific backup requirements.
- It is not possible to differentiate between project environments. For instance, a staging environment does not have to be distributed but might rely on sanitized database dumps that will be imported into the feature branch environments every night.
- Having all environments on the same node can lead to resource contention and potential performance degradation.
- It is essential to manage resources efficiently and ensure proper allocation for each environment to maintain optimal performance levels.
Motivation
File endpoints, which will be mounted into a container for any reason, need to be configurable upon startup and must be independent of each other.
Suggestion
Rewrite CI pipelines and introduce different types of file endpoints to address various use cases:
- Volumes synced in all zones (glusterfs) -> production env
- Volumes synced in the same zone (nfs) -> feature env
- Volumes on the same node (local filesystem) -> temp data
- Volumes for backups (local filesystem) -> backup data
- Maria DB Cluster synced in all zones -> db
- Minio Cluster synced in all zones -> assets via s3
- Elastic/Solr Search Cluster synced in all zones -> search