제1장 도메인 환경에서 애플리케이션 관리

내용 목차

1.1. 애플리케이션 관리
1.1.1. 2 Phase Deployment
1.1.2. 애플리케이션 ID
1.1.3. 애플리케이션 상태
1.1.4. 애플리케이션 관리 디렉터리 구조
1.1.5. 애플리케이션 대상
1.2. Managed Server(MS)에서의 Deploy
1.2.1. Run-time Deploy
1.2.2. Boot-time Deploy
1.2.3. 애플리케이션 동기화
1.3. Auto Redeploy
1.4. 디렉터리 모드의 Deploy
1.5. 애플리케이션 저장소(Application Repositories)
1.5.1. 애플리케이션 저장소 추가/삭제/조회
1.5.2. 애플리케이션 저장소에 있는 애플리케이션 Deploy
1.6. path를 지정하여 Deploy
1.7. Staging Mode Deploy
1.8. 애플리케이션 Undeploy

본 장에서는 도메인 환경에서 애플리케이션이 어떻게 관리되고, Deploy 작업은 어떻게 진행되는지 설명한다. 또한 Managed Server(이하 MS)에서 Deploy 작업 진행에 대해서 설명한다.

1.1. 애플리케이션 관리

Domain Administration Server(이하 DAS)는 도메인을 관리하는 서버이다. 애플리케이션은 도메인 단위로 관리되어야 하기 때문에 DAS에서는 도메인에 존재하는 모든 애플리케이션을 관리한다.

애플리케이션에 관련된 deploy 명령과 조회 명령은 모두 DAS를 통해서만 가능하다. DAS를 기동할 때 애플리케이션을 관리하는 서비스가 시작되고 이 서비스를 통해 서버나 클러스터에 deploy할 수 있다. deploy뿐만 아니라 애플리케이션과 관련된 모든 명령이 DAS를 통해서만 동작 가능하다. DAS에 장애가 발생해서 MS가 INDEPENDENT 상태가 된 경우에는 애플리케이션에 deploy하는 명령은 사용할 수 없다. 단, 콘솔 툴(jeusadmin)을 통해 해당 MS에 연결하여 애플리케이션 정보를 확인하는 조회 명령은 사용 가능하다.

주의

MS로 직접 연결하여 애플리케이션 정보를 조회하는 것은 MS가 INDEPENDENT 상태일 때만 가능하다. MS가 INDEPENDENT 상태인 것은 DAS로 접속할 수 없거나 DAS에서 MS를 관리할 수 없는 상황이기 때문에 MS로 직접 연결하여 애플리케이션의 정보를 확인한다.

애플리케이션을 서비스할 수 있도록 deploy하기 위해서는 먼저 애플리케이션을 도메인에 install시켜야 한다. 애플리케이션을 install하는 것은 DAS에 애플리케이션 파일을 설치하는 작업이고, deploy하는 것은 애플리케이션을 서비스할 수 있도록 만드는 작업이다.

  • install

    애플리케이션 파일을 DAS로 업로드하는 동작을 의미한다. DAS에 install된 애플리케이션만이 deploy가 가능하다.

    애플리케이션이 DAS에 install되었다는 것은 다음과 같은 의미를 갖는다.

    • WebAdmin이나 콘솔 툴을 통해 애플리케이션 파일을 도메인의 APPLICATION_INSTALL_HOME에 위치시키는 것을 의미한다.

      APPLICATION_INSTALL_HOME은 도메인에 install된 애플리케이션을 관리하는 저장소이다. 이 저장소는 변경될 수 없고 수동으로 접근해서도 안 된다. install된 애플리케이션을 삭제하거나 새로운 애플리케이션을 수동으로 추가해도 동적으로 반영되지 않는다. DAS를 재부팅한 경우에는 반영이 되겠지만 이는 절대 권장하는 방법이 아니다.

    • 사용자가 지정한 디렉터리에 애플리케이션을 수동으로 위치시키는 것을 의미한다.

      사용자가 지정한 디렉터리는 애플리케이션이 저장되는 위치(특정 디렉터리)를 의미한다. 사용자는 이 디렉터리를 애플리케이션 저장소(repository)로 추가하고 여기에 애플리케이션 파일을 수동으로 위치시킬 수 있다. WebAdmin과 콘솔 툴의 add-application-repository, remove-application-repository 명령을 통해 도메인에 애플리케이션 저장소를 추가, 삭제하는 것이 가능하다.

  • deploy

    애플리케이션이 서비스될 수 있도록 서버에 애플리케이션을 배포하고 서비스 준비 작업을 수행한다.

    사용자가 WebAdmin이나 콘솔 툴을 통해 애플리케이션을 deploy하겠다는 명령을 DAS로 보내면, DAS에서는 대상(target)이 되는 서버나 클러스터로 Deploy 작업을 진행한다. 이때 DAS와 서버에서는 2 Phase Deploy를 진행한다. 2 Phase Deploy에 대한 자세한 설명은 “1.1.1. 2 Phase Deployment”를 참고한다.

1.1.1. 2 Phase Deployment

애플리케이션 파일을 각 서버로 배포하고 애플리케이션 서비스를 위한 사전 작업을 진행한다. 이 작업이 성공한 후에 애플리케이션을 서비스할 수 있는 상태로 만든다.

이 작업과정을 DAS에서는 2단계로 나누어서 처리한다. 모든 deploy 명령은 DAS를 통하고 DAS에서는 대상이 되는 서버로 다시 명령을 내린다. 사용자가 Deploy 요청을 할 때 대상으로 설정한 모든 서버에 대한 Deploy 성공을 보장할 수 있어야 사용자가 내린 deploy 명령이 성공했다고 볼 수 있다. 따라서 애플리케이션을 Distribute, Start 두 단계로 나누어서 진행하고 1단계에서 실패하면 deploy 명령은 실패한 것이고 모든 서버에서 undeploy된다.

  • 1단계가 성공하게 되면 애플리케이션에 대한 Distribute 작업과 검증 작업이 성공한 것이기 때문에 잠재적으로 Deploy가 성공한 상태라고 볼 수 있다. 하지만 애플리케이션이 서비스될 수 있는 상태는 아니다.

  • 2단계가 성공해야 애플리케이션이 서비스될 수 있는 상태가 된다. 2단계에서는 실패한 서버가 있더라도 재시도해서 애플리케이션이 해당 서버에서 서비스될 수 있는 상태가 될 수 있도록 보장해준다.

이러한 두 단계를 하나의 deploy 명령이 아닌 각각 distribute 명령, start 명령으로 나누어서 수행할 수도 있다.

1단계 (Distribute 단계)

대상이 되는 서버나 클러스터로 애플리케이션을 distribute하고 검증한다. 이 단계를 JEUS에서는 애플리케이션 Distribute 단계라고 한다. 이 단계에서는 애플리케이션 파일을 각 서버에 배포하고, 애플리케이션이 서비스될 수 있도록 사전준비 작업과 검증 작업을 수행한다.

실제 Distribute 단계의 작업이 모두 성공하면 서비스를 하기 위한 모든 작업은 끝난 상태이다. EJB 모듈의 경우는 서비스 포트가 열리고 웹 모듈의 경우는 웹 리스너와 웹 모듈의 컨텍스트가 연결된다. 하지만 애플리케이션의 상태는 서비스될 수 없는 DISTRIBUTED 상태이다.

애플리케이션이 DISTRIBUTED 상태일 때 애플리케이션에 서비스를 요청하면 웹 모듈의 경우는 "503 Service Unavailable"이 발생하고, EJB 모듈의 경우는 "Bean이 존재하지 않는다"는 exception이 발생한다.

