Setup of Nginx Vhost

 

Introduction

This is an ancient way of setting up Vhost with nginx. As  we have Chef to automate everything. But before a kickoff with automation using chef, it’s crucial to interpret our problem statement by dealing with it manually.
 
“Choose Older Eggs For Hard Cooking Maria Simmons”

Problem Statement

NGINX is a free, open-source, high-performance HTTP server. Install nginx manually using package manager, and configure virtual host for opstree.com/blog/, chef.opstree.com.

Prerequisites

This exercise considers that you have a basic understanding of Git, and Vagrant. This blog deal with centos7.
 

Install Nginx

Clone our github repository and spin up a bare centos7 vagrant machine.
 
$ git clone git@github.com:OpsTree/Chef.git
 
Go to nginxVhost directory.
 
$ cd  Chef/centos/nginxVhost
 
  • This directory have a Vagrantfile. Which can initiate a centos7 vagrant box with 512mb ram.
 
$ cat Vagrantfile
 
 
This file update and install some basic tools in your vagrant machine using vagrant shell provisioning.
 
  • Launch new vagrant machine and login into it via ssh.
$ vagrant up
 
$ vagrant ssh
 
  • Add nginx repo
As nginx is not available in default list of centos7, we add nginx repo to it.
 
$ sudo yum install -y epel-release
 
  • Install nginx
Install nginx using package manager “yum”.
 
$ sudo yum install -y nginx
 
  • Start nginx
Nginx do not start on its own. Type following to start it.
 
$ sudo service nginx start

Setup Vhost

Let’s go ahead with our problem statement of setting up vhost with nginx. This leads some dull steps to serve our webpages with opstree.com/blog/ and chef.opstree.com.
 
  • Replace nginx.conf file with given nginx.conf file.
 
$ sudo cp /vagrant/nginx.conf /etc/nginx/nginx.conf
 
  • Copy opstree.com/blog/ and chef.opstree.com into the /etc/nginx/conf.d directory
$ sudo cp /vagrant/opstree.com/blog/ /etc/nginx/conf.d/opstree.com/blog/
 
$ sudo cp /vagrant/chef.opstree.com /etc/nginx/conf.d/chef.opstree.com
 
  • Create home directory for vhost.
$ sudo mkdir /usr/share/nginx/blog
$ sudo mkdir /usr/share/nginx/chef
 
  • Create index files.
$ sudo su -c “echo \”Welcome, this is opstree.com/blog/\” > /usr/share/nginx/blog/index.html”
$ sudo su -c “echo \”Welcome, this is chef.opstree.com\” > /usr/share/nginx/chef/index.html”
 
  • Make entry in /etc/hosts
$ sudo vim /etc/hosts
 
127.0.0.1 opstree.com/blog/
127.0.0.1 chef.opstree.com
 
  • Restart nginx server
 
$ sudo service nginx restart
 
  • Access and test your  Vhost
 
$ curl opstree.com/blog/
 
$ curl  chef.opstree.com
You have done all the tiring stuff to set up Nginx Vhost. 
 
“Don’t let a bad day make you feel like you have a bad life.”
 
We understand your hard labor, so in next blog we go ahead to automate all the stuff.   

Chef Start here with ease..

 

 

 

Introduction

 

“Until I discovered cooking, I was never really interested in anything. Julia Child”

Chef, the lead in automation industry has many tickling facet and calibre. Before introducing the potentials of “The Chef”, it’s non negotiable to evade the foresight of its relevance to devops exercises. Chef can take care of server automation, infrastructure environment and continuously deliver your application.

 

Motive behind this array

 

With this blog series, we will familiarize you with the concepts of chef and will try to make you comfortable with our hands on blogs. This series of blog contains 15 blogs in a row which will enhance the knowledge and draw your faith in chef.

 

“Always Pre-Heat The Oven Before Putting The Meat In !!”

 

Prerequisites

 

For all the upcoming blogs we presume that you have basic understanding of Git, Docker,Vagrant and Linux. This blog series is written in consideration with centos as platform, although you can apply them on ubuntu by following some minor changes.

 

 

 

We are going to use our public git repository for all the blogs in this series. We will be using centos7 vagrant box to spin up our testing environment.

 

 

 

We are going to follow a single problem statement in our all blogs to maintain the uniformity and avoid the ambiguity. We are going to install nginx using chef and deploying two virtual host (opstree.com/blog/, chef.opstree.com) with it.

 


Blogs in this series

 

  1. Setup of Nginx Vhost
In this blog we describe Nginx and manually setup the nginx, as per the problem statement and also create two virtual host(opstree.com/blog/, chef.opstree.com).
  1. Chef-Resources Easy as pie..
Here we took some example of resources such as package, git, file and service and put our hands to work with chef-apply. We perform some simple task using chef resources.
  1. Chef-Resources Elementary ingredient..
This blog provides you theoretical concepts about chef resources. In this article  resources and their attributes elaborated.
  1. Chef-Recipes Bake it calmly..
