Docker i.c.m. haproxy (meerdere instanties op een host)

[loewie1984]

Ik ben nieuw met Docker en de concepten en principes over hoe Docker werkt. Momenteel onderzoek ik hoe we RDP load balancing op basis van haproxy kunnen benutten.

Ik ben erin geslaagd docker op CentOS werkend te krijgen en haproxy met rdp load balancing aan de hand van "least connections" te laten werken met een geldige haproxy.cfg op basis van een enkele haproxy-instantie.

Om gebruik te maken van zogenaamde "stick tables" om de haproxy-functie als rdp / rds-connection broker te kunnen gebruiken, zijn echter ten minste twee hapee-peers nodig. Zie het haproxy.cfg-voorbeeld van haproxy zelf:

• Met connection broker: https://www.haproxy.com/d...esktop/connection-broker/
• Zonder connection broker: (waar haproxy dit deel met behulp van twee haproxy-peers en een stick-tabel vervult) https://www.haproxy.com/d...ithout-connection-broker/

Nu is mijn vraag: hoe krijg ik twee exemplaren van haproxy op een enkele docker-host?

Ik probeer de concepten en verschillen tussen de volgende scenario's te begrijpen:

1. Voer haproxy uit in een swarm met docker compose (dit repliceert / laadt een enkele container image in load balancing)
2. Voer haproxy-image twee keer uit, elk in hun eigen container met gebonden poorten 80, 443, 3389 en 9001 (maar wanneer ik dit probeer, krijg ik de melding bij de tweede container dat poorten gebonden op 0.0.0.0:port al in gebruik zijn door de eerste container)
3. Voer haproxy uit op een enkele host met twee netwerkadapters of virtuele netwerkadapters
4. Voer twee docker-hosts uit met elke container van de docker-haproxy-afbeelding (waarvan ik denk dat het gebruik van de docker volledig teniet wordt gedaan)

Idealiter is de architectuur van een redundante haproxy-configuratie met rdp loadbalancing gebaseerd

1. virtuele front-end ip. De ip-clients zullen verbinding maken met deze ip
2. De twee instanties van de loadbalancer die elk naar deze virtuele ip luisteren
3. De twee instanties die de sticktabel bij elkaar hielden om de rdp-sessies te hebben verbroken, hervatte met de host waarmee de client was verbonden

Dus mijn vraag is tweeledig:

1. hoe maak / configureer ik de docker en het docker-netwerk?
2. hoe interpreteer ik het configuratiebestand van haproxy?

Ik heb de vraag ook uitgezet bij onze jongens van stackoverflow, maar tot dusver nog geen reactie gehad.

[Anoniem: 160587]

https://www.haproxy.com/b...nd-dns-service-discovery/

Volgens mij beantwoord dat al je vragen. Eerste hit op Google bij "docker swarm haproxy", wel vraag ik mij af wat je bedoelt met "hoe interpreteer ik het configuratiebestand van haproxy?".

Daarbij als je Docker Swarm gebruikt gebruik je normaal meerdere machines die allemaal hosts zijn, het nut van een load balanced service op 1 fysieke machine draaien is er niet. Want als die fysieke machine plat gaat dan zijn je beide services dus plat.

Note: Nooit met Docker Swarm gewerkt maar ik werk dagelijks met Kubernetes en naar mijn kennis werkt Swarm ongeveer het zelfde als in dat je meerdere fysieke bakken in een pool hebt.

[Voor 14% gewijzigd door Anoniem: 160587 op 12-11-2019 10:37]

[loewie1984]

@Anoniem: 160587 allereerst dank voor je reactie.

Het concept van een swarm is volgens mij dat een image meerdere malen wordt opgestart met dezelfde configuratie parameters. Ik kan haproxy 1 keer draaien of 100 keer draaien met 1 haproxy.cfg, als ik hem 1 keer draai en hij crashed dan is haproxy onbereikbaar, als ik hem 100 keer draain en 1 crashed, heb ik nog 99 identieke instanties over.