[예 1.1] EJB 모듈이 DISTRIBUTED 상태일 때 요청이 들어온 경우 발생하는 클라이언트 exception

[2012.05.07 15:28:35][1] [t-1] [JNDI.Context-0073] exception occurred during JNDI operation
<<__Exception__>>
javax.naming.NamingException: javax.ejb.EJBException: java.rmi.RemoteException: EJB object is not read at 
jeus.ejb.client.BusinessObjectFactory.getObjectInstance(BusinessObjectFactory.
java:89)
  at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
  at jeus.jndi.JNSContext.lookupInternal(JNSContext.java:594)
  at jeus.jndi.JNSContext.lookup(JNSContext.java:549)
  at jeus.jndi.JNSContext.lookup(JNSContext.java:538)
  at jeus.jndi.JEUSFailoverContext.lookup(JEUSFailoverContext.java:314)
  at javax.naming.InitialContext.lookup(InitialContext.java:392)
  at test.HelloTest.testHelloBean(HelloTest.java:29)
  ......
Caused by: java.rmi.RemoteException: EJB object is not ready at 
jeus.ejb.container.RemoteInvocationManagerImpl.beforeInvoke(RemoteInvocationManagerImpl.
java:72
  at jeus.ejb.baseimpl.RemoteInvokerServer.preInvoke(RemoteInvokerServer.java:118)
  at jeus.ejb.baseimpl.RemoteInvokerServer.invoke(RemoteInvokerServer.java:97)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.
java:25)
  at java.lang.reflect.Method.invoke(Method.java:597)
  at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
  at sun.rmi.transport.Transport$1.run(Transport.java:159)
  at java.security.AccessController.doPrivileged(Native Method)
  at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
  at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
  at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.
java:790)
  at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
  at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.
java:886)
  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
  at java.lang.Thread.run(Thread.java:662)

[그림 1.1] 웹 모듈이 DISTRIBUTED 상태일 때 요청을 한 경우 발생하는 에러

웹 모듈이 DISTRIBUTED 상태일 때 요청을 한 경우 발생하는 에러

사용자가 Deploy 대상으로 설정한 모든 서버와 클러스터로 Distribute 작업이 성공해야 전체 성공이 될 수 있다. 하나라도 실패한 서버가 있다면 사용자가 내린 deploy 명령은 실패하고 성공한 서버에는 undeploy 명령이 보내지면서 이 단계에서 했던 작업을 모두 rollback한다. Deploy 대상으로 설정한 서버 중 일부 서버가 fail 또는 shutdown된 상태라면 이 또한 Deploy 실패이다. 이 경우 사용자가 Deploy 대상에서 해당 서버를 제외하고 deploy 명령을 다시 시도해야 한다.

Deploy 대상이 클러스터라면 클러스터 멤버 중 일부 서버가 fail 또는 shutdown된 상태이더라도 Distribute는 성공할 수 있다. 이런 서버들을 제외한 다른 모든 서버에서 Distribute 작업이 성공한다면 이 애플리케이션은 Distribute 성공이다.

2단계 (Start 단계)

대상이 되는 서버나 클러스터에는 이미 애플리케이션이 distribute된 상태일 때 애플리케이션이 서비스될 수 있도록 start시켜준다. 이 단계에서는 애플리케이션을 서비스될 수 있는 상태로 만들어주는 간단한 작업을 수행한다. 이 단계를 JEUS에서는 애플리케이션 Start 단계라고 한다.

Start 단계에서는 Distribute 단계에서와는 다르게 대상이 되는 서버나 클러스터 중에서 하나의 서버에서라도 Start 작업이 성공하면 전체 성공으로 간주한다. Distribute 작업을 마치면서 이미 애플리케이션의 검증 작업이 완료되었고, 이미 애플리케이션을 서비스할 수 있는 모든 준비가 갖춰진 것이기 때문이다.

Start 작업이 실패했다는 것은 서버가 잠시 장애상태라고 추정할 수 있다. 이는 서버가 정상화되면 Start 작업이 성공해서 애플리케이션을 서비스할 수 있다는 것을 의미이기도 하다. Start 작업에 실패한 서버는 DAS에서 별도의 Thread로 5초 간격으로 10번 재시도한다.

재시도도 실패하면 서버가 복구되지 않은 것이므로 수동으로 서버를 복구해야 한다. 서버가 복구된 후에 애플리케이션에 대해 start 명령을 다시 수행하면 애플리케이션 Start 작업을 실패했던 서버에서 start 명령이 정상적으로 수행된다.

1.1.2. 애플리케이션 ID

JEUS 7에서부터는 도메인에서 애플리케이션을 관리하기 위해 애플리케이션을 식별할 수 있는 ID를 애플리케이션마다 발급하여 사용하고 있다. 애플리케이션 ID는 도메인에서 애플리케이션을 관리하기 위해 필요한 이름이다. 또한 애플리케이션을 구별할 수 있는 식별자이기 때문에 도메인에서 유일해야 한다.

애플리케이션을 install할 때 ID를 설정할 수 있다. install 명령을 수행할 때 애플리케이션에 ID를 설정하지 않은 경우에는 애플리케이션 파일 이름으로 ID를 만들어서 사용한다. 예를 들어 examples.ear을 install할 때 ID를 설정하지 않았다면 애플리케이션 ID는 'examples_ear'이 된다. ID로는 알파벳이나 숫자를 사용할 것을 권장한다.

애플리케이션 ID는 deploy/undeploy 등 애플리케이션 제어 명령이나 조회 명령을 할 때 설정해야 한다. 도메인에 별도의 저장소(repository)를 설정하고 해당 위치에 애플리케이션 파일을 위치시킨 경우는 애플리케이션 파일 이름을 그대로 ID로 사용한다.

DAS에서 애플리케이션 파일을 전송받으면 도메인 디렉터리 하위에 존재하는 애플리케이션 INSTALL_HOME에 ID로 디렉터리를 생성하고 그 하위에 애플리케이션 파일을 위치시킨다.

애플리케이션을 install하면 다음의 디렉터리가 생성된다. INSTALL_HOME 디렉터리에 대한 자세한 설명은 절 1.1.4. “도메인 INSTALL_HOME 디렉터리”를 참고한다.

INSTALL_HOME/<APPLICATION_ID>/<APPLICATION_FILE>

서버에서도 애플리케이션 파일을 전송받을 때나 압축을 풀 때 DEPLOYED 디렉터리 하위에 APPLICATION_ID를 최상위 디렉터리로 두고 그 하위에 파일을 위치시키고 압축을 푼다.

주의

application name은 Java EE 6부터 표준 DD에 정의할 수 있으며, 애플리케이션 서비스를 위해서 반드시 필요한 이름이다. 이 값을 애플리케이션 ID와 혼동하면 안된다.

application name은 애플리케이션이 서비스되고 있는 서버에서만 유일하면 되지만 애플리케이션 ID는 도메인에서 유일해야 한다. application name을 설정하지 않은 경우 확장자를 제외한 애플리케이션 파일 이름이 application name이 된다.

application name 설정 방법에 대한 자세한 내용은 "Java EE 6 Platform Specification"을 참고한다.

1.1.3. 애플리케이션 상태

도메인에서는 애플리케이션에 대한 명령을 주관하기 때문에 도메인에서 보여지는 애플리케이션 상태는 target 서버 전체를 총괄하는 상태를 나타낸다. 서버에서는 실제 애플리케이션을 deploy하고 서비스하는 주체이기 때문에 애플리케이션이 어떤 상태인지를 나타낸다.

도메인에서의 애플리케이션 상태

다음은 도메인에서의 애플리케이션 Lifecycle을 보여주는 그림이다.