Chef recipes is in consideration for this edition. Create your first recipe and apply it with chef. Complete doctrine behind the recipes of chef with simplified examples.
  1. Chef-Cookbooks Roast it perfectly..
Walls of chef house, the cookbook, written from scratch with step to step explanation. Setup of nginx and proxy implementation with sample cookbook.
  1. Chef-Cookbooks Walls of chef-house..
This blog furnish entire theoretical stuff about cookbooks. This includes command line cookbook generation and handling. One by one description of complete directory structure of a cookbook.
  1. Chef-Kitchen Do it simply..
Installation of chef kitchen. Testing of our nginx cookbook in different environment using docker container. Create, converge, verify and destroy a node with kitchen.
  1. Chef-Kitchen Chefs diagnosis center..
Theory behind the chef kitchen. Complete cycle of kitchen. With in this article elaborated view of .kitchen.yml file, and .kitchen folder provided.
  1. Chef Foodcritic && Chef Rubocop Handle it casually..
Chef lint tools, foodcritic and rubocop requirement. Theory, setup and practice exercises for foodcritic and rubocop.
  1. Chef-Databags Carry all at once..
Introduction to databags and their need. Division of code and data with databags.  Databags implementation with chef-solo. Setup of mysql password with databags.
  1. Chef-Roles Club everybody..
Requirement and implementation of chef roles. Clubbing of multiple nodes with chef roles. Complete web stack (webserver, proxy server and database) setup with roles.
  1. Chef-Environment  Organized wisely..
Chef environments for better management of the need of an organization. A complete organizational view with chef to setup different environment. Handle environments with chef-knife.
  1. Chef Server-Client Setup
Complete setup of chef client-server mode. Use of vagrant provisioning only, to spin up chef-server, chef-client and workstation.
  1. Collaboration of Client Server and Workstations
How chef-server, client and workstations work together to automate a complete infrastructure. Chef-server web interface.
  1. Chef Server-Client Work quietly..
Kickoff working with workstation. Chef-client. Install nginx and setup proxies with nginx cookbook on client node.

 

 

jgit-flow maven plugin to Release Java Application

Introduction

As a DevOps I need a smooth way to release the java application, so I compared two maven plugin that are used to release the java application and in the end I found that Jgit-flow plugin is far better than maven-release plugin on the basis of following points:
  • Maven-release plugin creates .backup and release.properties files to your working directory which can be committed mistakenly, when they should not be. jgit-flow maven plugin doesn’t create these files or any other file in your working directory.
  • Maven-release plugin create two tags.
  • Maven-release plugin does a build in the prepare goal and a build in the perform goal causing tests to run 2 times but jgit-flow maven plugin builds project once so tests run only once.
  • If something goes wrong during the maven plugin execution, It become very tough to roll it back, on the other hand jgit-flow maven plugin makes all changes into the branch and if you want to roll back just delete that branch.
  • jgit-flow maven plugin doesn’t run site-deploy
  • jgit-flow maven plugin provides option to turn on/off maven deployment
  • jgit-flow maven plugin provides option to turn on/off remote pushes/tagging
  • jgit-flow maven plugin keeps the master branch always at latest release version.
Now let’s see how to integrate Jgit-flow maven plugin and use it

How to use Jgit-flow maven Plugin for Release

Follow the flowing steps
    1. Add the following lines in your pom.xml for source code management access
      
         scm:git:
        scm:git:git:
    2. Add these line to resolve the Jgit-flow maven plugin and put the other option that will be required during the build
      com.atlassian.maven.plugins
      maven-jgitflow-plugin
      1.0-m4.3
              
      true
      false
      true
      true
      true
      true
      true
      true
                
      master-test
      deploy-test       

Above code snippet will perform following steps:

    • Maven will resolve the jgitflow plug-in dependency
    • In the configuration section, we describe how jgit-flow plug-in will behave.
    • pushRelease XML tag to enable and disable jgit-flow from releasing the intermediate branches into the git or not.
    • keepBranch XML tag to enable and disable the plug-in for keep the intermediate branch or not.
    • noTag XMl tag to enable and disable the plug-in to create the that tag in git.
    • allowUntracked XML tag to whether allow untracked file during the checking.
    • flowInitContext XML tag is used to override the default and branch name of the jgit-flow plug-in
    • In above code snippet, there is only two branches, master from where that code will be pulled and a intermediate branch that will be used by the jgit-flow plug-in. as I have discussed that jgit-flow plug-in uses the branches to keep it records. so development branch will be created by the plug-in that resides in the local not remotely, to track the release version etc.
  1. To put your releases into the repository manager add these lines
    <distributionManagement>
      <repository>
        <id><auth id></id>
        <url><repo url of repository managers></url>
      </repository>
      <snapshotRepository>
        <id><auth id></id>
        <url><repo url of repository managers></url>
      </snapshotRepository>
    </distributionManagement>
  2. Put the following lines into your m2/settings.xml with your repository manager credentials
    <settings>
      <servers>
        <server>
            <id><PUT THE ID OF THE REPOSITORY OR SNAPSHOTS ID HERE></id>
           <username><USERNAME></username>
           <password><PASSWORD></password>
        </server>
      </servers>
    </settings>

