Experiment met Docker op het werk.

[bucovaina89]

Voor mijn werk zou ik een POC willen maken om Docker te integereren in onze bestaande virtualisatie-infrastructuur. Ik heb een concept in mijn hoofd maar ik heb niet veel ervaring met Docker. Ik wil anderen hun mening over wat ik misschien anders/beter of vooral niet kan doen.

Wij draaien vSphere 7.0.1 op 4 BL460c gen9/10 blades in een C7000. Storage is een 3PAR/MSA204 over FC/SAS resp.

Voor de POC zou ik in totaal 3 Linux Debian servers willen draaien. 2 fysieke(compute resources) en 1 VM(storage):

De Docker hosts zouden op een fysieke blade draaien om een vorm van HA te hebben mocht 1 blade crashen dat de containers elders kunnen worden opgestart. Ik heb nog geen backup strategie voor deze hosts maar met Ansible heb ik hoogstwaarschijnlijk binnen het uur terug een werkende host mocht er eentje plat gaan. Ik vermoed dat in geval van een "Docker OS crash", de meeste containers binnen de ~seconde zouden kunnen migreren (vMotion variant maar dan sneller, en ook afhankelijk van welke container, gitlab/confluence,jira heeft tijd nodig om te 'booten') naar een andere Docker host. Ik vermoed ook dat je de setup zodanig in elkaar kan steken dat op de fysieke Docker hosts geen data staat die niet met Ansible recreërbaar is. Ik vermoed dus dat de mogelijke backup strategie voor de fysieke blades: "geen backup nodig" is .

Ik zou dan ook 1 VM in vSphere willen draaien als NFS-share die als persistent storage gaat worden gebruikt voor de containers. Zo kan ik eenvoudig met Veeam backups nemen en ik vermoed dat je wel (NFS) shared storage moet hebben om containers te kunnen transporteren naar een andere Docker host. Een mogelijk probleem van deze VM is dan dat het een SPOF is.

Het hele doel zou dan uiteindelijk zijn om de voordelen van Containers (in dit geval: leaner, geen CPU-verlies door virtualisatielaag, apps gemakkelijker te managen, VMware/Veeam licentiekost lager) met OS virtualisatie (vooral dan backup in dit geval) te mixen.

Maar goed, ik denk dat mijn bezorgdheid op deze moment is of ik hier een start heb gegeven van een robuuste setup die upscalebaar is.

[jurroen]

Ik heb zelf heel beperkte ervaring met Docker, als BSD fanaat gebruik ik zelf jails om hetzelfde te bereiken

Zou de Docker setup dan in plaats van vSphere komen? Zo niet: vCenter (onderdeel van vSphere) kan meen ik native Docker draaien, ESXi kan dat niet.

Als Docker wel vSphere zou vervangen: je zou ook een setup kunnen maken waarbij twee blades de storage repliceren, bijvoorbeeld door ZFS te gebruiken. Als een van de twee blades dan onverhoopt stuk gaat, kun je de containers redelijk gemakkelijk overschakelen naar de andere storage mount.

[ Voor 58% gewijzigd door jurroen op 08-04-2021 15:10 ]

[svenvv2]

Zeker in een meer zakelijke omgeving zou ik direct de 'docker management-laag' meenemen. Kubernetes is een van de bekendere. Hoewel lichtelijk overkill voor wat je nu omschrijft maakt het alles een stuk makkelijker als je later wilt schalen.

Docker+k8s kennis staat ook zeer goed op je CV momenteel

[Falcon]

Als ik je 1 tip mag geven, ga het opbreken in kleine afrondbare taken.. zet deze in een todo/in progress/done vorm op (digitaal kan je gelijk even delen met een collega als dat handig is).

Zo zie je de voortgang van dit projectje en triggert gelijk om de juiste volgorde aan te houden. En niks fijners om taken af te ronden en het lijstje links korter te zien worden

[bucovaina89]

jurroen schreef op donderdag 8 april 2021 @ 15:06:
Ik heb zelf heel beperkte ervaring met Docker, als BSD fanaat gebruik ik zelf jails om hetzelfde te bereiken

Zou de Docker setup dan in plaats van vSphere komen? Zo niet: vCenter (onderdeel van vSphere) kan meen ik native Docker draaien, ESXi kan dat niet.

Als Docker wel vSphere zou vervangen: je zou ook een setup kunnen maken waarbij twee blades de storage repliceren, bijvoorbeeld door ZFS te gebruiken. Als een van de twee blades dan onverhoopt stuk gaat, kun je de containers redelijk gemakkelijk overschakelen naar de andere storage mount.

Docker zou als aanvulling dienen op vSphere. Helemaal vervangen lijkt me niet nodig, misschien zelfs niet wenselijk? Weet niet .

[-TAZZ-]

Gebruik gewoon Tanzu op de vSphere infra die je toch al hebt

