- Overview
- Autonomous Database
- ORDS Latest on Docker
- Docker volume for ORDS configuration
- Start it up!
- Conclusion
Overview
Welcome to the third instalment of my series on using Oracle REST Data Services (ORDS), NGINX, Docker, SSL and Autonomous Database! In this article, I will show you how to quickly get started using ORDS and Docker. Together we will walk through the basics of building the Docker image, storing configuration in a Docker volume, running multiple ORDS instances and balancing the load using NGINX. With the help of this guide, you will be able to have a load balanced Customer Managed ORDS with Autonomous Database up and running in no time. To recap on the previous articles:
- Load Balancing ORDS with NGINX introduced the concept of load balancing and the most basic of configurations to get started with NGINX running in docker. That was entirely using HTTP as the transport protocol.
- HTTPS Load Balance: NGINX & ORDS took that a step further by using a self signed certificate so that the traffic between client and server was over the more secure HTTPS protocol. That was with ORDS instances running on port 8080 and 8090.
Autonomous Database
In this article the ORDS instances will be running in Docker and sharing a configuration for an Autonomous Database hosted on Oracle Cloud Infrastructure Free Tier resources. The prerequisite for this article is an understanding of Installing and Configuring Customer Managed ORDS on Autonomous Database. The database has ORDS and APEX already installed. However, the credentials for ORDS Runtime user and PLSQL Gateway user are not known so the ords install adb command instruction will be used to create and configure additional users in the database to be used by our new ORDS instances.
Oracle Content Delivery Network
In the previous article we had the APEX images in the global/doc_root directory. It is much easier to not have to configure an ORDS instance to serve those static files and to use the Oracle Content Deliver Network instead. One should note that by default, the APEX installation in the Autonomous Database does not use the Oracle CDN for the APEX static resources. So if you have not done so already, use Oracle CDN for the APEX images. The URL to use will depend on the version of APEX in use. At the time of writing, that is APEX 22.2.0. Once you have made this change the next APEX upgrade will keep the IMAGE_PREFIX parameter in synch. See
https://support.oracle.com/epmos/faces/DocumentDisplay?id=2817084.1 and https://blogs.oracle.com/apex/post/running-customer-managed-ords-on-autonomous-database-heres-how-to-get-ready-for-apex-211-upgrade for more information on using Oracle CDN with APEX
begin
apex_instance_admin.set_parameter(
p_parameter => 'IMAGE_PREFIX',
p_value => 'https://static.oracle.com/cdn/apex/22.2.0/' );
commit;
end;
ORDS Latest on Docker
As shown in the previous article it is already straight forward to use ORDS from the command line to configure and run in standalone mode. In doing so, you are satisfying the most fundamental requirement for ORDS by providing a supported Java Runtime Environment for it to run in. Running ORDS in Docker takes care of that dependancy and provides a consistent structure. For your convenience, I have defined a Dockerfile to create an image with the latest version of ORDS built in. It does require the JDK 17 image from Oracle Container Registry jdk repository. To use images from the Oracle Container Registry you must first sign in using your Oracle Account to accept the license agreement for the Oracle image. Once you have accepted the licence, follow the installation instructions on the page to login and pull the jdk:17 image:
> docker login container-registry.oracle.com Username: <Oracle Account Username> Password: <Oracle Account Password> Login successful. > docker pull container-registry.oracle.com/java/jdk:17 17: Pulling from java/jdk 0b93191bf088: Pull complete f5a748ad7565: Pull complete 004350aa024a: Pull complete Digest: sha256:6ca4abe688e437a2189e54e42fc8325ed9d7230286f61bfb0199b8e693423f70 Status: Downloaded newer image for container-registry.oracle.com/java/jdk:17 container-registry.oracle.com/java/jdk:17
That will pull into your local Docker repository the most recent Oracle JDK 17 build.
Dockerfile for ORDS Entrypoint
The configuration is quite simple. A couple of folders are exposed for providing configuration and library extensions. That configuration directory is essential but in the majority of cases, customers do not have custom extensions so the lib/ext folder will not be used in this article. Similarly, although the Dockerfile specifies that both port 8080 and port 8443 should be exposed, we will only be using port 8080 for HTTP traffic in this article. It is NGINX that will be terminating the HTTPS traffic before routing upstream to our ORDS instances.
The Dockerfile we’ll use to create the ORDS image is available at ORDS_Latest_Dockerfile. Contents listed below.
#
# Defines a docker image, based on the Oracle JDK image, to run Oracle REST Data Services. During the image building
# process the most recent version of ORDS will be automatically downloaded and extracted.
#
# Volumes for configuration and lib/ext are defined.
#
# docker run -p 8080:8080 -v ords-adb-config:/opt/ords-config/ -v ords-lib-ext:/opt/ords/latest/lib/ext ords-latest/oraclejdk
#
# See https://peterobrien.blog/ for more information and examples.
#
FROM container-registry.oracle.com/java/jdk:17
MAINTAINER Peter O'Brien
ENV LATEST=/opt/ords-latest/
ENV CONFIG=/opt/ords-config/
WORKDIR $LATEST
ADD https://download.oracle.com/otn_software/java/ords/ords-latest.zip $LATEST
RUN jar xf ords-latest.zip; rm ords-latest.zip; chmod +x bin/ords
VOLUME $LATEST/lib/ext/ $CONFIG
EXPOSE 8080
EXPOSE 8443
WORKDIR $CONFIG
ENTRYPOINT ["/opt/ords-latest/bin/ords"]
CMD ["serve"]
To use the above Dockerfile and build an image locally called ords-latest/oraclejdk use the following command
> docker build --tag ords-latest/oraclejdk \ https://gist.githubusercontent.com/pobalopalous/fc6ab4ee777f6b7f32a400e920df682d/raw/ORDS_Latest_Dockerfile Downloading build context from remote url: https://gist.githubusercontent.com/pobalopalous/fc6ab4ee777f6b7f32a400e920df682d/raw/ORDS_Latest_Dockerfile [===============Downloading build context from remote url: https://gist.githubusercontent.com/pobalopalous/fc6ab4ee777f6b7f32a400e920df682d/raw/ORDS_Latest_Dockerfile [==================================================>] 878B/878B Downloading build context from remote url: https://gist.githubusercontent.com/pobalopalous/fc6ab4ee777f6b7f32a400e920df682d/raw/ORDS_Latest_Dockerfile [==================================================>] 878B/878B Sending build context to Docker daemon 2.56kB Step 1/13 : FROM container-registry.oracle.com/java/jdk:17 ---> 4945318567e9 Step 2/13 : MAINTAINER Peter O'Brien ---> Using cache ---> 1bb5b3ea1d92 Step 3/13 : ENV LATEST=/opt/ords-latest/ ---> Using cache ---> 4798e9cbc8d1 Step 4/13 : ENV CONFIG=/opt/ords-config/ ---> Using cache ---> a1f6e0bf441c Step 5/13 : WORKDIR $LATEST ---> Using cache ---> 1b961db4ee2d Step 6/13 : ADD https://download.oracle.com/otn_software/java/ords/ords-latest.zip $LATEST Downloading [==================================================>] 94.62MB/94.62MB ---> Using cache ---> f6d009ada2f1 Step 7/13 : RUN jar xf ords-latest.zip; rm ords-latest.zip; chmod +x bin/ords ---> Using cache ---> f6d20c737486 Step 8/13 : VOLUME $LATEST/lib/ext/ $CONFIG ---> Using cache ---> fde34609973e Step 9/13 : EXPOSE 8080 ---> Using cache ---> 77933cb86baa Step 10/13 : EXPOSE 8443 ---> Using cache ---> 094fc3d8332b Step 11/13 : WORKDIR $CONFIG ---> Using cache ---> 2d1b41e2c6f0 Step 12/13 : ENTRYPOINT ["/opt/ords-latest/bin/ords"] ---> Using cache ---> 9974ac45526d Step 13/13 : CMD ["serve"] ---> Using cache ---> 4cbe74b80bb5 Successfully built 4cbe74b80bb5 Successfully tagged ords-latest/oraclejdk:latest
You now have an image in your local Docker repository ready to run. Note that the base image is an Oracle JDK 17 one. You can of course change that to something else. At the time of writing, only Oracle JDK 11 and 17 are supported Java Runtime Environments for ORDS.
Docker volume for ORDS configuration
Now it’s time to start putting the ORDS configuration together. In the previous article I outlined a configuration folder structure which was defined on the host computer file system. We are deviating from that in two ways. First, as outlined above, we will not have any APEX images in the global/doc_root directory because we are using the Oracle CDN with APEX in the hosted Autonomous Database. Second, we’re using a Docker volume, rather than the local filesystem, to store all the configuration.
Docker volumes are an ideal way to persist data generated by and used by Docker containers. They provide several benefits, such as:
- Data isolation: Docker volumes are independent of the underlying filesystem, which ensures that the data persists even if the container is moved to a different host.
- Easy deployment: Docker volumes can be shared across multiple containers and hosts, making it easy to deploy applications in different environments.
- Data security: Docker volumes are stored outside the container, so they are not affected by any changes within the container. This ensures that your data remains secure and consistent.
- Performance: Docker volumes are stored on the host system, which can be faster than using shared storage. This can improve the performance of your containers.
The first configuration item for a Customer Managed ORDS on Autonomous Database is the wallet and getting that wallet zip file into the Docker volume involves a few steps that may not be intuitive if you are not familiar with Docker volumes. You see, to copy a file into a Docker volume, one must do that through a running container, but before we have a running container, we must first create the volume.
> docker volume create ords-adb-config ords-adb-config
Let’s assume you have downloaded your Autonomous Database wallet zip file to your ~/Downloads directory. For example: ~/Downloads/Wallet_DB202301101106.zip. We’re going to put it in the ords-adb-config volume as /opt/ords-config/Wallet_Autonomous.zip but first we must start a container to use it.
> docker run --detach --rm --name ords-latest \
-v ords-adb-config:/opt/ords-config/ \
ords-latest/oraclejdk
Note that we’re not mapping to any ports and once we’re finished with this container it will be removed. Let’s copy that wallet zip file. We know the name of the container is ords-latest because that’s the name we gave in the docker run command. Your wallet file name will be different but we’re going to copy it to /opt/ords-config/Wallet_Autonomous.zip to keep things simple for subsequent commands. If you are going to have multiple pools, you will have to have distinct filenames.
> docker cp ~/Downloads/Wallet_DB202301101106.zip \
ords-latest:/opt/ords-config/Wallet_Autonomous.zip
That ords-latest container is no longer required. It only came into existence to allow you to copy the zip file. When you stop the container it should be removed automatically.
> docker stop ords-latest
Configuration for Customer Managed ORDS
The wallet zip file is a good start but now it’s time to run through the Customer Managed ORDS with Autonomous Database install step which will create additional users in the database and store the necessary pool settings in the ords-adb-config Docker volume. We’re going to use the non-interactive silent installation so will have to provide the passwords for the existing ADMIN user, and the two users to create. Referring back to the ORDS documentation, the ords install adb command is…
ords install adb --admin-user <DATABASE USER> \
--db-user <DATABASE USER> \
--gateway-user <DATABASE USER>
--wallet <PATH TO ZIP FILE>
--wallet-service-name <NET SERVICE NAME>
--feature-sdw <BOOLEAN>
--feature-db-api <BOOLEAN> \
--feature-rest-enabled-sql <BOOLEAN> \
--password-stdin < adbs_passwords.txtLet’s create that file with the passwords to use. We can delete it once the ords install adb command completes. Create the adbs_passwords.txt file with three passwords on each line:
<PASSWORD FOR admin-user>
<PASSWORD FOR db-user>
<PASSWORD FOR gateway-user>In my case the adbs_passwords.txt file looks like this:
MyADMIN_password_1s_a_s@cret
K@@PThe!RuntimeUserPr1vate
G@teWayUs3r!IsHiddenWith my passwords file I can pass all these details in one command as I run it in Docker. Note that the entire command line also specifies -i which instructs the docker engine to use standard input ( STDIN ) for the container.
> docker run -i -v ords-adb-config:/opt/ords-config/ \
install adb \
--admin-user ADMIN \
--db-user ORDS_PUBLIC_USER2 \
--gateway-user ORDS_PLSQL_GATEWAY2 \
--wallet /opt/ords-config/Wallet_Autonomous.zip \
--wallet-service-name db202301101106_low \
--feature-sdw true \
--feature-db-api true \
--feature-rest-enabled-sql true \
--password-stdin < adbs_passwords.txt
ORDS: Release 22.4 Production on Mon Mar 06 09:52:30 2023
Copyright (c) 2010, 2023, Oracle.
Configuration:
/opt/ords-config/
Oracle REST Data Services - Non-Interactive Customer Managed ORDS for Autonomous Database
Connecting to Autonomous database user: ADMIN TNS Service: db202301101106_low
Retrieving information
Checking Autonomous database user: ORDS_PLSQL_GATEWAY2 TNS Service: db202301101106_low
The setting named: db.wallet.zip.path was set to: /opt/ords-config/Wallet_Autonomous.zip in configuration: default
The setting named: db.wallet.zip.service was set to: db202301101106_low in configuration: default
The setting named: db.username was set to: ORDS_PUBLIC_USER2 in configuration: default
The setting named: db.password was set to: ****** in configuration: default
The setting named: plsql.gateway.mode was set to: proxied in configuration: default
The setting named: feature.sdw was set to: true in configuration: default
The global setting named: database.api.enabled was set to: true
The setting named: restEnabledSql.active was set to: true in configuration: default
The setting named: security.requestValidationFunction was set to: ords_util.authorize_plsql_gateway in configuration: default
2023-03-06T09:52:38.256Z INFO Connecting to Autonomous database user: ADMIN TNS Service: db202301101106_low
------------------------------------------------------------
Date : 06 Mar 2023 09:52:38
Release : Oracle REST Data Services 22.4.4.r0411526
Database : Oracle Database 19c Enterprise Edition
DB Version : 19.18.0.1.0
------------------------------------------------------------
Container Name: C4TOSECRETNQ2JA_DB202301101106
------------------------------------------------------------
[*** script: ords_runtime_user.sql]
PL/SQL procedure successfully completed.
2023-03-06T09:52:42.532Z INFO ... Verifying Autonomous Database runtime user
[*** script: ords_gateway_user.sql]
PL/SQL procedure successfully completed.
2023-03-06T09:52:43.674Z INFO ... Verifying Autonomous Database gateway user
2023-03-06T09:52:43.675Z INFO Completed configuring for Customer Managed Oracle REST Data Services version 22.4.4.r0411526. Elapsed time: 00:00:05.407
[*** Info: Completed configuring for Customer Managed Oracle REST Data Services version 22.4.4.r0411526. Elapsed time: 00:00:05.407
]
2023-03-06T09:52:43.720Z INFO To run in standalone mode, use the ords serve command:
2023-03-06T09:52:43.723Z INFO ords --config /opt/ords-config serve
2023-03-06T09:52:43.723Z INFO Visit the ORDS Documentation to access tutorials, developer guides and more to help you get started with the new ORDS Command Line Interface (http://oracle.com/rest).
Note that because the Docker entrypoint for the image that we built earlier was specified as /opt/ords-latest/bin/ords which means we can run the ords command line with any supported commands and arguments.
Don’t forget to rm adbs_passwords.txt. You do not need it anymore.
In summary, we’ve just told ORDS to use the wallet zip file and the ADMIN credentials to connect to the hosted service, create some users and persist configuration details on the ords-adb-config volume. The docker container exits because the command is complete. You can see the ORDS configuration by running the ords config list command.
> docker run -v ords-adb-config:/opt/ords-config/ \
ords-latest/oraclejdk config list
ORDS: Release 22.4 Production on Mon Mar 06 19:07:27 2023
Copyright (c) 2010, 2023, Oracle.
Configuration:
/opt/ords-config/
Database pool: default
Setting Value Source
---------------------------------- -------------------------------------- -----------
database.api.enabled true Global
db.password ****** Pool Wallet
db.username ORDS_PUBLIC_USER2 Pool
db.wallet.zip.path /opt/ords-config/Wallet_Autonomous.zip Pool
db.wallet.zip.service db202301101106_low Pool
feature.sdw true Pool
plsql.gateway.mode proxied Pool
restEnabledSql.active true Pool
security.requestValidationFunction ords_util.authorize_plsql_gateway Pool
No doubt you will remember this from the previous article about HTTPS and NGINX with ORDS. There’s one more configuration setting to address. That’s to tell ORDS what header key / value pair to use to trust that the request was received by a load balancer over HTTPS even though ORDS is receiving traffic over HTTP.
docker run -v ords-adb-config:/opt/ords-config/ \ ords-latest/oraclejdk \ config set security.httpsHeaderCheck "X-Forwarded-Proto: https"
At this point we have a Docker volume ords-adb-config which has all the configuration settings necessary to run one or more Customer Managed ORDS with Autonomous Database instances as we see fit.
Start it up!
From the previous article you have a NGINX configuration that you have running in Docker to talk to two ORDS instances listening on port 8080 and 8090. Now let’s replace those ORDS instances with ones running in Docker with the above ords-adb-config Docker volume. You can leave the NGINX container running but if you have not done so already, shutdown those ORDS instances.
Up until now, we have not specified a container name when running ORDS in Docker. For convenience, we’ll refer to the container listening on port 8080 as ords-latest-8080 and the other one as ords-latest-8090.
> docker run --detach --rm --name ords-latest-8080 \
-p 8080:8080 \
-v ords-adb-config:/opt/ords-config/ \
ords-latest/oraclejdk
9e0d8ec541bc5c360c7e156153cfd8f6437d61ab2d4f627c887f03d7384a56e6
> docker run --detach --rm --name ords-latest-8090 \
-p 8090:8080 \
-v ords-adb-config:/opt/ords-config/ \
ords-latest/oraclejdk
7a36de7fb14e54710181c43caa6fb2aa9dfdf013f5afa32405378da61a9a13e0
Verify
To check that they are up and running have a look at the process list.
> docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 2c11ababaf1b ords-latest/oraclejdk "/opt/ords-latest/bi…" 4 hours ago Up 4 hours 8443/tcp, 0.0.0.0:8090->8080/tcp, :::8090->8080/tcp ords-latest-8090 7fd8c821be64 nginx "/docker-entrypoint.…" 6 hours ago Up 6 hours 0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp optimistic_kilby 9e0d8ec541bc 30e6e561dc7d "/opt/ords-latest/bi…" 6 hours ago Up 6 hours 0.0.0.0:8080->8080/tcp, :::8080->8080/tcp ords-latest-8080
Also use the docker logs command to keep track of the activity and status. We’ve given specific names for the two ORDS containers so we can refer to them directly,
> docker logs -f ords-latest-8080 ORDS: Release 22.4 Production on Mon Mar 06 13:48:57 2023 Copyright (c) 2010, 2023, Oracle. Configuration: /opt/ords-config/ 2023-03-06T13:48:58.335Z INFO HTTP and HTTP/2 cleartext listening on host: 0.0.0.0 port: 8080 2023-03-06T13:48:58.389Z INFO Disabling document root because the specified folder does not exist: /opt/ords-config/global/doc_root 2023-03-06T13:49:07.009Z INFO Configuration properties for: |default|lo| ... Mapped local pools from /opt/ords-config/databases: /ords/ => default => VALID 2023-03-06T13:49:14.790Z INFO Oracle REST Data Services initialized Oracle REST Data Services version : 22.4.4.r0411526 Oracle REST Data Services server info: jetty/10.0.12 Oracle REST Data Services java info: Java HotSpot(TM) 64-Bit Server VM 17.0.6+9-LTS-190
> docker logs -f ords-latest-8090 ORDS: Release 22.4 Production on Mon Mar 06 13:56:22 2023 Copyright (c) 2010, 2023, Oracle. Configuration: /opt/ords-config/ 2023-03-06T13:56:23.011Z INFO HTTP and HTTP/2 cleartext listening on host: 0.0.0.0 port: 8080 2023-03-06T13:56:23.066Z INFO Disabling document root because the specified folder does not exist: /opt/ords-config/global/doc_root 2023-03-06T13:56:32.683Z INFO Configuration properties for: |default|lo| ... Mapped local pools from /opt/ords-config/databases: /ords/ => default => VALID 2023-03-06T13:56:32.683Z INFO Oracle REST Data Services initialized Oracle REST Data Services version : 22.4.4.r0411526 Oracle REST Data Services server info: jetty/10.0.12 Oracle REST Data Services java info: Java HotSpot(TM) 64-Bit Server VM 17.0.6+9-LTS-190
As a reminder, to check the logs for the NGINX container you’ll have to specify the container name that was allocated at runtime. In my case it is optimistic_kilby.
> docker logs -f optimistic_kilby
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf
10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
/docker-entrypoint.sh: Configuration complete; ready for start up
to: 192.168.5.2:8080 {GET / HTTP/1.1} upstream_response_time 0.155 request_time 0.155
172.17.0.1 - - [06/Mar/2023:13:52:58 +0000] "GET /ords/ HTTP/1.1" 301 169 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36"
to: 192.168.5.2:8090 {GET /ords/ HTTP/1.1} upstream_response_time 2.356 request_time 2.356
to: 192.168.5.2:8080 {GET /ords/f?p=4550:1:117375695883225::::: HTTP/1.1} upstream_response_time 2.101 request_time 2.101
to: 192.168.5.2:8090 {GET / HTTP/1.1} upstream_response_time 0.006 request_time 0.006
172.17.0.1 - - [06/Mar/2023:13:53:03 +0000] "GET /ords/ HTTP/1.1" 301 169 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36"
to: 192.168.5.2:8080 {GET /ords/ HTTP/1.1} upstream_response_time 2.045 request_time 2.045
From the NGINX logs you can see that traffic is being alternated between the ORDS instance listening on port 8080 and 8090.
You can stop a container and restart it to confirm the failover works as before.
Conclusion
Building on the previous articles you now have both NGINX and ORDS running in Docker and using an Autonomous Database. This is still effectively a development / proof of concept environment because the DNS entry and SSL certificate are not properly setup to operate seamlessly. The nginx.conf is hardcoded with two upstream ORDS instances to use and the containers are using two specific ports on the host machine. In the next article we’ll look at using docker compose so that we have more flexibility around this.
Using the Dockerfile from this article you have created an ORDS image which can be used to run ORDS commands and update your configuration in ords-adbs-config. As an additional exercise you can look into increasing pool size (jdbc.MaxLimit) and doing a rolling restart of the two ORDS docker containers to pick up that configuration change.
Leave a comment and let me know how you get on.
Peter's Random Topic Library 