The devonfw ide needs to be prepared for microservices development

[maybeec]

As a developer I would like get a fully setup development environment for microservices on quarkus including (in a best case kubernetes / docker / any additional vscode integrations) in order to start working at day one.

• evaluation of eiPaasBox
• possibly simply apply scripts in case kubernetes and or docker is not yet installed
• evaluate scripting non-invasive WSL2 setup
  • for example: make sure it's compatible to other existing network setups
  • clearly define preconditions for WSL2 setup
  • evaluate on different shores whether WSL2 setup is possible
• clearly be able to state basic system requirements to develop microservices (especially on RAM preconditions of developer machines)

[isandesh1986]

Started working on this. Currently evaluating eiPaasBox.-- Done. eiPaasBox considered to be heavy to ship with the virtualbox and even 12GB of max memory looks to be memory intensive. eiPaasBox is taken out of the scope of this issue.

[maybeec]

Acceptance Criteria for end of April - focus on win10:

1. devonfw-ide should be able to check whether wsl2 is enabled on win10
2. devonfw-ide should be able to check if there is a linux distribution installed
3. devonfw-ide should be able to check whether kubernetes is installed on linux subsystem
4. devonfw-ide should be able to check whether docker is installed (on windows or on linux (subsystem))
5. devonfw-ide should be able to install kubernetes on linux subsystem
6. devonfw-ide should be able to install docker on linux subsystem
7. devonfw-ide should be able to setup the network in case on win10 for linux subsystem without destroying previously configured namingservers (keep VPN/corporate network working)

[hohwille]

I am happy to discuss all these changes. Some first thoughts already:

• We should not forget that the devonfw-ide is designed using a sandbox principle. It currently avoids global installations and therefore such global tools like git-for-windows are installed once by the user as a prerequesite. This is not a dogma and I am open to discuss as I sayed. Still the main goal of devonfw-ide is automating the initial setup as well as updates during project lifecycle of all the required tooling.
• We should not forget that devonfw-ide is platform agnostic and should work on windows, linux and macos.

BTW: I just installed docker desktop on my MacOS system that is as easy as installing git and already integrates with kubernetes. So in my case I would question why I would need installation support from devonfw-ide at all in this case.

That being sayed, we should IMHO start agile with this:

• lets first focus on windows that is our main platform (80% case)
• lets first start with some loose scripts out of devonfw-ide to do such setup. This makes it possible to create a solution by anybody with docker, kubernetes and WSL2 experience but without knowing all the details of devonfw-ide. Further something like this can be tested and provided in isolation much more easily. Once we have this working fundamentally, I am happy to do all the integration and potential aligning/refactoring/etc.

Besides the main pre-requesites of having docker and kubernetes running on your machine the question is IMHO more how do we then run things in there? Does that have to be part of devonfw-ide at all or do we just have some scripts that work standalone. Or is the tooling already considered as a commondity so developers only need yaml files and will run docker compose, etc. themselves? Or what role would devonfw-ide have to play here?

[maybeec]

Yes I agree, the sandbox principle for me is critical and should be maintained as much as possible.
We made some analysis on whether to provide IaC / Cloud tools also ootb and portable, but hat quite some trouble here.
I would strongly suggest to think about a few exceptions like for docker, (possibly vagrant), kubernetes.

What we actually can start with to enable custom provisioning would be the script support, I fully agree.
Then we can think of what steps we need to do on network setup between WSL2 and windows.

I also agree that windows would be just the starting point. I think even that having a look and integrating seemlessly with WSL2 might bring some value in case of command interoperability.

Besides the main pre-requesites of having docker and kubernetes running on your machine the question is IMHO more how do we then run things in there? Does that have to be part of devonfw-ide at all or do we just have some scripts that work standalone. Or is the tooling already considered as a commondity so developers only need yaml files and will run docker compose, etc. themselves? Or what role would devonfw-ide have to play here?

I think devonfw-ide should pre-setup the environment and bring them into shape, that you can run helm charts or terraform exectutions against your locally installed kubernetes. That would be my assumption. As learned from tkit, this might need some adaptions to the network interface especially if you work within VPN connections, which is quite common sense in our days.

[GuentherJulian]

Is there anything to do for this issue at the moment or can it be closed? With issue devonfw/ide#584 a first support for Docker and Kubernetes integration was made. Do we need additional commands e.g. for setting up helm or terraform?