Introducing the Application Load Balancer
Last updated
Last updated
This installment is based largely upon the last, but instead of provisioning a Network Load Balancer, we introduce the Layer-4 Application Load Balancer (ALB), and its associated Target Groups and Forwarding Rules structures. (Their corresponding entries in our Ansible Module's documentation can be found here, here and here, respectively.)
Please note that, as both the NAT Gateway and the ALB require their own reserved IP address, your will need to be able to reserve at least two IP addresses (you can see how many 'reserved IP addresses' your contract is currently using and still able to reserve in the DCD under [Profile Icon] --> Resource Overview).
Also note: From docs.ionos.com/cloud/early-access/application-load-balancer:
The ALB is not configured to support Source NAT (SNAT). Therefore, targets cannot initiate network connections through the load balancer.
Each Application Load Balancer must have at least one Listener and supports up to 10 Listeners.
This example consists of the following files:
File | Description |
---|---|
| This playbook reserves an IP address block and creates a Cubes-based jumpbox and NAT Gateway (as per Example 6) |
| After retrieving the necessary information via the Cloud API, this playbook provisions one or more 'application servers' and an ALB, along with a rule that will forward incoming |
| This playbook runs on the app servers themselves to (amongst other things) install the NGINX web server and custom, host-specific |
| This playbook cleans up all of the resources provisioned in the previous parts, and should be run once you're done with the earlier parts |
| This file contains the variable definitions common to all of this example's individual playbooks |
| This file is common to all of our Ansible examples and contains a set of more generally-used variable definitions |
Note: As with all other 'executable' examples in this repository, an 'End User Licence Agreement'-like statement will be displayed, which must also be accepted before the tasks proper can be executed.
Please note that, while potentially quite minimal, you will incur charges for the resources based upon how long you keep them provisioned; for more information on the actual costs, you can follow the links displayed in the 'EULA' text. Also note that, if you run the following through to completion, the playbook should 'clean up' after itself, but we recommend you verify this, e.g., via the DCD or
ionosctl
to make sure you won't be charged for any unwanted resources.
To provision the jumpbox and NAT Gateway, run the following command:
To provision the application servers and the ALB, run the following command:
To configure the application servers that were provisioned in Step 2, run:
Optionally, examine the resources that were provisioned in Steps 1 and 2
Execute the following to delete the resources provisioned in the previous steps:
Between Steps 3 and 5, you can also run the following commands to access the various resources, directly and via the load balancer:
Command | Description |
---|---|
| ssh into the specified server, where |
| retrieve the |
If you get a name 'certificate_manager_sdk_version' is not defined
error message when working with the Application Load Balancer, make sure you have the appropriate module installed (this can be done by running the command pip install ionoscloud-cert-manager
)
Due to the way in which browsers tend to keep their TCP connections open for a period of time, you might need to wait for these connections to time out before reloading this URL (otherwise the ALB will connect you with the same internal server)...
In this tutorial, we saw examples of:
how the ionoscloudsdk.ionoscloud.application_load_balancer
, target_group
and application_load_balancer_forwardingrule
modules can be used to provision and configure an ALB; and
how we can verify that the ALB is forwarding incoming connections as expected (and how its behaviour differs from the NLB)