LOGIN
Sign In or Register
Avatar
Not Registered Yet?

Join Now! It's FREE. Get full access and benefit from this site

Reset My password - Remind Me My username

Username
Password
Remember me

Source - http://hub.scalr.com/blog/top-questions-on-server-configuration-management-tools-chef-puppet-and-ansible-2

As a quick recap, configuration management tools enable companies to standardize and automate their infrastructure. Through standardization, you can build systems that are platform independent (i.e. instead of relying on AMIs or provider specific toolsets). These tools also make it easy reproduce servers for scaling or testing, and recover from disaster quickly by defining a proper application state. For example, if servers are not in that defined state when each server is checked, they are restored to their proper state. In addition, this standardization makes it easy to onboard new developers.

 

While the language across configuration management tools is different, the concepts are the same. At the fundamental level in each configuration tool, a resource represents a part of the system and its desired state, such as a package that should be installed, a service that should be running, or a file that should be generated.

In Chef, a recipe is a collection of resources that describes a particular configuration or policy. These collections are called playbooks in Ansible, and manifests in Puppet. These collections describe everything that is required to configure part of a system. Collections install and configure software components, manage files, deploy applications, and execute other recipes. We go into more detail in our blog post here.

 

Here are the top questions we got from the community:

 

How is the concept of master/agent configuration better (or not) than agentless, when it comes to infrastructure as code?

Chef and Puppet are master/agent configuration systems, while Ansible is an agentless system. The historic argument is that the agent-based installation process is difficult -  you have to set up the master, and then set up the agents on your nodes so that they know about the master. If you’ve got servers with diverse linux distros, on different versions of Windows, etc., installation can get tricky. Though, because they’re logging every few minutes, agent-based systems are powerful for advanced monitoring. At the end of the day this really is based on personal preference and what company requires. If your infrastructure is beefy and heavily standardized, installation on nodes isn’t complicated so use agent-based systems. If you have servers that run Python, try agentless.

 

Are these configuration management systems like MicroSoft System Center Configuration Manager (SCCM) but used for local and cloud?

This is like MS SCCM, but open-source and paid for per node. For those who haven’t used it, MicroSoft System Center Configuration Manager (SCCM) is used for infrastructure provisioning, monitoring, and automating workflow processes (usually sysadmin stuff). SCCM is a powerhouse in the enterprise space. While it can manage end clients on non-Windows servers, the server console portion of SCCM must be hosted and run on a Windows server machine. The reason other orchestration/configuration systems win here is that you pay on a per-node basis and you’re not totally tied into Windows Server’s licensing agreements. In other words, open-source vs proprietary. And with Chef/Puppet/Ansible the thinking is more in resources as opposed to SCCM, which is more in files and terminal commands.

 

An attendee commented on using SCCM:

 We really like Ansible because of the none-agent requirement. For Windows patching we utilize System Center Configuration Manager, and even though System Center can provide patching to Linux we have run into issues with SCCM agent staying healthy and running on our Linux systems. We have also run into when the SCCM admins have made changes it broke SCCM agent on a majority of our Linux servers. Our Linux patching process has been highly manual up to this point but we are seeking to automate this to free up staff time to be better directed at other support tasks, which is why were are reviewing several solutions. The non-agent aspect is highly desirable in our situation because of past experience with SCCM agent. I just wanted to provide that feedback so others that have not experienced agent issues with other deployment solutions may want to keep that in mind.”

 

If we have to pick a tool dependent on whether we deploy on cloud or on-premise - which of these tools would be a better choice?

We would recommend looking into network access requirements for each tool. If you have an agent that checks in periodically with a central master management piece, that is likely to work better then SSH which requires direct path / path through lots of proxies. 

 

One attendee mentioned in the comments: "[In regards to] SSH vs Agent - Agent is more secure where SSH not an option.

 

What happened to cfengine? This tool used to be mentioned alongside Chef and Puppet. 
Version 3 of cfengine is a complete revamp, but it compared to other configuration management tools the brand and community outreach isn’t strong, and does little the others don't do better.

How does StackStorm compare to the other orchestrators being reviewed?
StackStorm labels itself more of an automation platform, or a DevOps workflow tool that handles provisioning and configuring servers but also leans on automatic and event driven services that plugs into Jenkins and other CI/CD workflows.

 

From one attendee that had used all three: “For us, getting the Server engineers to adopt Chef has been very difficult. It grew organically on the Dev side of the house. Ansible appears to be something that guys without Dev skills could pick up more easily. Just [my] perception.”

 

