Gitlab 6.6.5에서 8.7.0으로 업그레이드 하기

6.6.5버전에서 8.7.0으로 바로 업그레이드 하면 오류가 발생하여 부득하게 7.10.4 omni버전으로 업그레이드 후 8.7.0버전으로 업그레이드 하였다.


*이전(Migration) - 이전이 필요 없을 경우 바로 7.10.4 omni버전으로 업그레이드 후 8.7.0 버전으로 업그레이드 하면 된다.
1. 백업
/home/git/gitlab$ sudo -u git -H bundle exec rake RAILS_ENV=production gitlab:backup:create (backing up at old gitlab server, source compile version)
 소스로 컴파일한 버전의 경우 위와 같이 백업 한다.

omnibus 버전인 경우는 
sudo gitlab-rake gitlab:backup:create

2. 복구
서버 사양은 2core 2G 이상의 RAM을 가지고 있어야 원활하게 작동한다. 
해당 서버가 마련 되었으면 아래 명령어를 이용하여 6.6.5버전을 설치한다.(Ubuntu에 설치)
sudo apt-get install openssh-server
sudo apt-get install postfix # sendmail or exim is also OK
sudo dpkg -i gitlab-x.y.z.deb # this is the .deb you downloaded(6.6.5)
sudo gitlab-ctl reconfigure

6.6.5버전은 https://about.gitlab.com/downloads/archives/ 경로를 통해 얻을 수 있다.(wget 혹은 다운로드 후 직접 서버에 업로드)

백업한 파일을 서버에 올린다.(e.g. /home/git/gitlab/tmp/backups/1461220799_gitlab_backup.tar)
해당 디렉토리로 옮긴다.
sudo mv 1461220799_gitlab_backup.tar /var/opt/gitlab/backups/
# 데이터베이스에 접근하는 프로세스를 정지 시킨다.
sudo gitlab-ctl stop unicorn
sudo gitlab-ctl stop sidekiq
# 복원한다.
/var/opt/gitlab$ sudo gitlab-rake gitlab:backup:restore BACKUP=1461220799
복원 시 혹시 버전이 맞지 않다고 하면 tar 파일 안의 "backup_information.yml" 파일의 버전 정보를 6.6.5로 변경 한 후 다시 tar로 묶어 사용한다.

# Gitlab을 시작한다.
sudo gitlab-ctl start
# Gitlab 상태를 확인한다.
sudo gitlab-rake gitlab:check SANITIZE=true


업그레이드 - 이전 하지 않은 경우 여기부터 시작하면 된다. 혹시나 모를 문제를 위해 백업은 반드시 실행 후 업그레이드 하자.

7.10.4버전 또한 https://about.gitlab.com/downloads/archives/ 경로를 통해 얻을 수 있다.(wget 혹은 다운로드 후 직접 서버에 업로드)
# Ubuntu/Debian:
sudo dpkg -i gitlab-ce_7.10.4-omnibus-1_amd64.deb


