[almighty] Ensuring Production-like Environments

[Tomas Nozicka]

On Út, 2016-11-01 at 14:24 -0400, Andrew Lee Rubinger wrote:
> The general premise we need to get to is:
> 
> "Make every environment as close to production as possible."
> 
> With containers we're now closer than we've been before to doing development, testing, builds, and pre-production deployments in a production-like environment.
yes, it should be a standard since we have containers :)

> 
> The naive approach we could take looks like a single base image to be used across the board for online IDE development, testing, executing integration tests in the pipeline, deploying to pre-production, and production.  For instance, we may associate an EAP codebase with a centos-eap base image that's used throughout Eclipse Che and the various OpenShift deployments for testing and poking around during development.  The differences between this and production may be limited to externalizable sysprops, environment variables, persistent volume mounts, etc.
Having a single image for dev, build, pipeline and prodution would result 
in bloated image for prod which we probably don't want. And e.g. pipelines
right now require special image (with jenkins slave packages)
so that would not work there. (But pipelines can use some common image for build.)

> But the problem has nuance.  I'd like us to arrive at a proposal for how we associate a "runtime" with a codebase.  Some questions to address:
> 
> 1) A Git repository (Almighty "codebase") may have N target runtimes contained within.
yes, and these runtimes should be part of ConfigMaps
  http://kubernetes.io/docs/user-guide/configmap/
and other types for this task like secrets, which are separate yaml
files and the application definition stays the same across all
environments

> 2) Che "receipes" (images) require root or sudo access, plus other tools[1].  Does that mean we have to make an "IDE" image that extends from our base image?  We can't have the container (OS-level) user executing our servers/frameworks running as root.
Any image that runs as root *won't* be allowed to run on OpenShift,
especially on Online! There is an option to allow it but inherently
this means a *security breach*, so don't expect it in any non test
installation!

(There are user namespaces for some time in Docker to solve this
security issue, but I have not seen any progress on supporting them in
OpenShift yet.)

> 3) Is it reasonable to assume that we can use the same image to build
the application as we would to run it? 

I don't think so, although for simplicity and a lack of proper tooling,
people often skip this issue and use the same image. There should
generally be 2 images, with the exception of non-compiled languages,
one for build and other for runtime to separate build and runtime
dependencies. And finally, OpenShift S2I now supports this "2-phase
builds"! 

> Or that the image used to build extends from the image to run?  For
instance, EAP applications need the JDK to run, but additionally need
Maven to build.
I would say this may work for JDK/Maven and many others, but ain't
generally true. I could thing of an image that needs some components
for runtime that are not needed for build.


> 
> Appreciate thoughts on what we think the relationship is between the WebIDE, Build, and Runtime images, and additionally how those map to an Almighty codebase.  Mission: how can we unify these from the perspective of a user such that a user chooses the runtime set once and it's consistent throughout environments?
> 
> "It works on my machine" needs to be a thing of the past (except for sysprops, env vars, persistent volumes, etc which are inevitable).
+1

> 
> S,
> ALR
> 
> [1] https://eclipse-che.readme.io/docs/recipes
> 
> -- 
> Red Hat Developer Group Architecture
> @ALRubinger
> _______________________________________________
> almighty-public mailing list
> almighty-public at redhat.com
> https://www.redhat.com/mailman/listinfo/almighty-public