-
Notifications
You must be signed in to change notification settings - Fork 2
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
chore: Update content for backup-utils
- Loading branch information
Showing
1 changed file
with
78 additions
and
42 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -32,11 +32,9 @@ Github Enterprise Server에서 백업 유틸리티(backup-utils)와 고가용성 | |
|
||
### github-backup-utils | ||
|
||
Github Enterprise Server를 운영할 때 공식적으로 github-backup-utils를 사용해서 백업을 수행해야 합니다. | ||
Github Enterprise Server를 운영할 때 공식적으로 backup-utils를 사용해서 백업을 수행해야 합니다. | ||
|
||
Github Support 측 공식 답변으로는 GHE 서버의 백업은 AWS Backup의 경우 보조 개념으로 사용하고, github-backup-utils를 메인 백업으로 사용하는 걸 권장한다고 합니다. | ||
|
||
이 경우 AWS Backup은 Optional한 선택지이므로 Github에서 공식적으로 제공하는 backup-utils만 사용해도 무방할 것 같습니다. | ||
Github Support 측 공식 답변으로는 Github Enterprise Server의 백업은 AWS Backup의 경우 보조 개념으로 사용하고, backup-utils를 메인 백업으로 사용하는 걸 권장한다고 합니다. 이 경우 AWS Backup은 선택사항이므로 Github에서 공식적으로 제공하는 backup-utils만 사용해도 무방합니다. | ||
|
||
| ||
|
||
|
@@ -71,15 +69,15 @@ Github Enterprise 시스템 구성은 다음과 같습니다. | |
|
||
### 백업 인스턴스 생성 | ||
|
||
#### OS | ||
#### OS (AMI) | ||
|
||
Github 측에서는 공식적으로 Ubuntu OS를 기준으로 백업 소프트웨어를 테스트 되었으므로 Ubuntu OS를 권장하고 있습니다. | ||
Github에서는 공식적으로 Ubuntu OS에서 백업 소프트웨어를 테스트했기 때문에 Ubuntu를 사용하는 걸 권장합니다. | ||
|
||
그러나 저는 이번 기회에 Amazon Linux 2023을 써보고 싶어서 백업 서버의 AMI로 Amazon Linux 2023을 선정했습니다. | ||
하지만 저는 AWS 환경을 사용하고 있어서 백업 서버의 AMI로 Amazon Linux 2023을 선택했습니다. 이유는 [Amazon Linux 2 FAQ](https://aws.amazon.com/ko/amazon-linux-2/faqs/) 문서에 의하면 Amazon Linux 2가 2025년 6월 30일에 완전 지원이 종료되기 때문입니다. | ||
|
||
| ||
|
||
제 경우 백업 서버의 OS로 Amazon Linux 2023 + ARM64 아키텍처를 사용했는데 운영에 전혀 영향이 없었습니다. | ||
제 경우 백업 서버의 OS로 Amazon Linux 2023 + ARM64 아키텍처를 사용했는데 백업서버 운영에 전혀 영향이 없었습니다. | ||
|
||
```bash | ||
$ cat /etc/os-release | ||
|
@@ -101,7 +99,8 @@ SUPPORT_END="2028-03-01" | |
|
||
#### 리소스 스펙 | ||
|
||
CPU 및 메모리 요구 사항은 GitHub Enterprise Server 어플라이언스의 크기에 따라 다릅니다. | ||
CPU 및 메모리 요구 사항은 GitHub Enterprise Server 어플라이언스의 크기에 따라 다릅니다. | ||
|
||
GitHub Enterprise Backup Utilities를 실행하는 호스트에는 최소 4개의 코어와 8GB의 RAM이 권장됩니다. | ||
|
||
| ||
|
@@ -135,21 +134,18 @@ tmpfs tmpfs 783M 0 783M 0% /run/user/1000 | |
|
||
### 백업 인스턴스에 접속 | ||
|
||
Github Enterprise 백업 인스턴스에 SSH로 접속합니다. | ||
Github Enterprise 백업 인스턴스에 SSH 또는 [SSM Session Manager](https://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/session-manager.html)로 접속합니다. | ||
|
||
```bash | ||
# SSH access command example | ||
$ ssh -i my-ec2-ssh-key.pem -p 22 -l ec2-user 10.190.33.44 | ||
ssh -i my-ec2-ssh-key.pem -p 22 -l ec2-user 10.190.33.44 | ||
``` | ||
|
||
2023년 7월 기준으로 Amazon Linux 2023은 Session Manager를 사용할 수 없고 SSH만 지원합니다. | ||
[Amazon Linux 2023 공식문서](https://docs.aws.amazon.com/linux/al2023/ug/connecting-to-instances.html) | ||
|
||
| ||
|
||
#### 필수 유틸리티 | ||
|
||
백업 서버에 git을 설치합니다. 백업 수행에 필요한 유틸리티입니다. | ||
백업 서버에 `git` 명령어을 설치합니다. 백업 수행에 필요한 유틸리티입니다. | ||
|
||
```bash | ||
$ sudo yum install -y git | ||
|
@@ -174,8 +170,9 @@ Amazon Linux 2023 기준으로 대부분이 이미 설치되어 있지만 git과 | |
[github-backup-utils v3.8.1](https://github.com/github/backup-utils/releases/tag/v3.8.1) 패키지를 `/opt/` 밑에 다운로드 받습니다. | ||
|
||
```bash | ||
$ wget https://github.com/github/backup-utils/releases/download/v3.8.1/github-backup-utils-v3.8.1.tar.gz \ | ||
-O /opt/github-backup-utils-v3.8.1.tar.gz | ||
VERSION="v3.8.1" | ||
wget https://github.com/github/backup-utils/releases/download/$VERSION/github-backup-utils-$VERSION.tar.gz \ | ||
-O /opt/github-backup-utils-$VERSION.tar.gz | ||
``` | ||
|
||
위 명령어가 실행되기 위해서 백업서버가 NAT Gateway를 경유해서 인터넷 아웃바운드 가능한 네트워크 환경이어야 합니다. | ||
|
@@ -475,18 +472,19 @@ $ sudo mv backup.config-example /etc/github-backup-utils/backup.config | |
|
||
### cronie 설치 | ||
|
||
Amazon Linux 2023에는 기본적으로 crontab이 설치되어 있지 않습니다. | ||
스케줄 백업을 지정하기 위해 cron 데몬(cronie)을 설치합니다. | ||
스케줄 백업을 수행하기 위해 cron 데몬<sup>cronie</sup>을 설치합니다. | ||
|
||
```bash | ||
$ sudo yum install -y cronie | ||
``` | ||
|
||
Amazon Linux 2023은 내부 반복 작업을 [systemd 타이머](https://www.freedesktop.org/software/systemd/man/systemd.timer.html)로 마이그레이션했기 때문에 의도적으로 cron이 제외되었습니다. [#300](https://github.com/amazonlinux/amazon-linux-2023/issues/300#issuecomment-1481592973) | ||
Amazon Linux 2023에는 기본적으로 crontab이 설치되어 있지 않습니다. Amazon Linux 2023은 내부 반복 작업을 [systemd 타이머](https://www.freedesktop.org/software/systemd/man/systemd.timer.html)로 마이그레이션했기 때문에 의도적으로 cron 패키지가 제외되어 있습니다. | ||
|
||
> Amazon Linux 2023에서 cron deprecation 관련으로는 [deprecated cron](https://docs.aws.amazon.com/linux/al2023/ug/deprecated-al2023.html#deprecated-cron)과 [Github issue #300](https://github.com/amazonlinux/amazon-linux-2023/issues/300#issuecomment-1481592973)을 참고합니다. | ||
| ||
|
||
백업서버가 재부팅될 경우에도 cron 데몬을 자동시작하도록 enable 설정합니다. | ||
백업서버가 재부팅된 후에도 cron 데몬<sup>crond</sup>을 자동시작하도록 enable 설정합니다. | ||
|
||
```bash | ||
$ sudo systemctl enable crond.service | ||
|
@@ -554,10 +552,10 @@ crontab에 백업 스케줄 작성 시 참고하세요. | |
* * * * * command to be executed | ||
┬ ┬ ┬ ┬ ┬ | ||
│ │ │ │ └───────────── Day of Week (0=Sun .. 6=Sat) | ||
│ │ │ └─────────────── Month (1..12) | ||
│ │ └───────────────── Day of Month (1..31) | ||
│ └─────────────────── Hour (0..23) | ||
└───────────────────── Minute (0..59) | ||
│ │ │ └─────────────── Month (1 .. 12) | ||
│ │ └───────────────── Day of Month (1 .. 31) | ||
│ └─────────────────── Hour (0 .. 23) | ||
└───────────────────── Minute (0 .. 59) | ||
``` | ||
|
||
| ||
|
@@ -569,11 +567,15 @@ crontab에 백업 스케줄 작성 시 참고하세요. | |
백업 서버에서 새로운 SSH 키페어를 생성합니다. | ||
|
||
```bash | ||
$ ssh-keygen -t ed25519 -C "[email protected]" | ||
ssh-keygen \ | ||
-t ed25519 \ | ||
-C "[email protected]" \ | ||
-P "" | ||
``` | ||
|
||
- `-t` (Type) : 어떠한 암호화 방식을 사용할 것인지를 지정합니다. 사용 가능한 타입으로는 rsa, dsa, ecdsa, ed25519 등이 있습니다. | ||
- `-C` (Comment) : 생성한 키에 주석 달기. 일반적으로는 Github Enterprise 관리자의 이메일 주소를 입력합니다. | ||
- `-t` (Type): 어떠한 암호화 방식을 사용할 것인지를 지정합니다. 사용 가능한 타입으로는 `rsa`, `dsa`, `ecdsa`, `ed25519` 등이 있습니다. | ||
- `-C` (Comment): 생성한 키에 주석 달기. 일반적으로는 Github Enterprise 관리자의 이메일 주소를 입력합니다. | ||
- `-P` (Passphrase): 패스프레이즈 없이 SSH 키를 생성합니다. | ||
|
||
| ||
|
||
|
@@ -593,10 +595,8 @@ authorized_keys id_ed25519 id_ed25519.pub known_hosts | |
또는 아래와 같이 Primary 서버의 `~/.ssh/authorized_keys` 파일에 추가해도 콘솔에서 설정한 것과 동일한 효과를 나타냅니다. | ||
|
||
```bash | ||
$ cat ~/.ssh/authorized_keys | ||
... | ||
# 백업서버의 공개키 id_ed25519.pub | ||
ssh-ed25519 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX [email protected] | ||
# Add public key in your GHE instance as backup target | ||
echo "ssh-ed25519 <your-public-key> [email protected]" | tee -a /home/admin/.ssh/authorized_keys | ||
``` | ||
|
||
| ||
|
@@ -775,14 +775,14 @@ Backup progress: 138.00 % (25 / 18 ) ghe-backup-es-rsync took 1s | |
|
||
| ||
|
||
### 정리 | ||
### 주요 핵심파일들 | ||
|
||
백업 서버에서 사용하는 핵심 파일 경로는 다음과 같습니다. | ||
EC2 기반의 `backup-utils` 서버에서 사용하는 중요파일 경로는 다음과 같습니다. | ||
|
||
- **설정파일 기본경로** : /etc/github-backup-utils/backup.config | ||
- **패키지 경로** : /opt/backup-utils/ | ||
- **스냅샷이 저장되는 경로** : /opt/backup-utils/data/ | ||
- **백업 로그 경로** : /opt/backup-utils/backup.log | ||
- **설정파일 기본경로** : `/etc/github-backup-utils/backup.config` | ||
- **패키지 경로** : `/opt/backup-utils/` | ||
- **스냅샷이 저장되는 경로** : `/opt/backup-utils/data/` | ||
- **백업 로그 경로** : `/opt/backup-utils/backup.log` | ||
|
||
| ||
|
||
|
@@ -799,7 +799,18 @@ Backup progress: 138.00 % (25 / 18 ) ghe-backup-es-rsync took 1s | |
그래서 백업서버 인프라를 쿠버네티스 클러스터에 CronJob 형태로 운영하는 결정을 했습니다. gp3 타입의 EBS 볼륨에 백업 데이터를 증적하는 메커니즘은 동일합니다. | ||
다만 백업을 수행하는 주체가 EC2 대신 `CronJob`이 주기적으로 스케줄링하는 `Pod`로 바뀐다는 점이 가장 큰 차이점입니다. | ||
|
||
이에 대한 설치 방법은 이 글의 주제를 벗어나므로 생략하겠습니다. 더 관심 있으신 분들은 제가 개발한 [backup-utils-chart](https://github.com/younsl/charts/tree/main/charts/backup-utils) 레포지터리를 확인하세요. | ||
backup-utils 설치는 SSH Key에 대한 Secret을 생성한 이후, 헬름 차트로 손쉽게 가능합니다. | ||
|
||
```bash | ||
helm upgrade \ | ||
--install \ | ||
--namespace backup-utils \ | ||
--create-namespace \ | ||
backup-utils . \ | ||
-f values.yaml | ||
``` | ||
|
||
더 관심 있으신 분들은 제가 개발한 [backup-utils](https://github.com/younsl/charts/tree/main/charts/backup-utils) 헬름차트를 확인하세요. | ||
|
||
| ||
|
||
|
@@ -812,12 +823,20 @@ Primary & Replica로 HA 구성을 했지만 둘다 깨지는 사단에 이르렀 | |
![backup-utils를 사용한 복구절차](./8.png) | ||
|
||
1. 복구할 새 Github Enterprise Server 인스턴스 생성: 반드시 **새로 생성된 인스턴스**에 복구를 해야만 합니다. | ||
2. GHE 새 인스턴스의 `/home/admin/.ssh/authorized_keys` 경로에 id_ed25519 공개키 등록 | ||
2. GHE 새 인스턴스의 `/home/admin/.ssh/authorized_keys` 경로에 SSH 공개키<sup>id_ed25519.pub</sup> 등록 | ||
3. 복구용 backup-utils deployment 파드 생성 | ||
4. **메인터넌스 모드 켜기**: `ghe-restore` 명령어를 수행하려면 `ghe-maintenance -s`를 사용해서 반드시 메인터넌스 모드가 켜져 있어야 합니다. | ||
5. Actions S3 설정: 이 단계는 내가 복구할 스냅샷에 Actions 데이터가 포함되어 있어서 필요했습니다. 자세한 설정 방법은 [Github Enterprise Server 공식문서](https://docs.github.com/en/enterprise-server/admin/managing-github-actions-for-your-enterprise/advanced-configuration-and-troubleshooting/backing-up-and-restoring-github-enterprise-server-with-github-actions-enabled#restoring-a-backup-of-github-enterprise-server-when-github-actions-is-enabled)에서 확인할 수 있습니다. | ||
|
||
```bash | ||
# Enable maintenance mode in new primary GHE instance | ||
ghe-maintenance -q | ||
ghe-maintenance -s | ||
``` | ||
|
||
5. **Actions S3 설정**: 이 단계는 내가 복구할 스냅샷에 Actions 데이터가 포함되어 있어서 필요했습니다. 자세한 설정 방법은 [Github Enterprise Server 공식문서](https://docs.github.com/en/enterprise-server/admin/managing-github-actions-for-your-enterprise/advanced-configuration-and-troubleshooting/backing-up-and-restoring-github-enterprise-server-with-github-actions-enabled#restoring-a-backup-of-github-enterprise-server-when-github-actions-is-enabled)에서 확인할 수 있습니다. | ||
|
||
```bash | ||
# Run these commands in new primary GHE instance | ||
# Actions S3 관련 설정 | ||
ghe-config secrets.actions.storage.blob-provider "s3" | ||
|
||
|
@@ -832,15 +851,32 @@ Primary & Replica로 HA 구성을 했지만 둘다 깨지는 사단에 이르렀 | |
ghe-config-apply | ||
``` | ||
|
||
6. 복구용 파드 → 새 인스턴스 SSH 포트<sup>TCP/122</sup>로 연결 가능여부 확인 `ghe-host-check` | ||
6. 복구용 파드 → 새 인스턴스 SSH 포트<sup>TCP/122</sup>로 연결 가능여부 확인 | ||
|
||
```bash | ||
ghe-host-check | ||
``` | ||
|
||
7. 복구용 파드에서 스냅샷 복구 `ghe-restore` | ||
|
||
| ||
|
||
## 정리 | ||
|
||
- Github Enterprise Server를 운영할 때 백업과 고가용성을 위한 Replica를 같이 혼합해서 사용하는 것이 모범사례입니다. | ||
- 백업 구성은 지루한 작업이지만 그 무엇보다 중요합니다. Github Enterprise Server에 재난이 닥쳤을 때에 후회하면 이미 늦습니다. | ||
- 최근 15시간 동안 Github Enterprise Server 서버를 복구한 후 포스트모템을 쓰면서 업무가 중단된 개발자들에게 미안하기도 하고 많은 생각이 스쳤습니다. | ||
|
||
> 초기에 Github Enterprise Server 구축할 때 `backup-utils`로 데이터 백업 구성 해놓길 잘했다. VCS를 self-hosted로 직접 운영하는 건 매우 고된 작업이구나.. 가끔은 Failover 이후에 Replica 서버까지도 고장나는 경우가 있구나.. 만약 데이터 백업하지 않았더라면? 모든 회사의 소스코드가 날라간 상황에서 나는 어떻게 되었을까? | ||
| ||
|
||
## 참고자료 | ||
|
||
[GitHub Enterprise Server Backup Utilities - Documentation](https://github.com/github/backup-utils#documentation) | ||
github-backup-utils 공식문서에 전체적인 설명이 잘 나와 있습니다. | ||
|
||
[Installing CronTab on Amazon Linux 2023 EC2](https://jainsaket-1994.medium.com/installing-crontab-on-amazon-linux-2023-ec2-98cf2708b171) | ||
Amazon Linux 2023에서 CronTab 설치 시에 참고한 글 | ||
|
||
[Deprecated in AL2023](https://docs.aws.amazon.com/linux/al2023/ug/deprecated-al2023.html#deprecated-cron) |