6.6. 배포 동작 사용자 정의


6.6.1. 배포 콘텐츠의 사용자 정의 디렉터리

배포된 콘텐츠를 저장할 JBoss EAP의 사용자 지정 위치를 정의할 수 있습니다.

독립 실행형 서버에 대한 사용자 지정 디렉터리 정의

기본적으로 독립 실행형 서버에 배포된 콘텐츠는 EAP_HOME/standalone/data/content 디렉터리에 저장됩니다. 이 위치는 서버를 시작할 때 -Djboss.server.deploy.dir 인수를 전달하여 변경할 수 있습니다.

$ EAP_HOME/bin/standalone.sh -Djboss.server.deploy.dir=/path/to/new_deployed_content

선택한 위치는 JBoss EAP 인스턴스 간에 고유해야 합니다.

참고

jboss.server.deploy.dir 속성은 관리 콘솔 또는 관리 CLI를 사용하여 배포된 콘텐츠를 저장하는 데 사용할 디렉터리를 지정합니다. 배포 스캐너에서 모니터링할 사용자 정의 배포 디렉터리를 정의하려면 배포 스캐너 구성 을 참조하십시오.

관리형 도메인에 대한 사용자 정의 디렉터리 정의

기본적으로 관리형 도메인에 배포된 콘텐츠는 EAP_HOME/domain/data/content 디렉터리에 저장됩니다. 이 위치는 도메인을 시작할 때 -Djboss.domain.deployment.dir 인수를 전달하여 변경할 수 있습니다.

$ EAP_HOME/bin/domain.sh -Djboss.domain.deployment.dir=/path/to/new_deployed_content

선택한 위치는 JBoss EAP 인스턴스 간에 고유해야 합니다.

6.6.2. 배포 순서 제어

JBoss EAP는 서버 시작 시 배포 순서에 대한 세분화된 제어를 제공합니다. 다시 시작한 후 주문의 지속성과 함께 여러 EAR 파일에 있는 애플리케이션 배포 엄격한 순서를 지정할 수 있습니다.

jboss-all.xml 배포 설명자를 사용하여 최상위 배포 간에 종속성을 선언할 수 있습니다.

예를 들어 먼저 배포되는 framework.ear 에 따라 app.ear 가 있는 경우 아래 표시된 대로 app.ear/META-INF/jboss-all.xml 파일을 생성할 수 있습니다.

<jboss xmlns="urn:jboss:1.0">
  <jboss-deployment-dependencies xmlns="urn:jboss:deployment-dependencies:1.0">
    <dependency name="framework.ear" />
  </jboss-deployment-dependencies>
</jboss>
참고

jboss-all.xml 파일에서 배포의 런타임 이름을 종속성 이름으로 사용할 수 있습니다.

이렇게 하면 framework.earapp.ear 앞에 배포됩니다.

중요

app.earjboss-all.xml 파일을 생성하고 framework.ear 를 배포하지 않으면 서버는 app.ear 를 배포하려고 시도하여 실패합니다.

6.6.3. 배포 콘텐츠 덮어쓰기

6.6.3.1. 배포 오버레이 정보

배포 오버레이 는 배포 아카이브의 콘텐츠를 물리적으로 수정하지 않고 기존 배포에 콘텐츠를 오버레이하는 데 사용할 수 있습니다. 아카이브를 다시 빌드하지 않고도 배포 설명자, 라이브러리 JAR 파일, 클래스, Jakarta 서버 페이지 및 기타 파일을 런타임 시 재정의할 수 있습니다.

이 기능은 다양한 구성 또는 설정이 필요한 다양한 환경에 맞게 배포를 조정해야 하는 경우에 유용할 수 있습니다. 예를 들어 애플리케이션 라이프사이클을 개발, 테스트, 스테이징, 프로덕션으로 이동하는 경우 배포 설명자를 교체하거나, 정적 웹 리소스를 수정하여 애플리케이션 브랜딩을 변경하거나, JAR 라이브러리를 대상 환경에 따라 다른 버전으로 교체할 수 있습니다. 또한 구성을 변경해야 하지만 정책 또는 보안 제한으로 인해 아카이브를 수정하거나 크래킹할 수 없는 설치에도 유용합니다.

