"Running in a Container" install topic out of date

[spadgett]

This topic is no longer accurate now that the console is a separate component, but it seems like it's generally out of date.

https://docs.openshift.org/latest/getting_started/administrators.html#running-in-a-docker-container

Related to #8009 and #8074
/assign

[spadgett]

cc @openshift/sig-master

This topic looks pretty out of date. It seems like we should be recommending cluster up.

[cdancy]

I'd also push back on recommending "cluster up" for the reasons noted in the prior issue. If anything give users a choice as to what they want as some, like myself, would rather not install another dependency just to start a docker container.

Can we also update the docs to say HOW to bring up the web console as this is no longer baked in? Thanks AOT!

[spadgett]

@cdancy It's not just the web console. You're missing a lot of basic components like the registry, router, service catalog, example image streams and templates. cluster up is doing a lot more than running a container.

I'm not sure what impact the changes coming in 3.10 will have on these steps either. cc @deads2k

[cdancy]

@spadgett that's fair but for local development, and just general playing around and getting your feet wet, you typically don't care about such things. If you're just writing code to work against origin/kubernetes, and you're trying to wire up some automated process, you just want something stupid-simple up and running quick that you can play around with on your desktop whilst leaving the "bigger" things to a more production oriented deployment.

[deads2k]

@spadgett that's fair but for local development, and just general playing around and getting your feet wet, you typically don't care about such things. If you're just writing code to work against origin/kubernetes, and you're trying to wire up some automated process, you just want something stupid-simple up and running quick that you can play around with on your desktop whilst leaving the "bigger" things to a more production oriented deployment.

That is where oc cluster up is going. We are moving away from a monolithic process into separate ones. Once you choose to do that, you have to decide how to easily wire them up together. One option is a bash script like hack/local-up-cluster.sh in kube, but as you start working with that you end up hitting numerous sharp edges that have produced a mega-bash script with dozens of env vars. Another option is to have a structured launch flow that "just works" and produces a cluster which can be evolved if you want to do something special or just used if you just need defaults.

Since openshift and kube are used to orchestrate containers, having the container runtime to back them is a fairly low bar as a prereq and one that allows us to make a unified dev launch flow that makes easy things easy and hard things possible.

[cdancy]

@deads2k yeah that all makes sense and aligns with what kubernetes does today with some 10+ containers required to get things off the ground. But if this is the case then remove that all-in-one solution from the documentation! ;)

[soltysh]

Yeah, removing this entirely from 3.9 docs onward does make sense. We will have to write the new one once the new oc cluster up is ready. I'll open a PR shortly.