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. アクションを有効にし、構成を再適用します。

   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 を "スクリプト化" できるワーフクローの例です。

この基本的なワークフローでは、API を使用して GitHub で問題を開くために使用 octokit/request-action します。

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 の管理