Simplifying Oracle GoldenGate Access: A Practical Guide to NGINX Reverse Proxy Configuration

Over the years working with Oracle GoldenGate Microservices Architecture: accessing your deployment shouldn’t require your users to remember multiple port numbers or expose every service directly to the network. That’s where a reverse proxy configuration comes in, and I’ve found NGINX to be a reliable solution for this challenge.

Why This Matters for Your Team

If you’re running Oracle GoldenGate 23ai with Microservices Architecture, you’ve probably noticed that each service operates on its own port. While this works from a technical standpoint, it creates friction for your users and potentially exposes more of your infrastructure than necessary. A well-configured reverse proxy solves both problems by providing a single, clean entry point to your GoldenGate environment.

Here’s what I’m seeing in the field: teams that implement reverse proxy configurations report better user adoption, simplified security posture, and easier management of their GoldenGate deployments. Let’s walk through how to achieve this.

What You’ll Need Before Starting

Before we dive into configuration, let’s make sure your environment is ready. Here’s what needs to be in place:

Infrastructure Requirements:

• Oracle GoldenGate 23ai Microservices Architecture installed
• At least one active deployment configured
• NGINX 1.19.4 or higher (critical for Oracle Linux 8 or RHEL 8)
• Java Runtime Environment 8 or higher

Access and Permissions:

• Oracle user account with sudo permissions
• Service Manager credentials ready
• PATH environment variable including NGINX installation directory

Important RHEL 8.x Considerations:

If you’re working with RHEL 8.x, NGINX installation requires enabling the appropriate module stream to meet the version requirement. The default NGINX 1.14 stream won’t work with Oracle GoldenGate 23ai. Here’s how to get the right version:

First, check available NGINX module streams:

dnf module list nginx

You’ll see multiple streams available (1.14, 1.16, 1.18, 1.20, 1.22). For GoldenGate 23ai, you need version 1.19.4 or higher, so enable either the 1.20 or 1.22 stream:

# Reset any existing NGINX module configuration

dnf module reset nginx

# Enable NGINX 1.20 or higher stream

dnf module enable nginx:1.20

# Install NGINX

dnf install nginx

If you need NGINX 1.22 specifically:

dnf module enable nginx:1.22

dnf install nginx

After installation, verify you have the correct version:

nginx -v

For Oracle Linux 8, the process is similar using yum instead of dnf:

yum module enable nginx:1.20

yum install nginx

Firewall Configuration:

Don’t forget to open the necessary ports in firewalld:

sudo firewall-cmd --permanent --add-port={80/tcp,443/tcp}

sudo firewall-cmd --reload

Verify Your NGINX Installation

Before proceeding with configuration, verify NGINX is properly installed and running:

# Check NGINX version (should be 1.19.4 or higher)

nginx -v

# Enable NGINX to start on boot

sudo systemctl enable nginx

# Start NGINX service

sudo systemctl start nginx

# Verify service status

sudo systemctl status nginx

You should see NGINX running and enabled. This confirms your environment is ready for the GoldenGate reverse proxy configuration.

The ReverseProxySettings Utility: Your Configuration Partner

Oracle provides a utility that does the heavy lifting for NGINX configuration. You’ll find the ReverseProxySettingsutility in your $OGG_HOME/lib/utl/reverseproxy directory. This tool generates the configuration file you need, incorporating your deployment details automatically.

Let me walk you through the key options you’ll work with:

Essential Parameters:

• -u or –user: Your Service Manager account name
• -P or –password: Your Service Manager password
• -o or –output: Configuration file name (defaults to ogg.conf)
• -h or –host: Virtual host name for your reverse proxy
• -p or –port: Proxy port (defaults to 80 or 443)

Optional Configurations:

• -s or –no-ssl: Configure without SSL (not recommended for production)
• –trailOnly: Configure only for inbound trail data
• -l or –log: Enable logging with specified log file

Understanding these options helps you tailor the configuration to your specific environment. I always recommend starting with logging enabled during initial setup so you can track what’s happening.

Step-by-Step Configuration Process

Let’s execute on this together. Here’s the approach I take when setting up NGINX as a reverse proxy for GoldenGate:

Phase 1: Generate Your Configuration

Navigate to the utility directory:

cd $OGG_HOME/lib/utl/reverseproxy

Run the utility with your credentials:

ReverseProxySettings -u adminuser -P adminpwd -o ogg.conf http://localhost:9100

Replace adminuser and adminpwd with your actual Service Manager credentials. The utility connects to your deployment and generates a configuration file that maps all your microservices.

Phase 2: Deploy the Configuration

Copy your generated configuration to NGINX:

sudo cp ogg.conf /etc/nginx/conf.d/.

