Azure VMware Solution での GitHub Enterprise Server の設定

この記事では、Azure VMware Solution のプライベート クラウドに GitHub.com の "オンプレミス" バージョンである GitHub Enterprise Server を設定する方法について説明します。 ここで取り上げるシナリオは、GitHub Actions で 1 分あたり最大 25 個のジョブを実行する、最大 3,000 人の開発者にサービスを提供できる GitHub Enterprise Server インスタンスです。 これには GitHub Actions などの "プレビュー" 機能 (本書の執筆時点) の設定が含まれます。 特定のニーズに合わせて設定をカスタマイズするには、「VMware への GitHub Enterprise Server のインストール」に記載されている要件をご確認ください。

開始する前に

GitHub Enterprise Server には有効なライセンス キーが必要です。 評価版ライセンスにサインアップできます。 統合によって GitHub Enterprise Server の機能を拡張する場合は、接続クライアント 5 人分の開発者ライセンスを無料で利用できるかどうかを確認してください。 GitHub のパートナー プログラムを通じてこのライセンスにお申し込みください。

VMware への GitHub Enterprise Server のインストール

1. VMware ESXi/vSphere (OVA) 用の GitHub Enterprise Server の最新リリースをダウンロードし、ダウンロードした OVA テンプレートをデプロイします。

   

   

2. 新しい仮想マシンに、GitHubEnterpriseServer などの分かりやすい名前を付けます。 インスタンスをアップグレードするとリリースの詳細が古くなるため、この詳細を VM 名に含める必要はありません。

3. ここではすべての既定値を選択し (詳細は後で編集します)、OVA がインポートされるまで待ちます。

4. インポートしたら、必要に応じてハードウェア構成を調整します。 このシナリオの例では、次の構成が必要です。

   リソース	標準セットアップ	標準セットアップ + "ベータ機能" (Actions)
   vCPU 数	4	8
   メモリ	32 GB	61 GB
   ストレージの接続	250 GB	300 GB
   ルート ストレージ	200 GB	200 GB

   実際のニーズは異なる場合があります。 「VMware への GitHub Enterprise Server のインストール」のハードウェアの考慮事項に関するガイダンスをご覧ください。 また、「VMware の CPU リソースまたはメモリ リソースの追加」を参照して、状況に応じてハードウェア構成をカスタマイズしてください。

GitHub Enterprise Server インスタンスの設定

新しくプロビジョニングされた仮想マシン (VM) の電源がオンになったら、ブラウザーを使用して構成します。 ライセンス ファイルをアップロードし、管理コンソールのパスワードを設定する必要があります。 このパスワードは安全な場所に書き留めてください。

少なくとも次の手順を実行することをお勧めします。

1. 管理コンソールに公開 SSH キーをアップロードして、SSH 経由で管理シェルにアクセスできるようにします。

2. お使いのインスタンスの TLS を構成して、信頼された証明機関によって署名された証明書を使用できるようにします。 設定を適用します。

   

3. インスタンスが再起動されている間に、GitHub Actions 用の BLOB ストレージを構成します。

   Note

   GitHub Actions は、GitHub Enterprise Server リリース 2.22 の制限付きのベータ版が現在提供されています。

   GitHub Enterprise Server で GitHub Actions を有効にするには(現在は "ベータ" 機能として利用可能)、外部 BLOB ストレージが必要です。 Actions では、この外部 BLOB ストレージを使用して成果物とログを格納します。 GitHub Enterprise Server での Actions では、記憶域プロバイダーとして Azure Blob Storage (およびその他) がサポートされます。 BlobStorage というストレージ アカウントの種類を使用して、新しい Azure ストレージ アカウントを作成する必要があります。

   

4. 新しい BlobStorage リソースのデプロイ完了後、([アクセスキー] の下にある) 接続文字列を後で使用するために保存します。

5. インスタンスが再起動したら、インスタンスの新しい管理者アカウントを作成します。 このユーザーのパスワードもメモしておいてください。

   

