X

Pat Shuff's Blog

  • Iaas
    August 3, 2016

Orchestration 2.0 - creating a storage element

In this blog we will look at an Oracle Orchestration for a Bitnami WordPress instance. We provisioned the instance by going to the http://cloud.oracle.com/marketplace and provisioned a WordPress instance. The instance that we are going to install can be found at https://cloud.oracle.com/marketplace/en_US/listing/4980490?_afrLoop=9282045484046863&_afrWindowMode=0&_afrWindowId=87oc7qxu0_1 and is based on Oracle Linux 6.7. The minimum profile for this instance is an OC3 (1 OCPU, 7.5 GB RAM) and 60 GB of local disk.

When we click on the Get App button for this application it takes us through the installation process for cloud compute services. The process that is kicked off when we click on the Get App button downloads a bootable image from the Marketplace and makes it available as an Image that we can create new instances from any time we want. The default size is 10 GB. We need to grow this installation to be 60 GB to allow MySQL and the WordPress application to operate properly.


To create an instance we go to the compute console and create instance. We select private images to get to the WordPress bitnami instance that we downloaded to boot from. We enter the network security list, ssh keys, and name for the instance.


The default disk size is 10 GB. We will keep this and review the configuration before launching.



Once we click on Create the cloud console creates three orchestration files to initialize the WordPress instance.
The first file that is created defines the storage. The file is called bitnami-wordpress-4.5.3-0-linux-_20160721144012_storage.json if we accept all of the defaults. In our example it would be called WordPress_4_5_3_storage.json. This file describes the storage that is needed for booting the operating system and is of the format

{
"relationships" : [ ],
"account" : "/Compute-metcsgse00028/default",
"description" : "",
"schedule" : {
"start_time" : "2016-07-21T19:40:35Z",
"stop_time" : "2016-07-21T21:50:02Z"
},
"oplans" : [ {
"obj_type" : "storage/volume",
"ha_policy" : "",
"label" : "bitnami-wordpress-4.5.3-0-linux-_20160721144012_storage",
"objects" : [ {
"managed" : true,
"snapshot_id" : null,
"snapshot_account" : null,
"machineimage_name" : "/Compute-metcsgse00028/marketplace01-user@oracleads.com/bitnami-wordpress-4.5.3-0-linux-oel-6.7-x86_64",
"status_timestamp" : "2016-07-21T19:44:51Z",
"imagelist" : "/Compute-metcsgse00028/marketplace01-user@oracleads.com/bitnami-wordpress-4.5.3-0-linux-oel-6.7-x86_64",
"writecache" : false,
"size" : "10737418240",
"storage_pool" : "/compute-us2-z12/cheis01nas100-v1_multipath/storagepool/iscsi/latency_1",
"shared" : false,
"status" : "Online",
"description" : "",
"tags" : [ ],
"quota" : null,
"properties" : [ "/oracle/public/storage/default" ],
"account" : "/Compute-metcsgse00028/default",
"name" : "/Compute-metcsgse00028/cloud.admin/bitnami-wordpress-4.5.3-0-linux-_20160721144012_storage",
"bootable" : true,
"hypervisor" : null,
"uri" : null,
"imagelist_entry" : 1,
"snapshot" : null
} ]
} ],
"user" : "/Compute-metcsgse00028/cloud.admin",
"name" : "/Compute-metcsgse00028/cloud.admin/bitnami-wordpress-4.5.3-0-linux-_20160721144012_storage"
}

Let’s walk through this file and look at all the structures. Let’s break down the structure without all of the child components.
{
"relationships" : [ ],
"account" : "/Compute-metcsgse00028/default",
"description" : "",
"schedule" : { … },
"oplans" : [ … ],
"user" : "/Compute-metcsgse00028/cloud.admin",
"name" : "/Compute-metcsgse00028/cloud.admin/bitnami-wordpress-4.5.3-0-linux-_20160721144012_storage"
}

