[Inbetriebnahme] Nutzung von Umgebungsvariablen im Betrieb

[schmandr]

Bei der Entwicklung von GRETL-Jobs können wir Variablen wie sourceDbUrl, sourceDbUser oder sourceDbPassword nutzen, so dass alle Jobs, die auf dieselbe DB zugreifen, diese Variablen nutzen können, ohne dass dies bei jedem Job immer wiederholt werden muss. Siehe https://github.com/schmandr/gretljobs/blob/d192f674fcae28ed34841ee3143a09b07e2f29cf/scripts/start-gretl.sh#L18-L25 (Die Variablen sollen schlussendlich anders heissen, aber das ist im Moment ja egal.)

Wie können wir dies auch im Betrieb (gretl-system) nutzen? Können wir sie beim Befehl unter https://github.com/sogis/gretl/tree/master/serviceConfig#gretl-runtime oder vielleicht eher unter https://github.com/sogis/gretl/tree/master/serviceConfig#gretl-jenkins mitgeben? (Dann müssen wohl auch die Templates entsprechend ergänzt werden.)

[schmandr]

Herausforderung ist hier aus meiner Sicht, dass ich mir einigermassen vorstellen kann, wie die Variablen in Jenkins verfügbar gemacht werden können; ob sie dann aber auch im Jenkins-Slave verfügbar sind, der sie schlussendlich wirklich braucht?

[chrira]

Ich habe beschrieben, wie in einem Job die DB Url und die Credentials konfiguriert werden können: Configure a database connection Somit ist sichergestellt, dass das Passwort im Job nicht sichtbar wird. Die Logik zum Auslesen sollte in eine Groovy Methode oder sogar in eine Shared Library von Jenkins ausgelagert werden.

Der Jenkins muss auf eine neue Version updated und die Plugins aktualisiert werden.

1. Version Updaten: README
2. OpenShift Jenkins Repo mit den Neuerungen von meinem Repo aktualisieren.
3. OpenShift Build vom Jenkins anstossen.

Exemplarischer Job, wie die Konfiguration angezogen werden kann. ` def dbUrl = '' def dbCredentialName = '' node ("master") { dbUrl = "${DB1_URL}" dbCredentialName = "${DB1_CREDENTIAL}" }

// name of GRETL runtime Docker container
node ("gretl") {
    // Git repository containing the files for the job
    git 'https://github.com/sogis/gretl.git'

    // directory of this job, relative to the Git repository root
    dir('gretl/inttest/jobs/dbTasks_PostgresLibsPresent') {
        // show current location and content
        sh 'pwd && ls -l'

        withCredentials([usernamePassword(credentialsId: "${dbCredentialName}", usernameVariable: 'DB_USER', passwordVariable: 'DB_PWD')]) {

            // do the job
            sh "gretl queryPostgresVersion -Pgretltest_dburi_pg=jdbc:postgresql://${dbUrl}/gretl -Pgretltest_dbuser=${DB_USER} -Pgretltest_dbpwd=${DB_PWD}"
        }
    }
}

`

[chrira]

Wenn das Passwort im Environment vom GRETL-Runtime Slave sichtbar sein darf, könnte eine erweiterte Konfiguration des Slave über OpenShift ConfigMap Templates gemacht werden. Dieses Template müsste für jede neue Variable angepasst werden.

[schmandr]

Es dürfte aus meiner Sicht im Environment vom GRETL-Runtime Slave sichtbar sein.

Wären für diese Lösung die Änderungen gemäss https://github.com/sogis/gretl/issues/111#issuecomment-374195248 gar nicht nötig, oder ebenfalls nötig?

[schmandr]

Vielen Dank! Das funktioniert bei mir soweit ich die Anpassungen gemacht habe. Einige Dinge gefallen mir aber nicht:

Mir passt irgendwie das Update auf registry.access.redhat.com/openshift3/jenkins-2-rhel7:v3.7 nicht. Ich bleibe lieber beim jetztigen Image. Das Update hat mit dem Patch-Befehl von https://github.com/sogis/gretl/tree/master/serviceConfig#update-gretl-runtime-image bei mir auch nicht funktioniert:

$ oc patch bc s2i-jenkins-build -p $'spec:\n  strategy:\n    sourceStrategy:\n      from:\n        kind: DockerImage\n        name: registry.access.redhat.com/openshift3/jenkins-2-rhel7:v3.7'
- The BuildConfig "s2i-jenkins-build" is invalid: spec.strategy.sourceStrategy.from.namespace: Invalid value: "openshift": namespace is not valid when used with a 'DockerImage'

Das Update ist ja offenbar nötig, damit der Zugriff von Jenkins auf ein OpenShift-Secret möglich ist. (Neuere Plugin-Version erfordert neuere Jenkins-Version.) Da das Passwort im Environment vom GRETL-Runtime-Slave sichtbar sein darf, würde ich lieber einen anderen Weg gehen, wie z.B. über ConfigMap Templates.

Nun hast du aber mit https://github.com/chrira/openshift-jenkins/commit/5b92545876963bc1b0182a8f05991c19a73e41a5 schon alles für die Aktualisierte Jenkins-Version umgestellt. In https://github.com/sogis/openshift-jenkins möchte ich dieses Update aber eben lieber nicht machen. Ist es ein Problem, wenn ab hier sich die beiden Repos unterscheiden? Oder wäre es am besten, wenn du die Änderungen in https://github.com/chrira/openshift-jenkins wieder rückgängig machen würdest? Oder ist das gar nicht so tragisch, wenn ich unseren Fork nicht nachziehe?

Was mir weiter an https://github.com/chrira/openshift-jenkins/commit/5b92545876963bc1b0182a8f05991c19a73e41a5 nicht so gefällt und mich deshalb noch vom Updaten unseres Forks abhält, ist die lange Plugin-Liste. Die war vorher schön kurz und übersichtlich. Jetzt sind auch alle bereits vorinstallierten und alle abhängigen Plugins drin, was wohl nicht nötig ist.