Patch Manual

1. GUI Patch

본 챕터는 일반적으로 진행되는 GUI 패치에 대해서 기술한다.

기본적으로 Linux 환경을 기반으로 설명하며, Windows 환경의 경우 아래와 같은 차이점이 존재한다.

패치 파일 확장자 변경 : .tar.gz → .zip, .sh → .bat
patch_assist의 파라미터로 입력되는 경로에 공백이 존재한다면 쌍따옴표 처리 필요
Manager와 node의 패치 이후 재기동이 안 되었다면 수동 기동 필요

1.1. 패치 준비

기본적으로 패치 파일은 Manager & Agent 패치를 위한 LENA패치 파일과 Engine 패치를 위한 파일들이 존재한다.

1.1.1. 패치 파일

Table 1. 패치 파일
구분	파일명	설명
Manager & Agent	LENA-1.3.4.4-EN9.tar.gz	LENA Manager와 Agent에 관한 패치 파일로 서비스 운영과 관계없는 영역의 패치이다.
Engine-WAS	EN9-1.3.4.4.tar.gz	lena-se, lena-ee 서버에 대한 패치 파일이다.
Engine-Session Server	ENZ-EN9-1.3.4.4.tar.gz	lena-session 서버에 대한 패치 파일이다.
Engine-Web Server	ENA-1.3.4.4.tar.gz, ENN-1.3.4.4.tar.gz	web 서버 중 EN-A와 EN-N 엔진에 대한 패치 파일이다.

파일명에 표기된 "1.3.4.4"와 "EN9" 의 경우 고정된 값이 아닌 패치할 버전에 따라 변동되는 값이므로 혼동하지 않도록 한다.

1.1.2. 스크립트 파일

[주의] 현재 설치된 버전이 1.3.4.4 이상이라면, [스크립트 파일]은 필요하지 않다.

1.3.4.4 버전부터 Manager 및 Agent 구조가 대폭 변경됨에 따라, 기존 GUI를 통한 패치가 지원되지 않는다.
따라서 설치된 버전이 1.3.4.4 보다 작다면, 반드시 patch_assist.sh 파일을 이용하여 Manager & Agent 패치 진행이 필요하다. (나머지 프로세스는 GUI로 진행 가능)

patch_assist.sh 사용법

  patch_assist.sh <deploy|apply> <manager|node> <filePath> <basePath>

Table 2. patch_assist.sh 파라미터 설명
파라미터	설명
[deploy] [apply]	deploy는 <filePath>의 파일을 <basePath> 하위의 특정 경로로 배포한다. apply는 배포한 파일을 이용하여 패치를 적용한다.
[manager] [node] [manager,node]	manager는 manager에 대해서 배포 또는 패치할때 입력한다. node는 node(Agent)에 대해서 배포 또는 패치할때 입력한다. [주의] manager,node는 standard 또는 enterprise 환경에서 node없이 manager만 단독으로 설치된 특수한 경우를 위한 파라미터이다. 해당 케이스에서 deploy 할때에는 [manager]로 입력하고, apply할때 [manager,node]로 입력하면 된다. 일반적인 경우 해당 파라미터는 사용되지 않는다.
[filePath]	패치 파일의 경로를 절대경로로 입력한다. 절대경로로 입력되기에 사용자가 원하는 임의의 경로에 패치 파일을 위치시켜도 무방하다.
[basePath]	lenaHome 경로를 절대경로로 입력한다.

1.2. 예시 환경

패치수행에서 기술될 예시에 관련한 환경에 대한 정보이다. 각자의 사용자 환경에 맞게 적절히 비교하여 참조 해야 한다.

Enterprise 설치환경

manager
node(Agent)
- se : test7001
- ee : test7002
- session : test5001

Web 설치환경

node(Agent)
- web(EN-A) : test6001

1.3. 패치수행

1.3.1. 스크립트 패치 수행

[주의] 현재 설치된 버전이 1.3.4.4 이상이라면, [스크립트 패치 수행]은 필요하지 않다. 하단의 [GUI 패치 수행]부터 진행하면 된다.

기본 수행

현재 설치된 버전이 1.3.4.4 보다 작다면 Manager & Agent에 대해서 패치할 때 스크립트로 패치가 필요하다.

배포

./patch_assist.sh deploy manager /engn001/patch/LENA-1.3.4.4-EN9.tar.gz /engn001/lena/1.3.4.3
./patch_assist.sh deploy node /engn001/patch/LENA-1.3.4.4-EN9.tar.gz /engn001/lena/1.3.4.3
./patch_assist.sh deploy node /engn001/patch/LENA-1.3.4.4-EN9.tar.gz /engn001/lenaw/1.3.4.3

패치

./patch_assist.sh apply manager /engn001/patch/LENA-1.3.4.4-EN9.tar.gz /engn001/lena/1.3.4.3
./patch_assist.sh apply node /engn001/patch/LENA-1.3.4.4-EN9.tar.gz /engn001/lena/1.3.4.3
./patch_assist.sh apply node /engn001/patch/LENA-1.3.4.4-EN9.tar.gz /engn001/lenaw/1.3.4.3

같은 경로의 manager와 node일 경우, 반드시 manager를 먼저 apply 해주어야 한다. (node를 먼저 apply 시 관련 오류메시지가 출력되며, 패치가 종료된다. 해당 상황이 발생하면 순서를 조정하여 다시 진행하면 된다.)

패치 이후 Manager와 node가 재기동이 안되었다면 수동 기동이 필요할 수 있다.

기본 수행 이후 점검

매니저가 정상적으로 기동되었다면 반드시 브라우저의 캐시 비우기 및 강력 새로고침을 통해서 캐시 삭제 필요하다.

성공 Case

기본 수행이 정상적으로 완료되었다면, 매니저 접속시 다음과 같은 화면을 확인할 수 있다.

Table 3. Manager & Agent 화면의 Status 값의 의미
- 상태	설명
	패치파일이 정상적으로 업로드 되어, 패치할 준비가 되었다. (upload 이후)
	패치파일이 정상적으로 업로드 되었고, 패치가 정상적으로 적용되었다. (patch 이후)
	업로드된 패치파일이 존재하지 않는 상태 (commit 이후 또는 최초 설치 상태)

히스토리 버튼을 눌러 패치기록을 확인 할 수 있다.

Figure 1. 히스토리 조회

Figure 2. 붉은색 히스토리 버튼

History 아이콘이 붉은색이라면, handwork 대상이 존재한다는 뜻이다. 해당 파일을 수동으로 비교하여 수정(merge, 병합)해주는 작업이 필요하다. 수정해주지 않을 시 정상적으로 작동하지 않을 수 있으므로 주의가 필요하다.
HANDWORK 작업은 인스턴스가 종료된 상태에서 진행하는것을 권장한다.

Manager와 모든 Agent의 패치가 완료된것이 확인되고 handwork 확인이 끝났다면 , GUI 패치 수행을 이어서 진행하면 된다.

기본 수행과 브라우저의 캐시 비우기 및 강력 새로고침을 모두 하였음에도 불구하고, 다음과 같은 화면이 확인된다면 아래 사항에 대해 확인이 필요하다. (Manager 와 관련된 Hotfix를 진행한 환경에서는 매니저 기동에 필요한 핵심 war파일인 lena.war가 HANDWORK상태로 검출되어 해당 증상이 발생할 수 있다. 우선적으로 lena.war파일을 처리하여 매니저를 정상기동하여 성공Case 점검에 대해 확인이 필요하다.)

{LENA_HOME}/bin/stop-manager.sh를 통해 manager 기동 중지
{LENA_HOME}/logs/lena-patcher/{date}/patch-yyyyMMddHHmmssSSS.log 파일확인
log 파일들 중 최하단에 "** Patch completed to Manager" 가 존재하는 로그파일이 대상파일
해당 로그파일에서 아래와 같은 형식의 항목 확인 ([HANDWORK] 이면서 target이 modules/lena-manager/webapps 하위의 lena.war이며 source가 repository/patch/…/depot/lena-manager/module/webapps 하위의 lena.war인 케이스)

[HANDWORK]Patching files to '/engn001/lena/1.3.4.3/modules/lena-manager/webapps/lena.war' (source : '/engn001/lena/1.3.4.3/repository/patch/LENA-1.3.4.4/depot/lena-manager/1.3.4.4/module/webapps/lena.war')

lena.war 파일 copy & paste

cp /engn001/lena/1.3.4.3/repository/patch/LENA-1.3.4.4/depot/lena-manager/1.3.4.4/module/webapps/lena.war /engn001/lena/1.3.4.3/modules/lena-manager/webapps/lena.war

{LENA_HOME}/bin/start-manager.sh를 통해 manager 기동 시작
상단의 성공 Case 점검 진행

1.3.2. GUI 패치 수행

Manager & Agent

관리모듈에 대해서 패치하는 과정이다.