DAS에서의 애플리케이션 상태는 다음의 과정으로 진행된다.

INSTALLED → DISTRIBUTING → DISTRIBUTED → STARTING → RUNNING

[그림 1.2] 도메인에서의 애플리케이션 Lifecycle

도메인에서의 애플리케이션 Lifecycle

다음은 각 상태에 대한 자세한 설명이다.

상태설명
INSTALLED애플리케이션 파일이 도메인으로 upload된 상태를 의미한다. 이 상태에서 Deploy 대상을 지정해서 deploydistribute 명령을 수행할 수 있다.
DISTRIBUTED애플리케이션이 Distribute를 성공적으로 완료한 상태를 의미한다. 이때 대상 서버들이 모두 SHUTDOWN 상태이더라도 DISTRIBUTED 상태로 나타난다.
RUNNING애플리케이션이 서비스되고 있는 상태를 의미한다. 애플리케이션에 Deploy 대상으로 설정한 서버들 중 한 서버에서라도 RUNNING 상태로 서비스되고 있으면 도메인에서 이 애플리케이션의 상태는 RUNNING이 된다.

참고

도메인에서는 위의 세 가지 상태 외에 DEPLOYED라는 상태가 존재한다.

DEPLOYED 상태란 deploy된 이력이 있는 애플리케이션의 대상 서버가 모두 RUNNING 상태가 아닐 때 도메인에서는 이 애플리케이션의 상태를 DEPLOYED로 나타난다. 대상 서버들이 running되지 않았다는 것은 애플리케이션을 서비스하고 있는 서버들이 없다는 의미이므로 RUNNING으로 표현하지 않고 DEPLOYED라는 상태로 나타낸다.

서버에서의 애플리케이션 상태

다음은 서버에서의 애플리케이션 Lifecycle을 보여주는 그림이다.

서버에서의 애플리케이션 상태는 다음의 과정으로 진행된다.

DISTRIBUTING → DISTRIBUTED → STARTING → RUNNING

[그림 1.3] 서버에서의 애플리케이션 Lifecycle

서버에서의 애플리케이션 Lifecycle

다음은 각 상태에 대한 설명이다.

상태설명
DISTRIBUTEDDAS로부터 온 distribute 명령이 성공한 상태를 의미한다. 애플리케이션은 이미 서비스될 준비를 마쳤고 start 명령을 통해 애플리케이션을 서비스 가능한 상태로 만들 수 있다.
RUNNING애플리케이션이 해당 서버에서 서비스되고 있는 상태를 의미한다.

1.1.4. 애플리케이션 관리 디렉터리 구조

애플리케이션을 deploy할 때 사용되는 디렉터리 구조는 다음과 같다.

도메인 INSTALL_HOME 디렉터리

애플리케이션이 도메인에 install되면 APPLICATION_INSTALL_HOME에 위치하게 된다.

[그림 1.4] 도메인의 INSTALL_HOME 디렉터리

도메인의 INSTALL_HOME 디렉터리

APPLICATION_INSTALL_HOME

DAS가 존재하는 머신에만 생성되는 디렉터리이다. 애플리케이션을 도메인에 install하면 이 디렉터리에 저장된다. install할 때 설정한 애플리케이션 ID로 디렉터리를 생성하고 그 하위에 실제 애플리케이션 파일을 위치시킨다. JEUS에서는 이 디렉터리를 APPLICATION_INSTALL_HOME이라고 하고 이를 줄여서 INSTALL_HOME이라고 한다. APPLICATION_INSTALL_HOME은 DOMAIN_HOME/.applications를 의미한다.

도메인에서 관리하는 애플리케이션 저장소

도메인에 추가한 애플리케이션 저장소(repository)는 다음과 같은 구조로 구성한다.

[그림 1.5] 도메인에 추가한 애플리케이션 저장소 디렉터리

도메인에 추가한 애플리케이션 저장소 디렉터리


애플리케이션 저장소에는 디렉터리 형태의 애플리케이션과 Archive 형태의 애플리케이션이 모두 저장된다. 이 경우 애플리케이션 ID는 사용자가 부여할 수 없고 항상 파일 이름을 사용하게 된다. 사용자는 애플리케이션 저장소를 추가하고 삭제할 수 있다. 추가 및 삭제 방법에 대해서는 “1.5.1. 애플리케이션 저장소 추가/삭제/조회”를 참고한다.

Deploy 이미지 디렉터리

서버에 애플리케이션을 deploy할 때 DAS로부터 애플리케이션을 전송받아서 다음의 경로에 위치시킨다.

SERVER_HOME/.workspace/deployed

이 위치를 DEPLOYED_HOME이라고 한다. DEPLOYED_HOME에 애플리케이션 ID로 디렉터리를 생성하고 전송받은 애플리케이션 파일을 하위에 위치시킨다.

또한 Deploy를 진행하면서 archive된 애플리케이션의 경우 파일의 압축을 푼다. 이를 애플리케이션의 Deploy 이미지 디렉터리라고 한다. 애플리케이션의 압축을 푸는 디렉터리는 애플리케이션 파일 이름을 변경해서 사용한다. myApp.ear의 경우 압축을 푸는 이미지 디렉터리는 'myApp_ear___'이 된다.

ear 애플리케이션일 경우는 ear 이미지 디렉터리 하위에 모듈의 압축을 푼다. 모듈의 압축을 푸는 디렉터리 이름은 ear의 압축을 푼 디렉터리를 생성한 규칙과 동일하게 ejb.jar인 경우는 'ejb_jar'가 된다.

[그림 1.6] 서버에 deploy된 ear 애플리케이션의 이미지 디렉터리

서버에 deploy된 ear 애플리케이션의 이미지 디렉터리


애플리케이션의 gen 디렉터리

애플리케이션이 서버에 deploy되면서 서비스에 필요한 파일들을 생성하는 경우가 있다.

EJB 애플리케이션과 웹 애플리케이션의 경우 파일 생성이 필요하다. 이 파일들을 DEPLOYED_HOME에 '_generated_'라는 디렉터리 하위에 생성한다. '_generated_' 디렉터리 하위에 애플리케이션 ID로 디렉터리를 생성하여 각 애플리케이션마다 개별적인 generated 디렉터리를 갖게된다. 이 디렉터리를 애플리케이션의 gen 디렉터리라고 한다.

[그림 1.7] 서버에 deploy된 ear 애플리케이션 gen 디렉터리

서버에 deploy된 ear 애플리케이션 gen 디렉터리


각 애플리케이션의 gen 디렉터리에는 다음와 같은 파일이 생성된다.

  • EJB의 경우는 EJB 2.x 형태의 Bean을 Dynamic Proxy 방식이 아닌 Stub 방식으로 사용할 때 Stub 파일과 Skel 파일을 생성한다.

  • 웹의 경우는 JSP를 Java로 generate한 파일과 embedable EJB(Java EE 6에서 웹 애플리케이션 안에 내장된 EJB 모듈을 지원한다. 이를 embedable EJB라고 한다)를 위한 stub 파일을 생성한다.

  • '_appdat.ser'은 애플리케이션의 Deploy 시간을 저장한 serializable 파일이다. 이 파일의 용도는 서버를 shutdown했다가 재부팅할 경우 애플리케이션이 변경되지 않았으면 Deploy 이미지 파일과 generate한 파일을 재생성하지 않도록 해서 부팅 속도를 빠르게 하기 위한 것이다.

1.1.5. 애플리케이션 대상

Deploy를 할 때는 어떤 서버에서 서비스할 것인지를 대상(target)을 명확히 해야 한다. Deploy 대상이 될 수 있는 것은 서버와 클러스터이다. 웹 모듈의 경우 특정 호스트로만 서비스하려면 추가적으로 가상 호스트를 설정하여 deploy할 수 있다.

