Unit 1.3 - Configuration Management Tools
Unit 1.3 - Configuration Management Tools
The configuration of your computer is in a constant state of flux. From the moment it
is taken out of the box, software is added, removed, and updated.
At enterprise scale, those types of changes must be made and tracked on hundreds or
even thousands of computers.
Configuration management (CM) controls those changes, continuously monitoring and
ensuring that organizational infrastructure is configured to the correct specifications.
Essentially, it’s a continuously updated inventory for technology assets. This
maintains the status quo across server environments, reduces incident resolution
time, and helps to prevent surprises.
In the long term, it maintains the integrity and consistency of a system or product
throughout its lifetime.
For example, on the application level, configuration management involves tracking
and logging all of the changes made to the software up until the product goes live.
This process helps developers to find and fix any bugs that emerge during
development or testing.
What are Configuration Management Tools?
CM tools- help development and operations teams to manage applications and
infrastructure.
CM tools should include features for enforcement, version control, change control, and
abstraction, and must also support your existing toolchains and systems.
Availability, ease of setup, scalability, configuration language, and interoperability
should all be considered.
When choosing a CM tool, evaluate whether you need capabilities like:
1. Servers and operating
2. Cloud-native routing and networking
3. Virtual private networks
4. Access policy and permissions
5. Load balancers
6. Autoscaling policy
Benefits of Configuration Management Tools
1. Quick disaster recovery:
Assets are easily recoverable and changes can be rolled back quickly, especially with
proper documentation of all the recovery points and logs.
2. Increased uptime & site reliability:
Tracking changes to the system reduces the risk of outages and security breaches. When
it comes to downtime, bad deployments are a frequent culprit. But with proper
configuration management, test environments can mimic production; this decreases the
chance of encountering a nasty surprise.
3. Easier scaling:
With configuration management, increasing the number of servers is as simple as
clicking a button or running a script. The goal is to make provisioning a non-event.
4. Better visibility & communication:
Everyone knows what changes have been made, so miscommunications are minimized.
5. Improved resource utilization:
With configuration management, you can get rid of duplicates and eliminate inefficient
usage of resources.
Ansible
Ansible provides open-source automation that reduces complexity and runs everywhere. Using
Ansible lets you automate virtually any task. Here are some common use cases for Ansible:
Eliminate repetition and simplify workflows
Manage and maintain system configuration
Continuously deploy complex software
Perform zero-downtime rolling updates
Ansible uses simple, human-readable scripts called playbooks to automate your tasks. You
declare the desired state of a local or remote system in your playbook. Ansible ensures that
the system remains in that state.
Ansible is designed around the following principles:
Agent-less architecture: Low maintenance overhead by avoiding the installation of additional software
across IT infrastructure.
Simplicity: Automation playbooks use straightforward YAML syntax for code that reads like
documentation. Ansible is also decentralized, using SSH existing OS credentials to access to remote
machines.
Scalability and flexibility: Easily and quickly scale the systems you automate through a modular
design that supports a large range of operating systems, cloud platforms, and network devices.
Idempotence and predictability: When the system is in the state your playbook describes Ansible does
not change anything, even if the playbook runs multiple times.
Ansible concepts
Control node
The machine from which you run the Ansible CLI tools (ansible-playbook , ansible, ansible-
vault and others). You can use any computer that meets the software requirements as a
control node - laptops, shared desktops, and servers can all run Ansible. You can also run
Ansible in containers known as Execution Environments.
Multiple control nodes are possible, but Ansible itself does not coordinate across them, see
AAP for such features.
Managed nodes
Also referred to as ‘hosts’, these are the target devices (servers, network appliances or any
computer) you aim to manage with Ansible.
Ansible is not normally installed on managed nodes, unless you are using ansible-pull, but
this is rare and not the recommended setup.
Inventory
A list of managed nodes provided by one or more ‘inventory sources’. Your inventory can
specify information specific to each node, like IP address. It is also used for assigning
groups, that both allow for node selection in the Play and bulk variable assignment.
To learn more about inventory, see the Working with Inventory section. Sometimes an
inventory source file is also referred to as a ‘hostfile’.
Playbooks
They contain Plays (which are the basic unit of Ansible execution). This is both an ‘execution
concept’ and how we describe the files on which ansible-playbook operates. Playbooks are written
in YAML and are easy to read, write, share and understand.
Modules
The code or binaries that Ansible copies to and executes on each managed node (when needed) to
accomplish the action defined in each Task.
Each module has a particular use, from administering users on a specific type of database to
managing VLAN interfaces on a specific type of network device.
You can invoke a single module with a task, or invoke several different modules in a playbook.
Ansible modules are grouped in collections. For an idea of how many collections Ansible includes,
see the Collection Index.
Plugins
Pieces of code that expand Ansible’s core capabilities. Plugins can control how you connect to a
managed node (connection plugins), manipulate data (filter plugins) and even control what is
displayed in the console (callback plugins).
Collections
A format in which Ansible content is distributed that can contain playbooks, roles, modules, and
plugins. You can install and use collections through Ansible Galaxy.
To learn more about collections, see Using Ansible collections.
Collection resources can be used independently and discretely from each other.
Puppet
"Puppet, an automated administrative engine for your Linux, Unix, and Windows
systems, performs administrative tasks (such as adding users, installing packages,
and updating server configurations) based on a centralized specification."
Conceived as a tool oriented toward operations and sysadmins, Puppet has
consolidated as a configuration management tool. It usually works in a client-server
architecture, and an agent communicates with the server to fetch configuration
instructions.
Puppet uses a declarative language or Ruby to describe the system configuration. It is
organized in modules, and manifest files contain the desired-state goals to keep
everything as required. Puppet uses the push model by default, and the pull model
can be configured.
Chef
"A systems integration framework, built to bring the benefits of configuration
management to your entire infrastructure." —GitHub repository
Chef uses "recipes" written in Ruby to keep your infrastructure running up-to-date and
compliant. The recipes describe a series of resources that should be in a particular
state. Chef can run in client/server mode or in a standalone configuration named
chef-solo. It has good integration with the major cloud providers to automatically
provision and configure new machines.
Chef has a solid user base and provides a full toolset to allow people with different
technical backgrounds and skills to interact around the recipes. But, at its base, it is
more technically oriented tool.