배포 오버레이를 정의할 때 배포 아카이브의 파일을 대체할 파일 시스템에서 파일을 지정합니다. 배포 오버레이의 영향을 받는 배포도 지정해야 합니다. 변경 사항을 적용하려면 영향을 받는 배포를 재배포해야 합니다.

매개 변수

다음 매개변수 중 하나를 사용하여 배포 오버레이를 구성할 수 있습니다.

  • name: 배포 오버레이의 이름입니다.
  • Content: 파일 시스템의 파일을 대체하는 아카이브의 파일에 매핑하는 쉼표로 구분된 목록입니다. 각 항목의 형식은 ARCHIVE_PATH=FILESYSTEM_PATH 입니다.
  • deployments: 이 오버레이가 연결된 배포를 쉼표로 구분한 목록입니다.
  • redeploy-affected: 영향을 받는 모든 배포를 다시 배포합니다.

전체 사용량 세부 정보를 보려면 deployment-overlay --help 를 실행합니다.

6.6.3.2. 배포 오버레이 정의

배포 아카이브의 내용을 물리적으로 수정하지 않고 기존 배포에 콘텐츠를 오버레이하도록 배포 오버레이를 정의할 수 있습니다.

프로세스

  1. deployment-overlay add management CLI 명령을 사용하여 배포 오버레이를 추가합니다.

    deployment-overlay add --name=new-deployment-overlay --content=WEB-INF/web.xml=/path/to/other/web.xml --deployments=test-application.war --redeploy-affected
    참고

    관리형 도메인에서 --server-groups 를 사용하여 적용 가능한 서버 그룹을 지정하거나 --all-server-groups 를 사용하여 모든 서버 그룹을 지정합니다.

  2. 배포 오버레이를 생성한 후 기존 오버레이에 콘텐츠를 추가하거나 오버레이를 배포에 연결하거나 오버레이를 제거할 수 있습니다.
  3. 선택 사항: 오버레이 구성을 지정하여 < overlay > 요소를 사용하여 HTML, 이미지 또는 동영상과 같은 정적 웹 리소스가 포함된 외부 디렉터리에 연결할 수 있습니다.

    & lt;overlay > 요소는 JAR 오버레이 절차와 유사하게 웹 애플리케이션의 정적 파일을 오버레이하는 정적 파일을 지정합니다. 이 요소는 애플리케이션 파일 jboss-web.xml 에 있습니다. 이 요소 구성을 사용하면 애플리케이션을 다시 패키징할 필요가 없습니다.

    다음 예제에서는 < overlay > 요소의 시스템 속성 대체를 보여줍니다. 여기서 {example.path.to.overlay}/PATH/TO/STATIC/WEB/CONTENT 위치를 정의합니다.

    예: jboss-web.xml 파일의 < overlay > 요소

    <jboss-web xmlns="http://www.jboss.com/xml/ns/javaee"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-web_10_0.xsd"
               version="10.0">
            <overlay>{example.path.to.overlay}</overlay>
    </jboss-web>

    jboss-descriptor-property-replacementtrue 로 설정된 경우 설명자 속성의 기본값인 < overlay > 요소에서 시스템 속성을 지정할 수 있습니다.

    jboss-descriptor-property-replacement 를 구성하려면 다음 관리 CLI 명령을 사용합니다.

    /subsystem=ee:write-attribute(name=jboss-descriptor-property-replacement,value=true)

    이 명령은 JBoss EAP 구성의 ee 하위 시스템에 다음 XML 콘텐츠를 추가합니다.

    <subsystem xmlns="urn:jboss:domain:ee:4.0">
        <jboss-descriptor-property-replacement>true</jboss-descriptor-property-replacement>
    </subsystem>
    참고

    & lt;overlay > 요소는 EAP 프로젝트에 이미 존재하는 배포 파일을 재정의하지 않습니다. 여러 <overlay > 요소에 동일한 파일이 포함된 경우 우선순위 순서는 애플리케이션 jboss-web.xml 파일에서 오버레이 요소의 순서에 따라 결정됩니다.

6.6.4. 롤아웃 계획 사용

관리형 도메인에서 도메인 또는 호스트 수준 리소스를 대상으로 하는 작업은 여러 서버에 영향을 미칠 수 있습니다. 이러한 작업에는 작업이 서버에 적용되는 시퀀스를 자세히 설명하는 롤아웃 계획과 일부 서버에서 성공적으로 실행되지 않으면 작업을 되돌릴 수 있는지 여부를 자세히 설명하는 정책이 포함될 수 있습니다. 롤아웃 계획을 지정하지 않으면 기본 롤아웃 계획이 사용됩니다.

