[Docker] DNS-server in Docker Swarm

[CAPSLOCK2000]

Ik probeer een DNS-server te hosten op Docker Swarm, maar ik loop tegen allerlei beperkingen aan die waarschijnlijk een gevolg zijn van klassiek denken aan mijn kant. Wie helpt me op weg?

Ik heb nu een klassieke VM met daarin een DNS-server. Die VM heeft een statisch IP. Een statisch IP is essentieel voor een DNS-server. Dat is problematisch voor Docker Swarm want voor zover ik weet is het niet mogelijk om statische IP-adressen te gebruiken binnen Docker Swarm. Alles moet dynamisch zijn.

Het model is dat de containers bereikbaar zijn op het IP-adres van iedere host-machine. Docker routeert het verkeer dan intern door. Dat klinkt leuk maar is praktisch onwerkbaar voor DNS-servers. De meest simpele beperking is dat je op de meeste plekken maar 2 ip-adressen kan opgeven voor je DNS-servers, en ik heb meer hosts dan dat. Ik wil er niet op rekenen dat een host altijd bereikbaar is. Het doel van dit project is juist om High-Availability te bereiken zodat ik individuele servers kan onderhouden of vervangen.

De klassieke oplossing is om er dan een load-balancer/proxy voor te zetten. Maar ja, dat is het probleem alleen maar verplaatsen, want waar ga ik de load-balancer dan hosten? Als ik dat in een klassieke VM ga doen kan ik daar beter de DNS-server zelf plaatsen en ben ik terug bij af.

Een vergelijkbaar verhaal kan ik houden over andere applicaties maar DNS is het lastigste omdat je daar IP-adressen moet gebruiken.

De beste oplossing die ik kan bedenken is om geen Docker Swarm te gebruiken, maar traditionele cluster-manager (zoals Cororsync/Pacemaker) in te zetten om standalone containers te starten die wel een statisch IP-adres kunnen krijgen. Ik zou echter liever een oplossing hebben die meer in de geest is van een moderne container omgeving, al weet ik niet hoe dat er dan uit zou moeten zien.

Iemand een suggestie voor de juiste aanpak?

PS. Ik ben niet getrouwd me Docker of Docker Swarm en heb ook even naar Kubernetes, Rancher, Nomad en andere tools gekeken. Die hebben ongeveer dezelfde beperkingen. Daarom zie ik het niet als een fout van Docker, maar als gebrek aan inzicht aan mijn kant. Ik wil met dit topic vooral mijn inzicht vergroten en begrijpen hoe ik zo iets aanpak in de containerwereld, ik ben dus niet op zoek naar een hack om het ouderwetse model bovenop containers te stapelen.

PS2. De DNS-server in kwestie host een gewoon domein met Bind en moet voor de buitenwereld bereikbaar zijn, ik heb het dus niet over Consul of andere tool die voor de containers intern is.

[Hero of Time]

Je verhaal is niet heel duidelijk wat je probleem nou precies is met je DNS server. Je zegt 1 VM te hebben die DNS doet. Je vervolgt je verhaal met dat al je docker instanties dynamisch zijn en maar 2 DNS servers kan hebben om te resolven. Waar haal je opeens meer dan tweee DNS servers vandaan? Dat is toch die ene klassieke VM? Of probeer je te zeggen dat die VM weg gaat en DNS ergens in je swarm gaat rond buzzen?

[Dronium]

Wat is de achterliggende reden om je DNS in een Docker Swarm te plaatsen? Redundantie, schaalbaarheid of gewoon om "modern" te doen?
DNS is, waar ik het gebruik, een stevig stuk van de fundering van je infra-structuur, dan wil je dus zo min mogelijk afhankelijkheden van andere componenten. Wij draaien onze DNS-servers nog gewoon fysiek direct op eigen hardware. Als je stroom hebt werkt het

[Turdie]

Dronium schreef op woensdag 21 november 2018 @ 19:24:
Wat is de achterliggende reden om je DNS in een Docker Swarm te plaatsen? Redundantie, schaalbaarheid of gewoon om "modern" te doen?
DNS is, waar ik het gebruik, een stevig stuk van de fundering van je infra-structuur, dan wil je dus zo min mogelijk afhankelijkheden van andere componenten. Wij draaien onze DNS-servers nog gewoon fysiek direct op eigen hardware. Als je stroom hebt werkt het

Niet als je power supply faalt, of je moederbord of een andere belangrijke hardware component voor het draaiende houden van de machine. Daarom zou ik een DNS server liever virtueel draaien, zodat je wat betere HA kan garanderen, of je zou er echt een fysiek cluster van moeten maken met twee fysieke dozen.Maar docker zou ik ook niet doen.

