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.

DevOps is an important component for software industry today. Developing and implementing a DevOps culture helps to focus IT results and to save time and money as the gap between developers and IT operations teams closes. Just as the term and culture are new, so are many of the best DevOps tools these DevOps engineers use to do their jobs efficiently and productively. To help you in your DevOps process, we have searched and created this list of DevOps tools which is mostly used by DevOps Engineers in their projects.
 
1. Chef



 
Chef is an extremely popular tool among DevOps engineers. From IT automation to configuration management, Chef relies on recipes and resources so you can manage unique configurations and feel secure knowing Chef is checking your nodes and bringing them up to date for you.
 
Key Features:
  • Manage nodes from a single server
  • Cross-platform management for Linux, Windows, Mac OS, and more
  • Integrates with major cloud providers
  • Premium features available
 
2. Jenkins




 
An extensible continuous integration engine, Jenkins is a top tool for DevOps engineers who want to monitor executions of repeated jobs. With Jenkins, DevOps engineers have an easier time integrating changes to projects and have access to outputs to easily notice when something goes wrong.
 
Key Features:
  • Permanent links
  • RSS/email/IM integration
  • After-the-fact tagging
  • JUnit/TestNG test reporting
  • Distributed builds
 
3. Puppet



Puppet is an open-source configuration management tool. It runs on many Unix-like systems as well as on Microsoft Windows, and includes its own declarative language to describe system configuration. DevOps engineers often rely on Puppet for IT automation. Get a handle on configuration management and software while making rapid, repeatable changes with Puppet.
 
Key Features:
  • Automatically enforce consistency of environments
  • Works across physical and virtual machines
  • A common tool-chain
  • Support key DevOps best practices, including continuous delivery
 
4. Ant






A Java library and command-line tool, Apache Ant looks “to drive processes described in build files as targets and extension points dependent upon each other.” This build automation tool is one that saves DevOps engineers a great deal of time.
 
Key Features:
  • Supplies a number of built-in tasks for compiling, assembling, testing, and running Java applications
  • Builds non-Java applications, such as C or C++ applications
  • Pilot any type of process which can be described in terms of targets and tasks
  • Extremely flexible and does not impose coding conventions or directory layouts to the Java projects which adopt it as a build tool
 
5. Apache Maven


 
DevOps engineers can manage a project’s build, reporting, and documentation from a central piece of information with Apache Maven. A software project management and comprehension tool, Maven has been a reliable tool for DevOps engineers.
 
Key Features:
  • Simple project setup follows best practices
  • Easily work with multiple projects at one time
  • Large repository of libraries and metadata that continue to grow
  • Extensible, with the ability to write plugins in Java or scripting languages
 
6. Logstash


For open source log processing, search, and analytics, Logstash is a popular tool among DevOps engineers. Because Logstash is licensed under Apache 2.0, you can use it in the way that best suits your needs.
 
Key Features:
  • Collects, parses, and stores logs for later use
  • Includes a web interface for searching and drilling into all of your logs
  • Ship logs from any source, parse them, timestamp them correctly, index them, and search them
 
7. Docker




 
An open platform for distributed applications, Docker is an application for DevOps engineers who want to “build, ship, and run any app, anywhere.” With Docker, you can quickly assemble apps from components and work collaboratively.
 
Key Features:
  • Assemble multi-container apps and run on any infrastructure
  • Compose an app using both proprietary containers and Docker Hub Official Repos
  • Manage all containers of an app as a single group
  • Cluster an app’s containers to optimize resources and provide high-availability
 
8. New Relic



With New Relic APM, DevOps engineers spend less time monitoring applications and more time on building and deploying. A popular, reliable tool, New Relic APM is a great choice for DevOps engineers.
 
Key Features:
  • Helps in the build, deployment, and maintenance of web software
  • Application monitoring in one place
  • Cross application and transaction tracing
  • Database and availability and error monitoring
 
9. Gradle




Gradle is a robust tool for automating building, testing, publishing, and deploying software packages and other projects. With the combined power and flexibility of Ant and Maven, Gradle is an open source build automation system which is perfect and very useful for DevOps engineers.
 
Key Features:
  • Declarative builds and build-by-convention
  • Language for dependency-based programming
  • Structure your build
  • Deep API
  • Multi-project builds
  • Ease of migration
 
