Page History
...
Kildekoden oprettes/ændres i svn.nspop.dk/svn/components/<komponent-navn> (herunder ligger trunk, tags og branches).
...
NSP laver et repository til det enkelte projekt under svn.nspop.dk/svn/components, samt oprtter de initielle foldere herunder.
...
| Jobnavn | adgang | jenkins konfiguration | funktion |
|---|---|---|---|
| NCC_build | leverandør | Leverandørens jenkinsfil | Jobbet her bygger fra trunk af komponenten. Det bygger på commitændringer, samt kan startes af leverandøren |
| NCC_release | NSP | Leverandørens jenkinsfil | Bygger en tagget udgave af kodebasen, ud fra leverandørens jenkinsfil. |
| NCC_push_snapshot | leverandør (indirekte) | NSP konfigureret job | Job triggered af trunk-build jobbet. Dette job pusher en :snapshot udgave af dockerimaget, der bygges, til registryet. Jobbet startes af leverandøren. |
| NCC_push_release | NSP | NSP jenkinsfil | Dette job starter et release-build job og pusher efterfølgende til registryet, med :<x.y.z> tag |
...
Denne indeholder opskriften på at bygge komponenten i NSP CI-miljøet. Denne fil er leverandørens "indgang" til byggejobbet. NSP sørger for at opsætte jobs, der anvender denne fil til byg og sikrer at de nødvendige afviklingsrettigheder er tilstede til stede for leverandøren. I udgangspunktet bliver disse jobs sat op til at bygge komponenten så snart der detekteres kodeændringer under /trunk.
...
| sub-folder | indhold | krav | note |
|---|---|---|---|
| configuration | konfigurationsfiler der forventes at være så tilpas dynamiske, at disse skal ændres pr. driftsmiljø | ja | filerne indeholdt i folderen forventes at defaulte til testopsætning. Det er således forventningen at disse er funktionsdygtige ved afvikling af docker-compose.yml filen under test (og evt. development) sub-folderen. Konfigurationsfilerne herunder må ikke samtidig være bygget ind i docker-imaget for komponenten. Disse volume mappes ind via docker-compose. |
| database | sql-filer | ja - hvis der anvendes db i enten test eller prod | filerne prefikses med timestamp. Det er forventningen at disse vol. mappes ind i en db-container til testsammenhæng og i øvrigt er beskrevet i installationsvejledningen ifht. hvilke evt. skal afvikles for at idriftsættelse af komponenten er mulig (oprettelse af db osv.). Der skal også være beskrevet hvilke filer der udelukkende er til test |
| test | 1 stk. docker-compose.yml | ja | docker-compose fil, der kan launche komponenten og dennes afhængigheder. Mock services, database osv skal startes i denne compose fil, yderligere kan man opsætte portmapning osv. Filen skal kunne afvikles med "docker-compose up" og det er forventningen at leverandørens integrationstest kan afvikles imod dette setup. Kodebasen indeholder således en opskrift til at startet komponenten lokalt, blot ved at hente compose-folderen med indhold. Konfigurationsfiler vol. mappes ind. Mock-services bør i udgangspunktet også overholde husreglerne. |
| release | 1 stk. docker-compose.yml | ja | docker-compose fil, der udelukkende indeholder volume mapning af de enkelte konfigurationsfiler fra configuration sub-folderen og så har de korrekte image angiverser for de enkelte services. Denne compose-fil bliver i byggemiljøet beriget og bliver basis for den Jinja2 template der kan idriftsætte komponenten i de forskellige miljøer. Der skal således ingen portmapning, netværk, log-vol.mapning el. lign. være i denne compose-fil. |
| development | 1 stk. docker-compose.yml | nej | dev specifik docker-compose fil, som kan have vol. mapping til target foldere/log foldere osv. |
...
I det daglige arbejde forventes udviklerne at anvende docker til udvikling og aftestning, således at det setup der leveres også er det er lokalt testes på og verificeres op imod. Afvikling imod de containere der driftes sikrer størst mulig træfsikkerhed, når der skal laves rettelser. Yderligere sikrer anvendelsen af docker-compose setuppet også at der ikke glemmes konfiguration el. lign. ved release, som hvis der fx deployes til en lokal wildfly uden NSP sikkerhedskomponenter eller afvikling imod en database med indhold, der ikke er defineret i det setup der leveres til NSP.
Koderepositoryet på svn.nspop.dk/svn/components anvendes som primært repository og udstilles også for offentligheden. CI-miljøet bygger dagligt eller pr. commit fra trunk og det forventes at man umiddelbart reparerer fejlende builds.
...
Der er til formålet konstrueret eksempelkode under NCC (NSP Containerized Component) - dette findes her: https://svn.nspop.dk/svn/components/ncc/
I NCC koden findes eksempler på hvordan koderepository'et bør struktureres, indhold af jenkins-byggefilen, samt en dockerfil. Yderligere bliver denne også releaset og deployet til test1 og indeholder derfor eksempler på funktionelle test-docker-compose-filer.
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
#!groovy
node {
try {
stage('Checkout') {
checkout scm
}
stage('Build') {
//This will resolve to docker.image('"registry.nspop.dk/platformtools/nspbuilder:jdk8').inside(){
docker.image("${NSPBUILDER_TAG}").inside(){
sh "mvn -B clean install"
}
}
stage ('Archive') {
//This will resolve to docker.docker.build('"registry.nspop.dk/components/ncc:build'${DOCKERTAG}", '--pull .')
docker.build("${REGISTRYTAG}", '--pull--build-arg BASE_TAG=${NSP_BASE_TAG} .')
}
} catch (err) {
//slackSend channel: '<channelname>', color: 'bad', message: "${env.JOB_NAME} ${env.BUILD_NUMBER} - Build failed ... (<${env.BUILD_URL}|Open>)", tokenCredentialId: 'Slack-Token'
throw err
} finally {
stage ('Clean') {
deleteDir()
}
}
} |
...
| Code Block | ||
|---|---|---|
| ||
ARG BASE_TAG=latest FROM registry.nspop.dk/platform/nsp:1${BASE_TAG} # Copy configuration files to the module directory RUN mkdir -p /pack/wildfly8wildfly/modules/dk/sds/nsp/examples/ncc/main/ COPY etc/module.xml /pack/wildfly8wildfly/modules/dk/sds/nsp/examples/ncc/main/ # Copy the war file to the deployment directory COPY target/ncc.war /pack/wildfly8wildfly/standalone/deployments/ |
compose-filer
...
| Code Block | ||
|---|---|---|
| ||
version: "3.6"
networks:
nsp_net:
external: true
ncc_net:
external: false
services:
cradb:
image: registry.nspop.dk/playground/cradb:latest
networks:
- ncc_net
environment:
- MYSQL_RANDOM_ROOT_PASSWORD=yes
nccdb:
image: mariadb:latest
networks:
- ncc_net
environment:
- MYSQL_RANDOM_ROOT_PASSWORD=yes
volumes:
- ../database/01_create_db.sql:/docker-entrypoint-initdb.d/01_create_db.sql
ncc:
image: registry.nspop.dk/components/ncc:1.0.9
ports:
- "8080"
depends_on:
- cradb
- nccdb
networks:
- nsp_net
- ncc_net
environment:
- LOG_MAX_FILE_SIZE=10MB
- LOG_MAX_BACKUP_INDEX=5
volumes:
- ../configuration/ncc.properties:/pack/wildfly8wildfly/modules/dk/sds/nsp/examples/ncc/main/ncc.properties
- ../configuration/log4j-ncc.xml:/pack/wildfly8wildfly/modules/dk/sds/nsp/examples/ncc/main/log4j-ncc.xml
- ../configuration/ncc-ds.xml:/pack/wildfly8wildfly/standalone/deployments/ncc-ds.xml
|
...
| Code Block | ||
|---|---|---|
| ||
version: "3.6"
services:
ncc:
image: registry.nspop.dk/components/ncc:1.0.9snapshot
volumes:
- ../configuration/ncc.properties:/pack/wildfly8wildfly/modules/dk/sds/nsp/examples/ncc/main/ncc.properties
- ../configuration/log4j-ncc.xml:/pack/wildfly8wildfly/modules/dk/sds/nsp/examples/ncc/main/log4j-ncc.xml
- ../configuration/ncc-ds.xml:/pack/wildfly8wildfly/standalone/deployments/ncc-ds.xml
|
...
| Code Block | ||
|---|---|---|
| ||
version: '3.6'
services:
ncc:
image: registry.nspop.dk/components/ncc:1.0.9
volumes:
- ../configuration/ncc.properties:/pack/wildfly8wildfly/modules/dk/sds/nsp/examples/ncc/main/ncc.properties
- ../configuration/log4j-ncc.xml:/pack/wildfly8wildfly/modules/dk/sds/nsp/examples/ncc/main/log4j-ncc.xml
- ../configuration/ncc-ds.xml:/pack/wildfly8wildfly/standalone/deployments/ncc-ds.xml
- /pack/log/ncc:/pack/wildfly8wildfly/standalone/log
container_name: '{{ comp_ncc_container_name }}'
restart: unless-stopped
ports:
- '{{ comp_ncc_port }}:8080'
environment:
- LOG_MAX_FILE_SIZE=10MB
- LOG_MAX_BACKUP_INDEX=5
- CRA_SERVER={{ comp_ncc_cra_dbserver }}
- CRA_USER={{ comp_ncc_cra_dbuser }}
- CRA_PWD={{ comp_ncc_cra_dbpassword }}
|
...