At the moment metadata of deployments is only stored directly on the deployed containers/pods (as labels). As a result, this data will be lost once the container/pod is deleted. This PR stores the metadata of each deployment in the internal JSON DB so it is available even if the underlying container/pod was removed.
This provides some advantages:
Services can be stopped (the underlying container/pod is removed but the deployment is still shown in the UI as stopped)
Migrations can be easier as only the DB data needs to be transferred
Features like updating the image of a service can be implemented without the risk of loosing data
This functionality is implemented in a wrapper class DeploymentManagerWithDB that builds on top of one of the existing deployment managers (Docker and Kubernetes). This replaces the old DeploymentManager which served as a base class for the Docker and Kubernetes managers.
Some implementation notes:
The service metadata is not stored in the project the service is deployed to. Instead, a special collection for each project is created in the system project. That way, the owner of a project can not directly modify the metadata using the json db endpoints (which could lead to inconsistencies) and instead has to use the service API.
A new status (STOPPED) has been added to deployments. It will be assigned when the underlying container/pod is missing and therefore the deployment can not be accessed (later start/stop/restart actions should be added)
The list service function not only returns services in the DB but also returns services that were started externally and add them to the DB. This for example allows to start extensions externally in a docker compose file.
At the moment metadata of deployments is only stored directly on the deployed containers/pods (as labels). As a result, this data will be lost once the container/pod is deleted. This PR stores the metadata of each deployment in the internal JSON DB so it is available even if the underlying container/pod was removed. This provides some advantages:
This functionality is implemented in a wrapper class
DeploymentManagerWithDBthat builds on top of one of the existing deployment managers (Docker and Kubernetes). This replaces the old DeploymentManager which served as a base class for the Docker and Kubernetes managers.Some implementation notes: