Hi Patrik, We have a few layers for php and nginx (http://interfaces.juju.solutions/). While are almost exclusively written in Python, Bash is another supported language for creating layers (though, with less bash layers written at the moment, it's likely not as well tested as Python).
Marco On Mon, Jan 4, 2016 at 9:39 AM Patrik Karisch <patrik.kari...@gmail.com> wrote: > Hi Marco, > > seems the best way to do so. Better supply my correct configuration of > nginx and php-fpm instead relying on another charm. Pro: My webapp charm > can specialize all config params. > > I've read the charm layers already and they seem interesting to build > different webapps. Although I must read more how my charm can adapt config > stuff from the layer and create one a layer for my nginx/php needs. And I > have to research in which languages I can use the reactive pattern, because > I don't know Python :) > > Thanks, > Patrik > > Marco Ceppi <marco.ce...@canonical.com> schrieb am Mo., 4. Jan. 2016 um > 15:13 Uhr: > >> Hi Patrik, >> >> It's best to think of the charm as an entire solution for the >> application/component your deploying. So if you need a web server to make >> this solution complete, it's best to include it. There are some exceptions >> to this, but generally speaking it's the rule of thumb. >> >> If you're looking to avoid re-implementing logic for apache2, or other >> common components, then I'd suggesting taking a look at charm layers. Charm >> layers give the same concept of composition as juju does with services, but >> at the charm creation level. >> https://jujucharms.com/docs/stable/authors-charm-building these are some >> early docs and we'll have a fully rewritten author docs around charm layers >> up in a week or so. >> >> Marco >> >> On Mon, Jan 4, 2016 at 6:54 AM Patrik Karisch <patrik.kari...@gmail.com> >> wrote: >> >>> Hi all, >>> >>> if I create a charm for my webapp, should it already install the >>> webserver or should it only provide a interface as subordinate for e.g. the >>> apache2 charm? In the first case, each webapp must be run in separate >>> containers as a minimum.. But I think scaling up is much easier, because it >>> provides the server. What do you think? >>> >>> Another unclear point for me. If I use the apache2 charm with >>> apache2-reverseproxy subordinate to proxy different webapps (everyone in >>> it's own LXC container) on the same host, is it easy to remove the >>> reverseproxy subordinate charm to deactivate the webapp easily? >>> >>> Best regards >>> Patrik >>> >> -- >>> Juju mailing list >>> Juju@lists.ubuntu.com >>> Modify settings or unsubscribe at: >>> https://lists.ubuntu.com/mailman/listinfo/juju >>> >>
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