서버

서버는 애플리케이션을 서비스하는 최소 단위이기 때문에 Deploy의 대상이 될 수 있다.

여러 서버를 대상으로 deploy 명령을 한 경우 지정한 서버 중 하나 이상의 서버에서 Deploy에 실패하거나 하나 이상의 서버가 다운되어 있는 경우 Distribute 단계에서 실패한다. 이 경우 Deploy에 실패한 서버에 성공할 수 있도록 적절한 조치를 취한 후 다시 deploy 명령을 수행해야 한다.

또는 실패한 서버를 Deploy 대상에서 제외하고 다시 deploy 명령을 수행하면 Deploy는 성공할 것이다. 만약 서버가 STANDBY 상태이거나 SUSPENDED 상태라면 사용자가 이 서버를 대상으로 deploy 명령을 해도 서버가 서비스될 수 없는 상태이기 때문에 애플리케이션을 start하지 않는다.

Distribute 작업까지만 진행하고 서버가 다시 start 또는 resume되어서 서비스할 수 있는 RUNNING 상태가 되었을 때 해당 애플리케이션을 start한다. 서버 상태에 대한 자세한 설명은 JEUS Server 안내서”의 “3.1.1. Managed Server의 Lifecycle”을 참고한다.

사용자가 서버에 deploy 명령이 아닌 distribute 명령만 수행한 경우에 애플리케이션은 서비스되지 않는다. 서버가 재부팅된 경우에도 이 상태는 유지되어야 한다. 따라서 DAS에서는 애플리케이션의 상태를 INSTALL_HOME 하위에 ".deployInfo.ser"라는 파일에 기록했다가 서버가 부팅할 때 애플리케이션에 대한 상태를 알려주어서 사용자가 이전에 한 작업을 계속 유지할 수 있도록 해준다.

주의

사용자가 설정 파일을 수동으로 수정한 경우라면 이 상태가 유지되지 않을 수도 있다.

JEUS 7부터는 설정 파일을 수동으로 수정하지 않고 WebAdmin이나 콘솔 툴을 사용할 것을 권장한다.

클러스터

클러스터에 속한 서버에는 서버를 대상으로 deploy할 수 없고 오직 클러스터만 대상으로 deploy할 수 있다. 클러스터를 대상으로 deploy한 경우 클러스터 멤버에 속한 서버 중 하나의 서버에서라도 Distribute가 실패하면 클러스터 Deploy는 실패한다.

하지만 서버 리스트를 대상으로 설정하고 deploy하는 경우와는 달리, 클러스터를 대상으로 deploy하는 경우는 클러스터 멤버 중 일부 서버가 Alive 상태가 아니더라도 Deploy에 성공할 수 있다. 클러스터 멤버 중 Alive 서버 모두에 deploy를 성공하면 클러스터 Deploy는 성공한다.

참고

클러스터는 단순 싱글 서버의 리스트를 의미하는 것이 아니고 서비스를 수행하는 하나의 그룹을 의미한다. 클러스터 멤버 중 Alive 서버에 Deploy를 성공하면 alive 상태가 아닌 서버에도 Deploy가 성공할 가능성이 매우 높아진다. 클러스터를 deploy할 경우 Alive 상태가 아닌 다른 멤버들은 정상화되거나 재기동될 때 또는 새로운 멤버가 클러스터에 추가되어서 부팅될 때 이미 클러스터 deploy되어 있는 애플리케이션을 deploy해야 한다. 만약 클러스터 멤버가 Boot-time Deploy에 실패한다면 DAS는 실패한 멤버들에 애플리케이션이 정상적으로 deploy될 수 있도록 보장해주어야 한다.

Deploy를 수행할 때 fail되었거나 RUNNING 상태가 아닌 서버의 경우도 failback되거나 재기동되었을 때 해당 애플리케이션은 deploy되어야 한다. 만약 서버가 Boot-time Deploy를 실패한다면 Deploy 성공을 보장해주기 위해 노력하는 것은 DAS의 역할이다.

DAS에서는 재시도를 통해 Boot-time Deploy에 실패한 클러스터 멤버에 대해서도 최대한 보장해줄 수 있도록 하고 있다. 5분 간격으로 5번의 재시도를 하고, 이것이 모두 실패하면 JEUS에서 복구할 수 있는 오류가 아니기 때문에 사용자가 원인을 찾아 해결할 수 있도록 DAS에서는 더 이상 Deploy를 보장해줄 수 없다는 것을 알려준다. deploy할 때 RUNNING 상태가 아니었던 서버뿐만 아니라 클러스터에 동적으로 추가된 서버도 마찬가지로 Boot-time Deploy를 실패한 경우 DAS에서 위와 같은 방법으로 Deploy를 보장해주고 있다.

DAS에서 클러스터 멤버로의 정해진 Deploy 재시도 작업이 모두 실패한 경우 다음과 같은 메시지를 출력해서 서버에서 에러를 직접 해결할 수 있도록 알려준다.

[예 1.2] 클러스터 멤버로 deploy를 재시도 중 실패하는 경우 로그 메시지

Deployment reattempts of the application[examples] failed 5 times. 
No more deployment attempts will be made. solve the problem for deploying application.

클러스터 멤버인데 애플리케이션 대상이 서버로 되어 있는 경우는 deploy하지 않는다. 사용자에게 해당 애플리케이션을 undeploy나 remove-application-target 명령을 수행할 수 있도록 다음과 같은 WARNING 메시지만 출력한다.

[예 1.3] 클러스터 멤버인 서버로 지정되어 있는 경우 MS를 부팅할 때 발생하는 로그 메시지

WARNING: The server[server1] is part of the cluster[cluster1], so this application[exampes] can only be deployed to the cluster. 
Deploy again this application to the cluster target.

deploy 명령으로 이런 문제는 발생할 수 없다. 클러스터 멤버인 서버를 별개의 서버 target으로 deploy를 시도하는 경우에는 deploy 명령이 수행되지 않는다. 이런 문제가 발생할 수 있는 경우는 xml을 수동으로 수정한 경우이다. 이는 JEUS에서 금지하고 있는 사항이기 때문에 전적으로 사용자의 잘못으로 간주한다. JEUS에서는 이로 인해 발생하는 오류들에 대해서는 책임지지 않는다.

서비스되고 있는 독립된 서버를 클러스터 멤버로 동적 추가한 경우는 서버에서 이미 서비스되고 있는 애플리케이션을 undeploy하고 애플리케이션 대상에서도 이 서버를 삭제한다. 또한 클러스터를 대상으로 deploy해야 하는 애플리케이션들도 동적으로 deploy시켜주고 있다. 이미 서버를 대상으로 deploy되어서 서비스하고 있는 애플리케이션이기는 하지만 클러스터에 추가하고 새로운 서비스를 하겠다는 사용자의 의도이기 때문에 애플리케이션을 undeploy하고 새로운 애플리케이션을 deploy해도 무방하다.

클러스터에 동적으로 새로운 멤버를 추가하는 것이 가능하기 때문에 애플리케이션에 대한 처리도 자동으로 해주고 있다. 하지만 이렇게 single 서버와 클러스터를 이미 별도로 구성해서 서비스하다가 싱글 서버를 클러스터의 멤버로 동적추가하는 경우는 자주 사용하지 않고, 사용자 의도이긴하나 서버에서 이미 진행 중인 서비스에 문제가 될 수도 있다. 따라서 클러스터를 확장하는 경우에는 새로운 서버를 추가하고 이 서버를 클러스터의 멤버로 추가하는 것을 권장한다.

