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

Brian (bex) Exelbierd bex at pobox.com
Wed Mar 2 13:18:00 UTC 2016


On 03/01/2016 11: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.

As I recall there was some discussion around devconf.cz about taking 
nulecule in a direction of more sensible defaults and simplification to 
try and make the files easier to comprehend and generate.

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

This is some of what I took away from the conversation I reference 
above.  I think that we need to think about what kind of 
stubbing/scaffolding support we want to assist developers with in 
general.  We could easily extend Atomic App to do this, but it needs to 
be in a way that is accessible to everyone on all platforms.

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

One thing we need here for the ADB is the ability to enter the atomicapp 
workflow from the desktop ...

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

I believe this is a key feature and benefit of using OpenShift.  Does it 
make sense for the use cases to add s2i like functionality to other 
situations such as pure docker or kubernetes?

regards,

bex




More information about the Container-tools mailing list