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.
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.
Top 40 Docker Interview Questions and Answers (2023) - Intellipaat
More information can be reviewed at the Docker site 
What is a Container? | Docker
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.
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.
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.
No, you can continue to use the other supported version of the collector's software.
Yes. Auvik will continue to offer Windows installer service
Installing the Windows collector using the Windows installer
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.
Debian 12 (codename: Bookworm) – Debian -- Debian “bookworm” Release Information
- 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.
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.
-
Manually to the single docker container -
-
Auvik will not provide recommend or support for the configuration and use of any third-party updating of Docker containers.
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:
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.
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 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
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
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
