@ -130,7 +140,7 @@ Our database servers should get more CPU and RAM, so we define to use a ``Large`
---
cs_offering: Large
The web servers should get a ``Small`` offering as we would scale them horizontaly, which is also our default offering.
The web servers should get a ``Small`` offering as we would scale them horizontally, which is also our default offering. We also ensure the known web ports are opened for the world.
..code-block:: yaml
@ -178,19 +188,18 @@ Now to the fun part. We create a playbook to create our infrastructure we call i
In the above play, we use the group ``cloud-vm``to handle all VMs in the cloud but use ``connetion=local`` because we want the modules to be executed locally.
In the above play we defined 3 tasks and use the group ``cloud-vm``as target to handle all VMs in the cloud but instead SSH to these VMs, we use ``connetion=local`` to execute the API calls locally from our workstation.
Note that for some modules, e.g. ``cs_sshkeypair`` you usually want this to be executed only once, not for every VM. Therefore you would make a separate play for this targeting localhost.
In the first task, we ensure we have a running VM created with the Debian template. If the VM is already created but stopped, it would just start it. If you like to change the offering on an exisiting VM, you must add ``force: yes`` to the task, which would stop the VM, change the offering and start the VM again.
..code-block:: yaml
In the second task we ensure the ports are opened if we give a public IP to the VM.
In the third task we add static NAT to the VMs having a public IP defined.
..Note:: The public IP addresses must have been acquired in advance, also see ``cs_ip_address``
..Note:: For some modules, e.g. ``cs_sshkeypair`` you usually want this to be executed only once, not for every VM. Therefore you would make a separate play for it targeting localhost. You find an example in the use cases below.
Use Case: Provisioning on a Basic Networking CloudStack setup