[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