Коротко о Tomcat

Осваиваем конфигурацию сервера Tomcat и узнаем, что иногда XML не избежать.
В прошлом месяце мы установили Tomcat, написали сервлет и развернули его. Как мы узнали, у Tomcat сразу есть вполне рабочие настройки. Но ведь ни одного уважающего себя системного администратора не удовлетворят настройки по умолчанию? Поэтому на нашем уроке мы немного поработаем с файлом настройки Tomcat /etc/tomcat6/server.xml. (Если вы со мной с самого начала, то помните, что я пользуюсь стандартными пакетами Tomcat из репозиториев CentOS, установленными в CentOS 6.2.) Немного сокращенная версия этого файла показана ниже. Я только убрал комментарии и несколько более продвинутых настроек, но файл по-прежнему вполне рабочий. Компоненты этого файла имеют строгую иерархическую структуру, которой точно соответствуют вложенные прямоугольники:
<Server port=”8005” shutdown=”SHUTDOWN”>
<Service name=”Catalina”>
<Connector port=”8080” protocol=”HTTP/1.1” connectionTimeout=”20000” redirectPort=”8443” />
<Connector port=”8009” protocol=”AJP/1.3” redirectPort=”8443” />
<Engine name=”Catalina” defaultHost=”localhost”>
<Realm className=”org.apache.catalina.realm UserDatabaseRealm” resourceName=”UserDatabase”/>
<Host name=”localhost” appBase=”webapps” unpackWARs=”true” autoDeploy=”true” xmlValidation=”false” xmlNamespaceAware=”false”>
</Host>
</Engine>
</Service>
</Server>
Рассмотрим некоторые компоненты более подробно. Коннектор (Connector) - компонент, который слушает соединения на указанный порт. В нашем файле настройки два коннектора. Первый - коннектор HTTP; он слушает порт 8080. Благодаря этому коннектору Tomcat может работать как самостоятельный web сервер. Статический контент (включая чистый HTML и изображения) обслуживает напрямую, а другие запросы передаются движку сервлетов. Второй, коннектор AJP, слушает порт 8009, который можно выбрать, если вы хотите скрыть Tomcat за Apache. Подробнее об этом поговорим немного позже.
Движок сервлетов [Engine] представляет механизм обработки запросов, связанный с сервисом. Он принимает и обрабатывает запросы от одного или нескольких коннекторов и возвращает результат браузеру через те же коннекторы. Важный атрибут тэга <Engine> - “defaultHost”. Он определяет хост, который будет обрабатывать запросы, направленные хостам, обслуживаемым этим движком и не соответствующим ни одному из заданных хостов. (Вскоре, надеюсь, станет понятнее.)
Хост [Host] задает виртуальный хост (его можно представить как webсайт), запросы для которого обрабатывает его движок. В Tomcat для реализации виртуального хостинга (то есть когда один сервер обслуживает несколько сайтов) достаточно поместить несколько контейнеров <Host> внутрь одного движка Engine. Важные атрибуты тэга <Host> - name и appBase. Вместе эти атрибуты связывают имя сайта - например, www.linuxformat.
Если вы знакомы с Apache, то это похоже на директиву контейнера <VirtualHost> в файле настройки Apache. Как и с виртуальным хостингом в Apache, нам потребуется небольшая помощь от DNS, который нужно настроить для разрешения имен всех наших сайтов на IPадреса нашего сервера Tomcat. Позже мы создадим дополнительный виртуальный хост в нашей конфигурации Tomcat.
Осталось обсудить еще один компонент - <Context>. Он задает свойства web приложения, запущенного на связанном с ним хосте <Host>. Компоненты <Context> можно размещать в тэгах <Host> прямо в server.xml, но в поставке Tomcat по умолчанию делается иначе. Вместо этого контексты определяются в каталогах вида $CATALINA_HOME/conf/<engine_name>/<host_name>. В нашей установке по умолчанию имя движка - Catalina, а единственный хост - localhost, поэтому имя файла будет таким: /etc/tomcat6/ Catalina/localhost.
URL связываются с ресурсами так: http://www.example.com:8080/trainina/test.html
Имя виртуального хоста. Tomcat Tomcat использует самое длинное связывает его с элементами <Host> из возможных соответствий для выбора должной appbase доступным контекстным путям
$CATALINA_HOME appBase, заданная для этого хоста
/usr/share/tomcat6/webapps/demo/test.html
<Realm className=”org.apache.catalina.realm” reloadable=”true”>
Путь контекста (“/training”) задает URL (часть, которая идет сразу после имени хоста), а docBase - имя каталога (в appBase для этого хоста), где находится контент соответствующего сайта.
Запутались? Нас таких много! Взгляните, как URL преобразуется в имя ресурса, который на самом деле выдается по запросу.