Hacker News new | past | comments | ask | show | jobs | submit login
Infrastructure automation by example (practicingruby.com)
52 points by adamnemecek on Sept 28, 2014 | hide | past | favorite | 15 comments



The article does a great job of exampling chef here, but if you want to play around with it, I highly recommend checking out Vagrant too. Vagrant is an absolutely awesome way to play around with configuration management solutions via the provisioners mechanism [1]. You can easily test and learn puppet/chef/ansible/cfengine/docker/salt/etc. I've done a screencast on Vagrant [2], Learning puppet with Vagrant [3], but you could easily apply this to Chef too.

[1] https://docs.vagrantup.com/v2/provisioning/index.html

[2] https://sysadmincasts.com/episodes/4-vagrant

[3] https://sysadmincasts.com/episodes/8-learning-puppet-with-va...


This is a good start but where Chef ends up sucking a bit is when you want to deploy a bunch of different apps in a SOA type of arrangement and don't want to duplicate code. I.e to deploy another ruby app you have to basically copy and paste this cookbook or you can try to switch to the 'application' cookbook which is chock full of magic and wonder and doesn't really look like any other chef code.

Chef really needs some dependency injection type stuff like what juju has going on. So something can provide a 'load balancer' and your app can optionally use a 'load balancer' but your app doesn't need to hardcode that it's using nginx, or ha proxy, or elb, or whatever in it's cookbook.


If you have a very similar apps, write a "library" cookbook that does the work that's common to deploying those apps. Any values that differ across the apps should be set by attributes. Next write "wrapper" cookbooks for each app that set those attributes and include the "library" cookbook.

A popular blog post on the topic is http://devopsanywhere.blogspot.com/2012/11/how-to-write-reus...


The configuration management landscape is full of good ideas but there are too many of them and most of them end up being the equivalent of C++ for infrastructure automation. You can do anything and everything in 10 different ways that are all equally complex. Chef for example has 9+ levels of attribute overrides ranging from X different cookbook attributes to Y different role attributes. I ask why are there so many override levels and there is no good answer because I've never needed more than 3 levels of attribute overrides. There's more but the override levels on their own are already enough headache. Then there are the ones that use a custom configuration language. I enjoy writing and using DSLs as much as the next guy but the whole point of DSLs is to keep them away from the Turing completeness threshold. As soon as you cross it there is no point in having one. All of the tools commit this sin except for Chef which just embeds the DSL in Ruby.

There is also the fact that none of these tools actually address cloud provisioning. They all work really well once you have your entire topology mapped out but do nothing to actually help with building that topology. That's why I'm hoping Terra takes over because it addresses this aspect of configuration management and I rather use something from Hashicorp than some other vendor.


Saltstack (http://docs.saltstack.com) and the included salt-cloud handle cloud provisioning rather well.


What are all the cloud resource types that salt can provision? All I can find are computer instances and volumes, which is not nearly enough to meet my needs. When bring up a new application on AWS, off the top of my head I need to create an autoscaling group, launch config, load balancer, cloudwatch alarms, dns entries, and ec2 instances.


Look at the boto_* modules here: http://docs.saltstack.com/en/latest/salt-modindex.html#cap-m


That's more promising! Thanks for the pointer. At present the list contains

    salt.modules.boto_asg	
    salt.modules.boto_cloudwatch	
    salt.modules.boto_elasticache	
    salt.modules.boto_elb	
    salt.modules.boto_iam	
    salt.modules.boto_route53	
    salt.modules.boto_secgroup	
    salt.modules.boto_sqs


Ya, it looks like Saltstack has a pretty good handle on it just going from the docs.


Chef also has provisioning, which should get St exactly what you want for all the major providers.


AFAIK chef only handles compute resources, e.g. it can set up EC2 instances but not volumes, IPs, load balancers, autoscaling groups, etc.

[0] https://docs.getchef.com/plugin_knife_ec2.html


A couple nitpicks:

It looks like their bash snippet for generating a certificate can be replaced with the `openssl_x509` resource from this openssl cookbook [0].

I'm surprised running `gem update --system` is working without specifying the path [1].

[0] https://github.com/opscode-cookbooks/openssl

[1] https://docs.getchef.com/resource_bash.html#attributes


Hey, I'm the one who developed the cookbook.

The openssl_x509 resource looks interesting. I'm going to take a look at it. Thanks for the link!

The bash resource works because it uses the system path by default. We actually no longer use that code, but rather install Ruby PPA packages now:

https://github.com/elm-city-craftworks/practicing-ruby-cookb...

-Mathias


Hi, I'm the guy who runs Practicing Ruby. :-)

Thanks for the feedback, I've emailed Mathias to let him know about your suggestions.

Bug reports, suggestions for improvements, and pull requests related to the cookbook can also be filed directly here: https://github.com/elm-city-craftworks/practicing-ruby-cookb...

Since we've been seeing a lot of traffic from this article, I'd be happy to also answer questions here that HN folks might have about how Practicing Ruby works!


I'm the one who co-authored that article with Gregory Brown (@sandal) and wrote the Chef cookbook.

Since the project was great in so many ways, I also shared some additional content on my personal blog today:

http://mlafeldt.github.io/blog/infrastructure-automation-by-...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: