Using AWS CodeDeploy with Eucalyptus Cloudformation for On-Premise Application Deployments

Background

Recently, Amazon Web Services (AWS) announced that their CodeDeploy service supports on-premise instances.  This is extremely valuable – especially for developers and administrators to allow utilization of existing on-premise resources.

For teams who are using HP Helion Eucalyptus 4.1 (or who want to use Eucalyptus), this is even better news.  This feature – along with HP Helion Eucalyptus 4.1 Cloudformation – developers can deploy applications within a private cloud environment of HP Helion Eucalyptus.  This makes it even easier for developers and administrators to separate out and maintain production (AWS) versus development (HP Helion Eucalyptus) environments (or vice versa).  In addition, since HP Helion Eucalyptus strives for AWS compatibility, the Cloudformation templates used on Eucalyptus, can be used with AWS – with just a couple of modifications.

The Setup

To leverage on-premise instances with AWS CodeDeploy, please reference the AWS documentation entitled “Configure Existing On-Premises Instances by Using AWS CodeDeploy“.  To use these steps with an HP Helion Eucalyptus cloud, a slight change had to be done to the AWS CLI tools.  When using the ‘aws deploy register’ command, AWS CLI checks to see if the instance is running on an AWS environment by confirm if the instance metadata is present.  For on-premise cloud environments that provide the same service, this will cause the on-premise instance registration to fail.  To resolve this issue, I updated the AWS CLI tools with a patch that checks the instance metadata variable ‘AMI ID’ – which on AWS will begin with ‘ami’.  All images on Eucalyptus start with ’emi’ (i.e. Eucalyptus Machine Images).  With this patch, on-premise instance registration completes without a problem.

In addition to the patch, the following is needed on HP Helion Eucalyptus 4.1 cloud environments:

  1. Ubuntu Server 14.04 LTS EMI (EBS-backed or Instance Store-Backed)
  2. Eucalyptus IAM access policy actions that allow the user to use CloudFormations, AutoScaling and EC2 actions.  (Along with the Eucalyptus documentation, reference the AWS IAM documentation as well.)

Once these requirements have been met on the HP Helion Eucalyptus 4.1 environment, developers can use their AWS credentials in the Eucalyptus Cloudformation templates to leverage the on-premise instances with AWS CodeDeploy.

Using Eucalyptus Cloudformation For Instance Deployment

To help get started, I provided the following example Cloudformation templates:

Each template has specific parameters that need values.  The key parameters are the following:

  • UserKeyPair -> Eucalyptus EC2 Key Pair
  • UbuntuImageId -> Ubuntu 14.04 Cloud Image (EMI)
  • SSHLocation -> IP address range that can SSH into the Eucalyptus instances

Once there are values for these parameters, the Cloudformation templates can be utilized to deploy the on-premise instances.

Configure Existing On-Premises Instances by Using AWS CodeDeploy

After the AWS IAM prerequisites have been met for AWS CodeDeploy, use the example Cloudformation templates with HP Helion Eucalyptus.  Below is an example output of both templates being used on a given HP Helion Eucalyptus 4.1 cloud:

# euform-describe-stacks --region account2-admin@eucalyptus-cloud
STACK UbuntuCodeDeployTest CREATE_COMPLETE Complete! Eucalyptus Cloudformation Example => Deploy an instance that is configured and registered as an on-premise instance with AWS CodeDeploy 2015-04-14T02:42:01.325Z
PARAMETER UbuntuImageId emi-759e12a3
PARAMETER UserKeyPair account2-admin
OUTPUT InstanceId i-df9af6f5
OUTPUT AZ thugmotivation101
OUTPUT PublicIP 10.111.75.103
STACK UbuntuCodeDeployAutoScalingTest CREATE_COMPLETE Complete! Eucalyptus CloudFormation Sample Template AutoScaling-Single AZ for AWS CodeDeploy on-premise instances. The autoscaling group is configured to span in one availability zone (one cluster) and is Auto-Scaled based on the CPU utilization of the servers. In addition, each instance will be registered as an on-premise instance with AWS CodeDeploy. Please refer to http://docs.aws.amazon.com/codedeploy/latest/userguide/how-to-configure-on-premises-host.html for additional information. 2015-04-14T02:41:44.733Z
PARAMETER InstanceType m1.xlarge
PARAMETER UbuntuImageId emi-759e12a3
PARAMETER UserKeyPair account2-admin
PARAMETER MinSize 2
PARAMETER MaxSize 4
PARAMETER Zone theinspiration
OUTPUT AutoScalingGroup UbuntuCodeDeployAutoScalingTest-ServerGroup-211FTERKLII6T

Since both Eucalyptus Cloudformation stacks have successfully deployed, let’s check out the instances:

