redhat-cip / ansible-cloud

A repository that demoes how all the ansible-cloud roles works together

Ansible Cloud

The purpose of this project is to offer a variety of roles to accomplish action on Clouds, no matter who the cloud provider is.

Most often than not, we generally do the same actions on cloud platforms, no matter who the provider is. For example: upload an ssh key, boot a server, create security groups, ...

Ansible provides many provider-specific modules to accomplish those tasks. The idea here is to provide generic roles so one can write a playbook once and run it on every supported cloud providers.

• The idea behind ansible-cloud
• How does it work
• Matrix of provider supported resources
• Provider specific requirements
  • Amazon
  • Digial Ocean
  • OpenStack
  • Vultr
• License
• Authors

The idea behind ansible-cloud

Most people use Ansible to configure their applications stacks. They usually do that on pre-spawned infrastructure. Ansible provide cloud-provider specific modules for one to manage its infrastructure the same way she manages her application stack.

ansible-cloud goes a step further, and offers generic roles rather than cloud-provider specific modules, for one to describe its infrastructure and spawn it in every ansible-cloud supported provider. Trying to get to the meta: write it once, run it everywhere - and making hybrid cloud a reality.

How does it work?

ansible-cloud provides a generic cloud.yml playbook that should remain untouched. Everything is data-driven and should happen in a variable files, where one would describe its infrastructure. Cloud specific values like flavor, regions, ... are maintained by ansible-cloud for each cloud provider. One can find them in inventory/host_vars/<provider>.

This is a sample of a variable file:

sshkeys:
  - name: wordpress-user
    content: 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC+ZFQv3MyjtL1BMpSA0o0gIkzLVVC711rthT29hBNeORdNowQ7FSvVWUdAbTq00U7Xzak1ANIYLJyn+0r7olsdG4XEiUR0dqgC99kbT/QhY5mLe5lpl7JUjW9ctn00hNmt+TswpatCKWPNwdeAJT2ERynZaqPobENgvIq7jfOFWQIVew7qFeZygxsPVn36EUr2Cdq7Nb7U0XFXh3x1p0v0+MbL4tiJwPlMAGvFTKIMt+EaA+AsRIxiOo9CMk5ZuOl9pT8h5vNuEOcvS0qx4v44EAD2VOsCVCcrPNMcpuSzZP8dRTGU9wRREAWXngD0Zq9YJMH38VTxHiskoBw1NnPz [e-mail]'
    region: '{{ region }}'

networks:
  - name: wordpress
    cidr: 192.168.44.0/24
    region: '{{ region }}'

securitygroups:
  - name: http
    region: '{{ region }}'
    network: wordpress
    rules:
      - cidr_ip: 0.0.0.0/0
        proto: tcp
        from_port: 80
        to_port: 81
      - cidr_ip: 0.0.0.0/0
        proto: tcp
        from_port: 443
        to_port: 444

  - name: prod
    region: '{{ region }}'
    network: wordpress
    rules:
      - cidr_ip: 0.0.0.0/0
        proto: tcp
        from_port: 22
        to_port: 23

  - name: db
    region: '{{ region }}'
    network: wordpress
    rules:
      - cidr_ip: 0.0.0.0/0
        proto: tcp
        from_port: 5432
        to_port: 5432

servers:
  - name: wordpress-api
    sshkey: wordpress-user
    image: '{{ server_image }}'
    region: '{{ server_region }}'
    flavor: '{{ server_flavor }}'
    network: wordpress
    security_groups:
      - http
      - prod

  - name: wordpress-db
    sshkey: wordpress-user
    image: '{{ server_image }}'
    region: '{{ server_region }}'
    flavor: '{{ server_flavor }}'
    network: wordpress
    security_groups:
      - db
      - prod

The above file describes what my cloud infrastructure should look like.

To deploy that on "the cloud", one would run the following command:

#> ANSIBLE_CLOUD_PROVIDER=openstack ansible-playbook -i inventory/hosts cloud.yml -e @topology/mytopology.yml

Here openstack has been specified, but one could replace it by vultr, amazon or any other supported cloud platform. Each provider has a minimum set of requirements one can find in the Provider specific requirements section.

Once the infrastructure is deployed, a user can rely on dynamic inventories to provision their application stack on the proper nodes. In the above scenario a server called 'web' has been spawned, it seems fairly reasonable that the following play could apply:

- hosts: web
  roles:
    - httpd

This is how a user could deploy this play using dynamic inventories:

#> ansible-playbook -i inventory/openstack.py play.yml

Summary

With the following two commands, a user should be able to deploy its infrastructure (including application stack) on any ansible-cloud supported cloud, making hybrid cloud a reality.

## Deploying the infrastructure
#> ANSIBLE_CLOUD_PROVIDER=provider ansible-playbook -i inventory/hosts cloud.yml -e @topology/mytopology.yml

## Deploying the application stack
#> ansible-playbook -i inventory/provider.py application.yml

Matrix of provider supported resources

	Vultr	Digital Ocean	OpenStack	Amazon
cloud-firewallrule	OK	-	OK	-
cloud-network	-	-	OK	OK
cloud-securitygroup	OK	-	OK	OK
cloud-server	OK	-	OK	OK
cloud-sshkey	OK	OK	OK	OK
cloud-volume	-	OK	OK	-

Provider specific requirements

Amazon

Global variable: ansible_cloud_provider: amazon

(Required) Environment variables:

• AWS_ACCESS_KEY
• AWS_SECRET_KEY

If the cloud provider is Amazon, one needs to have the boto and boto3 python modules installed on the controller.

Digital Ocean

Global variable: ansible_cloud_provider: digitalocean

(Required) Environment variables:

• DO_API_KEY

OpenStack

Global variable: ansible_cloud_provider: openstack

(Required) Environment variables:

• OS_USERNAME
• OS_PASSWORD
• OS_AUTH_URL
• OS_TENANT_NAME

If the cloud provider is OpenStack, one needs to have the openstacksdk python module installed on the controller.

Vultr

Global variable: ansible_cloud_provider: vultr

(Required) Environment variables:

• VULTR_API_KEY

License

Apache 2.0

Authors Information

• Ricardo Carrillo Cruz [e-mail]
• Yanis Guenane [e-mail]