cmueller/ansible
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Merge pull request #12994 from resmo/for_ansible

Browse source 
doc: cloudstack guide fix up
This commit is contained in:
Brian Coca 2015-11-01 15:47:21 -05:00
commit 1dbde84337
1 changed files with 38 additions and 39 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

77
docsite/rst/guide_cloudstack.rst
View file

@ -7,26 +7,25 @@ Introduction
```````````` ````````````
The purpose of this section is to explain how to put Ansible modules together to use Ansible in a CloudStack context. You will find more usage examples in the details section of each module. The purpose of this section is to explain how to put Ansible modules together to use Ansible in a CloudStack context. You will find more usage examples in the details section of each module.
Ansible contains a number of core modules for interacting with CloudStack based clouds. All modules support check mode and are designed to use idempotence and have been created, tested and are maintained by the community. Ansible contains a number of extra modules for interacting with CloudStack based clouds. All modules support check mode and are designed to use idempotence and have been created, tested and are maintained by the community.
.. note:: Some of the modules will require domain admin or root admin priviledges. .. note:: Some of the modules will require domain admin or root admin privileges.
Prerequisites Prerequisites
````````````` `````````````
Prerequisites for using the CloudStack modules are minimal. In addition to ansible itself, all of the modules require the python library ``cs`` https://pypi.python.org/pypi/cs. Prerequisites for using the CloudStack modules are minimal. In addition to ansible itself, all of the modules require the python library ``cs`` https://pypi.python.org/pypi/cs.
You'll need this Python module installed on the execution host, usually your workstation. You'll need this Python module installed on the execution host, usually your workstation.
.. code-block:: bash .. code-block:: bash
$ pip install cs $ pip install cs
.. note:: cs also inludes a command line interface for ad-hoc ineraction with the CloudStack API e.g. ``$ cs listVirtualMachines state=Running``. .. note:: cs also includes a command line interface for ad-hoc ineraction with the CloudStack API e.g. ``$ cs listVirtualMachines state=Running``.
Credentials File Credentials File
```````````````` ````````````````
You can pass credentals and the endpoint of your cloud as module arguments, however in most cases it is You can pass credentials and the endpoint of your cloud as module arguments, however in most cases it is a far less work to store your credentials in the cloudstack.ini file.
a far less work to store your credentials in the cloudstack.ini file.
The python library cs looks for the credentials file in the following order (last one wins): The python library cs looks for the credentials file in the following order (last one wins):
@ -48,8 +47,7 @@ The structure of the ini file must look like this:
Regions Regions
``````` ```````
If you use more than one CloudStack region, you can define as many If you use more than one CloudStack region, you can define as many sections as you want and name them as you like, e.g.:
sections as you want and name them as you like, e.g.:
.. code-block:: bash .. code-block:: bash
@ -60,26 +58,26 @@ sections as you want and name them as you like, e.g.:
secret = api secret secret = api secret
[exmaple_cloud_one] [exmaple_cloud_one]
endpoint = https://cloud.example.com/client/api endpoint = https://cloud-one.example.com/client/api
key = api key key = api key
secret = api secret secret = api secret
[exmaple_cloud_two] [exmaple_cloud_two]
endpoint = https://cloud.example.com/client/api endpoint = https://cloud-two.example.com/client/api
key = api key key = api key
secret = api secret secret = api secret
.. Hint:: Of course this can also be used to for login into the same region using different accounts.
By passing the argument ``api_region`` with the cloudstack modules, the region wanted will be selected. .. Hint:: Sections can also be used to for login into the same region using different accounts.
By passing the argument ``api_region`` with the CloudStack modules, the region wanted will be selected.
.. code-block:: yaml .. code-block:: yaml
- name: ensure my ssh pubkey exists on all cloudstack regions - name: ensure my ssh pubkey exists on all CloudStack regions
local_action: cs_sshkeypair local_action: cs_sshkeypair
name: my-ssh-key name: my-ssh-key
public_key: '{{ lookup('file', '~/.ssh/id_rsa.pub') }}' public_key: "{{ lookup('file', '~/.ssh/id_rsa.pub') }}"
api_region: '{{ item }}' api_region: "{{ item }}"
with_items: with_items:
- exoscale - exoscale
- exmaple_cloud_one - exmaple_cloud_one
@ -87,9 +85,9 @@ By passing the argument ``api_region`` with the cloudstack modules, the region w
Use Cases Use Cases
````````` `````````
The follwoing should give you some ideas how to use the modules to provision VMs to the cloud. As always, there isn't only one way to do it. But as always: keep it simple for the beginning is always a good start. The following should give you some ideas how to use the modules to provision VMs to the cloud. As always, there isn't only one way to do it. But as always: keep it simple for the beginning is always a good start.
Use Case: Provisoning in a Advanced Networking CloudStack setup Use Case: Provisioning in a Advanced Networking CloudStack setup
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Our CloudStack cloud has an advanced networking setup, we would like to provision web servers, which get a static NAT and open firewall ports 80 and 443. Further we provision database servers, to which we do not give any access to. For accessing the VMs by SSH we use a SSH jump host. Our CloudStack cloud has an advanced networking setup, we would like to provision web servers, which get a static NAT and open firewall ports 80 and 443. Further we provision database servers, to which we do not give any access to. For accessing the VMs by SSH we use a SSH jump host.
@ -117,10 +115,6 @@ As you can see, the public IPs for our web servers and jumphost has been assigne
The configure the jumphost, web servers and database servers, we use ``group_vars``. The ``group_vars`` directory contains 4 files for configuration of the groups: cloud-vm, jumphost, webserver and db-server. The cloud-vm is there for specifing the defaults of our cloud infrastructure. The configure the jumphost, web servers and database servers, we use ``group_vars``. The ``group_vars`` directory contains 4 files for configuration of the groups: cloud-vm, jumphost, webserver and db-server. The cloud-vm is there for specifing the defaults of our cloud infrastructure.
Our database servers should get more CPU and RAM, so we define to use a ``Large`` offering for them. The web servers should get a ``Small offering`` as we would scale them horizontaly, which is also our default offering.
Futher we provision a jump host which has only port 22 opened for accessing the VMs from our office IPv4 network.
.. code-block:: yaml .. code-block:: yaml
# file: group_vars/cloud-vm # file: group_vars/cloud-vm
@ -128,12 +122,7 @@ Futher we provision a jump host which has only port 22 opened for accessing the
cs_offering: Small cs_offering: Small
cs_firewall: [] cs_firewall: []
.. code-block:: yaml Our database servers should get more CPU and RAM, so we define to use a ``Large`` offering for them.
# file: group_vars/jumphost
---
cs_firewall:
- { port: 22, cidr: "17.17.17.0/24" }
.. code-block:: yaml .. code-block:: yaml
@ -141,14 +130,25 @@ Futher we provision a jump host which has only port 22 opened for accessing the
--- ---
cs_offering: Large cs_offering: Large
The web servers should get a ``Small`` offering as we would scale them horizontaly, which is also our default offering.
.. code-block:: yaml .. code-block:: yaml
# file: group_vars/webserver # file: group_vars/webserver
--- ---
cs_firewall: cs_firewall:
- { port: 80 } - { port: 80 }
- { port: 443 } - { port: 443 }
Further we provision a jump host which has only port 22 opened for accessing the VMs from our office IPv4 network.
.. code-block:: yaml
# file: group_vars/jumphost
---
cs_firewall:
- { port: 22, cidr: "17.17.17.0/24" }
Now to the fun part. We create a playbook to create our infrastructure we call it ``infra.yml``: Now to the fun part. We create a playbook to create our infrastructure we call it ``infra.yml``:
.. code-block:: yaml .. code-block:: yaml
@ -163,7 +163,6 @@ Now to the fun part. We create a playbook to create our infrastructure we call i
cs_instance: cs_instance:
name: "{{ inventory_hostname_short }}" name: "{{ inventory_hostname_short }}"
template: Linux Debian 7 64-bit 20GB Disk template: Linux Debian 7 64-bit 20GB Disk
service_offering: "{{ cs_offering }}" service_offering: "{{ cs_offering }}"
state: running state: running
@ -174,7 +173,7 @@ Now to the fun part. We create a playbook to create our infrastructure we call i
cidr: "{{ item.cidr | default('0.0.0.0/0') }}" cidr: "{{ item.cidr | default('0.0.0.0/0') }}"
with_items: cs_firewall with_items: cs_firewall
when: public_ip is defined when: public_ip is defined
- name: ensure static NATs - name: ensure static NATs
cs_staticnat: vm="{{ inventory_hostname_short }}" ip_address="{{ public_ip }}" cs_staticnat: vm="{{ inventory_hostname_short }}" ip_address="{{ public_ip }}"
when: public_ip is defined when: public_ip is defined
@ -240,14 +239,14 @@ The playbook looks like the following:
cs_sshkeypair: cs_sshkeypair:
name: defaultkey name: defaultkey
public_key: "{{ lookup('file', '~/.ssh/id_rsa.pub') }}" public_key: "{{ lookup('file', '~/.ssh/id_rsa.pub') }}"
- name: ensure security groups exist - name: ensure security groups exist
cs_securitygroup: cs_securitygroup:
name: "{{ item }}" name: "{{ item }}"
with_items: with_items:
- default - default
- web - web
- name: add inbound SSH to security group default - name: add inbound SSH to security group default
cs_securitygroup_rule: cs_securitygroup_rule:
security_group: default security_group: default
@ -255,8 +254,8 @@ The playbook looks like the following:
end_port: "{{ item }}" end_port: "{{ item }}"
with_items: with_items:
- 22 - 22
- name: add inbound TCP rules to security group search - name: add inbound TCP rules to security group web
cs_securitygroup_rule: cs_securitygroup_rule:
security_group: web security_group: web
start_port: "{{ item }}" start_port: "{{ item }}"
@ -281,7 +280,7 @@ The playbook looks like the following:
- name: show VM IP - name: show VM IP
debug: msg="VM {{ inventory_hostname }} {{ vm.default_ip }}" debug: msg="VM {{ inventory_hostname }} {{ vm.default_ip }}"
- name: assing IP to the inventory - name: assing IP to the inventory
set_fact: ansible_ssh_host={{ vm.default_ip }} set_fact: ansible_ssh_host={{ vm.default_ip }}
@ -290,4 +289,4 @@ The playbook looks like the following:
In the first play we setup the security groups, in the second play the VMs will created be assigned to these groups. Further you see, that we assign the public IP returned from the modules to the host inventory. This is needed as we do not know the IPs we will get in advance. In a next step you would configure the DNS servers with these IPs for accassing the VMs with their DNS name. In the first play we setup the security groups, in the second play the VMs will created be assigned to these groups. Further you see, that we assign the public IP returned from the modules to the host inventory. This is needed as we do not know the IPs we will get in advance. In a next step you would configure the DNS servers with these IPs for accassing the VMs with their DNS name.
In the last task we wait for SSH to be accessable, so any later play would be able to access the VM by SSH without failure. In the last task we wait for SSH to be accessible, so any later play would be able to access the VM by SSH without failure.