How can we help?

Docker FAQ

Follow
Things to Know

Auvik is now going to be offering a new version of its collector software. In offering this new version of the collector, Auvik is attempting to provide an extensible version of its collector. There are many different installation types of Docker containers. Containers can run virtually anywhere, greatly easing development and deployment: on Linux, Windows, and Mac operating systems; on virtual machines or on physical servers; on a developer's machine or in data centers on-premises; and, of course, in the public cloud.

In offering a Docker Collector, clients are required to understand how Docker Containers work and are maintained. Auvik will only provide first-level support for a Docker Container deployment. Auvik will treat support for this Collector Docker Container as it does as a Docker Service on a Windows machine. Auvik will make sure it will run as long as its set up correctly in the container. Auvik will support issues with the collector software but cannot support the Host or hub of the Docker Collector Container.

What is a Docker?

Docker is a set of platform-as-a-service products that use OS-level virtualization to deliver software in packages called containers. The service has both free and premium tiers. The software that hosts the containers is called Docker Engine. It was first started in 2013 and was developed by Docker, Inc. (1). Docker is a tool designed to make it easier to create, deploy, and run applications by using containers. Containers allow a developer to package up an application with all of the parts it needs, such as libraries and other dependencies, and ship it all out as one package. A Docker Container allows users not to install a whole OS as is done with VMware or hyperV virtual machines but take advantage of the Host OS and can run as a self-contained package.

Think of a Docker image as booting a VM off an ISO instead of a full Virtual machine.

More information can be reviewed at the Docker site

Why is Auvik building a Docker collector?

Auvik is building a Docker collector to make its Collector more flexible and extensible. With the termination of building any future version of the OVA Ubuntu collectors past 22.04, Auvik needs to be able to provide clients with a way to create a lightweight collector they can use in virtualized and hardware-independent situations. Docker-based collectors are a simple, proven technology auvik can do this with. A Docker Collector will allow clients to install a collector on machines they were not able to before. It will also eventually lead to the ability to install on network hardware that allows for Docker collectors to be installed.

What is Auvik trying to solve with this solution?

Auvik no longer wants to be limited by hardware for its collector.

Auvik is frequently asked how it can install a collector as a client's site without having to build a VPN and try to ensure that several VPNs to a shared collector have different IPs set up to devices internal to the network that can be monitored. With the release of the Docker collector solution, you can install the collector on any network hardware that allows Docker to run on it, possibly a NAS, firewall, AWS, or Azure instance. The Docker image grants almost limitless possibilities to run the collector.

What does it mean that the Auvik docker collector is running under Beta?

Since the Docker Collector will have a much more varied installation base, Auvik cannot promise functionality under all situations. Auvik will use this public Beta to understand how its customer will want to take advantage of the Docker Collector and where and what it will be installed on. Auvik can then react accordingly to the feedback and input os receives.

Do I have to use a Docker container?

No, you can continue to use the other supported version of the collector's software.

What Installation Options Are Available

Can I still use the Windows Service on a Windows desktop?
Can I still use the Ubuntu 20.04 or 22.04 version of the collector?

Yes. As long as Ubuntu supports the Long Term Support (LTS) versions of these OSes, Auvik will support the collector software running on them.

Are there differences in how the collector functions under Docker vs the Windows service or Linux versions?

Other than the differences in the Host OS, the functionality of the Docker Collector will be the same under OS it is installed on. To be flexible for other environments, the docker container emulates the required hardware while being a base x86/x64 container. If it runs under a different architecture than an X86/x64, it will take a performance hit due to the emulation. You will need to increase resources from other collector baselines accordingly.

What OS will this base image of the Docker container currently run under?

Debian 12 (codename: Bookworm) –

How do I set up a Docker container?
Are there any known limitations on this Docker Collector?
  • Docker installation: Auvik is providing a Docker Container of its collector to allow flexibility for installation in different environments. This image is built on an x86/x64 platform. This means installing on hardware other than that will require emulation by Docker to run. This will impact the collector's performance from what it is on native hardware. While this “emulation mode” is not fully supported by Auvik at this time, additional resources may be required for optimum performance if it is used.
  • Image auto-updates: Due to the nature of docker images, we cannot offer auto-updates of the Auvik Networks collector image. Some users leverage sidecar images such as Watchtower to monitor and auto-pull the latest docker image of their active containers. It is recommended that users manually handle pulling and updating the docker image to ensure no braking changes and that their collectors remain active.
How do I keep my Docker collector up to date?

The operating system of the Host of the container should be \kept up to date with either manually installing updates or a patching software system that you already use.

For the docker container itself, you will need to update the container periodically. This can be accomplished in several ways:

Make a statement about the Orchestrator differences disclaimer on the differences.

How should I size the resources for the Docker collector?
How do I adjust memory, CPU, or disk size for a Docker Collector?

This depends on how the docker image was deployed. Each deployment strategy has their own configuration of how to control CPU, memory, disk size limits (see links below).

