SOA Suite on Docker, Part 1: Now Certified, Even Without Kubernetes

A while back I wrote a blog series on running Oracle SOA Suite in Docker, starting with a high-level overview and working through setting up a host, a database, a SOA environment, and finally patching. Later I followed up with the 14c edition (SOA Suite 14c on Windows with WSL2 in ten minutes), an Apple Silicon edition, and a post on Docker Compose for SOA Suite.

This new mini-series is the production payoff of all of that. I recently moved a customer from SOA Suite 12c to 14.1.2, not as an in-place upgrade but as a fresh, fully containerized 14c deployment that we cut over composite by composite. Everything runs in plain containers on a single host per environment, with no Kubernetes anywhere in the picture.

Over four parts I'll cover:

• Part 1 (this post): why running SOA Suite in "just" Docker is now officially certified, and the overall shape of the deployment.

• Part 2: the upgrade strategy, side by side with the old environment, migrating composite by composite.

• Part 3: building a fully patched image within minutes of an Oracle Critical Patch Update (CPU), and now even the monthly security patches.

• Part 4: the Docker Compose gotchas we hit in production, and how we solved them.

Two things made this the right time. The first is the support clock. Oracle SOA Suite 12.2.1.4 is part of Fusion Middleware 12c, and its Premier Support ends on December 31, 2026, with Extended Support running only to the end of 2027. After that you are on Sustaining Support, with no more quarterly security fixes. SOA Suite 14.1.2 sits at the other end of that scale. Per the Oracle Fusion Middleware Lifetime Support Policy, 14c has Premier Support at least through December 2030 and Extended Support through December 2033, with regular updates and quarterly security patches throughout. For a system that sits in the middle of a customer's production integrations, staying on a release with active error correction and security patching is not optional. Keep in mind that there is a long-term plan to continue development of Oracle SOA Suite as got just recently outlined in the Fusion Middleware statement of direction.

The second driver is functional. 14c brings a number of real improvements, and the one that mattered most for this customer is the handling of REST requests. In particular, 14.1.2 adds multipart/form-data support to the REST binding, for both inbound and outbound file handling, which we need from time to time for requests that carry attachments. That let us drop some of the awkward workarounds we had been carrying on 12c.

The whole thing lives on OCI. Production is a single VM.Standard.E6.Flex running three containers: the WebLogic Administration Server, one SOA Managed Server, and an Oracle HTTP Server (OHS). The OHS sits between an OCI Load Balancer (which terminates SSL) and the SOA Managed Server, so the only externally reachable component is further isolated from the application tier behind it.

Dev and Test share a second VM.Standard.E6.Flex, running six containers in total: a full three-container stack for each of the two environments. Putting dev and test on one host is a deliberate licensing choice. With 2 OCPUs mapping to a single Oracle processor license, one machine comfortably covers both for the vast majority of dev/test scenarios. Running two complete SOA environments on one host does take a small networking trick, which I'll come back to in Part 4.

You might reasonably ask why we run our own containers at all, rather than using Oracle SOA Suite on the OCI Marketplace, which will provision a managed SOA Suite environment for you. The Marketplace offering is a fine starting point, but it provisions SOA Suite as a traditional WebLogic domain on a VM that you then patch in place. We wanted the opposite: an image we build ourselves and replace as a whole. The reasoning is mostly about patching, so I will save the detail for Part 3, but in short, building our own image is what lets us treat a patch as a container restart instead of a maintenance window.

Oracle SOA Suite Architecture in Docker

When I wrote the original 12c overview, certification was the part I was least comfortable with. The Docker support note covered Oracle WebLogic Server and Fusion Middleware in containers, and there was a separate, clear statement that SOA Suite was certified on Kubernetes. But whether an advanced Fusion Middleware component like SOA Suite was certified for production in plain Docker, without Kubernetes on top, was genuinely unclear to me. I ran it that way without ever hitting a problem, but "it works for me" is not the same thing as "Oracle certifies it."

With 14.1.2 that gap is closed, and you can read it straight off Oracle's public certification page.

On the Supported Virtualization and Partitioning Technologies for Oracle Fusion Middleware page, the Containers row (Docker and CRI-O, on Oracle Linux 8 UL10+ / Oracle Linux 9 UL4+) now lists Oracle SOA Suite explicitly, both 12c (12.2.1.4) and 14c (14.1.2.0), alongside WebLogic Server, Coherence, and Fusion Middleware Infrastructure. This is a separate row from the Kubernetes entry. In other words, SOA Suite in a plain container runtime is no longer something you infer; it is named, in the certified-containers row, for production use. The detail reference is KB766220 (formerly Doc ID 2017945.1).

Two things worth highlighting for an architecture like ours:

• Oracle HTTP Server 14.1.2.0 appears in that same Docker/CRI-O row (see KB390979, formerly Doc ID 3058839.1). That matters here, because our OHS tier is a container too, so the load-balancer-to-OHS-to-SOA chain is certified end to end.

• Kubernetes is now the option, not the requirement. SOA Suite on Kubernetes (via the WebLogic Kubernetes Operator) is still certified and documented under KB467628 (formerly Doc ID 2734437.1), and it is the right choice when you want declarative scaling and orchestration. But for a small, single-host topology, which is exactly what many SOA Suite installations actually are, you no longer have to take on an entire Kubernetes stack just to be on supported ground.

For us that's the whole point. A two-VM, plain-Docker deployment is now a fully supported, certified production topology, and we get to skip the operational weight of Kubernetes for an environment that genuinely doesn't need it.

That settles the "are we allowed to do this" question. The far more interesting question is what containers actually buy you in day-to-day operation, and the biggest win by a wide margin is how fast you can react to Oracle's patches now that there is a monthly security cadence on top of the quarterly CPUs. That's Part 3.

But first, in Part 2, I'll cover how we got onto 14.1.2 in the first place: not by upgrading 12c in place, but by standing the new environment up next to it and migrating composite by composite.

This is Part 1 of a four-part series on running and upgrading Oracle #SOA Suite 14c in Docker at Broadpin.