[Voor 20% gewijzigd door Turdie op 21-11-2018 20:33]

[CAPSLOCK2000]

Hero of Time schreef op woensdag 21 november 2018 @ 19:16:
Je verhaal is niet heel duidelijk wat je probleem nou precies is met je DNS server. Je zegt 1 VM te hebben die DNS doet. Je vervolgt je verhaal met dat al je docker instanties dynamisch zijn en maar 2 DNS servers kan hebben om te resolven. Waar haal je opeens meer dan tweee DNS servers vandaan? Dat is toch die ene klassieke VM? Of probeer je te zeggen dat die VM weg gaat en DNS ergens in je swarm gaat rond buzzen?

Ik heb meerdere DNS-servers. Een of meer daarvan wil ik als container gaan draaien in een of andere cloud of swarm.

Dronium schreef op woensdag 21 november 2018 @ 19:24:
Wat is de achterliggende reden om je DNS in een Docker Swarm te plaatsen? Redundantie, schaalbaarheid of gewoon om "modern" te doen?

Allemaal, maar vooral dat laatste. Voor de duidelijkheid, we hebben het hier over mijn thuis-netwerkje, niet over een zakelijke omgeving. Extra ijzer neerzetten is niet realistisch, er draait hier al veel te veel. Ik probeer hier zo efficiënt mogelijk om te springen met de resources die ik heb, tegelijkertijd wil ik meer leren over Docker en containers. Ik zoek bewust de grenzen op om te vinden waar die liggen.

Laat ik mijn vragen opnieuw formuleren:

Hoe ga je er mee om als je applicaties hebt die op IP-adres benaderd moeten worden?

Hoe zet je een cloud-applicatie (in casu Docker Swarm of Kubernetes) in DNS?
Als ik de handleiding goed interpreteer moet ik de IP-adressen van alle hosts opnemen en maar hopen dat de client automatisch naar het volgende IP-adres doorgaat als het eerste niet bereikbaar is. Ik zie alleen oplossingen met een externe loadbalancer/HA. Het is eigenlijk onmogelijk om statische adressen toe te wijzen aan cloud containers.

[Dronium]

Nu weet ik niet veel van Kubernetes of Docker maar toch:
Applicaties wil je niet op IP benaderen maar op DNS-naam. Dus moet de applicatie instance zichzelf bij je Dynamic-DNS server registreren en ook weer afgevoerd worden als ie uit gaat. Dan heb je altijd een kloppende set DNS records.

Verder moet je DNS niet vergelijken met een applicatie voor (eind) gebruikers. DNS hoort bij je infrastructuur daar moet je dus anders mee omgaan. Je clients / containers / applicaties zijn afhankelijk van een goed functionerende infra om te kunnen werken, dus om de infra-taken dan in zo'n container te stoppen zal niet alijd werken. Zeker in het geval van DNS want zoals je zelf al constateerd vereist DNS een statisch IP adres. DNS benader je ook nooit op (DNS) naam altijd, op IP adres. Hetzelfde geld ook voor een DHCP server bijvoorbeeld.

[CAPSLOCK2000]

Ik begin in te zien dat docker-swarm, kubernetes en andere cloudachtige oplossingen niet geschikt zijn voor het meeste wat ik er mee wil, want dat is meer infrastructuur dan applicatie.

Niettemin ga ik verder met docker, maar dan wat eenvoudiger, gewoon met stand-alone docker containers. Het netwerkdeel en HA verzorg ik wel met traditionele middelen. Eens kijken hoe dat bevalt.

[Kees]

Volgens mij is het voordeel van de dockerswarm dat je dan je dns server op elk van de adressen kan benaderen ongeacht waar hij draait. De swarm routeert het verkeer dan intern door. Het grootste nadeel is dat poort 53 meestal al wel bezet is in de swarm en je dus een andere poort moet nemen.

Ik doe het nu zelf met 1 vm (met powerdns, mysql, apache, en een webgui voor beheer) en dan 3 minimale docker containers met powerdns als superslave. Maar niet in docker swarm maar gewoon als losse containers op poort 5335 op mijn 3 hosts. En vervolgens heb ik een traditionele loadbalancer die het verkeer over die 3 containers verdeelt

[CAPSLOCK2000]

Dat model werkt alleen goed als je een klein aantal betrouwbare docker hosts hebt (zeg maximaal 3) of een externe loadbalancer hebt, die dan weer dubbel en HA moet worden uitgevoerd.

Meestal zijn dat soort omgevingen zo ingericht dat alle SSL wordt getermineerd op de loadbalancer en dat daarachter alles onbeveiligd is. Daarbij wordt impliciet aangenomen dat je lokale netwerk veilig is en dat alle containers/vms te vertrouwen zijn. Dat vind ik geen fijn model.

