Ubuntu 22.04でセルフホストランナーを使用してGitHub継続的インテグレーションパイプラインをセットアップする方法。

はじめに

ソフトウェアエンジニアリングは、ペースが速く競争の激しい分野です。製品をより早くユーザーに提供することは、競合他社に対して優位に立つことにつながります。明るい兆しとして、企業が公平な競争環境を持てるよう、業界のベストプラクティスが確立されています。

継続的インテグレーションと継続的開発（CICD）は、業界のベストプラクティスを活用して、この競争の激しい分野で企業に優位性をもたらす戦略の一例です。

バージョン管理ツールであるGitを備えたウェブベースのリポジトリであるGitHubは、ソフトウェア開発者、エンジニア、アーキテクトがCI/CDを実装することを可能にします。継続的開発（CD）とは、ビルド、テスト、デプロイを自動化する手法です。継続的インテグレーション（CI）により、多くの人が同じプロジェクトで共同作業を行い、マージ衝突を心配することなくコードが動作していることを確認できます。

GitHub Actionsを使用すると、ビルド、テスト、デプロイを自動化するステップを記述できます。

このチュートリアルでは、GitHub Actionsを使用して継続的インテグレーションを設定する方法を学びます。まず、コードをホストするためのGitリポジトリを設定することから始めます。次に、コードの変更を監視し、テストを実行するためのCIランナーを起動し、アプリケーションをビルドしてNginxが動作しているUbuntu 22.04サーバーにデプロイするGitHub CIプロセスを設定します。

前提条件

このチュートリアルを進めるには、以下が必要です。

• Ubuntu 22.04を実行しているサーバー。このチュートリアルに従って、初期のUbuntuサーバー設定, non-rootユーザーの追加、およびUbuntuのUFWファイアウォールの有効化.

• サーバーにNode.jsがインストールされている必要があります（バージョン14以上を推奨）。以下のチュートリアルを用意しています：UbuntuにNode.jsをインストールする方法.

• Nginxサーバーソフトウェアがインストールされている必要があります。以下のガイドを用意しています：Ubuntuを実行しているサーバーにNginxをインストールする方法.

• DockerとDocker Composeがローカルマシンにインストールされている必要があります。隔離された開発環境を実行するためです。以下のチュートリアルに従って、Dockerのインストールと操作方法をクラウドで行う方法を学んでください。

必要なものがすべて揃ったので、始めましょう。

ステップ1. プロジェクトリポジトリのクローン

このチュートリアルは、以下をベースにしています：Reactjs（ユーザーインターフェースを構築するための宣言的なJavascriptライブラリ）。プロジェクトをゼロから新しくセットアップしたい場合は、こちらのReactアプリのセットアップに関するリソースを使用してください。簡潔にするため、GitHub上にすでにセットアップされているこのReact.js repoのクローンを使用します。

クローンするアプリケーションは、react-router 6と、React Testing Libraryによるテストを備えたシンプルなReactアプリケーションであり、DOMにアクセスするためのメソッドを提供します。

リポジトリをクローンするには、緑色のボタンをクリックしてURLをコピーします。

ワークスペースでターミナルを開き、以下のコマンドを実行してアプリをクローンします：

リポジトリをクローンしたら、プロジェクトディレクトリに移動します：

docker-compose up コマンドを実行して、アプリをビルドおよび実行します：

プロセスが完了したら、以下にアクセスしてください。 http://localhost:3000

以下のような画面が表示されるはずです：

ステップ2. Node.js.ymlファイルの理解

このステップでは、何が行われているかを理解しやすくするために、GitHubのYAMLファイル内のディレクティブを定義します。リポジトリ内には、次のディレクトリがあります。 .github/workflows。ここには、次のファイルが含まれています。 node.js.ymlファイル。このファイルには、GitHub上のコードリポジトリに変更をプッシュした後に、GitHubランナーが実行するワークフローのステップが記述されています。YAML構文は、GitHub Actionsのワークフローを記述するために使用されます。YAMLファイルの拡張子は、 yaml または yml.

次のファイルを開きます。 node.js.ymlファイル。内容は以下のようになっているはずです：

このチュートリアルを執筆している時点では、Node.js 16のバージョン16を使用していました。それでは、GitHub Actionsのワークフローを理解しましょう：

