다음 그림은 Context/Web application에 관련된 웹 컨테이너의 그림이다.

[그림 6.1] JEUS 웹 컨테이너에 context/Web application

웹 애플리케이션은 클라이언트의 요청에 의한 웹 기반의 서비스(예를 들면, 장바구니에 물품을 추가하거나, 장바구니 안의 물품을 구매하거나 웹 기반의 경매 사이트에서 물건을 사기 위해 브라우징하는 등)를 수행하기 위한 static과 dynamic content의 집합이라고 할 수 있다.

JEUS 웹 컨테이너를 설명할 때 Java EE 웹 애플리케이션에 초점이 맞춰진다. Static 부분 뿐만 아니라 이런 애플리케이션의 패키징과 개발 규칙들까지 모두 Java EE 5 스펙, Servlet 2.5스펙, JSP 2.1 스펙에 정의되고 기술되어 있다.

Context는 논리적으로 Context Group 또는 가상 호스트 하위에 존재한다. 가상 호스트는 Context Group의 서브 컴포넌트이다. 등록된 Context는 묵시적 기본 가상 호스트로 작동한다. 본 장에서는 간략하게 기본 가상 호스트의 일부로 Context Group 아래에 Context를 설정한다고 가정한다.

가상 호스트의 더 자세한 사항은 “제7장 가상 호스트”를 참고한다.

Java EE 웹 애플리케이션은 Java EE 웹 컨테이너에 배포되고 등록되기 전에 특수한 Archive(라이브러리) 파일에 패키징하여 포함시켜야 한다. 이 애플리케이션들을 패키지할 때 사용하는 Archive들은 JAR/ZIP 파일들로 '.war' 확장자를 가지고 있다. 이들은 JAR 유틸리티를 사용하여 다른 JAR Archive를 생성하는 방법과 동일하게 생성된다.

WAR 파일의 구조는 다음과 같다.

[그림 6.2] WAR 파일 구조

다음 그림은 Context와 그 상위 컴포넌트들의 기본 디렉터리 구조이다.

[그림 6.3] Web Context 디렉터리의 구조

우선 디플로이할 웹 애플리케이션을 위해 jeus-web-dd.xml의 <context-path>에 설정할 다음과 같은 작업 디렉터리를 생성한다. 여기서는 <context-path>가 ‘/MyContext’라고 가정한다.

JEUS_HOME\webhome\app_home\MyContext

Context 디렉터리는 임의의 위치에 생성하여도 무방하다. 그 임의의 위치에서 관련 파일 작업을 한 후에 exploded 또는 archive 형태로 JEUSMain.xml의 <application> 등록, archive 형태로 autodeploy에 위치시켜서 재기동하거나 직접 콘솔 툴(jeusadmin)에서 디플로이가 가능하다.

webhome\app_home을 Context 디렉터리의 루트 디렉터리로 권장하는 이유는 콘솔 툴(jeusadmin)이나 웹 관리자(WebAdmin)의 사용에 있어서 편리함을 제공하기 때문이다.

예를 들어 콘솔 툴(jeusadmin)에서 디플로이 이후 인자로 Context 이름만 입력하여도 app_home의 웹 애플리케이션을 찾아서 디플로이해 주며, WebAdmin에서는 app_home의 웹 애플리케이션의 목록을 자동으로 출력한다.

Context 디렉터리를 생성한 후에는 웹 애플리케이션 디렉터리 구조 [그림 6.3]을 따라서 관련 파일을 생성하여 위치시킨다.

Context 디렉터리 생성이 완료되면 그 context를 위해 JEUS 전용의 DD를 생성한다. Well-formed DD를 작성할 때에는 JEUS_HOME\lib\schemas\jeus\jeus-web-dd.xsd을 준수하여 작성한다.

생성할 DD 파일의 위치는 다음과 같다. 여기에는 web.xml이 같이 위치한다.

JEUS_HOME\webhome\app_home\MyContext\WEB-INF

Web DD 파일이 생성되면 내용을 작성한다. 다음에서 이 파일에 포함될 설정 요소들에 대해서 설명한다. 좀 더 자세한 정보는 JEUS_HOME\docs\reference\schema\index.html에서 jeus-web-dd.xml를 참조한다.

다음은 JEUS Web Context 설정 파일의 예로 몇몇 항목들은 생략되어 있다.