Note that there are seven elements that define this object. The first is the relationship. In this file, this is the basis of a configuration and it does not have any dependencies on another object. The second is account. Account defines the owner of the object and also defines security associated with the object. We could have a specific account in our identity domain that can access this object or make it accessible to all users through the default label. The third element is the description. There is no description for this object. We could have added more information when we created this information when we provisioned the disk. This is an informative field and is not critical for creation. The fourth field is schedule. The schedule defines when the object was created and logs the start and stop times for the object. The fifth field is the oplans. Oplans defines the object. We obscured the definition at this point and will dive into that next. The sixth field is the user field. The user is who created the object and who owns the object. The final and seventh field is the name of the object. The name consists of the identity domain, the user that created it, and the name of the object. In this example the name is "/Compute-metcsgse00028/cloud.admin/bitnami-wordpress-4.5.3-0-linux-_20160721144012_storage”. In our example it would be "/Compute-metcsgse00028/cloud.admin/WordPress_4_5_3_storage”.

If we dive into the oplans we note that the object is defined with

{
"obj_type" : "storage/volume",
"ha_policy" : "",
"label" : "bitnami-wordpress-4.5.3-0-linux-_20160721144012_storage",
"objects" : [ … ]
}

The oplans consists of four elements and are defined in the documentation. All of these objects are required with the exception of ha_policy. The first parameter defined is the obj_type. This parameter can be defined as
  • Ip-reservation
  • Launchplan
  • Orchestration
  • Storage/volume
  • Secapplication
  • Seciplist
  • Seclist
  • Secrule

    We are defining this element as a storage/volume. We give it the name associated with the label parameter and the characteristics defined in the objects parameters. We have the option of defining the ha_policy as active or monitor. If we define it as active the object is restarted if it is deleted or fails. Active is only available if the obj_type is launchplan. We can set the ha_policy to monitor for obj_type of launchplan, storage/volume, or orchestration. If the object fails an error is thrown and can be thrown to a monitoring software package but the object is not automatically restarted or recreated. For all other objects, the ha_policy must be set to none or set to an empty field. For our example we would set the label to “WordPress_4_5_3_storage” rather than the default label generated by the bitnami installation.

    The objects field is defined in the documentation. We are going to dive into the storage volume object in this example. The fields that are required for storage is name, size, and properties. The optional fields are description, bootable, and tags. For our example we define the objects parameter as

    "objects" : [ {
    "managed" : true,
    "snapshot_id" : null,
    "snapshot_account" : null,
    "machineimage_name" : "/Compute-metcsgse00028/marketplace01-user@oracleads.com/bitnami-wordpress-4.5.3-0-linux-oel-6.7-x86_64",
    "status_timestamp" : "2016-07-21T19:44:51Z",
    "imagelist" : "/Compute-metcsgse00028/marketplace01-user@oracleads.com/bitnami-wordpress-4.5.3-0-linux-oel-6.7-x86_64",
    "writecache" : false,
    "size" : "10737418240",
    "storage_pool" : "/compute-us2-z12/cheis01nas100-v1_multipath/storagepool/iscsi/latency_1",
    "shared" : false,
    "status" : "Online",
    "description" : "",
    "tags" : [ ],
    "quota" : null,
    "properties" : [ "/oracle/public/storage/default" ],
    "account" : "/Compute-metcsgse00028/default",
    "name" : "/Compute-metcsgse00028/cloud.admin/bitnami-wordpress-4.5.3-0-linux-_20160721144012_storage",
    "bootable" : true,
    "hypervisor" : null,
    "uri" : null,
    "imagelist_entry" : 1,
    "snapshot" : null
    } ]
    } ]

    The name of our object is "/Compute-metcsgse00028/cloud.admin/bitnami-wordpress-4.5.3-0-linux-_20160721144012_storage". Note that this consists of the instance domain, username that created the storage, and the label for the storage. In our example it would be "/Compute-metcsgse00028/cloud.admin/WordPress_4_5_3_storage". We define the size as "10737418240" which is in bytes. This correlates to a 10 GB disk for the operating system. Properties is defined as [ "/oracle/public/storage/default" ] which defines the storage as default storage. We could have selected latency rather than default if we required a low latency and high IOPS storage that is typically used for a database. The rest of the fields in this description are optional. The bootable tag defines if this is a bootable image and the status defines if the storage is active or in standby mode. Note that the storage_pool defines that this storage element is an iscsi logical unit number that is made available to the compute node rather than dedicated attached storage.

    All of these fields define what is required to create the storage that we are going to create to boot our operating system and run our WordPress application. We could just as easily have defined this as a 20 GB disk or 200 GB disk. It is important to note that you get 128 GB free with a compute instance and will have to pay $50/TB/month if you go over 128 GB of storage per instance. Up next, how to take this storage and associate it with an instance.

  • Be the first to comment

    Comments ( 0 )
    Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.