Chef important introduction

Whole purpose of the configuration management tool:

To create the environment.

(I want a operating system,with java installed).

That environment,what we called as the infrastructure,on the top of that,we will run the application.

For dot.net application,IIS server should be configured.

Every application,whatever your company is developing would require certain environment to run it.

It would be as simple as commandline application.

Even for that,you may require python to run it.

Or probably,some users to be created.so it can be anything,it can be software installation or

It can be folder creations.

And generally,we do these things on our servers.

(these kind of configurations,we do on our servers).

Whenever we do that,on a broader way:

Historically we have two ways of doing it:

First one is the manual.

(you will ask the dev team,to write the set of instructions to be done for the installation).

And admin will do the configuration,based on the instructions given by the dev guys).

That was the first approach.

(example:I want linux server,tomcat).

Second is the writing a  shell/batch files in the windows.

(this creates some amount of automation).

In future the batch will be replaced by the powershell.

These are the traditional ways followed.

We are speaking about the configuration management tools:

Claim Infrastrcture is written as code (IAC).

The code can be different from different tools.

(writing your infrastructure as a code).

Whenever we do this,first,

Converting infrastructure to code you have some syntantical  items.

(syntactical ways of telling it).

If you want something to be installed.

Probably the way you tell differs.

(but your intenstion is same across tools).

When you write a code,you can execute it multiple times.

(what will be advantage of this code,these are consistent).

Whenever we write code,we can store it in version control system.

Whatever you write in the configuration management tool are bounded to be the version control.

Important characterstic  of any configuration management tool.

Idempotance

For example,shell file,I have written some types.

I will create folder and in that folder I am writing some files.

I will try to excute second time,it will create another file and fails.

The best thing is the scalable,you can apply this to multiple servers.

Some times you write instructions,which will work in multiple flavours of the linux.

The command which you write to start the service.

Centos 6 and centos 7 changes.

If you run one time or many a times you will get the same result.

They want the end result to be consistent.

Flipcart is a webapplication.

For any webapplication we  need a webserver.

Basically I need to write a infrastructure as a code,to create that environment.

Node or the server are the same.

We have three servers these where we want to create our environment.

Chef server will take care of the responsilibilities.applying configurations to your machines.

Once you create the chef-server

And after that you will install one chef component.

(and that component we called it as the chef-client).

The servers on which,we run our business. Is production.

The servers on which we test our applications. Us dev.

Chef-client software is configured to chef server periodically.

Chef-client is configured to ask,questions,it asked very simple question,do you have any job to do ?

(chef-client will ask questions to the chef-server).

Chef-client is configured for the periodic time.

Chef-client for every 30 mins will ask questions to the chef-server.

And chef-server responds back by saying,if yes or no, if yes it will say what work has to be done.

So,who is intiating the request.

Client is intiating the request.

Basically these models are called the PULL MODELS.

Client is asking for the details.

This is pull kind of configuration management.

So for every 30 mins,client will ask the chef-server do I need to do anything.

Your system where you develop the scripts.that is the workstation.

(chef will have one more architecturial component called the chef-workstation).

Chef only have this architectural component called workstation.

In earlier  chef we have only the knife,now we have the knife/chefdk.

But we are going to call as a chefdk(chef developmentkit).

To work on chef,on our machines we should have the chefdk to install.

we are installing the package tree on the linux servers.

When you apply anything from  localworkstation  to chef-server it did not apply directly to the nodes/server.

In chef,the script goes and it will be executed.

Whatever we write in chef,internally executed by the ruby.

All of the chef will be internally executed by the ruby.

That 30 minutes during which it tries to communicate,technically it is called the convergence.

One more term called the configuration drift or called as convergence drift.

One server asked the question to the chef server at 7am and it is configured run at halfhour
so when we  will be the next question 7:30

At 7:15 one of our developer,written script to written  a folder called  /var/temp

And he has uploaded the script  to the chef-server.these all done at 7:15,will the directory be created,so at 7:15 we have a difference between the configuration and the reality.

