【Git Hub】GitHub Actionsとは

はじめに

今回、Webアプリケーション作成後、アプリケーションを継続運用するために必要な知識である「Git Actions」について解説していく。本記事を読んで頂くことで、AWS（Cloud9）でアプリケーションを作成・編集し、ターミナルからGit pushを行うだけで、本番環境へのデプロイが自動で完了することができるようになる。

GitHub Actionsとは

【GitHub Actionsとは】
・GitHub Actionsの設定を終えれば、対象のブランチにpushするだけで、開発環境の差分をリモート環境へ反映できるようになる。
・デプロイを終えたアプリケーションに変更を加えた場合に、その差分を本番環境に取り込み、反映させるまでをGitHub Actionsを使って自動化できる。
・CI/CDツールとも呼ばれる。

CI/CDとは

【CI/CD（継続的インテグレーション／継続的デリバリー）とは】
・Continuous Integration（継続的インテグレーション）/ Continuous Delivery（継続的デリバリー）の略称。
・何か特定の技術を指すものではなく、ソフトウェアの変更を常にテストし、自動で本番環境に適用できるような状態にしておく開発手法のこと。

CI（継続的インテグレーション）とは

・Integration＝「完成・統合」という意味がある通り、継続的および定期的にソースコードの変更をビルドおよびテストしてリポジトリに統合する（完成させておく）。
・ソースコードをマージするタイミングなどで継続的にテストなどを自動実行する仕組みのこと。
・CIを用いることで手作業でテストせずに済む。

CD（継続的デリバリー）とは

・Delivery＝「届ける」と言う意味がある通り、ユーザーに継続的にアプリケーションを提供する（届ける）ために、CIでテストして検証したコードをリポジトリへリリースすることを自動化する。
・テストやビルドを行い、本番環境やステージング環境などへのデプロイまで行う仕組みのこと。
・CDを用いることで、最新版のアプリケーションが常にデプロイされている状態になる。

DevOps（デブオプス）とは

・開発の運用と統合すること。開発 (Development) と運用(Operations) の境目をなくし両担当者が連携して協力していこうという考え方・仕組みのこと。
・現在は、開発チームと運用チームが協力しながら開発を進めていくのが主流。
・アジャイル開発に似ているが、アジャイル開発は開発プロセスに主眼を置くが、DevOpsは開発と運用の一体化を重視している。
・CI/CDとの違いは、CI/CDは開発プロセスの一部を自動化するツールセットであり、DevOpsはそれを含む開発と運用全体の協力強化を目指す考え方であるということである。
・DevOpsは「考え」、CI/CDは「手段」。

GitHub Actionsを設定する

1.Git Hub(https://github.com/)へログインし、CI/CD対象のアプリケーションのリポジトリ画面の「Settings」をクリックする。

2.「Secrets and variables」内で「Actions」を選択し、選択した後に出てくる右の画面で「New repository secret」をクリックする。

3.HOST_NAME（サーバー(EC2)のパブリックIPアドレスの指定）を登録する。

4.USER_NAME（サーバー（EC2）のユーザーネーム(=ec2-user)）を登録する。

5.PRIVATE_KEY（サーバーの秘密鍵）を登録する。

ターミナル（cloud9）

cat ~/.ssh/id_rsa

上記出力結果の-----BEGIN RSA PRIVATE KEY-----から-----END RSA PRIVATE KEY-----までのコピーして、GitHubのSecretのPRIVATE_KEYに張り付ける。

6.3つのキーが正しく登録できているか確認する。

ワークフローを作成する。^[1]

ワークフローとは、1 つ以上のジョブを実行する構成可能な自動化プロセスです。 ワークフローは、リポジトリにチェックインされる YAML ファイルによって定義され、リポジトリ内のイベントによってトリガーされたときに実行されます。また、手動でトリガーしたり、定義されたスケジュールでトリガーしたりすることもできます。
ワークフローはリポジトリ内の .github/workflows ディレクトリで定義され、リポジトリには複数のワークフローを含めることができます。各ワークフローは、それぞれ異なる一連のタスクを実行できます。 たとえば、あるワークフローでは、pull request をビルドしてテストし、別のワークフローでは、リリースが作成されるたびにアプリケーションをデプロイし、さらに別のワークフローでは、新しい issue が開かれるたびにラベルを追加することができます。

GitHub Actionsのワークフローのファイル形式はYAML形式で記載しなければならない。

YAMLファイルの記載例

name: learn-github-actions
run-name: ${{ github.actor }} is learning GitHub Actions
on: [push]
jobs:
  check-bats-version:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm install -g bats
      - run: bats -v

7.CI/CDを用いたいアプリケーションフォルダの配下に、.githubフォルダを作成する。

8..githubフォルダ内にworkflowsフォルダを作成し、その配下にrails.ymlファイルを作成する。

9.rails.ymlファイル内に下記コードを追加する。

アプリケーション名/.github/workflows/rails.yml

<!-- ワークフロー名（任意） -->
name: Rails CI/CD 

<!-- GitHubのイベントの指定（mainのブランチにプッシュされた時） -->
on:
  push:
    branches: [main]

<!-- 処理の単位 -->
jobs:
<!-- ジョブ名（任意） -->
  build:
<!-- 処理を実行する環境を指定（GitHub Actioon用の仮想環境が立ち上がる） -->
    runs-on: ubuntu-latest
<!-- 処理の詳細 -->
    steps:
    - uses: actions/checkout@v2
    - name: Deploy
      env:
        PRIVATE_KEY: ${{ secrets.PRIVATE_KEY }}
        USER_NAME: ${{ secrets.USER_NAME }}
        HOST_NAME: ${{ secrets.HOST_NAME }}
      run: |
        echo "$PRIVATE_KEY" > private_key && chmod 600 private_key
        ssh -o StrictHostKeyChecking=no -i private_key ${USER_NAME}@${HOST_NAME} 'cd アプリケーション名 &&
        git pull origin ブランチ名 &&
        ~/.rbenv/shims/bundle install &&
        ~/.rbenv/shims/bundle exec rails assets:precompile RAILS_ENV=production &&
        ~/.rbenv/shims/bundle exec rails db:migrate RAILS_ENV=production &&
        if [[ -e tmp/pids/puma.pid ]];then sudo kill $(cat tmp/pids/puma.pid); echo kill puma process;fi &&
        ~/.rbenv/shims/rails s -e production'

「アプリケーション名」「ブランチ名」は、ご自身の環境に合わせて変更する。

完成図

鍵の設定を行う

10.公開鍵をサーバー（EC2）へ送る。（GitHub Actionsは仮想環境内からEC2サーバーに接続する必要があるため）

ターミナル（公開鍵をサーバー（EC2）へ送る）

 scp -i ~/.ssh/practice-aws.pem ~/.ssh/id_rsa.pub ec2-user@ipアドレス:.ssh/id_rsa.pub

ターミナル（出力結果）

a.pub
id_rsa.pub              100%  439   333.0KB/s   00:00  

id_rsaとid_rsa.pubとは

id_rsa （秘密鍵）
id_rsa.pub （公開鍵）

11.EC2サーバーにログインして、公開鍵をEC2サーバーに送る。

ターミナル（EC2サーバーへログイン）

ssh -i ~/.ssh/practice-aws.pem ec2-user@IPアドレス

ターミナル（公開鍵をEC2サーバーに送る）

cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

authorized_keysファイルとは

公開鍵を登録しておくファイルのこと。

Cloud9上の画面

ターミナル

ec2-user:~/environment (master) $ ssh -i ~/.ssh/practice-aws.pem ec2-user@18.・・・（←IPアドレス）
Last login: Thu May  2 11:06:31 2024 from 54.249.40.73
   ,     #_
   ~\_  ####_        Amazon Linux 2
  ~~  \_#####\
  ~~     \###|       AL2 End of Life is 2025-06-30.
  ~~       \#/ ___
   ~~       V~' '->
    ~~~         /    A newer version of Amazon Linux is available!
      ~~._.   _/
         _/ _/       Amazon Linux 2023, GA and supported until 2028-03-15.
       _/m/'           https://aws.amazon.com/linux/amazon-linux-2023/

38 package(s) needed for security, out of 52 available
Run "sudo yum update" to apply all updates.
[ec2-user@ip-172-31-40-223 ~]$ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
[ec2-user@ip-172-31-40-223 ~]$ 

12.EC2サーバーに公開鍵が登録されているかを確認する。確認が完了すれば、サーバーからログアウトする。

ターミナル（公開鍵がEC2サーバーに送られているか確認）

cat ~/.ssh/authorized_keys

:::deatails 確認のための出力結果

ターミナル

[ec2-user@ip-172-31-40-223 ~]$ cat ~/.ssh/authorized_keys
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIPcEgsuDZpzXAZEKsEg9JUpWHXdu+VWxXpO2FgIsZWr6 practice-aws
ssh-rsa AAA~~~~~~~~~~~Cl [e-mail]

ターミナル（サーバーからログアウトする）

exit

13.アプリケーションファイルに移動し、Gitでpushコマンドを実行して、Git Hubのリポジトリへ変更内容をPushする。

ターミナル（アプリケーションのディレクトリへ移動）

cd アプリケーション名

ターミナル（Git addコマンドを実行）

git add .

ターミナル(Git commitコマンドを実行）

git commit -m "コミットのコメント"

ターミナル(Git pushコマンドを実行）

git push 

Git Actionsが正しく動作しているか確認する。

14.Git Hub（ https://github.com/ )のアプリケーションリポジトリのActionsへ移動し、Git Actionsが正しく動作しているかを確認する。

15.EC2（ https://ap-northeast-1.console.aws.amazon.com/ec2 ）の起動しているインスタンスをクリックし、「オープンアドレス」をクリックし、アプリケーションが表示する。

16.変更箇所が反映されているかを確認する。

終わりに

お疲れ様でした。これで、アプリケーションを編集後、毎回EC2へログインして変更を反映する手間が省け、継続運用に集中できるようになると思います。修正等あればコメントよろしくお願い致します。

参考

https://www.sbbit.jp/article/cont1/81640

脚注

1. https://docs.github.com/ja/actions/using-workflows/about-workflows