Category: DevOps

Packer – How packer has simplified Cloud provisioning

Packer – How packer has simplified Cloud provisioning

What is Packer  –

Packer (HashiCorp) is an open source tool for creating identical machine images for multiple platforms from a single source configuration. Packer is lightweight, creating machine images for multiple platforms in parallel. Packer does not replace configuration management like Chef or Puppet. In fact, when building images, Packer can use tools like Chef or Puppet to install software onto the image.

A machine image is a single static unit that contains a per-configured operating system and installed software which is used to quickly create new running machines. Machine image formats change for each platform. Some examples include AMIs for EC2, VMDK/VMX files for VMware, OVF exports for VirtualBox, etc.

Packer and Continuous Delivery (CD) –

Packer is lightweight, portable, and command-line driven. This makes it the perfect tool to put in the middle of your continuous delivery pipeline. As part of this pipeline, the newly created images can then be launched and tested, verifying the infrastructure changes work. If the tests pass, you can be confident that the image will work when deployed. This brings a new level of stability and testability to infrastructure changes.

Packer template –

A Packer template is a configuration file that defines the image you want to build and how to build it. Packer templates use the Hashicorp Configuration Language (HCL). Packer configuration  has different block in configuration like mentioned below…

  • Packer Block –  The packer {} block contains Packer settings, including specifying a required Packer version.
  • Source Block – Thesource {} block configures a specific builder plugin, which is then invoked by a build block. Source blocks use builders and communicators to define what kind of virtualization to use, how to launch the image you want to provision, and how to connect to it.
  • Build block – The build  { } block defines what Packer should do with the Virtual Machine or Docker container after it launches.

Builders are responsible for creating machines and generating images from them for various platforms. For example, there are separate builders for EC2, VMware, VirtualBox, etc.

Please find the supported builder list here – https://www.packer.io/docs/builders

- virtualbox-iso
- vmware-iso
- hyperv-iso
- docker
  • Provisioner block – The provisioner { } block defines what Packer should do with the image build or Docker container after it launches.

Provisioners use builtin and third-party software to install and configure the machine image after booting. Provisioners prepare the system for use, so common use cases for provisioners include:

  • installing packages
  • patching the kernel
  • creating users
  • downloading application code
  • Post-Processors – Post-processors run after the image is built by the builder and provisioned by the provisioner(s). Post-processors are optional, and they can be used to upload artifacts, re-package, or more.
  • Communicators – are the mechanism Packer uses to upload files, execute scripts, etc. with the machine being created.

Communicators are configured within the builder section. Packer currently supports three kinds of communicators:

  • none – No communicator will be used. If this is set, most provisioners also can’t be used.
  • ssh – An SSH connection will be established to the machine. This is usually the default.
  • winrm – A WinRM connection will be established.

Packer Workflow –

The Packer workflow takes a defined source (usually an operating system installation media in ISO format or an existing machine), creates a machine on the builder, executes the Provisioner’s defined tasks and generates an output. Doing this on Hyper-V, VMWare workstation and Docker may look like what is shown below.

How to use Packer –

Initialize your Packer configuration and check and validate packer template…

$ packer init .
$ packer fmt .
$ packer validate .

Build the image with the packer build command. Packer will print output like what is shown below.

$ packer build new-os-image-template.hcl

Reference –

Packer software – https://www.packer.io

Thank you,

Arun Bagul

(Personal Blog and This is based on my knowledge)

IaC ~ Terraform and Pulumi

IaC ~ Terraform and Pulumi

Terraform and Pulumi

Before reading this blog I would recommend to read this blog – https://www.indiangnu.org/2017/top-5-infrastructure-as-code-iac-software/

Terraform is a tool for building, changing, and versioning infrastructure safely and efficiently. Terraform can manage existing and popular service providers as well as custom in-house solutions.

Key feature of Terraform and Pulumi are..

  1. IaC (Infrastructure as Code) for better management of
  2. Infrastructure and state management
  3. Supports all Cloud providers like Azure, GCP, AWS and virtualization infrastructure like VMware and HyperV
  4. Change Automation
  5. Help you to adapt IaaS, SaaS and PaaS

How to user Terraform –

Terraform has 3 steps . First is “terraform init” initialization step in which Terraform will check and download required providers and plugins. Second is “terraform plan” in this step Terraform will create plan of change in your infrastructure and user has choice to verify and confirm then plan and then start third step ie “terraform apply” this in step Terraform will create resources in providers infrastructure like azure, aws or gcp. Terraform will also save all objects created in Terraform stafe “.tfstate” file and we can use same configuration to add or delete or update resource in same workflow….

To Debug Terraform error we can define debug and log fails mentioned below-

export TF_LOG_PROVIDER=TRACE
export TF_LOG_CORE=TRACE
export TF_LOG_PATH=logs.txt
terraform init
terraform plan
terraform apply

For formatting and configuration validation use below command –

terraform validate
terraform fmt
 
terraform refresh

HashiCorp Configuration Language (HCL)

In Terraform we can define infrastructure required to deploy as code using HCL.