Table 4. Manager & Agent 화면의 Status 값의 의미
- 상태	설명
	패치파일이 정상적으로 업로드 되어, 패치할 준비가 되었다. (upload 이후)
	패치파일이 정상적으로 업로드 되었고, 패치가 정상적으로 적용되었다. (patch 이후)
	업로드된 패치파일이 존재하지 않는 상태 (commit 이후 또는 최초 설치 상태)

Upload

1.3.4.5 버전부터 지원하는 내용으로, 현재 패치 가이드에서는 해당 과정을 기술하지 않도록 한다.

Patch

1.3.4.5 버전부터 지원하는 내용으로, 현재 패치 가이드에서는 해당 과정을 기술하지 않도록 한다.

Rollback

1.3.4.5 버전부터 지원하는 내용으로, 현재 패치 가이드에서는 해당 과정을 기술하지 않도록 한다.

스크립트 패치수행 이전버전으로 돌아가기 위해서는 커맨드로만 수행가능하며 아래 방식을 통해 롤백 가능하다. patchId값은 {LENA_HOME}/etc/info/patch-history.xml 파일을 확인하여 조회 가능하다. 반드시 모든 대상 node를 먼저 롤백하고 마지막으로 manager를 롤백해야 한다. (manager를 먼저 롤백 시 관련 오류메시지가 출력되며, 롤백이 종료된다. 해당 상황이 발생하면 순서를 조정하여 다시 진행하면 된다.)

({LENA_HOME}/etc/patch/{PATCH_FILE}/etc/patch/bin/history.sh 을 통해서도 history 정보를 조회 할 수 있다.)

{LENA_HOME}/etc/patch/{PATCH_VERSION}/etc/patch/bin/restore.sh {PATCH_ID}

Commit

Patch가 정상적으로 완료되고, [HANDWORK] 추출 대상에 대해 확인 및 수정이 완료되었다면 Commit을 진행해도 된다. Commit이 된다면 이전 버전으로 Rollback 할 수 없으니 주의가 필요하다.

Manager & Agent의 경우, Commit이 완료되면 업로드한 패치파일이 삭제된다.

Figure 3. Manager & Agent Commit이 정상적으로 완료되었을때 메인화면 조회

WAS

관리모듈이 아닌 se나 ee 인스턴스 엔진을 패치하는 과정이다.

Table 5. WAS 화면의 Node Patch Status 값의 의미
- 상태	설명
	적절한 패치파일이 업로드 되지 않았다. (최초 설치 상태)
	적절한 패치파일이 정상적으로 업로드 되어, 패치할 준비가 되었다. (upload 이후)
	패치가 정상적으로 적용되었다. (patch 이후)
	적절한 패치파일이 정상적으로 업로드 되었고, commit이 정상적으로 적용되었다. (commit 이후)

Upload

EN9-1.3.4.4.tar.gz 파일을 업로드한다.

Patch

업로드가 정상적으로 완료되었다면 모든 서버들을 종료하고, 패치를 진행한다.

Figure 4. WAS 패치가 정상적으로 완료되었을때 메인화면 조회

히스토리 버튼을 눌러 패치기록을 확인 할 수 있다.

Figure 5. 히스토리 조회

Figure 6. 붉은색 히스토리 버튼

History 아이콘이 붉은색이라면, handwork 대상이 존재한다는 뜻이다. 해당 파일을 수동으로 비교하여 수정(merge, 병합)해주는 작업이 필요하다. 수정해주지 않을 시 정상적으로 작동하지 않을 수 있으므로 주의가 필요하다.
HANDWORK 작업은 인스턴스가 종료된 상태에서 진행하는것을 권장한다.

Rollback

패치 이후 롤백이 필요하다고 판단된다면 모든 서버들을 종료하고, 롤백을 진행한다.

Figure 7. WAS 롤백이 정상적으로 완료되었을때 메인화면 조회

Commit

Figure 8. WAS 커밋이 정상적으로 완료되었을때 메인화면 조회

Session Server

관리모듈이 아닌 session 인스턴스 엔진을 패치하는 과정이다.

Table 6. Session Server 화면의 Node Patch Status 값의 의미
- 상태	설명
	적절한 패치파일이 업로드 되지 않았다. (최초 설치 상태)
	적절한 패치파일이 정상적으로 업로드 되어, 패치할 준비가 되었다. (upload 이후)
	패치가 정상적으로 적용되었다. (patch 이후)
	적절한 패치파일이 정상적으로 업로드 되었고, commit이 정상적으로 적용되었다. (commit 이후)

Upload

ENZ-EN9-1.3.4.4.tar.gz 파일을 업로드합니다.

Patch

업로드가 정상적으로 완료되었다면 모든 서버들을 종료하고, 패치를 진행한다.

