Atlassian JiRA, Conflence AWS 환경 유지보수(Maintenance)

Atlassian 의 JiRA 및 Confluence 는 매우 유용한 협업 툴로 많은 기업에서 사용중이다. Atlassian 은 자사의 제품의 안정성 확보 및 기능 추가를 위해 지속적 지원을 해 나가고 있는데, 최근 Confluence 가 공통 협업 기능 “Synchrony”를 지원하기 시작한 것이 좋은 사례다.

Atlassian Confluence, AWS 에서 Synchrony 설정 방법

문제는 유지보수(메인터런스) 방법이 깔끔하지 않다는 것. JiRA 및 Confluence 가 매우 중요한 정보를 담고 있는 만큼 자칫 잘못하다 그동안 쌓아왔던 데이터를 모두 날릴 확률이 없지 않다. 자, AWS(Amazon Web Service) 환경에서 JIRA / Confluence 의 메인터런스 방법을 알아보자.

 

1. 운영체제 업그레이드

AWS 환경에서 가장 대중적으로 사용되는 Free-Linux, ubuntu 의 16.04 머신 이미지가 공식 등록 되었다. EC2 Instance 를 생성할 때 선택할 수 있게 되었고, 16.04.1 까지 업그레이드 된 상태다. 물론 성급히 OS 를 업그레이드 할 필요는 없다. 14.04 의 기본적 업데이트는 2018년 까지 지속 될 예정이기 때문이다.

• 참고 : https://www.ubuntu.com/info/release-end-of-life

ubuntu 는 “do–release–upgrade” 를 통해 메이저 버전 업그레이드가 가능하며, ubuntu 14.04 가 설치된 EC2 Instance 역시 예외가 아니다. 만약 이 커맨드가 동작하지 않는다면 시스템을 업그레이드 한 후 진행하자. (반드시 2번을 읽고 진행할 필요가 있다)

sudo su
apt-get update
apt-get -y upgrade
reboot
sudo su
do-release-upgrade

물론 여기까지 읽고 바로 OS 업그레이드를 진행한 사람은 없을 것이다. 바로 소중한 JIRA / Confluence 자료를 백업해야 하기 때문.

 

2. JiRA / Confluence 백업

운영체제를 업그레이드 하거나, 혹은 JIRA/Confluence 만 업그레이드 한다 하더라도 Cool-Backup 은 필수다. 물론 이 두 솔루션은 자체적인 백업 기능을 제공하고 있다.

 

경험적으로 이 백업은 일종의 보험일 뿐 완벽한 복원은 보장하지 않는다. 본인의 경우 3번의 백업 및 복구 시도에서 단 한차례도 완벽하게 복원 된 적이 없었다.

디렉터리 백업

tar cvvzf /tmp/backup.tar.gz /opt/atlassian
tar cvvzf /tmp/backup-application.tar.gz /var/atlassian

 

데이터베이스 백업

mysqldump --single-transaction -h[USER-RDS-HOST] -u[USER-NAME] -p [DBNAME] > atlassian.sql

–single-transaction 옵션을 사용한 이유는 AWS RDS 에서 권한 불충분으로 table lock 기능을 사용할 수 없어 dump 가 멈추는(권한 불충분) 현상을 막아준다.

백업이 완료 되었다.

OS를 업그레이드 하자. 결과는 뻔하다. 당신은 분명히 실패할 것이고 EC2 Instance 는 부팅되지 않을 것이다.  OS 업데이트 후 SSH 로그인이 되지 않는 결과를 맞이할 것이기 때문이다.

 

3. JIRA/Confluence 재설치 및 복구

OS 업그레이드 후 AWS Web-Console 에서 EC2 Status Check 부분을 살펴보면 OS 업그레이드 된 Instance만 2/2 checks passed 이 아닌 1/2 checks passed 상태 일 것이다. Screen Shot을 살펴보면 부팅은 완료되어 Login 대기중일 것이나, ssh 접근이 불가능할 것이다.

미련 갖지 말고 이 인스턴스를 멈추자(1). 비용이 중복 지출되는 것을 막아야 하기 때문이다. 만약 RI(Reserved Instance 라면 Support 를 통해 비용정책 이관에 대한 논의가 필요하다) 복구 설차는 다음과 같다.

 

 

2. EBS 볼륨 분리(Detach)

기존 EC2 Instance 에서 EBS Volume 을 분리하자. 새로운 EC2 Instance에 mount, 필요 파일들을 편리하게 복사 함으로써 작업 시간을 단축할 수 있다.

 

 

3. 신규 EC2 Instance 생성

신규 EC2 Instance 를 생성하고 기본 환경을 반영한다. 반드시 동일한 스팩일 필요는 없지만, 운영체제는 같아야 한다. Linux라 하더라도 ubuntu 에서 백업된 시스템은 rhel 에서 복구되지 않는다.

EC2 Instance 컨디션은 언제나 늘 최신을 유지하고, 특별한(호환성) 문제가 없다면 필요 라이브러리/어플리케이션은 최근 출시된 안정화 버전을 설치하자. 이 글을 작성하는 시점에서 openjdk 의 최신 버전은 9이며,  JIRA 및 Confluence 호환성에 특별한 문제는 없는 것으로 알려저 있다.

sudo su
apt-get update
apt-get -y upgrade
apt-get install openjdk-9-jre-headless
sync
reboot

 

4. 신규 EC2 Instance 에 EBS Volume 연결 (Attach)

3번 절차에서의 리부팅이 완료되면 EBS Volume 을 연결하자.

Instance 항목에 신규 EC2 Instance 를 선택해 Attach 버튼을 누르면 된다.

 

6. Atlassian 어플리케이션 다운로드