HCL is a toolkit for creating structured configuration languages that are both human- and machine-friendly, for use with command-line tools. Although intended to be generally useful, it is primarily targeted towards devops tools, servers, etc. HCL has both a native syntax, intended to be pleasant to read and write for humans, and a JSON-based variant that is easier for machines to generate and parse. HCL syntax is designed to be easily read and written by humans, and allows declarative logic to permit its use in more complex applications

What is Pulumi ?

Pulumi is a modern infrastructure as code platform that allows you to use familiar programming languages and tools to build, deploy, and manage cloud infrastructure.

Pulumi vs. Terraform

Here is a summary of the key differences between Pulumi and Terraform:

ComponentPulumiTerraform
Language SupportPython, TypeScript, JavaScript, Go, C#, F#Hashicorp Configuration Language (HCL)
State ManagementManaged through Pulumi Service by default, self-managed options availableSelf-managed by default, managed SaaS offering available
Provider SupportNative cloud providers with 100% same-day resource coverage plus Terraform-based providers for additional coverageSupport across multiple IaaS, SaaS, and PaaS providers
OSS LicenseApache License 2.0Mozilla Public License 2.0

Ref –

Pulumi  – https://www.pulumi.com

Terraform – https://www.terraform.io

HCL –  https://github.com/hashicorp/hcl

Terraform Error – https://learn.hashicorp.com/tutorials/terraform/troubleshooting-workflow

Thank you,

Arun Bagul

(Personal Blog and This is based on my knowledge)

LXC – Linux Container

LXC – Linux Container

Introduction-

What are the different Container technology?

Container technology has started after 2013. There is a high potential of getting confused about available container types like Docker , LXC/LXD and CoreOS rocket.

What’s LXC?
LXC (Linux Containers) is an operating-system-level virtualization method for running multiple isolated Linux systems (containers) on a control host using a single Linux kernel.
LXC is a userspace interface for the Linux kernel containment features. Through a powerful API and simple tools, it lets Linux users easily create and manage system or application containers.

Benefits of Linux Containers:
1 – Lightweight built-in virtualization
2 – Application/server isolation
3 – Easy deployment and management
4 – No additional licensing

Weaknesses of Linux Containers:
1 – Locked into the host kernel
2 – Supported only on Linux

Current LXC uses the following kernel features to contain processes:
– Kernel namespaces (ipc, uts, mount, pid, network and user)
– Apparmor and SELinux profiles
AppArmor is a Linux kernel security module that allows the system administrator to restrict programs’ capabilities with per-program profiles.
Security-Enhanced Linux is a Linux kernel security module that provides a mechanism for supporting access control security policies.
Seccomp policies
Chroots (using pivot_root)
Kernel capabilities
CGroups (control groups)

LXC is currently made of a few separate components:
– The liblxc library
– A set of standard tools to control the containers
– Distribution container templates
– Several language bindings for the API:
– python3
– Go
– ruby
– Haskell

The Linux kernel provides the cgroups functionality that allows limitation and prioritization of resources (CPU, memory, block I/O, network, etc.) without the need for starting any virtual machines, and also namespace isolation functionality that allows complete isolation of an applications’ view of the operating environment, including process trees, networking, user IDs and mounted file systems.

LXC containers are often considered as something in the middle between a chroot and a full fledged virtual machine. The goal of LXC is to create an environment as close as possible to a standard Linux installation but without the need for a separate kernel.
LXC combines the kernel’s cgroups and support for isolated namespaces to provide an isolated environment for applications. Docker can also use LXC as one of its execution drivers, enabling image management and providing deployment services.

What’s LXD?
LXD is a next generation system container manager. It offers a user experience similar to virtual machines but using Linux containers instead. LXD isn’t a rewrite of LXC, in fact it’s building on top of LXC to provide a new, better user experience. Under the hood, LXD uses LXC through liblxc and its Go binding to create and manage the containers.

What is difference between LXD vs Docker?
– Docker focuses on application delivery from development to production, while LXD’s focus is system containers.
– LXC in market since 2008 as compare to Docker 2013.
– Earlier Docker was based on LXC. Later Docker replaced it with libcontainer.
– Docker specializes in deploying apps
– LXD specializes in deploying (Linux) Virtual Machines

Application build using LXC?
Anbox – Android in a Box
Anbox is a container-based approach to boot a full Android system on a regular GNU/Linux system like Ubuntu. In other words: Anbox will let you run Android on your Linux system without the slowness of virtualization.

Reference –
WebSite: https://linuxcontainers.org
Version: LXC 2.1.x
https://linuxcontainers.org/lxd/getting-started-cli
http://www.tothenew.com/blog/lxc-linux-containers

Thank you,
Arun Bagul

DevOps – Comparison of different Configuration Management Software

DevOps – Comparison of different Configuration Management Software

Introduction-

I’m working as DevOps since 2010. Many colleagues, friends asked me about comparison of different Configuration Management Software like Chef, Puppet or Ansible/Salt etc.

It is very important and difficult task to choose right CM(configuration management) software for managing Infrastructure and Application deployments.

I’m attaching pdf file with comparison of different CM hope it will help you.

Document – Devops-Comparison-v3

NOTE: This comparison is purely based on my knowledge and experience. Please feel free to share your updates.

Thank You,

Arun Bagul