Research Assistant and Software Architect at Fraunhofer Austria Research GmbH
Obtained from the Original Post
DURAARK (Durable Architectural Knowledge)
Service Based Architecture
The current DURAARK system provides the following services:
- duraark-sessions: management service for sessions
- duraark-metadata: extraction of metadata from supported files (BIM models in the IFC format and point cloud files in the E57 format)
- duraark-sda: a knowledge graph that stores semantic information about a building
- duraark-geometricenrichemnt: tools for extracting information from point cloud scans
- duraark-digitalpreservation: service for storing files and additional information into a long-term preservation system
With this setup in place let’s dive into DCHQ!
Setup DURAARK on DCHQ
The use case we want to achive with DCHQ is to provide our stakeholder group with the possibility to setup their own copy of the DURAARK system with a “single-click” experience. We are a research company that develops a prototype of the system, but we are not hosting a production ready system for potential customers (the reasons for that lie in our company setup as non-profit organization). Therefore we are interested in using a hosted service where stakeholders can preview the DURAARK prototype on their own. Let’s see how we can achieve that with DCHQ …
The first step is to navigate to Manage > Template and create a new application template for the DURAARK system with the + sign. The content of the template looks like this:
For the duraark-* containers we are using the default Docker Compose format to describe how they should be deployed. The workbench-ui container is using a dedicated DCHQ feature -- template parameters — to setup the URL which the frontend will use to connect to the backend services. In this case we use a template parameter to find out the IP address of the host the web container is running on (or to be more precise: will be running on after the deployment). This value is set to the environment variable DURAARK_API_ENDPOINT which is read by the workbench-ui container to connect to the correct API endpoint.
The web container is a NGINX reverse proxy that serves the duraark-* backend services at a single base endpoint. For this setup the NGINX configuration needs to know the container IPs of the services which are only available at runtime after the system is provisioned. We can use a second dedicated DCHQ feature — plugins — in combination with the template parameters to setup the NGINX instance.
Plugins are bash scripts which are executed after a container is provisioned (or at runtime, depending on your needs). In this case we update the NGINX configuration file to point to the respective IPs of the duraark-* containers. This is the relevant NGINX configuration file:
To activate the plugin first note down the plugin ID (I took the ID directly from the URL after saving the plugin, as the page did not display the ID) head back to the template and have a look at line 34. Here the plugins keyword is used which references the plugin. The arguments section is then responsible for setting the environment variables used within the bash script. Again, template parameters are used to figure out the respective container IP addresses which get set as environment variables. When the plugin gets executed after the web container is started the plugin has all the information necessary to rewrite the NGINX configuration to adapt to the provisioned system.
The template is now setup and ready to be deployed from the Library section:
Setting up the application template feels very familiar for developers which are experienced in Docker and Docker Compose. The DCHQ specific extensions like plugins and template parameters are useful and make lifes easier when setting up post-provisioning tasks like a NGINX reverse proxy configuration. Have a look a the DCHQ blog to get more ideas on how to use the provided extensions, there is much more to see then touched in this post, e.g., for setting up multi-host environments for load balancing. The DCHQ team is also very responsive and willing to help if you experience any problems, which is great.
If you are interested in the DURAARK system feel free to drop me a note and I’ll keep you posted for updates on the system (my email is available here). Currently we have a prototype that is showcasing the developed functionality but still has some rough edges. You can also follow the development on Github or on the official project page.