MENU
If you have been watching our announcements, you know we have recently released a major new version of GroundWork Monitor Enterprise, version 8. As I write this, that’s actually 8.0.1, which is a little more than the first release. The thing about version 8 though, is that it’s containerized. That’s right, all of the many processes that GroundWork uses to monitor, alert, log, and report on your infrastructure are all running in Docker containers.
You might be wondering why we did this? Well, as always, we are trying to make your IT life easier. It might seem like it’s getting more complicated, with all those layers and single-process containers, docker-in-docker (yes, we use that for migrations and initializing the databases), but actually, we don’t think so. You will actually find it’s easier to use, easier to update, troubleshoot, and even to customize, since all the dependencies are inside the containers.
We no longer need to worry about the difference between SuSE 15 and CentOS 8, for instance. As long as Docker can run our containers, GroundWork will run fine. It’s easier to isolate processes and restart them quickly when configurations have to change. It’s easier to secure, since all the containers are on a separate network, bridged and proxied to the host. All the modern build methods are simple to integrate, and testing our software has become much deeper and easier for us. Easier to build for us means easier to maintain for you.
We decided to start off with packaging that is simple and easy to use as well: docker-compose. To put it simply, docker-compose is a way to set up all the container we need at once, with dependencies. This eliminates the timing issues we had to deal with using ctlscripts, some of which were extremely slow to execute, and took weeks to write and adapt. All automatic now.
When you need to interact with GroundWork, you now have a single place to go. If you need to back up or restore the system, install certificates, or change the host name, it’s all done through the entry point script: docker_command.sh. Using this script with the right arguments is usually all you need to do to make GroundWork fit into your devops environment seamlessly. Of course if you need to get fancy, you can, but sticking to the script will let you update smoothly when the next rev comes out.
We have separated configuration and data rigorously in this version, and we use shared volumes to store the files that you (very occasionally) need to access. While we have put a lot more of the configuration into the UI, should the need to adjust things arise, the sharing of /usr/local/groundwork/config across several containers makes it easy to check and change settings all in one place. It also make that one volume the focal point for migration, should any of the many open source apps we package need to be updated. Migration is key to GroundWork 8, and we now automate all of it for you.
One of the beautiful things about FOSS (Free Open Source Software) is that it’s maintained by dedicated, skilled programmers who publish their work openly for peers to review. When they are ready, they make a new release available “upstream” of GroundWork and we grab it and roll it into the testing cycle. That way you are always using a compatible, stable, and recent version of packages like PostgreSQL, Net-SNMP, ElasticStack, Grafana, and even Nagios™ when you use GroundWork Monitor. The fact that some of these upstream developers publish containerized versions of their code just makes that whole process ever easier to maintain.
Many of our customers have to run GroundWork on systems that are isolated from the Internet, often air-gapped and nearly always protected by stateful firewalls and IPS systems. The key to having these systems actually work, however, is compliance with standards. One especially difficult choice some security departments have to make is to disallow access to Internet software repositories. We get why, but it does make installing over the Internet impossible for some. We can deal with that, though. Our scripted installer only needs a system with Docker and Docker Compose installed to operate. Since Docker can be installed in many ways including .rpm and .deb, and docker-compose is a single file, it’s not usually an issue to prep an air-gapped system. Then you just transfer the GroundWork installer file, verify the md5 sum, and run it to install or update.
The containerization road is long, and we are in the first mile. While what we have now makes your IT life easier, we know you are looking to the future. So are we! With cloud services booming, there are many places a micro-services-enabled app can run. While we don’t have stateless containers, we do have lots of ways to scale GroundWork Monitor, and as the need arises we plan to make it run in Kubernetes, and in a selection of Cloud container orchestration services. The future is bright!
GroundWork Open Source, Inc.
www.gwos.com