[Container-tools] Nulecule/AtomicApp BoF at OSCon

Mon Aug 3 14:03:38 UTC 2015

Scott McCarty, RHCA
Product Manager: Container Strategy
Email: smccarty at redhat.com
Phone: 312-660-3535
Cell: 330-807-1043
Web: http://crunchtools.com

Did somebody say Satellite 6.1 is a Docker Registry server? http://red.ht/1SA5JF7

----- Original Message -----
> From: "Aaron Weitekamp" <aweiteka at redhat.com>
> To: "John Mark Walker" <johnmark at redhat.com>
> Cc: "container-tools" <container-tools at redhat.com>
> Sent: Wednesday, July 29, 2015 10:37:45 PM
> Subject: Re: [Container-tools] Nulecule/AtomicApp BoF at OSCon
> 
> 
> 
> 
> On Tue, Jul 28, 2015 at 10:37 AM, John Mark Walker <
> johnmark at redhat.com > wrote:
> 
> 
> 
> 
> 
> 
> 
> On Jul 28, 2015 9:25 AM, Daniel J Walsh < dwalsh at redhat.com > wrote:
> > 
> > 
> > 
> > On 07/28/2015 08:43 AM, James Shubin wrote:
> >> 
> >> On Mon, 2015-07-27 at 20:07 -0400, Langdon White wrote:
> >>> 
> >>> However, I wanted to bring up one thing which came up. One of the
> >>> people
> >>> 
> >>> asked me "how is this different from config mgmt a la chef".
> >>> While I
> >>> 
> >>> know in my head it is different,
> >>> 
> >> I agree...

Getting back to this question. I see container image (and glance image) builds as being a software supply chain that roughly follow the following paths [1]. For customers, provenance is the key governing factor [3][4]:

Custom Development
OS (vendor) -> Operations Team Core Build -> Middle-ware Stack (customer) -> Development Team (customer)

Commercial Off the Shelf Software
OS (vendor) -> ISV Software (vendor)-> Operations Team Core Build (customer) -> Development Team (customer)

At each of these stages, a Dockerfile could/should be used. 

I think the current configuration management tools (chef, puppet, ansible, salt, cf), as of August 2015 are nicely called from Dockerfiles during container build. Current configuration management tools are quite good at doing complicated installations, including configuration settings, etc. Interestingly, each team could use which ever CF tool they want without interfering with each other.

In my lab, at the OS stage, I have Kickstarts for building Glance/RHEV images, and Dockerfiles for building "container images." Both the kickstarts and Dockerfiles call the same puppet modules during build. This works well TODAY, with no technology changes, to create a standard image for both. Security hardening and things that would traditionally be included in the core build are done at this stage.

In my lab, at further stages, I have separate Dockerfiles for Middle-ware, and code. In real life, each of these Dockerfiles could be owned by different teams as desired: Middle-ware, Developers, Operations, etc. These could be controlled with Satellite (as a registry server [5]), etc.

The black hole I currently see, is that no configuration management tool (nor is Red Hat), giving the community guidance on how to build containers in a standard way so that they CAN be layered (as above) and orchestrated. Looking at the official MySQL container image on DockerHub [2]. Notice how critical configuration options are actually reserved for startup.

[1]: http://crunchtools.com/core-builds-service/
[2]: https://registry.hub.docker.com/_/mysql/
[3]: attached
[4]: attached
[5]: attached

Best Regards
Scott M

> >> 
> >> 
> >> 
> >>> and potentially even a wrapper around
> >>> 
> >>> config mgmt, I was struggling with articulating a clear/concise
> >>> answer.
> >>> 
> >>> As a result, I thought I would raise it to the list.
> >>> 
> 
> This is perhaps the big question we need to answer.
> 
> >>> 
> >>> 
> >>> Included James Shubin (who may already be subscribed) as the most
> >>> 
> >>> expert-y config mgmt person I know for his perspective.
> >>> 
> >> I've thought about this, and the short answer is that it's a long
> >> 
> >> answer. Here's the shortest version:
> >> 
> >> 
> >> 
> >> They're different, but only because IMO, the config management
> >> tools
> >> 
> >> which would solve this problem elegantly, don't currently exist
> >> ATM.
> >> 
> >> 
> >> 
> >> Assuming it doesn't offend anyone, I see Nulecule as a stop-gap
> >> until
> >> 
> >> config management learns how to better build multi-container
> >> 
> >> applications. This won't happen for at least a year. Assuming I'm
> >> wrong,
> >> 
> >> please excuse this due to my lack of knowledge into some of the
> >> Nulecule
> >> 
> >> specifics.
> 
> 
> To be fair, nulecule should be viewed independently of atomic. As in,
> nulecule could be used by config management tools to define cloud
> native apps.
> 
> >> 
> >> 
> >> 
> >> Container-tools at redhat.com
> >> 
> >> https://www.redhat.com/mailman/listinfo/container-tools
> >> 
> > atomic +labels (install, run, uninstall) allows an developer to
> > define how his application runs inside of the Open Container
> > Format.
> > Nulecule allows the define how Multi-Container applications can be
> > run/installed, and then allows the developer a standard format
> > to ask administrators for additional configuration data like how my
> > replicas of each service would they like.
> > 
> > Orchestration tools can than take advantage of this tooling to
> > spread the application throughout the environment.
> > 
> > Daniel Riek could probably expand on this.
> 
> Aaron W also had some thoughts on this, I believe - Aaron?
> 
> 
> 
> I agree with Dan's summary. I think we should stick with a pretty
> simple story. It's a generalized installation pattern for container
> apps. Like any good installer you can pass in parameters. Like any
> installer it can be incorporated into other tools and workflows or
> used stand-alone.
> 
> 
> 
> 
> -Aaron
> 
> 
> 
> 
> -JM
> _______________________________________________
> Container-tools mailing list
> Container-tools at redhat.com
> https://www.redhat.com/mailman/listinfo/container-tools
> 
> 
> 
> _______________________________________________
> Container-tools mailing list
> Container-tools at redhat.com
> https://www.redhat.com/mailman/listinfo/container-tools
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Core Builds in the Age of Service - Core Workflow.jpeg
Type: image/jpeg
Size: 128810 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/container-tools/attachments/20150803/bbd85922/attachment.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Core Builds - Provenance & The Software Supply Chain	(OpenShift).png
Type: image/png
Size: 360246 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/container-tools/attachments/20150803/bbd85922/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Core Builds - Provenance & The Software Supply Chain	(DockerExtended).png
Type: image/png
Size: 372949 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/container-tools/attachments/20150803/bbd85922/attachment-0001.png>