<jeus-web-dd  xmlns="http://www.tmaxsoft.com/xml/ns/jeus" version="6.0">
   <context-path>/examples</context-path>
   <enable-jsp>true</enable-jsp>
   <auto-reload>
      <enable-reload>true</enable-reload>
         <check-on-demand>true</check-on-demand>
         <reload-timeout>30000</reload-timeout>
   </auto-reload>
   <max-instance-pool-size>20</max-instance-pool-size>
   <added-classpath>
       <class-path>c:\mylib\lib.jar</class-path>
   </added-classpath>
   <allow-indexing>
       <directory>/images/</directory>
   </allow-indexing>
   <deny-download>
       <file>/data/secret.dat</file>
       <extension>dat</extension>
       <directory>/data/</directory>
   </deny-download>
   <aliasing>
       <alias>
           <alias-name>/images/</alias-name>
           <real-path>c:\web\images\</real-path>
       </alias>
   </aliasing>
   <file-caching>
       <max-idle-time>1800</max-idle-time>
       <max-cache-memory>10</max-cache-memory>
       <directory>/images/</directory>
   </file-caching>
       . . .
   <jsp-engine>
       . . .
   </jsp-engine>
   <session-config>
       . . .
   </session-config>
   <fast-deploy>true</fast-deploy>
   <library-ref>
       <library-name>myLibrary</library-name>
       <specification-version>2.0</specification-version>
   </library-ref>
   <properties>
       <property>
           <key>jeus.servlet.jsp.print.null.as.emptystring</key>
           <value>true</value>
       </property>
   </properties>
</jeus-web-dd>

다음은 설정 태그에 대한 설명이다.

Shared Library는 애플리케이션별로 필요한 라이브러리를 WEB-INF\lib가 아닌 JEUS_HOME\lib\shared 아래에 추가한 후에 여러 애플리케이션에서 공유하여 사용할 수 있도록 해준다. JEUS 재기동없이도 libraries.xml 파일 수정 후 모듈을 다시 디플로이하면 변경된 라이브러리가 반영된다.

Shared Library를 추가하기 위해서는 다음과 같이 JEUS_HOME\lib\shared\libraries.xml 파일에서 JSF, JSTL 라이브러리는 변경하지 않고 <library> 태그를 추가하고 공유할 JAR 파일들을 지정한다.

버전은 스펙 버전과 구현체 버전을 각각 지정할 수 있다. 다음은 스펙 버전에 대한 예이고, 구현체 버전에 대한 설명은 "JSF1.2, JSTL1.2 라이브러리 설정"을 참고한다.

<libraries xmlns="http://www.tmaxsoft.com/xml/ns/jeus">
    <!-- DO NOT MODIFY JSF1.2 and JSTL1.2 libraries!!! -->
    <library>
        <library-name>jsf</library-name>
        <specification-version>1.2</specification-version>
        <implementation-version>1.2_06</implementation-version>
        <files dir=".">
            <include name="jsf-injection-provider.jar"/>
        </files>
        <files dir="jsf_ri_1.2_06"/>
    </library>    
    <library>
        <library-name>jstl</library-name>
        <specification-version>1.2</specification-version>
        <implementation-version>1.2</implementation-version>
        <files dir="jstl_1.2"/>
    </library>

    <!-- Add user libraries from here -->
    <library>
        <library-name>myLibrary</library-name>
        <specification-version>2.0</specification-version>
        <implementation-version>2.1</implementation-version>
        <files dir=".">
            <include name="commons-logging.jar"/>
            <include name="commons-util.jar"/>
        </files>
        <files dir="myLib-2.1"/>
    </library>
</libraries>

Shared Library를 참조하기 위해서는 jeus-web-dd.xml에 다음과 같이 <library-ref>를 설정하면 된다. 버전이 명시되지 않은 경우는 libraries.xml에 등록된 동일한 이름의 라이브러리 중에서 최상위 버전을 참조한다.

   <library-ref>
       <library-name>myLibrary</library-name>
       <specification-version>2.0</specification-version>
   </library-ref>

JSF1.2, JSTL1.2 라이브러리 설정

