I’ll keep my idea of not having a pretty long article. Creating those “small” parts/chapters allows me to release something new in a weekly base or at least twice a month. In this one I’ll give a little attention on how we draw the layers of our OracleCommerce Docker images.
But before we begin, let’s list some components that we’re using with OracleCommerce. The most important, that I must mention are: Endeca with Experience Manager, Oracle Database, WebLogic and Apache. I’ll give you a quick explanation about what we did on each one.
At this stage, we decided to simplify the Endeca container, not contemplating auto-scale neither self config. However, what we’ve done was, create the base image and add an upper layer with the application, importing it and creating a multi process container.
For the Oracle Database, we’ve created our own base image based on what Oracle shared at GitHub. After creating our image obeying some of our compliance rules, we’ve created the next layer with an initial dump which later will need to receive some extra updates through Flyway.
Now lets drill deep a little in the main subject of this part: How we draw the Layers of OracleCommerce Containers. The first layer is the operational system with all requirements for OracleCommerce. This one is based on Oracle Linux and will be used on all containers in this solution. Next two layers are part of the same software, they are WebLogic and over it are the latest PSU or any other patch needed. Right above it is the OracleCommerce Layer with all patches needed for the project. The next layer contains all packages that must be deployed on WebLogic and need to be seen by AdminServer.
The last but not least is what we called Domain Layer, which I consider one of the most important part of the whole solution. Once it has the scripts and configurations to start and create objects inside WebLogic Domain, it allows us to scale up/down the number of Page Servers with the whole system online. This layer is also updated every time that we need to change some configuration on any managed server, like, the maximum number of JDBC connections, allowing us to be pretty close to an Immutable Infrastructure.
This whole set of layers allows us to apply new patches to WebLogic or ATG and propagate it to all containers, simply by rebuilding them. Even that doesn’t happen to often, it also allow us to quickly roll back if something doesn’t work well. One of main important thing is that it allow us to have exactly the same WebLogic, OracleCommerce on all environments, Development, Quality Assurance and Production, almost ending with the “works for me”.
Ok, writing those articles I may have caused the impression that this work was simple. One thing I can assure, it was a long journey, we started this project in mid 2016, with some containers for developers. Only that part took around 6 months to have something to make them happy. Ok, none of us where fully dedicated to this initiative, but when we found the right people, to assist me, and a project manager that allowed us to abduct them for some hours per day from their project, we could accomplish the hard part which was the OracleCommerce “customizations”.
After this journey we ended with an OracleCommerce with the ability of auto-scale. This wasn’t our main objective when we started and probably we’ll not using it right away, but this was a good consequence from what we had to create to allow us to dynamically add agents.
Probably next parts of “Having Fun With Docker” will not include OracleCommerce, but other stuffs, like, Stacks, Networks, build and so on… feel free to contact me for some extra details.