[Container-tools] Rethinking Nulecule
Carl Trieloff
cctrieloff at redhat.com
Thu Mar 10 18:14:51 UTC 2016
On 03/10/2016 01:09 PM, Lalatendu Mohanty wrote:
> On 03/10/2016 11:29 PM, Lalatendu Mohanty wrote:
>> On 03/10/2016 08:15 PM, Aaron Weitekamp wrote:
>>> On Thu, Mar 10, 2016 at 4:29 AM, Ratnadeep Debnath
>>> <rtnpro at gmail.com> wrote:
>>>
>>> Hi all,
>>>
>>> Till now, Nulecule's focus has been to be a spec to package and ship
>>> nested, composable multi container applications. Well, it helps
>>> us to
>>> focus on a smaller problem and solve it well. This also keeps
>>> implementation of Nulecule, e.g., atomicapp, lean and simple.
>>>
>>> However, is it enough?
>>>
>>>
>>> I will try to highlight a few shortcomings of the current
>>> Nulecule spec:
>>>
>>> - the spec file does not fully describe the architecture of the
>>> applications
>>> - it's difficult to get started with Nulecule as it requires
>>> knowledge
>>> of underlying providers
>>> - it's not possible to use the same Nulecule spec to deploy a
>>> Nulecule
>>> application across providers without writing artifacts for each
>>> provider
>>>
>>>
>>> So, we are thinking in the lines of extending Nulecule SPEC to
>>> describe a multi container application completely in the SPEC file,
>>> similar to Docker compose file. This will enable us to:
>>>
>>> - to automatically generate artifact files for underlying providers
>>> from the SPEC file
>>> - to override the generated artifact files, if needed
>>>
>>>
>>> The advantages of such a change would be:
>>>
>>> - zero barrier entry for developers
>>> - package once, in one language, and deploy anywhere
>>>
>>>
>>> This move will be beneficial to:
>>>
>>> - developers, with little knowledge about openshift, k8s,
>>> marathon, etc.
>>>
>>>
>>> I disagree that we can shoulder the burden of making openshift or
>>> kubernetes or anything else easier to use. We haven't been
>>> successful making our own tooling easy to use and adopt. The
>>> platform has to do this work.
>>
>> I think we all agree that Nulecule is a great idea. But to make it
>> successful with respect to community we need to make writing of
>> Nulecule spec relatively easier than writing Kubernetes configuration
>> files.
>>
>> Either we take this task along with Nulecule/Atomic App or work with
>> Kubernetes project to do it. We can work with Kubernetes project for
>> this, but what should we do with other providers e.g. Mesos.
>>
>> I am taking Kubernetes example because if we fix it it will be
>> applicable to OpenShift too. Point to note that writing Docker
>> compose files is already easy as compared to Kubernetes
>> configuration files.
>>
>> So the experience should be better then writing Kubernetes files and
>> better or equal to writing Docker compose files.
>>
>
> One of the advantage of Nulecule/Atomic App is we don't have to move a
> tar ball with all the artifacts with custom scripts and instructions
> to deploy the application in different environments e.g. test,
> production etc. However with containers automated pipeline which
> would move the application from test to production makes more sense
> and it kind of dilutes the advantage.
>
I saw Pradeepto's write-up on Helm/DM, using Nulecule for the 'bundle'
format with AtomicApp with Helm/DM - does that not mostly complete the
picture?
Carl.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/container-tools/attachments/20160310/0f817803/attachment.htm>
More information about the Container-tools
mailing list