가상 호스트(Virtual Host)

웹 엔진에서는 가상 호스트를 이용해 웹 컨텍스트를 특정 호스트에서 서비스할 수 있도록 하고 있다. 가상 호스트는 단독으로 지정할 수 없고 대상이 되는 서버 또는 대상이 되는 클러스터와 함께 지정할 수 있다. 대상이 되는 가상 호스트 없이 deploy할 경우에는 기본 가상 호스트에 deploy된다.

가상 호스트에 대한 자세한 내용은 JEUS Web Engine 안내서”의 “제5장 가상 호스트”를 참고한다. deploy 명령에 자세한 설명은 “4.3. WebAdmin을 사용한 애플리케이션 제어 및 모니터링”“4.4. 콘솔 툴을 이용한 애플리케이션 제어 및 모니터링”을 참고한다.

1.2. Managed Server(MS)에서의 Deploy

본 절에서는 MS에서 애플리케이션 또는 모듈을 deploy하는 방법에 대해서 설명한다.

1.2.1. Run-time Deploy

Run-time Deploy는 서버가 기동되어 있는 상태에서 애플리케이션 또는 모듈을 deploy하는 것이다. JEUS의 툴인 WebAdmin과 콘솔 툴을 이용해서 DAS에 접속하여 Run-time Deploy를 할 수 있다.

JEUS 7에서는 Run-time Deploy를 수행하면 영구 Deploy가 된다. 영구 Deploy는 deploy나 distribute 명령을 통해 애플리케이션이 Distribute에 성공하면 domain.xml에 그 내용이 저장되면서 DAS나 MS가 재부팅해도 해당 애플리케이션의 Deploy 정보를 설정 파일에서 읽어 Boot-time Deploy될 수 있도록 애플리케이션 정보를 유지해주는 것을 의미한다.

Deploy는 DAS를 통해서만 가능하기 때문에 domain.xml에 애플리케이션 정보를 쓰는 주체도 오로지 DAS뿐이다. MS에서는 Boot-time에 DAS로부터 설정을 받고 해당 설정에 등록된 애플리케이션 파일을 다운로드받아 XML 파일의 정보를 바탕으로 Boot-time Deploy를 진행할 수 있다.

Run-time Deploy의 명령 방법에 대한 자세한 내용은 “4.3. WebAdmin을 사용한 애플리케이션 제어 및 모니터링”“4.4. 콘솔 툴을 이용한 애플리케이션 제어 및 모니터링”을 참고한다.

1.2.2. Boot-time Deploy

Boot-time Deploy는 MS가 부팅할 때 domain.xml에 등록된 애플리케이션을 deploy하는 것을 의미한다. JEUS 7부터는 영구 deploy를 기본으로 하면서 최초 deploy 명령은 이전에 한 번 deploy된 이력이 있는 애플리케이션들의 서버가 부팅할 때 deploy된다.

DEPENDENT 상태에서의 Boot-time Deploy

MS는 부팅할 때 DAS로부터 domain.xml을 전송받아온다. 이 설정 파일에 등록된 애플리케이션이 있으면 애플리케이션의 대상을 보고 자신의 서버에 deploy해야 할 애플리케이션인지를 판단하여 Deploy를 진행한다. 이때 각 애플리케이션마다 Deploy 작업을 진행하는 것이 아니라 모든 애플리케이션에 대한 Distribute 작업을 먼저 진행하고, 모든 애플리케이션의 distribute가 성공한 경우에 애플리케이션 Start 작업을 진행한다.

참고

서버가 클러스터에 속한 멤버인데 애플리케이션이 서버 target으로 명시되어 있는 경우 해당 Boot-time에 애플리케이션은 deploy되지 않는다. Deploy의 대상은 클러스터에 속한 서버가 될 수 없다. 클러스터에 속한 서버는 오직 클러스터 단위로만 Deploy가 가능하다.

JEUS 툴을 통해 Deploy를 수행한 것이라면 이는 보장된다. 하지만 수동으로 XML 파일을 수정한 경우에는 JEUS에서 이를 보장해줄 수 없으니 XML 파일을 수동으로 수정하여 사용하지 않도록 한다.

Boot-time에 서버에서 진행하는 Distribute 작업은 Run-time에 서버에서 진행하는 Distribute 작업과 크게 다르지 않다. 먼저 애플리케이션 파일을 DAS로부터 전송받는다. 만약 서버에서 이전에 전송받아놓은 파일이 존재한다면 서버에 캐시된 애플리케이션 파일과 DAS에 install된 애플리케이션 파일의 시간을 비교하여 파일 전송 여부를 결정한다. 그 후에 애플리케이션 파일의 압축을 풀고 클래스를 로딩하고 애플리케이션이 서비스될 수 있는 환경을 구성하는 Distribute 작업을 진행한다.

서버를 부팅할 때 하나의 애플리케이션이라도 distribute에 실패하면 서버의 상태는 STANDBY 상태가 되고 그 시점에서 부팅이 멈추게 된다. 이 상황에서 start-server 명령을 수행하면 distribute에 실패한 애플리케이션들을 다시 distribute하고 Boot-time과 마찬가지로 모든 애플리케이션이 distribute에 성공해야 다음 작업인 애플리케이션 Start 작업이 진행된다. 이때도 Distribute 작업에 실패한 애플리케이션이 있다면 서버는 또 다시 STANDBY 상태에 머무르게 된다.

전체 애플리케이션에 대한 Distribute 작업이 성공하지 않았음에도 서버를 RUNNING 상태로 만들어 서비스하려면 다음의 명령을 수행한다.

[DAS]domain1.adminServer>start-server -force server1

start-server 명령에 -force 옵션을 주고 수행하면 현재 Distribute 작업이 성공한 애플리케이션에 대해서만 Start 작업을 수행하고 서버를 서비스 가능한 상태로 만들 수 있다. 이때 서버의 상태는 RUNNING이 된다.

Boot-time Deploy할 때 distribute가 완료된 시점에서 MS는 DAS로부터 해당 애플리케이션이 start를 수행할 수 있는 상태인지를 확인한다.

DAS에서의 애플리케이션 상태가 DEPLOYED, RUNNING 상태인 애플리케이션에 대해서만 Start 작업을 수행할 수 있다. 만약 DAS로부터 애플리케이션의 상태를 얻어오는 작업이 실패했다면 서버는 애플리케이션 Start 작업을 진행하지 않는다. 이때 서버는 부팅을 중단하고 STADNBY 상태에 머무르게 된다.

DAS에서의 애플리케이션 상태에 상관없이 애플리케이션을 start하여 서비스가 가능하려면, distribute에 실패한 애플리케이션이 있을 때와 마찬가지로 start-server 명령에 -force 옵션을 주고 수행하여 서버를 RUNNING 상태로 만들어 서비스 가능하도록 할 수 있다.

참고

DAS에서 DISTRIBUTED 상태인 애플리케이션은 서버에서도 Distribute 작업까지만 진행할 수 있게 하기 위해서 DAS에서는 별도의 파일에 이 정보를 기록하여 DAS가 다운되었다가 부팅된 상황에서도 애플리케이션 상태를 유지해줄 수 있도록 하고 있다.

서버가 SUSPENDED 상태에서 애플리케이션이 stop, start된 경우에도 마찬가지로 서버가 다시 resume이 되서 RUNNING 상태가 되었을 때 애플리케이션의 바뀐 상태를 잘 유지해줄 수 있도록 해야 한다. 이때는 DAS로부터 애플리케이션의 상태를 다시 받아오지는 않는다. SUSPENDED 상태이더라도 DAS로부터 애플리케이션 stop, start 명령은 받을 수 있기 때문에 실제 애플리케이션이 MS에서 명령을 수행할 수 없는 상태이더라도 DAS로부터 온 start, stop 작업을 기억했다가 서버가 다시 resume이 되는 순간 애플리케이션의 상태를 유지해줄 수 있도록 하고 있다.

참고

서버가 SUSPENDED 상태일 때 애플리케이션 stop 명령이 오면 서버에서는 이미 모든 애플리케이션이 stop된 상태이기 때문에 ApplicationAlreadyStoppedException이 발생한다. DAS에서는 이런 상황에서 발생한 exception은 애플리케이션 stop 작업이 실패했다고 취급하지 않는다.

서버가 SUSPENDED 상태일 때 애플리케이션 start 명령이 오면 서버에서는 애플리케이션 Start 작업을 수행할 수가 없다. 이때 서버가 suspend되기 이전에 해당 애플리케이션의 상태가 DISTRIBUTED 상태였다면 서버가 resume이 되면서 이 애플리케이션을 start해야 한다.

INDEPENDENT 상태에서의 Boot-time Deploy

서버가 INDEPENDENT 상태로 부팅된 경우는 DAS의 관리를 받지 않는다. 또한 DAS와 연결할 수 없는 상황이기 때문에 애플리케이션 파일 전송도 받을 수 없다. 따라서 Boot-time Deploy할 때에도 이전에 받아놓았던 애플리케이션 파일이 없거나 잘못되어 있다면 Deploy를 진행할 수 없다.

INDEPENDENT 상태로 서버를 부팅할 때는 애플리케이션 파일에 접근할 수 있는 경우에만 Deploy를 진행할 수 있다. 애플리케이션 파일을 접근할 수 있는 경우는 다음의 3가지 경우를 말한다.

  • MS가 DAS와 같은 머신에 존재하여 DAS에 install된 애플리케이션 원본 파일에 접근 가능한 경우

  • 애플리케이션 파일이 NAS에 존재하여 MS에서도 접근 가능한 경우

  • 압축을 풀어놓은 Deploy 이미지 디렉터리가 남아있는 경우

위의 경우에 해당되지 않는다면 해당 애플리케이션은 deploy해야 할 애플리케이션 파일을 찾을 수 없기 때문에 Deploy에 실패한다. 이 경우에도 마찬가지로 서버는 STANDBY 상태가 되며 부팅을 멈추게 된다.

이때는 콘솔 툴을 통해 MS로 connect하여 local-start-server 명령을 통해 서버를 RUNNING 상태가 되도록 할 수 있다.

참고

local-start-server 명령을 수행해도 deploy를 성공할 가능성이 매우 희박하기 때문에 이럴 경우에는 -force 옵션을 주고 서버를 start한다.

INDEPENDENT 상태로 서버를 띄울 때에는 DEPENDENT 상태와는 달리 DAS로부터 distribute만 진행해야 하는 애플리케이션 리스트를 받아올 수 없다. 따라서 distribute에 성공한 애플리케이션 모두를 start시켜 서비스가능한 상태로 만든다.

INDEPENDENT 상태로 부팅한 서버가 DAS와 연결되어 DEPENDENT 상태가 되면, 옵션에 따라 distribute에 실패한 애플리케이션들을 모두 distribute를 재시도한다. 실패했던 애플리케이션들이 모두 distribute에 성공하면 Boot-time Deploy할 때와 마찬가지로 DAS로부터 start해야 하는 애플리케이션 리스트를 받아와서 start시켜준다.

또한, distribute만 해야 하는 애플리케이션이 start되어서 서비스되고 있는 경우 이 애플리케이션은 stop시켜준다. 단, 서버가 부팅 중에 DAS가 failback되어 DEPENDENT 상태가 되었다면 위 작업을 별도로 진행하지는 않는다.

1.2.3. 애플리케이션 동기화

애플리케이션 파일의 동기화는 DAS의 주요 역할 중 하나이다. DAS와 MS 사이에 애플리케이션 파일이 동기화되는 경우는 크게 몇 가지가 있다.

  • Run-time Deploy를 수행할 경우

    MS에서는 새로 deploy할 애플리케이션 파일을 DAS로부터 전송받는다.

  • Boot-time Deploy를 수행할 경우

    MS에 deploy해야 할 애플리케이션 파일이 변경되었다면 MS에서는 DAS로부터 애플리케이션 파일을 새로 전송받는다.

  • MS가 INDEPENDENT 상태였다가 DEPENDENT 상태로 변환된 경우

    MS가 INDEPENDENT 상태였다가 DEPENDENT 상태로 변환되어 DAS의 관리를 받게 된 경우, 옵션을 통해서 애플리케이션의 동기화를 진행한다. 도메인 설정 중 'enable-to-resynchronize-applications' 를 true로 설정한 경우에 한해서 동기화를 진행하고 기본값은 false로 동기화를 진행하지 않는다. 해당 옵션이 true로 설정 된 경우, MS에서는 deploy에 실패한 애플리케이션에 대해서 애플리케이션 파일을 다시 전송받는다. 또한 Deploy에 성공한 애플리케이션 중에서 DAS에서 관리하는 애플리케이션 파일이 변경된 경우에도 MS에서 애플리케이션 파일을 다시 전송받는다.

DAS에서는 애플리케이션 파일의 동기화뿐만 아니라 애플리케이션의 도메인에서의 상태도 동기화한다.

Boot-time Deploy를 수행할 때 애플리케이션이 DAS에서 DISTRIBUTED 상태로 관리되고 있다면 DISTRIBUTED 상태까지만 만들어준다. 이 애플리케이션을 서비스하기 위해서는 사용자가 start-application 명령을 수행해야 한다.

뿐만 아니라 MS가 INDEPENDENT 상태였다가 DEPENDENT 상태로 변환된 경우 MS에서는 애플리케이션 파일뿐만 아니라 상태도 동기화해준다. DEPENDENT 상태가 된 애플리케이션은 DAS에서 관리하고 있는 애플리케이션의 상태에 따라 MS에서 서비스되고 있는 애플리케이션의 상태도 바뀌게 된다.

INDEPENDENT 상태의 MS에서는 모든 애플리케이션이 서비스될 수 있도록 RUNNING 상태로 만들었지만, DAS와 연결되어 DEPENDENT 상태가 된 후에는 DAS의 상태를 따른다.

DAS에서 애플리케이션이 DISTRIBUTED 상태였다면 MS의 애플리케이션도 중지하여 DISTRIBUTED 상태로 만든다. 또한 DAS에서 이미 undeploy한 애플리케이션이 MS에 존재한다면 이 또한 MS에서도 undeploy한다.

1.3. Auto Redeploy

JEUS 6까지는 지정된 디렉터리 또는 애플리케이션을 주기적으로 검사하면서 변경된 내용이 있을 경우 자동으로 Deploy 시도가 가능했다. 이 기능을 사용하면 애플리케이션을 수동적으로 deploy할 필요가 없으므로 애플리케이션을 개발할 때나 빈번한 업데이트가 필요한 애플리케이션의 경우 유용하게 사용할 수 있었다. JEUS 7에서는 Auto Deploy 기능은 지원하지 않는다. 도메인에서 애플리케이션의 변경을 감지해서 redeploy하는 기능만 남겨둔다.

참고

JEUS 7에서부터 도메인 구조로 변경되면서 애플리케이션을 관리하는 주체가 DAS이기 때문에 Auto Deploy를 지원하기가 어려워졌다. 애플리케이션 대상을 도메인 단위로 보기도 어렵고 Exploded 모듈의 경우는 다른 머신으로 전송되지 않기 때문에 Auto Deploy 기능은 제공하지 않는다.

