Puppet

What is Puppet?

Puppet is simply an IT automation software that helps system administrators to manage infrastructure throughout its lifecycle, from provisioning and configuration to patch management and compliance and to automate repetitive tasks, quickly deploy critical applications, and proactively manage change, scaling from 10s of servers to 1000s.

The content of this post is available as Presentation with more technical details.

How Puppet Works?

Puppet uses a declarative, model-based approach to IT automation that can be summarized in 4 steps:

1. Define the desired state of the infrastructure’s configuration using Puppet’s declarative configuration language
2. Simulate configuration changes before applying
3. Enforce the deployed desired state automatically, correcting any configuration drift
4. Report on the differences between actual and desired states and any changes made enforcing the desired state

Resources

System’s configuration is a collection of resources that vary in size, complexity, and lifespan.

For example:

• File
• User account
• Software package
• Running service
• Scheduled cron job

The implementation/representation of these resources is different based on which operating system you are using. For example, you’d need a different command to start or stop a service on Windows than you would on Linux

Resource Abstraction

Similar resources can be grouped into types:

• File "readme.txt" has the same attributes (path, permissions, owner, ...) and will tend to look like all other services
• User "dave" has the same attributes (shell, group, home directory, ...) will tend to look like all other users

The description of a resource type can be separated from its implementation. You can talk about whether a service is started without needing to know what OS is in use or how to start it.

The main concept behind Puppet is to describe the desired resource states in a way that isn’t tied to a specific OS by saying "make sure this user exist and has these attributes" instead of saying “run these commands that create this user with these parameters if does not exist".

Resource Types

Puppet has many built-in resource types, and you can install even more as plugins. Each type has a different set of attributes available.

Printable cheat sheet that explains the eight most useful types is available here:

Puppet splits resources into types and providers that lets you describe resources in a way that can apply to any system:

• Types: high-level description
• Providers: platform-specific implementations

Puppet will have a definition of what state a resource should have. To sync the resource, it query the current state, compares that against the desired state, then make any necessary changes.

More to come in the next few days :)

DevOps

DevOps = Development + Operations

In a typical IT organization, many organizations divide Development and System Administration into different departments.

Development folks are driven by the changes that they are paid to accomplish based on the business needs and they create as much changes as possible. On the other side, operations folks see the changes as the enemy as the business depends on them to keep the services up and they are always motivated to resist change as it undermines stability and reliability.

Frequent changes vs Stable services vs Cost efficient

While Development departments are usually driven by user needs for frequent delivery of new features, Operations departments focus more on availability, stability of IT services and IT cost efficiency. These two contradicting goals create a "gap" between Development and Operations, which slows down IT's delivery of business value and create a disconnection between what is traditionally considered development activity and what is traditionally considered operations activity.

DevOps is software development method/capability developed by Flickr in response to the interdependence of software development and IT operations to support a business requirement of ten deployments per day and aims to help an organization to rapidly produce software products and services. Also DevOps aids in release management by standardizing development environments with easy events tracking.

Companies with release/deployment automation problems usually have existing automation but want to more flexibly manage and drive this automation. Ideally, this automation can be invoked by non-operations resources in specific non-production environments (Dev and Stage environments) where developers are given more environment control.

Goal and Drivers

The goal is to automate as much as possible different operational processes. It’s a simple calculation to make: invest in making DevOps a reality and we all should be more efficient, increasingly nimble, and less frustrated.

The adoption of DevOps is being driven by factors such as:

• Use of agile and other development processes and methodologies
• Demand for an increased rate of production releases from application and business unit stakeholders
• Wide availability of virtualized and cloud infrastructure from internal and external providers
• Increased usage of data center automation and configuration management tools

Tools and Enablers

There is always a mismatch in development and operations tooling. Take a look at the popular tools that developers use on a daily basis then take a look at the popular tools that systems administrators use on a daily basis,  it’s doubtful you’ll see much interest in using each others tools or significant integration between them.

What types of tools are required to make DevOps a reality?

• Automated infrastructure (configuration management): the process of scripting environments from installing an operating system, to installing and configuring servers on instances, to configuring how the instances and software communicate with one another. By scripting environments, you can apply the same configuration to a single node or to thousands. Puppet IT automation software is an example where Puppet uses declarative language to manage various stages of the IT infrastructure lifecycle, including the provisioning, patching, configuration, and management of operating system and application components across enterprise data centers and cloud infrastructures

• Shared version control: ensures all system artifacts are well defined, consistently shared, and up to date across the release lifecycle. Development and QA organizations draw from the same platform version, and production groups deploy the exact same version that has been certified by QA

• One step build and deployment: by scripting or automating a wide variety of tasks that software developers do in their day-to-day activities including compiling source code, packaging binary code, running tests, deployment to production systems

   

ahmed.elgenedy@startain.com

Hello World :)

Welcome to my software-related blog ... and my first post :)

• Q: Why I am blogging?
• A: Because I do believe in "Knowledge Management" and that "العلم فى الكراس ... مش فى الراس" .... So here I am trying to document all the technical topics that I am interested in hoping that they will be beneficial for others. Additionally, this will open the door for further discussions with technology experts.

• Q: Is it only software and technology related blog?
• A: Simply, yes :) ... If I changed my mind later, I will have to change the answer of this question :D

   

ahmed.elgenedy@startain.com