Skip to main content

Kitchen Chef's diagnosis center


Introduction

This time we familiarize you with the backings of chef kitchen. Chef kitchen provides you facility of trial and verification of your cookbooks over different  environment so that you can confidently use  them on your targeted infrastructure. This may be getting boring some times but here is always some seeds in oranges.  

Prerequisites

This blog requires an initial information about Git and Vagrant. This blog uses centos7   as platform. It needs basic understanding of chef, it's cookbooks and chef kitchen. To know about chef cookbooks and work with  chef kitchen follow our previous blogs of this series Chef Start here with ease...


Setup Kitchen

To setup kitchen chase same procedure as we cater in our previous blog Chef-Kitchen  Do it simply .

Backings of  Kitchen

Chef kitchen is the diagnosis center of chef.  Here  you can test the authenticity of your cookbooks on different platforms and confidently use them on your infra. Kitchen achive this by using its configuration file where you define all the things which are necessary to run the complete cycle of kitchen.

.kitchen.yml

This file contains all the required stuff to  run chef kitchen. This file is divided into four major sections.




  • Driver: This is  the name of a driver that will be used to create platform instances used during cookbook testing. This is the default driver used for all platforms and suites unless a platform or suite specifies a driver to override the default driver for that platform or suite; a driver specified for a suite will override a driver set for a platform.


  • Provisioner: This specifies how the chef-client will be simulated during testing. chef_zero andchef_solo are the most common provisioners used for testing cookbooks


  • Platforms: This is a the name of a platform on which Kitchen will perform cookbook testing, for example,ubuntu-12.04 or centos-6.4; depending on the platform.
  • Suites: This is a collection of test suites, with each suite_name grouping defining an aspect of a cookbook to be tested.


.kitchen directory

This directory holds logs for every kitchen run for each platform entry in .kitchen.yml file. This folder also holds keypair for the ssh into your virtual environment.

Analysis of Kitchen

Kitchen performs its own complete cycle of testing via different phases.  Kitchen has its five phases i.e., create, converge, login, verify and destroy.  Each phase has its own significance and some specific task is gonna performed in every phase.

Create

In this step chef’s kitchen tool creates a virtual instance. This virtual instance could use cloud or any other virtualization technology. Chef supports cookbook testing across many cloud providers and virtualization technologies.

Converge

This phase is responsible for application of your cookbook on virtual  instance. Here your all  cookbooks deployed into the virtual instance, though in next steps you can verify the complete functioning of your cookbooks.

Login

This step creates a ssh session into  your machine and provide you a login into it. So that you can run your test to verify the proper functioning of your cookbook.

Verify

In this  step you manually perform all checks so that you can certify the authenticity of your cookbook over all platforms.

Destroy

This is the final step  of your kitchen testing cycle. Here you destroy your virtual environment after entire testing phases.




Here is also a combine command for all these phases i.e.,  kitchen test. This command club all the commands in below listed manner.
  • Kitchen destroy
  • Kitchen create
  • Kitchen converge
  • Kitchen verify


Hass finally this over!!  I know you too get frustrated with the theories. We now aware with the backings of Chef Kitchen.  


Be Warned: I Am Bored. This Could Get Dangerous.

1366791921.gif

Comments

  1. I have read your blog its very attractive and impressive. I like it your blog.

    appvn app

    ReplyDelete

Post a Comment

Popular posts from this blog

EC2 Ssh Connection Refused

When ssh: connect to host ip_address port 22 Connection refused



Unable to access server???
Exactly when you see the error - “ssh: connect to host ip_address port 22: Connection refused” while connecting your AWS EC2 Instance. In order to find solution of the problem, you will go to AWS forum and other channels where you need to answers several questions first. But it's very difficult to find the actual problem. In order to get clues what the problem is, we should provide as many details as possible about what we have tried and the results we are getting. Because there are hundreds of reason why a server or service might not be accessible, also connectivity is one of the toughest issue to diagnose, especially when you are hosting something critical on your box. I've seen several topics on this problem, but none offers a solution to it.  I was not aware for what should I look at first. So I walk through from the very basics and investigated the following thing Use of verbose while ss…

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…

VPC per envrionvment versus Single VPC for all environments

This blog talks about the two possible ways of hosting your infrastructure in Cloud, though it will be more close to hosting on AWS as it is a real life example but this problem can be applied to any cloud infrastructure set-up. I'm just sharing my thoughts and pros & cons of both approaches but I would love to hear from the people reading this blog about their take as well what do they think.


Before jumping right away into the real talk I would like to give a bit of background on how I come up with this blog, I was working with a client in managing his cloud infrastructure where we had 4 environments dev, QA, Pre Production and Production and each environment had close to 20 instances, apart from applications instances there were some admin instances as well such as Icinga for monitoring, logstash for consolidating logs, Graphite Server to view the logs, VPN server to manage access of people.




At this point we got into a discussion that whether the current infrastructure set-u…