Web App Interface

Merlijn Sebrechts merlijn.sebrechts at gmail.com
Mon Mar 7 10:28:00 UTC 2016


Very interesting idea, Tom!

Something that might help for your use-case are layer options
<https://github.com/juju-solutions/layer-basic/blob/master/README.md#layer-options>.
They are a way for layers to pass build-time config options to layers below
them.

Another thing that might be of interest is the payload concept
<https://insights.ubuntu.com/2015/10/22/charming-2-0-now-with-100-more-awesome/>
.

If we find a great way to do this, we might be able to swap out a
self-managed LAMP stack and replace it by a hosted LAMP solution that
implements the same 'payload interface', taking the modularity of Juju even
further...

2016-03-05 16:15 GMT+01:00 Tom Barber <tom at analytical-labs.com>:

> Yeah I think that's about right.  Currently saiku is subordinate of tomcat
> so we're basically locked in, which in reality is fine as we've not tested
> elsewhere but I like flexibility which is what juju relations offer.
>
> So it would be good to create a charm that maybe as Rick suggests provides
> a resource and implements a webapp interface that means I don't have to
> write a load of code to get it deployed on a bunch of different containers.
>
> I don't know much about the WordPress charm and that's php based but the
> idea would be similar to this where you could front WordPress with httpd
> nginx or haproxy just by swapping relations.
>
> Also for wars and stuff deploying them via actions is pretty grim as you
> loose the visiblity of what's deployed where which the relations give you.
>
> At the end of the day. A war is an app in a zip file that needs a
> container in exactly the same way my pdi charm requires a java interface to
> function, it needs a j2ee container.
>
> Cheers
>
> Tom
> On 5 Mar 2016 14:41, "Rick Harding" <rick.harding at canonical.com> wrote:
>
>> The Juju team is working on a feature called "juju resources" that can be
>> used to provide a blob to a charm to be used in the deployment. It sounds
>> like it might be interesting as a way to deliver the WAR file to the Tomcat
>> charm. The current beta1 implemented the local version where you can
>> defined and supply resources from your filesystem. Work is ongoing to be
>> able to pull those from the charm store.
>>
>> See the resources section of the beta release notes.
>>
>> https://lists.ubuntu.com/archives/juju/2016-February/006618.html
>>
>> All that being said, it might be interesting for some layer for a web app
>> resource where resources does some of the work you'd do in that layer. I'd
>> be interested to know what others think there.
>>
>> On Sat, Mar 5, 2016 at 6:40 AM Tom Barber <tom at analytical-labs.com>
>> wrote:
>>
>>> Okay so here's one I wanted to know if it made sense to people or not
>>> now there are layers, interfaces etc.
>>>
>>> Take Saiku or any other WAR based webapp. Currently our app is a Tomcat
>>> subordinate, which installs the WAR and a few other directories and just
>>> sed-s a few files to set some variables.
>>>
>>> In this land of layers and interfaces, does it make sense to have a
>>> webapp interface? I realise most of the current interfaces are for services
>>> and not file archives, but, if I deploy Tomcat, Wildfly, Karaf I know that
>>> (with a bit of tweaking) I can deploy a war to each of those and they
>>> should behave pretty much the same. So does it make sense to have an
>>> interface that lets me charm up my WAR file and then add a relation from
>>> WAR <-> J2EE Container so I can just link them together and have Juju place
>>> my WAR in the correct location?
>>>
>>> That way you can deploy on multiple services without having to do much,
>>> if anything, to your code.
>>>
>>> Cheers
>>>
>>> Tom
>>> --
>>> Juju mailing list
>>> Juju at lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20160307/c54f7cf7/attachment.html>


More information about the Juju mailing list