justinkendra - Fotolia
At its heart, IT provisioning is all about providing everything a user or application needs.
IT resources range from bare-metal servers to virtual machine instances, applications, storage volumes or instances, network support and more; sometimes those resources require authorization for users or groups.
IT provisioning -- and the tools and techniques to make it work -- is a vital part of systems management and configuration management. Every provisioning step, including creating a VM, software installation and configuration and storage and network tie-ins, can be performed manually, but there is a better way.
Modern IT provisioning relies on some level of automation and orchestration to be faster, more consistent and efficient, with fewer errors than manual steps. For example, a business that spins up new web servers regularly can specify in a script the precise resources to allocate; files and operating systems to install; access rights to grant storage and networks, users or groups; and other established elements to achieve a working instance that poses a known and approved configuration.
To automate IT provisioning, organizations map out and define tasks in advance -- with the help of images, scripts and templates -- that configuration management systems describe in different ways.
Images, scripts and templates
Scripts allow administrators to detail a series of events that can be executed repeatedly to achieve consistent results. Images, scripts and templates enable automated provisioning processes to provide consistency, reduce mistakes and preserve security and compliance.
Scripts are some of the earliest forms of automation, and many IT old-timers remember creating DOS batch files. Today, powerful tools, such as Windows PowerShell, deploy intricate scripts to provision disks, list and configure devices; run background tasks; or replicate any other administrative activity. For example, at a business with 600 servers, an administrator can log on to each server individually to check for a given service. In addition, a script can gather and report information about every server automatically in minutes -- without overlooking one system. A more complex script could also install the needed service on systems that lack it.
Templates are generic patterns to create something. In IT provisioning, templates are generally more abstract and dynamic than scripts, allowing for greater variability and choice in the provisioning outcome. A template defines any number of deployment scenarios, with different components used or tasks performed for each selected scenario. For example, a template defines the standard tasks to set up a server, with different storage, VM and base image choices implemented when the template creates a web, database, application or other server type. The overall process, as defined by the template, is identical; the components change.
Script languages support a growing range of conditional actions -- and that increasingly muddles the line between scripts and templates. Scripts can invoke a template to run as part of a process, and vice versa. The term workflow applies to both scripts and templates. Definitions and usages are fluid.
Images are files that contain pre-arranged, ready-to-run content such as VM images. For example, a cloud administrator invokes an Amazon Machine Image in an Elastic Compute Cloud instance on Amazon Web Services, while a data center administrator spins up a local VM using an Open Virtualization Format file. Images could contain a complete application or operating system that's ready to be added to an existing server or VM. This enables a development team to roll up a new software release into an image that the operations team pushes to production systems via automation tools.
In effect, images are components that can be deployed as part of the resource provisioning or change processes. Admins can invoke images from a script or call images from a template. They should closely track image use, because many commercial applications require costly licenses.
Scripts, templates and images are certainly not the only components found within resource provisioning tools. Other components include software libraries, data and other files, as well as orchestration or workflow tasks that include management approvals or notifications.
Playbooks, manifests, recipes and script languages
Playbooks, manifests and recipes are all terms for the scripts of configuration management tools.
Ansible, owned by Red Hat, uses YAML-based playbooks and roles. A role is a set of tasks and files used to configure a host server to handle a specific function: The role specifies that the server is configured as a web server. A playbook denotes the relationship or mapping among hosts and roles. For example, playbooks possess names like webservers.yml, with role definitions stored in folders like roles/webservers/. In Ansible, any machine can be a controller, which applies the desired configuration to other systems (nodes) through secure shell connections.
Puppet uses modules and manifests created using its own domain-specific language. A manifest folder contains all of the class definitions (.pp files) used in the configuration, while a module contains manifests, along with other files or folders containing downloadable files, libraries, facts, templates, functions and so on. The completed module can then be applied to a desired system. Modules and manifests are reusable. Unlike Ansible, Puppet uses a centralized control system called Puppet Master, which is responsible for delivering the configuration to each node.
Chef uses recipes and cookbooks scripted with Ruby. A recipe is the basic building block of Chef, detailing the resources, attributes and actions that create a configuration. Recipes could include other recipes, but the resulting recipe is always stored in a cookbook. A cookbook contains all of the elements and policies that are needed for the complete system configuration -- recipes, files, templates, attributes, libraries and other resources. Chef uses a centralized controller called Chef Server to push new or updated configurations to desired node.
Idempotent behavior in provisioning
Idempotent behavior means that an outcome will remain unchanged no matter how often a process occurs. In an idempotent configuration management tool, multiple identical IT provisioning requests are the same as a single one. For example, if a configuration process is disrupted or incomplete, the resource provisioning process resumes where it left off when the process restarts. And the ultimate end-state remains in the same, expected, predictable configuration. The idempotent configuration tool won't create multiple instances of an operating system, drivers or other items, so several provisioning attempts create the same result as one successful attempt. Idempotent behavior is also described in many application programming interfaces.
Well-conceived, policy-driven IT provisioning can help ensure a level of standardization and predictability that is vital for resource efficiency, security and compliance.
Provisioning is typically the process of initial creation or allocation -- just one small portion of the broad configuration management umbrella. Beyond provisioning, other configuration management features and functions include asset discovery and management, desired state enforcement and change management, reporting and alerting, formal workflow orchestration, system inventory and license management, capacity tracking and planning, and much more.