Figure 9. Session Server 패치가 정상적으로 완료되었을때 메인화면 조회

히스토리 버튼을 눌러 패치기록을 확인 할 수 있다.

Figure 10. 히스토리 조회

Figure 11. 붉은색 히스토리 버튼

History 아이콘이 붉은색이라면, handwork 대상이 존재한다는 뜻이다. 해당 파일을 수동으로 비교하여 수정(merge, 병합)해주는 작업이 필요하다. 수정해주지 않을 시 정상적으로 작동하지 않을 수 있으므로 주의가 필요하다.
HANDWORK 작업은 인스턴스가 종료된 상태에서 진행하는것을 권장한다.

Rollback

패치 이후 롤백이 필요하다고 판단된다면 모든 서버들을 종료하고, 롤백을 진행한다.

Figure 12. Session Server 롤백이 정상적으로 완료되었을때 메인화면 조회

Commit

Figure 13. Session Server 커밋이 정상적으로 완료되었을때 메인화면 조회

Web Server

관리모듈이 아닌 web 인스턴스 엔진을 패치하는 과정이다.

Table 7. Web Server 화면의 Node Patch Status 값의 의미
- 상태	설명
	적절한 패치파일이 업로드 되지 않았다. (최초 설치 상태)
	적절한 패치파일이 정상적으로 업로드 되어, 패치할 준비가 되었다. (upload 이후)
	패치가 정상적으로 적용되었다. (patch 이후)
	적절한 패치파일이 정상적으로 업로드 되었고, commit이 정상적으로 적용되었다. (commit 이후)

Upload

ENA-1.3.4.4.tar.gz 파일을 업로드합니다.

Patch

업로드가 정상적으로 완료되었다면 모든 서버들을 종료하고, 패치를 진행한다.

Figure 14. Web Server 패치가 정상적으로 완료되었을때 메인화면 조회

히스토리 버튼을 눌러 패치기록을 확인 할 수 있다.

Figure 15. 히스토리 조회

Figure 16. 붉은색 히스토리 버튼

History 아이콘이 붉은색이라면, handwork 대상이 존재한다는 뜻이다. 해당 파일을 수동으로 비교하여 수정(merge, 병합)해주는 작업이 필요하다. 수정해주지 않을 시 정상적으로 작동하지 않을 수 있으므로 주의가 필요하다.
HANDWORK 작업은 인스턴스가 종료된 상태에서 진행하는것을 권장한다.

Rollback

패치 이후 롤백이 필요하다고 판단된다면 모든 서버들을 종료하고, 롤백을 진행한다.

Figure 17. Web Server 롤백이 정상적으로 완료되었을때 메인화면 조회

Commit

Figure 18. Web Server 커밋이 정상적으로 완료되었을때 메인화면 조회

1.4. FAQ (Trouble Shooting)

1.4.1. 스크립트 파일과 패치파일은 어디에 위치해야하는가?

Q.스크립트 파일과 패치파일은 어디에 위치해야하는가?
A.{LENA_HOME}과 같은 서버에만 위치한다면, 파라미터를 절대경로로 입력받기 때문에 어디에 위치하든 관계없다.

1.4.2. 브라우저의 강력 새로고침을 해도 매니저 화면이 깨지거나 이상할때

Q.브라우저의 강력 새로고침을 해도 매니저 화면이 깨지거나 이상할때
A.lena.war파일이 HANDWORK로 상태로 패치되었는지 확인이 필요하다.
자세한 내용은 [스크립트 패치수행]의 [실패 Case] 챕터를 참조한다.

1.4.3. Web Server는 어떤 패치 파일로 진행하는가?

Q.Web Server가 깔려있는 Agent는 어떤 패치파일로 패치하는가?
A.WAS가 깔려있는 Agent와 동일하게 LENA-{VERSION}.tar.gz 파일을 이용해서 Manager & Agent 패치를 진행하면 된다.
이후 ENA-{VERSION}.tar.gz 또는 ENN-{VERSION}.tar.gz 파일을 이용하여, 엔진패치를 진행할 수 있다.

1.4.4. Manager & Agent 패치와 엔진패치의 차이점

Q.Manager & Agent 패치와 엔진패치의 차이점
A.Manager & Agent 패치는 서비스와 직접적으로 관계가 없는 관리 모듈(매니저)에 대한 패치이고, 엔진패치는 WAS,Session Server,Web Server 같은
서비스와 직접적으로 관계 된 인스턴스에 대한 패치입니다.

1.4.5. HANDWORK는 언제 발생하는가?