Verder vindt ik het wel prettig om iedere dienst z'n eigen IP-adres te geven. Dat maakt het filteren en routeren van verkeer een stuk makkelijker en overzichtelijker. Ik heb diensten die hele grote gaten in de firewall nodig hebben (bv alle UDP poorten > 1024). Als zo'n dienst z'n eigen IP-adres heeft is dat acceptabel, maar als diensten geen eigen IP meer hebben kan ik de firewall wel afschaffen.

[Hero of Time]

CAPSLOCK2000 schreef op zaterdag 24 november 2018 @ 12:10:
Meestal zijn dat soort omgevingen zo ingericht dat alle SSL wordt getermineerd op de loadbalancer en dat daarachter alles onbeveiligd is. Daarbij wordt impliciet aangenomen dat je lokale netwerk veilig is en dat alle containers/vms te vertrouwen zijn. Dat vind ik geen fijn model.

Dat is een nogal achterhaald statement die je hebt. Je gaat er dus maar vanuit dat loadbalancers intern niet aan HTTPS kunnen doen. Als je nog zo'n antiek stuk software/hardware hebt, moet je eens gaan upgraden. Ik heb van de week nog een HAProxy ingericht en die ontvangt HTTPS en zet dan naar de backend een nieuwe beveiligde verbinding op om de boel door te zetten.

[CAPSLOCK2000]

Je gaat er dus maar vanuit dat loadbalancers intern niet aan HTTPS kunnen doen.

Kom op he, we kennen elkaar toch wel iets beter dan dat?
Dat ik het woord 'meestal' gebruik zegt toch dat ik weet dat het wel kan?


Technisch gezien kan het wel, ik heb ze draaien, maar alleen in een klassiek netwerk met vaste hostnames. Ik krijg het niet goed in het cloud/swarm-model ingepast.

Hoe kom je aan SSL-certificaten voor je containers?
Heb je een eigen CA voor iedere dienst die je draait?
Of doe je opportunistische SSL zonder de geldigheid van de certificaten te controleren?

Want mijn swarm-containers hebben geen vast IP-adres of hostname, traditionele certificaten kan ik dus niet gebruiken. Certificaten aanvragen met LetsEncrypt zou nog kunnen maar is niet genoeg, dan moet ik nog steeds op een andere manier controleren welke hosts toegang hebben want iedereen kan een LE cert krijgen. Ik zou voor iedere dienst een eigen CA kunnen opzetten maar dat zou veel werk worden en redelijk verwarrend zijn.
Hoe pak jij dat aan?

[Hero of Time]

Certificaten werken op basis van domein/hostnaam. Je applicatie of website luistert op die naam. Ik zie dus niet echt een probleem hier. Of je nou met een externe CA werkt, LE, een eigen CA of SS gebruikt, je hebt altijd iets om op te valideren: de naam. Of je container nou een IP heeft dat eindigt op 10, 100 of 254 maakt dan ook niet uit, net als de hostnaam zelf piet, klaas of annabel is.

[CAPSLOCK2000]

Hebben jouw services dan een vaste hostname?
Bij die van mij wordt de hostname willekeurig gekozen door Docker Swarm. Daar kan ik geen voorgegeneereerde SSL-certs op zetten want ik weet niet welke naam zo'n container zal krijgen. Misschien dat ik namen kan registeren bij consul en dan DNS forwarden naar Consul, maar dat wordt een draak van een constructie. Ik zie ook nog wel mensen die met Traefik werken of iets vergelijkbaars, maar dan ga je weer al je verkeer via één centraal punt sturen en ben je het probleem eigenlijk alleen maar aan het verplaatsen.

[Voor 21% gewijzigd door CAPSLOCK2000 op 24-11-2018 13:20]

[Hero of Time]

Ja, want we gebruiken geen docker op kantoor. Maar ik doelde meer op de naam waar de service op luistert in je container, dan de hostnaam van hoe het 'systeem' zelf.

[CAPSLOCK2000]

Het begrip "service" heeft een heel specifieke betekenis in de wereld van Docker Swarm.
Dat is een container die in de Swarm draait.

Zo'n service kun je niet zomaar op een externe DNS-naam benaderen. Intern hebben ze een unieke hostname en IP-adres. Je kan ze alleen benaderen via de naam of het ip-adres van de host.

Een HA-proxy config zou er ongeveer zo uitzien:

 backend www.mijndienst.nl
        server server1 host1.hoster.nl:8080
        server server2 host2.hoster.nl:8080
        server server3 host3.hoster.nl:8080

