Project deployment
Interesting student projects can be deployed using KASK resources. KASK employee have to confirm that the project should be deployed. The basic deployment environment is Docker Swarm.
If a project is to be deployed it has to provide at least Dockerfile that will automatically prepare the containers. Usage of docker registries and proper docker-compose file is however recommended. In all cases however all the needed sources, dependencies etc. have to be specified within the Dockerfil/docker-compose and should be pulled automatically! No manual steps should be involved in project deployment!
Project updates should also be automated using Dockerfile/docker-compose.
The applications have to work behind multiple reverse proxy servers! If it needs some special headers set proper Nginx configuration should also be provided! The Docker Swarm nodes are behind 2 reverse proxy with load balancing!
I cannot directly expose ports to the outside world!
New projects
All semi-ready projects that need to be presented to the public can be deployed using department's resources. The department has one entry point for all services - https://kask.eti.pg.gda.pl. The access node serves as a reverse proxy for all services running inside of the department's network. In rare cases the services can have a dedicated domain, however it will always be hosted via the same access node.
As all hardware and software resources are limited and the deployment have to be done mainly by the laboratory administrator the projects need to pass the following criteria:
deployment is only possible for projects stored in the department's repositories,the application have to be stable enough so it will not impact other services,it is advise so that the application is at least almost ready - the administrator has other tasks and cannot cponstantly deploy new versions, in some cases this can be bypassed by creation of a VM, however resources dedicated to that are currently limited,the application should work under the web servers available in the laboratory, see here for details,
resources of all names must be similar - the app, the database, all components, directories etc. should have common base name to kip things tidy. Especially in MSSQL the database name can be different from the DB file name. Do not do such things,the database should be provided as a text file that will create all the tables and populate them with data,remember about case sensitivity! Things working in Windows will not work in Linux if the author will disregard code cleanup and the cases between files/database and the code will differ. MySQL in Windows is not case sensitive, in Linux it is!all configuration parameters (app name, db connection string, base URL etc.) should be available in one, easy for modification place,the application must work both as root application and in any different context. Usually all apps will be available as https://kask.eti.pg.gda.pl/somename. If the app assumes that its context is root or forces redirects to a specific, hardcoded path it will not work,local URL's cannot be hard-coded, they must be easily configurable or the application should find out it's real context automatically,if it is possible the app should use a Linux host - such servers are far easier to administer. Please bare that in mind, especially that Linux is case sensitive - watch out for file extension cases (Windows like to spell them using uppercase), database and table names - MySQL in windows is not case sensitive and Windows version of mysqldump tends to write all data using lower case. In such case the app might stop working after data restore if the table names in the code use capital letters,always test your application, especially see if it can be deployed outside the IDE you are using! Sometime production environment requires special configuration that is done by the IDE automatically in the background,each application has to have complete deployment manual describing each step of the installation in detail. Always assume that I do not know the technology you are using and I do not know what libraries are needed. There is just to many possible solutions to know them all.
Updating the already deployed project
Before creating new version always use a repository with the original code so that the extended and currently deployed version will be the same. The update procedure is similar as for new project - update and test the app, write updated deployment manual and push everything into the repository. I will update the application when you will let me know. When updating the database always provide update file. If this is not possible you need to provide a script that will recreate the whole database, usually with data.