6.6.4.1. 롤아웃 계획의 예

다음은 5개의 서버 그룹을 포함하는 롤아웃 계획의 예입니다. 작업은 서버 그룹에 직렬로, 시리즈 내 또는 동시에 동시 그룹에 적용할 수 있습니다. 자세한 내용은 롤아웃 계획 구문을 참조하십시오.

{"my-rollout-plan" => {"rollout-plan" => {
    "in-series" => [
        {"concurrent-groups" => {
            "group-A" => {
                "max-failure-percentage" => "20",
                "rolling-to-servers" => "true"
            },
            "group-B" => undefined
        }},
        {"server-group" => {"group-C" => {
            "rolling-to-servers" => "false",
            "max-failed-servers" => "1"
        }}},
        {"concurrent-groups" => {
            "group-D" => {
                "max-failure-percentage" => "20",
                "rolling-to-servers" => "true"
            },
            "group-E" => undefined
        }}
    ],
    "rollback-across-groups" => "true"
}}}

위의 예제를 살펴보면 도메인의 서버에 작업을 적용하는 것은 세 단계로 수행됩니다. 서버 그룹에 대한 정책이 서버 그룹 전체에서 작업 롤백을 트리거하는 경우 다른 모든 서버 그룹도 롤백됩니다.

  1. 서버 그룹 group-Agroup-B 는 작업을 동시에 적용합니다. 이 작업은 group-A 의 서버에 직렬로 적용되지만 group-B 의 모든 서버는 동시에 작업을 처리합니다. 그룹 A 에 있는 서버의 20% 이상이 작업을 적용하지 못하면 해당 그룹 전체에서 롤백됩니다. group-B 의 서버가 작업을 적용하지 않으면 해당 그룹에서 롤백됩니다.
  2. group-Agroup-B 의 모든 서버가 완료되면 이 작업이 group-C 의 서버에 적용됩니다. 이러한 서버는 작업을 동시에 처리합니다. group-C 의 서버가 두 개 이상 적용되지 않으면 해당 그룹에서 작업을 롤백합니다.
  3. group-C 의 모든 서버가 완료되면 서버 그룹 group-Dgroup-E 가 작업을 동시에 적용합니다. 이 작업은 group-D 의 서버에 직렬로 적용되지만 group-E 의 모든 서버는 동시에 작업을 처리합니다. group-D 에 있는 서버의 20% 이상이 작업을 적용하지 못하면 해당 그룹 전체에서 롤백됩니다. group-E 의 서버가 작업을 적용하지 못하면 해당 그룹에서 롤백됩니다.

6.6.4.2. 롤아웃 계획 구문

다음 방법 중 하나로 롤아웃 계획을 지정할 수 있습니다.

각 메서드에는 다른 초기 명령이 있지만 두 방법 모두 롤아웃 작업 헤더를 사용하여 롤아웃 계획을 정의합니다. 이 명령은 다음 구문을 사용합니다.

rollout (id=PLAN_NAME | SERVER_GROUP_LIST) [rollback-across-groups]
  • PLAN_NAMErollout-plan 명령을 사용하여 저장된 롤아웃 계획의 이름입니다.
  • SERVER_GROUP_LIST 는 서버 그룹 목록입니다. 쉼표(,)를 사용하여 여러 서버 그룹을 분리하여 각 서버 그룹에서 순차적으로 작업을 수행해야 함을 나타냅니다. 캐럿(^) 구분자를 사용하여 각 서버 그룹에서 동시에 작업을 수행해야 함을 나타냅니다.

    • 각 서버 그룹에 대해 다음 정책 중 하나를 설정합니다. 쉼표를 사용하여 여러 정책을 구분합니다.

      • rolling-to-servers: true 로 설정된 경우 그룹의 각 서버에 작업을 적용하는 부울입니다. 값이 false 이거나 지정하지 않으면 작업이 그룹의 서버에 동시에 적용됩니다.
      • max-failed-servers: 그룹의 모든 서버에서 작업을 되돌리기 전에 작업을 적용하지 못할 수 있는 최대 서버 수를 사용하는 정수입니다. 지정하지 않는 경우 기본값은 0 입니다. 즉, 서버의 실패가 그룹 전체에서 롤백을 트리거합니다.
      • max-failure-percentage: 그룹의 모든 서버에서 되돌리기 전에 작업을 적용하지 못할 수 있는 그룹의 총 서버 수의 최대 백분율을 나타내는 0 에서 100 사이의 정수입니다. 지정하지 않는 경우 기본값은 0 입니다. 즉, 서버의 실패가 그룹 전체에서 롤백을 트리거합니다.

        참고

        max-failed-serversmax-failure-percentage 가 0이 아닌 값으로 설정된 경우 max-failure-percentage 가 우선합니다.

  • rollback-across-groups: 한 서버 그룹의 모든 서버에서 작업을 롤백해야 하는지 여부를 나타내는 부울입니다. 기본값은 false 입니다.

