Azure / AKS-Construction

Accelerate your onboarding to AKS with; Helper Web App, bicep templating and CI/CD samples. Flexible & secure AKS baseline implementations in a Microsoft + community maintained reference implementation.

Home Page:https://azure.github.io/AKS-Construction/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Use the CARML models as much as possible

PixelRobots opened this issue · comments

It would be good to use the CARML modules as a base as they seem to be the ones that will be moving to the public repository. you can find the modules at https://github.com/Azure/ResourceModules.

One thing with the modules is the AKS one does need a bit of work as they do not support cilium and a few other bits currently, but I am sure they are open to pull requests from Microsoft employees to help fix and maintain them.

I'm not sure of the value that would add, can you explain?

Having one place for modules (being the public repo) would end up meaning less work to manage bicep in my opinion.

Within Microsoft we see a lot of teams all doing their own thing and not bringing it back to other places. A lot of duplicated work all around.

But isn't the CARML module just a thin shim on the resource object?

The allowed() values seem to be a repetition from the resource provider, eg. outboundType. However it isn't complete, Nat Gateway has been around for ages and isn't in the list. By specifying values in the allowed() it restricts our ability to use the module. We'd have to PR it, then wait, then make a separate PR to this project. AKS is a really fast moving service, and it takes quite a lot of time to keep up.

I'll be honest, it seems like unnecessary abstraction... and I think we need to carefully consider dependencies where there's no discernible value.
I do like some of the CARML modules like Virtual Network that deal with multiple problems that are otherwise awkward (vnet peering). However if it's a simple shim on the resource, then I don't think the value for effort is clear.

You are defiantly not wrong about the AKS one being a bit out of date. I do want to update it, but they only accept pr's from Microsoft employees.

I think for me, after thinking further based off your comment, it might be more about the folder structure and some of the nice bits of the CARML modules like peering etc.

I think we should definitely refactor the bicep/ folder here, and if there are modules in the bicep registry that make sense to use we should.... but on a case by case basis.