GitHub Enterprise Serverの管理が面倒だからGitHub Enterprise Cloudに移行したい人（企業）へ

先週「来週は違うネタを書く」って言ったやんけ！

ごめんなさい。やんごとなき事情により書けなくなりました。
大掛かりなイベントなので運営の方も最後まで決断を迷われたと思いますし個人的にもとても楽しみにしていたのですが、何かあってからでは遅いので賢明な判断だと思います。
発表スライドは大事に取っていますが、今回の発表内容はしばらく他のイベントで話しちゃダメだよと言われたのでまだ公表できません。

というわけで、急遽またGitHubネタでいきます。

GitHub Enterprise Server（以下GHES）とGitHub Enterprise Cloud（GHEC）の違いは去年の記事に書いたとおりで、一言でいうとGHES＝オンプレ版、GHEC＝クラウド版（https://github.com/）です。

この中で、GHESはオンプレだからサーバーをこちらで用意しないといけない、バックアップをこちら側で取らないといけない、GHECでは使える最新機能が少し遅れて入る（最近の例だとGitHub Actions）といった理由でGHECへの移行を検討している（あるいは最初からGHECの使用を検討している）企業は少なからずあると思います。

確かにGHECはサーバーの管理をGitHub社に完全おまかせ状態なので、サーバーの用意もバックアップも障害対応もアップデートもGitHub社が管理してくれるという点では超絶便利なんですが、運用面を何も考えずにGHECを使うとえらい目にあいます。

安易に移行する前に、一度立ち止まって以下の内容を読んでみてください。GHECがダメだというつもりは全くありませんが、メリットしか見えていない状態で飛びつくとあとから苦労するよ、という話です。

「クラウド版はGitHub社にソースコードを預けることになるから云々」「github.comに障害が発生したら云々」みたいなクラウドあるあるではありません。

安易にForkを許可するとセキュリティー面で問題が出る

GHECでは、リポジトリーのフォークを許可するかどうかを選べる設定があります。しかし、ちょっと手元で変更を試してみたいとか、新人研修用のリポジトリを各自のアカウントで解いてほしい等の理由でフォークを許可したい場合があると思います。

ところで、GHECにはSSOにより組織アカウントへの安易なアクセスを制限できる機能があります。
詳細はこちらの記事が詳しいので読んでいただきたいのですが、このようにSSOでセキュリティーを高めても、個人アカウントにforkされてしまっては意味がありません。

別の組織（例えばfooに対してfoo-devなど）を作成して、フォーク先は個人リポジトリではなくfoo-devしか選べないようにするといった設定があればいいのですが、現在のところそういった設定はできないようです。
ただ、他の企業からもこの機能のリクエストはあるようなので、もしかしたらそのうち実装されるかもしれません。

現時点でどうしてもフォーク先を制限したいのなら、組織で使うための個人アカウントを発行するしかありません。
ただし、以前の記事で書いたとおり、規約上は無料アカウントは1人につき1つしか取得してはいけないので、組織用のアカウントは有料アカウントにする必要があります。

そもそも同一人物が複数のアカウントを使うケースはGitHub社としては想定していないそうですが。

名前空間が全世界で共有されている

GHESでは、アカウント名や組織名は自由に作成できました。しかし、GHECでは名前空間を世界中で共有しているので、すでに取られているものは取得できません。

そのため、例えば組織名を2つも3つも取得したい場合は他とかぶらないようにプレフィックスをつける必要があります。

また、組織名自体を外部から不可視状態にすることもできません。

アカウントと従業員の対応付けがしづらい

アカウントを本名で登録していたり、本名が推測できるようなアカウント名ならいいのですが、そうでない場合はpull requestやissueについた名前を見て「こいつ誰だ」となる場合も少なくありません。

「何十人規模の開発チームならともかく、数人レベルなら覚えておけよ」という意見もあるかもしれませんが、数人レベルでも新入社員にとっては大変ですよ。

ただでさえ覚えることが多い上に、チームメンバーの顔と名前を一致させないといけない挙げ句、GitHubのIDと本人まで対応付ける必要まで出てくるので。

CDによるデプロイにはセキュリティー面で注意が必要

もはやリリースを自動的に行うことは珍しくも何でもありません。現在はリリースの自動化のためにGitHub Actionsという便利な機能が実装されているので、例えばリリースタグを作成したら自動的にウェブサービスが最新版になるといった設定もできます。

しかし、GitHub Actionsを使ってデプロイする場合、公開ネットワークを通じて行うことになるのでその点は注意が必要です。

デプロイ先のサーバー側でアクセス元の制限を行おうにも、GitHub Actionsに使われるVMはAzure上に作成され、そのIPアドレスはとても広く、かつ定期的に更新されるので制限は難しいのです。

Install SSH Keyで提案しているのは、踏み台サーバー経由でrsyncを使う方法。不正なアクセスがあったら踏み台サーバーを落とせばいいのでまだ対応が楽です。

あるいは、GitHubからのpush型のデプロイではなく、社内サーバーにJenkins等を導入してpull型のデプロイを構成してみるのもいいかもしれません。

GitHub Pagesが全世界に公開される

内部で使うAPIドキュメント等をGHES上にGitHub Pagesで作っていた場合は要注意です。
privateリポジトリーであってもGitHub Pagesはインターネット上に公開されてしまうので、思わぬ機密情報が漏れてしまう可能性があります。

外部からリンクを張っていなければ検索エンジンにインデックスされる可能性は低いですが、安全にいくなら社内用のサーバーに転送したほうがいいです。

---

以上、GHECで開発する場合の注意点を5つほど挙げてみました。

安易に移行を決める前に、上記の問題それぞれに対して適切な運用ができるかを一度検討してみてはいかがでしょうか。