Posts categorized “configuration management”
A question that often comes up is "why should I use config management when I can just use images?" In this article, we’ll explore the differences between images and configuration management, and talk about the benefits and drawbacks of each.
It goes without saying that booting and configuring a server manually every time you need one gets old fast. Thankfully there are a number of tools to help with orchestration and automation available to you.
To list a few you can:
- create a 'golden image' of a server's desired state.
- learn and setup Chef/Puppet/Salt Stack to manage your infrastructure.
- use Rackspace's Cloud Deployments to spin up an environment.
This is a guest post written by Michael DeHaan, CTO at AnsibleWorks. AnsibleWorks provides IT orchestration solutions that simplify the way IT manages systems, applications, and infrastructure.
A while back I wrote about Ansible as a way to simply automate IT infrastructure, and showed how to achieve some interesting zero-downtime rolling update capabilities.
If you are a frequent reader of this blog you will have seen Hart's posts about "Cooking with Chef":
- Part one: Introduction to Chef
- Part two: Cookbooks and Deploying with Knife
- Part three: Installing your own Open Source Chef
Further to these there are also a lot of tutorials on the internet. Most of them seem to focus on using chef to deploy/manage Linux servers but you will have a hard time to find a lot for doing the same on Windows Servers (Yes, Windows as in Microsoft Windows).
I have therefore sat down and put together a detailed step-by-step walkthrough that will guide you through installing your own Open Source Chef Server on a Rackspace Cloud Server running CentOS 6.4, installing the knife-windows plugin and then spinning up, bootstrapping and installing IIS on a Windows Server 2012 Rackspace Cloud Server without logging on to it once. Read on, if you dare...
Several months before I joined Rackspace last year, there were efforts under way to provide an Autoscaling solution for Rackspace customers. Features that we needed in OpenStack and Heat hadn't been released yet, and there were no OpenStack experts on the Autoscaling team. As such, the engineers began developing a product that met Rackspace customer needs, integrated with the existing monitoring and load-balancing infrastructure, and made calls to OpenStack Nova APIs as part of the scaling up and down process.
I was once debugging a deployment issue where one server wouldn't send outgoing email, even though it was running the same version of our application software as other machines that were functioning just fine. After a while I traced it down to the fact that four years ago a developer had stuck an extra mail JAR file into the Tomcat
lib/ directory. This incident showed me that every server performing a function should be exactly the same as every other server performing that function.
This is the third post in a series on Chef:
In those posts I used Opscode's Hosted Chef platform. There are three options for running the Chef Server:
- Hosted Chef: Hosted Chef is a version of a Chef server that is hosted by Opscode. Hosted Chef is cloud-based, scalable and available (24x7x365), with resource-based access control. Hosted Chef has all of the automation capabilities of Chef, but without requiring it to be set up and managed from behind the firewall.
- Private Chef: Private Chef is a version of a Chef server that is designed to provide all of the infrastructure automation capabilities of Chef and is set up and managed from within the organization.
- Open Source Chef: Open Source Chef is an open source version of the Chef server that contains much of the same functionality as Hosted Chef, but requires that each instance be configured and managed locally, including performing data migrations, applying updates to the Open Source Chef server and ensuring that the Open Source Chef server scales as the local infrastructure it is supporting grows. Open Source Chef includes support from the Chef community, but does not include support directly from Opscode.
This post focuses on installing your own Open Source Chef.
Continuing the series on Chef that I started in part one, you should now have an account with Opscode and a working knife install. In this post, I will explain how cookbooks and roles work and we will deploy our first application with Chef.
As I said in a prior post on Puppet, many of our customers use configuration management packages to manage their cloud infrastructure. These packages include Opscode’s Chef, CFEngine, Red Hat’s Spacewalk, and Puppet Labs’ Puppet. Here, I’ll dive into Chef to show you how easy it is to manage Cloud Servers using a configuration management solution. In this series I'll walk you through setting up Hosted Chef using Opscode's platform, deploying your first application to Rackspace with Chef, and more.