[예 6.2]에 설명한 libraries.xml 파일에는 JSF1.2와 JSTL1.2가 Shared Library로 이미 추가되어 있음을 확인할 수 있다. Java EE 5 스펙은 JSF1.2와 JSTL1.2를 포함하고 있기 때문에 WEB-INF\lib 아래에 JSF, JSTL 라이브러리 없이도 정상적으로 디플로이가 되어야 한다.

JEUS_HOME\lib\system 아래에 JSF와 JSTL 구현체를 두면 Java EE 5 스펙을 만족할 수 있지만 이 경우에는 하나의 JSF, JSTL 구현체만 사용할 수 있는 문제가 발생한다. JSF 구현체는 1.2 뿐만 아니라 1.1 버전도 있고 SUN RI가 아닌 Apache의 myfaces도 있기 때문에 JEUS에서는 여러 가지 버전의 구현체를 사용할 수 있도록 Shared Library 형태로 JSF, JSTL을 제공한다.

구현체의 위치, 종류에 따라 사용되는 구현체의 경우는 다음과 같이 나누어 진다.

특정 버전의 JSF나 JSTL을 사용하기 위해서는 libraries.xml에 library를 등록하고 jeus-web-dd.xml에서 <library-ref>로 참조하도록 할 수도 있다. 가장 간단한 방법은 기존 J2EE1.4의 웹 모듈처럼 WEB-INF\lib 아래에 JSF, JSTL 구현체를 위치시키면 된다.

JSF1.2의 경우는 Managed Bean에서 @EJB나 @Resource 같은 annotation으로 WAS가 제공하는 리소스에 접근할 수 있고 WAS는 annotation으로 명시된 리소스들을 injection할 수 있어야 한다.

JEUS에서는 JSF1.2 RI에 JEUS Injection을 지원하기 위해서 Shared Library로 jsf-injection-provider.jar를 제공하고 있다.

JEUS 5에서는 사용자의 편의성과 Servlet 2.3 이전에 개발된 애플리케이션을 위해서 표준이 아닌 기능도 제공하고 JSP Parsing에 문법 체크도 최신 스펙에 비해서 엄격하지 않게 적용하였다.

Servlet 2.3 이전에는 Servlet과 JSP를 직접 사용해서 웹 애플리케이션을 개발했지만 현재는 웹 프레임워크를 점차 사용하는 추세이고 Java EE 5에서는 표준 웹 프레임워크로 JSF1.2와 JSTL1.2가 추가되었다.

웹 프레임워크는 Servlet, JSP 스펙에 대한 참조 구현체인 Tomcat을 사용해서 주로 개발하고 테스트하기 때문에 스펙과 다른 비표준 기능 지원시 다양한 호환성 문제가 발생할 수 있다. 그래서 JEUS 6에서는 JEUS 5에 대한 하위 호환성을 위해서 기존의 JSP Parser도 지원하지만 디폴트는 Jasper 기반의 JSP Parser로 변경하였다.

JEUS 5에서 문제가 없었던 웹 모듈도 JEUS 6에 디플로이하면 여러 가지 에러가 발생할 수 있다. JEUS 6에서 Servlet 2.5, JSP 2.1, JSF 1.2, JSTL 1.2의 최신 스펙을 사용하기 위해서는 JSP 컴파일할 때 발생하는 에러 메시지와 JSP 라인을 확인 후 수정해서 업그레이드해야 한다.

디플로이할 때 다음과 같은 형태로 에러가 발생한다면 '/jsp/customtag12/date.jsp'의 2번째 라인의 62번째 컬럼에서 어떤 문제가 있는지 확인해야 한다.

[2007.01.15 10:02:29][2][b029] [mycontainer-12] [WEB-5697] [examples#examples] par
sing 35 jsp file(s)
[2007.01.15 10:02:33][1][b029] [mycontainer-12] fail to parse jsp file : /jsp/cust
omtag12/date.jsp
<<__Exception__>>
jeus.servlet.jsp2.Jsp2EngineException: 
file:C:/jeus6/webhome/johan_mycontainer/examples/examples_war___/jsp/customtag12/d
ate.jsp(2,62) 
Failed to load or instantiate TagExtraInfo class: customtag12.ShowDateTei
    at jeus.servlet.jsp2.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler
.java:59)
    at jeus.servlet.jsp2.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:46
7)
    at jeus.servlet.jsp2.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:29
8)

