Autodeploying applications on containerized weblogic instances

How a simple automatic deployment plugin turned into a wild bantha chase

Storytelling

This week, I started working as a freelance software consultant. Since I am very new to the team, I was actively looking to contribute something of value to the team as soon as I could. Today I was asked to do a simple task: updating some library and deploying all dependent applications on the development servers.

As I was doing this, I realized my team has a manual process for installing application on their containerized weblogic 12.c servers. Remember the ‘containerized’ part, it will play a significant role in the rest of the story.

If you know me, you know I am quite lazy and hate menial tasks that I believe a computer can do better. That’s basically the reason I got into computer science in the first place. After convincing my client of the advantages of semi-automatic deployments, he gave me some time to execute a so called technical spike. It’s basically a set amount of time you are allowed to work on proving that a technical solution is actually possible. Since your efforts are timeboxed, your client is sure you won’t spend all of your allocated budget on doing something you think is cool instead of delivering the feature they originally requested.

So there I was, overjoyed that I got to use my past experience to try and improve my new team’s everyday coding process. I dove right in and had my Maven configuration done in under an hour. Things were looking good, and I launched the first deploy command to the weblogic container on our dev server. I was treated to a demoralizing wall of red text scrolling over my terminal window. My local machine could not establish a connection to the dockerized weblogic server. Having set up a Maven command line deploy to a weblogic server in the past, I could not figure out what was the root cause of the problem. After fighting for a while, my time ran out. So I went back to my original task, feeling highly disappointed.

Untill I stumbled on some information in the dark corners of the internet later that evening. (I have a compulsive need to know why my stuff doesn’t work the way it is supposed to, especially when I suspect the infrastructure to be responsible)

The technical problem

Oracle Weblogic servers use the t3 protocol to receive administration/control calls. By default, port 7001 is assigned to listen to such calls. As it turns out, the protocol does not play nice with containerization. Meaning that somehow, somewhere, there is an issue when your container software maps it’s external facing port to a different internal port. For me the original set up was having port 30193 map to 7001. With this original set-up, Maven would always give me long red error messages stating that it could not establish a connection to the administration server.

So, how do we fix this? It’s actually quite simple. Since t3 does not play nice with port mapping, we set the docker host port to be the same as the internal port. So we set up an identity mapping. For me, that would be either 90123:90123, or 7001:7001. The second is the easiest solution, and works perfectly when your server machine only has one running docker weblogic container. On my project though, our servers host upwards of 10 docker containers. We use port mapping and incremental port numbers to differentiate between containers, that each hold a few specific components of the overall application. So, we go with mapping the custom port to itself. The next step is to make weblogic listen to this port, and accept incoming admin requests. In weblogic 12.c, you do this by following these steps:

• log in to the weblogic administration console
• open your server settings (Environment -> [Server name]).
• navigate to the ‘protocols’ tab
• in general settings, enable ’tunneling’
• save
• open ‘protocols -> channels’
• create a new channel for the t3 protocol, on the port you mapped (for me, 90134)
  • use this for both internal and external listening port
• save
• And there you go! You should now be able to control your weblogic administration server through the maven-weblogic-plugin.

High level details of the set-up

Since setting the entire thing up is a but more complicated than it seems at first glance, here is an added bonus of some of the things I have noticed while replicating this case from scratch.

• Oracle weblogic docker images are not that easy to get. The official repository requires you to make an account and accept a license agreement before allowing you to download the images. I have found some ‘alternative’ versions on code sharing websites, but would not use these in a professional environment.

• There is a codehaus version of the weblogic-maven-plugin. This plugin does not work the same way as the official oracle plugin. The official plugin is harder to find and install though. The one you want to use is the com.oracle.weblogic one:

<plugin>
    <groupId>com.oracle.weblogic</groupId>
    <artifactId>wls-maven-plugin</artifactId>
    <version>12.1.1.0</version>
</plugin>

• I would advise you to not put the server url, or login information directly into your pom files. As an alternative, you can work with property profiles in your local maven settings file.

• The manual fix I performed on the system (identity mapping + creation of a weblogic channel listening to this port) works on a container that maintains it’s state. If you are in the business of rebuilding containers, or are not using a persistent memory state, you want to change the weblogic configuration that get loaded in you weblogic’s container start-up procedure.

Caveat

Some things to consider:

The last few days, I was working on setting up a minimal environment to demonstrate this issue and the workaround for the purpose of this article. The set-up is not going as smoothly as I would want it to. I also have to complete the full configuration at time of writing (the spike time window expired, and I will return to the task at a later time).