기본적으로 배포 하는 방법에 대해서는 앞서 설명 하였다.


Tomcat War Deploy 하기 (http://blog.whitelife.co.kr/240)


이해가 안되는 경우 위 글을 참고하기 바란다.


항상 Java Web Application 을 Build 하여 전체 배포를 할 수는 없다. 고객의 추가 요구 사항에 따라 프로그램 소스는 얼마든지 수정 될 수 있다.


JSP 파일만 수정되면 Restart 가 생략이 가능 하지만, 그 이외의 파일이라면 반드시 수행해야 한다.


  • server.xml
<Host name="localhost"  appBase="/home/users/parkmc/webapps"
    unpackWARs="false" autoDeploy="true" deployOnStartup="false">

<!-- SingleSignOn valve, share authentication between web applications
     Documentation at: /docs/config/valve.html -->
<!--
<Valve className="org.apache.catalina.authenticator.SingleSignOn" />
-->

<!-- Access log processes all example.
     Documentation at: /docs/config/valve.html
     Note: The pattern used is equivalent to using pattern="common" -->
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
       prefix="localhost_access_log." suffix=".txt"
       pattern="%h %l %u %t &quot;%r&quot; %s %b" />

</Host>


War 압축된 상태가 아닌, Context 경로에 직접 파일로 배포 하는 경우에는 unpackWARs="false" 로 설정 해야 한다. 기본적인 경로는 /ROOT 이다. 개별 적으로 추가가 필요하다면, Context 를 추가 한다.


/ROOT
    /META-INF
    /WEB-INF
        /classes
        web.xml


위의 폴더 구조에 따라 배포를 진행 한다. 파일 복사가 끝났다면, /bin/startup.sh 를 하여 서버를 시작 하자.


프로젝트가 마무리 되고, 실제 서비스 적용 할 때 두 가지 방법으로 나뉜다.


  1. WEB Server, WAS(Web Application Server)
  2. WAS(Web Application Server)

첫 번째 방법은 정적 요소인 Image, Css, Javascript 파일은 WEB Server 에서 응답 하고, 프로그래밍 요소가 들어간 요청 에 대해서는 역 프록시(Reverse Proxying) 하여 WAS 로 요청을 전달 한다. Business Logic 처리 후 결과를 응답 한다.
두 번째 방법은 WAS 에서 정적 요소와, 프로그래밍 요소가 들어간 요청을 받고 응답 한다.


보통 관리자 페이지는 내부 네트워크에 있는 PC 만 접근이 되야 한다. WAS 만 사용 하는 경우에는 프로그래밍 적으로 제한해야 하지만, WEB Server 사용 시 서버 설정으로 제한 할 수 있다.


  • /httpd/conf/httpd-vhosts.conf
<Location "/admin">
    Order mutual-failure
    Allow from 192.168.0.1
</Location>

ProxyPass / http://localhost:8080/
ProxyPassReverse / http://localhost:8080/
ProxyPreserveHost On


Directory 와는 다르게 Location 은 Url 기준 이다. 속성 값에 해당 주소를 설정 한다.


Order Value Description
1 deny, allow deny, allow 지시자 검사
2 allow, deny allow, deny 지시자 검사
3 mutual-failure 모든 접속을 거부 Allow from Ip 만 허용


allow 는 허용 되는 Ip 이고, deny 는 반대 되는 개념 이다.


참고 사이트


부팅 할 때 shift 버튼을 누른 상태로 하면, GRUB 메뉴 화면이 출력 된다. root 계정으로 부팅을 위해서는 파라미터 값을 수정해야 한다.


Ubuntu, with Linux 3.13.0-32-generic (recovery mode) 메뉴로 커서를 이동 하고, e 키를 눌러 보자.


부팅 할때 필요한 값들이 설정되어 있는 페이지에서 값을 수정 하자.


linux /vmlinuz-3.13.0-32-generic root=/dev/mapper/dev--vg-root ro recovery nomodeset


해당 라인을 찾아서 아래와 같이 수정 한다.


linux /vmlinuz-3.13.0-32-generic root=/dev/mapper/dev--vg-root rw init=/bin/bash


F10 키를 눌러서 부팅 한다.


root@(none):/# 


해당 문구가 나오면 부팅이 완료 된 것이다.


root@(none):/# sudo passwd root


비밀번호를 수정 한 후 재 부팅 하자.


참고 사이트


Java Web Application 은 build 하면 war 파일로 압축 되어 생성 된다. manager 기능을 사용하면 web page 에서 upload 하여 편리하게 deploy 할 수 있다. 하지만 기능이 제한되는 단점이 있다.


manager 기능을 이용한 배포는 해당 링크를 참고 하자. (http://blog.whitelife.co.kr/73)


직접 deploy 하려면 server.xml 파일을 설정 해야 하고, $CATALINA_HOME 환경 변수 설정이 되어 있어야 한다. tomcat 의 start, stop, deploy, undeploy 를 $CATALINA_HOME/bin/catalina.sh 가 담당 하는대, $CATALINA_HOME 가 정의 되어 있지 않으면, 아무 동작도 할 수 없다.


windows 는 고급 시스템 설정에 환경 변수, linux 는 home directory 의 ~/.bashrc 파일에 추가 하자.


  • 환경 변수



  • ~/.bashrc

# User specific aliases and functions

export JAVA_HOME=/home/whitelife/java
export CATALINA_HOME=/home/whitelife/tomcat
export PATH=$PATH:$JAVA_HOME/bin:$CATALINA_HOME/bin



server.xml 은 $CATALINA_HOME/conf 에 있는대, 이 정보를 기반으로 tomcat 은 동작 한다.


  • server.xml
<Host name="localhost"  appBase="webapps"
    unpackWARs="true" autoDeploy="true">

    <!-- SingleSignOn valve, share authentication between web applications
         Documentation at: /docs/config/valve.html -->
    <!--
    <Valve className="org.apache.catalina.authenticator.SingleSignOn" />
    -->

    <!-- Access log processes all example.
         Documentation at: /docs/config/valve.html
         Note: The pattern used is equivalent to using pattern="common" -->
    <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
           prefix="localhost_access_log." suffix=".txt"
           pattern="%h %l %u %t &quot;%r&quot; %s %b" />

    <!--<Context docBase="static" path="/static" reloadable="true"/>-->
    <Context docBase="test" path="/" reloadable="true"/>

</Host>


appBase, docBase 에 대해 알아야 구체적인 설정을 할 수 있다. appBase 는 상대 경로로 적용 되어 있으면, $CATALINA_HOME/webapps 를 참조 한다. 설치 후 고양이 마크를 볼 수 있는 화면도 하위 폴더인 /ROOT 에 있다. 만약 다른 경로를 사용하고 싶다면, 절대 경로로 설정 한다. docBase 는 appBase 하위 폴더 설정 이라고 보면 되는대, 기본적으로 appBase 에 ROOT Web Application 이 deploy 된다. 추가 적으로 deploy 하는 경우에 사용한다고 보면 이해가 될 것이다. 그 때 사용하는 tag가 context 이다.


docBase: appBase 하위 경로
path: host 뒤에 정의 되는 prefix (ex: path=”/test”, http://localhost:8080/test)
reloadable: class 파일 수정 시 redeploy 여부


deploy 를 예로 들면, appBase 경로에 docBase 이름을 가진 test.war 파일을 복사 하고, $CATALINA_HOME/bin 에 있는 startup 을 실행 한다. windows 인 경우 확장자는 bat, linux 인 경우 sh 로 한다. 서버가 시작 되면, 압축이 풀리면서 deploy 가 진행 된다.


테스트 페이지에 접속 하면 deploy 여부를 확인 할 수 있을 것 이다.


지금부터는 경험담 이다. appBase 를 상대경로로 하고, docBase 에 원하는 Web Application 을 deploy 했다. 문제점이 생길떄도 있고, 아닌 경우도 있었다. ROOT Web Application 으로 인식 하고 최초에는 ROOT 로 deploy 하고, 그 후에 deploy 를 한다. 두번 deploy 되어 라이브러리 충돌 하는 경우가 생겼다. 최근에 참 두려운 Exception 으로 자리잡은 ClassCastException 이다. Class는 존재 하는대, 무엇으로 Cast 할지 판단을 하지 못하여 발생 하는 것 같다. 정말 충돌 나는 지 확인을 위해 두가지 테스트를 했다.


  1. war deploy
  2. war 압축을 풀고 수동 deploy

2번 방법으로 했을때에는 이미 압축이 풀려 있기 때문에, ROOT deploy 를 하지 않았다. 정상 동작 하였다.


해결을 위해서는 appBase 만 설정 하고, ROOT.war 로 파일 명을 지정하여 deploy 하거나, 압축을 풀고 직접 수동으로 deploy 하면 된다. 취향에 따라 방법을 선택 하자.


Maven 을 사용 하는 경우에는 pom.xml 파일에 finalName 을 추가하여 mvn package 하면 원하는 파일명으로 war 파일을 얻을 수 있다.


<build>
    <finalName>ROOT</finalName>
</build>


통상 서버 구축 시 필요에 따라 정적 파일은 WEB 서버, 프로그래밍 요소가 들어간 파일은 WAS 가 처리 한다. 설정 방법에 대해 알아 보자.


  • /httpd/conf/extra/httpd-vhosts.conf

#
# VirtualHost example:
# Almost any Apache directive may go into a VirtualHost container.
# The first VirtualHost section is used for all requests that do not
# match a ServerName or ServerAlias in any <VirtualHost> block.
#
<VirtualHost *:80>
    ServerAdmin webmaster@dummy-host.example.com
    DocumentRoot "/home/sample/www"
    ServerName sample.co.kr
    ServerAlias www.sample.co.kr

    ErrorLog "logs/error_log"
    CustomLog "logs/access_log" common

    ProxyPass /upload !
    ProxyPassReverse /upload !

    ProxyPass / http://localhost:8080/   
    ProxyPassReverse / http://localhost:8080/   
    ProxyPreserveHost On

</VirtualHost>

ProxyPass /upload ! - WEB 서버에서 DocumentRoot 하위 파일을 참조 하여 응답 한다. 

ProxyPass / http://localhost:8080/ - WAS 로 리다이렉션 한다. 

ProxyPreserveHost On - WAS 로 리다이렉션 할때 HOST 정보를 함께 전달 한다.


위 내용을 적용 한 후 서버를 재 시작 해보자.


Tomcat의 Servlet 개발 시 HttpSession 클래스를 사용 한다. Session Timeout 설정을 위해서는, setMaxInactiveInterval(int interval) 함수를 사용해서 개별적으로 정해줄 수 있지만, 공통으로 사용할 수 있게 설정을 하는 편이 좋다. web.xml 에 아래 샘플을 추가 하자.


<session-config>
    <session-timeout>30</session-timeout>
</session-config>


session-timeout 은 분 단위로 설정 된다. 30 이라고 선언했다면 getSession() 할때 마다 Session 유효 시간은 30분 이다.

session 이 created, destoryed 되는 것을 확인 하고 싶을 때가 있을 것이다. HttpSessionListener 를 구현하면 확인이 가능하다.


  • HttpSessionCheckingListener.java
public class HttpSessionCheckingListener implements HttpSessionListener {

    private Logger logger = LoggerFactory.getLogger(this.getClass());

    public void sessionCreated(HttpSessionEvent event) {
        if (logger.isDebugEnabled()) {
            logger.debug("Session ID".concat(event.getSession().getId()).concat(" created at ").concat(new Date().toString()));
        }
    }

    public void sessionDestroyed(HttpSessionEvent event) {
        if (logger.isDebugEnabled()) {
            logger.debug("Session ID".concat(event.getSession().getId()).concat(" destroyed at ").concat(new Date().toString()));
        }
    }
}


위 파일을 web.xml 에 등록 할 차례다.


<listener>
    <listener-class>kr.co.whitelife.web.mvc.listener.HttpSessionCheckingListener</listener-class>
</listener>


Tomcat Start 한 후 로그를 살펴 보자. 생성되는 부분, 소멸되는 부분 확인이 가능하다.


created
2014-10-07 14:06:05,957  DEBUG HttpSessionCheckListener - Session IDD31C36AE223F8C14BB1087F6BFCEBD35 created at Tue Oct 07 14:06:05 KST 2014
destroyed
2014-10-07 14:08:06,068  DEBUG HttpSessionCheckListener - Session IDD31C36AE223F8C14BB1087F6BFCEBD35 destroyed at Tue Oct 07 14:08:06 KST 2014

참고 사이트


Tomcat Work Directory 를 초기화 한다. Eclipsc 의 경우 Servers > 마우스 오른쪽 > Clean Tomcat Work Directory 클릭, 서버를 재 시작 하자.

Maven Repository 에 있는 라이브러리 압축 파일이 께져서 발생 하는 현상 이다.


Maven Repository 를 초기화 한 후 라이브러리를 다시 받고 서버를 시작해 보자.
해결 될 것 이다.


+ Recent posts