# euca-describe-instances --region account2-admin@eucalyptus-cloud
RESERVATION r-feeb1023 968367465792 UbuntuCodeDeployTest-CodeDeploySecurityGroup-HP5L5HRU3WI98
INSTANCE i-df9af6f5 emi-759e12a3 euca-10-111-75-103.eucalyptus.a-35.autoqa.qa1.eucalyptus-systems.com euca-10-111-75-107.eucalyptus.internal running account2-admin 0 m1.xlarge 2015-04-14T02:42:11.346Z thugmotivation101 monitoring-disabled 10.111.75.103 10.111.75.107 instance-store hvm sg-422ed69a x86_64
TAG instance i-df9af6f5 aws:cloudformation:logical-id CodeDeployInstance
TAG instance i-df9af6f5 aws:cloudformation:stack-id arn:aws:cloudformation::968367465792:stack/UbuntuCodeDeployTest/b210c81a-7e34-476f-9c59-7ea69ac9647a
TAG instance i-df9af6f5 aws:cloudformation:stack-name UbuntuCodeDeployTest
RESERVATION r-10df526e 968367465792 UbuntuCodeDeployAutoScalingTest-InstanceSecurityGroup-B2OVH0XWAFN5S
INSTANCE i-9b2b14e3 emi-759e12a3 euca-10-111-75-97.eucalyptus.a-35.autoqa.qa1.eucalyptus-systems.com euca-10-111-75-106.eucalyptus.internal running account2-admin 0 m1.xlarge 2015-04-14T02:42:05.939Z theinspiration monitoring-enabled 10.111.75.97 10.111.75.106 instance-store hvm d739a9eb-ba3c-4f16-940c-366a516cebfe_theinspiration_1 sg-556b10ce x86_64
TAG instance i-9b2b14e3 Name UbuntuCodeDeployAutoScalingTest
TAG instance i-9b2b14e3 aws:autoscaling:groupName UbuntuCodeDeployAutoScalingTest-ServerGroup-211FTERKLII6T
TAG instance i-9b2b14e3 aws:cloudformation:logical-id ServerGroup
TAG instance i-9b2b14e3 aws:cloudformation:stack-id arn:aws:cloudformation::968367465792:stack/UbuntuCodeDeployAutoScalingTest/2a5aefc6-c5c3-41e8-a9b4-a9ca095c1696
TAG instance i-9b2b14e3 aws:cloudformation:stack-name UbuntuCodeDeployAutoScalingTest
RESERVATION r-6c8a9642 968367465792 UbuntuCodeDeployAutoScalingTest-InstanceSecurityGroup-B2OVH0XWAFN5S
INSTANCE i-12f1a3a3 emi-759e12a3 euca-10-111-75-101.eucalyptus.a-35.autoqa.qa1.eucalyptus-systems.com euca-10-111-75-111.eucalyptus.internal running account2-admin 0 m1.xlarge 2015-04-14T02:42:05.872Z theinspiration monitoring-enabled 10.111.75.101 10.111.75.111 instance-store hvm 16a61ee7-d143-4f08-b926-c711ce335a1a_theinspiration_1 sg-556b10ce x86_64
TAG instance i-12f1a3a3 Name UbuntuCodeDeployAutoScalingTest
TAG instance i-12f1a3a3 aws:autoscaling:groupName UbuntuCodeDeployAutoScalingTest-ServerGroup-211FTERKLII6T
TAG instance i-12f1a3a3 aws:cloudformation:logical-id ServerGroup
TAG instance i-12f1a3a3 aws:cloudformation:stack-id arn:aws:cloudformation::968367465792:stack/UbuntuCodeDeployAutoScalingTest/2a5aefc6-c5c3-41e8-a9b4-a9ca095c1696
TAG instance i-12f1a3a3 aws:cloudformation:stack-name UbuntuCodeDeployAutoScalingTest

As we can see above, the Eucalyptus Cloudformation instances are tagged just as if they were running on AWS – again demonstrating the AWS compatibility desired by HP Helion Eucalyptus.

Now, look in the AWS Management Console, under the AWS CodeDeploy service.  In the dropbox under ‘AWS CodeDeploy’, select ‘On-Premise Instances':

Displaying the dropdown box options under the AWS CodeDeploy title
Displaying the dropdown box options under AWS CodeDeploy

Once that has been selected, the on-premise instances running on HP Helion Eucalyptus should show up as ‘Registered':

Display of Registered On-Premise Instances for AWS CodeDeploy
Display of Registered On-Premise Instances for AWS CodeDeploy

Now developers can proceed with remaining steps of using AWS CodeDeploy to do an application deployment.

Conclusion

As demonstrated, the new feature in AWS CodeDeploy allows developers to gain a true sense of a hybrid cloud environment.  This feature – along with HP Helion Eucalyptus’s AWS compatibility – makes it easy for developers and administrators to use the same toolset to deploy, manage and maintain both public and private cloud environments.  Don’t forget – using AWS CodeDeploy with on-premise instances does have an AWS pricing cost associated with it.  Check out AWS CodeDeploy Pricing for more details.

Enjoy!

Using AWS CodeDeploy with Eucalyptus Cloudformation for On-Premise Application Deployments

UCSB Sweethearts of Cloud Computing: AppScale and Eucalyptus

hspencer77:

AppScale and Eucalyptus: Great Tag Team for On-Premise Cloud Computing

Originally posted on shaon's blog:

Cloud computing is the use of computing resources (hardware and software) that are delivered as a service over a network (typically the Internet). – Wikipedia

According to Wikipedia currently there are few popular service models exist.

1. Infrastructure as a service (IaaS)
2. Platform as a service (PaaS)
3. Software as a service (SaaS)

So, I have an Eucalyptus cloud, which is great, serves as AWS-like IaaS platform. But now I want PaaS. And right here Appscale comes into play with full compatibility of Google App Engine (GAE) applications. In this post, we will install the popular open source PaaS framework Appscale on Eucalyptus, the AWS compatible open source IaaS platform.

Agenda
0. Introduction
1. Resize Lucid image
2. Install Appscale from source
3. Install Appscale Tool
4. Bundle Appscale image
5. Run Appscale
6. Run an application on Appscale

Eucalyptus
Eucalyptus Cloud platform is open source software for building…

View original 541 more words

UCSB Sweethearts of Cloud Computing: AppScale and Eucalyptus

Test Drive: Drupal Deployment on Eucalyptus using Stackato, Amazon Route 53 and the Eucalyptus Community Cloud

Recently, I did a blog discussing how to deploy a Jenkins server using Stackato, running on Eucalyptus.  At the end of that blog, I mentioned how the Eucalyptus Community Cloud (ECC) could be used for testing out the Stackato Microcloud image on Eucalyptus.   The previous blog – I felt – was more for DevOps administrators who had access to their own on-premise Eucalyptus clouds.  The inspiration of this blog comes from the blog on ActiveBlog entitled “Deploy & Scale Drupal on Any Cloud with Stackato” to show love to Web Developers, and show the power of Amazon’s Route 53.

Test Drive Pre-Reqs

The prerequisites for this blog are the same that are mentioned in my previous blog regarding using Stackato on Eucalyptus (for the Eucalyptus pre-reqs, make sure the ECC is being used).  In addition to the prerequisites mentioned above, the following is needed:

After the prerequisites have been met, its time to setup the Drupal environment.

Test Drive Engage!

Since the ECC is being used, there is no need to worry about bundling, uploading and registering the Stackato image.  The Stackato image used for this blog is as follows:

IMAGE emi-859B3D5C stackato_v2.6.6/stackato-cloudinit.manifest.xml
150820662310 available public x86_64 machine eki-6FBE3D2D eri-67463B77 instance-store

Next, lets make sure the user has an elastic IP that will be used in AWS Route 53, and a security group to allow proper network traffic to the instance.  Do the following:

  1. Make sure the user credentials are sourced correctly, and euca2ools is installed correctly.
  2. Grab an elastic IP using euca-allocate-address (in this example 173.205.188.105 was allocated):

    # euca-allocate-address
    ADDRESS 173.205.188.105

  3. If the user already doesn’t have a keypair, create a keypair for the user by using euca-create-keypair, and make sure the permission of the file is 0600:  

    # euca-create-keypair hspencer-stackato > hspencer-stackato.priv 
    # chmod 0600 hspencer-stackato.priv

  4. Create a security group for the instance to use:

    # euca-create-group stackato-test -d "Test Security Group for Stackato PaaS"
    GROUP stackato-test Test Security Group for Stackato PaaS

  5. Authorize ping, ssh, http, and https ports:

    # euca-authorize -P icmp -t -1:-1 -s 0.0.0.0/0 stackato-test
    GROUP stackato-test
    PERMISSION stackato-test ALLOWS icmp -1 -1 FROM CIDR 0.0.0.0/0
    
    # euca-authorize -P tcp -p 22 -s 0.0.0.0/0 stackato-test
    GROUP stackato-test
    PERMISSION stackato-test ALLOWS tcp 22 22 FROM CIDR 0.0.0.0/0
    
    # euca-authorize -P tcp -p 80 -s 0.0.0.0/0 stackato-test
    GROUP stackato-test
    PERMISSION stackato-test ALLOWS tcp 80 80 FROM CIDR 0.0.0.0/0
    
    # euca-authorize -P tcp -p 443 -s 0.0.0.0/0 stackato-test
    GROUP stackato-test
    PERMISSION stackato-test ALLOWS tcp 443 443 FROM CIDR 0.0.0.0/0

  6. Now, launch the instance, specifying the keypair name to use, and a VM type.  On the ECC, only m1.xlarge and c1.xlarge meet the requirements of launching the Stackato image:

    # euca-run-instances -k hspencer-stackato -t c1.xlarge emi-859B3D5C -g stackato-test
    RESERVATION r-66EE4030 628376682871 stackato-test
    INSTANCE i-E85843C4 emi-859B3D5C euca-0-0-0-0.eucalyptus.ecc.eucalyptus.com euca-0-0-0-0.eucalyptus.internal
     pending hspencer-stackato 0 c1.xlarge 2013-02-24T19:40:35.516Z partner01 eki-6FBE3D2D
     eri-67463B77 monitoring-disabled 0.0.0.0 0.0.0.0 instance-store

  7. Once the instance gets to a running state, associate the elastic IP that the user owns to the instance:

    # euca-describe-instances
    RESERVATION r-66EE4030 628376682871 stackato-test
    INSTANCE i-E85843C4 emi-859B3D5C euca-173-205-188-106.eucalyptus.ecc.eucalyptus.com
     euca-10-9-190-24.eucalyptus.internal running hspencer-stackato 0 c1.xlarge 
    2013-02-24T19:40:35.516Z partner01 eki-6FBE3D2D eri-67463B77 monitoring-disabled
     173.205.188.10 10.9.190.24 instance-store
    
    # euca-associate-address -i i-E85843C4 173.205.188.105
    ADDRESS 173.205.188.105 i-E85843C4
    
    # euca-describe-instances
    RESERVATION r-66EE4030 628376682871 stackato-test
    INSTANCE i-E85843C4 emi-859B3D5C euca-173-205-188-105.eucalyptus.ecc.eucalyptus.com
     euca-10-9-190-24.eucalyptus.internal running hspencer-stackato 0 c1.xlarge 2013-02-24T19:40:35.516Z
     partner01 eki-6FBE3D2D eri-67463B77 monitoring-disabled 173.205.188.10 10.9.190.24 instance-store

  8. Log into the AWS management console,  select Route 53, and setup the A and CNAME records in your domain as mentioned here under the Stackato Documentation regarding detailed DNS configuration.  In this example, the DNS name associated with the elastic IP 173.205.188.105 is stackato-dev.mindspew-age.com.
  9. Next ssh into the instance, and proceed to follow the steps for setting up the Stackato instance that is mentioned in my previous blog under the section Configuration of the Stackato Instance.  Make sure the DNS name setup in AWS Route 53 is used with “kato rename public-DNS-name” and “kato setup core api.public-DNS-name” configuration steps.
  10. After the instance is configured, just open up the browser and go to the DNS name set up for the Stackato instance in AWS Route 53, as mentioned in the Stackato Documentation regarding configuration via the Management Console.
  11. Once logged into the Stackato Management Console, select “App Store” in the lefthand menu and select “Drupal” to install

    App Store - Drupal Application
    App Store – Drupal Application

     

  12. After Drupal has installed, start the application.  Once it has started successfully, select the URL that shows up in the right-hand menu box.  The Drupal log-in page will appear in your browser

    Drupal Landing Page
    Drupal Landing Page

Thats it!  Now Drupal is ready for any web developer to test out on the ECC.  If there is any questions/comments/suggestions, please feel free to leave comments.  Enjoy!

Test Drive: Drupal Deployment on Eucalyptus using Stackato, Amazon Route 53 and the Eucalyptus Community Cloud

Ansible + AWS + Eucalyptus == Solid Configuration Management for Hybrid Cloud

hspencer77:

Good AWS + Eucalyptus Love with Ansible!

Originally posted on Take that to the bank and cash it!:

You may be forgiven for thinking that a version 1.0 software release indicates some sort of significant milestone for the lifecycle of a project.  Perhaps in many cases it does but with Ansible, not so much.  Michael DeHaan articulates it much better than I could in this post to the project mailing list.  My personal experience from using Ansible since v0.8 is that each release delivers consistency, quality and increased flexibility.  It’s great to see fast releases delivering something which is incrementally more useful and enjoyable to use.  There’s always new handy stuff in each release.

For those using AWS and Eucalyptus, Ansible 1.0 is a perfect example of incremental AWSomeness (geddit?!).  Along with a host of other improvements it delivers the following for AWS/Eucalyptus users:

  • An updated ec2 module; ported to boto by our very own tgerla and now with the capability to launch multiple instances.  It works…

View original 152 more words

Ansible + AWS + Eucalyptus == Solid Configuration Management for Hybrid Cloud