Den här lösningen är väldigt behaglig för ögonen (och magen) och ganska användbar. Du kan både ha kakan och äta den! Starta bara HAProxy inuti en docker -container, där HAProxy kommer att fungera som proxy för trafiken och logga till stdout. Dessutom kan HAProxy starta och övervaka ytterligare processer, så du slipper ta till krångliga knep för att starta flera processer i containern.
global log stdout format raw local0 debug defaults log global mode http option httplog clf option dontlognull option httpchk default-server check inter 5s fall 5 downinter 1s rise 2 timeout connect 5s timeout client 10s timeout server 10s timeout http-request 1s listen myapp bind :8080 option httpchk GET / server srv1 127.0.0.1:8081 check program myserver command /usr/bin/python3 -m http.server 8081Docker Filen är inte särskilt komplicerad, vi ser bara till att installera den senaste stabila versionen av HAProxy från back-ports (vanliga HAProxy-paket för Debian/Ubuntu, back-ports och det privata PPA-arkivet sköts avsamma person – tack, Vincent!).
FROM debian:bullseye
RUN export DEBIAN_FRONTEND=noninteractive && \\
echo 'deb <http://deb.debian.org/debian> bullseye-backports main' > \\
/etc/apt/sources.list.d/backports.list && \\
apt-get update -y && \\
apt-get install -y -t bullseye-backports haproxy && \\
apt-get install -y python3
COPY haproxy.conf /etc/haproxy/haproxy.cfg
CMD haproxy -W -db -f /etc/haproxy/haproxy.cfgVi har instruerat HAProxy att starta i förgrunds- och master-worker-läge, så att den kan starta/starta om andra program . Detta undviker slumpmässiga hackningar som är nödvändiga när du vill starta flera processer i containern. HAProxy kan skicka UNIX-signaler vid omladdning till ditt program, men den kommer inte att starta om ett kraschat program (den kommer dock att logga händelsen). Om du verkligen behöver omstarter kan du prova catatonit , ett lämpligt minimalt init-system för containrar, eller till och med köra med Podman, som har stöd för att köra systemd inuti containern.
I molnmiljöer behöver man ofta kommunicera med andra tjänster med hjälp av tjänstens DNS-namn. En vanlig fallgrop är att sådana DNS-poster har mycket kort TTL och lätt kan ändras. Är din applikation redo för en sådan miljö? Behöver du starta om den, har du kod som hanterar DNS-grejer? HAProxy till undsättning. Låt oss föreställa oss att du kör din tjänst i AWS-molnet:
resolvers aws
nameserver aws_local 169.254.169.253:53
hold valid 60s
listen myservice
http-request set-header Host %[env(MYSERVICE_HOST)]
bind 127.0.0.1:8081
server srv1 "${MYSERVICE_HOST}":443 ssl verify none check resolvers aws resolve-prefer ipv4169.254.169.253:53 är AWS DNS-resolver, i det reserverade IP-blocket, alltid tillgänglig för dina applikationer. Vi har instruerat HAProxy att köra DNS-resolver åt oss och cachelagra resultaten i 60 sekunder. Vår applikation behöver inte och bör inte göra någon DNS-resolvering på egen hand. Den bör bara ansluta till omvärlden via HAProxy.
Vi hårdkodade inte DNS-namnet på tjänsten, det är specificerat i exekveringsmiljön (t.ex. fungerar det på bara EC2-maskiner, men även på ECS/EKS). För att vara på den säkra sidan har vi satt Host-headern, så vår applikation behöver inte veta något om tjänsten, den behöver bara ansluta till localhost, port 8081 (dvs. vi kan routa många appar bara genom att mappa portnummer).
Kakan Docker Cake + Say my name är en del av en serie ”recept” som utforskar olika sätt att bygga tillförlitliga applikationer med (HA)Proxy.PS. Om du har några frågor om något av de ovan beskrivna tankegångarna är du välkommen att dela med dig av dem i kommentarsfältet. Klicka här för att läsa del 4:Service Discovery Ice cream — Den långa och krokiga vägen till K8s