Deploying OMS for Docker via Rancher

Introduction
Today we’ll be deploying Microsoft Operations Management Suite (OMS) for Docker via Rancher… Sound cool? It is! Basically we’re going to do the following guide and add Rancher to the twist.

For those unfamiliar with the Microsoft offering and more knowledgeable  in the OSS community. Imaging OMS as being the Microsoft counterpart of a typical ELK stack. The advantage is that it’s managed and that there are already a lot of integrations possible.

Preparing the host
The host I used is an Ubuntu 16.04 (Xenial). So we’ll need to follow the systemd part… So go to the following file (/etc/systemd/system/multi-user.target.wants/docker.service) and update the highlighted lines

root@docker02:/etc/systemd# cat /etc/systemd/system/multi-user.target.wants/docker.service
[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
After=network.target docker.socket
Requires=docker.socket

[Service]
Type=notify
# OMS added :
Environment="DOCKER_OPTS=--log-driver=fluentd --log-opt fluentd-address=localhost:25225"
# the default is not to use systemd for cgroups because the delegate issues still
# exists and systemd currently does not support the cgroup feature set required
# for containers run by docker
ExecStart=/usr/bin/dockerd -H fd:// $DOCKER_OPTS
ExecReload=/bin/kill -s HUP $MAINPID
# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
LimitNOFILE=infinity
LimitNPROC=infinity
LimitCORE=infinity
# Uncomment TasksMax if your systemd version supports it.
# Only systemd 226 and above support this version.
TasksMax=infinity
TimeoutStartSec=0
# set delegate yes so that systemd does not reset the cgroups of docker containers
Delegate=yes
# kill only the docker process, not all processes in the cgroup
KillMode=process

[Install]
WantedBy=multi-user.target

Once that’s been done, reload systemd and restart the docker.service

root@docker02:/etc/systemd# systemctl daemon-reload
root@docker02:/etc/systemd# systemctl restart docker.service

Deploying the OMS agent via Rancher
To deploy the agent, use the following docker-compose file ;

omsagent:
  ports:
  - 127.0.0.1:25224:25224/udp
  - 127.0.0.1:25225:25225/tcp
  environment:
    WSID: <your workspace id>
    KEY: <your key>
  labels:
    io.rancher.scheduler.global: 'true'
    io.rancher.container.pull_image: always
    io.rancher.scheduler.affinity:host_label: deployoms=true
    io.rancher.container.hostname_override: container_name
  tty: true
  image: microsoft/oms
  privileged: true
  volumes:
  - /var/run/docker.sock:/var/run/docker.sock
  stdin_open: true

(Sidenote ; Remove the scheduler.affinity if you do not want to use a certain label… The above docker-compose will launch OMS on -all- hosts with the label “deployoms” set to “true”)

After a few seconds/minutes it’ll be started…

And you can see from the shell that it’s doing -something- 🙂

Let’s check the footprint… It’s about 36MiB, which is kinda fair for what it does.

 

Validation in OMS

And yes, we can see our data in OMS ;

One improvement, as you might have noticed… I’m using the container name as hostname for OMS. Which doesn’t make it easy to map a hostname to the container. That’s definitely something to improve, though it was a bit out-of-scope for my brief 5″ PoC. 😉