Amazon Web Services

The Amazon Web Services (AWS) provider manages multiple types of resources.

aws_ec2

AWS Instances can be provisioned using this resource.

Topology Schema

Within Linchpin, the aws_ec2 resource_definition has more options than what are shown in the examples above. For each aws_ec2 definition, the following options are available.

Parameter

required

type

ansible value

comments

role

true

string

N/A

name

true

string

instance_tags

name is set as an instance_tag value.

flavor

true

string

instance_type

image

true

string

image

region

false

string

region

count

false

integer

count

keypair

false

string

key_name

security_group

false

string / list

group

vpc_subnet_id

false

string

vpc_subnet_id

assign_public_ip

false

boolean

assign_public_ip

EC2 Inventory Generation

If an instance has a public IP attached, its hostname in public DNS, if available, will be provided in the generated Ansible inventory file, and if not the public IP address will be provided.

For instances which have a private IP address for VPC usage, the private IP address will be provided since private EC2 DNS hostnames (e.g. ip-10-0-0-1.ec2.internal) will not typically be resolvable outside of AWS.

For instances with both a public and private IP address, the public address is always provided instead of the private address, so as to avoid duplicate runs of Ansible on the same host via the generated inventory file.

aws_ec2_key

AWS SSH keys can be added using this resource.

Note

This resource will not be torn down during a destroy action. This is because other resources may depend on the now existing resource.

aws_s3

AWS Simple Storage Service buckets can be provisioned using this resource.

Note

This resource will not be torn down during a destroy action. This is because other resources may depend on the now existing resource.

aws_sg

AWS Security Groups can be provisioned using this resource.

Note

This resource will not be torn down during a destroy action. This is because other resources may depend on the now existing resource.

aws_ec2_eip

AWS EC2 elastic ips can be provisioned using this resource.

aws_ec2_vpc_net

AWS VPC networks can be provisioned using this resource.

>`_

aws_ec2_vpc_internet_gateway

Manage AWS VPC INTERNET Gateways. * :docs1.5:`Topology Example <workspace/topologies/aws-ec2-vpc-internet-gateway.yml>` * ec2_vpc_net module <https://docs.ansible.com/ansible/latest/modules/ec2_vpc_igw_module.html>

aws_ec2_vpc_subnet

AWS VPC subnets can be provisioned using this resource. * :docs1.5:`Topology Example <workspace/topologies/aws-ec2-vpc-subnet.yml>` * ec2_vpc_subnet module

aws_ec2_vpc_routetable

AWS VPC routetable can be provisioned using this resource. * :docs1.5:`Topology Example <workspace/topologies/aws-ec2-vpc-routetable.yml>` * ec2_vpc_route_table module

aws_ec2_vpc_endpoint

AWS VPC endpoint can be provisioned using this resource. * :docs1.5:`Topology Example <workspace/topologies/aws-ec2-vpc-endpoint.yml>` * ec2_vpc_endpoint module

aws_ec2_elb_lb

AWS EC2 elb lb load balancer can be provisioned using this resource. * :docs1.5:`Topology Example <workspace/topologies/aws-ec2-elb-lb.yml>` * ec2_vpc_endpoint module

Additional Dependencies

No additional dependencies are required for the AWS Provider.

Credentials Management

AWS provides several ways to provide credentials. LinchPin supports some of these methods for passing credentials for use with AWS resources.

One method to provide AWS credentials that can be loaded by LinchPin is to use the INI format that the AWS CLI tool uses.

Credentials File

An example credentials file may look like this for aws.

$ cat aws.key
[default]
aws_access_key_id=ARYA4IS3THE3NO7FACEB
aws_secret_access_key=0Hy3x899u93G3xXRkeZK444MITtfl668Bobbygls

[herlo_aws1_herlo]
aws_access_key_id=JON6SNOW8HAS7A3WOLF8
aws_secret_access_key=Te4cUl24FtBELL4blowSx9odd0eFp2Aq30+7tHx9

See also

Examples for all Providers for provider-specific credentials examples.

To use these credentials, the user must tell LinchPin two things. The first is which credentials to use. The second is where to find the credentials data.

Using Credentials

In the topology, a user can specific credentials. The credentials are described by specifying the file, then the profile. As shown above, the filename is ‘aws.key’. The user could pick either profile in that file.

---
topology_name: ec2-new
resource_groups:
  - resource_group_name: "aws"
    resource_group_type: "aws"
    resource_definitions:
      - name: demo-day
        flavor: m1.small
        role: aws_ec2
        region: us-east-1
        image: ami-984189e2
        count: 1
    credentials:
      filename: aws.key
      profile: default

The important part in the above topology is the credentials section. Adding credentials like this will look up, and use the credentials provided.

Credentials Location

By default, credential files are stored in the default_credentials_path, which is ~/.config/linchpin.

Hint

The default_credentials_path value uses the interpolated :dirs1.5:`default_config_path <workspace/linchpin.conf#L22>` value, and can be overridden in the :docs1.5:`linchpin.conf`.

The credentials path (or creds_path) can be overridden in two ways.

It can be passed in when running the linchpin command.

$ linchpin -vvv --creds-path /dir/to/creds up aws-ec2-new

Note

The aws.key file could be placed in the default_credentials_path. In that case passing --creds-path would be redundant.

Or it can be set as an environment variable.

$ export CREDS_PATH=/dir/to/creds
$ linchpin -v up aws-ec2-new

Environment Variables

LinchPin honors the AWS environment variables

Provisioning

Provisioning with credentials uses the --creds-path option.

$ linchpin -v --creds-path ~/.config/aws up

Alternatively, the credentials path can be set as an environment variable,

$ export CREDS_PATH="~/.config/aws"
$ linchpin -v up