Just some copy&paste from Wikipedia for a presentation
Continuous configuration automation
Types of approaches
Infrastructure as code (IaC) is the process of managing and provisioning computer data centers through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools. The definitions may be in a version control system.
In software engineering, version control is system responsible for managing changes to computer programs, documents, large web sites, or other collections of information. Version control is a component of software configuration management.
It can use either scripts or declarative definitions, rather than manual processes, but the term is more often used to promote declarative (functional) approaches.
The declarative approach defines the desired state and the system executes what needs to happen to achieve that desired state. Imperative defines specific commands that need to be executed in the appropriate order to end with the desired conclusion.
Added value and advantages
The value of IaC can be broken down into three measurable categories:
cost (reduction)
Cost reduction aims at helping not only the enterprise financially, but also in terms of people and effort, meaning that by removing the manual component.
speed (faster execution)
Infrastructure automation enables speed through faster execution when configuring your infrastructure and aims at providing visibility to help other teams across the enterprise work quickly and more efficiently.
risk (remove errors and security violations)
Automation removes the risk associated with human error, like manual misconfiguration; removing this can decrease downtime and increase reliability. These outcomes and attributes help the enterprise move towards implementing a culture of DevOps, the combined working of development and operations.
Methods
There are two methods of IaC: push and pull . The main difference is the manner in which the servers are told how to be configured. In the pull method the server to be configured will pull its configuration from the controlling server. In the push method the controlling server pushes the configuration to the destination system.
This is a comparison of notable free and open-source configuration management software, suitable for tasks like server configuration, orchestration and infrastructure as code typically performed by a system administrator.
| Ansible | Combines multi-node deployment, ad-hoc task execution, and configuration management in one package. Manages nodes over SSH and requires python (2.6+ or 3.5+) to be installed on them. Modules work over JSON and standard output and can be written in any language. Uses YAML to express reusable descriptions of systems. |
| Chef | Chef is a configuration management tool written in Erlang, and uses a pure Ruby DSL for writing configuration "recipes". These recipes contain resources that should be put into the declared state. Chef can be used as a client–server tool, or used in "solo" mode. |
| Juju | Juju concentrates on the notion of service, abstracting the notion of machine or server, and defines relations between those services that are automatically updated when two linked services observe a notable modification. |
| Puppet | Puppet consists of a custom declarative language to describe system configuration, distributed using the client–server paradigm (using XML-RPC protocol in older versions, with a recent switch to REST), and a library to realize the configuration. Puppet will then ensure the server's state matches the description. |
| Salt | Salt started out as a tool for remote server management. As its usage has grown, it has gained a number of extended features, including a more comprehensive mechanism for host configuration. This is a relatively new feature facilitated through the Salt States component. With the traction that Salt has gotten in the last bit, the support for more features and platforms will continue to grow. |
Configuration Examples
Ansible
---
- hosts: all
tasks:
- name: ensure nginx is at the latest version
apt: name=nginx state=latest
become: yes
- name: start nginx
service:
name: nginx
state: started
become: yes
- name: copy the nginx config file and restart nginx
copy:
src: /home/foo/static_site.cfg
dest: /etc/nginx/sites-available/static_site.cfg
become: yes
- name: create symlink
file:
src: /etc/nginx/sites-available/static_site.cfg
dest: /etc/nginx/sites-enabled/default
state: link
become: yes
- name: copy the content of the web site
copy:
src: /home/foo/static-site-src/
dest: /home/foo/static-site
- name: restart nginx
service:
name: nginx
state: restarted
become: yes
Ansible supports the Jinja templating engine
Puppet
'nginx-plus': {
apt::source { 'nginx':
location => "https://plus-pkgs.nginx.com/${distro}",
repos => 'nginx-plus',
key => '573BFD6B3D8FBC641079A6ABABF5BD827BD9BF62',
}
exec { 'download 90nginx file':
command => "/usr/bin/wget -q -O /etc/apt/apt.conf.d/90nginx https://cs.nginx.com/static/files/90nginx",
creates => "/etc/apt/apt.conf.d/90nginx"
}
file { '/etc/ssl/nginx':
ensure => directory,
mode => "0755",
owner => "root",
group => "root",
}
file { '/etc/ssl/nginx/nginx-repo.crt':
ensure => present,
mode => "0644",
owner => "root",
group => "root",
content => "Contents of your nginx‑repo.crt file here as one line",
}
file { '/etc/ssl/nginx/nginx-repo.key':
ensure => present,
mode => "0644",
owner => "root",
group => "root",
content => "Contents of your nginx‑repo.key file here as one line",
}
}
Salt
nginx:
pkg:
- installed
service.running:
- watch:
- pkg: nginx
- file: /etc/nginx/nginx.conf
- file: /etc/nginx/sites-available/default
/etc/nginx/nginx.conf:
file.managed:
- source: salt://nginx/files/etc/nginx/nginx.conf
- user: root
- group: root
- mode: 640
/etc/nginx/sites-available/default:
file.managed:
- source: salt://nginx/files/etc/nginx/sites-available/default.jinja
- template: jinja
- user: root
- group: root
- mode: 640
/usr/share/nginx/html/index.html:
file.managed:
- source: salt://nginx/files/usr/share/nginx/html/index.html.jinja
- template: jinja
- user: root
- group: root
- mode: 644
Module types
The Salt system maintains many module types to manage specific actions. Modules can be added to any of the systems that support dynamic modules. These modules manage all the remote execution and state management behavior of Salt. The modules can be separated into six groups:
-
Execution modules are the workhorse for Salt's functionality. They represent the functions available for direct execution from the remote execution engine. These modules contain the specific cross platform information used by Salt to manage portability, and constitute the core API of system level functions used by Salt systems.
-
State modules are the components that make up the backend for the Salt configuration management system. These modules execute the code needed to enforce, set up or change the configuration of a target system. Like other modules, more states become available when they are added to the states modules.
-
Grains are a system for detecting static information about a system and storing it in RAM for rapid gathering.
-
Renderer modules are used to render the information passed to the Salt state system. The renderer system is what makes it possible to represent Salt's configuration management data in any serializable format.
-
Returners: the remote execution calls made by Salt are detached from the calling system; this allows the return information generated by the remote execution to be returned to an arbitrary location. Management of arbitrary return locations is managed by the Returner Modules.
-
Runners are master side convenience applications executed by the salt-run command.
List of systems management systems
Nagios Core
Nagios Core is open source software licensed under the GNU GPL V2.
Currently it provides:
- Monitoring of network services (SMTP, POP3, HTTP, NNTP, ICMP, SNMP, FTP, SSH)
- Monitoring of host resources (processor load, disk usage, system logs) on a majority of network operating systems, including Microsoft Windows, using monitoring agents.
- Monitoring of any hardware (like probes for temperature, alarms, etc.) which have the ability to send collected data via a network to specifically written plugins
- Monitoring via remotely run scripts via Nagios Remote Plugin Executor
- Remote monitoring supported through SSH or SSL encrypted tunnels.
- A simple plugin design that allows users to easily develop their own service checks depending on needs, by using their tools of choice (shell scripts, C++, Perl, Ruby, Python, PHP, C#, etc.)
- Available data graphing plugins
- Parallelized service checks
- Flat-text formatted configuration files (integrates with many config editors)
- The ability to define network host using 'parent' hosts, allowing the detection of and distinction between hosts that are down or unreachable
- Contact notifications when service or host problems occur and get resolved (via e-mail, pager, SMS, or any user-defined method through plugin system)
- The ability to define event handlers to be run during service or host events for proactive problem resolution Automatic log file rotation
- Support for implementing redundant monitoring hosts
- Support for implementing performance data graphing
- Support for database backend (such as NDOUtils)
- Push notifications
- A web-interface for viewing current network status, notifications, problem history, log files, etc.