Atomic and ASL Installers and Chef

Highland · **Joined:** Mon Apr 10, 2006 12:55 pm **Posts:** 656

I saw that you guys got the installer working on the Amazon Linux. That was fast! I'm hoping this will be just as fast.

I need a -y option for the atomic installer. We're starting to work on using Chef to configure our EC2 instances. Chef is a scripting language so you can automatically configure your server instances (it makes cloud environment scalability a snap). Sadly, I don't think I can tell Chef to type "yes" so the installer goes ahead. I know, I know, you want your liability limited but the inability to skip this makes my life harder. I haven't even begun to tackle putting ASL into Chef yet either, so if there were some way to pass attributes to the config via CLI arguments that would be helpful as well. Or maybe an automated installer instead?

scott · **Posted:** Mon Oct 31, 2011 8:42 pm

Ok I might have that now, if you set the variable:

export NON_INT=1

and then run the installer, it should bypass the prompt

paulie · **Joined:** Tue Apr 20, 2010 2:49 am **Posts:** 74

Sorry to take this off on a slight tangent but can I ask why you settled on Chef over the other options for configuration management?

The only one I've spent time looking at (and the one I am going to invest time learning) is cfengine. I have read around a lot of the others though and Chef and Puppet seem to be the popular choices but the thought of having to bring in a load of (frankly horrid) Rails packages and non-packages just to make things simpler seems counter-productive to me.

cfengine seems to almost have a negative reputation, but it has minimal depencies and they provide rpm's for Centos.

Anyway, I'm just interested in your thoughts and conclusions (since I'm fickle I could change again!),

Paul

scott · **Posted:** Tue Nov 01, 2011 1:04 pm

puppet appears to be the most en vogue for the enterprise clients

Highland · **Joined:** Mon Apr 10, 2006 12:55 pm **Posts:** 656

A couple of comments

