Quantcast
Channel: サイバーエージェント 公式エンジニアブログ
Viewing all articles
Browse latest Browse all 161

Upgrading the GitHub Enterprise on AWS

$
0
0

技術本部 Advanced Dev.Center(略してADC)の村上です。

私達はMake Your Goals Come True. Easier + Faster. 

をコンセプトに開発環境の改善や統一化を行ってます。

タイトルのとおり、私達の組織ではソースコードのバージョン管理システムとしてGithub Enterprise(以下GHE)を導入しており、今回久しぶりにアップデートを行ったので、それについて書かせていただきます。

なお、今回の作業にはADCメンバーに加え、敏腕インフラエンジニアの@kakerukaeruさんのお力添えあってこそということを彼の上司@strskへ向けてアピールしておきます。

 

規模・SPEC

規模感としてはユーザ数は約1000名、Organization約400、Repository約10,000になります。

 

- Primary on AWS EC2

Instance Type :r3.4xlarge

EBS(root device) :100GiB

EBS(block device) :1500GiB

 

- Replica on AWS EC2

Instance Type :r3.4xlarge

EBS(root device) :60GiB

EBS(block device) :1500GiB

 

アップデート方針決め

アップデート前のバージョンはVersion 2.2.7で、アップデート検討中にVersion2.7が発表されたのですが、発表されたばかりだったため2.7系へのアップデートは行わず、2.6系に留めることにしました。

今回Version 2.6.8にアップデートしたわけですが、GHEの仕様上、アップデートは現在のバージョン(v2.2.7)から最新バージョン(v2.6.8)まで一気に行うことはできないので、いったん2.4系へアップデートしてから2.6系へアップデートする手順を踏んでいます。

 

今回の作業で最も注意を払った点は

・会社の資産であるソースコードや付随データを失わないこと

・サービスに支障をきたさないこと

 

なので万が一のことを考えいつでも戻せるような手順を事前検証を行いつつ、何度も考えては議論しました。

右矢印結論

・アップデート前のプライマリはアップデート後もそのまま残しておいて、いつでも元のバージョンへ戻せるようにしておく。

・アップデートするのはレプリカのみとする。アップデート後は本番のElasticIPを付け替えて本番として利用する。

・新プライマリ、旧プライマリのそれぞれには新規でレプリカを用意する。

 

 

事前検証&準備

主に検証したのは以下になります。

・インスタンス作成〜レプリケーション

・リストア検証、snapshotからの再構築
今回は切り戻しをしないので本手順は発生しませんが、再現性の確認のため実施。

・プライマリとレプリカの設定ファイルの比較

$ ssh -p122 admin@hostname -- 'ghe-config -l'

でCLIから設定の確認ができます。

アップデート前はv2.2だったのでレプリカとの設定ファイルの結構差分がありました。

 

・backupUtilsの更新

githubの公式ツールであるbackupUtilsが古くなっていたので更新。

・EBS snapshotの作成

snapshotは差分バックアップなので、事前に実行しておくとメンテナンス時間中のバックアップが短くてすみます。

 

手順

・メンテナンス開始告知

・メンテナンスモードに入れ、ユーザアクセス遮断

・バックアップ( backup-utiles及び EBSスナップショット)を取得

・レプリカとプライマリのレプリケーションを切断

・レプリカのSettingsをプライマリと同じにする

・レプリカをアップデート(v2.2.7 -> 2.4.9 -> 2.6.8)

2.2.7 -> 2.4.9は約1時間、2.4.9 -> 2.6.8は約40分かかりました。

・新しくレプリカ機を用意しレプリケーション開始

・プライマリとレプリカのElasticIPを付け替える

この作業により、DNS更新なしにレプリカを本番に置き換えることができますし、万が一の場合も即時元のバージョンへ戻すことができます。

・メンテナンスモードを解除

 

確認コマンド

アップデート前後でのrepoやorganizationデータの比較に利用したAdmin用APIは下記になります。

- Repository listhttp(s)://<hostname>/stafftools/reports/all_repositories.csv- Organizations listhttp(s)://<hostname>/stafftools/reports/all_organizations.csv- Gist list(only public)http(s)://<hostname>/api/v3/gists/public- number of issue, hook, milestone, orgs, repost, comment etchttp(s)://<hostname>/api/v3/enterprise/stats/all

 

アップデート後

1. pull requestが消えた!?

メンテナンス終了後、業務開始時間になると、pull requestが表示されないとの報告が続々と寄せられました。

アップデート前後のpull request数の変化はなく、詳細に確認してみるとlistの表示だけに問題があることがわかりました。結果としてindex作成が終わっていないことが原因でした。その後もindex作成は完了せず、結局、16時間後に確認した時点で80%弱の進捗でした。

翌朝ようやくIndex再構築の完了が確認でき、pull requestのリスト表示は正常に戻りました。次回のアップデートでは事前に周知しておきたいです。

2. deploy keyが消えた!?

GHEの仕様でdeploy keyはrepository毎に設定してくださいというアナウンスをしていましたが、事実上2.2系では同じorganization内であればdeploy keyの使い回しができてしまっていました。v2.4にバージョンアップしたことで仕様に忠実(?)になり、その使い回しができなくなったようです。

https://enterprise.github.com/releases/2.4.0/notes

正しい挙動になったということなのですが、一部利用者間で混乱が発生する事態になりました。repository数が多いプロジェクト救済のため、MachineUserの運用も検討しましたが、複数のデメリットが払拭できず見送ることにしました。
GHEへMachineUserの運用について問い合わせたところ、issueは上がっているものの、現行、一般ユーザと権限・コスト両面で同様の取り扱いということでしたので、改善を待ちたいです。

3. markdownの画像が表示されない!?

バージョン2.6からW3Cのレコメンドに従い、HTTPSコンテンツ上のHTTPコンテンツ(いわゆるmixed content)はブロックするように仕様変更されていました。

なので2.6以降使えなくなっています。

https://enterprise.github.com/releases/2.6.0/notes

4. やっぱり古いバージョンを残しておいて良かった

こちらは頃合いをみて削除予定ですが、アップデート後はたくさんの方が検証するために、アップデートとは無関係の事象も報告されたりするので、問題の切り分けのためにも残しておいてよかったと思いました。また、いざという時はこっちにそのままのデータがあるという安心感も大きいです。

これから

未解決の問題もまだ残っており、新機能の検証、バイナリデータの管理等改善したい項目が日々生まれている状況です。全サービスのエンジニアと協力し合いながら、快適な開発環境の提供をチームで取り組んでいきます。

いつもADCに協力してくれるエンジニア・クリエイターの皆様、いつもありがとうございます。皆様の激励が我々の励みになっています。

また今回の記事が同じような開発環境を担当している方々の参考になれば幸いです。
 

 

 


Viewing all articles
Browse latest Browse all 161

Trending Articles