how to best add bicep, flux and kubelogin to devcontainer?

[rjfmachado]

Hi, looking for some pointers on how to best approach this. At this point, my postCreateCommand looks like this for devcontainer with azure-cli and kubectl-helm-minikube features.

"postCreateCommand": "az bicep install && az extension add --name ssh && az extension add --name aks-preview && wget https://github.com/Azure/kubelogin/releases/download/v0.0.20/kubelogin-linux-amd64.zip && unzip kubelogin-linux-amd64.zip && sudo mv bin/linux_amd64/kubelogin /usr/local/bin/ && rm kubelogin-linux-amd64.zip && rm -rf bin && curl -s https://fluxcd.io/install.sh | bash"

I see #149 can help with az cli extensions, but it should be easier to add "commands" to features.

I've considered adding functionality to kubectl-helm-minikube, but I'm thinking we'd be better off with a more generic feature name for cloud native/kubernetes? Flux is more niche, but kubelogin is about to become mandatory for AKS when using Azure AD so it should also probably be considered to be deployed together with kubectl.

Thanks!

[samruddhikhandale]

Trying to analyze how the postCreateCommand can be simplified.

az bicep install

Being able to add commands to every Feature is an interesting suggestion. // cc - @bamurtaugh / @Chuxel Probably something like this?

      "ghcr.io/devcontainers/features/azure-cli": {
            "version": "latest",
            "postCreateCommand": "az bicep install"
        }

Unfortunately, we currently don't support that but I agree, it would be a great improvement. However, in the devcontainers/images repo, we have tried to handle such scenarios with local features (example). Maybe that's something you could use to avoid writing commands in the postCreateCommand?

az extension add --name ssh && az extension add --name aks-preview

As you correctly pointed out, https://github.com/devcontainers/features/issues/149 should help.

wget https://github.com/Azure/kubelogin/releases/download/v0.0.20/kubelogin-linux-amd64.zip && unzip kubelogin-linux-amd64.zip && sudo mv bin/linux_amd64/kubelogin /usr/local/bin/ && rm kubelogin-linux-amd64.zip && rm -rf bin

Looks like a good candidate to be added to the kubectl-helm-minikube Feature. Would you be interested in creating a PR which adds this as an option to the kubectl-helm-minikube Feature? 😄

curl -s https://fluxcd.io/install.sh

Flux would be an exciting new Feature as part of the Feature's collection (else you could also add it as a local Feature)

We also have a self-publishing mechanism available if you want to publish and maintain this feature in your own repo: https://github.com/devcontainers/feature-template. We'd love for the community to be able to publish and use features without having to go through a central repo.

You could also refer to https://github.com/devcontainers/features#contributions for contributing details.

I hope this helps 😄

[bamurtaugh]

Thanks for opening this issue and using Features, @rjfmachado!

It is an interesting idea to add a postCreateCommand property when referencing a Feature - @samruddhikhandale the way you show seems like it could be reasonable. Although, it feels like these kinds of commands could (and maybe should) be added to the install.sh script of the Feature itself?

[samruddhikhandale]

Although, it feels like these kinds of commands could (and maybe should) be added to the install.sh script of the Feature itself?

Looking at the list of Azure CLI commands, there are plenty commands which could be added to install.sh. I don't think we should be adding all of them to the install file because the Feature would become bulky and not sure if every user would want it. If we have some postCreateCommand or similar option for the Feature, then the user can add commands as per their configuration (without complicating the postCreateCommand of the devcontainer.json).

However, bicep looks like a good candidate to be added to the azure-cli Feature as an option.

[Chuxel]

I think we need to be careful here since the intent of these features is to install things - you wouldn't want to accidently fire az commands that provision infrastucture since this would fire during the Dockerfile build.

• There's a feature request for postCreateCommand support in features, so that part we've got a proposal for. We should not call it that here.
• The bicep command itself is too powerful. I'm not sure overloading the Azure CLI is the right thing here since there's other things like azd, the functions SDK, etc.

@bamurtaugh I believe you were connecting with folks on the Azure side and bicep was one of the features that could be created there. I think an official Azure spot would be better for this type of thing than in the open spec repository. The Azure CLI was "grandfathered" in along with the AWS one. Would it make sense to follow up again and see if there's a spot for a broader set of Azure requests like this? I think that's really what is missing here. Templates will also be in this same category as the spec for that part goes live.

[bamurtaugh]

@Chuxel I'll follow up again on the Azure side as its been some time since the initial discussions.

[rjfmachado]