From 7:15 to 7:30 we have a situation what you want and what you present.this state is called the CONFIGURATION DRIFT or CONVERGENCE DRIFT.

(7:15 to 7:30 your expected to folder be there,but there is no folder).

The reason behind there is no folder on the production machine because the chef-client did not asked the question,if it is asked the question,then only It can able to create a folder.

Note:

Your chef server has to be a linux machine.

(whether it is Ubuntu/centos/fedora).

Chef workstation  and chef-client(nodes/servers) can be anything may be windows/linux/mac/unix

The problem with the script,it cannot be scaled,so we are going for the infrastructure tools.

(using script,we have to make a lot of tooling inorder to make that script work).

Why infrastructure as a code is a forward way?

The reason behind it,whenever you write code,you can test it.(let it be any code).

This testing is called the unit testing,that we cannot do by the shell scripting.

(whenever I write a code,I can test it,whenever I write a script I cannot able to test it (I mean unit testing is not possible).

I mean,I test it by manually executing it.

Basically,we are learning,how to write a infrastructure as a code,using the chef.

So,if it is chef,how do we write it.

Intially,we used to have a lot physical servers.

Do I need to know about the shell scripting?

I certain organsations,your  job as a devops engineer,will be,these are the existing shell scripts,we have to be in a position to read that and automate it.

Converting the bash script to the equivalent chef code.(equivalent configuration management tool).

Important concept of configuration management rule:

Denoting an element of a set which is unchanged in value when multiplied or otherwise operated on by itself.

The great comparsion,with configuration management I can give idempotent,we cannot give samething with the shell.

(if I run script for one time or for 1000 times,I will always get the same output).

Hosted chef,upto five nodes it was free.if you go beyond we have to purchase the licenses.

Create a organsation on your name.

the other components are knife/chefdk components and the chef-client component.

Bookshelf,Manage and the chef-client will speak with the help of API.

And chef server have multiple components in it.

(bookshelf,cookbooks,searchindex and Datastore and we will speak about the different components).

DK and knife are same

Agent and client are also same.

This workflow is very very important.

Chef has architecturally three components:

Local workstation,chef server and chef nodes.

Chef server will only be one

Where as chef nodes and chef clients are multiple.

On the local workstation,we have a components to develop the scripts .

Chef-client   is the agent software.

(what does agent-software does is,for every 30 mins it gives updates about the chef-nodes).

(if there are new policies it will apply,so this is called as convergence).

There is another concept called the configuration drift,it is also called the,the gap or the difference between the ideal situation and the current situation.

AWS plugins have the opswork and it can support any components.

But if you want a managed service,chef is an answer.

Chef work is very simple:

It has to transfer a file

It has to store the reports.(report comes back,it has to store it).

They are architectural components ,they are message queues over there.

(there is no chance of message to be locked).

They don’t use API calls,they use the message queues internally (so when the load is more,it might be slow,but does not break).

For example: (Message queues)

You went to atm and you swiped money.you did not get the money,but the balance was cutted from the account and at night 12pm you got your money back.

Reason:for example,whenever you sent a message,http:google.com/ that is called as unreliable messaging because once you type that,if google server is up,the message will reach to it,other wise it may not reach.

Reliable messaging is the message queue.

Before sending the message,the message will send in to a queue.

There will be queue of messages.

And then you would have a server,once it reaches the server,your server will send the acknowledgement.till it gets the acknowledgement,it will not delete the message from the queue.so it is a guaranteed delivery.

Chef uses the message queues.

So,everything you asked is guarantee delivery.

This happens in chef and puppet,this both uses the message queues.

Puppet problem:

We have to remember the directory structures.

(interms of puppet,we need to know the conf def,hierarchies and the directory structure and related environment paths).

Chef solution:

And the only way to eliminate that is:

The developers machine,rather than the server.

You just develop in your machine and just upload to the chef server using simple knife commands.

Can we use chef-client less?

If you have the access to the chef-server,develop scripts directly.(that is what,we don’t do in the chef).