10. Git 




Git is a mature, actively maintained open source project originally developed in 2005 by Linus Torvalds, the famous creator of the Linux operating system kernel. Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
 
Key Features:
  • Working offline
  • Fast to Work With
  • Repositories Are Smaller
  • Moving or Adding files
  • Ignore Certain Files
  • Branches
  • Check the Status of Your Changes
  • Stash Branches
  • Cherry Pick Changes from Branches
  • Find version that Introduced a bug using Binary Search
 
These are the most popular DevOps tools which are used by DevOps engineers or practitioners these days. But to make most out of these tools you need to have proper knowledge of these tools like installation process, implementation process, where to you use, how to use, troubleshooting and much more. So, if you think you need help or training for these tools or for DevOps related helps than we are here to assist you with our industry expertise professionals.
 
Download the VM(Zip File here)
https://pe-education-vms.s3.amazonaws.com/learning/learning_puppet_vm.zip

Minimum requirements

  • Internet-enabled Windows, OS X, or Linux computer with 10GB free space and a VT-x/AMD-V enabled processor.
  • Up to date virtualization software. See the setup instructions below for details.

Setting up the Learning VM

  1. Before beginning, you may want to use the MD5 sum provided at the VM download page to verify your download. On Mac OS X and *nix systems, you can use the command md5 learning_puppet_vm.zip and compare the output to the text contents of thelearning_puppet_vm.zip.md5 file provided on the download page. On Windows systems, you will need to download and use a tool such as the Microsoft File Checksum Integrity Verifier.

  2. Get an up-to-date version of your virtualization software. We suggest using either VirtualBox or a VMware application appropriate for your platform. VirtualBox is free and available for Linux, OS X, and Windows. VMware has several desktop virtualization applications, including VMWare Fusion for Mac and VMware Workstation for Windows.

  3. The Learning VM's Open Virtualization Archive format must be imported rather than opened directly. Launch your virtualization software and find an option for Import or Import Appliance. (This will usually be in a File menu. If you cannot locate an Import option, please refer to your virtualization software's documentation.)

  4. Before starting the VM for the first time, you will need to adjust its settings. We recommend allocating 4GB of memory for the best performance. If you don't have enough memory on your host machine, you may leave the allocation at 3GB or lower it to 2GB, though you may encounter stability and performance issues. Set the Network Adapter to Bridged. Use an Autodetect setting if available, or accept the default Network Adapter name. (If you started the VM before making these changes, you may need to restart the VM before the settings will be applied correctly.) If you are unable to use a bridged network, we suggest using the port-forwarding instructions provided in the troubleshooting guide.

  5. Start the VM. When it is started, make a note of the IP address and password displayed on the splash page. Rather than logging in directly, we highly recommend using SSH. On OS X, you can use the default Terminal application or a third-party application like iTerm. For Windows, we suggest the free SSH client PuTTY. Connect to the Learning VM with the login root and password you noted from the splash page. (e.g. ssh root@<IPADDRESS>) Be aware that it might take several minutes for the services in the PE stack to fully start after the VM boots. Once you're connected to the VM, we suggest updating the clock with ntpdate pool.ntp.org.

  6. You can access this Quest Guide via a webserver running on the Learning VM itself. Open a web broswer on your host and enter the Learning VM's IP address in the address bar. (Be sure to use http://<ADDRESS> for the Quest Guide, as https://<ADDRESS> will take you to the PE console.


Troubleshooting

For the most up-to-date version of this troubleshooting information, check the GitHub repository. If nothing here resolves your issue, feel free to email us at This email address is being protected from spambots. You need JavaScript enabled to view it. and we'll do our best to address your issue.

For issues with Puppet Enterprise that are not specific to the Learning VM, see the Puppet Enterprise Known Issues page.

The cowsay package won't install

The Learning VM version 2.29 has an error in the instructions for this quest. The cowsay package declaration should includeprovider => 'gem', rather than ensure => 'gem'.

If you continue to get puppet run failures related to the gem, you can install the cached version manually: gem install /var/cache/rubygems/gems/cowsay-0.2.0.gem

I completed a task, but the quest tool doesn't show it as complete