Q.HANDWORK는 언제 발생하는가?
A.인스턴스를 Install 할때 참조하는 Depot 영역과 실제 인스턴스 영역의 내용이 다르면서,
Patch 파일의 Depot 영역이 다를 때 발생한다.
이는 HANDWORK로 발생 된 영역을 시스템상에서 자동으로 Patch 파일로 수정할 경우, Custom하게 수정된 영역까지 덮어쓰여질 수 있기 때문에 사용자에게 판단을 넘기는 절차이다.
따라서 해당 상태에 대해서 무시하지 않고 확인하는 절차가 반드시 필요하다.

1.4.6. 화면에서 WAS/Session Server 패치파일을 업로드했는데 패치 진행이 안될 때

Q.화면에서 WAS/Session Server 패치파일을 업로드했는데 패치 진행이 안될 때
A.해당 Node가 ENGINE_PATCHING 상태인지 확인이 필요하다. WAS와 Session Server는 같은 Node일 수 있기 때문에 한쪽이 패치 진행 중이라면 동시에 진행할 수 없다.
따라서 해당 화면에서 패치를 진행한적이 없는데 ENGINE_PATCHING 상태라면, 해당 Node에서 진행했던 패치가 Commit 되었는지 확인이 필요하다.

1.4.7. Manager & Agent 만 패치 해도 되나요?

Q.Manager & Agent 만 패치 해도 되나요?
A.현재 버전에서는 Manager & Agent 패치와 엔진패치의 분리가 완전히 이루어지지 않았으므로 반드시 전부 같은 버전으로 패치를 수행해야 한다.
추후 버전에서, 독립적으로 엔진패치가 가능하도록 수정 될 예정이다.

1.4.8. Commit하면 어떻게 되나요?

Q.Commit하면 어떻게 되나요?
A.롤백을 위해 저장해둔 백업데이터가 삭제되고, 더이상 과거버전으로 롤백 할 수 없게 됩니다. 따라서 충분한 테스트 과정을 거친 후 Commit을 진행해야 합니다.
Manager & Agent의 Commit은 업로드한 패치파일이 삭제되며, 엔진패치의 Commit은 다른 Node에서도 업로드한 패치파일을 사용할 수 있기때문에 업로드한 패치파일이 삭제되지 않습니다.

1.4.9. 1.3.1.x, 1.3.2.x, 1.3.3.x 패치파일도 gui로 진행할 수 있나요?

Q.1.3.1.x, 1.3.2.x, 1.3.3.x 패치파일도 gui로 진행할 수 있나요?
A.1.3.1.x, 1.3.2.x, 1.3.3.x 패치파일은 더이상 GUI 패치가 지원되지 않습니다. 다음 챕터의 CLI패치를 참조하여 진행이 필요합니다.

2. CLI Patch

본 챕터는 고급 사용자용으로 CLI 패치에 대해서 기술한다.
CLI 패치는 버전의 제약없이 패치를 제공한다.
모든 패치과정을 커맨드로 입력할 수 있지만 커맨드 입력순서 혹은 파라미터 입력순서, 로그 확인 등이 까다로울 수 있으니 주의가 필요하다.

기본적으로 Linux 환경을 기반으로 설명하며, Windows 환경의 경우 아래와 같은 차이점이 존재한다.

패치파일 확장자 변경 : .tar.gz → .zip, .sh → .bat
patch_assist의 파라미터로 입력되는 경로에 공백이 존재한다면 쌍따옴표 처리 필요
Manager 와 node의 패치 이후 재기동이 안되었다면 수동 기동 필요

2.1. 패치 준비

기본적으로 패치파일은 Manager & Agent 패치를 위한 LENA패치파일과 Engine 패치를 위한 파일들이 존재 한다.

2.1.1. 패치 파일

Table 8. 패치 파일
구분	파일명	설명
Manager & Agent	LENA-1.3.4.4-EN9.tar.gz	LENA Manager와 Agent에 관한 패치파일로 서비스 운영과 관계없는 영역의 패치이다.
Engine-WAS	EN9-1.3.4.4.tar.gz	lena-se, lena-ee 서버에 대한 패치파일이다.
Engine-Session Server	ENZ-EN9-1.3.4.4.tar.gz	lena-session 서버에 대한 패치파일이다.
Engine-Web Server	ENA-1.3.4.4.tar.gz, ENN-1.3.4.4.tar.gz	web 서버 중 EN-A와 EN-N 엔진에 대한 패치파일이다.

파일명에 표기된 "1.3.4.4"와 "EN9" 의 경우 고정된 값이 아닌 패치할 버전에 따라 변동되는 값이므로 혼동하지 않도록 한다.

2.1.2. 스크립트 파일

