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. 😉