Thank you for the discussion, I agree not to overload the azure cli feature set. I'd also prefer to see a bicep or overall Azure feature, that simply downloads and installs the bicep binary, replacing the az bicep install command.

[rjfmachado]

Hi @samruddhikhandale @bamurtaugh @naioja and I went ahead and forked the repo, copied the feature kubectl-helm-minikube into a new feature called cloud-native and added support for kubelogin, flux v2 and Azure AD workload Identity cli. As we've extended the features inside kubectl-helm-minikube, we felt that it be better named "cloud-native", but we're also happy just to make the changes to the existing feature.

It's still a work in progress, needs testing and documentation, but we'd like to understand how to best make the actual contribution before opening a PR. We've done testing by sampling exporting the required environment variables, but we'd like to understand if it's possible to try the actual vscode "Add dev container configuration files" flow.

I appreciate your guidance or comments.

ps, re-reading the thread I already noticed we're missing the tests, we'll get to it soon.

[bamurtaugh]

Hi @rjfmachado, thanks so much for working on this!

You're certainly welcome to self-host this cloud-native Feature.

As some general guidance, we generally encourage folks to think in separate components, i.e. making individual tools their own Features. But you can certainly create larger or more comprehensive Features if that's what works well for your scenario.

If you'd like your Features to appear in our public index so that other community members can find them, you can do the following:

• Go to github.com/devcontainers/devcontainers.github.io
  • This is the GitHub repo backing the containers.dev spec site
• Open a PR to modify the collection-index.yml file
  • This index is from where supporting tools like VS Code Dev Containers and GitHub Codespaces surface Features for their dev container creation UI

Please let us know if you have other questions or feedback!

[rjfmachado]

Thank you @bamurtaugh, those last steps did help connect the dots as to how this works e2e.

We do think the cloud-native feature has a "better together" story to it, things like kubelogin will be almost mandatory for AKS users with newer versions of Kubernetes and will most times have to be installed with kubectl. The other tools are more niche, we may consider and host separate features for them.

We'll look into hosting the feature(s) as suggested and will create it from scratch from the template as well.

[bamurtaugh]

Sounds good, thanks @rjfmachado and looking forward to hearing how it goes for you! We're happy to help and eager to hear your feedback along the way.

[rjfmachado]

hi @bamurtaugh, we've created https://github.com/devcontainers/devcontainers.github.io/pull/81 and have the source feature here https://github.com/rjfmachado/devcontainer-features. 1st time, appreciate if you can spare some time to see if we've missed something.

Thanks, Ricardo and Adrian

[rjfmachado]

hi @bamurtaugh , we've managed to get this to work after a few "puzzling moments" with some of the recent changes. We had to disable the options as we havent managed to trigger the options choices to show in vscode ui. So we'll have to look into this.

Another thing, that I'm not sure where to best report: If going through the vscode > Dev Containers: Add dev container configuration files UI, it will add my feature to the devcontainer.json, if running vscode locally (tried in wsl).

{ "name": "Ubuntu", "image": "mcr.microsoft.com/devcontainers/base:jammy", "features": { "ghcr.io/rjfmachado/devcontainer-features/cloud-native:1": {} } ... }

But, if I try to do the same thing when in codespaces, the devcontainer.json does not get my feature added.

{ "name": "Ubuntu", "image": "mcr.microsoft.com/devcontainers/base:jammy", ... }

[samruddhikhandale]

If going through the vscode > Dev Containers: Add dev container configuration files UI, it will add my feature to the devcontainer.json, if running vscode locally (tried in wsl).

This is an interesting bug, I'll create an issue and look at resolving this.

[samruddhikhandale]

@rjfmachado Thanks for reporting, created an issue for tracking 👉 - https://github.com/microsoft/vscode-remote-release/issues/7584

[bamurtaugh]

Thanks for opening the PR and providing feedback @rjfmachado - exciting to see your work added to the index!

Thanks for opening the issue @samruddhikhandale. If you have other issues or questions @rjfmachado, please let us know.

[rjfmachado]

Thanks for all the support @samruddhikhandale @bamurtaugh, this was fun and tons of learning. We'll look into feature options now and the intent to allow users to pin a specific version of the installed tool. Q: will vscode bring the options choices for selection in the UI or do we need to specify in the .json file?

[samruddhikhandale]

Q: will vscode bring the options choices for selection in the UI or do we need to specify in the .json file?

We still need to discuss if we should prompt for options for every Feature which user has selected. If we do then we will take advantage of options property in devcontainer-feature.json. That's how we are currently prompting options for Templates.

[rjfmachado]

Thanks all, I'll close this issue.