Can I run tasks in parallel with Ansible rather than running it serially (say 50 servers being updated with a patch)?

The default method is to run each task across all servers in parallel, meaning that it will run the first task (e.g. installing Git) on all servers in a group, and once all servers respond with a success, failure, or unchanged response, Ansible will move to the next task on all servers. It doesn’t run on a server, wait, move on to the next, it will run on all servers at once over SSH. If you want to deploy updates in batches, you can run a percentage of servers in a group (e.g. 50%, by listing it in the playbook as serial: 50%).

 

An attendee made this comment as we mentioned Ansible:

 

I have attended a presentation from RedHat regarding Ansible that states [that Ansible scales well]. They have large scale hosting companies that on the fly spin up servers and perform patching for their servers via Ansible. The one mentioned had over 50,000 servers and it seemed to handle the volume / scale fine. I of course don’t know everything about Puppet or Chef or Salt, but one thing I find really nice about Ansible is the ability to perform rolling updates / tasks. So if you say had 1000 servers you can say you want to run 10% or 100 at a time and keep it rolling until all 1000 are done. It can be stated by percentage or defined number...I am sure I sound a bit biased but one of the main reasons Ansible is high on our list right now is the fact that it is agentless and does not really consume resources.”

 

With Ansible, how can we handle the security implications about allowing passwordless ssh to a root account on all systems? What mechanisms are there for access control and auditing?

There are definitely security implications if you are going to allow passwordless ssh. So it’s on the company to ensure that security groups or NSGs are well defined. We should also mention that the passwordless ssh is only enabled on the machine you are running Ansible commands and playbooks from, so if anything consider that workstation to be your weak point. Make sure SSH access is only permissible through your IP. As an alternative solution to connecting via SSH, if you use docker, Ansible allows you to deploy playbooks directly into Docker containers using the local Docker client. All you need is a user inside that container.

 

Does ansible run single-threaded or is it addressing multiple servers in a group asynchronously?
Ansible runs on each host in parallel. This means that it attempts to run your tasks on all servers defined at the top of the playbook before moving on to the next task.

 

One user said in regards to all three tools: “Ansible seems better for "orchestration" and Puppet/Chef are really good for "Configuration Management".  Ansible can be used to stop applications and databases and then run Puppet and then start applications and databases.

 

Lastly, we got a surprise question from the audience on Jenkins, a CI/CD pipeline tool that can be used in conjunction with tools like Chef to completely automate the infrastructure behind your applications.

 

What is the alternative of Jenkins?
While we recommend Jenkins, If you’re a Ruby shop, Capistrano is geared towards your deployments. If you live in the AWS world, you can try using the CodeCommit/CodeDeploy/CodePipeline toolset. If you’re looking for a provider agnostic solution, CircleCI is great. If your workflows revolve around Atlassian, try Bamboo. 

 

If you are unsure of what CI/CD pipeline tool to use, or how they work, we will be hosting a webinar on Jenkins as part of our on-going series on infrastructure-as-code.

  1. Write a cookbook using you can install apache http server in CentOs and Ubuntu, enable the services and start the service.

  2. Write a recipe using template resources to create a file, but only if an attribute has a specific value.

  3. Write a recipe to create a file using a string, but not if “/etc/passwd” exists?

  4. Write a cookbook to unzip a file, and then move a files from one location to another using batch, bash chef resources?

  5. Create a role and assign any two cookbooks to role and setup a 2 nodes assigned to role and conerse the role.

  6. Write a cookbook using install version of latest tomcat and deploy jenkins.war files into war.

  7. Write a 4 cookbooks php, mysql, apache and webapp respectively and map a dependency between them and install a sample web application.

  8. Write a cookbook to install git, wget, zip in RHEL and Ubuntu.

  9. Write a cookbook in which create a file using a string, but only if “/etc/passwd” exists

  10. Write a coobook to run a batch file that unzips and then moves files from one location to another.

 

Source - learn.chef.io

What is a resource?
Answer- A resource represents a piece of infrastructure and its desired state, such as a package that should be installed, a service that should be running, or a file that should be generated.

Question: What is a recipe?
Answer- A recipe is a collection of resources that describes a particular configuration or policy. A recipe describes everything that is required to configure part of a system. Recipes do things such as:

install and configure software components.
manage files.
deploy applications.
execute other recipes.

Question: What happens when you don't specify a resource's action?
Answer- When you don't specify a resource's action, Chef applies the default action.

Question: Are these two recipes the same?

package 'httpd'
service 'httpd' do
   action [:enable, :start]
 end

