0

I've an existing NodeJS server application:

  • Deployed in a RHEL7 VM
  • Clients make HTTPS POST requests to the REST API via a URL e.g., https://example.url.xxx:3000/api/endpoint
  • In-app middleware code decrypts and authenticates the requests using TLS and LDAP
  • As part of handling the requests, the application retrieves data from database VMs elsewhere in the network (i.e., not localhost)
  • Database IP, port, credentials etc. are passed in-app to the underlying framework's database connector

We're currently migrating the application's code to work with the latest version of the underlying framework (it's a complete revamp):

  • The application will also be upgraded to NodeJS 18 and simultaneously Dockerised via node:18-slim base image.
  • The client-facing API must remain the same i.e., https://example.url.xxx:3000/api/endpoint
  • The RHEL7 VM will be used as the container's host. It'll eventually be upgraded to RHEL8, though likely not before the container is deployed to production.
  • The database connection needs to be encrypted with SSL. This will be done in-app by passing a DSN string containing the SSL config to the database connector.

How do I route the incoming/outgoing traffic to the container? I can currently think of two approaches, as illustrated below:

enter image description here

Approach 1: Expose the container directly on the VM's network interface and give it the host VM's original IP configuration. The host VM will be set to a different configuration. The client's HTTPs request will resolve to the same IP address as before, but it's now addressed to the container instead.

I personally believe this approach is the cleanest, as the configuration settings in the original application can be directly transferred and reused in the upgraded, Dockerised application.

Approach 2: Expose the container to localhost only. Client requests are still sent to the VM, which is mapped to e.g., localhost:3000. Likewise, database requests from the container is routed by the host VM to the external database VM.

I've no work experience with Linux VMs, so I'm unsure how to implement either approach:

  1. For approach 1, how do I expose the container to the external network?
  2. For approach 2, how do I configure the host to route/map the incoming and outgoing traffic? While the traffic to/from localhost within the VM may be unencrypted, the client-VM connection must remain secured with HTTPS/TLS and LDAP, and the DB-VM connection must be secured with SSL, so in this approach additional setup may be needed unless the in-app implementation within the container is still applicable.

0

You must log in to answer this question.