First of all thanks a lot for this great application!
I wanted to let the community know that I had created a Docker image of LibreNMS based on Alpine Linux with the main following features :
Alpine Linux 3.8, Nginx, PHP 7.2
Cron tasks as a “sidecar” container
OPCache enabled to store precompiled script bytecode in shared memory
This image includes the minimum requirements for better performance. This is why a docker-composer file is set up to facilitate scalability and operational maintenance :
Traefik as reverse proxy and creation/renewal of Let’s Encrypt certificates
Memcached image ready to use for better scalability
RRDcached image ready to use for better scalability
Postfix SMTP relay image to send emails
MariaDB image as database instance
Cron jobs as a “sidecar” container
If you have any questions, feel free to open an issue on the GitHub repository.
Yeah, it is only used for distributed polling. I guess if you want to allow that out of the box.
The funny thing is memcached used to be used inside LibreNMS, but it massively slowed things down. That got ripped out, so it is only used for distributed polling. Also, if you use the BETA librenms service, it uses redis instead of memcached so in that case there is no use for memcached.
Neither memcached or redis or used for any sort of caching at this time. Only distributed locking and queueing.
I don’t want to belittle your work by no means, there’s no doubt you gave a lot of thought and time into this, however putting every other component to a container is a bit of over-engineering IMHO. I also think it complicates the monitoring and backups etc of the monitoring system itself, but of course everyone has their own preference of how they should manage their systems.
Just my two cents
Well, depends how you define an “service”, you can call whole LibreNMS with it’s dependencies and enchancements including rrdcached as an “monitoring service”
And recommended does not mean, that you have to divide everything into subcomponents, or you would have to start splitting by cron, web server, rrdcached, pollers, discovery, etc…
@Etz If you are on a cluster environment (swarm, k8s) you will have problems with this logic.
Imagine you want 5 replicas of LibreNMS. If cron is included in your image, your cron will be launched 5 times (as a simple example).
@CrazyMax This is a great container for Swarm/K8s purposes, I agree. I have recently built a lab instance with separate rrdcached, memcached, webserver, mysql, and multiple poller containers but I had not yet created a compose file nor migrated to alpine. The cron sidecar and traefik load balancer are interesting additions, would you mind explaining your reasoning behind each? Specifically, why traefik over nginx (I suspect the letsencrypt renewal is a traefik builtin? That would be very interesting!)
Thank you for the fast forward - I shall definitely be trying it out!
traefik is great for letsencrypt (a bit like caddy) but also does load balancing and high availability. That being said i had great trouble getting traefik to work like i want it in a swarm mode cluster with Consul for SSL config sharing, i saw a few weird behaviours .
It’d be interesting if anyone got LibreNMS working in a swarm cluster but i see a few problems, for one, you would have to use a network volume driver and RRDCached is really IO intensive and from my experience you will encounter slow down and major issues writing across network drives.
Maybe for this image support for device Syslog would be a nice addition
@psb The sidecar container pattern approach (used here for cron) is a Docker “best practice” to manage microservices architectures. “A sidecar runs alongside your service as a second process and provides ‘platform infrastructure features’ exposed via a homogeneous interface such as a REST-like API over HTTP.” From a logging standpoint, the advantage of a sidecar approach is that each container is linked to its own logging container. Here only cron logs are relevant if you want to push them to a logger manager like Graylog, ELK or Splunk.
Traefik is a Docker-aware reverse proxy that includes its own monitoring dashboard. It’sa wonderful piece of software written in Go language that gives everything that we need, and it can do much much more. In its essence it is dynamic reverse proxy. It can connect to many popular deployment platforms (docker, swarm, mezos, kubernetes, etc.) and obtain information about services (containers) :
Yes this is a connection to Let’s encrypt service and it is completely dynamic. For every Host rule (domain/sub-domain) that appears in Traefik, it will go to Let’s encrypt and obtain key and certificate (store them in acme.json file) for that host configuration.
Technically, you can setup PHP on the frontends to use memcached to store session data, allowing you to load balance the front-end and use the same session among any node being load balanced, so you don’t have to login again when you get shunted to a different web-server… but not sure why you need that on a single node instance…
I will work on it but I still need to adapt the image for the distributed poller mode. I think I’ll come to you on Discord because I’ll probably have some questions about implementation.
