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.