CloudBolt Software Logo

CloudBolt Blog

Rick Kilcoyne

Recent Posts

Confessions of a Cloud Skeptic

Posted by Rick Kilcoyne

2/2/16 2:22 PM

TL;DR Like many others, I used to believe Cloud was just a computer somewhere else. I've since come to the realization that Cloud is an application that abstracts and virtualizes the operational details of the servers, software, networks and storage required to deploy modern Internet-based applications. If Enterprise IT is to survive the onslaught of Cloud, they must adopt the same operational efficiencies as AWS and other public cloud providers.  This includes exposing IT as a Self-Service Application or Portal. Only then will they be able to stave off Shadow IT and offer their customers the ability to develop, deploy, and manage applications without the day-to-day involvement of IT Operations.

I freely admit it took me a while to come to terms with the term "Cloud". For years I used the infamous Visio cloud shape in my network diagrams.  Still, it was difficult to buy into "cloud" as a revolutionary new place where data could be stored centrally and transferred locally over high-speed Internet. "Cloud" became a term that I viewed as spin on the old: mainframe, client/server, web hosting, ASP, MSP, CSP.  In short, "cloud" was a new term for the same thing – my "stuff" is stored and running elsewhere. And yes, I admit to getting a kick out of watching Larry Ellison poke fun at Cloud Computing back in 2008. With his usual flair, Ellison pointed out that "Cloud Computing" covers everything we were already doing. In the late 2000’s, everything and anything in the computing industry was described as Cloud, Cloud-ready, or Cloud-enabled.

NoCloud.pngFor years I wholeheartedly agreed with anyone that claimed that “cloud” was just a marketing buzzword. With time, though, my attitude slowly shifted.  Cloud isn't necessarily a set of servers that live on a faraway network. A true cloud is a software application, complete with its own UI, API, user management, and a suite of opaque services. Virtualization at the server, network, and storage levels allow users to interact with abstractions that look and feel like physical systems. Cloud architecture is yet another example of Marc Andreessen's declaration that "Software is eating the World", only this time it's enterprise IT being served up for breakfast, lunch, and dinner.

With the right amount of vision and execution, enterprise IT stands to benefit from cloud computing.  But it will require them to provide users the ability to utilize resources on their own terms. This is a delicate balancing act:

  • Too many restrictions from IT will drive users into the arms of public cloud providers while fueling shadow IT.
  • Running a wide-open environment will come at the expense of security, reliability, and maintainability.

If enterprise IT is going to survive and thrive in the face of public cloud, they need to balance corporate governance needs against user self-service and operational agility that encompasses what the leading public cloud providers are already doing – certainly no easy task.

First this requires embracing the fact that service desks and request tickets are relics of IT past. Users (specifically developers) want fast, easy, and reliable access to IT resources and the freedom to experiment and innovate without the overhead of passing everything through IT operations (ITOps). With the new enterprise Cloud, developers and product teams become responsible for the deployment and management their own applications.  ITOps provides the platform for enterprise cloud applications (web-based or otherwise) which manages all the backing networks, systems, and storage. Unless a problem percolates up to the application level, users have little-to-no visibility into what's happening behind the scenes.

As a test of this model, think of AWS. Do you frequently file trouble tickets with AWS? Do you constantly hear about day-to-day operational difficulties at AWS? Do you find yourself waiting until some AWS team returns from lunch to get the servers or services you requested? If your enterprise IT team is embracing what I feel is the true meaning of "Cloud", then asking these same answers of your enterprise cloud should yield the same resounding "NO!"

Read More

Topics: Public Cloud, Shadow IT, Self Service IT, Hybrid Cloud

Create a CloudBolt Plug-in: Check EC2 Instance Reachability

Posted by Rick Kilcoyne

11/2/15 11:30 AM

UPDATE: As of Verison 5.3.1, it will no  longer be necessary to check EC2 instance reachability. This functionality has been rolled into the product. This article is still a great example of what it takes to write a CloudBolt plug-in and will be useful in many other scenarios. ~Rick

 

A common use-case I see frequently is the need to make sure new EC2 instances are up and ready to accept SSH connections before CloudBolt marks the provisioning job as complete. In this article, we’re going to work together to write a CloudBolt plug-in that will add this functionality to our CloudBolt environments. In doing so, I hope you'll not only gain an appreciation for the power of CloudBolt as a cloud automation platform, but you'll also see how easy it is to extend our base feature set using upgrade-safe scripts.

Getting Started

