The key components to the json file are
{
"AWSTemplateFormatVersion" : "2010-09-09",
"Description" : " ... ",
"Parameters" : { ... },
"Mappings" : { ... },
"Resources" : { ... },
"Outputs" : { ... }
}
We can create a simple storage element in S3 with the following file
{
"Resources" : {
"HelloBucket" : {
"Type" : "AWS::S3::Bucket"
}
}
}
Note that the only thing that we truly need is the definition of a resource. The resource has a label of "HelloBucket" and the resource consists of an element defined as "AWS::S3::Bucket". Note that the Type is very specific to AWS. We could not take this generic definition and port it to any other platform. We don't know how much storage to allocate because S3 is typically an open ended definition. This is radically different from out storage creation from a few days ago where we had to define the storage_pool, size of the disk, and properties of the instance like is it bootable, what image to boot from, and what account it is associated with. The CloudFormation interface assumes account information because it is run from a web based or command line based interface that has your account information embedded into the user interface.
We could get a little more complex and define an instance. With this instance we reference an AMI that predefines the content and operating system. We also define the security ports and connection keys for this instance in the definition.
{
"Resources" : {
"Ec2Instance" : {
"Type" : "AWS::EC2::Instance",
"Properties" : {
"SecurityGroups" : [ { "Ref" : "InstanceSecurityGroup" }, "MyExistingSecurityGroup" ],
"KeyName" : "mykey",
"ImageId" : "ami-7a11e213"
}
},
"InstanceSecurityGroup" : {
"Type" : "AWS::EC2::SecurityGroup",
"Properties" : {
"GroupDescription" : "Enable SSH access via port 22",
"SecurityGroupIngress" : [ {
"IpProtocol" : "tcp",
"FromPort" : "22",
"ToPort" : "22",
"CidrIp" : "0.0.0.0/0"
} ]
}
}
}
}
We can also define some of the characteristics into the application. For CloudFormation we can configure WordPress with the following parameters
"Parameters": {
"KeyName": {
"Description" : "Name of an existing EC2 KeyPair to enable SSH access into the WordPress web server",
"Type": "AWS::EC2::KeyPair::KeyName"
},
"WordPressUser": {
"Default": "admin",
"NoEcho": "true",
"Description" : "The WordPress database admin account user name",
"Type": "String",
"MinLength": "1",
"MaxLength": "16",
"AllowedPattern" : "[a-zA-Z][a-zA-Z0-9]*"
},
"WebServerPort": {
"Default": "8888",
"Description" : "TCP/IP port for the WordPress web server",
"Type": "Number",
"MinValue": "1",
"MaxValue": "65535"
}
},
In summary, the Amazon CloudFormation and Oracle Orchestration are very similar. The components that you use to define a system are done similarly. Amazon makes assumptions that you are running on AWS and gives you short cuts and shorthand that allows you to create predefined components quickly and easily. Unfortunately this configuration does not translate to any other cloud provider or an in house solution. Oracle Orchestration is a little more nuts and bolts but is designed to help you create everything from scratch and build upon the foundation for system definitions. CloudFormation has a graphical user interface that generates json files for you based on dragging and dropping components into a design pallet. Oracle takes a slightly different approach and uses the Oracle Marketplace to automatically generate the json files. There is not a graphical design tool that allows you to drag and drop components but there are tools to take a configuration that is in your data center and generate the parameter list that can be used to generate the json files for Orchestration. We are not saying that one is better than the other in this blog. We are mainly pointing out that they two tools and utilities have different target audiences and functionality. Unfortunately, you can't take one configuration and easily map it into the other configuration. Hopefully someone at some point will take these files and create a translator.