idealista / aws_cloudmap_role

A role for managing services and instances in AWS Cloud Map service

Aws Cloudmap Ansible role

This ansible role uses aws-cli to manage instances in Aws Cloudmap services. It has been tested for the following Debian versions:

• Buster
• Bullseye

This role has been generated using the cookiecutter tool, you can generate a similar role that fits your needs using the this cookiecutter template.

• Getting Started
  • Prerequisities
  • Installing
• Usage
  • Using Access Keys
• Testing
• Built With
• Versioning
• Authors
• License
• Contributing

Getting Started

These instructions will get you a copy of the role for your Ansible playbook. Once launched, it will install Aws Cloudmap in a Debian system.

Prerequisities

Ansible 5.2.0 version installed.

Molecule 3.x.x version installed.

For testing purposes, Molecule with Docker as driver and Goss as verifier.

Installing

Create or add to your roles dependency file (e.g requirements.yml):

- src: idealista.aws_cloudmap_role
  version: x.x.x
  name: aws_cloudmap
  scp: git

Install the role with ansible-galaxy command:

ansible-galaxy install -p roles -r requirements.yml -f

Use in a playbook:

---

- hosts: someserver
  roles:
    - role: aws_cloudmap_role

Usage

This role does not implement all the features provided by the AWS Cloud Map service and, for now, only manages the creation of HTTP services without health checks, as well as the registration/deregistration of instances with a custom list of attributes. Service removal is not implemented due to the shared nature of the use of Cloud Map, which means that some newly created services could be used by other teammates.

An existing namespace must exist prior to running it.

Look at the defaults/main.yml file to see the possible configuration properties.

AWS credentials will be needed for using this role. If you are running it inside an EC2 instance with a correct IAM Role attached, odds are it will work flawlessly. If not, you will have to set some variables as stated in the Using Access Keys section to first create the ~/.aws/credentials file.

Overall, the most important variable is aws_cloudmap_instances, which can be configured like this:

---

aws_cloudmap_instances:
  - instance_name: "my-instance"
    service_name: "node-exporter"
    action: "register"
    attributes:
      AWS_INSTANCE_IPV4: "127.0.0.1"  # Real ip of the host/endpoint specified in the 'instance_name' key
      AWS_INSTANCE_PORT: "9100"
      custom_attribute: "custom_value"

Action could be register or deregister, and it will do exactly what you think: register or deregister the instance_name "my-instance" in the service_name "node-exporter".

Using Access Keys

For using access keys you can set the following variables:

• aws_cloudmap_profile (mandatory)
• aws_cloudmap_access_key_id (mandatory)
• aws_cloudmap_secret_access_key (mandatory)
• aws_cloudmap_session_token (optional)

By enabling aws_cloudmap_set_credentials, the file ~/.aws/credentials will be created and populated with the access keys, allowing the role to connect to other regions and/or accounts.

Testing

Install dependencies

$ pipenv sync

For more information read the pipenv docs.

Testing

$ pipenv run molecule test 

You can run tests with real AWS credentials and variables by editing the file molecule/default/group_vars/aws_cloudmap_group/main.yml. Take a look at it to see some useful examples.

Built With

Versioning

For the versions available, see the tags on this repository.

Additionaly you can see what change in each version in the CHANGELOG.md file.

Authors

• Idealista - Work with - idealista

See also the list of contributors who participated in this project.

License

This project is licensed under the Apache 2.0 license - see the LICENSE file for details.

Contributing

Please read CONTRIBUTING.md for details on our code of conduct, and the process for submitting pull requests to us.