Steve Loughran wrote:
Ralph Goers wrote:
Steve Loughran wrote:
Simone Gianni wrote:
The thing to remember about WAR files is that they are a packaging
format that is intended to make it easy to deploy web apps. Not
distribute, but deploy. The old WAR/EAR use cases always had the
'assembler' who would be some person who would somehow assemble WARs
and EJB beans to make a working app, presumably through some GUI
that required the same work to be repeated every release.
If you are doing lots of late binding tuning to the WAR file, then
perhaps build time is the wrong place to do it; it should really be
done as part of the deployment process, where per machine
optimisations can go in. In this world what you want from the outset
is the exploded WAR, which is then taken with server-specific
options to create the target WAR for the target system.
Pardon me for saying so, but this is just nuts.
:)
In my environment our CM folks do the build and then make it
available for operations. Noone after CM is allowed to modify the
parts. Any modifiable configuration has to be placed outside the
webapp. Furthermore, CM prefers that no exploded webapps be used,
since it is much easier to distrubute wars.
ok. So where do the per-system modifications go in? do your war files
have hard coded assumptions about LDAP bindings, JDBC URLS or rely on
the app server to set up the JNDI bindings for all the info kept in
your dir server?
We have a system property that specifies the location of an XML file
containing all these kinds of properties. Typically, it will go in the
JBoss server's conf directory. We also have a more extensive
configuration repository that is shared across servers and the XML
config file has the information to connect to it.
Next question: how do ops automate the 'provisioning' of the app
server? Do they have a piece of paper telling them what bits of the
system you need 'Redhat EL with Java 1.5.06 and the patches need to
/etc/profile to get it set up, or what services need to be running? Do
you find that they decide to try 1.5.09 without telling you? Or that
they forget to do something essential like bringing up the DNS server
before the database and app servers come up.
Ops never changes an OS version or Java version without it having been
verified in our QA area first. Everyone is informed before that
happens. I must admit I've never had to tell our ops folks that DNS and
the database must be up before starting the app server.
Because that's the kind of thing we can automate and lock down under
SCM. That lets us create a blank VMWare or Xen disk image, have it run
a PXE preboot to get the base image, then after it comes up we can
bring the system up to the state where the WAR file deploys.
In that world, you dont really need an opts team to deploy. You just
have a server that manages the build and deploy of the latest bit of
the SCM tree tagged as ready to go into production. It sticks it out
every night, and as server load increases, it brings up new machines.
The ops team take on a different role: managing the Xen/VMWare server
farm, monitoring the health of the (much larger) VM cluster, setting
up the approved system configurations. This is the stuff that Amazon
EC2 presumably does behind the scenes -an outsourced ops team.
That would probably never happen in my environment.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