[bucovaina89]

svenvv2 schreef op vrijdag 9 april 2021 @ 09:19:
Zeker in een meer zakelijke omgeving zou ik direct de 'docker management-laag' meenemen. Kubernetes is een van de bekendere. Hoewel lichtelijk overkill voor wat je nu omschrijft maakt het alles een stuk makkelijker als je later wilt schalen.

Docker+k8s kennis staat ook zeer goed op je CV momenteel

Kan je daar een tweetrapsraket van maken? Eerst 2 docker hosts op zetten en zien hoe het werkt en daarna kubernetes opzetten met diezelfde 2 hosts?

[init6]

Docker is een product wat ik zie als goede entrypoint om dingen in te leren. Zet het op je laptop, ga er mee spelen en leer hoe de isolatie werkt, hoe je containers in kan komen, wat het inhoudt als je een container verwijderd, stateless en stateful workloads en krijg het concept onder controle.

Ga hierna kijken naar management tools welke deze containers beheren. Als je Docker eenmaal kent zal je snappen dat het niet veel voorstelt. Heel veel mensen doen heel moeilijk dat het niet secure is en dat ze het niet snappen. Voor wie bezig geweest is met linux kernel troep die weet dat het niet veel meer is dan cgroups, network namespaces en heel veel lijm om je een goede introductie te geven. Het echte werk begint pas met container clusters zoals Kubernetes.

Als ik heel eerlijk mag zijn: Kubernetes heeft de oorlog gewonnen. Er was Mesos (die is einde oefening), er is een hashicorp product wat Nomad heet, er is Docker swarm en er waren nog meer tools. Maar Kubernetes is wat 99% van de industrie draait. Het resultaat is dat iedereen een kubernetes oplossing aanbied. Wil je Grafana draaien? Er is een kubernetes helm chart. Wil je SQL? Er zijn MariaDB helm charts en als je SQL clustering wilt een Galera chart. En ga zo maar door. Het ontzorgt je daardoor, je hoeft alleen de helm charts in te vullen en je applicatie draait vaak al met de defaults. Daarnaast is cluster communicatie zoals DNS en networking al geregeld. Alleen kubernetes puur vanilla draaien is iets wat ik alleen beginners aanraad. Kelsey Hightower heeft Kubernetes the hard way ergens op github staan en legt uit hoe je van scratch een Kubernetes cluster kan bouwen. Dat doe je een keer en daarna raad ik aan om te gaan kijken naar een aantal opties:
- Je draait het in de hosted omgeving van Google, AWS of Azure. Zij zetten Kubernetes voor je op.
- Je wilt het zelf draaien, dan zijn er vele abstractie / management lagen die je kunt gebruiken. (Rancher, Openshift, RedShift, Tanzu, Platform9 en nog een hele zooi).
- Je bent gek dus je draait het hardcore vanilla.

Kubernetes heeft sinds een aantal updates Docker engine verwijderd en vervangen voor containerd, Docker zelf lopen al meerdere partijen al heel lang tegen aan te schoppen. Redhat omdat het niet secure genoeg is en niet selinux genoeg doet, Kubernetes nu. Docker zal over een tijd dus alleen gebruikt worden door de developers maar op container clusters zie ik het wel verdwijnen. Maar het is goed om iig de basis van mee te krijgen.

1. De eerste stap die je dus moet gaan maken is zet een docker setup op je laptop of test machine en ga spelen. Zet een LAMP stack op die via diverse containers met elkaar praten. Zoiets.
2. Ga kijken naar container clusters. Kubernetes is mijn inzien de enige verstandige keuze op dit moment. Zet een test cluster op, je kan dat hardcore doen of heel makkelijk door k3s/minikube te installeren op je laptop.
3. Zet een POC cluster op via diverse management platforms.
4. Lees je het schompes mbt production ready maken van deze clusters.

Succes. We zijn nu bezig met een migratie van ons oude container cluster naar Rancher. Het is best interessant.

[cytherea]

init6 schreef op vrijdag 23 april 2021 @ 10:55:
- Je bent gek dus je draait het hardcore vanilla.

Of je werkt met zulke gevoelige data en zulke high performance dat je eigen hardware moet gebruiken en grip wil hebben of wat er gebeurd.

Bij de inrichting van ons cluster heb ik juist helm vermeden, ik wil precies weten wat er gedeployed wordt en waarom. Uiteindelijk geef je heel veel complexiteit uit handen en iemand bepaald hoe jouw configuratie gaat zijn. Wij hebben heel veel moeten tunen om onder load pods te kunnen verwijderen en een nieuwe versie erneer te zetten. Het werkt nooit zo perfect als in de advertentie. Pod wordt gekilled terwijl er nog een net een paar requests bezig zijn om maar een voorbeeld te geven. Daar is een kleine vertraging nodig om de pod uit de ingress te halen en de lopende requests af te handelen.

