The IT landscape has evolved significantly over the past decades. Local physical servers were migrated to local virtual machines, and later became locally clustered hypervisor infrastructures. Businesses formed providing hosted virtual machines, which isolated users from hardware. Some of these businesses grew into providing compute and other services of an entire datacentre in a global shared infrastructure which we now know as “the cloud”.
Most IT systems at present have a mix of systems and applications, from on-prem physical and virtual machines to cloud-hosted solutions using VMs, containers and serverless.
Traditionally, application services ran locally on one server, or across two in active-standby mode. Eventually, these were clustered and were then virtualised into operating system-level containers. These containers are now being orchestrated while running on physical, local virtual or cloud infrastructure.
The chances are that your IT environment has now become a mixture of the above; some (potential legacy) physical systems, one or more locally hosted physical hypervisors running various guests, some systems in the cloud, and maybe some containers running on top of them all. Maintaining consistency across mixed environments may seem like a daunting task.
However, when it comes to Linux based systems, I would like to argue that the core principles of a well-maintained Linux infrastructure haven’t changed. They still apply to any of these systems across these platforms, since configuration management and automation can be applied in the same way – primarily because of one thing - it’s all Linux.
Linux infrastructures still use the same base OS, libraries and system resources, these have simply been abstracted to different layers. It doesn’t matter if you are running Linux services on physical systems, Virtual Machine Guests, KVM/Xen Hypervisors, AWS, CentOS, RHEL, Machine Images for cloud providers, Docker Containers, or Kubernetes… it’s still Linux under the hood. Here again, the fundamentals to maintain your infrastructure remain the same and can be applied in a consistent fashion across your environment.
For example, you still want consistent patching applied across your environments. And so the list goes on. Consistent application configurations. Consistent remote logging across all environments. Consistent security standards (e.g. hardening and credential management) across all servers. Consistent application health monitoring regardless of where the application is hosted, etc.
Admittedly, machine images in the cloud require a different setup to VM templates on a hypervisor, or to a kickstarted physical server, for example. But it is just that: a slightly different Linux system configuration. Nothing more. The base OS configuration and setup is much the same regardless of being physical, VM or cloud image. Fortunately, automation toolkits are already widely available to enable you to do this easily. More importantly, these tools can be applied across any Linux environment regardless of where your Linux systems and services run.
So with this in mind – what is an easy way to apply consistency across our systems in different environments while still being able to customize some specific parts?
How can we ensure that for example our security configuration baseline is the same across any Linux system regardless of where it runs? How can we easily build, rebuild and potentially even migrate systems and services without re-inventing the entire process?
It all starts off with a Configuration Management (CM) tool like for example Ansible or Puppet. It is necessary to keep your system, service deployments and configuration consistent, to establish your security baseline and to enable you to quickly rebuild a system. Configuration management can be applied across physical, local VMs, cloud-managed pets, and in the build process for containers and system images / templates (golden images).
This configuration management code can be reused in different environments to achieve consistency with slight customisations where necessary:
From here, the possibilities are endless. You can consider automated patching, security audits and hardening, deployment of monitoring systems and version control for starters, etc.
In the end, it’s all Linux.