Build and push MID server image to ECR
We have several available containerized MID Server downloads. For this exercise, we will use the Linux Docker Recipe. Please note that based on the type of host you plan to run the MID Server, you might have to ensure you meet certain prerequisites.
In the ServiceNow instance, navigate to MID Server --> Downloads and download the Linux Docker Recipe.
Note, it is also possible to copy the download link and use a terminal with a curl /wget command to execute the download.
Upon downloading the files, unzip it in a folder. The folder will contain all the required files to build the image and configure it to our needs.
The mid.env files is used to store the environment variables, but we can also inject the environment variables in the deployment steps. In our case, we won't modify any of the files.
The Dockerfile contains the commands that will be executed to build the image.
Now that we have the files, we need to build the image and push it to the ECR repository. This can be done in several ways, in our case, we will use Docker CLI commands.
Open a terminal in the folder. Now, in AWS navigate to your newly created Private ECR Repository and click on View push commands. This will provide the commands we need to execute in order to build and push our image to the repository.
Copy the first command and paste in the terminal. This should give us back a Login Succeeded.
Copy the second command and paste it in the terminal. You can also use additional parameters on how you build the Docker image for ECS.
Upon executing the build command, we should get a trace of the successful build execution.
Copy the third command, this will allow us to tag our docker image. You can modify the tag you want to apply to the image.
The execution of this command won’t return any message. In order to check the correct tag creation, you can execute a command to see the Docker images. This should show the details of your newly tagged image.
docker images
At this stage, we have already built and tagged our image, so we are ready to push it to the repository. Paste the 4th command into the terminal and execute it. This process can take some minutes.
Now we can go back to our ECR repository in AWS and see the newly pushed image.
Creation of namespace and secret on cluster
Once we have our cluster ready and the MID Server container image in our repository, we can start with the deployment.
The deployment can be done in several manners, we are going to use environment variables and Kubernetes Secrets for the process.
We will also create a namespace in the cluster where we will enclose the resources that are part of this exercise. This is an optional step, but recommended in order to have our resources organized.
To create the namespace, we create a yaml file and paste the following content:
kind: Namespace
apiVersion: v1
metadata:
name: mid-server-namespace
labels:
name: mid-server-namespace
The configuration file defines a basic namespace creation, where name attributes will hold the naming we define.
In a terminal, run the command pointing to your newly created namespace file:
kubectl create -f namespace.yaml
Once executed we can run the following command to check that the namespace was added:
kubectl get namespaces
As part of the environment variables required for the MID Deployment, we will have to provide credentials to log in to the ServiceNow instance. While this can be done directly in plain text in the deployment file, for security reasons we are going to create a secret that will store the values for us.
To do so, we need to execute the following command:
kubectl create secret generic -n mid-server-namespace mid-server-secret \
--from-literal=SN_PASSWD='XXXXXXXXXXXXXX'
The values are as follows:
- -n mid mid-server-namespace: We are stating that the secret needs to be created for the mid-server-namespace (namespace we recently created)
- --from-literal=SN_PASSWD: we define the literal of our password. SN_PASSWD defines the key we will use for the secret.
Replace XXXX with your password and we run the command to create the secret.
We can validate it by running the command below, which will list the secrets created in our namespace:
kubectl get secrets -n mid-server-namespace
Deployment of MID server container to EKS
Once we have our cluster ready and the MID Server container image in our repository, we can start with the deployment.
The deployment can be done in several manners, we are going to use environment variables and Kubernetes Secrets for the process.
Execute the command below to check the name of your newly created namespace:
kubectl get namespaces
We now create a new yaml file, which will contain the instructions and parameters required for our deployment.
apiVersion: apps/v1
kind: Deployment
metadata:
name: containerized-mid-server
namespace: mid-server-namespace
spec:
selector:
matchLabels:
app: MIDServerManagement
provider: ServiceNow
replicas: 1
template:
metadata:
labels:
app: MIDServerManagement
provider: ServiceNow
spec:
containers:
- name: containerized-mid-server-cluster
imagePullPolicy: IfNotPresent
image: XXXXXXXXX.dkr.ecr.eu-central-1.amazonaws.com/containerized_mid_server:latest
env:
- name: MID_INSTANCE_URL
value: https://XXXXXXXXX.service-now.com
- name: MID_INSTANCE_USERNAME
value: XXXXX
- name: MID_INSTANCE_PASSWORD
valueFrom:
secretKeyRef:
name: mid-server-secret
key: SN_PASSWD
- name: MID_SERVER_NAME
value: "containerized MID Server"
From the code above, the parameters are as follows:
- metadata – name: name we give to our deployment.
- metadata – namespace: target namespace for our deployment.
- spec – matchlabels: labels and selectors.
- Spec – replicas: amount of replicas to deploy. 1 in our case.
- spec – spec – containers: parameters to specify the details of the container running our MID server.
- Name: name of the cluster we will run our container. (our new cluster name).
- imagePullPolicy: specifies when will image be pulled.
- Image: the URI of the image to deploy. In our case, it will be the URI of the ECR Registry we created in step Build and push MID server image to ECR. We can get the URI from AWS by navigating to: AWS--> ECR--> repository_name --> Copy URI.
- Env: contains the environment variables parameters we will use for our deployment. In our case, we use only:
- MID_INSTANCE_URL: url of your serviceNow instance
- MID_INSTANCE_USERNAME: username created in step MID Server configurations in ServiceNow instance
- MID_INSTANCE_PASSWORD: we get the value from the secret we created in previous step.
- MID_SERVER_NAME: name of the MID server (this value will be displayed in the MID Server list in your instance)
Make sure to replace XXXX with the values in your case and update the other parameters as needed.
The MID Server accepts more parameters (see documentation), you can add the required following the same format.
After updating the deployment file, we launch the deployment from a terminal by executing:
kubectl create -f dpl.yaml
The execution of the command should give us a response such as:
deployment.apps/containerized-mid-server created
In order to check the correct deployment, we launch the command below:
kubectl get deployments -n mid-server-namespace
Validation and troubleshooting of containerized MID Server deployment
We will first check that the pods in our cluster are running correctly:
kubectl get pods -n mid-server-namespace
We should see that our pod are in READY 1/1 and the STATUS is Running. Other values might indicate there
were issues on the deployment.
We can easily get more details on the deployment process by executing:
kubectl describe deployment containerized-mid-server -n mid-server-namespace
If we require even further details, we can always use Logs command to fetch the logs from the pod. The logs will show the execution of the MID Server.
kubectl logs containerized-mid-server-XXXXXXX -n mid-server-namespace
We are now confident about the successful deployment of our MID server, so we open our ServiceNow instance and navigate to Discovery-->MID Servers.
Our MID Server should appear in the list, but will not yet appear with a Validated status.
Last missing step is opening our MID Server and clicking on Validate. This will restart and validate our containerized MID Server, making it operative.
You can now see the live containerized execution logs, simply executing the logs command again (you will see that the mid server restarts in order to finalize the validation).
See the Containerized MID Server series:
- Creating ECR repository and EKS cluster for MID Server [Containerized MID Server series 1/3]
- Building & deploying containerized MID Server on AWS EKS [Containerized MID Server series 2/3]
- Service Account for containerized MID Server [Containerized MID Server series 3/3]
References
Deploying a containerized MID server in a Kubernetes cluster
