Introduction
In the realm of modern application development, Oracle Application Express (APEX) shines as a potent tool for crafting robust web applications atop the Oracle Database. With the muscle of Oracle Cloud Infrastructure (OCI) backing it up, developers can weave intricate architectures to meet diverse business demands. Let's embark on a journey through the architecture of PokéAPEX, an Oracle APEX application hosted in OCI, unraveling the interplay of its OCI components.
Vanity URLs
Oracle Cloud Infrastructure's Always Free Tier offers a wealth of resources for developers to experiment and deploy applications without incurring costs. However, certain advanced features, such as vanity URLs for Oracle APEX applications, come with specific requirements that may not be compatible with the constraints of the Always Free Tier.
Vanity URLs provide a customized, branded web address for accessing Oracle APEX applications. To set up a vanity URL, the APEX application must be deployed within a private subnet, typically associated with a paid Oracle Cloud Infrastructure (OCI) subscription. This requirement poses a challenge for users leveraging the Always Free Tier, which primarily offers resources within public subnets.
Check this post for further details: Introducing Vanity URLs for APEX and ORDS on Oracle Autonomous Database.
Challenges with Always Free Tier and Vanity URLs
Private Subnet Requirement: Vanity URLs necessitate the deployment of the Oracle Autonomous Database (ADB) associated with the APEX application in a private subnet. However, the Always Free Tier primarily provides resources within public subnets, making it incompatible with this requirement.
Network Limitations: Always Free Tier users are limited in their ability to configure complex networking setups, such as creating private subnets and configuring Virtual Cloud Networks (VCNs) with specific routing rules, which are essential for deploying ADB in a private subnet.
Potential Workarounds
While the Always Free Tier presents challenges for implementing vanity URLs with Oracle APEX applications, there are potential workarounds to consider:
Explore Alternative URL Options: Instead of vanity URLs, consider utilizing the default URL provided by Oracle Cloud for accessing APEX applications deployed in the Always Free Tier. While not as customizable as vanity URLs, it still allows users to access their applications without additional costs.
Upgrade to Paid Subscription: For users requiring advanced features like vanity URLs and private subnets, upgrading to a paid OCI subscription may be necessary. Paid subscriptions offer greater flexibility in resource allocation and network configuration, enabling users to deploy APEX applications with vanity URLs in private subnets.
Optimize Resource Usage: Evaluate your resource utilization within the Always Free Tier and optimize accordingly. By efficiently managing resources and avoiding unnecessary allocations, you may free up capacity to accommodate the deployment requirements for vanity URLs.
Create a Compute Instance: Provision a compute instance within the Always Free Tier of Oracle Cloud Infrastructure. Select an appropriate operating system, such as Oracle Linux or Ubuntu, for hosting the NGINX web server to act as a reverse proxy.
Architecture Diagram
The architecture of PokéAPEX application in Oracle Cloud Infrastructure (OCI) is designed within a single Virtual Cloud Network (VCN) featuring two public subnets.
The first public subnet hosts the Autonomous Database running Oracle APEX, along with a Network Security Group configured to permit traffic exclusively on ports 80 and 443, ensuring secure access to the application.
In the second public subnet, a compute instance is deployed housing NGINX, which serves as a reverse proxy for handling incoming requests. Additionally, this instance is configured with Let's Encrypt for SSL certificate management, ensuring secure communication between clients and the application. The default security list associated with this subnet allows incoming traffic from the Internet on ports 80 and 443, facilitating seamless user interaction with the application.
This architecture provides a robust and secure environment for hosting and accessing the Oracle APEX application within OCI.
Configuration Steps
Create an Autonomous Database
In Oracle Cloud Infrastructure, obtaining an Oracle Application Express (APEX) instance can be accomplished through several methods. One common approach is by provisioning an Oracle Autonomous Database, which includes APEX as a fully managed service within the database instance. This enables users to quickly set up an APEX environment without worrying about infrastructure management.
Another method involves deploying APEX on Oracle Cloud Infrastructure (OCI) through Quickstarts. Find more details on how to provision an APEX instance in just a few minutes by reading OCI Quickstart - APEX blog post.
Create a Compute Instance
Provision a compute instance by following the steps described in OCI - Create compute instance.
Install and Configure NGINX
Install NGINX on the compute instance and configure it to act as a reverse proxy for the Oracle APEX application. Modify the NGINX configuration file to define the upstream server pointing to the APEX application's URL or IP address.
Refer to How to Configure Custom URLs for Oracle Autonomous Database using NginX and Let's Encrypt for further details.
SSL Configuration
Optionally, configure SSL/TLS encryption for secure communication between clients and the NGINX reverse proxy. You can obtain a free SSL certificate from Let's Encrypt or use self-signed certificates for testing purposes.
Refer to How to Configure Custom URLs for Oracle Autonomous Database using NginX and Let's Encrypt for further details.
Domain Name Configuration
Associate a custom domain name with the public IP address of the compute instance. This can be achieved by configuring DNS settings with your domain registrar or DNS provider to point the domain to the IP address of the NGINX reverse proxy.
Add an "A" record that points your domain to the public IP address of your NGINX server.
Host: Enter either '@' to represent the root domain or 'www' for the subdomain www.
Value: Enter the public IP address of your NGINX server (OCI compute instance).
TTL (Time to Live): Choose an appropriate TTL. This determines how often DNS servers will refresh the DNS records.
server {
listen 80;
server_name yourdomain.com www.yourdomain.com;
location / {
# Your NGINX configuration directives go here
# For example, proxy_pass, root, etc.
}
}
It may take some time for DNS changes to propagate worldwide. This propagation process can take up to 24-48 hours, although it often occurs much faster. Once the DNS changes have propagated, your domain should be successfully pointing to your NGINX server's public IP address.
Reverse Proxy Configuration
Configure NGINX to listen for incoming requests on port 80 or 443 (if SSL is enabled) and proxy them to the APEX application running on its default port (e.g., 8080). Additionally, set up appropriate URL rewriting rules to ensure seamless integration between the custom domain and the APEX application.
server {
server_name pokeapex.com;
location / {
rewrite ^/$ /ords/r/<apex-workspace>/pokeapex permanent;
}
location /ords/ {
proxy_pass <your_apex_url>/ords/;
proxy_set_header Origin "" ;
proxy_set_header X-Forwarded-Host $host:$server_port;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
}
location /i/ {
proxy_pass <your_apex_url>/i/;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
### NGINX configuration...
Security Considerations
Implement necessary security measures, such as firewall rules and access control, to restrict access to the compute instance and protect it from unauthorized access or malicious attacks.
You optionally can block developer and administrator tools exposed by Oracle REST Data Services (ORDS). These tools include Database Actions, REST-Enabled SQL, the API of ORDS itself, Simple Oracle Document Access (SODA) for REST, and more. Refer to Oracle Autonomous Database Vanity URLs Part 3: Blocking ORDS-Provided Developer and Administrator Tools for further details.
### NGINX configuration...
# Block tools
# A shortcut to get to the ORDS and Database Actions sign-in page. Prompts first for user name.
location /ords/sql-developer {
return 404;
}
# ORDS landing page
location /ords/_/landing {
return 404;
}
# The sign-in and signed-out pages used when authenticating to ORDS (including Database Actions).
location /ords/sign-in/ {
return 404;
}
# Access to REST-Enabled SQL.
location /ords/_/sql {
return 404;
}
# Access to Database Actions (including SQL Developer Web).
location /ords/admin/_sdw/ {
return 404;
}
# Base access to the APIs of ORDS itself.
location /ords/_/db-api/ {
return 404;
}
# User-specific access to the APIs of ORDS itself. These APIs support operations like DataPump Import, Data Guard standby management, get Data Dictionary information, provision a database instance, monitor a database, and so forth.
location /ords/admin/_/db-api/ {
return 404;
}
# Access to the SODA for REST APIs. These APIs provide JSON document access to data.
location /ords/admin/soda/ {
return 404;
}
# Miscellaneous property information exposed by ORDS.
location /ords/_/public-properties/ {
return 404;
}
# Access to the Data Tools components of Database Actions (aka Autonomous Data Platform). This includes data load, data insights, and so forth.
location /ords/admin/_adp/ {
return 404;
}
# APEX Workspace login -> f?p=4500
location /ords/f {
return 404;
}
location /ords/r/apex/workspace-sign-in/ {
return 404;
}