1 / 14

Chapter 2 Applying Practical Automation

Speaker : Chuang-Hung Shih Date : 2010.3.09. Chapter 2 Applying Practical Automation. Applying Practical Automation. This chapter presents the prerequisite information in an easy-to-digest format. This chapter assumes familiarity with Bourne Shell scripting.

doyle
Download Presentation

Chapter 2 Applying Practical Automation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Speaker : Chuang-Hung Shih Date : 2010.3.09 Chapter 2Applying Practical Automation

  2. Applying Practical Automation This chapter presents the prerequisite information in an easy-to-digest format. This chapter assumes familiarity with Bourne Shell scripting. If your scripting is as portable as possible from the start, in effect you’re buying insurance against future pain.

  3. Seeing Everything As a File Both real and pseudo devices (such as /dev/null, /dev/zero, and so on) can be read from and (often) written to as normal files. For example, if you want to create an ISO file on a remote system from a DVD in your laptop, you could run this: dd if=/dev/cdrom | ssh remotehost ‘dd of=/opt/big/vmware/sol10.iso You can then configure VMware to mount the ISO file as a CD- ROM drive and quickly boot from the device and install on a host with no physical CD/DVD drive.

  4. Seeing Everything As a File It's important to remember that the vast majority of automation operations are based on copying and/or modifying files. Often when files change or new files are distributed, a process on the host needs to restart so the host can recognize the change. The bulk of what we’ll be doing in this book is copying files, modifying files, and taking actions based on the success or failure of earlier file operations.

  5. Understanding the Procedure Before Automating It We've seen many administrators open a cfengine (configuration engine) config file to automate a task and end up sitting there, unsure of what to do. This is the first rule of automation: Automation is simply a set of already working steps, tied together in an automated manner. This means that the first step toward automating a procedure usually involves manual changes!

  6. Understanding the Procedure Before Automating It Here's an overview of the automated change development process: Make the change in a test environment. Make it fit your policy. Automate the deployment steps. Test the deployment to a small number of testing or stage hosts and confirm that you achieve the desired effects. Deploy the change to all hosts using the newly developed automation.

  7. Exploring an Example Automation An SA( system administration) needs to create user accounts regularly. In this case, you’ll use several commands to create a directory on a central Network File System (NFS) server and send off a welcome e-mail. The script might look as simple as this:

  8. Exploring an Example Automation If it generates any errors, you might find it difficult to determine what failed. In just a few minutes, you can make some simple additions to turn this procedure into a tool that’s usable by all SA staff:

  9. Exploring an Example Automation

  10. Turning the Script into a Robust Automation Every automation's primary focus should be to achieve one of two things: A change to one or more systems that achieves a business goal: The creation of a new user account falls into this category. No change at all: If something unexpected happens at any point in the automation, no changes should be made at all. This means that if an automated procedure makes several changes, a failure in a later stage should normally result in a rollback of the earlier changes (where appropriate or even possible).

  11. Turning the Script into a Robust Automation Your earlier user-creation script could use some improved error messages, as well as a rollback step. Give that a shot now:

  12. Turning the Script into a Robust Automation

  13. Attempting to Repair, Then Failing Noisily You’ll encounter situations where a rollback is multistep, so you’ll need to evaluate each step’s exit code and indicate or contraindicate further rollback steps based on those exit codes. Each and every step in an automation or administrative script needs to ensure success.

  14. Focusing on Results When in doubt, opt for simplicity. Don't attempt fancy logic and complicated commands when the goal is simple. For example, you might have a script that takes a list of DNS servers and generates a resolv.conf file that’s pushed to all hosts at your site. When a new DNS server is added or a server is replaced with another, you need to run the script to update the file on all your systems. A complicated procedure becomes a simple file push. This is the KISS (Keep It Simple, Stupid) principle in all its glory.

More Related