배포를 위한 patch_assist.sh파일과 적용을 위한 patch_command.sh 파일이 필요 하다.

patch_assist.sh 사용법

  patch_assist.sh <deploy|apply> <manager|node> <filePath> <basePath>

Table 9. patch_assist.sh 파라미터 설명
파라미터	설명
[deploy] [apply]	deploy는 <filePath>의 파일을 <basePath> 하위의 특정경로로 배포한다. apply는 배포한 파일을 이용하여 패치를 적용한다.
[manager] [node] [manager,node]	manager는 manager에 대해서 배포 또는 패치할때 입력한다. node는 node(Agent)에 대해서 배포 또는 패치할때 입력한다. [주의] manager,node는 standard 또는 enterprise 환경에서 node없이 manager만 단독으로 설치된 특수한 경우를 위한 파라미터이다. 해당 케이스에서 deploy 할때에는 [manager]로 입력하고, apply할때 [manager,node]로 입력하면 된다. 일반적인 경우 해당 파라미터는 사용되지 않는다.
[filePath]	패치파일의 경로를 절대경로로 입력한다. 절대경로로 입력되기에 사용자가 원하는 임의의 경로에 패치파일을 위치시켜도 무방하다.
[basePath]	lenaHome 경로를 절대경로로 입력한다.

patch_command.sh 사용법

Usage:
  patch_command.sh <patchFileName> <lenaHomePath> <command> <attr>

Args:
  patchFileName  : Must end with .tar.gz (name validation)
  lenaHomePath   : Must be an absolute path, and must exist
  command        : patch | restore | commit
  attr           : Comma-separated items. Items may contain spaces ONLY when command=patch.
                   Example: 'lena-manager,lena-node'
                          : 'lena-was,lena-se test8001,lena-ee test8002'
                          : 'lena-se test8001,lena-ee test8002,lena-session,lena-session test6001'
                          : 'lena-web,lena-web test7001'
                          : 'lena-wbn,lena-wbn test7002'

Table 10. patch_command.sh 파라미터 설명
파라미터	설명
[patchFileName]	patchFileName은 LENA-1.3.4.4-EN9.tar.gz 와 같이 경로없이 패치파일명만 적어주면 된다. 이는 patch_assist.sh를 통해서 이미 배포되었기때문에 경로정보가 필요없기 때문이다.
[lenaHomePath]	입력하는 [attr]의 경로에 적절한 {LENA_HOME}경로를 절대경로로 입력한다.
[command]	patch, restore, commit이며 restore는 화면에서 rollback과 동일한 의미이다.
[attr]	입력하는 patchFileName과 적절하게 매칭하여 입력해야한다. 아래 표에서 보다 자세하게 기술한다. [patch] command의 경우 attr을 따옴표로 묶어 다건 처리가 가능합니다. 쉼표를 구분자로 반복하여 command를 호출한다.

Table 11. patch_command.sh 의 attr 구체적 사용법
패치파일	command	허용 attr	주의사항
LENA-1.3.4.4-EN9	patch	[lena-manager] [lena-node]	manager를 반드시 먼저 패치해야한다.
	restore	[{patchId}]	{LENA_HOME}/etc/info/patch-history.xml을 참고하여 patchId를 확인 할 수 있으며 패치한 순서에 역순으로 진행해야 한다.
	commit	[lena-node] [lena-manager]	manager를 반드시 마지막에 패치해야한다.
EN9-1.3.4.4	patch	[lena-was] [lena-se {serverId}] [lena-ee {serverId}]	lena-was를 반드시 먼저 패치해야한다.
	restore	[{patchId}]	{LENA_HOME}/etc/info/patch-history.xml을 참고하여 patchId를 확인 할 수 있으며 패치한 순서에 역순으로 진행해야 한다.
	commit	[lena-was]
ENZ-EN9-1.3.4.4	patch	[lena-se {serverId}] [lena-ee {serverId}] [lena-session] [lena-session {serverId}]	해당 session이 설치되어있는 node의 모든 se,ee인스턴스를 반드시 먼저 입력해야한다. 이후 lena-session을 수행하고 마지막으로 session 서버에 대해 패치해야한다.
	restore	[{patchId}]	{LENA_HOME}/etc/info/patch-history.xml을 참고하여 patchId를 확인 할 수 있으며 패치한 순서에 역순으로 진행해야한다.
	commit	[lena-session]
ENA-1.3.4.4	patch	[lena-web] [lena-web {serverId}]	lena-web를 반드시 먼저 패치해야한다.
	restore	[{patchId}]	{LENA_HOME}/etc/info/patch-history.xml을 참고하여 patchId를 확인 할 수 있으며 패치한 순서에 역순으로 진행해야한다.
	commit	[lena-web]
ENN-1.3.4.4	patch	[lena-wbn] [lena-wbn {serverId}]	lena-wbn을 반드시 먼저 패치해야한다.
	restore	[{patchId}]	{LENA_HOME}/etc/info/patch-history.xml을 참고하여 patchId를 확인 할 수 있으며 패치한 순서에 역순으로 진행해야한다.
	commit	[lena-wbn]

작업 편의상 모든 패치파일을 각 패치 대상에 patch_assist를 통해서 deploy 후 진행하는것을 권장함.

patch_assist.sh의 apply는 patch_command.sh의 manager,node에 대한 patch와 동일한 기능을 한다. 본 CLI 가이드 문서에서는 사용방식의 통일성을 위해 patch_assist.sh는 배포를 위한 deploy만 사용하고 patch_command.sh를 이용하여 patch/restore/commit을 진행한다.

2.2. 예시 환경

CLI_COMMAND 수행에서 기술될 예시에 관련한 환경에 대한 정보이다. 각자의 사용자 환경에 맞게 적절히 비교하여 참조 해야 한다.

Enterprise 설치환경

manager
node(Agent)
- se : test7001
- ee : test7002
- session : test5001

Web 설치환경

node(Agent)
- web(EN-A) : test6001

2.3. CLI_COMMAND 수행

모든 커맨드 작업은 manager, node, 인스턴스를 종료한 뒤 작업하는것을 권장한다.

2.3.1. 공통

Rollback (Restore)

패치 이후 이전 버전으로 돌아가기 위해서는 restore 명령어를 수행해야합니다. 이때 restore순서는 패치한 순서의 역순으로 진행 해야한다.

./patch_command.sh {PATCH_FILE_NAME} /engn001/lena/1.3.4.3 restore '{PATCH_ID}'

patchId값은 {LENA_HOME}/etc/info/patch-history.xml 파일을 확인하여 조회가능하다. ({LENA_HOME}/etc/patch/{PATCH_FILE}/etc/patch/bin/history.sh 을 통해서도 history 정보를 조회 할 수 있다.)

2.3.2. Manager & Agent

배포

./patch_assist.sh deploy manager /engn001/patch/LENA-1.3.4.4-EN9.tar.gz /engn001/lena/1.3.4.3
./patch_assist.sh deploy node /engn001/patch/LENA-1.3.4.4-EN9.tar.gz /engn001/lena/1.3.4.3
./patch_assist.sh deploy node /engn001/patch/LENA-1.3.4.4-EN9.tar.gz /engn001/lenaw/1.3.4.3

Patch

./patch_command.sh LENA-1.3.4.4-EN9.tar.gz /engn001/lena/1.3.4.3 patch 'lena-manager,lena-node'
./patch_command.sh LENA-1.3.4.4-EN9.tar.gz /engn001/lenaw/1.3.4.3 patch 'lena-node'

/engn001/lena/1.3.4.3은 노드와 매니저가 같은 경로이므로 lena-manager를 먼저 수행했다.

각 패치가 완료 된 이후 log를 확인하여 HANDWORK를 진행해야한다.

{LENA_HOME}/logs/lena-patcher/{date}/patch-yyyyMMddHHmmssSSS.log 파일확인
아래와 같은 엔트리 추출

[HANDWORK]Patching files to .....

추출된 모든 엔트리의 경로를 기반으로 파일 비교처리하여 HANDWORK작업(수정작업) 진행
- HANDWORK 작업은 문서파일은 merge(병합)작업, .war 또는 .jar파일의 경우 copy 처리를 권장한다.
- HANDWORK 작업의 target이 modules/lena-manager/webapps 하위의 lena.war이라면 반드시 lena-manager가 중지되었는지 확인하고 copy처리하도록합니다. (lena.war뿐만 아니라 다른 HANDWORK 작업에서도 모든 인스턴스(manager와 node 포함)들이 중지된 상태에서 작업하는것을 권장한다.)

패치가 완료된 뒤 매니저 기동시 반드시 브라우저의 캐시 비우기 및 강력 새로고침을 통해서 캐시 삭제 필요 하다.
패치 이후 Manager와 node가 재기동이 안되었다면 수동 기동이 필요할 수 있다.

Commit

Patch가 정상적으로 완료되고, [HANDWORK] 추출 대상에 대해 확인 및 수정이 완료되었다면 Commit을 진행해도 됩니다. Commit이 된다면 이전 버전으로 Rollback 할 수 없으니 주의가 필요하다.