Start Release jgit-flow maven plugin command

To start the new release execute jgitflow:release-start.

Finish Release jgit-flow maven plugin  command

To finish new release, execute mvn jgitflow:release-finish.
For a example I have created a repository in github.com. for testing and two branch master-test and deploy-test. It is assumed that you have configured maven and git your system.

In the deploy-test branch run following command
$ mvn clean -Dmaven.test.skip=true install jgitflow:release-start

This command will take input from you for release version and create a release branch with release/. then it will push this release branch into github repository for temporarily because we are not saving the intermediate branched

Now At the end run this command
$ mvn -Dmaven.test.skip=true jgitflow:release-finish
after finishing this command it will delete release/ from local and remote.

Now you can check the changes in pom file by jgitflow. in the above snapshot, it is master-test branch, you can see in the tag it has removed the snapshot and also increased the version.  It hold the current version of the application.

And in the deploy-test branch it show you new branch on which developers are working on

2015 – What an exciting year has gone by

 

OpsTree 2015 Journey

2015 – What an exciting year has gone by. We have had all the fun we could have asked for. We learnt, grew, built relationships, earned valuable trust and we did all these because we are driven by our core values of honesty, transparency and assiduousness. At the onset of the new year, we would like to thank all our partners who laid their valuable faith on us and helped us do our bit in their success stories. Read on to know all about 2015 at OpsTree.

We built great partnerships

2015 at Opstree was a year filled with excitement and challenges and success. The team grew and we shifted to a great new office, but most importantly we built great partnerships. The team worked towards achieving the agreed goals with the intention to go beyond the expectation of our partners at each step. Our relations with our partners stand testimony to this. 

 We multiplied productivity by learning

We grew qualitatively by deciding to invest heavily in learning. We dedicate one full day per week towards self-development and learning. The results of our learning is evident through the thought leadership initiatives like our blogs, github contributions and open source contributions. But for us, what is more valuable than thought leadership is the significant improvement in the knowledge pool of the company. Today our resources are at least 2x more productive, because of their commitment to learning. 

We matured as Devops Company

We found that there three types of requirements in the market and we aligned our offering along that line. We divided our company into three verticals


1. End to End devops management – This vertical works closely with Product companies typically startup/midsize companies. OpsTree manages the complete dev/tech ops of such companies which allows our partners to focus on their core function while they still have state of the art infra setup and happy end users.


2. Work with big players – This vertical works with large service companies in team augmentation/back to back devops contract mode. This enables OpsTree to create an impact on bigger players through our esteemed partners.

3. Devops Solutioning –This team consists of devops architects who are passionate about devops. Architectural decisions, development of libraries, solutioning and conducting trainings is what drives them.
Worked with some prestigious Logos

Some of our key outcomes for the last year have been the end to end management of DevOps operations of certain well established product companies. It is through their recommendations and references that we are growing at this fast pace. All our client relations have been partnerships where we have grown together to help each other deliver the best. Our expanding team is filled with enthusiastic people who are always looking for their next challenge. 

We Guarantee improved Productivity

At the core of everything we do are our core values of giving our best to every project and trying every possible method to get the most optimized outcome. Giving our partners a “wow” experience is what we aim for. 

Welcome 2016

It is well researched and accepted fact – ‘Devops helps companies deliver more’. Gartner says by 2016 DevOps will evolve from a niche to a mainstream strategy employed by 25% of the Global 2000 organizations. We are ready for this exciting new tomorrow. Are you? 

The Reset Button !!!!

!!!! The Reset button !!!!

Anyone who has recently used the Google Compute Engine for creating the VM instances will be aware of the reset button available.

Since I wasn’t very much sure of it , I just clicked it without much know-how . This resulted in making all the servers to their original state as they were freshly build and which is certainly a very bad thing for us.

But , we had  puppet that we used to create the whole infrastructure as it is . All the modules we had used and changes we made were committed to GitHub repo and this certainly was a boon to us, else we have to sit whole day long for making those changes on the servers.

Just in couple of minutes the new  instances were created using the compute engine-create group instance feature. We did  installation of the foreman  and git on one of the servers and set up the  puppet clients agents accordingly . This took around 15 more crucial minutes and then cloned our GitHub repo which contains all the  necessary modules and configurations required for the rest of infrastructure.

These are the conditions where Configuration Management Tools like Puppet come in picture and help us get on the track in the shortest possible manner.
It was a hectic day but definitely made us learn several important aspects. Using puppet for maintain the infrastructure is really important now days. It is reliable,efficient and fast for deploying configurations on the servers  and making ready for the production work load.