De services weten niet op welke host ze draaien en daarbij is het sowieso onwenselijk om ze een SSL-cert geven op naam van de host. Ik zou CNAMES kunnen opnemen 'backend1.mijndienst.nl -> host1.hoster.nl' maar als ik dat voor iedere applicatie ga doen wordt het best een zooitje en moet je die mappings bij houden als er een host bij komt of weg gaat. Dat voelt ook niet ideaal.

[Hero of Time]

En ik doe dus niks met Docker. Maar als je een webserver in containers draait, serveer je een website. Die heeft een bepaalde naam en de webserver in je container moet dan dus naar die naam luisteren en het bijpassende certificaat ervoor serveren. Ik denk dus nog aan de klassieke manier van certificaten aanbieden van een bepaalde dienst, waarbij het niet uitmaakt hoe de machine zelf heet. Dat principe lijkt mij niet heel anders te zijn voor Docker containers, of wel?

[CAPSLOCK2000]

Hero of Time schreef op zaterdag 24 november 2018 @ 21:07:
En ik doe dus niks met Docker.

Dat kan ik ook niet helpen

Die heeft een bepaalde naam en de webserver in je container moet dan dus naar die naam luisteren en het bijpassende certificaat ervoor serveren. Ik denk dus nog aan de klassieke manier van certificaten aanbieden van een bepaalde dienst, waarbij het niet uitmaakt hoe de machine zelf heet. Dat principe lijkt mij niet heel anders te zijn voor Docker containers, of wel?

Het principe klopt, maar de praktijk niet. Docker Services zijn niet direct per IP of op hostname bereikbaar, je moet ze aanspreken op het IP-adres van de host. Om een SSL-certificaat te controleren heb je een hostname nodig. Ik kan niet de hostname van de dienst gebruiken, die wijst immers naar de loadbalancer.

Ik heb dus een DNS-naam nodig die naar de IP-adressen wijst waar de service draait.

De eerste mogelijkheid is dat de containers een SSL-cert geef met de hostname van de host. Dan zouden alle diensten in mijn netwerk dezelfde hostnames in hun SSL-cert krijgen. Dat wordt een puinhoop en maakt het onmogelijk om vast te stellen of ik met de juiste service ben verbonden, of dat ik per ongeluk op de verkeerde poort zit, of zo iets. Dat vind ik dus geen goede optie.

Een andere mogelijkheid is dat ik extra DNS-namen opneem. (bv backend4.service15.site.com) Dan krijg ik het kruisproduct van services en hosts aan hostnames er bij. Of ik moet iets gaan goochelen met split-DNS zodat mijn backend0hosts gebruik kunnen maken van de publieke DNS-naam en de IP-adressen van de hosts. Ik moet hoe dan ook een extra mapping bij gaan houden tussen services en hosts en bijwerken iedere keer als er een host of service bij komt.

Er is ook nog wel software om dit een beetje te automatiseren met een Service Registry, zoals bv Consul, dat oa service-discovery en dns-services aanbiedt binnen je Docker-omgeving en gebruikt kan worden om bv dynamisch configs te genereren voor je loadbalancer. Dat is echter weer een laag aan complexiteit er bij. Ik zou het liever op IP-niveau regelen en iedere service een uniek IP-adres geven en dan door m'n routers en switches laten uitzoeken waar het pakketje naar toe moet.

Dat zou ik kunnen oplossen dor op iedere host een stand-alone container te draaien met haproxy en keepalived of zo iets, maar dat is nog een laag aan complexiteit er over heen.

Ik vermoed dat ik ergens iets moet aanpassen in mijn manier van denken over dit soort infrastructuur. Ergens neem ik een ouderwetse afslag of zie ik een stuk techniek over het hoofd.

[Voor 5% gewijzigd door CAPSLOCK2000 op 26-11-2018 11:00]

[CAPSLOCK2000]

Kleine update, ik heb het nu min of meer bevredigend draaien.
Ik gebruik pacemaker+corosync als cluster-manager, hiermee stuur ik zowel qemu VM's aan als Docker containers. Alle data staat op Ceph. Ceph draait overigens ook vanuit Docker containers, maar die worden niet aangestuurd door corosync.
Op alle hosts heb ik netwerk-bridge waar alle containers en VMs mee zijn verbonden. De bridges op de hosts zijn via een vlan met elkaar verbonden.
VM's stellen zelf een IP-adres in, containers wijs ik een vast ip-adres toe bij het opstarten.
Ik moet nog een paar details goed krijgen maar op zich werkt het.
De volgende stap is om toch ook Docker Swarm te gaan gebruiken voor bepaalde applicaties die zich daar goed voor lenen.