• name

name: cicd-tut

ワークフローの名前。この名前はリポジトリの Actions タブに表示されます。

• on

on はイベントを定義するために使用されます。イベントはワークフローを自動的にトリガーしたり、後で実行するようにスケジュールしたりできます。イベントは単一または複数にすることができ、特定のブランチ、タグ、またはファイルに対してワークフローの実行を指定することもできます。これはフィルターのように機能します。

YAMLファイルでは、以下のような自動の複数イベントを定義しています：

• コードがリポジトリにコミットされると、 push イベントがトリガーされます。

• mainブランチでプルリクエストが作成されると、 pull_request イベントがトリガーされます。

ワークフローの実行をそのブランチのみに制限するために、ブランチ名 main を指定しています。また、! フラグの後にブランチ名を続けることで、無視するブランチを指定することもできます。

• jobs

ワークフローは基本的に1つまたは複数のジョブで構成されています。これらのジョブは、最初から最後まで順番に実行されます。

各ジョブは、 runs-on で指定されたランナー環境で実行されます。ジョブは、 ubuntu-latest で表されるGitHubランナー、または self-hosted で表される self-hosted ランナーのいずれかで実行することを選択できます。選択は必要なジョブの数によって異なります。セルフホストランナーを使用すると、リソースの柔軟性と制御が向上します。

次のステップでは、まずGitHubランナーでジョブを実行し、その後、独自のサーバーにGitHubセルフホストランナーをセットアップします。

• strategy

Strategy（ストラテジー）を使用すると、単一のジョブ定義で変数を使用して、変数の組み合わせに基づいた複数のジョブ実行を自動的に作成できます。

YAMLファイルにはnode-versionの変数が1つありますが、次のようにNodeバージョン18の変数をもう1つ追加すると、 node-version: [16.x, 18.x]、マトリックスストラテジーは、Nodeバージョン16と18の両方に対して、Reactアプリケーションの2つのジョブ実行を作成します。

• steps

ステップは、ジョブを構成する一連のタスクです。ステップでは、コマンドの実行、タスクのセットアップ、パブリックリポジトリでのアクションの実行、またはDockerレジストリに公開されているアクションの実行が可能です。

ステップには名前があります。これは任意ですが、GitHub上に表示されるステップを簡単に識別できる名前を指定するために使用できます。

ステップでは、ジョブ内で実行するアクションを選択できます。アクションは再利用可能です。アクションを定義する際にアクションのバージョンを指定します。これは、アクションの所有者がアップデートを公開したときにワークフローが破損するのを防ぐために重要です。

上記のコードスニペットでは、 checkout@v3 は指定されたバージョンを持つアクションの例です 3。このアクションはリポジトリをチェックアウトし、ワークフローがリポジトリにアクセスできるようにします。

上記の actions/setup-node@v3 などの一部のアクションには、 with キーワードを使用して示される入力があります。setup node アクションは、Node バージョン 16 とキャッシュされる npm を必要とします。

• run

このアクションは、オペレーティングシステムのシェルを使用してコマンドラインプログラムを実行します。

上記のYAMLファイルには3つのコマンドがあり、すべてランナー環境の同じシェルを使用して実行されます。

• 最初のコマンド npm i は、React アプリケーションに必要なすべての依存関係をインストールします。

• 2番目の npm test は、作成したテストを実行します。テストは、テキスト learn react がホームページにレンダリングされることを期待します。

• 最後に、 npm run build コマンドは、アプリケーションのプロダクションビルドを含む build ディレクトリを作成します。後で、この build ディレクトリを Nginxサーバーブロックで使用します。.

ステップ3. GitHubランナーを使用したGitHub CIのテスト

このステップでは、GitHubランナーを使用して継続的インテグレーション（CI）プロセスをテストします。まず、 node.js.yml ファイルを開くことから始めます。アクションが実行されるランナーのタイプを ubuntu-latest に変更します。この目的は、独自のセルフホストランナーを設定する前に、GitHubワークフローがGitHubランナー上で完全に動作するかどうかをテストすることです。