대신 최초 deploy할 때 애플리케이션 대상과 Auto Redeploy를 체크할 주기를 설정해서 수동으로 deploy를 하면 애플리케이션 파일이 변경된 경우에 이를 감지하여 애플리케이션 대상으로 Auto Redeploy를 할 수 있다.

Auto Redeploy 설정을 한 애플리케이션에 대해서는 설정한 주기마다 애플리케이션 파일의 변경을 체크한다.

  • Archive 모듈의 경우는 Archive 파일의 last modified time으로 애플리케이션의 변경을 감지해서 redeploy한다.

  • Exploded 모듈의 경우는 표준 Deployment Descriptor(이하 DD)의 last modified time으로 변경을 감지해서 애플리케이션을 redeploy한다.

Redeploy는 DAS가 대상이 되는 서버로 redeploy 명령을 보내고, 서버에서는 Auto Redeploy와 일반 redeploy 명령이 다르게 동작하지 않는다. DAS에서는 모든 서버에 Redeploy가 성공해야 전체 성공으로 간주한다. 파일이 변경되었다고 해서 바로 redeploy되지 않을 수 있다.

설정한 주기가 되어야 애플리케이션 파일 변경 여부를 체크하기 때문에 최대 설정한 주기만큼 기다려야 Redeploy가 진행된다. 이 주기의 기본값은 10초이다.

1.4. 디렉터리 모드의 Deploy

애플리케이션은 Java EE 스펙에서 정의한 각 애플리케이션 타입에 맞는 형태로 압축되어 있어야 한다. 하지만 개발 단계에서의 편의성을 제공하기 위해 압축된 애플리케이션이 풀려있는 형태의 애플리케이션 또한 deploy할 수 있도록 지원하고 있다. JEUS에서는 이런 디렉터리 형태의 애플리케이션을 Exploded 모듈이라고 한다.

DAS와 같은 머신에 존재하는 서버나 클러스터를 대상으로 한 경우나 DAS와 다른 머신에 있는 서버나 클러스터이더라도 NAS(Network Attached Storage)와 같이 다른 머신에서도 접근 가능한 경로에 위치한 경우에 한해서 Deploy가 가능하다. 이런 애플리케이션은 install-application 명령을 통해서 DAS의 애플리케이션 INSTALL_HOME으로 install시키는 것이 아니라 애플리케이션의 상위 디렉터리를 WebAdmin의 'Application Repository' 항목을 지정하거나 deploy 명령을 할 때 -path 옵션을 주고 deploy해야 한다. 이런 애플리케이션을 deploy할 때도 옵션으로 애플리케이션의 ID를 줄 수 있다. ID를 주지 않은 경우는 애플리케이션 파일 이름이 애플리케이션의 ID가 된다.

1.5. 애플리케이션 저장소(Application Repositories)

도메인 환경에서는 해당 도메인에서 서비스되는 모든 애플리케이션을 DAS에서 관리하기 때문에 애플리케이션을 deploy하기 전에 애플리케이션 파일을 DAS로 install하는 작업을 항상 선행해야 한다. 하지만 도메인에 애플리케이션 저장소를 추가한 경우에는 애플리케이션 파일의 Install 작업을 생략해도 애플리케이션을 deploy할 수 있다.

1.5.1. 애플리케이션 저장소 추가/삭제/조회

도메인에서는 DAS로 install된 애플리케이션을 한 곳에 모아 관리한다. 이 디렉터리에는 수동으로 애플리케이션을 위치시킬 수는 없다.

여러 저장소(repository)를 설정할 수 있고, 설정한 디렉터리는 모두 애플리케이션 저장소로 인식된다. 애플리케이션 저장소를 추가, 삭제하고 설정되어 있는 정보를 조회하려면 WebAdmin이나 콘솔 툴을 사용해야 한다.

도메인에 애플리케이션 저장소로 설정한 디렉터리에는 Java EE 애플리케이션을 위치시킬 수 있다. Archive 모듈뿐만 아니라 Exploded 모듈도 가능하다.

도메인에 등록된 애플리케이션 저장소(repository)에는 install-application/uninstall-application 명령을 통해서 애플리케이션 파일을 추가, 삭제하는 것은 불가능하다. 애플리케이션 파일을 수동으로 추가, 삭제하면 도메인에서 이를 자동으로 인식할 수 있다. 이렇게 위치시킨 애플리케이션은 도메인에서 INSTALLED 상태로 인식된다. 삭제된 애플리케이션 파일은 애플리케이션 정보에 나타나지 않고 더 이상 도메인에서 관리하지 않는다.

애플리케이션의 ID는 애플리케이션 파일 이름이기 때문에 deploy 명령을 할 때 파일 이름을 -id 옵션으로 지정한다.

애플리케이션 파일이 업데이트하려면 이 저장소의 파일을 수동으로 업데이트한다. 만약 애플리케이션을 deploy할 때 Auto Redeploy 주기를 설정했다면 DAS에서 파일의 변경 여부를 자동으로 감지하여 Auto Redeploy가 가능하다.

애플리케이션 저장소를 추가할 때 저장소에 존재하는 파일 이름이 이미 도메인에서 사용되고 있는 애플리케이션 ID라면 해당 애플리케이션은 도메인에서 인식되지 않고 다음과 같은 로그 메시지가 발생한다.

[2012.05.15 12:37:40.625][1] [adminServer-68] [Deploy-0005] WARNING: The application[myApp] already exists on /JEUS_HOME/.applications/myApp.ear. Change the file name of [/home/user1/apps/myApp].

중복된 애플리케이션 ID를 사용하는 경우 애플리케이션 정보 요청하거나 DAS를 시작하는 경우도 동일한 로그가 발생한다.

또한 추가하려는 애플리케이션 저장소에 유효한 애플리케이션이 존재하지 않는다면 다음과 같은 로그 메시지가 발생한다.

[2012.05.15 12:37:40.625][1] [adminServer-68] [Deploy-0062] WARNING: The repository(/home/user1/apps) does not contain any valid applications, but new applications can be added.

애플리케이션 저장소를 삭제할 때 저장소에 존재하는 파일이 도메인에 distribute되어 있거나 deploy되어 있다면 애플리케이션 저장소는 삭제되지만 애플리케이션이 도메인의 관리 대상에서 삭제되지는 않고 다음과 같은 로그 메시지가 발생한다.

[2012.05.15 12:44:04.328][1] [adminServer-93] [Deploy-0124] WARNING: The application[myApp] is RUNNING in repository[/home/user1/apps]. To remove this application from the domain, undeploy it.

주의

애플리케이션 저장소를 삭제하려고 하는 의도가 이미 서비스되고 있는 애플리케이션까지 도메인에서 제외시키겠다는 의도인지 알 수 없다. 서비스되고 있는 애플리케이션을 제외한 다른 애플리케이션만 제외될 것을 원할 수도 있기 때문에 JEUS에서 이를 판단해주기가 모호하다. 따라서 저장소를 삭제할 때 서비스 중인 애플리케이션을 내리고 싶다면 undeploy 명령을 수행해야 한다.

WebAdmin 사용