NON_INT did indeed get around the need for a yes/no response. For some reason, however, the installer would simply fail without installing the RPM. Chef creates a strange environment and that may be why. I wound up writing a manual workaround where it grabs the GPG key and the latest atomic-release RPM (hard-coded but they don't change a lot) and that worked. Gonna run with that for now. Here's my script for CentOS5. Hopefully it helps.

Code:

remote_file "#{Chef::Config[:file_cache_path]}/atomic.rpm" do
  source "http://www.atomicorp.com/channels/atomic/centos/5/" + node['repos']['arch'] + "/RPMS/atomic-release-1.0-13.el5.art.noarch.rpm"
  mode "0644"
  not_if "test -f /etc/yum.repos.d/atomic.repo"
end

remote_file "#{Chef::Config[:file_cache_path]}/atomic-gpg.txt" do
   source "https://www.atomicorp.com/RPM-GPG-KEY.art.txt"
   notifies :run, "execute[install_atomic_key]", :immediately
   not_if "test -f /etc/yum.repos.d/atomic.repo"
end

execute "install_atomic_key" do
   command "rpm --import #{Chef::Config[:file_cache_path]}/atomic-gpg.txt"
   not_if "test -f #{Chef::Config[:file_cache_path]}/atomic-gpg.txt"
end

execute "install_atomic_repo" do
   command "rpm -i #{Chef::Config[:file_cache_path]}/atomic.rpm"
   not_if "test -f /etc/yum.repos.d/atomic.repo"
   action :run
end

and the definition of the arch

Code:

if node[:kernel][:machine] == "x86_64"
   default[:repos][:arch] = 'x86_64'
else
   default[:repos][:arch] = 'i386'
end

Kudos for obsoleting the php53 libraries in favor of ART.

Quote:

why you settled on Chef over the other options for configuration management?

We looked at both Chef and Puppet. Puppet is more mature and has a lot more "recipes", examples, etc, but also has its own scripting language. Chef is written with a vanilla Ruby engine which means it's a bit easier to go "off the map" and write your own code. I've not heard of cfengine.
Here's a slightly pro-chef article on the subject
http://devopsanywhere.blogspot.com/2011 ... =pulsenews
One comment that got my attention

Quote:

I don't believe there are many in the Puppet community that have extensively experimented with Chef before choosing Puppet. There are many in the Chef community that have worked previously with Puppet and found that it did not meet their needs.

So far we're actively building and deploying EC2 instances with Chef and it's not bad.

scott · **Posted:** Tue Nov 01, 2011 6:30 pm

Well I don't see any reason not to support both. Thanks for posting the script!

Highland · **Joined:** Mon Apr 10, 2006 12:55 pm **Posts:** 656

I'm trying to reverse engineer the ASL install script and it's a bit confusing because of all the flavors it supports. Is there a list of all the packages and things the installer does? I'm trying to set this up like a normal service (i.e. Apache) and build the config via options set in Chef.

scott · **Posted:** Wed Nov 02, 2011 6:59 pm

Its leveraging the decadency trees that yum & rpm will generate dynamically. It can be different between two nearly identical systems.

paulie · **Joined:** Tue Apr 20, 2010 2:49 am **Posts:** 74

Shirley the script just ends up with the correct repo files in /etc/yum.repos.d?

So once you've got it manually, and since you're deploying to (presumably) identical instances of EC2 images, you can just use chef to copy the config files from the central repository?

Quote:

. It can be different between two nearly identical systems.

But presumably on two identical systems it will be identical.

mikeshinn · **Posted:** Thu Nov 03, 2011 11:45 am

Quote:

But presumably on two identical systems it will be identical.

Probably, because for an ASL installation that depends on the version of ASL being installed at the time and the options selected during installation. So, if you installed the same version and selected the same things at that time they should be the same. With that said, and this is the important part: the installer changes regularly, so what it is doing today is not what it may be doing tomorrow. Reverse engineering it is not going to give you a stable picture of what the installation will require in the future.

So, when installing ASL you should always use the latest installer to install ASL. Don't download it, run the command that downloads the latest installer and pipes that into a shell. It changes that often so we can keep on top of all the control panels, OSes, vendor forks of third party software (or even core software like mysql and PHP), and specific hosters requirements and virtualization technologies.

ASL installations not using the official installer are definitely not supported in any way shape or form for this reason.

Highland · **Joined:** Mon Apr 10, 2006 12:55 pm **Posts:** 656

I'm thinking that I can template out /etc/asl/config, install the files via yum, and then kick off asl -s -f to set the box up based on the config (thank you, Notepad++, and your color coding of shell scripts)

I'm still writing the template but I will update how it's going.

Highland · **Joined:** Mon Apr 10, 2006 12:55 pm **Posts:** 656

mikeshinn wrote:

So, when installing ASL you should always use the latest installer to install ASL. Don't download it, run the command that downloads the latest installer and pipes that into a shell. It changes that often so we can keep on top of all the control panels, OSes, vendor forks of third party software (or even core software like mysql and PHP), and specific hosters requirements and virtualization technologies.

ASL installations not using the official installer are definitely not supported in any way shape or form for this reason.

I would MUCH prefer to use the installer (it's a ton of work trying to get around it) but in its current form it can't be used with automation like Chef, Puppet, etc. What would be awesome is to be able to have the installer do its thing but pass arguments in the CLI call.

Example

Code:

asl -u username -p password -agree yes

paulie · **Joined:** Tue Apr 20, 2010 2:49 am **Posts:** 74

My bad I was thinking entirely of the atomic repo installer having never used the ASL installer, I did think you were overstating what the atomic repo installer does

However if its an interactive script expecting answers to questions in a uniform manner then you could look at wrapping expect around the ASL installer and running the expect script through Chef?

It'd be yet another thing to learn mind (though basic stuff in expect wasn't so bad, and I've never gone beyond really basic stuff).

mikeshinn · **Posted:** Fri Nov 04, 2011 11:48 am

Quote:

I would MUCH prefer to use the installer (it's a ton of work trying to get around it) but in its current form it can't be used with automation like Chef, Puppet, etc. What would be awesome is to be able to have the installer do its thing but pass arguments in the CLI call.

Example
Code:
asl -u username -p password -agree yes

Great idea, could you submit a feature request thru the support portal for this?

Justin · **Joined:** Fri Jul 02, 2010 2:45 pm **Posts:** 9

Hi everyone! I am highland's coworker, and I've been the one setting up Chef and staging our move to EC2.

With the way I'm setting up our servers, I want to use only Chef to manage them so there's not any scripts run on them outside of that that requires any manual input. This really helps lock down the config across environments, along with allowing for very simple deployment, should we need to throw more instances out there. While I realize the installer is the only supported solution for ASL, with Chef I just have more control with less manual involvement.

I created a cookbook for ASL, which can be got from here:

https://github.com/ocg/Chef-Cookbooks/tree/master/asl

I'm still largely a novice when it comes to Ruby and Chef, so take it for what it's worth (as-is, no warranty, and all that good stuff). Basically, everything should work by just changing the first 12 lines of the default attributes, but you may want to change more of the configuration.

The general idea of what this does is:

* Installs Apache2 (this cookbook is required)
* Installs the atomic repository if not installed
* Installs asl-lite or asl (depending on the version specified in the attributes) via package resource (yum)
* Configures ASL then runs either /var/asl/bin/asl -s -f or /var/asl/bin/asl-lite -u if the configuration changed

This should work on most CentOS and RHEL installs.

Atomic and ASL Installers and Chef

Who is online