-
Notifications
You must be signed in to change notification settings - Fork 247
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question: gMSA + OnPrem Hosted SQL + docker compose scale >1 = unstable Business Central #3669
Comments
gMSA or reply urls - is that because you want to use Windows Auth or O365 auth for the containers? |
on working Traefik v2/v3 support - is there anything you can share with the community? |
gMSA because I want to make use of AD "features". That allows me to make use of Windows Auth, work with Services talking to the DB while making use of the gMSA account, also to allow file access to a shared AD related file server (which we will drop soon - but still). Bottom line my dilemma is that my IT wants me to not use UserName/Password to talk to the DB. They want that I make use of a managed service account. that forced me into this gMSA topic. i fooled around with those but no success:
and
I will open another issue to reference the traefik stuff. But keep in mind: this is about the try to not use New-BcContainer but make use of docker-compose ;) |
about traefik v2: (WiP) |
Thanks @KristofKlein - will have a look when I have some time to spare:-) |
As I miss a better place to ask for this, I just drop it here :)
I had a dream ... or maybe not a dream, but a wish from my manager: "we have all this old OnPrem Hardware flighing around, don't you think we should make use of this - what about this docker stuff, that sounds fancy. Go - use it!"
Well, ok, thanks to @freddydk, @tfenster and some others I was able to get "everything" working... until I was asked to "add more"...
So the first thing I did, Traefik v2/v3 support. Took a while, but now it works. so nice. So, "more" ... what about orchestration, Swarm, Kubernetes ... well ok...but... not so easy with bccontainerhelper, so - back to the roots, dockerfiles, docker run, docker compose and what not ... actually I did not even went to full orchestration, but sticked to docker compose and its ability to also scale container.
And all worked, and container started and scaled and .... the system went down the drain. Because of gMSA and the small but unfortunate detail about "all containers will express themself as the gMSA Account" ... so if I now scale a container, Business Central will see that as the same machine, with the same service and goes nuts on the session/service handling. Healthcheck does apperently no longer know what the status of a ST is, and forces sessions to terminate etc.
"just use a gMSA for every container" ... well, sure, but that will not work with scale. as scale just makes replicas of the same. "Well use dedicated docker images with prepacked servicetier names"....good idea! tried that! But ofc, same problem, scaling would kill this.
"Don't use gMSA" - oh I would love to, but that means: register reply URIs in azure for every new instance (if someone knows how to do this from powershell, shoot!), no AD Service account for DB access.
I am just curious what people found out on thisone. Gave up, found a way ( besides using Cosmo or a full VM scaler).
Someone might say that is clearly a fault of the BC Service Instance to not use the correct value to register itself. Not even sure what it uses.. it is not HostName as this would be the containername and would make everything work out of the box. $env:computername is the gMSA, or does it use some network stack to trace it ?
So I don't expect a bccontainer to fix this - but maybe the common audience has an idea :)
The text was updated successfully, but these errors were encountered: