httpd-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Httpd Wiki] Update of "RunningMultipleApacheInstances" by TimBannister
Date Wed, 03 Oct 2012 22:12:55 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Httpd Wiki" for change notification.

The "RunningMultipleApacheInstances" page has been changed by TimBannister:
http://wiki.apache.org/httpd/RunningMultipleApacheInstances?action=diff&rev1=7&rev2=8

Comment:
Changed “Apache” to “httpd” where this makes better sense, tidying, fixed some spelling
errors

  = Running Multiple Apache Instances =
  
- This is a Recipe for configuring multiple apache instances. While writing this recipe I've
noticed that there are other pages in this wiki that also deal with this subject, either tangently
or in more direct ways:
+ This is a Recipe for configuring multiple https instances. While writing this recipe I've
noticed that there are other pages in this wiki that also deal with this subject, either tangently
or in more direct ways:
-  * [[ExtendingPrivilegeSeparation]] -- run several apache instances behind a reverse proxy,
use high ports for the backend instances to improve security
+  * [[ExtendingPrivilegeSeparation]] -- run several httpd instances behind a reverse proxy,
use high ports for the backend instances to improve security
-  * [[DifferentUserIDsUsingReverseProxy]] -- run several apache instances behind a reverse
proxy, run each instance under an different unpriviliged user
+  * [[DifferentUserIDsUsingReverseProxy]] -- run several https instances behind a reverse
proxy, run each instance under an different unprivileged user
  
  Some of the ideas in this recipe have already been advanced in these other wiki pages. However,
the focus of this recipe is more on the operating system support (FreeBSD, Ubuntu) for this
type of set up. The operating system usually provides facilities, such as rc(8) in BSD systems,
or init(5) in Linux and other SysV systems, that help admins in launching processes after
sucessfully booting the system. 
  
@@ -19, +19 @@

  
  === Or: why do we need to run multiple apache instances in one host? ===
  
- Although you can certainly have a single apache installation, running a single apache instance,
and still have different virtual hosts that can be accessed separately, sometimes following
this easy path can lead you to a heavy and bloated apache instance.
+ Although you can certainly have a single installation of Apache httpd, running a single
instance, and still have different virtual hosts that can be accessed separately, sometimes
following this easy path can lead you to a heavy and bloated web server.
   
- If your virtual hosts have different requirements (e.g. modperl for one virtual host, modpython
for another, and maybe modphp for a third virtual host), then your apache instance is almost
surely a RAM eater. Remember that apache will instantly spawn new child processes of the same
instance as needed ... if your perl web app is being frequently accessed, why spawn several
instances of an httpd process that is also loaded with modpython, modphp and an assortment
of other modules that, at least from the standpoint of the perl web app, are useless?
+ If your virtual hosts have different requirements (e.g. mod_perl for one virtual host, mod_python
for another, and maybe mod_php for a third virtual host), then your apache instance is almost
surely a RAM eater. Remember that httpd will instantly spawn new child processes of the same
instance as needed ... if your perl web app is being frequently accessed, why spawn several
instances of an httpd process that is also loaded with mod_python, mod_php and an assortment
of other modules that, at least from the standpoint of the perl web app, are useless?
  
- The answer to this, is simple: have separate lighter configurations for your modperl, modpython
and modphp apps, listening on different ports (e.g. 81, 82, 83), and have a reverse proxy
apache instance with virtual hosts configured to pass requests to the corresponding apache
instances. 
+ The answer to this, is simple: have separate lighter configurations for your mod_perl, mod_python
and mod_php apps, listening on different ports (e.g. 81, 82, 83), and have a reverse proxy
instance of Apache with virtual hosts configured to pass requests to the corresponding apache
instances. 
  
  In this recipe, I'll briefly explain how to do something along these lines: 