만약 최신 스펙이 필요하지 않고 기존에 개발된 모듈을 그대로 JEUS6에서 사용하기 위해서는 다음과 같이 jeus-web-dd.xml에 JEUS5 호환의 JSP Parser가 이 Context에만 적용되도록 설정할 수 있다.

    <properties>
        <property>
            <key>jeus.servlet.jsp.modern</key>
            <value>false</value>
        </property>
    </properties>

jeus-web-dd.xml에 설정한 옵션은 이 Context에만 적용되고 WEBMain.xml에서는 ContextGroup이나 VirtualHost 단위로도 옵션을 설정할 수 있다. Container 레벨에서 옵션을 적용하기 위해서는 다음과 같은 VM 옵션을 설정할 수 있다.

-Djeus.servlet.jsp.modern=false

VM 옵션은 ContextGroup, VirtualHost, Context에서 Override되기 때문에 jeus-web-dd.xml에 설정한 옵션이 최종적으로 적용된다. jeus-web-dd.xml에 옵션 설정이 없다면 상위의 디폴트 설정이 적용된다. 나머지 옵션들은 “JEUS Reference Book”의 “1.7. 서블릿/웹 시스템 프로퍼티”에서 확인할 수 있다.

추가 옵션은 하위 호환성이 필요한 경우만 적용하고 신규 개발은 추가적인 옵션 없이 표준에 따라 개발할 것을 권장한다.

정적 리소스를 처리하는 서블릿 매핑

Servlet 표준에서는 Servlet 또는 JSP가 아닌 경우 WAS에서 제공하는 기본 서블릿(Default Servlet)으로 처리하도록 되어 있다. 이를 ResourceServlet이라고 한다. JEUS v6.0 Fix#9부터는 이러한 ResourceServlet을 직접 매핑해서 사용할 수 있다.

다음과 같이 web.xml에서 <servlet-mapping> 설정에 'jeus.servlet.servlets.ResourceServlet'로 매핑한다.

<servlet-mapping>
    <servlet-name>jeus.servlet.servlets.ResourceServlet</servlet-name>
    <url-pattern>/static/*</url-pattern>
</servlet-mapping> 

jeus-web-dd.xml을 통해 애플리케이션별로 적용할 웹 보안 설정에 대해 설명한다.

Redirect Location 보안 설정

애플리케이션은 javax.servlet.http.HttpServletResponse.sendRedirect(String location) 표준 API를 통해서 "302 Found" 응답을 보낼 수 있다. 이때 기본적으로 Location으로 넘겨주는 문자열에 대해서 아무런 확인을 하지 않고 그대로 URL로 전환해서 Location 헤더로 설정한다. 그렇기 때문에 악의적인 사용자가 CRLF injection과 같은 공격을 할 수 있다. 이를 방지하기 위해 애플리케이션은 jeus.servlet.security.RedirectStrategy 인터페이스를 구현해서 jeus-web-dd.xml에 설정할 수 있다.

다음은 jeus.servlet.security.RedirectStrategy 인터페이스를 설정한 예이다.

package jeus.servlet.security;

import javax.servlet.http.HttpServletRequest;

public interface RedirectStrategy {
    /**
     * Makes the redirect URL.
     *
     * @param location the target URL to redirect to, for example "/login"
     */
    String makeRedirectURL(HttpServletRequest request, String location)
        throws IllegalArgumentException;
}         

설정한 인터페이스를 다음과 같이 구현할 수 있다.

package jeus.servlet.security;
import javax.servlet.http.HttpServletRequest;

public class RejectCrlfRedirectStrategy implements RedirectStrategy {
    private Pattern CR_OR_LF = Pattern.compile("\\r|\\n");

    @Override
    String String makeRedirectURL(HttpServletRequest request, String location)
       throws IllegalArgumentException {
        if (CR_OR_LF.matcher(location).find()) {
           throw new IllegalArgumentException("invalid characters (CR/LF) in redirect location");
        }
       return makeAbsolute(location);
    }

    private String makeAbsolute(String location) {
       // make code for make absolute path
    }
}         

jeus-web-dd.xml의 설정 방법은 다음과 같다.

...
<web-security>
    <redirect-strategy-ref>
    jeus.servlet.security.RejectCrlfRedirectStrategy
    </redirect-strategy-ref>