General help links:

Can I Run the Docker Collector in other Environments?

In theory, yes. This is one of the reasons Auvik has built a docker container collector.

The Docker image Auvik is releasing is basically an x64-based VM. This means that it can be run natively on computers/servers with an Intel/AMD-based CPU. Hardware Emulation on other architectures is not fully supported in this beta. Auvik Support will only be able to assist successful docker installs on Support environments. Best efforts are in place for the most typical uses.

This means that if a customer has a Kubernetes cluster, they could run the docker image as a Kubernetes service. Kubernetes is just a container orchestrator (ensuring the configured system is running as expected). As a user of Kubernetes, you give the cluster/system a set of nodes. AWS EC2 instances can provide these nodes as well as MS Azure Cloud or Google Cloud.

As for Firewalls or NASes, the short answer is a "yes, but with a VERY large asterisk." The device has already got to support Docker containers. If it does not, Auvik cannot configure it to do so.

With the multitude of different ways to use a Docker container, Auvik has not been able to validate all environments that it may be run under. During this Beta, there may be instances where the Docker collector does not work properly. Auvik asks that you report these instances to Auvik support so it can research solutions or limitations.

Will the Docker collector auto scan my network?

This is dependent on how the networking is configured for the container. The configured networks can be listed and inspected using docker network ls and docker network inspect .

When configured to use bridged mode, the Docker engine will assign an IP address from the docker bridge network to the container. As such on initial connection of the container, the Collector may attempt to auto-scan the docker subnet. This can be addressed by navigating into the Discovery Manage Networks tab, and disabling scanning of the subnet. If scanning is not disabled, it is possible that other docker containers will appear on the map as additional Generic Devices.

When configured to use host mode, the Docker engine will start the container within the host machines network, removing any network isolation. This will result in the container IP address being that of the host machines. As such, on initial connection of the container, the Collector will attempt to auto-scan the host machines subnet. This is the same behaviour traditionally seen when using the Linux OVA or scripted install solutions.

Additional information on Docker network configuration can be here: Network drivers overview

Does Auvik have a sample file of the setting typically used for a Docker Collector Container?

Docker Desktop Command
docker run -it \
--name nanook \
--hostname nanook
\
--cap-add NET_ADMIN
\
-e
AUVIK_USERNAME="nanook@auvik.com" \
-e
AUVIK_API_KEY="nanook-test-key" \
-e
AUVIK_DOMAIN_PREFIX="nanooksmsp" \
-v
'./config:/config' \
-v
'./etc/auvik:/etc/auvik' \
-v
'./logs/:/usr/share/agent/logs/' \
auviknetworks/collector:latest
Docker Compose
version: "3.8" 
services:
collector:
image: auviknetworks/collector:latest
container_name: "nanook"
hostname: "nanook"
environment:
AUVIK_USERNAME: "nanook@auvik.com"
AUVIK_API_KEY: "nanook-test-key"
AUVIK_DOMAIN_PREFIX: "nanooksmsp"
cap_add:
- NET_ADMIN
volumes:
- './config/:/config/'
- './etc/auvik/:/etc/auvik/'
- './logs/:/usr/share/agent/logs/'
restart: unless-stopped
Kubernetes Service
apiVersion: v1
kind: Secret
metadata:
name: auvik-collector
stringData:
nanooksmsp-api-key: bmFub29rLXRlc3Qta2V5Cg== # base64 encoding of nanooks api key
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: collector
namespace: collector
labels:
app: collector
spec:
serviceName: collector
replicas: 1
volumeClaimTemplates:
- metadata:
name: config
spec:
accessModes: [ "ReadWriteOnce" ]
resources:
requests:
storage: 16Mi
- metadata:
name: etcauvik
spec:
accessModes: [ "ReadWriteOnce" ]
resources:
requests:
storage: 32Mi
- metadata:
name: logs
spec:
accessModes: [ "ReadWriteOnce" ]
resources:
requests:
storage: 16Gi
selector:
matchLabels:
app: collector
template:
metadata:
name: collector
namespace: collector
labels:
app: collector
spec:
restartPolicy: OnFailure
containers:
- name: collector
image: auviknetworks/collector:latest
volumeMounts:
- name: config
mountPath: /config/
- name: etcauvik
mountPath: /etc/auvik/
- name: logs
mountPath: /usr/share/agent/logs/
resources:
requests:
memory: "4Gi"
cpu: "2"
limits:
memory: "4Gi"
cpu: "2"
env:
- name: AUVIK_USERNAME
value: "nanook@auvik.com"
- name: AUVIK_DOMAIN_PREFIX
value: "nanooksmsp"
- name: AUVIK_API_KEY
valueFrom:
secretKeyRef:
name: auvik-collector
key: nanooksmsp-api-key
Was this article helpful?
0 out of 1 found this helpful
Have more questions? Submit a request