Total Pageviews

Wednesday, 27 July 2022

Getting started with Kubernetes

Wanted to be back with a Bang, so chose the hottest topic - KUBERNETES 

Name and Origin:

     """Regular online stuff..."""

             It is a Greek word, meaning helmsman or pilot. "Kubernetes" word has letters between the start and ending characters which is why also called K8s. Kubernetes currently is an open-source project originally designed by Google.

Why not just Containers, what is the need for an Orchestration tool?

             We all know Docker containers help to easily build an application just with the help of a packaged image. We can run the containers simply on a VM. Limitations related to running multiple containers (containerized applications) on a VM led to the raise of Orchestration tools. 

Limitations like resources being used by a single container, handling unexpected container restarts, scaling the number of instances of an application, and deploying the configuration changes without downtime.

Kubernetes is one such container orchestration system that helps to easily scale the instances, automate the deployment process and efficiently distribute the resources among the available workloads.

Dockers vs Kubernetes

Docker is a containerized application.

Kubernetes is an Orchestration tool to manage such containerized applications.

Kubernetes Terminology

Namespace

                Within a cluster, Kubernetes Namespace helps us to identify or isolate the set of resources for an application or a project, or a team. The namespace is simply for grouping a set of workloads, services, and resources related to a particular application.

Workload

                 A Workload is simply an application or a component of an application running in a Namespace.

