larsderidder
commented
1 year ago Thank you for this contribution! As you know we are working on updating the infra, upgrading versions and we are also working towards a single Kubernetes deployment configuration. This helps us a lot in progressing, so thanks again!
Hello TNO,
Hereby our results of the internship project at the Hanze UAS, where we made the docker-toolsuite available in an Azure VM and then Azure Kubernetes Services for our researchers to use. We would like to thank you for the pleasant collaboration during the project and hope this will continue with future students.
There is 2 new folders we added to the repository in the Experimental folder. One containing our implementation of the docker-toolsuite in an Azure VM, the other containing results of our Azure Kubernetes Services Implementation. We have tried to make the results usable by everyone, no matter the preferred platform. Both versions have an edited README.md that explains how you can set it up for yourself.
Automated deployment This version is a revision of docker-compose that aims to make it easier to set up. Some steps are automated, but not yet all. There now is a .env file where you only have to define variables once, they automatically get applied everywhere at once. This removes a lot of the complexity when trying to provide the environment in the cloud. The user still has to manually create a user in keycloak and create a Grafana API key. Since every container is in one single docker-compose.yaml file, the grafana, essim, and panel-service are automatically started. ESSIM and panel-service need to be restarted by the user after the api-key is inserted. The setup of Keycloak is done by adding a Dockerfile, which copies files and runs them. We've understood from you that this is not very favourable. This could maybe be done in the setup.sh script instead.
Kubernetes deployment This is our implementation of the toolsuite in Kubernetes. It lacks a large number of best practices from Kubernetes, but is fully functional. Traefik was added as an ingress controller. This version too has a setup.sh script, but contrary to the automated-deployment version, no user interference is required, it is fully automatic. Also unlike automated-deployment, this version does not (yet) make use of the .env file and dynamic configuration. In the setup.sh script it is also possible to start the environment from a backed-up database. A few other scripts like init-database.sh was also changed a little bit because of this.
To be implemented A lot of things still have to be implemented, and the environment is not yet production ready. Future students will be working on improving our repository and will keep contributing future improvements back upstream. Both versions need to be better tested before they can be used by the average user. Both versions still lack features, but the environment variables are probably also implementable in kubernetes. The other way around, the automated-deployment version can be improved by implementing the setup.sh script used by kubernetes.
We hope our contributions to the project will be of good use. We have made a lot of changes which might not be very clear, so if there is any questions, concerns or things we should add to the README.md please ask.