Home / Browse / yaws / Mail / Archive

yaws

Email Archive: erlyaws-list (read-only)

[Erlyaws-list] integrating yaws into OTP nodes

From: Hal Snyder <hal@va...> - 2004-03-22 23:27

Most new Erlang applications we write for our telephony platform
use yaws for status and control. We needed to work in a scheme of
configuration management to support this practice. Here's what we
have so far.

I wonder if anyone else is doing something similar and has comments.

This is gruesome and boring CM, but if we don't make it sensible
at our site at the outset we will make a zoo of varying ad hoc
directory setups and soon lose the ability to reuse code, simply
because of stupidity in the build system.

We keep source in CVS, but that doesn't really matter for this
discussion. Also unless you use pkgsrc, you'll be more accustomed to
/usr/local/ than /usr/pkg/ for site additions to the OS.


1. There are applications and releases.

Applications in our CVS tree are like the lib apps in the Ericsson
distribution.

Releases on the other hand combine several apps and libs into a single
node, with .boot and .script files and so on.


2. There are development and production modes.

When developing, a programmer works in "local mode" from his/her home
directory, inside a CVS work area. Non-Ericsson libs and yaws pages
and .boot and .script all come from the local sandbox.

In production, files are placed under /usr/pkg/vail/otp and run as
user "erts".


3. The layout.

Here is what happens in the programmer's CVS sandbox
(* marks derived files, -> marks symlinks):

otp/
  lib/
    my_app/
      vsn.mk
      src/
        xxx.app.src
        xxx.appup.src
        xxx.erl
      ebin/
        xxx.app*
        xxx.appup*
        xxx.beam*
      priv/
      yaws/
        yyy.yaws
      ...
    yaws/
      src/
      ebin/
      www/

otp/
  releases/
    my_app_rel/
      vsn.mk
      zzz.config.src
      zzz.rel.src
      yaws.conf.src
      zzz.rel*
      local/ (everything under here is generated by gmake)
        yaws.conf* (docroot points to this directory)
        zzz.config*
        zzz.boot*
        zzz.script*
        zzz.sh* (shell script to start the node in local mode)
        my_app -> ../../../lib/my_app/yaws
        my_other_app -> ../../../lib/my_other_app/yaws        
        index.html* (simple nav to all apps on the node)

Production:

/usr/pkg/lib/erlang/lib (usual Ericsson distribution) 
/usr/pkg/vail/otp/ (site files in production)
  lib/
    my-app-1.1/
      src/
      ebin/
      yaws/
  rel/
    my_app_rel-1.2/
      my_app_rel.boot
      my_app_rel.script
      my_app_rel.config
      my_app_rel.sh
      yaws.conf (docroot points to this directory)
      my_app -> ../../lib/my_app-1.1/yaws
      my_other_app -> ../../lib/my_other_app-2.5/yaws
      index.html (simple nav to all apps on the node)

We are just rolling out this arrangement. It permits multiple versions
of releases and libs to coexist. Users do not need to know version
numbers when typing URLs.

Normally we like all logs in /var, typically a filesystem for
scribbling. But here we wanted to keep installation simple, and for
that it helps to put all files associated with a release under one
directory.

We use autoconf and NetBSD's cross-platform pkgsrc to package and
deploy our OTP nodes.

Thread View

Thread	Author	Date
[Erlyaws-list] integrating yaws into OTP nodes	Hal Snyder <hal@va...>

Re: [Erlyaws-list] integrating yaws into OTP nodes

From: Mikael Karlsson <mikael.karlsson@cr...> - 2004-03-23 12:54

Tuesday 23 mars 2004 00:24 Hal Snyder wrote:
> Most new Erlang applications we write for our telephony platform
> use yaws for status and control. We needed to work in a scheme of
> configuration management to support this practice. Here's what we
> have so far.
>
> I wonder if anyone else is doing something similar and has comments.
>
> This is gruesome and boring CM, but if we don't make it sensible
> at our site at the outset we will make a zoo of varying ad hoc
> directory setups and soon lose the ability to reuse code, simply
> because of stupidity in the build system.
>
.. lots of CM stuff deleted...
>

OK, maybe my response is not right on topic, but could it be possible to
to have a more general way of handling yaws applications?  I would like to 
see some framework application that embeds yaws (or made within 
yaws itself), that deploys otp applications and yaws script files on the 
same time. So that you get a similar behaviour as a Java Servlet Container. 
It is not too hard to implement I think.

Erlang Servlets
- Implement an OTP application.

- in the /priv directory have a subdirectory (/yaws) that contains.
   html files and yaws scripts + a configuration file (like javas web.xml)
   that contains any data to be used by yaws config, like server paths, 
   used modules, environment variables, script bindings  etc.

- have a servlet container application (something like OTPs webtool) that:
-- runs yaws in embedded mode.
-- unpacks the OTP release.
-- add server configuration data to yaws from the web.xml 
    configuration file.
-- maybe copy the html and script files to some deployment dir.
-- starts the OTP application, using application controller in order 
     to run the new web service. In case it is just yaws scripts and Mod
     callbacks no new gen_servers need to start, but it should be OTP
     compliant anyway I think.
-- one should of course be able to stop the application and remove it
    from the configuration. And upgrade to new release versions, etc..

In this way we can have just one single Yaws-webserver, but 
deploy many applications independently (like btt, webmail, wiki) 
within it. Maybe also deploy several instances of 
the same app (like http://myurl/wiki1 and http://myurl/wiki2).
Now, if you also add mnesia to support all your erlang-servlets,
you get a distributed transaction capable little mean machine that
maybe could get those J2EE/EJB engines to look like {big, slow,
ancient, etc.}?

/Mikael