0

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

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

Atlassian Confluence, AWS 에서 Synchrony 설정 방법

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

일반적인 업그레이드는 새로운 바이너리 파일을 받아 실행 및 Upgrade(3) 을 선택하는 방법이다. 이 글은 OS 등 중대 업그레이드가 동시에 진행 되 었을 때를 가정해 작성한 문서다.

 

1. 운영체제 업그레이드

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

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

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

 

2. JiRA / Confluence 백업

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

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

디렉터리 백업

Confluence / JiRA 동일

  • 구동파일 위치 : /opt/atlassian
  • 어플리케이션 데이터 위치 : /var/atlassian

데이터베이스 백업

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

압축 파일 및 DB 파일은 ‘최악’의 경우 복원을 위해 사용 하게 될 매우 중요한 백업이다. 다른 시스템으로 꼭 복사해두자.

백업이 완료 되었다.

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 를 통해 비용정책 이관에 대한 논의가 필요하다) 복구 설차는 다음과 같다.

  1. 기존 인스턴스 중지 (STOP)
  2. EBS 볼륨 분리(Detach)
  3. 신규 인스턴스 생성
  4. 2번에서 분리된 EBS 볼륨 연결(Attach)
  5. OS 업데이트 및 필요 어플리케이션 설치 (JAVA)  > 리부팅
  6. JIRA or Confluence 다운로드 및 권한 부여
    1. ‘구’ 버전과 ‘신’버전 2개의 패키지가 반드시 필요
  7. ‘구’ 버전의 어플리케이션 설치
  8. 웹으로 접근 및 SERVER ID 취득 (설치 화면 2번째 단계에서 확인 가능)
  9. 서비스 중지 (service stop <jira or confluence>)
  10. ‘백업’ 데이터 복구 (기존 압축 본 해제)
    1. /opt/atlassian 복구
    2. /var/atlassian 복구
  11. Atlassian License 갱신
    1. https://my.atlassian.com 에서 SERVER ID 기반 신규 라이센스 취득
    2. Confluence or JiRA Local license 갱신
  12. ‘신’버전 으로 업그레이드
  13. 리부팅

2. EBS 볼륨 분리(Detach)

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

 

3. 신규 EC2 Instance 생성

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

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

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. 업그레이드 할 버전

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

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

7. 신규 SERVER-ID 취득

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

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

Server ID Format : AAAA-BBBB-CCCC-DDDD

8. 서비스 중지

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

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 에 위치한 각각의 파일 권한을 저장해 두면 큰 도움이 될 것이다.

기존 시스템과 동일한 환경으로 회귀했다. 하지만 실행은 불가능하다. 라이선스가 다르기 때문이다.

 

10. 라이선스 갱신

License Key 취득

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

 

License Key 갱신 방법

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

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. 설정 및 환경 재 정돈

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

 

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

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

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

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

 

Leave a Reply

Your email address will not be published. Required fields are marked *