Hands-On Enterprise Automation on Linux

Efficiently perform large-scale Linux infrastructure automation with Ansible

James Freeman

• Publisher: Packt Publishing
• Year: 2020
• Print ISBN:
  9781789131611
• Edition: 1
• eBook ISBN:
  9781789137460
• Topic: Computer Science
• Subtopic: Business Intelligence
• Index: Computer Science

Achieve enterprise automation in your Linux environment with this comprehensive guide

Key Features

• Automate your Linux infrastructure with the help of practical use cases and real-world scenarios
• Learn to plan, build, manage, and customize OS releases in your environment
• Enhance the scalability and efficiency of your infrastructure with advanced Linux system administration concepts

Book Description

Automation is paramount if you want to run Linux in your enterprise effectively. It helps you minimize costs by reducing manual operations, ensuring compliance across data centers, and accelerating deployments for your cloud infrastructures.

Complete with detailed explanations, practical examples, and self-assessment questions, this book will teach you how to manage your Linux estate and leverage Ansible to achieve effective levels of automation. You'll learn important concepts on standard operating environments that lend themselves to automation, and then build on this knowledge by applying Ansible to achieve standardization throughout your Linux environments.

By the end of this Linux automation book, you'll be able to build, deploy, and manage an entire estate of Linux servers with higher reliability and lower overheads than ever before.

What you will learn

• Perform large-scale automation of Linux environments in an enterprise
• Overcome the common challenges and pitfalls of extensive automation
• Define the business processes needed to support a large-scale Linux environment
• Get well-versed with the most effective and reliable patch management strategies
• Automate a range of tasks from simple user account changes to complex security policy enforcement
• Learn best practices and procedures to make your Linux environment automatable

Who this book is for

This book is for anyone who has a Linux environment to design, implement, and maintain. Open source professionals including infrastructure architects and system administrators will find this book useful. You're expected to have experience in implementing and maintaining Linux servers along with knowledge of building, patching, and maintaining server infrastructure. Although not necessary, knowledge of Ansible or other automation technologies will be beneficial.

Section 1: Core Concepts

The objective of this section is to understand the systems administration fundamentals and techniques that will be covered in this book. First, we will cover a hands-on introduction to Ansible, the tool that will be used throughout this book for automation and purposes such as package management and advanced systems administration en masse.

This section comprises the following chapters:

• Chapter 1, Building a Standard Operating Environment on Linux
• Chapter 2, Automating Your IT Infrastructure with Ansible
• Chapter 3, Streamlining Infrastructure Management with AWX

Building a Standard Operating Environment on Linux

This chapter provides a detailed exploration of the Standard Operating Environment (henceforth, SOE for short) concept in Linux. Although we will go into much greater detail later, in short, an SOE is an environment where everything is created and modified in a standard way. For example, this would mean that all Linux servers are built in the same way, using the same software versions. This is an important concept because it makes managing the environment much easier and reduces the workload for those looking after it. Although this chapter is quite theoretical in nature, it sets the groundwork for the rest of this book.

We will start by looking at the fundamental definition of such an environment, and then proceed to explore why it is desirable to want to create one. From there, we will look at some of the pitfalls of an SOE to give you a good perspective on how to maintain the right balance in such an environment, before finally discussing how an SOE should be integrated into day-to-day maintenance processes. The effective application of this concept enables efficient and effective management of Linux environments at very large scales.

In this chapter, we will cover the following topics:

• Understanding the challenges of Linux environment scaling
• What is an SOE?
• Exploring SOE benefits
• Knowing when to deviate from standards
• Ongoing maintenance of SOEs

Understanding the challenges of Linux environment scaling

Before we delve into the definition of an SOE, let's explore the challenges of scaling a Linux environment without standards. An exploration of this will help us to understand the definition itself, as well as how to define the right standards for a given scenario.

Challenges of non-standard environments

It is important to consider that many challenges experienced by enterprises with technology estates (whether Linux or otherwise) do not start out as such. In the early stages of growth, in fact, many systems and processes are entirely sustainable, and in the next section, we will look at this early stage of environment growth as a precursor to understanding the challenges associated with large-scale growth.

Early growth of a non-standard environment

In a surprisingly large number of companies, Linux environments begin life without any form of standardization. Often, they grow organically over time. Deployments start out small, perhaps just covering a handful of core functions, and as time passes and requirements grow, so does the environment. Skilled system administrators often make changes by hand on a per-server basis, deploying new services and growing the server estate as business demands dictate.

This organic growth is the path of least resistance for most companies—project deadlines are often tight and in addition both budget and resource are scarce. Hence, when a skilled Linux resource is available, that resource can assist in just about all of the tasks required, from simple maintenance tasks to commissioning complex application stacks. It saves a great deal of time and money spent on architecture and makes good use of the skillset of staff on hand as they can be used to address immediate issues and deployments, rather than spending time on architectural design. Hence, quite simply, it makes sense, and the author has experienced this at several companies, even high-profile multi-national ones.

Impacts of non-standard environments

Let's take a deeper look at this from a technical standpoint. There are numerous flavors of Linux, numerous applications that perform (at a high level) the same function, and numerous ways to solve a given problem. For example, if you want to script a task, do you write it in a shell script, Perl, Python, or Ruby? For some tasks, all can achieve the desired end result. Different people have different preferred ways of approaching problems and different preferred technology solutions, and often it is found that a Linux environment has been built using a technology that was the flavor of the month when it was created or that was a favorite of the person responsible for it. There is nothing wrong with this in and of itself, and initially, it does not cause any problems.

