Page History
...
Dette Dokument beskriver installation og initiel opsætning af en STS service/server. STS installationen vil blive refereret til som service eller installation.
Forudsætninger
Det forudsættes at STS’en installeres på et NSP-lignende miljø. Herunder beskrives afhængigheder hertil i detalje.
...
- Konfigurationsfiler skal opdateres til nyeste version; stier, passwords og lignende skal med over i ny konfiguration.
- Database konfiguration kan bevares, såvidt det er muligt i forhold til skema ændringer.
- Cachen i databasen, navnligt cprhash og cprcache, kan tømmes
Jenkins
STS bygges med NSP's Jenkins server via følgende jobs:
- STS_build - Bygger koden
- STS_push_snapshot - Pusher det nyeste snapshot image til NSP Docker Registry.
NSP Leverandøren er selv ansvarlige for at pushe release versioner af STS til NSP Docker Registry gennem Jenkins.
Docker
STS består af et Docker images som pushes til NSP Docker Registry med følgende
...
navn:
Docker image name |
|---|
| registry.nspop.dk/components/sts/sts |
Docker Compose
STS leveres samtidig som et sæt af Docker Compose filer i folderen https://svn.nspop.dk/svn/components/sts/trunk/compose.
For release x.y.z af STS findes Docker Compose filerne i folderen https://svn.nspop.dk/svn/components/sts/tags/release-x.y.z/compose
En leverance af STS består af en compose folder som beskrevet ovenfor samt tilhørende tags af de fem Docker images.
Compose folderen indeholder 5 underfoldere:
Folder | Indhold |
|---|---|
| configuration | Her ligger alle de konfigurationsfiler som det forventes af driften tilretter til det anvendte miljø. Se Driftvejledningen |
| database | Her ligger alle de databasefiler som det forventes at driften lægger på en NSP database |
| development | Her ligger en Docker Compose fil til brug for udvikling. Se Guide til Udviklere. |
| test | Her ligger en Docker Compose fil der kan starte NAS2 i en standalone test konfiguration. |
| release | Her ligger den Docker Compose fil som det forventes driften anvender på både test og produktionsmiljøerne. |
Java Keystores
Der benyttes et antal java keystores. Disse beskrives i driftsvejledningen.
...
Anden opsætning af datasource er overladt til NSP projektet, dog ville det give mening at have en pool og sætte en forbindelses- checker op. Dette er medtaget i leverancens eksempel.
Luna modul
STS kan integrere med en Lunaboks på to forskellige måder. Seal integrationen til bokse købt inden 2014 (generation 4) og NLL integrationen til bokse købt efter 2014 (generation 5).
Det forventes at den JBoss som STS deployes på indeholder et jboss-modul med navnet dkAlt efter hvilket miljø STS kører i skal det integrere med Luna HSM bokse. Uanset hvilket miljø STS afvikles i forventes det at der er et modul i Wildfly der hedder dk.nsi.nsp.sts.luna. STS afhænger af eksistensen af et sådant modul. Modulet kan være tomt - men skal, såfremt man anvender nyere Lunabokse, ændres til at indeholde Luna biblioteker (driver). Herved kan disse deployes/opgraderes uafhængig af STS.
Modulet kan (såfremt det ikke allrede findes) oprettes med følgende jboss-cli kommando:
...
I det docker image der leveres findes dette modul som et tomt modul. Dette er tilstrækkeligt når STS skal afvikles i et IKKE produktions miljø. I et produktions miljø skal dk.nsi.nsp.sts.luna
...
modulet være opdateret med de korrekte jar filer til at integrere med Luna HSM boksene.
Installation af Luna HSM jar filerne sker ved at volume mounte folderen med wildly modulet til /pack/wildfly8/modules/dk/nsi/nsp/sts/luna/main i den kørende container. Dette er beskrevet i release version af den docker-compose fil der leveres med projektet.
I modulet skal passende jar-filer placeres, for miljøer som benytter Luna HSM.
Dette vil fungere med Luna biblioteket, der fulgte med 2014 Luna-indkøbet. For integration op mod tidligere Lunabokse skal Luna driverne fortsat manuelt indlejres i sts.war inden deployment
Logning
Logging i STS er normalt konfigureret i filen, /pack/wildfly8/standalone/configuration/log4j-sts.xml. 1 Der findes 3 overordnede log-emner:
...