Date: Thu, 28 Mar 2024 10:21:39 +0000 (UTC) Message-ID: <1022492614.83.1711621299353@4d4ef609acaa> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_82_649612361.1711621299353" ------=_Part_82_649612361.1711621299353 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
This doc describes the current deployment architecture we use for the Di= amond/SGC version of fragalysis. Part of the work funded by Janssen aims to change our deploym= ent infrastructure to be more generic, and to use only open-source deployme= nt software (such as Travis and Kubernetes).
Fig. 1 shows a diagram for the current model of deployment for the fraga= lysis stack, which is explained in simple(ish) terms below.
fig.= 1 =E2=80=93 architecture diagram for Fragalysis deployment infrastructure = for Diamond.
The Fragalysis stack is built from a number of components:
Fragalysis: the scientific code https://github.com/xchem/fragalysis
Fragalysis back-end: the code for the back-end database= s for the application, built with django and djangoRestFramework https://github.com/xchem/frag= alysis-backend
Fragalysis stack: the code to pull all of the other com= ponents together and build the web image that is deployed https://github.com/xchem/fragalysis-stac= k
Fragalysis front-end: The javascript code for the web a= pp https://github.co= m/xchem/fragalysis-frontend
Fragalysis loader: The code to process data with fragal= ysis and push it over to the web container https://github.com/xchem/fragalysis-loader
= Jenkins constantly polls these github repositories. When a change is pu= shed to the master branch of any of the repositories, jenkins sees it and b= uilds the relevant component in it=E2=80=99s docker container.
The web image is the result of the fragalysis-stack container. When any = of the containers that aren=E2=80=99t the loader are built, the full stack = builds, producing a new web image, that contains everything we need for the= web app to run.
The web container is pushed to a docker repository by Jenkins, which is = then automatically deployed to Openshift on our cluster in Iceland.= The changes to the web container are then seen on the physical = web app.
Data upload follows a slightly different process. When new data is pushe= d up to a directory on our cluster, we tell Jenkins it=E2=80=99s there by s= ending it a curl request. Jenkins then creates a new loader image containin= g the new data, and pushes it to openshift. The fragalysis scientific code = then processes this data, populating the back-end database. When the loader= has finished, it=E2=80=99s container stops. In this way, we can add new da= ta to fragalysis without having to re-build the full stack.
The approach to migrating images between test and production projects wi= ll be similar to that documented in the RedHat article Using Image Tags Through the SDLC<= /u>, where: -
their =E2=80=9CDev=E2=80=9D and =E2=80=9CProduction=E2=80=9D stages are = our =E2=80=9CTEST=E2=80=9D and =E2=80=9CPRODUCTION=E2=80=9D stages
the registry is shared between all projects/stages.
The basic workflow is described below in two stages, one for TEST and on= e for PRODUCTION. A simple schematic overview is included at the end of thi= s section.