awsebcli 3.4.4

Command Line Interface for AWS EB.

EB-CLI

EB Command Line Interface (CLI) is a tool that helps you deploy and manage your AWS Elastic Beanstalk applications and environments. It also provides integration with Git. This file provides a sample walkthrough of EB CLI. To view a list of commands, type:

eb –help

For more information about a specific command, type:

eb {cmd} –help

For detailed information about EB CLI, see EB Command Line Reference.

Installation

You will need administrator/sudo privileges unless you install into a virtual environment. To install you will first need to install Python and Pip. The most recent version of Python now includes pip.

To install Python, go here.

If you already have Python, but need to install Pip, go here.

After you have installed Pip, run the following command:

pip install awsebcli

Getting Started

EB CLI requires you to have AWS security credentials. For procedures to get security credentials, see the documentation.

1. Create a new directory for your project.

In Linux/UNIX, type the following:

mkdir my-hello-app

In Windows, type the following:

md my-hello-app

2. Create an index.html file for EB CLI to use as your sample application.

echo “Hello World” > index.html

NOTE: In Windows, do not include quotes in the command.

3. Set up your directory with EB CLI and then answer the questions to configure AWS Elastic Beanstalk.

eb init

When prompted for your AWS security credentials, type your access key ID and secret access key. To answer a question with the default value, press Enter.

4. Create your running environment and deploy the Hello World application.

eb create

Wait for AWS Elastic Beanstalk to finish creating the environment. When it is done, your application is live in a load-balancing environment.

5. View your application.

eb open

6. Update the sample application to create a new application version to deploy.

Make a change to your code by typing the following:

echo “ to you.” >> index.html

NOTE: In Windows, do not include quotes in the command.

When you are ready to launch your new application version, type the following:

eb deploy

7. View the updated environment.

eb open

8. Shut down your running environment.

eb terminate

Confirm that this is the environment that you want to terminate by typing the environment name.

9. Clean up.

To completely remove your application and clean up the local project directory, type the following:

eb terminate –all

Confirm that this is the application that you want to remove by typing the application name.

EB CLI Commands

This section describes some EB CLI 3 commands and why you would use them.

1. View environment status.

eb status -v

The status command will show you the current state of your application. This includes things such as:

• Environment Name

• Application Version

• Solution Stack

• Health

• Number of running instances

2. List your running environments.

eb list

The list command will show you a list of running environments. The environment with an asterisk next to it is the default environment. To see more detailed information about your environments, type the following to use verbose mode:

eb list -v

3. Change your current environment.

You can run most commands with any environment by using the following syntax:

eb {cmd} <environment>

To change your default environment, type the following:

eb use [environment_name]

4. Open the AWS Elastic Beanstalk management console.

To view your environment in the AWS Management Console, type the following:

eb console

5. Change environment variables.

You can set environment variables for your running environment at any time by typing the following:

eb setenv foo=bar

You can view your environment variables by typing the following:

eb printenv

Using EB CLI with Git

EB CLI 3 provides integration with Git. After running “git clone” or “git init”, run the following command:

eb init

EB CLI 3 will now recognize that your application is set up with Git.

To use Git with EB CLI 3:

1. Make any change to your code.

2. After you make a change to your code, type the following:

   git commit

3. Deploy your updated code.

Now when you run the “eb deploy” command, EB CLI will only deploy the code that was under source control. Make sure to always commit what you want to deploy. EB CLI uses your commit ID and message as the version label and description, respectively.

4. Deploy to production.

When you are ready to deploy an updated version of your code, use Git tags.

git tag -a v1.0 -m “My version 1.0”

The tag will be used for the version label so you always know which version your environment is running on. If you have already deployed this version, EB CLI will deploy that version to your environment instead of uploading a new application version.

5. Use branches.

EB CLI enables you to associate different branches with different branches of your code. For example:

git checkout master

eb use prod

git checkout develop

eb use dev

Now whenever you switch to a new branch, your default environment will also switch.

Changelog

3.4.4 (2015-05-18)

• Changed how Sample Application is handled internally

3.4.3 (2015-05-12)

• Fix issue with “eb config” when adding new option settings

• Update golang local container file

• Fix issue with overwriting docker environment variables during local

3.4.2 (2015-05-09)

• Fix issue with installation for eb local files

3.4 (2015-05-07)

• Added ‘localContainerDefinitions’ section for multi-continer docker

• Multi-container docker containers now correctly read ‘environment’

• Added printenv/setenv commands to eb local

• t2.micro is now default instance type for accounts with a default vpc

• add –staged option to eb deploy for deploying git stage rather then commit

• Fix config file path resolution

3.3.2 (2015-04-30)

• Fix “eb open” for windows

3.3.1 (2015-04-28)

• Fix –force option on “eb labs cleanup-versions”

3.3 (2015-04-28)

• Added “local” commands

• Added “eb labs cleanup-versions” for cleaning up old app versions

• Added support for an .ebignore file

• using “eb terminate –all” now removes application bundles from s3

• Add support for branch specific defaults in config.yml

• Fix interactive vpc bug

• Fix “eb open” race condition

• Incomplete credentials errors are now more verbose

3.2.2 (2015-04-06)

• Fix issue with creating single instance environments

3.2.1 (2015-04-02)

• Added warning string for Multi-container permissions on “create”

3.2 (2015-03-30)

• Added “platform” commands

• Added “upgrade” command

• Added “abort” command

• Added “labs” commands

• Printed events now look nicer

• Logs and events are automatically paged.

• Health based rolling updates are now default for new environments.

3.1.3 (2015-03-13)

• Added option on create for specifying database version (–database.version)

3.1.2 (2015-02-26)

• Fix multithreaded issue on python 3.4.3

• Fix environment names printing in columns

• Update botocore to 0.93.0

3.1.1 (2015-02-24)

• Fix git issue on windows

• Support older versions of git

• Saved Configurations now work with Worker tier

3.1 (2015-02-17)

• Editor backup files (file.txt~) no longer included in application zip

• Added commands for Saved Configurations (eb config –help)

• Now receive alerts for an outdated cli and outdated environment platform.

• Deploy now works in subdirectories

• Config now works in subdirectories

• Can now specify your own timeout period with “–timeout x”

• Can now specify environment variables on environment create with “–envvars”

• Can now get the latest platform version when you clone an environment. “eb clone”

• Application Bundle uploads now show status

• Large file uploads are now multi-threaded

• Added warning on deploy if unstaged git changes exist

• Can now swap environment CNAME’s using “eb swap”

• Exposed –vpc option on create

• Added –no-verify-ssl option

• Updated Botocore to 0.88.0

3.0.11 (2015-02-09)

• Fixed Zipping issue for Windows Containers

3.0.10 (2014-11-24)

• Fixed parsing error for uploads in a s3 bucket with auto-deletion policy

• Fixed terminated environment issues

• No longer uploads application if the application version already exists in s3

• Default database username changed from admin to ebroot

• Trim application version description if it is too long

• Application version no longer includes git hash