NOTE: MY POSTINGS REFLECT MY OWN VIEWS AND DO NOT NECESSARILY REPRESENT THE VIEWS OF MY EMPLOYER
Deploying a containerized MID server in a Kubernetes cluster
Why?
The ServiceNow MID server is an incredibly powerful appliance to enable everything from discovery to metrics and event ingestion.
However, managing them individually can be an additional burden. Especially as its capabilities continue to evolve and the recommendation is to scale them horizontally.
As such I’ve found a way to deploy and manage containerized MID servers within a kubernetes cluster.
Let’s talk about some of the pros and cons to this approach before we dive into the how.
Pros
- Speed: A containerized MID server is incredibly quick to deploy and configure.
- Availability: Configuring this as a deployment within a kubernetes cluster ensure that kubernetes is managing the state of the MID server container and will restart or re-deploy it if a catastrophic failure occurs.
- Livestock not Pets: When you know you can quickly and easily deploy a fresh MID server why waste time troubleshooting potential issues? Kill it, redeploy, move on.
- Proximity: Especially if you’re looking at discovering your kubernetes infrastructure, deploying a MID server into your cluster(s) ensures that you’re keeping the network distance between the MID server and the discovered resources as short as possible.
- Ease: Once you’ve got this process down, it’s incredibly simple to execute.
- Scalability: Once you've got this process automated you can deploy more MID servers automatically in order to scale your capabilities horizontally on command.
Cons
- TOTALLY UNSUPPORTED: This is completely unsupported right now. There are no official MID server container images. If you call support they’ll likely tell you to deploy a supported MID server configuration.
- No Windows Discovery: Since the container image is based on a linux root you won’t be able to utilize this container to discover windows resources. It simply doesn’t have access to the right toolset and protocols to complete that task.
- Community Built Container Image: This configuration is reliant upon a container image built and posted by the community. At some point in the near future I’m hoping there’ll be an officially supported container image. Until that time this is definitely a “use at your own risk” situation.
How?
There are a couple pre-requisites that this article assumes:
- You have a working kubernetes cluster deployed.
- You have a kubectl client configured to connect to said cluster.
Once you’ve got the pre-requisites out of the way, I’ll share the YAML files I’ve built for this and then talk through their methodology.
Overview:
- Build Infra Namespace
- Build Kubernetes Secret
- Configure Deployment Manifest
- Deploy the MID server
- Update and Validate the MID server
Build Infra Namespace
The first thing I recommend is to create a Namespace to be able to collect all of the infrastructure tools into a single namespace. I use this in my clusters in order to maintain separation of the tools from the standard workloads.
Build a YAML manifest file containing the following:
kind: Namespace
apiVersion: v1
metadata:
name: infra
labels:
name: infra
Once that’s completed deploy the namespace with the following command:
kubectl apply -f <YOUR_FILE_NAME>
Then you can confirm that its been deployed with the following command:
kubectl get namespaces
Build Kubernetes Secret
Kubernetes has a built in method for storing encrypted information that can be shared among pods securely. This is great if you want to manage passwords or utilize the same username and password across multiple pods but have it accessed securely.
What we’ll be doing in this case is building a Kubernetes Secret to store the MID server password that’s used for the MID to login to your ServiceNow instance. Once that’s completed we’ll import that password into the pod as an environment variable for the MID server software to use.
Here’s how:
kubectl create secret generic -n infra mid-server-secret \
--from-literal=SN_PASSWD='<MIDUSER_PASSWORD_HERE>'
Configure Deployment Manifest
Now that we’ve got the namespace and the secret created we can build the deployment manifest for the MID server itself. Create a new manifest file containing the following:
apiVersion: apps/v1
kind: Deployment
metadata:
name: mid-server
namespace: infra
labels:
app: mid-server
spec:
replicas: 1
selector:
matchLabels:
app: mid-server
template:
metadata:
labels:
app: mid-server
spec:
containers:
- name: mid-server
image: moers/mid-server:latest
env:
- name: SN_HOST_NAME
value: <SN_INSTANCE_FQDN>
- name: USER_NAME
value: <YOUR_MID_USERNAME>
- name: PASSWORD
valueFrom:
secretKeyRef:
name: mid-server-secret
key: SN_PASSWD
- name: HOSTNAME
value: '<MID_SERVER_NAME>'
imagePullPolicy: IfNotPresent
Note that there are other environment variables that are passed into the pod as part of the env: block. Those could also be stored in secrets or a config map. But for simplicity’s sake we’re adding them to the manifest directly.
Deploy the MID Server
Once you’ve got the manifest built it’s now time to deploy it. We’ll use the kubectl apply command in order to do so. It’s helpful to remember that if there are no net new changes to the manifest, kubectl won’t execute any changes on the cluster.
kubectl apply -f <YOUR_FILE_NAME>
Once that’s completed you should see your pod running with the following command:
kubectl get pods -n infra
The output should look similar to this:
NAME READY STATUS RESTARTS AGE
mid-server-eks-ffd9f9845-bl7d2 1/1 Running 0 17m
Update and Validate the MID Server
Once the pod shows that its in a running state, you should be able to log in to your instance to verify the MID server and validate it as you would any other MID server.
Video:
I've made an accompanying youtube video walking through this process. You can find that here.
Closing
You now have a fully running and containerized MID server. Note that this is configured purely for outbound communications. In order to configure this for Operational Intelligence or for Agent Client Collector connectivity we’ll need to configure a kubernetes service to route and allow those inbound requests. Look for an upcoming blog post on that topic!