Dat is niet waar ik naar op zoek ben.
Haproxy beschrijft zelf dat als je gebruik wilt maken van haproxy met rds connection broker dat je tenminste twee haproxy peers nodig hebt (zie ook het voorbeeld wat ik aanhaal in de link) een swarm is x aantal keer van 1 peer. Maar ik heb dus 2 peers nodig, zodat haproxy over twee peers een stick table bij kan houden, zodat het kan functioneren als connection broker.

En ik ben het met je eens dat je voor high availibitily haproxy op twee hosts moet draaien omdat je anders je failover teniet doet. Maar primair moet ik volgens mij twee haproxy instanties draaien, waar die staan maakt voor test doeleinden niet uit. En om daar een tweede host voor te configureren vond ik wat ver gaan.

[Anoniem: 160587]

maar de sticky table zal host based zijn. Dus je moet of 2 netwerk kaarten regelen (of virtuele adapters) of aparte machines.

[loewie1984]

Dat zou kunnen, daar probeerde ik achter te komen. En de volgende vraag die ik dan heb is, hoe configureer ik dat op 1 docker host.

[Berlinetta]

Holy shit, ik heb het idee dat dit veel makkelijker kan. Hiermee kan denk ik veel fout gaan. Ik ben alleen kwijt hoe het heet.

[Voor 15% gewijzigd door Berlinetta op 12-11-2019 21:18]

[Hero of Time]

Bridged mode voor je container waarschijnlijk, zodat het een IP van je DHCP krijgt (of je vast insteld). Standaard zit je met NAT en dat bind dan op alle interfaces.

[loewie1984]

Hero of Time schreef op dinsdag 12 november 2019 @ 21:45:
Bridged mode voor je container waarschijnlijk, zodat het een IP van je DHCP krijgt (of je vast insteld). Standaard zit je met NAT en dat bind dan op alle interfaces.

Ik heb even gekeken, maar de network interface staat al in bridge, toch krijgt elke docker container zijn eigen ip adres in de 172.x.x.x reeks, in plaats van de ip range waarin de host zich in ons netwerk bevindt 10.232.x.x

[CAPSLOCK2000]

Ik heb er zelf nooit mee gewerkt, maar hoe zeker weet je dat je 2 haproxy instanties nodig hebt voor stick tables? Als ik zo snel even zoek vind ik daar geen bron voor. Als ik https://www.haproxy.com/b...-to-haproxy-stick-tables/ lees dan lijkt het me optioneel.

To solve that problem you can add a peers section to the top of your configuration

"can" en niet "must". De peers optie lijkt me dus optioneel.

[Hero of Time]

Je noemde trouwens dat je een connection broker hebt. Wat is eigenlijk de reden om alsnog via haproxy te werken via en toch wel wat omslachtige manier ipv via de bewezen methode van de connection broker? Want daarmee heb je ook aardig wat opties, meer dan met haproxy.

[loewie1984]

@Hero of Time ik heb nog geen connection broker. Ik wilde haproxy daarvoor inzetten omdat deze de functionaliteit bevat. Anders moet ik een windows gebaseerde connection broker opzetten. Dat heeft niet mijn voorkeur omdat het hele rds gebeuren van server 2012/2016/2019 gewoon omslachtig is/werkt.

[Hero of Time]

Waar RDP je dan heen? Is dat geen Windows RDS omgeving dan?

Maar voor haproxy, wat is je config nu eigenlijk? Misschien kan iemand anders met ervaring met haproxy hier helpen. Want je zit met RDP wel met een situatie waar je aan moet denken. Log je in van hetzelfde systeem maar met een andere gebruiker, dan zou het niet erg moeten zijn om een andere server te krijgen. Wil je een verbroken sessie hervatten, dan wil je die juist hervatten. Dat is denk hetgeen wat je wilt.

[loewie1984]

CAPSLOCK2000 schreef op woensdag 13 november 2019 @ 17:51:
Ik heb er zelf nooit mee gewerkt, maar hoe zeker weet je dat je 2 haproxy instanties nodig hebt voor stick tables? Als ik zo snel even zoek vind ik daar geen bron voor. Als ik https://www.haproxy.com/b...-to-haproxy-stick-tables/ lees dan lijkt het me optioneel.


