StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>If by 'cloud' you mean an <strong><em>IaaS</em></strong> <em>(Infrastructure-as-a-Service provider)</em>, such as EC2 etc - as opposed to <em>PaaS</em> (<em>Google App Engine, Heroku, etc</em>), then the trend these days seems to be <a href="http://java.dzone.com/articles/infrastructure-code-key-devops" rel="nofollow">Infrastructure-as-Code</a>, and <a href="http://en.wikipedia.org/wiki/DevOps" rel="nofollow">DevOps</a>. This is not exactly 'zero configuration'; it is more like configure <em>once</em>, and describe the configuration of your stack as whole in a DSL which can be used to build or rebuild your entire stack from nothing but a set of freshly booted VMs running on whatever cloud.</p> <p>So you have a <em>configuration management</em> system, and a bunch of machine-readable 'recipes' that the configuration management system understands. It's usual for the recipes to be expressed in some sort of custom DSL, though there do exist systems where the language is actually XML.</p> <p>Some well-known examples of such <em>configuration management</em> systems include:</p> <ol> <li><a href="http://www.opscode.com/chef/" rel="nofollow">Chef</a></li> <li><a href="http://puppetlabs.com/" rel="nofollow">Puppet</a></li> </ol> <p>There are many others; but I've no experience with them (CFEngine, bcfg2 (uses XML))</p> <p>These tools are <em>idempotent</em>. Which means, you can keep re-running the configuration as many times as you want, and only what needs to be done to meet the description specified by your recipes will be done. If you have specified certain files to be placed in certain directories with certain contents, then they will be created (or modified) only if they need to be. Packages will be installed only if they need to be, or if their version differs from what the recipes specify.</p> <p>For example, in Chef, to specify that a user <code>tomcat</code> must exist, and that a certain version of Java must be installed, and that postfix should be running, and that a certain XML file must be available at a given location, you would have a recipe that looks like:</p> <pre class="lang-rb prettyprint-override"><code>user "tomcat" package "java" do version "1.6.0_u27" end directory "/etc/yourapp" do owner "tomcat" end package "postfix" # Ensure that postfix is installed and running. service "postfix" do action [:enable, :start] end tempate "/etc/yourapp/config.xml" source "config.xml.erb" # This will be a template file that references variables variables( :db_server => '10.1.2.4' #just an example; there will be ways to automate this ) mode "0755" end </code></pre> <p>Chef for one, provides a bunch of pre-written recipes or 'cookbooks' that you simply download, include and use as part of your infrastructure. In Chef, you write your cookbooks based on what you want the servers to be - then you define <em>roles</em>, which specify what cookbooks will be applied to what class of servers that make up your stack. You simply assign roles to your instances, boot them, and watch the entire stack bring itself up.</p> <p>I'd say that this is becoming the standard method of maintaining full-stack executable descriptions of infrastructure (doesn't have to be just cloud - I test on VMWare and/or VirtualBox but deploy to multiple public cloud vendors with the same recipes.)</p> <p>The downside is you'll need to learn the DSL. And possibly, make significant changes to your workflow. These systems also have their individual pros/cons. But doing things this way is certainly the next tier down from maintaining a customized VM image, and in many ways more flexible. If for example, every cloud provider gives you an NTP server address to keep your instances in sync, then images will have to be changed depending on the provider. With Chef/Puppet, this can be automated and abstracted away neatly. </p> <p>While VM Images are frozen copies of your desired 'configuration', they do not capture how <em>each component - each instance in the stack</em> - is to interact with one another. For example, an application server needs to know about the database server, it's address, various connection parameters - the database server needs to know about all the application servers that might want to connect to it (in a cloud context, the application servers may even grow or shrink in number with time). This is dynamic stuff that is very easy to automate with a system like Chef. </p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload