Posts categorized “chef”
Chef recently launched Chef Metal, a way to define clusters of machines with
Chef recipes. With Chef Metal's
machine resource, you can keep your entire
server environment under the same version control that holds your configuration
Elasticsearch is a powerful distributed schema-less datastore and its main focus is indexing/search functionality. One benefit of Elasticsearch is simple cluster management via multicast, which is provided out of the box.
Unfortunately, multicast is often blocked by cloud vendors due to security concerns of a mutli-tenancy network (imagine exposing your software to the rest of the cloud via multicast). This is where Rackspace Cloud Networks can help out. One of the primary goals of Cloud Networks is to allow"personal" L2 networks in a mutli-tenancy environment. This means we get multicast!
Understanding the Chef Environment File in Rackspace Private Cloud v4.2.x powered by OpenStack Havana
In a previous post I went through two typical Chef Environment files specific to Rackspace Private Cloud v4.1.x powered by OpenStack Grizzly with nova-network and Quantum Networking. However, with Rackspace Private Cloud v4.2.x powered by OpenStack Havana some things have changed, in particular Quantum has been renamed to Neutron.
In the following post, I am going to break down each part of the Chef Environment file, including the Highly Available pieces, specific to Rackspace Private Cloud 4.2.x powered by OpenStack Havana.
There are few ways to backup a Chef server. Opscode has some documenation on their wiki Backing up Chef Server. Some of this is outdated now because chef no longer uses Couch DB.
However there is this little gem (pun intended) called knife-backup.
Rackspace Private Cloud uses Chef to deploy an OpenStack environment. Chef provides the ability to quickly configure and deploy an OpenStack environment on one to many nodes. An integral part of deployment is the Chef Environment file. This file can be difficult to understand as a newcomer to Chef.
In the following post, I am going to break down each part of two typical Chef Environment files specific to Rackspace Private Cloud v4.1.x powered by OpenStack Grizzly.
A new post covering the Chef Environment file for Rackspace Private Cloud v4.2.x, including the highly available bits, can be found here.
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...
Maintaining hosts files on standard *nix system has been traditionally done by hand. This becomes a challenge as the number of systems grow and this is more true in the Cloud model where you might add/delete servers at a higher rate. One solution would be to use DNS and use a local zone to store your host name to IP mapping. If you are in the automation using Chef world, here is another example on how to automatically generate the host file entries.
In today's Configuration Management landscape the general motto is "infrastructure as code" and as good devopsians we should be testing our code. This blog post takes a look at test-kitchen + OpenStack to make your life of testing chef cookbooks easier, faster and fun.
Recently, Opscode released a case study on Rackspace customer Indiegogo and their use of Chef to power their fundraising efforts. Last year, MTV came to Indiegogo and asked them to power their telethon fundraiser for Hurricane Sandy. Oh, and it had to be ready in FOUR DAYS. Indiegogo used the Opscode Hosted Chef platform and more than 500 Rackspace Cloud Servers to have 100% uptime throughout the entire event.
DevOps and automation are all the rage now a days and Chef is at the forefront. I spent Thursday and Friday of last week at ChefConf in San Francisco and heard some amazing presentations. The presentations were all recorded and are available on YouTube.
I wrote last week about a couple of keynotes that I attended, which you can find here. This post will share some more of the presentations I was able to attend, but also talk about the overall key points that all the speakers referenced.
Windows presents some challenges when it comes to using deployment automation tools. If you’ve used 'knife-rackspace' to create Linux servers on our cloud, you know that the bootstrap process happens automatically. The server is created, a connection is made via SSH, the Chef client is installed, and the server role is assigned… all with a single command. If you spin up a Windows server, knife-rackspace still attempts to bootstrap the server via SSH… and this will obviously fail. So what next? What are your options, and which approach will produce the best results?
Hello from Sunny San Francisco! Today is day 1 of ChefConf, a Devops focused convention. Developers and Engineers come to ChefConf to learn about Opscode's latest features and learn from their peers. Below I'll talk about a few of the sessions I attended today.
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 a guest post from Ryan Richard. Ryan is an OpenStack Engineer for Rackspace Private Cloud and is a Red Hat Certified Architect. He has been at Rackspace for almost 6 years and has been working on OpenStack for one year. His current role involves in designing, deploying and supporting OpenStack based private clouds inside and outside of Rackspace data centers. You can follow him on twitter: @rackninja.
Egle Sigler is a Private Cloud Architect, who started working at Rackspace in 2008. She was one of the first to receive Rackspace OpenStack certification. Before working with OpenStack, Egle worked on MyRackspace customer control panel, software architecture and enterprise tools. In her spare time, Egle enjoys traveling, hiking, snorkeling and nature photography.
No matter how “cloudy” your environment and processes are, at the end of the day they still need to run on physical infrastructure. Traditionally, physical infrastructure is static in nature and time consuming to work with for a number of reasons. When we were building out the next-generation development and testing platform for Rackspace Private Cloud Software, we found ourselves face to face with the issues caused by constantly provisioning infrastructure.
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.