Pod

               """Bookish definition...""'

                A pod is one of the smallest deployable/execution unit in Kubernetes. A pod contains one or more containers. Containers within the pod shares the storage and network resources of a pod.

Container

                A container is the deployed version of the packaged image. It is the software package that we build and deploy to containerize an application. It is immutable, which means once a container is in a running state we cannot make any configuration changes. If we want to make some changes, that needs to be build and the new image is to be deployed.

GIST:

A namespace is a collection of Workloads related to an application, Workloads is a collection of multiple pods, and Pod is a collection of containers that are nothing but multiple packaged software deployments.

Helm

                Helm is simply for the package management in Kubernetes. In simple words, Helm is the equivalent of Yum and Apt for K8s. Kubernetes includes a set of helm charts, that helps to deploy a packaged application.

Tiller

                Tiller is the server portion of the Helm, it runs within the Kubernetes cluster. Going forward in helm3, Tiller is no longer included. It is been deprecated, helm client interacts directly with the Kubernetes API for helm charts deployments.

Loading soon....

Kubernetes Components

kubelet

kubeadm

kubectl


Sorry for taking a while (Looongg gap)...

Hi Everyone,

This is a simple post to apologize for the gap I took all these years. I will be back soon with all the helpful stuff that makes one feel easy to master the SRE/DevOps/System Admin/Infrastructure Engineer Interviews.

In the past few years, I was unable to keep up with my blogging interests due to being busy with multiple things in my personal life and work life. 

Evolution

I agree a lot of changes in the market, with the evolution of DevOps methodology Admin life turned diversely. Many things, many tools, and many platforms came into the picture that made the Sys admin job split into many different roles like SRE, DevOps Engineer, Infrastructure Engineer, etc...

Key factors

1. Automation                             --         Configuration management tools

2. Version control                       --          Source code version management tools

3. CI/CD                                     --          Build and deployment automation

4. Dockerizing applications        --          Enterprise applications packaged and deployed as containers

5. Cloud technologies                 --          Cloud platforms like AWS, Azure, and GCP

The above-mentioned are the key factors that revolutionized the operations part of the IT industry.

Change

Changed from https://solarishandy.blogspot.com/ to https://interviewshandy.blogspot.com/


As earlier, I try my best to post some useful stuff on this blog and I promise that I will try to be regular in posting my content.

Sunday, 5 March 2017

Vagrant Commands and Working with "Vagrantfile" !!!

Let us see working with different commands of Vagrant. In this post, I wanted to explain about, how we can play with "Vagrantfile" to build an development environment. 

For example, if we need 25 similar Ubuntu machines for our development team, we can simply do some modifications related to vm.config in our "Vagrantfile" and simply by giving one "vagrant up" command we can spin 25 machines within minutes only.

Other than regular vagrant halt/destroy/suspend/resume we are going to see about the VM provisioning which we can do through "Vagrantfile". We can even integrate our configuration management tools like Chef and Puppet with Vagrant to automate few things.

Let us start with some basic commands... 

USER@USER-PC MINGW64 /f $ cd Workspace_local/vagrant/
USER@USER-PC MINGW64 /f/Workspace_local/vagrant $ vagrant status
Current machine states:

default                   running (virtualbox)

The VM is running. To stop this VM, you can run `vagrant halt` to shut it down forcefully, or you can run `vagrant suspend` to simply suspend the virtual machine. In either case, to restart it again, simply run `vagrant up`.
USER@USER-PC MINGW64 /f/Workspace_local/vagrant $

To view list of vagrant boxes which are downloaded and readily available....

USER@USER-PC MINGW64 /f/Workspace_local/vagrant $ vagrant box list
ubuntu/trusty64 (virtualbox, 20170222.0.1)
USER@USER-PC MINGW64 /f/Workspace_local/vagrant $ 

To halt our running vagrant....

USER@USER-PC MINGW64 /f/Workspace_local/vagrant $ vagrant halt default
==> default: Attempting graceful shutdown of VM...
USER@USER-PC MINGW64 /f/Workspace_local/vagrant $ vagrant status
Current machine states:

default                   poweroff (virtualbox)

The VM is powered off. To restart the VM, simply run `vagrant up`
USER@USER-PC MINGW64 /f/Workspace_local/vagrant $

To restart we can use the command reload or up,

USER@USER-PC MINGW64 /f/Workspace_local/vagrant $ vagrant reload
==> default: Checking if box 'ubuntu/trusty64' is up to date...
==> default: Clearing any previously set forwarded ports...
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
    default: The guest additions on this VM do not match the installed version of
    default: VirtualBox! In most cases this is fine, but in rare cases it can
    default: prevent things such as shared folders from working properly. If you see
    default: shared folder errors, please make sure the guest additions within the
    default: virtual machine match the version of VirtualBox you have installed on
    default: your host and reload your VM.
    default:
    default: Guest Additions Version: 4.3.36
    default: VirtualBox Version: 5.0
==> default: Mounting shared folders...
    default: /vagrant => F:/Workspace_local/vagrant
==> default: Machine already provisioned. Run `vagrant provision` or use the `--provision`
==> default: flag to force provisioning. Provisioners marked to run always will still run.
USER@USER-PC MINGW64 /f/Workspace_local/vagrant $

Let us check the current status,

USER@USER-PC MINGW64 /f/Workspace_local/vagrant $ vagrant status
Current machine states:

default                   running (virtualbox)

The VM is running. To stop this VM, you can run `vagrant halt` to shut it down forcefully, or you can run `vagrant suspend` to simply suspend the virtual machine. In either case, to restart it again, simply run `vagrant up`.
USER@USER-PC MINGW64 /f/Workspace_local/vagrant $

Previously what we did is Shutdown, we have a option to suspend our Vagrant instance...

USER@USER-PC MINGW64 /f/Workspace_local/vagrant $ vagrant suspend
==> default: Saving VM state and suspending execution...
USER@USER-PC MINGW64 /f/Workspace_local/vagrant $ vagrant status
Current machine states:

default                   saved (virtualbox)

To resume this VM, simply run `vagrant up`.
USER@USER-PC MINGW64 /f/Workspace_local/vagrant $

We can resume our vagrant instance from its current state,

USER@USER-PC MINGW64 /f/Workspace_local/vagrant $ vagrant resume
==> default: Resuming suspended VM...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
==> default: Machine booted and ready!
==> default: Machine already provisioned. Run `vagrant provision` or use the `--provision`
==> default: flag to force provisioning. Provisioners marked to run always will still run.
USER@USER-PC MINGW64 /f/Workspace_local/vagrant $

Lets check the status again...

USER@USER-PC MINGW64 /f/Workspace_local/vagrant $ vagrant status
Current machine states:

default                   running (virtualbox)

The VM is running. To stop this VM, you can run `vagrant halt` to shut it down forcefully, or you can run `vagrant suspend` to simply suspend the virtual machine. In either case, to restart it again, simply run `vagrant up`.
USER@USER-PC MINGW64 /f/Workspace_local/vagrant $

We can completely destroy our instance, but before destroy we need to halt...

USER@USER-PC MINGW64 /f/Workspace_local/vagrant $ vagrant halt
==> default: Attempting graceful shutdown of VM...
USER@USER-PC MINGW64 /f/Workspace_local/vagrant $ vagrant status
Current machine states:

default                   poweroff (virtualbox)

The VM is powered off. To restart the VM, simply run `vagrant up`
USER@USER-PC MINGW64 /f/Workspace_local/vagrant $

Now we can simply destroy,

USER@USER-PC MINGW64 /f/Workspace_local/vagrant $ vagrant destroy
    default: Are you sure you want to destroy the 'default' VM? [y/N] y
==> default: Destroying VM and associated drives...
USER@USER-PC MINGW64 /f/Workspace_local/vagrant $

USER@USER-PC MINGW64 /f/Workspace_local/vagrant $ vagrant status
Current machine states:

default                   not created (virtualbox)

The environment has not yet been created. Run `vagrant up` to create the environment. If a machine is not created, only the default provider will be shown. So if a provider is not listed, then the machine is not created for that environment.
USER@USER-PC MINGW64 /f/Workspace_local/vagrant $

If we delete our existing Vagrantfile, then...

USER@USER-PC MINGW64 /f/Workspace_local/vagrant $ vagrant status
A Vagrant environment or target machine is required to run this command. Run `vagrant init` to create a new Vagrant environment. Or, get an ID of a target machine from `vagrant global-status` to run this command on. A final option is to change to a directory with a Vagrantfile and to try again.
USER@USER-PC MINGW64 /f/Workspace_local/vagrant $

Let us see how we can run a script at the time of "vagrant up" by including it in the "Vagrantfile".

Shell Script:

Below I am going to make some changes in default Vagrantfile and include a script which will run and install "Apache" during the start up of instance...

USER@USER-PC MINGW64 / $ cd /f/Workspace_local/vagrant
USER@USER-PC MINGW64 /f/Workspace_local/vagrant $ vi Vagrantfile
USER@USER-PC MINGW64 /f/Workspace_local/vagrant $

USER@USER-PC MINGW64 /f/Workspace_local/vagrant $ cat Vagrantfile | grep vag1
config.vm.define "vag1" do |vag1|
  vag1.vm.box = "ubuntu/trusty64"
  vag1.vm.network "private_network",type:"dhcp"
  vag1.vm.synced_folder "../vagrant", "/home/vagrant"
  vag1.vm.box_url = "https://atlas.hashicorp.com/ubuntu/boxes/trusty64"
  vag1.vm.network "forwarded_port", guest: 80, host: 8080
  vag1.vm.provision "shell", path: "apache_script.sh"
USER@USER-PC MINGW64 /f/Workspace_local/vagrant $


If we check the status, now we can see...

USER@USER-PC MINGW64 /f/Workspace_local/vagrant $ vagrant status
Current machine states:

vag1                      not created (virtualbox)

The environment has not yet been created. Run `vagrant up` to create the environment. If a machine is not created, only the default provider will be shown. So if a provider is not listed, then the machine is not created for that environment.
USER@USER-PC MINGW64 /f/Workspace_local/vagrant $ 

As you see, I included a script "apache_script.sh" in my Vagrantfile. I am going to include few lines, so that my script is responsible for Apache installation in the Vagrant instance...

USER@USER-PC MINGW64 /f/Workspace_local/vagrant $ vi apache_script.sh
USER@USER-PC MINGW64 /f/Workspace_local/vagrant $

USER@USER-PC MINGW64 /f/Workspace_local/vagrant $ cat apache_script.sh
date

apt-get update
apt-get install -y apache2

echo " checking apache service"
service apache2 status

USER@USER-PC MINGW64 /f/Workspace_local/vagrant $

If we up this instance, it will straightaway creates a ubuntu instance and installs Apache in it.

USER@USER-PC MINGW64 /f/Workspace_local/vagrant $ vagrant up
Bringing machine 'vag1' up with 'virtualbox' provider...
==> vag1: Importing base box 'ubuntu/trusty64'...
==> vag1: Matching MAC address for NAT networking...
==> vag1: Checking if box 'ubuntu/trusty64' is up to date...

************ OUTPUT TRUNCATED ********************

    vag1: virtual machine match the version of VirtualBox you have installed on
    vag1: your host and reload your VM.
    vag1:
    vag1: Guest Additions Version: 4.3.36
    vag1: VirtualBox Version: 5.0
==> vag1: Configuring and enabling network interfaces...
==> vag1: Mounting shared folders...
    vag1: /vagrant => F:/Workspace_local/vagrant
    vag1: /home/vagrant => F:/Workspace_local/vagrant
==> vag1: Running provisioner: shell...
    vag1: Running: C:/Users/USER/AppData/Local/Temp/vagrant-shell20170305-8664-103uhrn.sh
==> vag1: Get:1 http://security.ubuntu.com trusty-security InRelease [65.9 kB]
==> vag1: Ign http://archive.ubuntu.com trusty InRelease

************ OUTPUT TRUNCATED ********************

==> vag1: Ign http://archive.ubuntu.com trusty/restricted Translation-en_US
==> vag1: Ign http://archive.ubuntu.com trusty/universe Translation-en_US
==> vag1: Fetched 11.8 MB in 35s (336 kB/s)
==> vag1: Reading package lists...
==> vag1: Reading package lists...
==> vag1: Building dependency tree...
==> vag1: Reading state information...
==> vag1: The following extra packages will be installed:

************ OUTPUT TRUNCATED ********************

==> vag1: Preparing to unpack .../libaprutil1-dbd-sqlite3_1.5.3-1_amd64.deb ...
==> vag1: Unpacking libaprutil1-dbd-sqlite3:amd64 (1.5.3-1) ...
==> vag1: Selecting previously unselected package libaprutil1-ldap:amd64.
==> vag1: Preparing to unpack .../libaprutil1-ldap_1.5.3-1_amd64.deb ...
==> vag1: Unpacking libaprutil1-ldap:amd64 (1.5.3-1) ...

************ OUTPUT TRUNCATED ********************

==> vag1:  *
==> vag1: Setting up ssl-cert (1.0.33) ...
==> vag1: Processing triggers for libc-bin (2.19-0ubuntu6.9) ...
==> vag1: Processing triggers for ureadahead (0.100.0-16) ...
==> vag1: Processing triggers for ufw (0.34~rc-0ubuntu2) ...
==> vag1:  checking apache service
==> vag1:  * apache2 is running
USER@USER-PC MINGW64 /f/Workspace_local/vagrant $

Enter localhost:8080 in the browser url and check...


Lets login and check whether the home directory is in sync or not...

USER@USER-PC MINGW64 /f/Workspace_local/vagrant $ vagrant ssh
vagrant@127.0.0.1's password:
Welcome to Ubuntu 14.04.5 LTS (GNU/Linux 3.13.0-110-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

  System information as of Sun Mar  5 21:14:39 UTC 2017

  System load:  0.75              Processes:           79
  Usage of /:   3.6% of 39.34GB   Users logged in:     0
  Memory usage: 25%               IP address for eth0: 10.0.2.15
  Swap usage:   0%

************ OUTPUT TRUNCATED ********************

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.
vagrant@vagrant-ubuntu-trusty-64:~$

Since this is not the default one, it asks for the password of vagrant user...

vagrant@vagrant-ubuntu-trusty-64:~$ pwd
/home/vagrant
vagrant@vagrant-ubuntu-trusty-64:~$ ls
apache_script.sh  Vagrantfile  Vagrantfile_orig
vagrant@vagrant-ubuntu-trusty-64:~$

My script and Vagrantfile modifications done their job perfectly.

CHEF:

Let us try initializing another instance using chef by writing a simple recipe to build an Apache server.

USER@USER-PC MINGW64 /f/Workspace_local/vagrant $ vi Vagrantfile

Edited Vagrantfile, so that it will create a vagrant instance with name chef-vag and chef installed at the time of spin up.

USER@USER-PC MINGW64 /f/Workspace_local/vagrant $ cat Vagrantfile | grep chefvag
config.vm.define "chef-vag" do |chefvag|
  chefvag.vm.box = "ubuntu/trusty64"
  chefvag.vm.network "private_network",type:"dhcp"
  chefvag.vm.synced_folder "../vagrant", "/home/vagrant"
  chefvag.vm.box_url = "https://atlas.hashicorp.com/ubuntu/boxes/trusty64"
  chefvag.vm.network "forwarded_port", guest: 80, host: 1234
  chefvag.vm.provision "chef_solo" do |chef|
USER@USER-PC MINGW64 /f/Workspace_local/vagrant $


To run the recipe we need to create the chef directory structure,

USER@USER-PC MINGW64 /f/Workspace_local/vagrant $ mkdir -p cookbooks/myvag/recipes
USER@USER-PC MINGW64 /f/Workspace_local/vagrant $ cd cookbooks/myvag/recipes/

USER@USER-PC MINGW64 /f/Workspace_local/vagrant/cookbooks/myvag/recipes $ vi default.rb
USER@USER-PC MINGW64 /f/Workspace_local/vagrant/cookbooks/myvag/recipes $

Sample Chef recipe which helps for apache installation on my chef-vag instance,

USER@USER-PC MINGW64 /f/Workspace_local/vagrant/cookbooks/myvag/recipes $ cat default.rb
execute "apt-get update"
package "apache2"
execute "service apache2 status"
USER@USER-PC MINGW64 /f/Workspace_local/vagrant/cookbooks/myvag/recipes $

USER@USER-PC MINGW64 /f/Workspace_local/vagrant/cookbooks/myvag/recipes $ cd ../../../
USER@USER-PC MINGW64 /f/Workspace_local/vagrant $

Lets check the current status of my instance,

USER@USER-PC MINGW64 /f/Workspace_local/vagrant $ vagrant status
Current machine states:

chef-vag                  not created (virtualbox)

The environment has not yet been created. Run `vagrant up` to create the environment. If a machine is not created, only the default provider will be shown. So if a provider is not listed, then the machine is not created for that environment.
USER@USER-PC MINGW64 /f/Workspace_local/vagrant $

Command to check the status of all existing vagrant instances,

USER@USER-PC MINGW64 /f/Workspace_local/vagrant $ vagrant global-status

id       name   provider   state   directory
-----------------------------------------------------------------------
92481d5  vag1   virtualbox running F:/Workspace_local/vagrant

The above shows information about all known Vagrant environments on this machine. This data is cached and may not be completely up-to-date. To interact with any of the machines, you can go to that directory and run Vagrant, or you can use the ID directly with Vagrant commands from any directory. For example:  "vagrant destroy 1a2b3c4d"

USER@USER-PC MINGW64 /f/Workspace_local/vagrant $

Let us try to start the chef-vag instance....

USER@USER-PC MINGW64 /f/Workspace_local/vagrant $ vagrant up
Bringing machine 'chef-vag' up with 'virtualbox' provider...
==> chef-vag: Checking if box 'ubuntu/trusty64' is up to date...
==> chef-vag: Fixed port collision for 22 => 2222. Now on port 2200.
==> chef-vag: Clearing any previously set network interfaces...
==> chef-vag: Preparing network interfaces based on configuration...
    chef-vag: Adapter 1: nat
    chef-vag: Adapter 2: hostonly
==> chef-vag: Forwarding ports...
    chef-vag: 80 (guest) => 1234 (host) (adapter 1)
    chef-vag: 22 (guest) => 2200 (host) (adapter 1)
==> chef-vag: Booting VM...
==> chef-vag: Waiting for machine to boot. This may take a few minutes...
    chef-vag: SSH address: 127.0.0.1:2200
    chef-vag: SSH username: vagrant
    chef-vag: SSH auth method: private key
    chef-vag:

************ OUTPUT TRUNCATED ********************

    chef-vag: /home/vagrant => F:/Workspace_local/vagrant
    chef-vag: /tmp/vagrant-chef/55cd743a2054d1c91454ad65be2b0aa4/cookbooks => F:/Workspace_local/vagrant/cookbooks
==> chef-vag: Running provisioner: chef_solo...
    chef-vag: Installing Chef (latest)...
==> chef-vag: Generating chef JSON and uploading...
==> chef-vag: Running chef-solo...
==> chef-vag: stdin: is not a tty
==> chef-vag: [2017-03-05T23:01:59+00:00] INFO: Started chef-zero at chefzero://localhost:8889 with repository at /tmp/vagrant-chef/55cd743a2054d1c91454ad65be2b0aa4, /tmp/vagrant-chef
==> chef-vag:   One version per cookbook
==> chef-vag: [2017-03-05T23:01:59+00:00] INFO: Forking chef instance to converge...
==> chef-vag: Starting Chef Client, version 12.19.36
==> chef-vag: [2017-03-05T23:01:59+00:00] INFO: *** Chef 12.19.36 ***

************ OUTPUT TRUNCATED ********************

==> chef-vag:
==> chef-vag: - myvag (0.0.0)
==> chef-vag: Installing Cookbook Gems:
==> chef-vag: Compiling Cookbooks...
==> chef-vag: Converging 3 resources
==> chef-vag: Recipe: myvag::default
==> chef-vag:
==> chef-vag: * execute[apt-get update] action run
==> chef-vag:
==> chef-vag:     [execute] Hit http://security.ubuntu.com trusty-security InRelease
==> chef-vag:               Ign http://archive.ubuntu.com trusty InRelease
==> chef-vag:
==> chef-vag: Hit http://archive.ubuntu.com trusty-updates InRelease
==> chef-vag:               Hit http://security.ubuntu.com trusty-security/main Sources

************ OUTPUT TRUNCATED ********************

==> chef-vag:
==> chef-vag: Hit http://archive.ubuntu.com trusty-backports/universe Sources
==> chef-vag:               Hit http://archive.ubuntu.com trusty-backports/multiverse Sources
==> chef-vag:               Hit http://archive.ubuntu.com trusty-backports/main amd64 Packages
==> chef-vag:               Hit http://archive.ubuntu.com trusty-backports/multiverse amd64 Packages
==> chef-vag:
==> chef-vag: Hit http://archive.ubuntu.com trusty-backports/main Translation-en
==> chef-vag:

************ OUTPUT TRUNCATED ********************

==> chef-vag: [2017-03-05T23:02:08+00:00] INFO: execute[apt-get update] ran successfully
==> chef-vag:     - execute apt-get update
==> chef-vag:   * apt_package[apache2] action install
==> chef-vag: [2017-03-05T23:02:18+00:00] INFO: apt_package[apache2] installed apache2 at 2.4.7-1ubuntu4.13
==> chef-vag:
==> chef-vag:     - install version 2.4.7-1ubuntu4.13 of package apache2
==> chef-vag:   * execute[service apache2 status] action run
==> chef-vag:
==> chef-vag:     [execute]  * apache2 is running
==> chef-vag: [2017-03-05T23:02:18+00:00] INFO: execute[service apache2 status] ran successfully
==> chef-vag:     - execute service apache2 status
==> chef-vag: [2017-03-05T23:02:18+00:00] INFO: Chef Run complete in 16.691522998 seconds
==> chef-vag: Running handlers:
==> chef-vag: [2017-03-05T23:02:18+00:00] INFO: Running report handlers
==> chef-vag: Running handlers complete
==> chef-vag: [2017-03-05T23:02:18+00:00] INFO: Report handlers complete
==> chef-vag: Chef Client finished, 3/3 resources updated in 18 seconds

USER@USER-PC MINGW64 /f/Workspace_local/vagrant $


USER@USER-PC MINGW64 /f/Workspace_local/vagrant $ vagrant status
Current machine states:

chef-vag                  running (virtualbox)

The VM is running. To stop this VM, you can run `vagrant halt` to shut it down forcefully, or you can run `vagrant suspend` to simply suspend the virtual machine. In either case, to restart it again, simply run `vagrant up`.
USER@USER-PC MINGW64 /f/Workspace_local/vagrant $

USER@USER-PC MINGW64 /f/Workspace_local/vagrant $ vagrant global-status
id       name     provider   state   directory
-------------------------------------------------------------------------
92481d5  vag1     virtualbox running F:/Workspace_local/vagrant
bd57218  chef-vag virtualbox running F:/Workspace_local/vagrant 
USER@USER-PC MINGW64 /f/Workspace_local/vagrant $

PUPPET:

Similar to Chef recipe, we can even write a Puppet manifest file and provision puppet in the Vagrantfile to automate things...

USER@USER-PC MINGW64 /f/Workspace_local/vagrant $ vi Vagrantfile
USER@USER-PC MINGW64 /f/Workspace_local/vagrant $

USER@USER-PC MINGW64 /f/Workspace_local/vagrant $ cat Vagrantfile
# -*- mode: ruby -*-
# vi: set ft=ruby :

# All Vagrant configuration is done below. The "2" in Vagrant.configure
# configures the configuration version (we support older styles for
# backwards compatibility). Please don't change it unless you know what
# you're doing.
Vagrant.configure("2") do |config|

config.vm.define "puppet-vag" do |puppetvag|

  puppetvag.vm.hostname = "pupp-ci"
  puppetvag.vm.box = "ubuntu/trusty64"
  puppetvag.vm.box_url = "https://atlas.hashicorp.com/ubuntu/boxes/trusty64"
  puppetvag.vm.network "forwarded_port", guest: 80, host: 1111

  puppetvag.vm.provision "puppet" do |puppet|
          puppet.manifests_path="manifests"
          puppet.manifest_file="default.pp"
  end
end
config.vm.define "puppet-vag-db" do |puppetvagdb|

  puppetvagdb.vm.hostname = "pupp-db"
  puppetvagdb.vm.box = "centos/7"
  puppetvagdb.vm.box_url = "https://atlas.hashicorp.com/centos/boxes/7"
  end
end
USER@USER-PC MINGW64 /f/Workspace_local/vagrant $

This time I am creating a instance with CentOS template....

USER@USER-PC MINGW64 /f/Workspace_local/vagrant $ vagrant status
Current machine states:

puppet-vag                not created (virtualbox)
puppet-vag-db             not created (virtualbox)

This environment represents multiple VMs. The VMs are all listed above with their current state. For more information about a specific VM, run `vagrant status NAME`.
USER@USER-PC MINGW64 /f/Workspace_local/vagrant $

Like Chef, we need to create directory structure of Puppet to run the Puppet default.pp manifest file during initiation of instance...

USER@USER-PC MINGW64 /f/Workspace_local/vagrant $ mkdir manifests
USER@USER-PC MINGW64 /f/Workspace_local/vagrant $ cd manifests/

USER@USER-PC MINGW64 /f/Workspace_local/vagrant/manifests $ vi default.pp

Sample manifest file to automate apache installation,

USER@USER-PC MINGW64 /f/Workspace_local/vagrant/manifests $ cat default.pp
exec { "apt-get update":
        command => "/usr/bin/apt-get update",
}

package { "apache2":
        require => Exec["apt-get update"],
}
USER@USER-PC MINGW64 /f/Workspace_local/vagrant/manifests

Lets spin up the instances with puppet provisioning,

USER@USER-PC MINGW64 /f/Workspace_local/vagrant/manifests vagrant up
Bringing machine 'puppet-vag' up with 'virtualbox' provider...
Bringing machine 'puppet-vag-db' up with 'virtualbox' provider...
==> puppet-vag: Importing base box 'ubuntu/trusty64'...

**************** OUTPUT TRUNCATED ***************

==> puppet-vag: Booting VM...
==> puppet-vag: Waiting for machine to boot. This may take a few minutes...
    puppet-vag: SSH address: 127.0.0.1:2201
    puppet-vag: SSH username: vagrant
    puppet-vag: SSH auth method: private key
    puppet-vag:
    puppet-vag: Vagrant insecure key detected. Vagrant will automatically replace
    puppet-vag: this with a newly generated keypair for better security.
    puppet-vag:
    puppet-vag: Inserting generated public key within guest...
    puppet-vag: Removing insecure key from the guest if it's present...
    puppet-vag: Key inserted! Disconnecting and reconnecting using new SSH key...
==> puppet-vag: Machine booted and ready!

**************** OUTPUT TRUNCATED ***************

==> puppet-vag: Setting hostname...
==> puppet-vag: Mounting shared folders...
    puppet-vag: /vagrant => F:/Workspace_local/vagrant
    puppet-vag: /tmp/vagrant-puppet/manifests-a11d1078b1b1f2e3bdea27312f6ba513 => F:/Workspace_local/vagrant/manifests
==> puppet-vag: Running provisioner: puppet...
==> puppet-vag: Running Puppet with default.pp...
==> puppet-vag: stdin: is not a tty
==> puppet-vag: Notice: Compiled catalog for pupp-ci.hsd1.nj.comcast.net in environment production in 0.18 seconds
==> puppet-vag: Notice: /Stage[main]/Main/Exec[apt-get update]/returns: executed successfully
==> puppet-vag: Notice: /Stage[main]/Main/Package[apache2]/ensure: ensure changed 'purged' to 'present'
==> puppet-vag: Notice: Finished catalog run in 80.51 seconds
==> puppet-vag-db: Box 'centos/7' could not be found. Attempting to find and install...
    puppet-vag-db: Box Provider: virtualbox
    puppet-vag-db: Box Version: >= 0
==> puppet-vag-db: Loading metadata for box 'https://atlas.hashicorp.com/centos/boxes/7'
    puppet-vag-db: URL: https://atlas.hashicorp.com/centos/boxes/7
==> puppet-vag-db: Adding box 'centos/7' (v1611.01) for provider: virtualbox
    puppet-vag-db: Downloading: https://atlas.hashicorp.com/centos/boxes/7/versions/1611.01/providers/virtualbox.box
    puppet-vag-db:
==> puppet-vag-db: Successfully added box 'centos/7' (v1611.01) for 'virtualbox'!

**************** OUTPUT TRUNCATED ***************

USER@USER-PC MINGW64 /f/Workspace_local/vagrant/manifests $

Lets check the apache server from browser's url... (Always remember to change port number, when you are running more than 1 Apache server)

localhost:1111

USER@USER-PC MINGW64 /f/Workspace_local/vagrant/manifests $ vagrant status
Current machine states:

puppet-vag                running (virtualbox)
puppet-vag-db             running (virtualbox)

This environment represents multiple VMs. The VMs are all listed above with their current state. For more information about a specific VM, run `vagrant status NAME`.
USER@USER-PC MINGW64 /f/Workspace_local/vagrant/manifests

One last command which I wanted to discuss is "vagrant box add"

We can create our own vagrant boxes which means, in our infrastructure if we have a instance and we need to replicate more from existing one, then we can package a box and using that packaged box we can spin new instances...

Let me explain with a scenario, we implemented different instances so far and my development environment is in need of more "vag1" instances.

Package it,

USER@USER-PC MINGW64 /f/Workspace_local/vagrant $ vagrant box list
         centos/7        (virtualbox, 1611.01)
         ubuntu/trusty64 (virtualbox, 20170222.0.1)
USER@USER-PC MINGW64 /f/Workspace_local/vagrant $

USER@USER-PC MINGW64 /f/Workspace_local/vagrant $ vagrant package vag1

This will package by compressing the instance, once the package is ready...

USER@USER-PC MINGW64 /f/Workspace_local/vagrant $ vagrant box add <package_name>

These are many other things to work on Vagrant, these are different main things which we should know atleast. Depending upon different scenarios and requirements we modify the Vagrantfile in different ways.

################################################################################