Het hangt allemaal af van wat je eisen zijn of je afhankelijk wil worden van andermans configuratie.

Daarnaast +1 voor Kubernetes, docker alleen heb je nog niet heel veel aan. Kubernetes geeft je manieren om secrets te beheren, volumes te mounten, zaken HA te maken, opschalen, enz..
Maar reken wel op een flinke leercurve, sommige dingen moet je op een andere manier opzetten (een pod moet stateless zijn, anders kom je in de knoei met HA). Niet proberen om Mariadb op Cephfs te draaien, heeft ons een corrupte database opgeleverd.

@bucovaina89 Ik zou de stap van puur docker overslaan en meteen naar Kubernetes gaan. Met de juiste inrichting heb je loadbalancing en HA meteen goed geregeld. Belangrijk is wel waar je de state neerzet, die moet ook HA zijn.

[init6]

cytherea schreef op vrijdag 23 april 2021 @ 11:40:
[...]


Of je werkt met zulke gevoelige data en zulke high performance dat je eigen hardware moet gebruiken en grip wil hebben of wat er gebeurd.

Dan nog niet. Vanilla from scratch is echt niet meer nodig. Rancher is een pakket bijvoorbeeld dat Vanilla Kubernetes voor je neerzet maar daar een goede interface omheen bouwt. Waar ik normaal weken tot maanden bezig zou zijn met Ansible/Terraform neer te zetten draait het binnen een week of 2 in een productie setup.

Bij de inrichting van ons cluster heb ik juist helm vermeden, ik wil precies weten wat er gedeployed wordt en waarom. Uiteindelijk geef je heel veel complexiteit uit handen en iemand bepaald hoe jouw configuratie gaat zijn. Wij hebben heel veel moeten tunen om onder load pods te kunnen verwijderen en een nieuwe versie erneer te zetten. Het werkt nooit zo perfect als in de advertentie. Pod wordt gekilled terwijl er nog een net een paar requests bezig zijn om maar een voorbeeld te geven. Daar is een kleine vertraging nodig om de pod uit de ingress te halen en de lopende requests af te handelen.

Helm charts worden hier enkel gedeployed als ze opensource en inzichtelijk zijn, dus ik kan elke yaml van de charts lezen. Vervolgens kan ik dergelijke logica inbouwen dmv sidecars neer te zetten. Een voorbeeld is een deel van onze website waarin we 3 uur doen om de cache goed op te warmen, de health check gaat pas op groen totdat de cache is opgewarmd.

Het hangt allemaal af van wat je eisen zijn of je afhankelijk wil worden van andermans configuratie.

We kijken intern heel erg naar wat onze core business is en hoeveel tijd, geld en moeite we willen steken in onze setup. Dat is deels omdat ik na bijna 10 jaar het allemaal wel gezien heb en niet zo nodig meer databases hoef te draaien, maar ook omdat we 2-3 man hebben om het werk te doen. Goede mensen vinden die infra kunnen met Kubernetes en ook nog eens automatiseren is moeilijk.

Databases hebben we daarom liever niet in containers, we draaien het liefste op SaaS oplossingen tenzij we niet uitkomen qua kosten of design keuzes. We draaien daarom alleen onze eigen grote SQL clusters en onze NoSQL in onze cluster setups met TiB's aan data omdat het te duur is elders maar iets simpels als een mongodb of SQL met een paar honderd MB aan data draait bij ons in SaaS.

We willen bezig zijn met onze diensten ontsluiten, niet met hoe een database draait. Het maken van een eigen chart of een eigen deployment voor een opensource tool hoort voor ons niet bij onze core dienstverlening, als iemand anders deze al heeft gebouwd dan pakken we die. Werkt hij niet zoals we willen dan pakken we de code van een ander en bouwen het om naar onze use case.

[bucovaina89]

kudos to @cytherea @init6 . Ik denk dat als we er serieus mee willen beginnen dat het inderdaat k8s zal moeten worden.

[The Eagle]

Als jij nu wilt beginnen experimenteren om later op te schalen, zou ik eens naar minikube kijken. Lokale k8s installatie. Kun je voelen wat het doet en hoe het werkt.
Groot verschil tussen docker en k8s is bijvoorbeeld het gebruik van IP adressen. Een docker container is een eenheid en heeft zijn eigen IP. k8s werkt met een extern IP voor een functionaliteit, en met interne IP's voor containers. Schaalt dus een stukje makkelijker

Lastige van containers is dat je er bijvoorbeeld niet zomaar een dubbele DB instance in kunt draaien als een enkele functionaliteit. Die instances kunnen namelijk niet met elkaar communiceren op DB niveau en dan krijg je een split brain, om maar te zwijgen van een situatie die nooit Point in time recoverable is.