After the brief introduction (Having Fun With Docker – Part #1), it’s time to share the fun that we had for the last months preparing ATG to run inside Docker. Sorry if I turn this article in something technical and feel free to make any suggestion or comments.
During our journey we’ve learned, what I consider the most important change that we must consider and use it, Immutable Infrastructure, I’ll try to not go too deep on it (even that is too hard to me not to do it). Simplifying, containers must be completely static, if we need to change it, we must create a new version of the container, we cannot accept any change after it’s running. Basically, if we need to update some file, change some configuration or any other change that we need to do, we must create a new version of the container’s image.
Now, back to our goal, how to pack ATG and all his dependent components in to scalable containers. The first step was to understand how to build a minimal WebLogic structure, my first idea was to have containers running only the managed server, it was also my first “deception”. This option showed me that we could create an unmanageable monster and I wasn’t sure if this approach will have some real benefit or if some developer will want my head when I show him too many management consoles. I chose an approach where our containers will depend on some external services, like Admin Server, which will end having more than one service running (NodeManager and ManageServer). Find this “limit” of how many services must be in the same container showed not that hard. If you keep in mind, that only what must be running in the same server/virtual machine to have the services working then you probably found your answer about what should be in the same container.
Based on how WebLogic works, it needs a domain which is the entity in charge of all configurations, considering the ATG, multiple domains, will create the unmanageable monster, and the chances of success will be really low.
At this time, some developers to whom I was talking about it, got pretty sceptical if this is really possible, but I’m persistent (some say that I’m stubborn), which means that before standing the white flag, I’ll probably make it work.
What I’ve learned from my other tests, is that to make the containers solution a success they must be “smart” enough to configure itself and find his dependencies during the start. Better if they can survive to human beings (we all make mistakes) and grow without any help, which will give me time to have fun with other stuff.
After few more tests (may be not just “few”), and using what we had built to automate ATG installation we figured out that having a single domain with an Administration Server reachable by the new containers will be probably the best choice, and can even allow us to have mixed environments with legacy infrastructure, with modern, fancy and elastic containers.
Before someone think that at this moment I could start hating Docker on complex applications, that caused the opposite, the challenge to convert some regular clusters into scalable cluster which are able scale up and down, without the need of a explicit “master service”. That made me find ways on how it can work, how dynamic it can be and where I can use those concepts. But the most fun part is scale an ATG environment from 1 page server to 10 with only 9 clicks. Don’t think that the journey was easy and was finished. We took several months to have something running, and as all algorithm they always can be improved.