Automating AWS Cloud9
Automating AWS Cloud9
Check out this article to learn how to deploy AWS Cloud9 as a way to keep you and your team in the same IDE configuration.
Join the DZone community and get the full member experience.Join For Free
See why enterprise app developers love Cloud Foundry. Download the 2018 User Survey for a snapshot of Cloud Foundry users’ deployments and productivity.
AWS Cloud9 is a cloud-based Integrated Development Environment (IDE) for writing, running, and debugging code. With Cloud9, you can code with only your web browser. No need to download software, configure your environments, or set up your IDE and its configuration on each of your computers. You can collaborate in the same environment with other developers while seeing each of your changes in real time – raising the bar when it comes to pair programming and code reviews.
In this blog post, you’ll learn the problems that Cloud9 helps solve along with its benefits. You’ll also learn how to configure a Cloud9 environment using the console and how to automate the provisioning of Cloud9 environments using AWS CloudFormation.
The Problems with Local Machines
We’ve been developing solutions on AWS for almost a decade at Stelligent. I’ve always found the irony in writing code on my local machine – with its idiosyncratic configurations – and then deploying that same code to the AWS platform with its different configurations. In fact, much of the purpose of Continuous Integration (CI) is to identify those things that “work on my machine” but do not work in downstream environments on their way to production. From my early days in software development, I’ve always thought that assumptions are the bane of effective programming.
In fact, in an effort to reduce assumptions, and prior to Cloud9, I’d often use vim on a newly launched EC2 instance just to ensure I knew how it might work on someone else’s machine who doesn’t have the same local machine configuration as me. Even though I’ve used vi for years, I don’t really consider myself a relative expert, so it wasn’t necessarily preferable to operate this way but I also didn’t want to turn work over to others that didn’t consider the impact of dependencies and local machine configurations.
When each engineer is developing locally, it also makes it difficult to share work in real time. This is particularly relevant for distributed teams. Sure, you can you screen share but you cannot give others access to that code in real time – unless you hand the control over to your computer control to others. To say the least, this is not convenient or desirable. Looking at each other’s screens does not scale well.
Being able to switch between devices is also a challenge. For instance, let’s say you’re working on your machine at work and want to switch to another machine while at home or traveling. Usually, this means you have to keep your IDE configurations in sync or accept the differences between the configuration of each of your machines.
Also, at the time of this writing, most IDEs don’t have much if any support for serverless applications that integrate services such as Lambda and API Gateway into the IDE.
In short, most IDEs make it difficult to get to the point of doing what you really want to be doing: writing code, collaborating with others, and getting feedback from customers.
Features and Benefits of Using Cloud9
With AWS Cloud9, you can simply launch an IDE from your web browser and get started quickly. Here are some of the features of Cloud9:
- Code with others in the same environment in real time;
- Deep integration with Serverless tools such as AWS Lambda;
- Direct terminal access with tools such as the AWS CLI and Git already configured;
- Customize key bindings, themes, AWS settings, user settings, project settings, etc.;
- Leverage AWS’s network connection to increase your speed of development; and
- Code in nearly any programming language you choose and use some of the top IDE platforms such as vim, emacs, and Sublime.
Cloud9 is a fully-functioning IDE you can run in your web browser enabling you to collaborate with other programmers in real time, eliminate dependencies on local configurations, and leverage AWS’ network throughput to rapidly focus on developing software
From the perspective of reducing the waiting and speeding up feedback loops, there are a couple of key benefits to Cloud9. The first is the real-time collaboration in being up to work with other developers in real time on the same code. The fact that most tools are already installed and configured (e.g. git and the AWS CLI) saves a lot of time and you can go from computer to computer and access your same environments and settings. All of this saves lots of unnecessary time and allows developers to focus on developing features for customers. In less than one minute, it launches your environment and you can immediately start writing code.
There is AWS CodeStar integration in Cloud9. With AWS CodeStar, you can set up your entire continuous delivery toolchain in minutes, allowing you to start releasing code faster.
Manually Setup a Cloud9 Environment
Here are the steps to manually configure your AWS Cloud9 environment:
- Go to the AWS Cloud9 console and select Create environment
- Enter a Name and Description
- Select Next step
- Select Create a new instance for environment (EC2)
- Select t2.micro
- Leave the Cost-saving setting at the After 30-minute (default) option
- Select Next step
- Review best practices and select Create environment
After clicking the Create environment button, it usually takes less than a minute to launch your Cloud9 environment. You can use this environment for only you or have other team members access the environment. By using the same environment with others on your team, you can collaborate with one or more engineers on the same code using the same settings much the way you might do with something like Google Docs.
You can also modify IDE configurations such as custom key bindings, themes, AWS settings, user settings, and project settings.
You can access the terminal, individual files, and use built-in integrations to deploy and test your applications and services – all from within your Cloud9 IDE.
Create a CloudFormation Template
Now that you’ve manually created a Cloud9 environment using the AWS Console, here are the steps to automating the provisioning of your Cloud9 environment:
- Create a new CloudFormation template. You can base it off of this CloudFormation template – which is based on the AWS CloudFormation resource here.
Parameters: EC2InstanceType: Default: t2.micro Description: EC2 instance type on which IDE runs Type: String AutoHibernateTimeout: Default: 30 Description: How many minutes idle before shutting down the IDE Type: Number SubnetIdentifier: Description: SubnetId Type: AWS::EC2::Subnet::Id Resources: IDE: Type: AWS::Cloud9::EnvironmentEC2 Properties: Repositories: - RepositoryUrl: https://github.com/stelligent/mu-cloud9.git PathComponent: github.com/stelligent/mu-cloud9 Description: Cloud9 IDE AutomaticStopTimeMinutes: Ref: AutoHibernateTimeout SubnetId: Ref: SubnetIdentifier InstanceType: Ref: EC2InstanceType Name: Ref: AWS::StackName
- Save the template and commit it to your version-control system. You’ll also want to upload it to S3 so that you can launch it through the Launch Stack button that you’ll see below.
There are three main steps in launching this solution: preparing an AWS account, launching the stack, and testing the deployment. Each is described in more detail in this section.
Step 1. Prepare an AWS Account
- If you don’t already have an AWS account, create one at http://aws.amazon.com by following the on-screen instructions. Part of the sign-up process involves receiving a phone call and entering a PIN using the phone keypad. Be sure you’ve signed up for the CloudFormation service.
- Use the region selector in the navigation bar of the console to choose the Northern Virginia (us-east-1) region
Step 2. Launch the Stack
Click on the Launch Stack button below to launch the CloudFormation stack. Before you launch the stack, review the architecture, configuration, security, and other considerations discussed in this post. To download the template, click here.
Time to deploy: Approximately 2 minutes.
You’ll go through a few screens as part of launching the stack. Once you see the CloudFormation Stack details, you’ll see a screen similar to the one below.
On this screen, there are four parameter values you may enter:
- Stack name – The unique name for your CloudFormation stack. The name is used to uniquely name the Cloud9 environment. When launching from the Launch Stack button above, the default name is Cloud9Stack.
- AutoHibernateTimeout – The number of minutes a Cloud9 IDE must be idle before it automatically stops the EC2 instance on which it’s running. The default value is 30 minutes.
- EC2InstanceType – The type of EC2 instance on which the Cloud9 environment will be launched. t2.micro is the default EC2 instance type.
- SubnetIdentifier – You will choose an existing Subnet Id with an existing VPC to identify which subnet your Cloud9 environment will be launched within the virtual private cloud.
At the conclusion of this process, you’ll see a Create stack button which you will click to launch the Cloud9 environment.
Here’s a listing of the key AWS resources that are created when this stack is launched:
The Cloud9 environment is configured on an EC2 instance within a subnet of a VPC.
Step 3. Test the Deployment
Once the primary CloudFormation stack has been launched, click on the Cloud9URL Output in your CloudFormation stack. Your newly provisioned Cloud9 environment will launch within your web browser. You may begin using the IDE.
For Cloud9, AWS charges you for the EC2 instance the EBS storage. Since you can choose different EC2 instance types and the amount of time you use Cloud9 may vary, prices are variable Fortunately, AWS provides a typical example pricing chart on the AWS Cloud9 Pricing page.
If you’re using the default settings running an IDE for 4 hours a day for 20 days a month with the auto-hibernate set to 30 minutes, your monthly charges for 90 hours of usage would be $1.85 (this is for the compute and storage fees).
Published at DZone with permission of Paul Duvall , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.