[Container-tools] Improving the atomic.app developer experience

[Dusty Mabe]

On 03/01/2016 05:01 PM, Josh Berkus wrote:
> Folks,
> 
> So as of 1.0, we will have an excellent packager format for 
> Atomic/Nulecule apps and the Atomic platform.  However, what we will not 
> have is a tool which makes it easier for developers to package their 
> applications.  I think that's something we can do, but we'll need to 
> build 2.0 to do it.  The goal is to have an atomic.app which saves 
> developers work, so that they *want* to use it.
> 
> Here's the main areas I can see where we can make atomic.app better for 
> developers in priority order:
> 
> 1. File Generation:  right now atomic.app requires typing out/copying 
> multiple files in multiple locations, most of which are duplicative of 
> standard templates or each other.  Really, we should be able to take 
> just a tree file alone from the user and generate all of the other 
> files, except in the "advanced" cases.  All of the other files are 
> derivative of that tree file and 3rd-party APIs.
> 

So basically 'automatically' generating provider config files
(kubernetes, openshift, mesos/marathon, etc..). Is that correct?


> 2. Security and Permissions: we need a way for developers to be able to 
> use their chosen tools on their desktop, but still use atomic.app to 
> build apps (see prior email).  As a bonus, we could offer the ability to 
> set SELinux permission requirements as part of the atomic.app format; 
> that would not only make atomic.app valuable, it would ease the tendency 
> of developers to just disable SELinux.

+1. 

> 
> 3. Integrated Image Build: as the next step, it would really help 
> developers if we could build their images (e.g. myuser/mywebapp), 
> register them, and then deploy them via atomic app as one command.  This 
> would mean that users would just provide a tree file and a set of source 
> code repos (with dockerfiles) and one command would do the rest.

+1 - I've thought about this myself. Basically we specify a git
repo where the Dockerfile + context directory live as part of the
Nulecule. Atomic App doesn't have to be the tool that is capable of
interpreting this information and doing the build, but being able to
specify it in the spec is interesting.

Atomic App probably could pull off the "build" part in the case of a
local kubernetes or basic docker provider but in cases where you have 
to push to a registry it might get more complicated.

Either way.. having the ability to take a Nulecule and not "rely" on
any images being built and basically putting it in the oven and
building everything to completion and then running would be
attractive. It would also make it easier to confirm that the source
bits that exist out there still work and haven't rotted in some way.

> 
> Now, I'm not wedded to any particular way to accomplish the above; 
> whether it's via atomic.app, Cockpit integration, or even Ansible is 
> fine with me as long as the installation and the steps are simple.
> 
> Thoughts?
>