[almighty] Ensuring Production-like Environments

Andrew Lee Rubinger alr at redhat.com
Tue Nov 1 18:24:35 UTC 2016


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.

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.

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.
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.
3) Is it reasonable to assume that we can use the same image to build the
application as we would to run it?  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.

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).

S,
ALR

[1] https://eclipse-che.readme.io/docs/recipes

-- 
Red Hat Developer Group Architecture
@ALRubinger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20161101/b07a4f6c/attachment.htm>


More information about the almighty-public mailing list