fititnt / ap-application-load-balancer

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.
https://ap-application-load-balancer.etica.ai/
The Unlicense
1 stars 0 forks source link
ansible-role application-load-balancer letsencrypt load-balancer

AP Application Load Balancer - v0.9.0-beta

GitHub: fititnt/ap-application-load-balancer Website: ap-application-load-balancer.etica.ai

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.

asciicast

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

One line emoji explanation:

☺️ 🤖 :end: UFW (:1-65535) :end: HAProxy (:80, :443) :end: OpenResty (:8080, :4443 🔒) :end: App

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

  1. Have Ansible installed on some computer
    1. https://docs.ansible.com: Installation Guide
    2. 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
  2. Have at least one VPS or Bare metal VPS that can be controlled by your installation Ansible
  3. Have basic knowledge on how to use Ansible Playbooks
    1. https://docs.ansible.com: Working With Playbooks
    2. 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-folder roles/ap-application-load-balancer)

Complete examples using AP-ALB

Quickstart on how to hotfix/debug production servers

See debugging-quickstart.md.

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.

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

License

Public Domain

To the extent possible under law, Etica.AI has waived all copyright and related or neighboring rights to this work to Public Domain.