7.6. 배포 동작 사용자 정의

배포된 콘텐츠를 저장할 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 인스턴스 간에 고유해야 합니다.

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

기본적으로 관리형 도메인에 배포된 콘텐츠는 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 인스턴스 간에 고유해야 합니다.

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

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

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

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

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

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

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

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

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

생성된 후에는 기존 오버레이에 콘텐츠를 추가하거나 오버레이를 배포에 연결하거나 오버레이를 제거할 수 있습니다. 전체 사용량 세부 정보를 보려면 deployment-overlay --help 를 실행합니다.

롤아웃 계획 정보

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

다음은 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"
}}}

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

롤아웃 계획 구문

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

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

rollout (id=PLAN_NAME | SERVER_GROUP_LIST) [rollback-across-groups]

롤아웃 계획을 사용하여 배포

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

다음 관리 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)}

저장된 롤아웃 계획을 사용하여 배포

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

저장된 롤아웃 계획 제거

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

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

기본 롤아웃 계획

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