&&

service 'httpd' do
   action [:enable, :start]
   end
package 'httpd'

Answer-
No, they are not. Remember that Chef applies resources in the order they appear. So the first recipe ensures that the httpd package is installed and then configures the service. The second recipe configures the service and then ensures the package is installed.

Question: The second recipe may not work as you'd expect because the service resource will fail if the package is not yet installed.

Are these two recipes the same?

package 'httpd'
service 'httpd' do
   action [:enable, :start]
   end
package 'httpd'
service 'httpd' do
   action [:start, :enable]
   end

Answer-
No, they are not. Although both recipes ensure that the httpd package is installed before configuring its service, the first recipe enables the service when the system boots and then starts it. The second recipe starts the service and then enables it to start on reboot.

Are these two recipes the same?

file '/etc/motd' do
owner 'root'
group 'root'
mode '0755'
action :create
end

file '/etc/motd' do
action :create
mode '0755'
group 'root'
owner 'root'
end

Answer-
Yes, they are! Order matters with a lot of things in Chef, but you can order resource attributes any way you want.

Question -
Write a service resource that stops and then disables the httpd service from starting when the system boots.

Answer -
service 'httpd' do
action [:stop, :disable]
end

How does a cookbook differ from a recipe?
A recipe is a collection of resources, and typically configures a software package or some piece of infrastructure. A cookbook groups together recipes and other information in a way that is more manageable than having just recipes alone.

For example, in this lesson you used a template resource to manage your HTML home page from an external file. The recipe stated the configuration policy for your web site, and the template file contained the data. You used a cookbook to package both parts up into a single unit that you can later deploy.

How does chef-apply differ from chef-client?

chef-apply applies a single recipe; chef-client applies a cookbook.

For learning purposes, we had you start off with chef-apply because it helps you understand the basics quickly. In practice, chef-apply is useful when you want to quickly test something out. But for production purposes, you typically run chef-client to apply one or more cookbooks.

You'll learn in the next module how to run chef-client remotely from your workstation.

What's the run-list?

The run-list lets you specify which recipes to run, and the order in which to run them. The run-list is important for when you have multiple cookbooks, and the order in which they run matters.

What are the two ways to set up a Chef server?

Install an instance on your own infrastructure.
Use hosted Chef.

What's the role of the Starter Kit?
The Starter Kit provides certificates and other files that enable you to securely communicate with the Chef server.

Where can you get reusable cookbooks that are written and maintained by the Chef community?
Chef Supermarket, https://supermarket.chef.io.

What's the command that enables you to interact with the Chef server?
knife

What is a node?
A node represents a server and is typically a virtual machine, container instance, or physical server – basically any compute resource in your infrastructure that's managed by Chef.

What information do you need to in order to bootstrap?
You need:

your node's host name or public IP address.
a user name and password you can log on to your node with.
Alternatively, you can use key-based authentication instead of providing a user name and password.

What happens during the bootstrap process?
During the bootstrap process, the node downloads and installs chef-client, registers itself with the Chef server, and does an initial checkin. During this checkin, the node applies any cookbooks that are part of its run-list.

Which of the following lets you verify that your node has successfully bootstrapped?

The Chef management console.
knife node list
knife node show
You can use all three of these methods.

What is the command you use to upload a cookbook to the Chef server?
knife cookbook upload

How do you apply an updated cookbook to your node?
We mentioned two ways.

Run knife ssh from your workstation.
SSH directly into your server and run chef-client.
You can also run chef-client as a daemon, or service, to check in with the Chef server on a regular interval, say every 15 or 30 minutes.

Update your Apache cookbook to display your node's host name, platform, total installed memory, and number of CPUs in addition to its FQDN on the home page.

Update index.html.erb like this.
<html>
<body>
<h1>hello from <%= node['fqdn'] %></h1>

<pre>
<%= node['hostname'] %>
<%= node['platform'] %> - <%= node['platform_version'] %>
<%= node['memory']['total'] %> RAM
<%= node['cpu']['total'] %> CPUs
</pre>
</body>
</html>

Then upload your cookbook and run it on your node.

What would you set your cookbook's version to once it's ready to use in production?

According to Semantic Versioning, you should set your cookbook's version number to 1.0.0 at the point it's ready to use in production.

What is the latest version of the haproxy community cookbook?

To know the latest version of any cookbook on Chef Supermarket, browse to its page and view the latest version from the version selection box.

Or, get the info from the knife cookbook site command, like this.

