About IT automation

- [Instructor] IT automation is the use of software to create repeatable processes to replace all or part of human interaction in IT systems. IT automation software works within the confines of the tradition IT environment to carry out tasks with little to no human interaction. Modern dynamic IT environments need to scale faster than they ever have in the past and the key to managing this lies with IT automation. Most IT tasks can be automated to some degree. The advantages of automating is it gets the tedious repetitive tasks out of the hands of people. This allows the same technicians and engineers to be more productive, reduce errors, improve collaboration, and free up time for more meaningful work. Automation can apply to other systems, such as network infrastructure, cloud provisioning, application development, and configuration management. Using automation technologies we can penetrate specific areas, such as containers, devops, cloud and edge computing, vulnerability assessments for security, system testing, as well as monitoring. Generally speaking, if it's an IT task then automation can probably be applied to it. There are multiple IT automation stacks, such as Puppet, Chef, Salt from Saltstack, and the reason we're here, Ansible Engine. There are others, both commercial and open-source, but we'll focus on these four. This is not a comparison of these technologies, as much as an overview of how these systems work and how Ansible contrasts to the others. With any of these configuration management systems there's a control host and then a client receiving commands and or configuration information. The client often can have a piece of software running on it called an agent that's waiting for commands and or configuration data. In some cases, such as Salt and Ansible, the client may be agentless. With Puppet the control host is called the Puppet master and the client is the Puppet agent. And it uses an SSL connection provided by OpenSSL for communication. The configuration data is stored in a file formatted similar to the Ruby language called the Puppet Manifest. The Manifest is compiled specifically for each host and that host-specific Manifest is sent to the specific client. This keeps sensitive data secret, but puts a lot of load on the Puppet master. There are a lot of after-market pieces of software to enhance Puppet and give it more power, as well as make it scale. Chef is a bit different. It uses a lightweight RabbitMQ message queue connection between the server and the client's agent. Chef configuration data is stored as Cookbooks and Recipes written in Ruby. Salt from Saltstack, in addition to Ansible, represents the next generation of IT automation systems. The control host in Salt is called the Salt master and the client is called the Salt minion. It was designed from the beginning to be a remote execution stack with a super lightweight encrypted tunnel between the Salt master and Salt minion using 0MQ, making it very fast. By default, it has an agent that's installed in the Salt minion that waits for instructions. It can also work agentless and use the SSH protocol to communicate with the client. This requires less initial setup, but isn't as fast and also relies on SSH access to the clients. Salt configuration files called Salt State files are normally stored in YAML format, but it supports many different formats, and in fact, you can create your own. Also, their not compiled specifically for each client, which relieves the control host of this arduous task. The entire Salt State file is sent across the network and the client only pays attention to the portion that pertains to it. This means you don't want to have any sensitive data in the State files, as all clients can see them. This is a very fast solution that works for most situations. For sensitive data Salt has specific State files called Salt Pillars, which are specific to each client. This adds a bit of administrative overhead, but allows Salt to scale to 10s of 1,000s of clients. The last system we'll look at is Ansible Engine. Ansible is very similar to Salt when running in agentless mode. It uses SSH or Remote Powershell on Windows host to send commands and configuration data to the client. As such, the client configuration is very simple, as those communication methods are usually configured already. Ansible stores its configurations in Playbooks and Plays in INI or YAML format. Ansible aims to be simple to setup, simple to configure, consistent, secure, and reliable. There's a performance overhead for using SSH, so Ansible has SSH pipelining, which allows executing multiple commands in one connection. Both Salt and Ansible are great at sending commands to the clients as well as configuring them. When Ansible's not controlling node it's not consuming any resources on the node, as there are no client applications running. So here's how they work. Let's say the configuration says that Apache should be installed and it should be running. It doesn't matter which OS the client is running, it could be Ubuntu Linux, Red Hat Linux, or even Windows. The control host holds a bunch of files that describe the configuration of the client. Since these configuration files are ASCII text they can be tracked using revision control. This revision control could be local or remote. The automation process might go like this. The production control host and client are cloned into a test environment, then a branch of the current production configuration is done on the revision control server, changes are made and tested. The branch is then merged back into the production configuration and pushed out to our production control host, which modifies the configuration of our clients. We then delete the configuration branch. It may be more complex than this, but I think you get the idea.