</web-security>
..

<redirect-strategy-ref>는 jeus.servlet.security.RedirectStrategy 인터페이스를 구현한 클래스 이름이다. 이 클래스는 웹 애플리케이션의 클래스 패스에 포함시키면 된다.

위에서 제시한 jeus.servlet.security.RejectCrlfRedirectStrategy의 경우 기본적으로 제공하는 RedirectStrategy이며 CR, LF 또는 CRLF가 있는 Location이 sendRedirect API로 넘어올 경우 500 에러가 발생한다.

그 외에도 CR, LF 또는 CRLF 문자열을 빈 문자열로 치환해주는 jeus.servlet.security.RemoveCrlfRedirectStrategy를 제공한다.

본 절에서는 web.xml에 정의된 보안 Role을 실제 시스템 사용자와 사용자 그룹에 어떻게 지정하는지 살펴보겠다. 이 매핑은 “jeus-web-dd.xml”에 기술된다

개발자가 다음의 내용을 DD(web.xml)에 정의하였다고 가정하자.

<web-app>
    <security-role>
        <role-name>manager</role-name>
    </security-role>
    <security-role>
        <role-name>developer</role-name>
    </security-role>
    <servlet>
        . . .
    </servlet>
    <security-constraint>
        <web-resource-collection>
            <web-resource-name>
                MyResource
            </web-resource-name>
            <url-pattern>/jsp/*</url-pattern>
            <http-method>GET</http-method>
            <http-method>POST</http-method>
        </web-resource-collection>
        <auth-constraint>
            <role-name>manager</role-name>
        </auth-constraint>
    </security-constraint>
</web-app>

위의 예제에서는 굵은 글씨로 두 개의 보안 Role이 선언되어 있다. 세 번째 굵은 글자 라인은 manager role이 <security-constraint> 태그에 어떻게 사용되어 지는지를 보여주고 있다.

웹 애플리케이션이 실제의 시스템에 디플로이될 때, manager와 developer Role을 시스템의 특정한 사용자로 바인딩해야 한다. 이 매핑은 <context><role-mapping>에 정의되어 있다. <role-mapping> 태그는 0개 이상의 <role-permission> 태그들을 가지고 있다. 이 태그를 이용하여 <principal-to-role> 매핑을 정의한다. 다음의 하위 태그들과 함께 바인딩된다.

2개의 Role “manager”와 “developer”가 “Peter”와 “Linda”로 각각 매핑되어 있다.

<jeus-web-dd  xmlns="http://www.tmaxsoft.com/xml/ns/jeus" version="6.0"> 
     . . .
     <role-mapping>
         <role-permission>
             <principal>Peter</principal>
             <role>manager</role>
         </role-permission>
         <role-permission>
             <principal>Linda</principal>
             <role>developer</role>
         </role-permission>
     </role-mapping>
     . . .
</jeus-web-dd>

Role이 실제 사용자에 매핑되듯이 EJB 레퍼런스, 자원 레퍼런스, 관리되는 객체의 레퍼런스를 실제 시스템 자원에 매핑할 필요가 있다.

다음은 Symbolc 레퍼런스 매핑의 예이다.

<web-app>
    . . .
    <ejb-ref>
        <ejb-ref-name>ejb/account</ejb-ref-name>
        <ejb-ref-type>Entity</ejb-ref-type>
        <home>com.mycompany.AccountHome</home>
        <remote>com.mycompany.Account</remote>
    </ejb-ref>
    <resource-ref>
        <res-ref-name>jdbc/EmployeeAppDB</res-ref-name>
        <res-type>javax.sql.DataSource</res-type>
        <res-auth>Container</res-auth>
        <res-sharing-scope>Shareable</res-sharing-scope>
    </resource-ref>
    <resource-env-ref>
        <resource-env-ref-name>
            jms/StockQueue
        </resource-env-ref-name>
        <resource-env-ref-type>
            javax.jms.Queue
        </resource-env-ref-type>
    </resource-env-ref>
    . . .
</web-app>

이 웹 애플리케이션을 등록하기 위하여, web.xml에 있는 <ejb-ref>, <resource-ref>, <resource-env-ref> 아래의 모든 Symbolc 레퍼런스 이름들이 실제 의도하는 자원의 JNDI 이름과 매핑되어야 한다. 이 매핑은 jeus-web-dd.xml에서 <ejb-ref>, <res-ref>, <res-env-ref>를 추가하면 완성된다.

이 태그들은 다음과 같은 하위 태그들을 가지는 <jndi-info> 태그가 있다.

다음은 JNDI 이름이 위의 3개의 레퍼런스와 매핑된 jeus-web-dd.xml의 예이다.

<jeus-web-dd  xmlns="http://www.tmaxsoft.com/xml/ns/jeus" version="6.0">
        . . .
        <ejb-ref>
            <jndi-info>
                <ref-name>ejb/account</ref-name>
                <export-name>AccountEJB</export-name>
            </jndi-info>
        </ejb-ref>
        <res-ref>
            <jndi-info>
                <ref-name>jdbc/EmployeeAppDB</ref-name>
                <export-name>EmployeeDB</export-name>
            </jndi-info>
        </res-ref>
        <res-env-ref>
            <jndi-info>
                <ref-name>jms/StockQueue</ref-name>
                <export-name>StockQueue</export-name>
            </jndi-info>
        </res-env-ref>
        . . .
</jeus-web-dd>

웹 애플리케이션을 디플로이하는 방법은 다음과 같은 3가지 방법이 있다.

다음은 JEUSMain.xml의 <application> 등록하는 예제이다.

JEUS_HOME은 c:\jeus6로 가정하고 “Examples”와 “MyApp”라는 2개의 Context를 등록한다. 두 Context의 요청 URL은 “/examples”와 “/myapp”라고 지정되어 있다. 예를 들어, http://www.foo.com/examples/index.html를 요청하면 “Examples” context의 “index.html”을 반환한다(웹 컨테이너의 context group의 HTTP 리스너의 포트가 80으로 설정되어 있다고 가정한다).

<jeus-system xmlns="http://www.tmaxsoft.com/xml/ns/jeus">
    <node>
        <name>tmax1</name>
        ...
    </node>
    <application>
        <name>Examples</name>
        <path>
          c:\jeus6\webhome\app_home\examples
        </path>
        <deployment-target>
            <target>
                <engine-container-name>
                    tmax1_container1
                </engine-container-name>
                <web-context-group>
                    <name>MyGroup</name>
                    <virtual-host-name>
                       www.foo.com
                    </virtual-host-name>
                </web-context-group>
            </target>
        </deployment-target>
        <deployment-type>COMPONENT</deployment-type>
        <web-component/>
    </application>
    <application>
        <name>MyApp</name>
        <path>
          c:\jeus6\webhome\app_home\myapp
        </path>
        <deployment-target>
            <target>
                <engine-container-name>
                    tmax1_container1
                </engine-container-name>
                <web-context-group>
                    <name>MyGroup</name>
                    <virtual-host-name>
                       www.foo.com
                    </virtual-host-name>
                </web-context-group>
            </target>
        </deployment-target>
        <deployment-type>COMPONENT</deployment-type>
        <web-component/>
    </application>
</jeus-system>

등록의 마지막 과정으로 웹 애플리케이션의 JSP 페이지들을 프리컴파일할 수 있다. 이것은 JEUS_HOME\bin\의 JSP 배치 컴파일러 appcompiler, jspc 툴로 한다.

appcompiler는 JEUS와 관계없이 오프라인 상태에서 JSP 프리컴파일이 가능하고, jspc는 JEUS가 기동되고 디플로이가 완료된 모듈에 대해서 프리컴파일을 수행할 수 있다. 이 툴들에 대해서는 “JEUS Reference Book”의 “4.4. appcompiler”와 “JEUS Reference Book”의 “4.7. jspc”의 설명을 참고한다.

JSP 배치 컴파일러를 이용하면, JSP가 처음 요청되었을 때의 성능을 향상시킬 수 있다. 배치 컴파일러는 새로운 웹 애플리케이션이 등록되었을 때 각 JSP를 수동으로 요청해야 하는 번거로움을 없애주므로 시스템 관리자에게는 편리성을 제공한다.

위의 과정을 거친 후 등록이 정확이 되었는지 수동으로 확인하기 위해서 jeusadmin 툴을 사용하여 웹 컨테이너를 재시작한다.

다음의 예에서 JEUS 노드 이름은 “johan”이라고 가정한다.