Vi vill visa dig hur du använder HAProxy och Hashicorp Consul för skojs skull och vinst. Du kan till och med lägga till en lättviktig orchestrator ovanpå, för bättre smak (för detta kommer vi att använda Nomad , ett lättviktigt alternativ till Kubernetes).
Utgångspunkten är två blogginlägg på HAProxy och Hashicorp webbplatser:
Vårt scenario omfattar att köra maskiner med tjänster som httpd (apache, nginx), databastjänster eller något annat som kan nås av HAProxy. Du kan köra dina maskiner på bare-metal, på AWS EC2, Google Cloud, Hetzner, containrar. Det är mycket flexibelt och lätt att förstå. Hela konfigurationen kommer att vara större än summan av delarna!
För att förenkla saker och ting i det här blogginlägget kommer vi att köra allt lokalt med Docker -containrar, med den extra finessen att vi använderPodman – en alternativ docker -implementering som utan problem klarar av att köra systemd inuti containrar – så att vi enkelt kan simulera ”riktiga” maskiner som kör flera tjänster. I vårt fall vill vi köra Consul-agenten och Apache-webbservern på varje maskin.
Låt oss börja med Consul-serverkonfigurationen. Vi kommer att göra den tillgänglig för Podman-standardnätverket för containrar (10.88.0.0/16). Detta är en konfiguration med en enda nod, inget särskilt avanceradt.
konsul.hcl:
datacenter = "haproxy" server = true data_dir = "/var/lib/consul/" bind_addr = "10.88.0.1" client_addr = "127.0.0.1" bootstrap = true bootstrap_expect = 1 enable_syslog = true log_level = "INFO"Observera att detta förväntar sig att Podmans standardbryggnätverk körs, så Consul kan binda till 10.88.0.1 (dvs. du bör redan ha minst en container igång).
Installationen är ganska enkel, vi har använt Fedoras basavbildning, eftersom den har systemd stöd direkt ur lådan:
FROM fedora
RUN dnf -y install yum-utils; \\
dnf config-manager --add-repo <https://rpm.releases.hashicorp.com/fedora/hashicorp.repo>; \\
dnf -y install httpd consul; \\
dnf clean all; \\
systemctl enable httpd; \\
systemctl enable consul
COPY consul.json http_service.json /etc/consul.d/
EXPOSE 80
CMD [ "/sbin/init" ]Klientens konsulkonfiguration är två filer, en för själva konsuln och en för den exponerade tjänsten, i JSON-format, så vi blandar det inte med serverkonfigurationen:
konsul.json
{
"server": false,
"datacenter": "haproxy",
"log_level": "INFO",
"enable_syslog": true,
"leave_on_terminate": true,
"start_join": ["10.88.0.1"]
}http_service.json
{
"service": {
"name": "http",
"port": 80
}
}Vi kan nu starta två maskiner med podman kör -ti httpd och kontrollera läget med konsuln:
$ consul members
Node Address Status Type Build Protocol DC Partition Segment
xxxxxxx 10.88.0.1:8301 alive server 1.12.2 2 haproxy default <all>
193a0e634f9a 10.88.0.20:8301 alive client 1.12.2 2 haproxy default <default>
d1da0f13c496 10.88.0.19:8301 alive client 1.12.2 2 haproxy default <default>
$ dig @127.0.0.1 -p 8600 http.service.haproxy.consul. SRV
...
;; QUESTION SECTION:
;http.service.haproxy.consul. IN SRV
;; ANSWER SECTION:
http.service.haproxy.consul. 0 IN SRV 1 1 80 d1da0f13c496.node.haproxy.consul.
http.service.haproxy.consul. 0 IN SRV 1 1 80 193a0e634f9a.node.haproxy.consul.
;; ADDITIONAL SECTION:
d1da0f13c496.node.haproxy.consul. 0 IN A 10.88.0.19
d1da0f13c496.node.haproxy.consul. 0 IN TXT "consul-network-segment="
193a0e634f9a.node.haproxy.consul. 0 IN A 10.88.0.20
193a0e634f9a.node.haproxy.consul. 0 IN TXT "consul-network-segment="Bra, Consul körs som en DNS-resolver och exponerar alla maskiner med registrerade http-tjänster. Den exporterar till och med SRV-poster, så vår tjänst behöver egentligen inte vara på fördefinierade/privilegierade portar (80/443). För det här testet har vi dock använt standardport 80 från Fedora Apache-paketet.
HAProxy-konfiguration är trivial, särskilt om du känner till upplösare:
resolvers consul nameserver consul 127.0.0.1:8600 accepted_payload_size 8192 hold valid 5s listen apache_ice_cream bind :8080 balance roundrobin server-template apache 1-10 _http._tcp.service.consul resolvers consul resolve-opts allow-dup-ip resolve-prefer ipv4 checkDetta kan ge plats för upp till 10 driftsatta servrar, alla registrerade via Consul. Vi använder _TJÄNSTNAMN._tcp.tjänst.konsult som ett generiskt sätt att få exponerad tjänst, oberoende av Consul-klusternamn.
Nomad-tjänstkonfiguration, config.hcl:
client {
enabled = true
}
server {
enabled = true
bootstrap_expect = 1
}
datacenter = "haproxy"
name = "nomad01"
plugin "nomad-driver-podman" {
config {
socket_path = "unix://run/podman/podman.sock"
}
}Apache-jobbkonfiguration, apache.nomad:
job "apache" {
datacenters = ["haproxy"]
type = "service"
group "web" {
task "httpd" {
driver = "podman"
config {
image = "docker://docker.io/library/httpd:latest"
init = false
}
resources {
cpu = 2000
memory = 1024
}
}
}
}Låt oss köra några nomadkommandon för att starta den första och ytterligare containrar:
nomad job start apache.nomad ## detta startar vår första container nomad job scale apache web 2 ## skala grupp med en annan containerOch vi kan se felsökningsutdata i HAProxy
apache_ice_cream/apache1 ändrade sin IP-adress från (none) till 10.88.0.40 via ytterligare DNS-post. apache_ice_cream/apache1 ändrade sitt FQDN från (null) till f45addea6709.node.haproxy.consul via 'SRV-post' [VARNING] (30077): Servern apache_ice_cream/apache1 ('f45addea6709.node.haproxy.consul') är UPPTAGEN/KLAR (löses igen). Servern apache_ice_cream/apache1 ('f45addea6709.node.haproxy.consul') är UPPTAGEN/KLAR (löses igen). [VARNING] (30077): apache_ice_cream/apache2 ändrade sin IP-adress från (none) till 10.88.0.41 via ytterligare DNS-post. apache_ice_cream/apache2 ändrade sin IP från (none) till 10.88.0.41 via ytterligare DNS-post. apache_ice_cream/apache2 ändrade sitt FQDN från (null) till acea6eeb1aa9.node.haproxy.consul via 'SRV-post' [VARNING] (30077): Servern apache_ice_cream/apache2 ('acea6eeb1aa9.node.haproxy.consul') är UPPTAGEN/KLAR (löses igen). Servern apache_ice_cream/apache2 ('acea6eeb1aa9.node.haproxy.consul') är UPPTAGEN/KLAR (löses igen).Det här Nomad-exemplet är lite längre än andra, per aspera ad astra . Det är en liten demonstration av att du inte behöver Kubernetes skalningskomplikationer (ordvits avsedd) för att skapa något relativt enkelt, flexibelt, skalbart och hanterbart:
Essän om Service Discovery-glass är en del av en serie "recept" som utforskar sätt att bygga tillförlitliga applikationer med (HA)Proxy.PS. Om du har några frågor om någon av ovanstående tankar är du välkommen att dela dem i kommentarsfältet. Klicka här för att läsa del 5 .: Belgisk OLAP-kub — Vänd på steken vid fel med shards