JIRA or Confluence 을 다운로드 하자. 2가지 버전이 필요하다.  (예제는 7.2.1 및 7.2.6 을 받는 경우)

1. 기존에 설치된 버전
2. 업그레이드 할 버전

• URL : https://www.atlassian.com/software/jira/download-archives

sudo su
mkdir /opt/download
cd /opt/download
wget https://www.atlassian.com/software/jira/downloads/binary/atlassian-jira-software-7.2.1-x64.bin
wget https://www.atlassian.com/software/jira/downloads/binary/atlassian-jira-software-7.2.6-x64.bin
chmod +x *.bin

기존 버전. 즉 구 버전은 손상된 기존 환경을 복구할 때 필요하다. 새로운 버전을 처음부터 설치 및 복구 하는 방법이 있지만, 동일 환경에서 백업된 버전에서 가장 높은 성공률을 보이는건 어찌보면 당연한 케이스다.  이 문서에서 사용된 예제 시스템에는 7.2.1 이 설치되어 있었기 때문에 7.2.1 을 설치했다.

별도의 환경 설정 및 라이브러리 (기존엔 mysql connector 을 복사했을 것이다) 설치가 불필요하다. Express Install (1) 로 진행하면 설치 완료 까지 몇 분 걸리지 않는다.

./atlassian-jira-software-7.2.1-x64.bin

 

7. 신규 SERVER-ID 취득

Server ID 는 Atlassian 이 식별하는 우리 서버의 고유 ID 다. 신규 EC2 Instance (Server)에서 진행 되었기 때문에 Server ID 는 당연히 변경 되었을 것이다. Atlassian License 는 이 Server ID 를 기반으로 하고 있기 때문에 반드시 이 ID 값을 취득해야 한다.

취득 방법은 매우 간단하다. 이 단계에서 우린 이미 구 버전으로 어플리케이션 설치가 완료 되었고, 설치 화면 두번째에서 Server ID 가 발급되기 때문이다. 이를 노트패드 등에 기록해 두자.

 

8. 서비스 중지

복구를 위해선 현재 구동중인 어플리케이션 (JiRA / Confluence)을 중단해야 한다. 어플리케이션이 실행 중인 경우 기존 파일 이동 시 실행중인 프로세스 이슈로 완벽하게 복사가 이뤄지지 않기 때문이다.

service stop confluence (or jira)

 

9. 백업 파일 복구

엄연히 말해 백업 파일이 아닌, 기존 시스템에서의 이전이다. 앞선 4번에서 EBS Volume 을 Attach 했다. 이를 이용해 환경을 완벽하게. 동일하게 복구할 것이다.

1. lsblk 를 통해 연결된 디바이스 명을 찾는다. xvda 는 기본 디바이스 이며, xvdf1 이 신규 디바이스 이다 (mount point 가 없다)
2. 마운트 될 폴더명을 생성한다. (mkdir /old)
3. 생성된 폴더에 마운트한다 (mount /mnt/xvdf1 /old)

기존 스토리지가 연결 되었기 때문에 필요한 파일들을 옮기자. Atlassian 어플리케이션의 경우 ‘권한’ 부분을 제외하고 특별한 이슈가 발생하지 않는다. User ID / Group ID 가 서로 다르지 않은가만 확인해 보자 (JIRA : jira , Confluence : confluence) 혹시나 모르니 /var 및 /opt 에 위치한 각각의 파일 권한을 저장해 두면 큰 도움이 될 것이다.

cp -r /old/var/atlassian /var/ cp -r /old/opt/atlassian /opt/

 

10. 라이선스 갱신

License Key 취득

앞서 취득한 Server ID 기반 신규 License 를 발급 받아야 한다.  Atlassian License URL 내 Server ID 만 입력하면 신규 License Key 취득이 가능하다. (발급된 License Key 의 엔터문자를 제거해야 한다)

• URL : https://my.atlassian.com/products/index

 

License Key 갱신 방법

Confluence – confluence.cfg.xml 파일에 License Key 와 Server ID 를 수정

vi /var/atlassian/application-data/confluence/confluence.cfg.xml
 
....
<property name="atlassian.license.message">LICENSE KEY</property>
<property name="confluence.setup.server.id">SERVER-ID</property>
....

JIRA – Database 내 License 를 변경

• https://confluence.atlassian.com/jirakb/how-to-get-and-update-jira-license-string-from-the-database-441746313.html 참고

 

11. ‘신’ 버전 업그레이드

지금 까지 구 버전으로 진행 했다면 이제 신 버전을 설치할 단계다. 신 버전의 설치는 2가지 의미가 있다.

1. ‘말’ 그대로 새로운 버전으로 업그레이드
2. 설정 및 환경 재 정돈

./atlassian-jira-software-7.2.6-x64.bin

 

설치 모드는 Upgrade (3) 을 진행하면 되고, 설치 완료 후 시스템 리부팅으로 작업이 끝난다.

 

먼 길을 돌아왔다. 이상하게 OS 업그레이드 할 때 마다 JIRA/Confluence 가 설치된 Instance 만큼은 정상 동작하지 않았다. 물론, 가장 좋은 방법은 설치 후 백업 데이터 복원이다. 하지만, 이경우 DB 를 날리거나 신규 DB 로 설치해야 할 뿐만 아니라, 백업 데이터가 완벽하게 복원된다 보장받기도 어렵다.

매번 Confluence / JIRA 의 유지보수 때 마다 다음의 만반의 준비를 하고 작업에 임하고 있다.

1. RDS Dump
2. EBS Snapshot 생성
3. 폴더 압축
4. 프로그램 내 백업

백업은 매우 중요하다는 것! 잊지 말자