Writing Python code is a relatively painless process that usually starts with a text editor. I use OSX, so I prefer TextMate. If you’re a Windows user, I suggest Sublime Text 2 (http://www.sublimetext.com/2) or Notepad++. Another great option is to use PyCharm for all your CloudBolt plug-in development projects. I plan to expand on this topic in a future article.

Planning Our Attack

Let’s talk briefly about what we want to accomplish with this plug-in: When we provision a VM to EC2 via CloudBolt, we want to wait until that server is finished initializing and ready for SSH access before marking the entire CloudBolt provisioning job as complete. By default CloudBolt marks the job complete once the VM state is set to “OK” by AWS. Unfortunately, this isn’t the full story on the VM's readiness. The “OK” state is set before the VM is initialized and before the user can login via SSH. Imagine your poor users – they just used the awesome CloudBolt platform to spin up a VM, and once their job is “complete”, they get a “Connection Refused” error when they try to connect via SSH – not cool.

To address this issue, we'll extend CloudBolt to wait until our new EC2 instance has passed all EC2 status checks before marking the job as successfully completed. To accomplish this, we’ll trigger an action at the post-provision stage of the “Provision Server” Orchestration Action that will poll EC2 every two seconds to see if our new instance is reachable according to the EC2 status checks. We‘ll implement this action as a CloudBolt plug-in script written in Python.

Starting our Plug-in

Let's start our plug-in with a file called “poll_for_init_complete.py” with the following contents:


def run(job, logger=None, **kwargs):
    return """"""

The CloudBolt platform knows to call this function when it‘s time to execute the plug-in, therefore it's essential that it exists in your plug-in script. Note that the first and required parameter to this function is called job. This implies that we should expect the CloudBolt platform to call this function with the originating provisioning job passed as a job.models.Job object.

Returning a tuple of ("", "", "") is the default way of communicating to the CloudBolt platform that the script was a success.

Let's Get Busy

Let's add a few more lines to our plug-in script to get the server (our new EC2 instance) from the Job object and wait until it's reachable:


import time
from jobs.models import Job
 
TIMEOUT = 600
 
def run(job, logger=None, **kwargs):
    server = job.server_set.first()
    timeout = time.time() + TIMEOUT
 
    while True:
        if is_reachable(server):
            job.set_progress("EC2 instance is reachable.")
            break
        elif time.time() > timeout:
            job.set_progress("Waited {} seconds. Continuing...".format(TIMEOUT))
            break
        else:
            time.sleep(2)
 
    return """"""

Let's walk through what what we have so far:

server = job.server_set.first() sets the variable called server to the Server object associated with this job. Since we're working with a server provisioning job, it's safe to assume we're only going to have one Server associated with this job, therefore we call first() on our job's server_set property.

We defined a constant called TIMEOUT in our plug-in module and set it to 600. We then use this TIMEOUT at timeout = time.time() + TIMEOUT to set the time at which we should no longer wait for our EC2 instance to initialize. This prevents CloudBolt from waiting indefinitely if for some reason EC2 cannot determine the reachability of our server. Since this is in seconds, we'll stop waiting after a maximum of 10 minutes has passed before marking the job as complete. This should be the exception – not the norm.

We then start an infinite loop that will only stop when either our timeout elapses or we determine that our EC2 instance is reachable with the function is_reachable(server) which we haven't yet defined.

Is it Reachable or Not?

The script above is still missing the implementation of our is_reachable function. Given the server object associated with this job, this function will use the AWS Boto API to determine the reachability status for our new EC2 instance.  Note: Boto is the name of the Python API used to access the AWS API.

Let's add our is_reachable function to our script above our run function:


import time
 
TIMEOUT = 600
 
def is_reachable(server):
    instance_id = server.ec2serverinfo.instance_id
    ec2_region = server.ec2serverinfo.ec2_region
 
    rh = server.resource_handler.cast()
    rh.connect_ec2(ec2_region)
    wc = rh.resource_technology.work_class
 
    instance = wc.get_instance(instance_id)
    conn = instance.connection
    status = conn.get_all_instance_status(instance_id)
    return True if status[0].instance_status.details[u'reachability'] == u'passed' else False
 
 
def run(job, logger=None, **kwargs):
    # SNIP... 

Let's step through this function step-by-step:

  1. instance_id = server.ec2serverinfo.instance_id
    Get the EC2 instance ID associated with our new server being provisioned through CloudBolt. This is a string that looks like i-2423c494 in the EC2 console.

  2. ec2_region = server.ec2serverinfo.ec2_region
    Get the AWS region into which our new EC2 instance is being deployed.

  3. A few CloudBolt platform API gymnastics to get the backing Boto API objects without specifying any credentials. Always keep credentials out of your scripts!
    rh = server.resource_handler.cast()
    rh.connect_ec2(ec2_region)
    wc = rh.resource_technology.work_class

  4. instance = wc.get_instance(instance_id)
    Get the Boto Instance object associated with our new server's instance ID.

  5. status = instance.connection.get_all_instance_status(instance_id)
    Using the connection associated with our Boto Instance object, return the instance status for our server.

  6. return True if status[0].instance_status.details[u'reachability'] == u'passed' else False
    If the reachability status for our server is “passed”, return True because our new server is now reachable. If not, return False. We use status[0] because our get_all_instance_status function above returns an array. In this case we're only asking for the status of one instance, so we know the array only has one Status object and thus we use status[0].

Going back to our loop you can now see how the is_reachable function is used to keep the loop going if the answer is false:


while True:
    if is_reachable(server):
        job.set_progress("EC2 instance is reachable.")
        break
    elif time.time() > timeout:
        job.set_progress("Waited {} seconds. Continuing...".format(TIMEOUT))
        break
    else:
        time.sleep(2)

If our server is NOT reachable, and our timeout hasn't expired, we wait two seconds and try again.

Putting it All Together

The complete script can be downloaded from cloudbolt-forgeCloudBolt Forge is a source of user-contributed actions and plug-ins

Now that it's ready, let's add it to the appropriate trigger point in CloudBolt.

In your CloudBolt instance, navigate to Admin > Actions > Orchestration Actions and click “Provision Server” on the left tab bar. Find the “Post-Provision” trigger point at the bottom of the page and click the “Add an Action” button.

Select “CloudBolt Plug-in” and in the next dialog, click "Add new cloudbolt plug-in".

Specify a name for our new plug-in (Poll for EC2 Init Complete), select the "Amazon Web Services" resource technology, browse to your script, and click "Create".  Selecting the "Amazon Web Services" resource technology ensures this plug-in only runs against AWS resource handlers that you've defined and not others to which this plug-in is not applicable.

Give it a try

Provision a server to one of your AWS-backed CloudBolt environments. Watching the job progress, you'll see that the job is not marked as complete until the server is fully reachable and SSH access is available.

Questions? Comments? Concerns?

Don't hesitate to reach out to me (rkilcoyne@cloudbolt.io) or any of the CloudBolt Solutions team for help!

Read More

Topics: Automation, AWS, CloudBolt

CloudBolt v.5.1 Now Available

Posted by Rick Kilcoyne

7/15/15 3:17 PM

The heat of Summer has settled in, and we have a new release to help keep your end-users cool and comfortable. This release adds a plethora of new automation features starting with the ability to run remote scripts on any server regardless of cloud or OS. Yes, that includes Windows – we use winrm to work with our favorite OS from Redmond. You can also now wire up CloudBolt to your favorite internal tools using webhooks. Want to notify everyone in your project HipChat room when a server is ready? Create a webhook in CloudBolt!

We've all been been eagerly anticipating the ability to respond to user-defined thresholds on quotas. This release delivers this ability in the form of Admin > Event Automations. Speaking of Admin, checkout the new UI for the Admin section. This release includes several UI improvements and there are many more to come, so if you have suggestions – keep 'em coming!

There are many other new additions to CloudBolt with this release including initial support for Kubernetes/Docker, Service Catalog improvements, and API improvments. Also note, we've renamed CSCV to CIT (Continuous Infrastructure Testing). If you're not using this feature to test your CloudBolt environments, you're really missing out!

If you haven't yet tried CloudBolt, you have to see it to believe it – schedule a demo or request a download today.

Existing customers: start your upgrade process today by going to http://support.cloudbolt.io and downloading the latest upgrader. As always, if you run into any issues, please don't hesitate to drop us a support request at support@cloudbolt.io and we'll jump on it ASAP.

Check out the release notes.

Read More

Topics: News, Upgrade, Release Notes

Meet the CloudBolt team at ChefConf 2015

Posted by Rick Kilcoyne

3/21/15 7:34 AM

ChefConf 2015 is a little more than a week away and we couldn't be more excited!

Not only is ChefConf amongst the seminal configuration management events of the year, but it's also a great opportunity for us to rub elbows with our automation peers and demonstrate how we leverage Chef to quickly deliver configured applications to end-users. CloudBolt includes native integration with Hosted Chef, Enterprise Chef, and Open Source Chef to deliver the best cloud delivery platform, and it does so by building atop your existing Chef infrastructure and automation efforts.

If you're headed to ChefConf 2015 in San Jose, stop by booth T3, say hello, build a server, and get some free stuff!

~Rick

Read More

Topics: Event