Skip to content

Application description

Bluespice deployment topology

The deployment job is defined in nomad/templates repository.

Topology

bluespice

Huge image containing main application with a few another components:

init script

Starting all following serivec

  • Path: /opt/docker/init.sh

Apache

Routes request to php-fpm or static content

  • Configuration path is /etc/apache2/sites-enabled/bluespice.conf
  • Logs are in /data/apache/logs/
  • Data is in /data/bluespice/w/ directory

PHP-fpm

PHP application server

  • Restart could be done by /etc/init.d/php7.4-fpm restart

cron

runs scheduled tasks

Requirements:

  • backuping
  • monitoring
  • perzistent storrage (files)

This container is antipathern, but in this case we’ll keep it as it is

db

Recomended DB from bluespice is mariadb, but we tested it with a percona and it seems to be running. So we run it with percona8

Requirements:

  • backuping
  • monitoring
  • perzistent storrage (db)

elasticsearch

Fast database for searching.

Requirements:

  • backuping
  • monitoring
  • perzistent storrage (db)

operator

There is onky a simple script preparing directory structure in this container. This image will die after the job has been done.

tomcat

Java application server. It is not clear to me what does it doing, but from my small research it contains some exporting services (PDF, …).

callback

There is onky a simple script informing ES that deploy has been finished. This image will die after the job has been done.

Application lifecycle

Create deployment

We have nomad deployment and We are able to do as many deployments as we want. But We should be able to do these deployments from ESko and to do so, We need to:

  • add template to nomad integration (it is DONE)
  • need mechanism how to paste oauth keys to the deployments
    • gitlab pipeline is able to do it
    • nomad template can use it
    • ⚠️ but ESko do NOT have fields for that ⚠️

More detailed description of deploy is there

Update deployment

It is 3rd part application, we don’t have control over the application release but we have to be able control which version runs in our cloud.

So We have to complicate a release a bit as could be seen at the folowing graph.

graph TB

release((<center>New version<br>by<br><b>bluespice</b></center>)) ==> git1(["clone new images"]) ==> t1{"Test new image"};
t1 -- Big release --> project([Plan an update project]) --> pmo[["Enqueue update as a project"]]
t1 == Minor update<br>without problems ==> stage(["Update <b>Staging</b> wiki"]) ==> es(["Upgrade <b>ESko's</b> WIKI"]);
t1 -- Errors --> feedback([Report bugs<br>and skip the version<br><b>till everything will be fixed</b>])

feedback ---> git1;

es ==> updateCloud((<center><b>Update<br>all clients</b></center>))

This process expects that we have our own image registry and have control over the images in the cloud. To do so we have to do:

  • Prepare Docker images mirror - clone images from bluespice to easy gitlab and use in our infrastructure only this images with tags

Delete deployment

It is easiest part, the aplication should be deleted via ESko as usual.