6.6.4.3. 롤아웃 계획을 사용하여 애플리케이션 배포

롤아웃 계획의 전체 세부 정보를 헤더 인수에 전달하여 배포 명령에 직접 제공할 수 있습니다. 형식에 대한 자세한 내용은 롤아웃 계획 구문 을 참조하십시오.

다음 관리 CLI 명령은 직렬 배포에 대해 rolling-to-servers=true 를 지정하는 배포 계획을 사용하여 애플리케이션을 main-server-group 서버 그룹에 배포합니다.

deploy /path/to/test-application.war --server-groups=main-server-group --headers={rollout main-server-group(rolling-to-servers=true)}

6.6.4.4. 저장된 롤아웃 계획을 사용하여 애플리케이션 배포

롤아웃 계획이 복잡할 수 있으므로 롤아웃 계획의 세부 정보를 저장할 수 있습니다. 이를 통해 매번 롤아웃 계획의 전체 세부 정보가 필요하지 않고 롤아웃 계획 이름을 사용할 때 참조할 수 있습니다.

프로세스

  1. rollout-plan 관리 CLI 명령을 사용하여 롤아웃 계획을 저장합니다. 형식에 대한 자세한 내용은 롤아웃 계획 구문 을 참조하십시오.

    rollout-plan add --name=my-rollout-plan --content={rollout main-server-group(rolling-to-servers=false,max-failed-servers=1),other-server-group(rolling-to-servers=true,max-failure-percentage=20) rollback-across-groups=true}

    이렇게 하면 다음 배포 계획이 생성됩니다.

    "rollout-plan" => {
        "in-series" => [
            {"server-group" => {"main-server-group" => {
                "rolling-to-servers" => false,
                "max-failed-servers" => 1
            }}},
            {"server-group" => {"other-server-group" => {
                "rolling-to-servers" => true,
                "max-failure-percentage" => 20
            }}}
        ],
        "rollback-across-groups" => true
    }
  2. 애플리케이션을 배포할 때 저장된 롤아웃 계획 이름을 지정합니다.

    다음 관리 CLI 명령은 my-rollout-plan 저장된 롤아웃 계획을 사용하여 모든 서버 그룹에 애플리케이션을 배포합니다.

    deploy /path/to/test-application.war --all-server-groups --headers={rollout id=my-rollout-plan}

6.6.4.5. 저장된 롤아웃 계획 제거

제거할 롤아웃 계획의 이름을 지정하여 rollout-plan 관리 CLI 명령을 사용하여 저장된 롤아웃 계획을 제거할 수 있습니다.

rollout-plan remove --name=my-rollout-plan

6.6.4.6. 기본 롤아웃 계획

여러 서버에 영향을 미치는 모든 작업은 롤아웃 계획을 사용하여 실행됩니다. 작업 요청에 롤아웃 계획을 지정하지 않으면 기본 롤아웃 계획이 생성됩니다. 계획에는 다음과 같은 특징이 있습니다.

  • 하나의 고급 단계만 있을 것입니다. 작업의 영향을 받는 모든 서버 그룹에는 작업이 동시에 적용됩니다.
  • 각 서버 그룹 내에서 작업은 모든 서버에 동시에 적용됩니다.
  • 서버 그룹의 모든 서버에서 실패하면 그룹 전체에서 롤백이 발생합니다.
  • 서버 그룹이 실패하면 다른 모든 서버 그룹이 롤백됩니다.
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2026 Red Hat
맨 위로 이동