This places your GoldenGate configuration where NGINX expects to find it.

Phase 3: Secure Your Configuration

This is where many implementations fall short, so let’s get it right. Update your ogg.conf file with proper SSL/TLS settings:

Configure Modern Cipher Suites:

Find the ssl_ciphers line and replace it with:

ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305;

Add TLS 1.3 cipher suites on the next line:

ssl_conf_command Ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;

These cipher configurations ensure you’re using current security standards that balance strong encryption with broad compatibility.

Handle Your Certificates Properly:

For self-signed certificates (development/testing):

sudo cp ogg.key /etc/nginx/.

sudo cp ogg.pem /etc/nginx/.

Update the certificate paths in ogg.conf:

ssl_certificate /etc/nginx/ogg.pem;

ssl_certificate_key /etc/nginx/ogg.key;

For production environments with CA-signed certificates, you’ll want to include the complete certificate chain:

cat server_cert.pem intermediate_ca_cert1.pem intermediate_ca_cert2.pem > ogg_chain.pem

sudo cp ogg_chain.pem /etc/nginx/.

sudo cp ogg.key /etc/nginx/.

Then update ogg.conf to reference the chain:

ssl_certificate /etc/nginx/ogg_chain.pem;

ssl_certificate_key /etc/nginx/ogg.key;

Phase 4: Validate and Deploy

Before restarting NGINX, validate your configuration:

sudo nginx -t

You should see confirmation that the syntax is correct and the test is successful. If you encounter errors, review your certificate paths and cipher configurations.

Restart NGINX to activate your changes:

sudo systemctl restart nginx

If the configuration doesn’t load properly, perform a full stop and start of the service rather than just a reload.

Phase 5: Verify Your Configuration

Open a web browser and access your Service Manager through the proxy:

https://dc.example.com

You should reach the Service Manager login page without specifying any microservice-specific ports. From here, you can access all your GoldenGate microservices through clean, proxy-managed URLs.

Understanding SSL Termination

Let’s address an important security consideration. When you configure NGINX as a reverse proxy with SSL, the encrypted connection terminates at the proxy itself. This means the connection between NGINX and your GoldenGate services is unencrypted by default.

In many enterprise environments, this is acceptable because the proxy and GoldenGate services run within the same secure network segment. However, you need to understand this architecture when discussing your security posture with compliance teams.

Important limitations to note:

• Mutual TLS (mTLS) is not supported when using a reverse proxy
• Connections between the proxy and origin servers are unencrypted
• Your network security controls become more critical in this configuration

Practical Recommendations from Experience

After implementing this configuration across multiple RHEL 8.x and Oracle Linux 8 environments, here are insights that can help your deployment succeed:

For RHEL 8.x Environments:

• Always verify NGINX module stream before installation using dnf module list nginx
• The default 1.14 stream will not work with GoldenGate 23ai
• Document which module stream you’ve enabled for future reference
• Test firewalld rules after enabling ports to ensure connectivity

For Initial Setup:

• Start with logging enabled to troubleshoot any issues quickly
• Test with self-signed certificates first, then move to CA-signed certificates
• Document your certificate renewal process before going live
• Verify NGINX version meets the 1.19.4 minimum requirement

For Production Deployments:

• Use CA-signed certificates with complete certificate chains
• Schedule regular certificate expiration reviews
• Implement monitoring for NGINX health and GoldenGate service availability
• Create a rollback plan before making configuration changes
• Keep your NGINX module stream updated within your enabled stream

For Team Success:

• Share the proxy URL with your team rather than individual service ports
• Document which certificates are used and where they’re stored
• Create runbooks for common maintenance tasks
• Test your configuration after any NGINX updates or module stream changes
• Include NGINX module stream information in your environment documentation

What Does Success Look Like?

You’ll know your implementation is working well when:

• Users access GoldenGate services through a single, memorable URL
• Certificate warnings are eliminated for properly configured SSL
• Service access no longer requires port number knowledge
• Your security team sees reduced exposed ports on network scans
• Maintenance can be performed on individual services without changing user access points

Let’s Connect on This

Configuring reverse proxy for Oracle GoldenGate Microservices Architecture streamlines access and simplifies your security model. The ReverseProxySettings utility handles much of the complexity, but understanding the certificate configuration and security implications ensures a robust deployment.

If you’re working through this implementation and encounter challenges specific to your environment, I’m interested in hearing about them. Every deployment teaches us something new about balancing security, accessibility, and operational efficiency.

What aspects of your GoldenGate infrastructure are you looking to simplify next? The principles we’ve covered here for reverse proxy configuration often apply to other integration points in your data architecture.

Please follow and like: