ap_application_load_balancer
AP Application Load Balancer - v0.9.0-beta
AP-ALB is not a single software, but Infrastructure As Code via Ansible Role to automate creation and maintance of with features common on expensive Application Load Balancer of some cloud providers (e.g. Alibaba, AWS, Azure, GCloud, IBM, etc). It can be used both to create your own ALB on cheaper hardware on these same cloud providers or have your own ALB on any other provider of VPSs or bare metal servers. And yes, it handle automatic HTTPS for you on-the-fly even for clusters of ALBs, like enterprise versions of Traefik or Caddyserver.
AP-ALB is flexible: you can either use dedicated very small VPSs with the role of load balancing to another services or replace your Apache/NGinx/HAproxy in each server with AP-ALB. Consider around just 64MB of RAM per node as baseline. (So, if you are deployng in a dedicated 1GB VPS, consider at least reuse the same node puting behind the AP-ALB one Varnish-Cache!)
New on v0.8: in addition to the single-node setup, you can now deploy 3-node High Available AP-ALB Cluster using Consul instead of local filesystem. We recommend using the Ansible Role brianshumate.consul for setup and manangement of Consul component. Examples can be found at fititnt/ansible-linux-ha-cluster.
Source code for this demo at https://github.com/fititnt/ansible-linux-ha-cluster/releases/tag/demo-003-ap-alb-v0.8.7-beta. The roles brianshumate.consul: v2.5.3, 2019-11-14 and githubixx.ansible_role_wireguard: v4.1.1, 2019-11-11 are not part of AP-ALB, but are used to show a demo of a cross-platform cluster.
- The Solution Stack of AP-ALB
- Quickstart Guide
- ALB components
- Advanced usage
- FAQ
- License
The Solution Stack of AP-ALB
One line emoji explanation:
☺️ 🤖 :end: UFW (:1-65535) :end: HAProxy (:80, :443) :end: OpenResty (:8080, :4443 🔒) :end: App
- Infrastructure as Code:
- Ansible 2.9+ (See: Ansibe documentation)
- Operational System:
- Debian Family
- Debian 10
- Ubuntu Server LTS 18.04
- RedHat Family
- CentOS 8, CentOS 7
- RHEL 8, RHEL 7
- Compatible, but some functionalities requires extra steps:
- Arch Linux
- BSD Family: FreeBSD 12
- SUSE Family: OpenSUSE 15
- Debian Family
- Firewall
- UFW
- With exception of FreeBSD (OS that not even as option can have UFW installed) other OSs listed as supported can work with UFW.
- UFW
- Load Balancing
- Automatic HTTPS
- The Apps/Rules configuration
See Advanced usage.
AP-ALB Goals
Content moved to docs/goals/index.md.
AP-ALB Non-Goals
Content moved to docs/goals/index.md.
Quickstart Guide
The minimum you already should know to use AP-ALB
Note: this guide assumes that you at least
- Have Ansible installed on some computer
- https://docs.ansible.com: Installation Guide
- Tip: if is your first time with Ansible, this computer is likely to be own computer and NOT the server where you want to install ALB
- Have at least one VPS or Bare metal VPS that can be controlled by your installation Ansible
- Have basic knowledge on how to use Ansible Playbooks
- https://docs.ansible.com: Working With Playbooks
- Hint:
ap-application-load-balancer
can be imported as a Ansible Role, but it is not released on Ansible Galaxy (it means you can copy some version of AP-ALB and place on sub-folderroles/ap-application-load-balancer
)
Complete examples using AP-ALB
Quickstart on how to hotfix/debug production servers
ALB components
Content moved to docs/component/index.md.
Advanced usage
Lua
Lua is fantastic language! Is actually easier to lean Lua and implement some advanced rules than push Apache/Nginx configurations too much.
- Learn Lua in 15 Minutes (text): http://tylerneylon.com/a/learn-lua/
- Learn Lua in an Hour (video): https://www.youtube.com/watch?v=S4eNl1rA1Ns
- Lua 5.1 short reference: http://lua-users.org/files/wiki_insecure/users/thomasl/luarefv51.pdf
- Lua Online compiler: https://repl.it/languages/lua
Tip: you very likely will use Lua 5.1, because is the supported version of LuaJIT (it means is faster and with more support).
ALB Internals
See ALB Internals (working draft).
Risk mitigation
"Layered security, also known as layered defense, describes the practice of combining multiple mitigating security controls to protect resources and data." — Layered security on Wikipedia
AP-ALB, as one Infrastructure as Code way to implement a single or a clustered servers to work as Application Load Balancers, is designed to work with aceptable risks without rely on some features that are not available on very cheap VPSs without enterprise features (like private networking, extra disks, snapshots) and still relatively sysadmin (user) friendly for what it is really doing. By extension, this also means it will work with mixed setups (e.g. some VPSs could be on expensive AWS, while others on other cloud providers, like Azure, or cheaper but very good ones, like Contabo).
Still use passwords for intra-cluster communications (We're looking at you, Redis, MongoDB...)
TL;DR: if a software support autentication with AP-ALB you SHOULD implement this layer of defence even if and 80% of guides on internet teach how to use without. This is not a strong requeriment if you is using AP-ALB inside the same region of cloud provider with support for private networking or you implement IPSec/OpenVPN, but even on this cases still better already have your services ready to expand and avoid human error with future misconfigurations.
Some softwares in special (like Redis and MongoDB) tend to have friendly guides that will work securely (securely as "from outside attacks, not from errors inside your network") without need of authentication. There are so many things that can go wrong that the overhead of performance the need of authentication and extra steps on your scripts are not plausible excuses.
Even if the AP-ALB does not manange your service on another VPS, you may eventually want to use HAProxy to load balance a service that is not on localhost, but on that VPS. And the easyers ways to do this are likely to go charlie-foxtrot.
Should you use private networkig from my cloud provider? Should you implement IPSec/OpenVPN?
TL;DR: not required, but is a good idea if you can.
If some of your hosts are on a cloud provider that you already have option to have extra firewalls or private networking inside the VPSs on that region, yes that's a good idea. You already paid, use it.
About implement IPSec/OpenVPN or equivalent to do Software-Defined Networking,
it's up to you, but since it can be not trivial to implement, we try to not
depent on this implementation. As ALB v0.8.0-alpha
we do not have Components
to automate creation of private network, but you could still use the
Shared options or do the initial setup without Ansible
automation.
Prefer guides that assume security requirements for geo-distributed applications
TL;DR: This last topic on Risk mitigation is for where you can find relevant information.
Do not assume same level of security of private networking and same datacenter: the averange guide on internet (in special the ones from cloud providers) will assume both cases and sometimes they are so resilient on this feature that will suggest no autentication at all for intra-cluster communication even when the underlines softwares allow and strongly encourage it's use.
One generic protip here is, when in doubt with guides, check the same guides but with "geo-distributed applications/replication" or "multicloud". Even if you do not implement IPSec or OpenVPN, the averagen guide on how to configure the applications will very likely to still rely on autentication for the apps that need to talk with each other.
FAQ
- Which version of AP-ALB should you use?
- Choose at ap-application-load-balancer/releases. You can use the master branch, but we recommend review new updates. ALB is meant to be used non-stop on production servers, so you can stick with some version or maintain your own private changes.
- How much overhead of RAM and CPU a server with AP-ALB have compared with
alternative NameOfAlternative?
- The overhead of HAProxy and OpenResty is low. Trust me.
- AP-ALB is mean to be installed just only on frontend servers that are exposed to
public IPs and then access internal servers?
- This use is just one of the cases (and the most intuitive compared to cloud ALBs)
- BUT you can also have, as example, both
- all-in-one (BothApplication/Network Load Balancer and some PHP/Python/Java/Etc servers) on a single machine or
- put AP-ALB servers behind AP-ALB servers.
- If AP-ALB could be installed "on everyting" it means even on database servers?
- If you are both your application server and database server are on same host, yes
- But if you have to choose betwen put a network load balancer (the HAProxy) or on the database(s) server(s) or on the application server(s) (the ones running PHP/Python/NodeJS/Java/Etc) put on you application servers.
License
To the extent possible under law, Etica.AI has waived all copyright and related or neighboring rights to this work to Public Domain.
AP Application Load Balancer (AP-ALB). Sophisticated monolithic Ansible role to manage standalone and clusters of cross-platform and multicloud load balancers. Abstract HAProxy + OpenResty + On-the-fly auto HTTPS. Dedicated to Public Domain.
ansible-galaxy install fititnt/ap-application-load-balancer