- Example: running different web applications listening in different ports, and using a reverse
proxy that forwards incoming requests (e.g. blog.company.com, svn.company.com, www.company.com)
to the corresponding apache instances.
+ Example: running different web applications listening in different ports, and using a reverse
proxy that forwards incoming requests (e.g. blog.company.com, svn.company.com, www.company.com)
to the corresponding https instances.
  
  == HowTo ==
  
  How do we configure apache so that we're able to start/stop/restart individual instances?

  
- Because apache allows you to load modules dynamically, most of the time, a single installation
of apache can serve the needs of multiple instances, and every instance may be configured
to run different sets of modules. As an example, you can run a very lightweight proxy module,
a modperl instance to run your perl web applications, a modpython instance with DAV to run
subversion, a separate instance running PHP, etc, all from a single local installation of
apache. Unless you have a requirement for a custom built apache instance (e.g. tweaking compile
options differently for different instances), you don't really need to compile and install
apache to different places (prefixes), as many online guides suggest. 
+ Because apache allows you to load modules dynamically, most of the time, a single installation
of apache can serve the needs of multiple instances, and every instance may be configured
to run different sets of modules. As an example, you can run a very lightweight proxy module,
a mod_perl instance to run your perl web applications, a mod_python instance with DAV to run
Subversion, a separate instance running PHP, etc, all from a single local installation of
Apache. Unless you have a requirement for a custom built instance (e.g. tweaking compile options
differently for different instances), you don't really need to compile and install httpd to
different places (prefixes), as many online guides suggest. 
  
  In FreeBSD, a clever port maintainer had set up a number of rc scripts that simplify the
task of launching all configured instances after booting the system. So if you're using FreeBSD
as your server OS, then you're lucky, as the configuration is painless. 
  
@@ -51, +51 @@

   make clean && make install clean
   }}}
  
- This will fetch the sources for apache (currently 2.2.17), extract them, and run configure,
make and finally install apache-22 on your system. As mentioned before, note that only one
local installation is required to run multiple instances of apache. Also note that if you
configure the port (''make config'') to enable mod_perl, mod_python (or any other dynamically
loaded module that does not come with the standard apache distribution), then the FreeBSD
ports system will 'Do The Right Thing(TM)' and will fetch, extract, configure, make and install
the code for the corresponding modules. Easy, huh?
+ This will fetch the sources for Apache (currently 2.2.17), extract them, and run configure,
make and finally install apache-22 on your system. As mentioned before, note that only one
local installation is required to run multiple instances of apache. Also note that if you
configure the port (''make config'') to enable mod_perl, mod_python (or any other dynamically
loaded module that does not come with the standard apache distribution), then the FreeBSD
ports system will 'Do The Right Thing(TM)' and will fetch, extract, configure, make and install
the code for the corresponding modules. Easy, huh?
  
- Note also, that there are other alternative apache ports in FreeBSD that will install different
flavours of apache:
+ Note also, that there are other alternative ports in FreeBSD that will install different
flavours of Apache https:
  
   * www/apache22-event-mpm
   * www/apache22-peruser-mpm
@@ -64, +64 @@

  
  '''2. Create your apache configurations'''
  
- In FreeBSD, the configuration files for the recently installed port live in '/usr/local/etc/apache22'.
There you will find a sample 'httpd.conf' file. This file may include directives found in
other conf files located in a directory called 'extra', at the same location. Please read
them, and familiarize yourself with their contents. If you've configured apache before, you'll
find your way around easily.
+ In FreeBSD, the configuration files for the recently installed port live in '/usr/local/etc/apache22'.
There you will find a sample 'httpd.conf' file. This file may include directives found in
other conf files located in a directory called 'extra', at the same location. Please read
them, and familiarize yourself with their contents. If you've configured Apache before, you'll
find your way around easily.
  
  Now, let's create a number of separate apache configurations. Essentially this means creating
different httpd.conf files, for example:
  
@@ -101, +101 @@

   LoadModule php5_module                        libexec/apache22/libphp5.so
  }}}
  