다음은 WebAdmin을 사용해서 애플리케이션의 저장소를 추가하는 과정에 대한 설명이다.

  1. WebAdmin의 왼쪽 메뉴에서 [Domain]을 선택하면 Domain 설정 화면으로 이동한다. 저장소를 추가하기 위해서 왼쪽 메뉴 하단에 위치한 [LOCK & EDIT] 버튼을 클릭한다.

  2. Domain 설정 화면에서 'Application Repositories' 항목에 추가할 저장소 디렉터리를 입력한다. [확인] 버튼을 클릭하면 변경된 설정이 저장되고, 화면 상단에 저장 결과에 대한 메시지가 나타난다.

    'Application Repositories' 항목의 [입력] 버튼을 클릭하면 Navigation 팝업 화면이 나타나고 애플리케이션 저장소의 경로를 선택할 수 있다.

  3. 화면 왼쪽 하단에 위치한 [Activate Changes] 버튼을 클릭하여 추가한 애플리케이션 저장소를 도메인에 반영한다.

    Activate Changes 팝업 화면에서 변경하려는 설정에 대한 설명을 작성할 수 있다. 'Description' 항목에 해당 변경에 대한 설명을 작성하고 [확인] 버튼을 클릭한다.

  4. 서버에 Activate가 완료되면 설정한 애플리케이션 저장소 디렉터리가 도메인에 추가되고, 화면 상단에 반영 결과를 자세하게 표시된다.

  5. WebAdmin의 왼쪽 메뉴에서 [Applications]를 선택하여 Deployed Applications 화면으로 이동한다. 도메인에 추가한 애플리케이션 저장소에 있는 애플리케이션들이 INSTALLED 상태로 도메인에 등록된 것을 확인할 수 있다.

콘솔 툴 사용

도메인에 애플리케이션 저장소를 추가하려면 add-application-repository 명령을 사용하고, 삭제하려면 remove-application-repository 명령을 사용한다. install할 때 설정하는 ID로 애플리케이션 관리 디렉터리 하위에 디렉터리를 생성하고 거기에 애플리케이션 Archive 파일을 위치시킨다.

다음은 콘솔 툴으로 애플리케이션 저장소를 추가, 삭제, 조회하는 예제이다.

[DAS]domain1.adminServer>add-application-repository /apps/test
Successfully performed the ADD operation for An application repository.
Check the results using "add-application-repository or list-application-repositories"

[DAS]domain1.adminServer>list-application-repositories
Application Repositories
================================================================================
+------------------------------------------------------------------------------+
|                        Path to Application Repository                        |
+------------------------------------------------------------------------------+
| /apps/test                                                                   |
+------------------------------------------------------------------------------+
================================================================================

[DAS]domain1.adminServer>remove-application-repository /apps/test
Successfully performed the REMOVE operation for An application repository.
Check the results using "remove-application-repository or list-application-repositories"

[DAS]domain1.adminServer>list-application-repositories
Application Repositories
================================================================================
+------------------------------------------------------------------------------+
|                        Path to Application Repository                        |
+------------------------------------------------------------------------------+
(No data available)
================================================================================

참고

콘솔 툴에서 애플리케이션 저장소를 추가, 삭제, 조회하는 명령에 대한 자세한 설명은 JEUS Reference Book”의 “4.2.6.1. add-application-reporitory”JEUS Reference Book”의 “4.2.6.11. remove-application-repository”JEUS Reference Book”의 “4.2.6.9. list-application-repositories”를 참고한다.

1.5.2. 애플리케이션 저장소에 있는 애플리케이션 Deploy

애플리케이션 저장소를 추가한 후에는 저장소에 존재하는 애플리케이션을 WebAdmin과 콘솔 툴로 deploy할 수 있다. 자세한 내용은 절 4.4.2. “애플리케이션 저장소에 있는 애플리케이션 Deploy”를 참고한다.

1.6. path를 지정하여 Deploy

도메인 환경에서 권장하는 애플리케이션 파일의 관리 방법은 2가지로 구분된다.

애플리케이션 파일이 도메인에 의해 관리되길 원한다면 애플리케이션을 INSTALL_HOME으로 install하는 것을 권장하고 사용자가 직접 애플리케이션 파일을 관리하려면 애플리케이션 저장소를 설정하는 것을 권장한다. 애플리케이션 파일을 직접 관리해도 실제 운영환경에서는 도메인에서 사용할 애플리케이션 파일을 업무별로 묶어 몇 개의 디렉터리에 위치시키는 것을 권장하기 때문이다.

하지만 개발 단계에서는 이렇게 애플리케이션을 모아두지 않고 별개로 각각 다른 경로에 존재할 수도 있다. 이 경우 개발의 편의성을 위해 애플리케이션 deploy할 때 -path 옵션을 주고 deploy할 수 있도록 제공한다.

path를 지정해서 애플리케이션을 deploy할 때는 -id 옵션은 설정할 수 없다. Exploded 모듈이나 Archive 모듈 모두 Deploy가 가능하고, 애플리케이션 파일의 경로를 -path 옵션으로 주고 deploy한 애플리케이션은 도메인의 애플리케이션 INSTALL_HOME으로 복사하는 과정 없이 애플리케이션을 DAS에 등록하여 Deploy를 진행한다. 이때 애플리케이션 ID는 애플리케이션 파일 이름을 그대로 사용한다.

WebAdmin과 콘솔 툴을 통해 -path 옵션을 주고 deploy하는 방법에 대한 자세한 내용은 절 4.4.2. “path를 지정하여 Deploy”를 참고한다.

1.7. Staging Mode Deploy

Exploded 모듈의 경우는 DAS와 같은 머신에 존재하는 MS에만 deploy할 수 있다. Exploded 모듈의 경우는 주로 개발 단계에서 사용하므로 여러 머신을 사용하지 않기 때문에 같은 머신에서만 Exploded 모듈을 deploy하고 서비스할 수 있다. 하지만 테스트 단계에서는 애플리케이션을 Exploded 모듈 형태로 유지하면서 여러 머신에 도메인을 구성하여 테스트할 수 있기 때문에 Exploded 모듈을 다른 머신에 deploy할 수 있는 방법이 필요하다.

애플리케이션을 deploy할 때 -staging 옵션을 주고 deploy하면 Exploded 모듈을 압축하여 다른 머신에 존재하는 MS에도 전송해줄 수 있다. staging으로 deploy된 애플리케이션은 MS에서는 Archive 모듈과 동일하게 취급된다. 압축을 풀어서 deploy하고, MS가 재기동될 때는 DAS와 애플리케이션 파일을 동기화한다.

애플리케이션의 내용이 변경되었다면 redeploy 명령으로 변경된 파일을 MS에 적용하고 다시 deploy할 수 있다. redeploy 명령을 할 때는 -staging 옵션을 줄 필요없이 기존 Archive 모듈을 redeploy할 때와 마찬가지로 redeploy 명령을 수행한다. 단, 이때는 -path 옵션을 주면 안 된다. MS에서는 redeploy 명령을 받아서 우선적으로 애플리케이션 파일에 대한 동기화 작업을 진행하고 기존 애플리케이션을 undeploy한 뒤 새로운 애플리케이션을 deploy한다.

WebAdmin과 콘솔 툴을 통해 -staging 옵션을 주고 deploy하는 방법에 대한 자세한 내용은 “4.5. Staging Mode Deploy”를 참고한다.

1.8. 애플리케이션 Undeploy

JEUS 관리 도구를 이용해서 명시적으로 애플리케이션을 undeploy하는 것과 서버 셧다운 시점에 애플리케이션이 undeploy되는 것은 서로 동작 방식이 구분된다.

다음은 두 동작의 차이점이다.

 관리 명령에 의한 Undeploy서버 셧다운 시점의 Undeploy
파일 삭제 여부서버 내부적으로 생성한 파일을 삭제한다. 예를 들어 JSP, EJB 컴파일 결과물들이 삭제되고 EJB 3.0 스케줄 정보가 DB에서 삭제된다.서버 내부적으로 생성한 파일을 삭제하지 않는다.
적용되는 TimeoutGraceful Undeploy TimeoutGraceful Shutdown Timeout(Undeploy Timeout은 적용되지 않는다)