Is there a containerized MID server (Docker/etc.)?

[Kerry Hormann]

Is anyone working on a containerized version of the MID server software?  I have built my own stuff, but the Tanuki service wrapper is REALLY getting in the way, basically making the container idea non-workable.

If you like the idea of containerization but don't have a solution, please up-vote the idea I posted on this forum!

[Philip Van den]

Hey Kerry,

Great idea.

However, having fully installed containers will cause more issues than solutions due to duplication. Also, you need to perform some actions on the platform side to get things sorted.

Have you considered the following:

• use default container containing some basics
• use Ansible (or other automation) to install the midserver on the container
• figure out if you can register and validate the new midserver using the API and custom Ansible module

Let me know what you think about this.

[Kerry Hormann]

Thanks Phillip,

Yes, I have created a configuration management module (we use Puppet) to install the MID server, but that's not the question.  To go this route, you need to have:

• a machine (physical or virtual) for each MID server
• with an operating system
• with appropriate IP and DNS entries
• with security settings (firewall and remote access)
• declared state (packages, settings, etc.) for more than just your app

This also usually includes licensing costs for "managed nodes" in your CM environment, and even for VMs in some environments.

Once an organization decides to make the significant change to move from "server" to "container" infrastructure, the idea of using CM to install software is somewhat nullified.  At best, CM can be used to manage the desired state of individual settings, but it's not appropriate (or even possible sometimes) to run inside a container.

It is common to use a "persistent storage container" to store configuration and persistent bits (logs, settings, files, etc.) so that the application container can be updated/destroyed/recreated at will.

How the MID server is added to and verified within the NOW platform is not what needs to change - that process can remain as-is.  I do not see a need to dynamically add MID servers.  The part that I would like to address is how the application is deployed and updated.

The Java process wrapper that is used makes it impossible to host multiple MID servers on a single system (unless this has been fixed recently??), multiplying the management of all these systems (we have no less than 12 at the moment, and this will likely double in the near future).  Getting rid of this (ahem...) "helper" software is a priority for me, but it's even more pressing in the light of the move to Kubernetes.

[Philip Van den]

Hey Kerry,

You should be able to install multiple mid servers on a single system.

https://docs.servicenow.com/bundle/orlando-servicenow-platform/page/product/mid-server/task/t_Instal...

Didn't try it yet but should work out of the box.

If you would not duplicate containers, you should be able to have a container image for every unique mid server. 

I do think there is a limitation that it is not possible to create services for each mid server, but you can work around this...

Also, the updating and management of the mid server application can be done from the ServiceNOW platform, I would first try to leverage this.

I would advise to get in contact with your ServiceNOW represetative and SC to discuss this in more detail. I feel like I am missing a bit information to fully understand your solution.

[Kerry Hormann]

Phillip, thank you for that link, and thank you for the discussion.  I posted this hoping that I was missing something, but also to spur community support (via the idea portal) for this, if others are interested.

For now, it seems like containerization is not on the ServiceNow radar.  And you are right - following-up with our sales channel to see if I can get traction there is a great idea.

Regarding the docs, it is good to see that they've attempted to fix the one-MID-per-server issue, but the documentation still states: "Only one MID Server service can be a daemon on a Linux host. This is a limitation of the Tanuki wrapper service."  And since an application on system isn't of much use if it's not running (thus the idea of a daemon), this isn't really a solution.

I have tried writing my own service units, and they work well - until the update script runs.  The real issue is that the updater does not seem to allow for (or expect?) more than one MID installation, and ends up breaking one of them (usually not the one being upgraded).  As I said before - the Tanuki wrapper is trouble - it's either not robust enough for this "advanced" usage or it's just broken.  Either way, it's being very unhelpful.

But again, my question goes beyond running daemons on linux servers - this is about using our container infrastructure (and a single helm file) instead of maintaining a pile of servers.  I have also tried to create a "persistent container" (like a "container-as-a-VM") that runs the MID software, but again, the Tanuki wrapper gets in the way and the upgrade never completes.

Bottom line - there are better ways of daemonizing software than using the Tanuki wrapper.  Personally, I would release RPM/DEB/PKG/AUR/etc packages, because I have experience doing this.  But the containerized solution goes beyond that - a dependency-free application that requires no platform-specific package or customization.  The container has all the binaries it needs to run on a Linux (or Windows) kernel - there is no hypervisor, and the only virtualization done is for storage and networking.