My colleague Chris Barclay sent a guest post to introduce two powerful new features for AWS OpsWorks.
New Modes for OpsWorks
I have some good news for users that operate compute resources
outside of AWS: you can now use AWS OpsWorks to deploy and operate
applications on any server with an Internet connection including
virtual machines running in your own data centers. Previously, you
could only deploy and operate applications on Amazon EC2 instances
created by OpsWorks. Now, OpsWorks can also manage existing EC2
instances created outside of OpsWorks. You may know that OpsWorks is a
service that helps you automate tasks like code deployment, software
configuration, operating system updates, database setup, and server
scaling using Chef. OpsWorks gives you the flexibility to define your
application architecture and resource configuration and handles the
provisioning and management of resources for you.
Click here to learn more about the
benefits of OpsWorks.
Customers with on-premises servers no longer need to operate separate
application management tools or pay up-front licensing costs but can
instead use OpsWorks to manage applications that run on-premises, on
AWS, or that span environments. OpsWorks can configure any software
that is scriptable and includes integration with AWS services such
as Amazon CloudWatch.
Use Cases & Benefits
OpsWorks can enhance the management processes for your existing EC2
instances or on-premises servers. For example:
- With a single command, OpsWorks can update operating systems and
software packages to the latest version across your entire
fleet, making it easy to keep up with security updates.
- Instead of manually running
commands on each instance/server in your fleet, let OpsWorks run scripts
or Chef recipes for you. You control who can run scripts and are
able to view a history of each script that has been run.
Instead of using one user login per instance/server, you can manage
operating system users and ssh/sudo access. This makes it easier
to add and remove an individual user’s access to your instances.
Create alarms or scale instances/servers based on custom Amazon CloudWatch
metrics for CPU, memory and load from one instance/server or aggregated
across a collection of instances/servers.
Let’s walk through process of registering existing on-premises or EC2 instances. Got to
the OpsWorks Management Console
and click Register Instances:
Select whether you want to register EC2 instances or on-premises
servers. You can use both types, but the wizard operates with one
class at a time.
Give your collection of instances a Name, select a Region, and
optionally choose a VPC and IAM role. If you are registering EC2
instances, select from the table before proceeding to the next step.
Install the AWS CLI
on your desktop (if you have already installed an older version of the CLI, you may need to update it in order to
use this feature).
Run the command displayed in the Run Register Command section using the CLI installed in the previous step.
This uses the CLI installed on your desktop to install the OpsWorks agent onto the selected instances.
You will need the instance’s ssh user name and private key in order to perform the installation. See
the documentation if you want to run the CLI on
the server you are registering. Once the registration process is complete, the instances will appear in the list as “registered.”
Click Done. You can now use OpsWorks to manage your
instances! You can view and perform actions on your instances in
the Instances view. Navigate to the Monitoring view to see the 13
included custom CloudWatch metrics for the instances you have
Pricing and Availability
OpsWorks costs $0.02 per hour for each on-premises server on which you install the agent, and is available at no
additional charge for EC2 instances. See the OpsWorks Pricing page to learn more about our
free tier and other pricing information.
— Chris Barclay, Principal Product Manager
Feed Source: Amazon Web Services Blog
Article Source: AWS OpsWorks Update – Support for Existing EC2 Instances and On-Premises Servers