Open KristofKlein opened 2 months ago
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? I think other people tried to make this work also, but failed.
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 am still trying to change the mind on that. Which than would allow me to make use of O365 and EntraID instead of Auth via AD. But for EntraID I end up with the problem that: every time I want to spin up someting new, I get a new URL behind Traefik, that I have to register in my one app registration. And until now I have not managed to script that successful. If I could, I would most likely make that part of the container start routine to register itself. and than I would be happy. since containers without gMSA I can scale, as they will register themself as the containername which is unique.
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) https://github.com/KristofKlein/BCtraefik
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 :)