./patch_command.sh LENA-1.3.4.4-EN9.tar.gz /engn001/lenaw/1.3.4.3 commit 'lena-node'
./patch_command.sh LENA-1.3.4.4-EN9.tar.gz /engn001/lena/1.3.4.3 commit 'lena-node,lena-manager'

/engn001/lena/1.3.4.3은 노드와 매니저가 같은 경로이므로 lena-node를 먼저 수행했다.

2.3.3. WAS

배포

./patch_assist.sh deploy node /engn001/patch/EN9-1.3.4.4.tar.gz /engn001/lena/1.3.4.3

Patch

./patch_command.sh EN9-1.3.4.4.tar.gz /engn001/lena/1.3.4.3 patch 'lena-was,lena-se test7001,lena-ee test7002'

Node Engine인 lena-was를 먼저 패치하고 이후 각 인스턴스들을 패치했다.

각 패치가 완료 된 이후 log를 확인하여 HANDWORK를 진행해야한다.

{LENA_HOME}/logs/lena-patcher/{date}/patch-yyyyMMddHHmmssSSS.log 파일확인
아래와 같은 엔트리 추출

[HANDWORK]Patching files to .....

추출된 모든 엔트리의 경로를 기반으로 파일 비교처리하여 HANDWORK작업(수정작업) 진행
- HANDWORK 작업은 인스턴스가 종료된 상태에서 진행하는것을 권장한다.
- HANDWORK 작업은 문서파일은 merge(병합)작업, .war 또는 .jar파일의 경우 copy 처리를 권장한다.

Commit

./patch_command.sh EN9-1.3.4.4.tar.gz /engn001/lena/1.3.4.3 commit 'lena-was'

2.3.4. Session Server

배포

./patch_assist.sh deploy node /engn001/patch/ENZ-EN9-1.3.4.4.tar.gz /engn001/lena/1.3.4.3

Patch

./patch_command.sh ENZ-EN9-1.3.4.4.tar.gz /engn001/lena/1.3.4.3 patch 'lena-se test7001,lena-ee test7002,lena-session,lena-session test5001'

Session Server의 경우 동일 Node에 설치된 se,ee 서버에 대해서도 패치가 필요하며 반드시 session 관련 항목보다 먼저 수행되어야 한다. 따라서 test7001과 test7002에 대해 먼저 패치수행하였음을 확인할 수 있다. 이후 Node Engine인 lena-session을 패치하고 마지막으로 각 session 인스턴스들을 패치했다.

각 패치가 완료 된 이후 log를 확인하여 HANDWORK를 진행해야 한다.

{LENA_HOME}/logs/lena-patcher/{date}/patch-yyyyMMddHHmmssSSS.log 파일확인
아래와 같은 엔트리 추출

[HANDWORK]Patching files to .....

추출된 모든 엔트리의 경로를 기반으로 파일 비교처리하여 HANDWORK작업(수정작업) 진행
- HANDWORK 작업은 인스턴스가 종료된 상태에서 진행하는것을 권장한다.
- HANDWORK 작업은 문서파일은 merge(병합)작업, .war 또는 .jar파일의 경우 copy 처리를 권장한다.

Commit

./patch_command.sh ENZ-EN9-1.3.4.4.tar.gz /engn001/lena/1.3.4.3 commit 'lena-session'

2.3.5. Web Server

배포

./patch_assist.sh deploy node /engn001/patch/ENA-1.3.4.4.tar.gz /engn001/lenaw/1.3.4.3

Patch

./patch_command.sh ENA-1.3.4.4.tar.gz /engn001/lenaw/1.3.4.3 patch 'lena-web,lena-web test6001'

Node Engine인 lena-web을 먼저 패치하고 이후 각 web 인스턴스들을 패치했다.

각 패치가 완료 된 이후 log를 확인하여 HANDWORK를 진행 해야한다.

{LENA_HOME}/logs/lena-patcher/{date}/patch-yyyyMMddHHmmssSSS.log 파일확인
아래와 같은 엔트리 추출

[HANDWORK]Patching files to .....

추출된 모든 엔트리의 경로를 기반으로 파일 비교처리하여 HANDWORK작업(수정작업) 진행
- HANDWORK 작업은 인스턴스가 종료된 상태에서 진행하는것을 권장한다.
- HANDWORK 작업은 문서파일은 merge(병합)작업, .war 또는 .jar파일의 경우 copy 처리를 권장한다.

Commit

./patch_command.sh ENA-1.3.4.4.tar.gz /engn001/lenaw/1.3.4.3 commit 'lena-web'