Integrating AWS Services
Many development scenarios require integrating AWS services, such as Rekognition or Translate, into the Brightspot webapp. The following sections describe how to integrate those services into Brightspot.
Most development scenarios involve coding on a host, building a .war, and deploying the .war to a Brightspot server running in a virtualized environment, typically a Vagrant virtual machine or a Docker container.
The most efficient way to integrate AWS into these virtualized environments is to configure the credentials on the host, and then have the virtual environment use the host’s credentials.
Referring to the previous illustration, the host connects directly to AWS. When you run aws on the host:
- The host looks up the credentials.
- The host authenticates with AWS.
- The host sends the command to AWS.
- The host receives the response from AWS.
Similarly, when you run aws on the guest:
- The guest looks up the host’s credentials.
- The guest authenticates with AWS.
- The guest sends the command to AWS. (The command may include some parameters retrieved from the server’s
- The guest receives the response from AWS.
The advantage to this topology is that you configure the host once instead of doing the configuration on each guest.
A prerequisite for this step is to open an AWS account. Amazon offers a free-tier account at AWS Free Tier. When you sign up for the account, be sure to generate an access key and a secret access key. (If you are using a shared corporate account, obtain the access key and a secret access key from the account administrator.)
Next, configure a connection from the host to an AWS service. The easiest way to ensure you have this connection is to install the AWS CLI. For information about installing the AWS CLI, see Installing or updating the latest version of the AWS CLI. After you finish installing the CLI, you have two files. The first file is a credentials file.
~/.aws/credentials with single profile [default]aws_access_key_id = AASSECRETKEY aws_secret_access_key = ASECRETACCESSKEY
Line 1 is the name of the profile. In some development environments, you may have more than one profile, such as default for your personal AWS account and corporate for your company’s AWS account, as in the following example.
~/.aws/credentials with single profile with multiple profiles [default]aws_access_key_id = MYSSECRETKEY aws_secret_access_key = MYSECRETACCESSKEY [corporate]aws_access_key_id = OURSSECRETKEY aws_secret_access_key = OURSECRETACCESSKEY
The second file is a configuration file. In most cases, it specifies the AWS region serving your commands.
~/.aws/config [default]region = us-east-1
In this step, you test the host’s connection with AWS.
aws sts get-caller-identity
This command returns your user ID, account number, and user ARN.
If you have multiple profiles, you can specify the required one at the command line.
aws sts get-caller-identity --profile=psd-corporate
As a best practice, simulate the specific calls you’ll be making from Brightspot to AWS because this helps to eliminate problems at the host level when diagnosing error messages. In these commands, ensure you use the role, topic, and queue identifiers that you will configure in Brightspot.
This section describes how to integrate AWS services into a Vagrant virtual machine. Integration with a Docker container is similar.
Ensure the Vagrant guest can reach the
~/.aws/credentials file on the host. Vagrant provides a synchronization facility to access this file. For details, see Synced Folders.
The best approach for using the host’s credentials is to assign them to AWS’s environment variables on the guest as described in the following table.
|Credentials file to use when sending commands to AWS. This file resides on the host, so ensure you configure the Vagrant guest to have access to this file.|
|Profile to use when sending commands to AWS. Depending on your development environment, you can define this statically when creating the Vagrant guest, or read it from a file on the host.|
|AWS region to use. Depending on your development environment, you can define this statically when creating the Vagrant guest, or read it from |
aws command looks for the values of these environment variables, and reverts to default values if these variables do not exist.
In the vast majority of production environments, media are stored on a cloud provider such as AWS. Similarly, most AWS services that you use in a development environment also require storing files in AWS buckets. For your development environment to store media on AWS buckets, you need to configure the following environment variables in Tomcat’s
For information about configuring these environment variables, see Storage item configuration.