osswald
I'm new here

Mongo DB austauschen

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 Smiley Happy

0 Kudos
15 Replies
TanjaGroßmüller
Crownpeak employee

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 Kudos
groth
Crownpeak employee

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: true

Und 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 Kudos

Hallo Christian,

die Datenbank die wir anbinden wollen ist nur über SSL erreichbar.

Wie geben wir der Verbindung diese Informationen mit?

0 Kudos

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 Kudos

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 Kudos

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 Kudos

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 Kudos

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 Kudos

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 Kudos