The quest tool uses a series of Serverspec tests for each quest to track task progress. Certain tasks simply check your bash history for an entered command. In some cases, the /root/.bash_history won't be properly initialized, causing these tests to fail. Exiting the VM and logging in again will fix this issue.

It is also possible that we have written the test for a task in a way that is too restrictive and doesn't correctly capture a valid syntactical variation in your Puppet code or another relevant file. You can check the specific matchers by looking at a quest's spec file in the ~/.testing/spec/localhost/ directory. If you find an issue here, please let us know by sending an email toThis email address is being protected from spambots. You need JavaScript enabled to view it..

Password Required for the Quest Guide

The Learning VM's Quest Guide is accessible at http://<VM's IP Address>. Note that this is http and not https which is reserved for the PE console. The PE console will prompt you for a password, while no password is required for the Quest Guide. (The Quest Guide includes a password for the PE console in the Power of Puppet quest: admin/puppetlabs)

I can't find the VM password

The password to log in to the VM is generated randomly and will be displayed on the splash page displayed on the terminal of your virtualization software when you start the VM.

If you are already logged in via your virtualization software's terminal, you can use the following command to view the password: cat /var/local/password.

Does the Learning VM work on vSphere, ESXi, etc.?

Possibly, but we don't currently have the resources to test or support the Learning VM on these platforms.

My puppet run fails and/or I cannot connect to the PE console

It may take some time after the VM is started before all the Puppet services are fully started. If you recently started or restarted the VM, please wait a few minutes and try to access the console or trigger your puppet run again.

Also, because the Learning VM's puppet services are configured to run in an environment with restricted resources, they are more prone to crashes than a default installation with dedicated resources.

You can check the status of puppet services with the following command:

systemctl --all | grep pe-

If you notice any stopped puppet-related services (e.g. pe-puppetdb), double check that you have sufficient memory allocated to the VM and available on your host before you try starting them (e.g. service pe-puppetdb start).

If you get an error along the lines of Error 400 on SERVER: Unknown function union... it is likely because the puppetlabs-stdlib module has not been installed. This module is a dependency for many modules, and provides a set of common functions. If you are running the Learning VM offline, you cannot rely on the Puppet Forge's dependency resolution. We have this module and all other modules required for the Learning VM cached, with instructions to install them in the Power of Puppet quest. If that installation fails, you may try adding the --force flag after the --ignore-dependencies flag.

I can't import the OVA

First, ensure that you have an up-to-date version of your virtualization software installed. Note that the "check for updates" feature of VirtualBox may not always work as expected, so check the website for the most recent version.

The Learning VM has no IP address or the IP address will not respond.

If your network connection has changed since you loaded the VM, it's possible that your IP address is different from that displayed on the Learning VM splash screen. Log in to the VM via the virtualization directly (rather than SSH) and use thefacter ipaddress command the check the current address.

Some network configurations may still prevent you from accessing the Learning VM. If this is the case, you can still access the Learning VM by configuring port forwarding.

Change your VM's network adapter to NAT, and configure port forwarding as follows:

Name   -   Protocol - HostIP -   HostPort - GuestIP - GuestPort
SSH        TCP        127.0.0.1  2222                 22
HTTP       TCP        127.0.0.1  8080                 80
HTTPS      TCP        127.0.0.1  8443                 443
GRAPHITE   TCP        127.0.0.1  8090                 90

Once you have set up port forwarding, you can use those ports to access the VM via ssh (ssh -p 2222 root@localhost) and access the Quest Guide and PE console by entering http://localhost:8080 and https://localhost:8443 in your browser address bar.

I can't scroll up in my terminal

The Learning VM uses a tool called tmux to allow us to display the quest status. You can scroll in tmux by first hitting control-b, then [ (left bracket). You will then be able to use the arrow keys to scroll. Press q to exit scrolling.

Running the VM in VirtualBox, I encounter a series of "Rejecting I/O input from offline devices"

Reduce the VM's processors to 1 and disable the "I/O APIC" option in the system section of the settings menu.

Still need help?

If your puppet runs still fail after trying the steps above, feel free to contact us at This email address is being protected from spambots. You need JavaScript enabled to view it. or check the Puppet Enterprise Known Issues page.

Page 1 of 2