If organic growth brings with it one fundamental problem, it is this: scale. Making changes by hand and always using the latest and greatest technology is great when the environment size is relatively small, and often provides an interesting challenge, hence keeping technical staff feeling motivated and valued. It is vital for those working in technology to keep their skills up to date, so it is often a motivating factor to be able to employ up-to-date technologies as part of the day job.

Scaling up non-standard environments

When the number of servers enters the hundreds, never mind thousands (or even greater!), this whole organic process breaks down. What was once an interesting challenge becomes laborious and tedious, even stressful. The learning curve for new team members is steep. A new hire may find themselves with a disparate environment with lots of different technologies to learn, and possibly a long period of training before they can become truly effective. Long-serving team members can end up being silos of knowledge, and should they depart the business, their loss can cause continuity issues. Problems and outages become more numerous as the non-standard environment grows in an uncontrolled manner, and troubleshooting becomes a lengthy endeavor—hardly ideal when trying to achieve a 99.99% service uptime agreement, where every second of downtime matters! Hence, in the next section, we will look at how to address these challenges with an SOE.

Addressing the challenges

From this, we realize our requirement for standardization. Building a suitable SOE is all about the following:

• Realizing economies of scale
• Being efficient in day-to-day operations
• Making it easy for all involved to get up to speed quickly and easily
• Being aligned with the growing needs of the business

After all, if an environment is concise in its definition, then it is easier for everyone involved in it to understand and work with. This, in turn, means tasks are completed quicker and with greater ease. In short, standardization can bring cost savings and improved reliability.

It must be stressed that this is a concept and not an absolute. There is no right or wrong way to build such an environment, though there are best practices. Throughout this chapter, we will explore the concept further and help you to identify core best practices associated with SOEs so that you can make informed decisions when defining your own.

Let's proceed to explore this in more detail. Every enterprise has certain demands of their IT environments, whether they are based on Linux, Windows, FreeBSD, or any other technology. Sometimes, these are well understood and documented, and sometimes, they are simply implicit—that is to say, everyone assumes the environment meets these standards, but there is no official definition. These requirements often include the following:

• Security
• Reliability
• Scalability
• Longevity
• Supportability
• Ease of use

These, of course, are all high-level requirements, and very often, they intersect with each other. Let's explore these in more detail.

Security

Security in an environment is established by several factors. Let's look at some questions to understand the factors involved:

• Is the configuration secure?
• Have we allowed the use of weak passwords?
• Is the superuser, root, allowed to log in remotely?
• Are we logging and auditing all connections?

Now, in a non-standard environment, how can you truly say that these requirements are all enforced across all of your Linux servers? To do so requires a great deal of faith they have all been built the same way, that they had the same security parameters applied, and that no-one has ever revisited the environment to change anything. In short, it requires fairly frequent auditing to ensure compliance.

However, where the environment has been standardized, and all servers have been built from a common source or using a common automation tool (we shall demonstrate this later in this book), it is much easier to say with confidence that your Linux estate is secure.

A standards-based environment isn't implicitly secure, of course—if there is an issue that results in a vulnerability in the build process for this environment, automation means this vulnerability will be replicated across the entire environment! It is important to be aware of the security requirements of your environment and to implement these with care, maintaining and auditing your environment continuously to ensure security levels are maintained.

Security is also enforced by patches, which ensure you are not running any software with vulnerabilities that could allow an attacker to compromise your servers. Some Linux distributions have longer lives than others. For example, Red Hat Enterprise Linux (and derivatives such as CentOS) and the Ubuntu LTS releases all have long, predictable life cycles and make good candidates for your Linux estate.

As such, they should be part of your standards. By contrast, if a bleeding edge Linux distribution such as Fedora has been used because, perhaps, it had the latest packages required at the time, you can be sure that the life cycle will be short, and that updates would cease in the not too distant future, hence leaving you open to potential unpatched vulnerabilities and the need to upgrade to a newer release of Fedora.

Even if the upgrade to a newer version of Fedora is performed, sometimes packages get orphaned—that is to say, they do not get included in the newer release. This might be because they have been superseded by a different package. Whatever the cause, upgrading one distribution to another could cause a false sense of security and should be avoided unless thoroughly researched. In this way, standardization helps to ensure good security practices.

Reliability

Many enterprises expect their IT operations to be up and running 99.99% of the time (or better). Part of the route to achieving this is robust software, application of relevant bug fixes, and well-defined troubleshooting procedures. This ensures that in the worst case scenario of an outage, the downtime is as minimal as possible.

Standardization again helps here—as we discussed in the preceding section on security, a good choice of underlying operating system ensures that you have ongoing access to bug fixes and updates, and if you know that your business needs a vendor backup to ensure business continuity, then the selection of a Linux operating system with a support contract (available with Red Hat or Canonical, for example) makes sense.

Equally, when servers are all built to a well-defined and understood standard, making changes to them should yield predictable results as everyone knows what they are working with. If all servers are bui...

Table of contents

• Title Page
• Copyright and Credits
• Dedication
• About Packt
• Foreword
• Contributors
• Preface
• Section 1: Core Concepts
• Building a Standard Operating Environment on Linux
• Automating Your IT Infrastructure with Ansible
• Streamlining Infrastructure Management with AWX
• Section 2: Standardizing Your Linux Servers
• Deployment Methodologies
• Using Ansible to Build Virtual Machine Templates for Deployment
• Custom Builds with PXE Booting
• Configuration Management with Ansible
• Section 3: Day-to-Day Management
• Enterprise Repository Management with Pulp
• Patching with Katello
• Managing Users on Linux
• Database Management
• Performing Routine Maintenance with Ansible
• Section 4: Securing Your Linux Servers
• Using CIS Benchmarks
• CIS Hardening with Ansible
• Auditing Security Policy with OpenSCAP
• Tips and Tricks
• Assessments
• Other Books You May Enjoy