-  Now, we also need to configure the virtual hosts in the proxy instance, so that whenever
a request comes for the subversion DAV server, it is passed onto your 'python-dav' apache,
whereas requests for your wordpress blog are passed to your 'php' apache instance. Let's edit
'httpd-proxy.conf' again:
+  Now, we also need to configure the virtual hosts in the proxy instance, so that whenever
a request comes for the Subversion DAV server, it is passed onto your 'python-dav' httpd instance,
whereas requests for your wordpress blog are passed to your 'php' instance. Let's edit 'httpd-proxy.conf'
again:
  
   {{{
   # httpd-proxy.conf
@@ -124, +124 @@

   # you might need to use the "ProxyPreserveHost On" directive, depending on your configuration
   }}}
  
- So we're finished with the configuration, and now we need to launch all the apache instances,
and test that everything is working as expected. Of course you can do this using 'apachectl',
e.g.
+ So we're finished with the configuration, and now we need to launch all the instances of
httpd, and test that everything is working as expected. Of course you can do this using 'apachectl',
e.g.
  
   {{{
   /usr/local/sbin/apachectl -f /usr/local/etc/apache22/proxy-httpd.conf configtest
@@ -163, +163 @@

  apache22_php_enable="YES"
  }}}
  
- When these ''profiles'' are configured in /etc/rc.conf, and ''enabled'', they will be started
after successfully booting the system. If you want to declare a profile but you only want
to start the corresponding apache instance manually, you can just edit '/etc/rc.conf' and
say, e.g. :
+ When these ''profiles'' are configured in /etc/rc.conf, and ''enabled'', they will be started
after successfully booting the system. If you want to declare a profile but you only want
to start the corresponding httpd instance manually, you can just edit '/etc/rc.conf' and say,
e.g. :
  
   {{{
   # the apache php instance
@@ -171, +171 @@

   apache22_php_enable="NO"
   }}}
  
- Later, you can start/stop any apache instance manually using just the profile name (proxy,
perl, python, php), like this:
+ Later, you can start/stop any httpd instance manually using just the profile name (proxy,
perl, python, php), like this:
  
   {{{
   /usr/local/etc/rc.d/apache22 start php
@@ -196, +196 @@

  
  '''2. Create your apache configurations'''
  
- In Ubuntu, the configuration files for your recently installed apache are under '/etc/apache2'.
+ In Ubuntu, the configuration files for your recently installed webserver are under '/etc/apache2'.
  [writing in progress ...]
  
  There is some Debian/Ubuntu specific information in /usr/share/doc/apache2/README.Debian.gz
after installation.
@@ -204, +204 @@

  
  '''3. Configure the system to launch the apache instances after boot'''
  
- I'm not sure this will be similar (and painless) as in the case of FreeBSD (see section
on rc.conf above). The apache rc scripts installed with the apache port in FreeBSD have been
aware of the possibility of different profiles for years now. 
- 
- Recently, the ubuntu/debian init scripts (e.g. /etc/init.d/apache2) have been updated to
support multiple instances of apache (e.g. multiple configurations, named /etc/apache2-$SUFFIX).
Depending on the release of debian/ubuntu you're using you may be lucky ... or not. 
+ The Ubuntu/Debian init scripts (e.g. /etc/init.d/apache2) have been updated to support multiple
instances of (e.g. multiple configurations, named /etc/apache2-$SUFFIX).
- 
- The feature appeared in Debian in version 2.2.14-6 in Feb 2010: http://lists.alioth.debian.org/pipermail/pkg-apache-commits/2010-February/000295.html
- 
- In Ubuntu, the apache2 packages in Maverick (10.10) contain these patches: 
- http://changelogs.ubuntu.com/changelogs/pool/main/a/apache2/apache2_2.2.16-1ubuntu3.1/changelog
- 
- However the Lucid (10.04, Long Term Support Release) apache2 apparently do not:
- http://changelogs.ubuntu.com/changelogs/pool/main/a/apache2/apache2_2.2.14-5ubuntu8.4/changelog
  
  Documentation can be found in /usr/share/doc/apache2/README.multiple-instances
  

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org


Mime
View raw message