Mongo DB austauschen
Author: osswald
Publication Date: 2/21/2019 10:51
Hallo zusammen,
unser Kunde möchte aus Performance und juristischen Gründen nicht die MongoDB des CaaS innerhalb des Clusters nutzen, sondern stattdessen eine eigene dedizierte MongoDB außerhalb der Cloud anbinden.
Wie groß ist der Aufwand dafür? Ist das überhaupt vorgesehen?
Vielen Dank schon mal für Eure Antworten :smileyhappy:
Tags: caas, datenbank, mongodb, tauschen
-
Author: TanjaGroßmüller - 2/27/2019 10:12
Hallo Philipp,
unser Team ist diese Woche krankheitsbedingt leider sehr dezimiert. Ich bitte Dich daher noch um Geduld bis kommende Woche, wo wir das dann mal gemeinsam besprechen.
Vielleicht kannst Du uns zwischenzeitlich die Beweggründe für den Wunsch näher erläutern? Und wir reden schon über Kubernetes, oder?
Viele Grüße,
Tanja
0 -
Author: groth - 3/12/2019 7:58
Hallo Philipp,
sorry nochmal für die Verzögerung, unsere Kapazitäten waren die Tanja sagte sehr dezimiert.
Du kannst die MongoDB in den Helm Charts einfach deaktivieren, das ist also absolut vorgesehen. Wenn du dir die values.yaml der Helm Chart anschaust, dann findest du die zum einen die Property um die MongoDB zu deaktivieren:
mongo:
#set to false to remove mongodb from the release altogether
#if you do that, you need to adjust "credentials.caasRepoServer" and "credentials.caasRepoAdditions" above
enabled: trueUnd zum anderen die Properties, um die Verbindungseinstellungen zu deiner eigenen MongoDB anzugeben:
credentials:
[...]
#uncomment and enter your mongodb nodes in case you disable mongodb below with 'mongo.enabled=false'
#caasRepoServer: "caas-mongo-0.caas-mongo,caas-mongo-1.caas-mongo,caas-mongo-2.caas-mongo"
caasRepoAdditions: "replicaSet=rs0\\&readPreference=secondaryPreferred\\&serverSelectionTimeoutMS=5000"Ich hoffe das hilft dir weiter und du kannst dein Setup damit aufbauen.
Beste Grüße
Christian
0 -
Author: mhdl - 3/27/2019 8:33
Hallo Christian,
die Datenbank die wir anbinden wollen ist nur über SSL erreichbar.
Wie geben wir der Verbindung diese Informationen mit?
0 -
Author: mhdl - 3/27/2019 13:37
Hi,
Ich finde aktuell keine Möglichkeit um ein CA-Zertifikat mit in die caas.repo.additions zu geben.
Ist das aktuell so nicht vorgesehen? Dann macht aber auch die Möglichkeit SSL zu aktivieren wenig Sinn oder?
Grüße,
Marcel
0 -
Author: brueder - 3/28/2019 14:51
Hallo Marcel,
wir haben bisher nicht vorgesehen, die interne Verbindung zu verschlüsseln, und ich habe das noch nicht ausprobiert. Aber es müsste eigentlich gehen - vorausgesetzt, ihr verwendet keine selbstsignierten Zertifikate.
Etwas mehr Kontext:
Wir bauen den Connection-String zur MongoDB zu zusammen:
mongo-uri: mongodb://%CAAS_REPO_USER%:%CAAS_REPO_PASSWORD%@%CAAS_REPO_SERVER%/?authSource=admin&%CAAS_REPO_ADDITIONS%
In den caasRepoAdditions im helm-Chart kann man also alles hinzufügen, was man in einen solchen Connection-String schreiben kann. Laut Connection String URI Format — MongoDB Manual kann man zur Verwendung von ssl einfach ssl=true setzen.
Es ist aber aktuell nicht vorgesehen, (selbstsignierte) Zertifikate oder CAs in der Rest-API zu importieren, und es ist - bisher - auch nicht geplant das zu ändern. Vorhanden sind standardmäßig alle CAs, die in einer JRE mitgeliefert werden.
Solange es im Produkt keinen direkten Support für selbstsignierte Zertifikate und eigene CAs gibt, möchte ich aber zumindest aufzeigen wie man das Problem selbst lösen kann, denn ich möchte euch nicht bremsen. Eine Änderung am Container kann euch genau das erlauben, was ihr erreichen wollt. Am Ende ist das ja "nur" ein OpenJDK-Alpine-Container (plus die Anwendung natürlich), der zur Zertifikatsvalidierung auf die cacerts schaut. Diese Datei könnt ihr ersetzen. Das grobe Vorgehen wäre wie folgt:
* Erstellt ein Dockerfile, das in etwa so aussieht
FROM e-spirit/caas-rest-api:2.4.16
COPY cacerts /etc/ssl/certs/java/cacerts
* erstellt die cacerts so, dass euer Zertifikat mit enthalten ist.
* legt diese Datei mit dort hin wo das Dockerfile liegt
mit docker build . -t changed/caas-rest-api:2.4.16 könnt ihr den Build anstoßen. Das geht davon aus, dass die e-spirit-Images auf der Maschine im Docker-Repo liegen. Dann wird ein neues Image erstellt. Dieses müsst ihr dann statt dem originalen Image verwenden. Achtung, es ist aktuell nicht möglich ohne Änderung an den helm-Charts den Namen eines einzigen Images zu ändern (das ist normalerweise auch nicht sinnvoll), es ist also am einfachsten den gleichen Namen / das gleiche Tag zu verwenden. Wenn ihr das verwendet und ssl=true in den caasRepoAdditions setzt, müsste es gehen. Aber: Ich habe den Prozess bisher nicht ausprobiert, sehe aber auch erst einmal keinen Grund warum es nicht gehen sollte.
Sollte es später direkten Support im Produkt geben, könnt ihr euch diesen Schritt einfach sparen und das Zertifikat dort dann angeben.
Hilft das erst einmal?
Viele Grüße,
Lena
0 -
Author: mhdl - 3/29/2019 7:48
Hi Lena,
vielen Dank für die schnelle und sehr umfangreiche Antwort.
Allerdings bauen wir aktuell das REST-Api Image nicht selbst, wie modifizieren wir das dann?
Der Parameter CAAS_REPO_ADDITIONS nimmt auch nicht alle in der MongoDB Doku erwähnten Parameter, bekomme hier für einige undefined oder ähnliche Fehler.
Grüße,
Marcel
0 -
Author: tenter - 3/29/2019 10:31
Hi Marcel,
besteht denn für euch die Möglichkeit es selbst zu bauen? Das würde euer Problem ziemlich einfach lösen. Wir haben da keinen anderen Workaround für das Problem - einfaches reinmounten in den Container reicht hier leider nicht.
Der CAAS_REPO_ADDITIONS-Parameter ist nur ein Teil des resultierenden Connection-Strings für die Datenbank, wie Lena oben beschreibt. Kannst du uns konkreter sagen, welche Parameter nicht funktionieren? Dann könnten wir uns das nochmal genauer anschauen.
Grüße,
Hannes
0 -
Author: mhdl - 4/9/2019 12:47
Hallo Lena,
wir haben es versucht wie du sagtest.
Wir haben das bestehende Image als Base-Image benutzt und den CACERTS – KeyStore von Java mitsamt den benutzten Zertifikaten hineinkopiert und dieses Image deployed.
Wir erhalten beim Start des Pods nun folgenden Fehler:
04:00:32.139 [cluster-ClusterId{value=‘5cab3e8997d8aa0001ad376d‘, description=‘null‘}-5b4cbd6e-0ac1-41fb-903a-c8e5af8ffeec-0.659dc287bad647f9b4fe17c4e4c38dcc.databases.appdomain.cloud:30494 / ] INFO org.mongodb.driver.cluster – Exception in monitor thread while connecting to server 5b4cbd6e-0ac1-41fb-903a-c8e5af8ffeec-0.659dc287bad647f9b4fe17c4e4c38dcc.databases.appdomain.cloud:30494 Com.mongodb.MongoSocketWriteException: Exception sending message
At com.mongodb.connection.InternalStreamConnection.translateWriteException(InternalStreamConnection.java:445)
At com.mongodb.connection.InternalStreamConnection.sendMessage(InternalStreamConnection.java:194)
At com.mongodb.connection.CommandHelper.sendMessage(CommandHelper.java:89)
At com.mongodb.connection.CommandHelper.executeCommand(CommandHelper.java:32)
At com.mongodb.connection.InternalStreamConnectionInitializer.initializeConnectionDescription(InternalStreamConnectionInitializer.java:85)
At com.mongodb.connection.InternalStreamConnectionInitializer.initialize(InternalStreamConnectionInitializer.java:45)
At com.mongodb.connection.InternalStreamConnection.open(InternalStreamConnection.java:108)
At com.mongodb.connection.DefaultServerMonitor$ServerMonitorRunnable.run(DefaultServerMonitor.java:111)
At java.lang.Thread.run(Thread.java:748)
Caused by: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
At sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1002)
At sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385)
At sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:757)
At sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
At com.mongodb.connection.SocketStream.write(SocketStream.java:74)
At com.mongodb.connection.InternalStreamConnection.sendMessage(InternalStreamConnection.java:191)
… 7 common frames omitted
Caused by: java.io.EOFException: SSL peer shut down incorrectly
At sun.security.ssl.InputRecord.read(InputRecord.java:505)
At sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:983)
… 12 common frames omitted
Wir wissen hier nicht weiter.
Benutzt eure Verbindung tatsächlich den Java-Keystore? Wenn ich nämlich, aus einer Test-Applikation heraus, versuche auf die DB zu kommen, geht das.
Hast du noch Ideen dazu?
0 -
Author: TanjaGroßmüller - 4/15/2019 8:47
Hallo Marcel,
so eine richtige Idee haben wir auch aktuell nicht. Im Prinzip sind ja diese Schritte zu erledigen:
https://restheart.org/learn/setup/#connect-restheart-to-mongodb-over-tlsssl
Daher prüf doch zunächst noch mal den Inhalt des Keystores (keytool -list ...). Wie ist die mongo-uri gesetzt?
Könntest Du uns außerdem noch einen größeren Auszug des Logs zukommen lassen, also vor allem den Start des Pods bis zu dem o.g. Fehler? Kommt der dann nur einmal oder wiederholt?0 -
Author: ulti - 4/17/2019 9:47
Hallo Tanja,
ich denke, dass wir aktuell zuerst zwei andere Issues mit der Verbindung haben. Aber erstmal eine gute Nachricht: Vom Pod der RestAPI komme ich mit Curl ganz generell auf den MongoDB Service.
/ $ curl -i 5b4cbd6e-0ac1-41fb-903a-c8e5af8ffeec-0.659dc287bad647f9b4fe17c4e4c38dcc.databases.appdomain.cloud:30494
HTTP/1.0 200 OK
Connection: close
Content-Type: text/plain
Content-Length: 84
It looks like you are trying to access MongoDB over HTTP on the native driver port.
Allerdings habe ich festgestellt dass wir eine Exception bekommen, wenn ein GET kommt. Dann versucht der DefaulServerMonitor auf die Adresse des Arbiters zu verbinden und bekommt eine UnkownHostException (siehe Logfile im Anhang). Mich wundert auch, wie die Adresse des Arbiters zustande kommt.
Der zweite Punkt betrifft den Connection String. Ihr baut diesen ja wie folgt zusammen:
mongo-uri: mongodb://%CAAS_REPO_USER%:%CAAS_REPO_PASSWORD%@%CAAS_REPO_SERVER%/?authSource=admin&%CAAS_REPO_ADDITIONS%
Was wir aber benötigen wäre:
mongo-uri: mongodb://%CAAS_REPO_USER%:%CAAS_REPO_PASSWORD%@%CAAS_REPO_SERVER%/ibmclouddb?authSource=admin&%CAAS_REPO_ADDITIONS%
Kann man das umstellen?
Viele Grüße
Uli
0 -
Author: TanjaGroßmüller - 4/18/2019 12:56
Hallo Uli,
wie sieht denn Eure values.yml jetzt aus, also konkret die Werte für caasRepoServer und caasRepoAdditions?
Soll mit "ibmclouddb" die Authentication Database benannt werden?
Frohe Ostern!
Tanja
0 -
Author: ulti - 4/18/2019 13:38
Hallo Tanja,
hier die Werte für die beiden Keys sind aktuell wie folgt:
caasRepoServer = 5b4cbd6e-0ac1-41fb-903a-c8e5af8ffeec-0.659dc287bad647f9b4fe17c4e4c38dcc.databases.appdomain.cloud:30494
caasRepoAdditions = replicaSet=replset\&ssl=true\&authSource=admin\&readPreference=secondaryPreferred\&serverSelectionTimeoutMS=5000
Ich habe /ibmclouddb erstmal weggelassen, da ich es nicht ganz verstehe. IBM nennt folgenden Connection String:
mongodb://<USER>:<PASSWORD>@5b4cbd6e-0ac1-41fb-903a-c8e5af8ffeec-0.659dc287bad647f9b4fe17c4e4c38dcc.databases.appdomain.cloud:30494,5b4cbd6e-0ac1-41fb-903a-c8e5af8ffeec-1.659dc287bad647f9b4fe17c4e4c38dcc.databases.appdomain.cloud:30494/ibmclouddb?authSource=admin&replicaSet=replset
Aber die authSource wird mit admin angegeben und das Funktioniert auch. Eine DB mit Namen ibmclouddb kann ich auch nicht finden wenn ich show dbs mache:
replset:PRIMARY> show dbs
admin 0.000GB
examples 0.000GB
local 0.006GB
myMongoDb 0.000GB
Also daher denke ich, dass es klappen sollte. Im Logfile kann man auch sehen, dass die Verbindung aufgebaut wird.
Kann unser Problem eher mit der Monitoring-Exception zusammenhängen die man in den Logs sieht? Ansonsten erhalte ich mit einem GET-Request ein 403 (siehe Log im Anhang).
Viele Grüße
Uli
0 -
Author: TanjaGroßmüller - 4/24/2019 9:54
Hallo Uli,
meinem Verständnis nach gibt es also zwei Probleme:
1. der Monitor-Thread meldet Fehler:
a) ursprünglich einen SSL-Fehler (vg. Post von Marcel am 09.04.), welcher aber jetzt nicht mehr auftritt (?)
b) jetzt den Fehler, dass der DNS-Name des Arbiters nicht aufgelöst werden kann.
2. ein 403-Status bei GET
Zu 1.
Der Monitor-Thread wird vom Treiber gestartet - evtl. gibt es ein Kompatibilitätproblem. Gibt es seitens IBM eine Empfehlung, welcher Java-Treiber zu verwenden ist?
Was passiert, wenn Du den Connection-String genauso angibst, wie von IBM genannt - es sollte möglich sein, den Wert in caasRepoServer anzugeben.
zu 2.
Kannst Du auf MongoDB-Seite Logs sehen, die mehr Infos zu dem 403 auf GET zu bekommen? Existiert der User, den Du angibst, dort überhaupt? Und existiert die "caas_admin"-DB für die API Keys?
Viele Grüße,
Tanja
Nachtrag:
Ich habe gerade noch diesen Post hier gefunden: [JAVA-3103] Do not monitor the arbiters - MongoDB
Das hört sich dann für mich so an, als ob man den Fehler des Monitor-Thread ignorieren kann - zumal er auch nur als INFO geloggt wird.
0 -
Author: ulti - 4/24/2019 16:56
Hallo Tanja,
vielen Dank für den Hinweis! Das Bootstrap war nicht korrekt. Jetzt geht es, lag tatsächlich am API Key.
Viele Grüße
Uli
0 -
Author: TanjaGroßmüller - 4/25/2019 8:19
Hallo Uli,
das ist schön zu hören! Wenn das Thema nun erledigt ist, wäre es super, wenn Du die "richtige Antwort" entsprechend markierst, damit auch andere Community-Teilnehmer diese auf den ersten Blick finden. Gerne kannst Du natürlich auch noch nähere Details zur Lösung teilen, falls diese für die Allgemeinheit (und uns natürlich :-)) interessant sein könnten.
Viele Grüße,
Tanja
0
Vous devez vous connecter pour laisser un commentaire.
Commentaires
15 commentaires