お使いの GitHubアカウント に新しいリポジトリを作成します。続ける前に、ワークスペースディレクトリに戻り、 .git ディレクトリを削除してください。表示されない場合は、隠しファイルを確認してください。ターミナルで次のコマンドを使用してディレクトリを削除できます：

これで、すべてのプロジェクトファイルを git add し、コミットしてリポジトリにプッシュできます。行き詰まった場合は、プロジェクトフォルダをGitHubリポジトリに接続する ガイド（上記で作成したもの）を参照してください。

完了したら、リポジトリの Code タブをクリックします。総コミット数の横に小さなオレンジ色のドットが表示されます。それをクリックすると、以下のようなモーダルが表示され、ワークフローがキューに入っていることを示します：

次に、モーダルの Details リンクをクリックするか、 Actions タブに移動すると、 node.js.yml ワークフローの各ステップがGitHubランナーによって実行されているのを確認できます：

成功したら、 Actions タブをクリックします。次のようになっているはずです：

これで完了です。Codeタブの小さなオレンジ色のドットが緑色のチェックマークに変わっているはずです。GitHubランナーがアプリケーションのビルドに成功しました。

次に、さらに一歩進めて、独自の UbuntuサーバーインフラストラクチャでGitHubセルフホストランナーを使用するようにビルド環境を変更しましょう。.

ステップ4. セルフホストランナーを使用するためのGitHubワークフローの設定

サーバーにセルフホストランナーをインストールする前に、ワークスペースに戻り、 node.js.yml  ワークフローファイルを編集して、GitHubのセルフホストランナーで実行されるようにします。

この段階では、セルフホストランナーが定義されていないため、変更をコミットするとジョブはキューに入ります。

リポジトリで、 Settings タブをクリックし、左側のサイドバーで Actions をクリックしてから、 Runners をクリックします。:

Click New self-hosted runner をクリックし、オペレーティングシステムとして Linux を選択します。

ランナーをダウンロードしてサーバーにインストールする方法を示す手順が表示されます。

ステップ5. サーバーへのGitHubセルフホストランナーのインストールと設定

このステップでは、セルフホストランナーをセットアップします。セルフホストランナーとは、GitHubウェブサイト上のGitHub Actionsからのジョブの実行をデプロイおよび管理できるシステムです。GitHubホストランナーに対するセルフホストランナーの利点の1つは、柔軟性です。オペレーティングシステム、ハードウェア、およびその他のツールをより詳細に制御でき、必要なアプリケーションのニーズに合わせてカスタマイズできます。

セルフホストランナーは、以下のようなさまざまなレベルで追加できます。

• リポジトリレベルのランナー：これらは単一のリポジトリ専用です。

• 組織レベルのランナー：これらは組織内の複数のリポジトリのジョブを処理できます。

• エンタープライズレベル：複数の組織に割り当てることができます。

続行するには、ssh経由でサーバーにログインします。

次のコマンドでホームディレクトリに移動します。

次に、以下の名前のディレクトリを作成します。 action-runners そして、その中に移動します。

次に、最新バージョンのランナーパッケージをダウンロードします。

次に、ダウンロードしたパッケージを以下のコマンドで解凍します。

リポジトリに戻り、 Settings タブの左側パネルで、 Actions、次に Runners をクリックします。これは ステップ 4.

セルフホストランナーをGitHubリポジトリにリンクするトークンを含むコマンドが表示されます。GitHubランナーのコードを解凍したディレクトリ内で、表示されたコマンドを使用してランナーをリンクします。例：

認証が成功するはずです：

Defaultランナーグループの場合は、そのままEnterキーを押します。

次に、ランナーの名前（例： my-runner）を入力し、Enterキーを押します。

追加のラベルの追加をスキップするにはEnterキーを押します。以下のスクリーンショットのような成功メッセージが表示されるはずです：

作業ディレクトリの名前（例： react-cicd）を入力します。成功すると、次のテキストが表示されます。 settings saved.

最後に、 ./run.sh を実行します。これにより、以下が表示されるはずです。 Connected to Github:

しかし、これはバックグラウンドでは実行されません。ターミナルで ctrl+c を入力するとランナーが停止してしまいます。ランナーをサービスとして実行し続け、対話を継続できるようにするために、これを .svc.sh サービスに置き換える必要があります。

