Add self-contained installer container

[FloThinksPi]

Introduce a Docker-based installation approach that bundles all required tooling (kind, kubectl, helm, helmfile, cf CLI) in a single container image. Users now only need Docker installed on their host.

Changes:

• Add Dockerfile with Alpine base and all CLI tools
• Add .dockerignore to keep image minimal
• Refactor Makefile to run commands inside container
• Mount temp/ and docker socket for cluster management
• Update README with simplified prerequisites and usage
• Modify init.sh to use native openssl/ssh-keygen (available in container)

The original make targets (up, down, login, bootstrap) work as before, but now automatically build and use the installer container. Internal targets prefixed with _ can still be used directly if tools are installed on the host.

[c0d1ngm0nk3y]

But not using the local kind has the drawback that it make local development of the cloudfoundry components a bit harder. Right? Is it worth it? We already use docker for dependencies where it makes sense - at least we thought so. The prerequisites are rather minimal.

This is the workflow that would get a bit more complicated I guess.

[FloThinksPi]

@c0d1ngm0nk3y

But not using the local kind has the drawback that it make local development of the cloudfoundry components a bit harder. Right? Is it worth it? We already use docker for dependencies where it makes sense - at least we thought so. The prerequisites are rather minimal.

This is the workflow that would get a bit more complicated I guess.

Not really, docker, kubectl as well as kind are tools that interface with the kubeapi or docker deamon via network. I tested that and it does not really make a difference when you create a cluster in the containers kind and then query it with the hosts kind. Similar to all the other tools.

The Local development doc thus only needs an addition that recommends(optionally) to use make shell to run the kind and other commands in the right version in a shell in the container, localy installed is still possible but then one needs to take care about the installed tools themself and i see no big benefit in doing so since the dev usecase should work as is. I need to try it out though and add the make shell command to the local development docs.

It has the benefit for you that you can rely on functionality of specific versions and this deployment does not need to support a ranges of versions of tooling e.g. helmfile v3 and v4, openssl, etc. It may make the life of the project easier (even if more tools are added its stays the same pattern) as it gurantees that in the container everything matches version wise and is also renovate bumped :)

Plus for someone just wanting to consume this this also has the benefit of being distributeable via docker hub or gh container registry. Then as a consumer i just pull the container and setup CF which is from a pure "i want to get a local CF running to try something out" maybe also a nice workflow.

[pbusko]

It has the benefit for you that you can rely on functionality of specific versions and this deployment does not need to support a ranges of versions of tooling e.g. helmfile v3 and v4, openssl, etc.

We're already using the most vital tools as docker images, leaving only kind and kubectl as external.

[c0d1ngm0nk3y]

@FloThinksPi I finally found the time to try it out and there are 2 points that are not so nice and tbh, I am not sure if it is worth it for this minimal (to me nearly academical) improvement (see comment from Pavel):

• For the first use of make up, it just does nothing for over 2 mins. I had to look at the pr to figure out what is going on. OK, we can build the docker image not quietly, but still it would add 2 mins for people that want to try it out. Of course only for the first time.

• Although it is true, that you can work with kind, it will no longer edit the default context, so you would have to get the kubeconfig yourself. That is not a big deal, but it is kind of nice that you can call make up and directly interact with kubectl and k9s.

I see the benefit for the "I only want a CF API" use case, but on the other hand it only needs kind' and kubectl. So when you are interested in k8s, realistically only kind`.

[ZPascal]

Suggested change

	FROM alpine:3.21@sha256:c3f8e73fdb79deaebaa2037150150191b9dcbfba68b4a46d70103204c53f4709
	FROM alpine:3.23@sha256:c3f8e73fdb79deaebaa2037150150191b9dcbfba68b4a46d70103204c53f4709

It's better to use the current Alpine version instead of the old 3.21 release.

[ZPascal]

I've asked myself: Is ash (the default Alpine shell) not enough for this case? Is bash really necessary?

If yes, we should also add the bash-completion package to handle the bash autocompletion.