その他の構成手順

実稼働環境で使用するためにインスタンスを強化するには、次のオプションのセットアップ手順を実行することをお勧めします。

1. 次に対する保護のために高可用性を構成します。

   • ソフトウェアのクラッシュ (OS またはアプリケーション レベル)
   • ハードウェア障害 (ストレージ、CPU、RAM など)
   • 仮想化ホスト システムの障害
   • ネットワークの論理的または物理的な切断

2. バックアップ ユーティリティを構成して、プライマリ インスタンスとは別の可用性でホストされる、ディザスター リカバリーのためのバージョン管理されたスナップショットを用意します。

3. 有効な TLS 証明書を使用してサブドメインの分離を設定し、クロスサイト スクリプティングやその他の関連する脆弱性を軽減します。

GitHub Actions ランナーの設定

Note

GitHub Actions は、GitHub Enterprise Server リリース 2.22 の制限付きのベータ版が現在提供されています。

この時点で、管理者アカウントが作成された、GitHub Enterprise Server のインスタンスが実行されている必要があります。 また、GitHub Actions による永続化に使用される外部 BLOB ストレージも必要です。

Azure VMware Solution を使用して GitHub Actions を実行するための場所を作成します。

1. Ubuntu Server の最新リリースに基づいて、クラスターで新しい VM をプロビジョニングします。

   

2. セットアップを続けて、コンピューティング リソース、ストレージ、互換性を選択します。

3. VM にインストールするゲスト OS を選択します。

   

4. VM が作成されたら、電源を入れて SSH 経由で接続します。

5. GitHub Actions ワークフローからジョブを実行する Actions ランナー アプリケーションをインストールします。 リリース ページ で、または次のクイック スクリプトを実行して、Actions ランナーの最新の Linux x64 リリースを特定し、ダウンロードします。 このスクリプトでは、curl と jq の両方が VM 上に存在している必要があります。

   LATEST\_RELEASE\_ASSET\_URL=$( curl https://api.github.com/repos/actions/runner/releases/latest | \
   
   jq -r '.assets | .[] | select(.name | match("actions-runner-linux-arm64")) | .url' )
   
   DOWNLOAD\_URL=$( curl $LATEST\_RELEASE\_ASSET\_URL | \
   
   jq -r '.browser\_download\_url' )
   
   curl -OL $DOWNLOAD\_URL
   

   これで、お使いの VM のローカルにファイル actions-runner-linux-arm64-*.tar.gz が作成されました。 この tar をローカルに抽出します。

   tar xzf actions-runner-linux-arm64-\*.tar.gz
   

   この抽出によって、config.sh や run.sh スクリプトなど、いくつかのファイルがローカル環境にアンパックされます。

GitHub Actions の有効化

Note

GitHub Actions は、GitHub Enterprise Server リリース 2.22 の制限付きのベータ版が現在提供されています。

GitHub Enterprise Server インスタンスで GitHub Actions を構成して有効にします。

1. GitHub Enterprise Server インスタンスの管理シェルに SSH 経由でアクセスし、次のコマンドを実行します。

2. BLOB ストレージの接続文字列が含まれる環境変数を設定します。

   export CONNECTION\_STRING="<your connection string from the blob storage step>"
   

3. Actions のストレージを構成します。

   ghe-config secrets.actions.storage.blob-provider azure
   
   ghe-config secrets.actions.storage.azure.connection-string "$CONNECTION\_STRING`      
   

4. 設定を適用します。

   ghe-config-apply
   

5. 事前チェックを実行し、GitHub Enterprise Server で Actions に必要な追加のソフトウェアをインストールします。

   ghe-actions-precheck -p azure -cs "$CONNECTION\_STRING"
   

6. Actions を有効にして、構成を再適用します。

   ghe-config app.actions.enabled true
   
   ghe-config-apply      
   

7. BLOB ストレージの正常性を確認します。

   ghe-actions-check -s blob
   

   Blob Storage is healthy (BLOB ストレージは正常です) という出力が表示される必要があります。

8. GitHub Actions が構成されたので、ユーザーに対してそれを有効にします。 GitHub Enterprise Server インスタンスに管理者としてサインインし、任意のページの右上隅にある を選択します。

9. 左側のサイドバーで、[Enterprise overview] を選択してから、[Policies]、[Actions] の順に選択し、すべての組織に対してアクションを有効にするオプションを選択します。

10. [Self-hosted runners]\(セルフホステッド ランナー\) タブでランナーを構成します。[Add new]\(新規追加\) を選択し、ドロップダウンから [New runner]\(新しいランナー\) を選択します。 実行するコマンドのセットが表示されます。

11. コマンドをコピーしてランナーを構成します。次に例を示します。

    ./config.sh --url https://10.1.1.26/enterprises/octo-org --token AAAAAA5RHF34QLYBDCHWLJC7L73MA
    

12. config.sh コマンドをコピーし、お使いの Actions ランナーのセッション (以前に作成したもの) に貼り付けます。

    

13. ランナーを "実行する" には、./run.sh コマンドを使用します。

    ヒント

    このランナーを企業内の組織で使用できるようにするには、その組織のアクセス権を編集します。 組織のサブセットや、さらには特定のリポジトリだけに、アクセスを制限することもできます。

    

(省略可能) GitHub Connect の設定

この手順は省略可能ですが、GitHub.com で提供されているオープンソース アクションを使用する予定の場合にお勧めします。 これにより、これらの再利用可能なアクションをワークフロー内で参照することによって、他の人の作業に基づいて構築できます。

GitHub Connect を有効にするには、「GitHub Connect を使用した GitHub.com アクションへの自動アクセスを有効にする」の手順に従います。

GitHub Connect が有効になったら、[Server can use actions from GitHub.com in workflow runs] オプションを選択します。

最初のワークフローの設定と実行

Actions と GitHub Connect が設定されたので、このすべての作業を有効に利用してみましょう。 次に示すのは、優れた octokit/request-action を参照し、GitHub Actions で動作する GitHub API を使用した対話によって GitHub を "スクリプト化" できるワーフクローの例です。

この基本的なワークフローでは、octokit/request-action を使い、API を使用して GitHub で issue を開きます。

Note

GitHub.com はアクションをホストしますが、GitHub Enterprise Server 上で実行される場合は、GitHub Enterprise Server API を "自動的に" 使用します。

GitHub Connect を有効にしないことを選択した場合は、次の代替ワークフローを使用します。

1. お使いのインスタンスのリポジトリに移動し、上記のワークフローを次のように追加します。.github/workflows/hello-world.yml

   

2. リポジトリの [Actions] タブで、ワークフローが実行されるまで待ちます。

   

   それが処理されるのを確認できます。

   

すべてが正常に実行されると、リポジトリに "Hello world" という新しい問題が表示されます。

おめでとうございます。 Azure VMware Solution のプライベート クラウドで実行されている GitHub Enterprise Server 上の最初のアクション ワークフローを完了しました。

この記事では、Azure VMware Solution のプライベート クラウド上に、GitHub.com のセルフホスト型に相当する、GitHub Enterprise Server の新しいインスタンスを設定しました。 このインスタンスには、GitHub Actions のサポートが含まれており、ログと成果物を保持するために Azure Blob Storage を使用します。 しかしながら、ここまでは、GitHub Actions でできることをほんの少し学んだだけです。 GitHub の Marketplace で Actions の一覧を確認したり、独自に作成したりしてください。

次のステップ

ここまでで、Azure VMware Solution のプライベート クラウドでの GitHub Enterprise Server のセットアップについて説明しました。次は、以下の内容について説明します。

• GitHub Actions を開始する方法
• ベータ プログラムに参加する方法
• GitHub Enterprise Server の管理