[...]

"can" en niet "must". De peers optie lijkt me dus optioneel.

Dit heeft me een zetje in de goede richting gegeven. Als je kijk naar het voorbeeld zoals haproxy het zelf in hun documentatie heeft staan:

stick-table type string len 32 size 10k expire 8h peers hapee
stick on rdp_cookie(mstshash)

Dan is het dikgedrukte onderdeel alleen belangrijk als je de stick table wilt verdelen/synchroniseren over twee hosts. Het weghalen van het dikgedrukte deel in de configuratie heeft er voor gezorgd dat haproxy in ieder geval wilt starten en blijft draaien in docker (waar dit voorheen met dikgedrukt deel in de config niet het geval was)

Ik heb nu twee maal getest, en kom na een disconnected sessie wederom op dezelfde machine uit. Hij hervat dus de sessie. We gaan dit nu op grotere schaal testen.

Hero of Time schreef op woensdag 13 november 2019 @ 21:48:
Waar RDP je dan heen? Is dat geen Windows RDS omgeving dan?

Maar voor haproxy, wat is je config nu eigenlijk? Misschien kan iemand anders met ervaring met haproxy hier helpen. Want je zit met RDP wel met een situatie waar je aan moet denken. Log je in van hetzelfde systeem maar met een andere gebruiker, dan zou het niet erg moeten zijn om een andere server te krijgen. Wil je een verbroken sessie hervatten, dan wil je die juist hervatten. Dat is denk hetgeen wat je wilt.

De config zoals ie nu is:

#global global ssl-server-verify none #stats page listen stats bind :9001 mode http timeout client 6h stats enable stats hide-version stats realm Haproxy\ Statistics stats uri / stats auth statsadmin:password stats admin if TRUE #rdp configuration frontend ft_rdp mode tcp bind 0.0.0.0:3389 name rdp timeout client 1h log global option tcplog tcp-request inspect-delay 2s tcp-request content accept if RDP_COOKIE default_backend bk_rdp backend bk_rdp mode tcp balance leastconn persist rdp-cookie timeout server 1h timeout connect 4s log global option tcplog option tcp-check stick-table type string len 32 size 10k expire 12h stick on rdp_cookie(mstshash) tcp-check connect port 3389 ssl default-server inter 3s rise 2 fall 3 server TS100 x.x.x.100:3389 weight 10 check server TS101 x.x.x.101:3389 weight 10 check server TS102 x.x.x.102:3389 weight 10 check server TS103 x.x.x.103:3389 weight 10 check server TS104 x.x.x.104:3389 weight 10 check server TS105 x.x.x.105:3389 weight 10 check server TS106 x.x.x.106:3389 weight 10 check server TS107 x.x.x.107:3389 weight 10 check server TS108 x.x.x.108:3389 weight 10 check server TS109 x.x.x.109:3389 weight 10 check server TS110 x.x.x.110:3389 weight 10 check server TS111 x.x.x.111:3389 weight 10 check server TS112 x.x.x.112:3389 weight 10 check

De dikgedrukte zaken zijn even aangepast voor hier te posten.

We connecteren dus via een haproxy load balancer op basis van least connections naar een set van RDS servers. Haproxy vervult dus op deze manier de rol van connection broker.

Op deze manier hervatten we dus inderdaad een verbroken connectie.

[Hero of Time]

Een RDS connection broker doet meer dan alleen je verbinding laten maken met de server met de minste verbindingen. Het stuurt je namelijk van een rustige server naar een andere, als je daar je sessie had. Dus stel je hebt 3 servers, waarbij 1 en 2 elk 8 gebruikers hebben. Server 3 heeft er 5. Je verbreekt je verbinding met server 1 en maakt een uur later weer opnieuw verbinding. Je komt dan initieel op server 3 uit, maar je sessie is op server 1. Door de connection broker wordt je van server 3 alsnog naar server 1 gestuurd, ondanks dat server 3 minder verbindingen heeft.

Ik weet niet of HAproxy dit doet. Je initiële tests doet het goed, het is dus uiteindelijk de vraag of dit ook blijft.