knife cookbook site show haproxy | grep latest_version
latest_version: http://cookbooks.opscode.com/api/v1/cookbooks/haproxy/versions/1.6.6

Create a second node and apply the awesome_customers cookbook to it. How long does it take?

You already accomplished the majority of the tasks that you need. You wrote the awesome_customers cookbook, uploaded it and its dependent cookbooks to the Chef server, applied the awesome_customers cookbook to your node, and verified that everything's working.

All you need to do now is:

Bring up a second Red Hat Enterprise Linux or CentOS node.
Copy your secret key file to your second node.
Bootstrap your node the same way as before. Because you include the awesome_customers cookbook in your run-list, your node will apply that cookbook during the bootstrap process.
The result is a second node that's configured identically to the first one. The process should take far less time because you already did most of the work.

Now when you fix an issue or add a new feature, you'll be able to deploy and verify your update much more quickly!

What's the value of local development using Test Kitchen?

Local development with Test Kitchen:

enables you to use a variety of virtualization providers that create virtual machine or container instances locally on your workstation or in the cloud.
enables you to run your cookbooks on servers that resemble those that you use in production.
speeds up the development cycle by automatically provisioning and tearing down temporary instances, resolving cookbook dependencies, and applying your cookbooks to your instances.

What is VirtualBox? What is Vagrant?

VirtualBox is the software that manages your virtual machine instances.

Vagrant helps Test Kitchen communicate with VirtualBox and configures things like available memory and network settings.

Verify that your motd cookbook runs on both CentOS 6.6 and CentOS 6.5.

Your motd cookbook is already configured to work on CentOS 6.6 as well as CentOS 6.5, so you don't need to modify it.

To run it on CentOS 6.5, add an entry to the platforms section of your .kitchen.yml file like this.

---
      driver:
      name: vagrant
provisioner:
      name: chef_zero
platforms:
      - name: centos-6.6
      driver:
      box: opscode-centos-6.6
      box_url: http://opscode-vm-bento.s3.amazonaws.com/vagrant/virtualbox/opscode_centos-6.6_chef-provisionerless.box
      - name: centos-6.5
      driver:
      box: opscode-centos-6.5
      box_url: http://opscode-vm-bento.s3.amazonaws.com/vagrant/virtualbox/opscode_centos-6.5_chef-provisionerless.box
suites:
      - name: default
      run_list:
      - recipe[motd::default]
      attributes:

In many cases, Test Kitchen can infer the box and box_url parameters, which specify the name and location of the base image, or box. We specify them here to show you how to use them.

Run kitchen list to see the matrix of test instances that are available. Here, we have two platforms – CentOS 6.5 and CentOS 6.6 – multiplied by one suite – default.

$kitchen list

Instance           Driver   Provisioner  Verifier  Transport  Last Action
default-centos-66  Vagrant  ChefZero     Busser    Ssh        <Not Created>
default-centos-65  Vagrant  ChefZero     Busser    Ssh        <Not Created>

Run kitchen converge to create the instances and apply the motd cookbook.

$kitchen converge
   -----> Starting Kitchen (v1.4.0)
   -----> Creating <default-centos-66>...
   Bringing machine 'default' up with 'virtualbox' provider...
   [...]
   Running handlers:
   Running handlers complete
   Chef Client finished, 1/1 resources updated in 10.372334751 seconds
   Finished converging <default-centos-66> (3m52.59s).
   -----> Creating <default-centos-65>...
   Bringing machine 'default' up with 'virtualbox' provider...
   [...]
   Running handlers:
   Running handlers complete
   Chef Client finished, 1/1 resources updated in 5.32753132 seconds
   Finished converging <default-centos-65> (10m12.63s).
 -----> Kitchen is finished. (19m47.71s)

Now to confirm that everything's working, run kitchen login. But this time, you need to provide the instance name so that Test Kitchen knows which instance to connect to.

$kitchen login default-centos-66
      Last login: Wed May 13 20:15:00 2015 from 10.0.2.2
      
      hostname:  default-centos-66
      fqdn:      default-centos-66
      memory:    469392kB
      cpu count: 1
      [vagrant@default-centos-66 ~]$ logout
      Connection to 127.0.0.1 closed.$kitchen login default-centos-65
      Last login: Wed May 13 20:28:18 2015 from 10.0.2.2
      
      hostname:  default-centos-65
      fqdn:      default-centos-65
      memory:    469452kB
      cpu count: 1
      [vagrant@default-centos-65 ~]$ logout
      Connection to 127.0.0.1 closed.
Page 1 of 3