로그상에 에러가 발생하면  “NoMethodError (undefined method `push_events=' for ~~~”, 이 명령어를 실행한다. “sudo gitlab-rake db:migrate , sudo gitlab-ctl reconfigure”.
로그 위치는 /var/log/gitlab/gitlab-rails/production.log 이다. permission 오류가 발생하면 sudo를 사용하자. 

이로써 7.10.4버전으로 업그레이드가 완료 되었을 것이다. gitlab 페이지를 열면 해당 버전으로 정상작동하는 것을 알 수 있다.

이제는 8.7.0버전으로 업그레이드 차례이다.
서버에서 아래 명령어를 수행한다.
curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash
sudo apt-get install gitlab-ce
sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart



reference site




추가문제해결

위키가 생성 되지 않는 문제가 발생하고 production.log 에 "NoMethodError (undefined method username' for~~~" 오류가 발생하는 경우 아래 URL을 참고 하여 /opt/gitlab/embedded/service/gitlab-rails/app/services/wiki_pages/create_service.rb 파일 내용만 수정하면 일단 작동은 된다.(Workaround)


8.8.0에서 완전 수정 될 듯 하다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

AWS를 이용한 Serverless 환경 구축 2 - Lambda로 DynamoDB 쓰고 읽기

이미지
지난 번에 Lamda로 hello_world만 찍기만 하여 demo의 성격 이었다면 이번은 실제로 DynamoDB에 쓰고 읽기를 해보자. 순서는 아래와 같다. DynamoDB table 생성 후 IAM 권한 추가(Access DynamoDB) Lambda 함수의 쓰기, 읽기를 만들 것이다. DynamoDB table 생성 1. "Create table"을 선택한다.   2. "Table name", "Primary key"에 값을 입력한 후 "Create"를 클릭한다.(예 Table name: Page, Primary key: id) 3. DynamoDB table이 간단하게 생성 되었다. IAM DynamoDB 접근권한 추가 기존 Role에는 DynamoDB 접근권한이 없으므로 권한을 추가해야 한다. 1. 기존에 사용하던 " lambda_basic_execution" Role에 Jason을 추가 해 주면 된다.("Statement"[]안에 추가) { "Sid": "Stmt1428341300017", "Action": [ "dynamodb:DeleteItem", "dynamodb:GetItem", "dynamodb:PutItem", "dynamodb:Query", "dynamodb:Scan", "dynamodb:UpdateItem" ], "Effect": "Allow", "Resource": "*" } Lambda 쓰기 함수 만들기 이번에는 L...
자세한 내용 보기

Gitlab CI 설정

이미지
-build 수행 프로젝트 페이지로 이동하여 설정부분(Setting)의 build가 활성화 되지 않았으면 활성화 시킨다. repository 최상단에 .gitlab-ci.yml을 작성하여 올린다.(  http://doc.gitlab.com/ee/ci/yaml/README.html ) README 파일과 같은 위치 .gitlab-ci.yml 작성법은  https://gitlab.com/help/ci/yaml/README.md#script  참고한다. add, commit 후 push하면 자동으로 build가 진행된다. -Runner 설치 build를 진행 하려면 Runner를 설치해야한다. ( https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/docs/install/linux-repository.md ) 참고하면 된다. Runner 설치 시  URL과 token은 해당 프로젝트의 Runner 화면을 확인한다.(아래 빨간 선 부분) 위 화면까지 했으면 Specific Runner를 생성하였을 것이다. Shared Runner를 생성하려면  https://gitlab.com/help/ci/runners/README.md  을 참고한다. (해당 내용을 보면 Shared와 Specific Runner의 차이를 알 수 있다. 원하는 것을 선택하여 사용하면 된다.) Runner가 설치 되었으면 Build에서 pending 상태의 작업들이 성공 되어 있는 것을 알 수 있다. 구미에 맞게 .gitlab-ci.yml을 작성하여 CI를 진행하면 된다.
자세한 내용 보기

AWS Ceritificate Manger 이용방법

이미지
간편하게 SSL 서비스를 이용할 수 있는 방법으로 AWS Ceritficate Managemer(이하 ACM) 서비스가 출시 되었다. Virginia 지역에서만 가능하던 것이 이제 전 지역에서 사용가능하다. 기존 SSL 을 이용하는 것과 비교하여 매우 쉬워졌다. https://aws.amazon.com/ko/blogs/aws/new-aws-certificate-manager-deploy-ssltls-based-apps-on-aws/ ACM은 기존 SSL인증 업체에 해당 키 값을 받아 Amazon 서비스에 등록하고 매년 갱신 하는 불편함을 제거 해 주는 서비스이다. 기존 SSL 인증업체 같은 경우 보안사고가 발생하였을때, 보험금을 통해 해당 사고를 보상 해주지만 ACM은 무료이니 보상이라는 개념은 없어 보인다. 적용하고 보니 최상위 인증기관Certificate Authorities(CA)은 Starfiled Service이다. https://en.wikipedia.org/wiki/Starfield_Technologies 소유주가 GoDaddy이다. CA업체에 관한 정보는 이러하다. https://en.wikipedia.org/wiki/Certificate_authority 결론적으로 판단은 본인이 하겠지만 믿고 써도 된다고 본다. 본격적으로추가하는 방법은 매우 간단하다. 1. ACM 페이지를 방문하여 시작한다.(Get started) - ELB에 추가하려면 해당 지역에서 추가 해야 하는 것으로 알고 있다. 2. Domain입력 지점에 필요한 domain명을 입력하고(www.example.com) Review and request를 누르면 거의 완료다. 여러개 추가 하려고 하면 "Add another name to this certificate" 나 *(wildcard)를 이용한다. 3. confirm하면 생성은 끝났다.. 4. validation을 위해 e-mail 인증을 한다. 해당 e-mail을 찾아...
자세한 내용 보기