ランナーを ctrl+c で停止します。次のコマンドを実行して .svc.sh サービスをインストールできます。

インストールが完了したら、次のコマンドでサービスを開始します：

成功すると、以下が表示されます。 active (running).

確認するために、 svc.sh サービスが起動して動作していることを確認するには、次のコマンドを実行します：

この時点で、セルフホストランナーを待ってキューに入れられていたワークフローは正常に実行されるはずです。ファイルを編集して試してみることもできます。たとえば、 概要.tsx ファイルを修正し、変更をコミットしてプッシュすると、セルフホストランナーがジョブを正常に完了します。

ステップ 6. Nginxサーバーブロックのセットアップ

このステップでは、Reactアプリケーションのビルドバージョンを表示するために、Nginxでサーバーブロックを設定します。参考になるチュートリアル「Nginxサーバーブロックのセットアップ」を用意しています。

以下は、このチュートリアルで使用するサーバーブロックの例です：

Nginxのサーバーブロック設定ファイルを、以下のディレクトリ内に作成します。 /etc/nginx/sites-available ディレクトリ。

次のコマンドを使用して、nanoエディタでサイトのサーバーブロック設定ファイルを開きます：

上で共有したサーバーブロックをコピーし、ご自身のディレクトリパスに合わせて変更した上で、開いたファイルに貼り付けます。編集が終わったら、 ctrl+x を押し、次に y と enter を押して保存し、終了します。

保存したら、次のコマンドを実行して、 react-cicd サーバーブロック設定のシンボリックリンクを /etc/nginx/sites-available から /etc/nginx/sites-enabled へ作成します：

変更を有効にするには、Nginxを再起動する必要があります。ただし、Nginxサービスを再起動する前に、次のコマンドを実行してNginxの設定が有効かどうかをテストしてください：

設定が正しい場合、テストは成功するはずです。

サーバーブロック内の server_name ディレクティブの値 “ react.test ” にお気づきでしょうか？この値をローカルマシンの hosts ファイルに追加します。これにより、ブラウザでアプリケーションを開くことができるようになります。このステップは、ローカル開発環境で使用される仮想ドメインにのみ必要です。サーバーのパブリックIPにリンクされた登録済みのドメイン名がある場合は、すでにブラウザからそのドメイン名にアクセスできるはずです。

ローカルマシンで、次のコマンドを使用してhostsファイルを開きます：

hostsファイル内に、サーバー of IPアドレス（例： 127.0.0.1）を追加し、その後に仮想ドメイン名を記述します。

以下に例を示します。その後、ファイルを閉じて保存します：

サーバーに戻り、 /var/www ディレクトリ内に、次のコマンドを実行して新しいディレクトリ（「react-cicd」など）を作成します：

この段階で、 node.js.yml ファイルの最後のコマンドのコメントアウトを解除します。

このコマンドは、前の ステップ 5.

でactions-runnerディレクトリ内に指定したワークフォルダからReactアプリケーションのビルドフォルダをコピーし、 public フォルダを /var/www/react-cicd ディレクトリに配置します。

これで、サーバーブロックがアプリにアクセスし、ブラウザに表示できるようになります。

最後に、次のコマンドでNginxサービスを再起動します：

これで、 概要.tsx ファイルを変更し、変更をコミットしてリポジトリにプッシュできます。ビルドが成功すると、 http://react.test または指定したドメイン名で、Reactアプリのビルドバージョンを確認できます。すでに作成されたテストが失敗する可能性があるため、 href 要素（ Home.tsx ファイル内）の編集は避けてください。リポジトリの Actions タブにも、完了したジョブのビルドが表示されるはずです。

まとめ

Github Actionsを使用した継続的インテグレーションには、優れた開発者体験、継続的なテストのサポート、大規模なチームでのコラボレーションの容易化、開発時間の短縮、新機能の迅速なリリース、リアルタイムのフィードバック、顧客満足度の向上など、競合他社に対して優位に立てる多くのメリットがあります。この知識をさらに深めるために、以下について学ぶのもよいでしょう： Ubuntu上でのGitLab継続的インテグレーション（CI）パイプラインのセットアップ、およびセルフマネージドGitLabインスタンスを使用したDockerイメージのホストとプライベートビルドの実行。

ハッピーコンピューティング！