Walkthru
Cloudamatic's mu tooling provides a number of illustrations and deployment patterns to get you started, ranging from the trivial to complex multitier deployments. A full set of demonstration BOK's are available in our repository as illustrated in Figure 1 below:
Figure 1: View of mu demos in GitHub
Optionally additional targeted deployments for useful services such as GlusterFS clusters, etc. will be available in future outside the open source project through our enhanced Apps program. Contact us if you're interested in enhanced apps or Cloudamatic/mu training.
The simple-server basket of kittens (BOK) below represents the absolute bare minimum descriptor to bring up a server. While not that useful in itself, it illustrates how little is required to start using Cloudamatic, and provides a building block for more complex and useful deployments:
Figure 1 -- BOK for Absolute Bare Minimum Server in Cloud
As you see, all you need to do is:
- Name the application, in this case "demo"
- Declare a "servers" array (see generic YAML Documentation for syntactic details)
- Within the array declare an individual server
- Give the server a node name to identify it within the deployment -- "simple"
- Give the server a size, in this case "m3.medium"
Note that we're using AWS as a deploy target in all our documentation
Cloudamatic is adaptable to a wide range of operating systems, and supports Windows as well as Linux for deployment nodes. Here's our simple server configured to run a windows instance, adding a few minor features along the way:
Note the additions:
- The platform attribute specifies windows rather than the (Linux) default
- We add a storage volume, which is implemented as an AWS Elastic Block Store (EBS) attachment
- We create an in-place firewall rule (ingress-rule) allowing Windows Terminal Server (port 3389) access for two concrete IP's
- We add a couple of administrators, who will be notified about the deploy and any Nagios alerts
The inline ingress-rule is to illustrate simplicity,. Usually you'll want to put your firewall rules in a separate firewall-rules stanza, often in an included file.
The deployment descriptor below is a very basic single-file BOK to start a single server running PHP. It goes beyond the absolute minimum in actually "doing something" to the provisioned server resource. In Cloudamatic "doing something" involves configuration (in this case) and orchestration (in more complex cases to come).
The simple server PHP orchestrates a single server and installs and configures PHP on the machine.
Line 7 Friendly name for the server (mostly used for tagging purposes)
Line 8 Base AMI to be used
Line 9 SSH user that the mu master uses to SSH into the node
Line 10 Size of the EC2 instance
Line 11: 12 Setting the static IP section to true will assign an Elastic IP on the EC2 instance.
Line 15: 21 Map to the security group rules.
Line 22: 24 Important configuration management component. This is where Mu consolidates orchestration and configuration management into one consistent YML / JSON based BOK. Here we set the runlist to run on the nodes.
Line 26: 32 Here we see an example of Mu dependency injection. The EC2 instance is launched in the VPC specified in this block. This can either be the current VPC (the same VPC as the Mu master), a target VPC, or a new VPC that will be created as part of this run.
Line 39: 43 This is a standard pattern for creating route tables in a new VPC. We create 2 routes tables, a public route table that sends all outbound traffic to the internet gateway, and a private route table that routes all outbound traffic to the NAT instance. Note the dependency on the NAT instance on Line 11. The dependency block is an important component of mu BOKs and enforces an order of creation for the different cloud resources. In this particular case, we want to make sure the mu-deploy creates the NAT instances first before creating the route tables.
Line 44: 49 This is a standard pattern for creating subnets in a new VPC. Mu makes the $az global variable available to all the BOKs. In this common VPC pattern, we leverage this ruby array of availability zones to create a public and a private subnet in each availability zone in the region we are currently provisioning in.
NOTE: $vpc_deploy_id, current_vpc and $azs are global variables that the mu platform makes available to all BOKs. This is an important architectural design to allow for "DRY" BOKs.