GitHub Actionsのself-hosted runnersをVPSで動かしてCI / CDパイプラインを作る (今どきVPS構築2020年版)

## 背景
5年前に建てたVPSサーバが老朽化。老朽化というよりここ数年全くさわっていなくて忘れて中身がわからなくなってメンテできない状態になっている。
いろいろ問題点が出てきたが対応できてない。
綺麗にするため一度VPSを一からたてなおしたいが、Jenkinsを使っている部分の移行が面倒くさそう。
github actionsを活用してjenkinsを廃止したら意外にシンプルで今どきの構成になったので、事例として共有しようと思いました。

## Before
Webサーバがたっていて、jenkinsサーバをたててデータ更新batchを配下で実行管理する構成

![vps_github_actions_before.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/116075/98a4cc5e-3e5e-aed4-8e60-d5034076bd2c.png)


## 問題点
- 今建っているVPSはUbuntu14.04。古いのでUbuntu20.04にあげたい。
- まだpython2。Ubuntu14.04でpython3系の新しいversion入れるの面倒。
- いろいろなお試しをしていたので、ゴミファイルがたまっている。よくわからないので一回今たっているVPSサーバを捨てたい。
- 一から建て直したいがJenkinsまわりの移行が面倒くさそう。セットアップもはまりそうなので、建て直しに二の足を踏んでしまう。
- local開発環境は以前windows上に構築したが、windows7から10にアップデートしてから全く動かしてないので動くかどうか。ubuntuとwindowsでOS違いで環境たてているので環境差分があるのもいけてない。

## 5年前との環境の変化
- githubでprivateリポジトリを作れるようになった（あえて今bitbucketを使う理由がなくなった)
- gihtub actionsという便利なCI/CDツールが出てきて、しかも無料で使える
- vscode remoteが便利で、あえてlocal pc上にテスト環境を作る必要がない


## 改修方針

**ダーウィン『最も強い者が生き残るのではなく、最も賢い者が生き延びるのでもない。唯一生き残ることが出来るのは、変化できる者である。』**

- Jenkinsは廃止して、データ更新batchの定期実行をgithub actionsに引っ越す
- VPSをgithub actionsのself hosted runnerとして登録する (jenkins slaveのように扱えるので便利です)
- frontとbatchでわかれていたリポジトリを統合し、さらにBeforeでjenkinsの設定部分だった定期実行の設定をgithub actionsのworkflowの設定ファイルにして、あわせてbitbucketから引っ越ししてgithubで一つのリポジトリにまとめる
- local開発環境もVSCode remoteに移行し実環境はVPSに引っ越し

## After

![vps_github_actions_after.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/116075/895bab38-93a6-151f-f70b-a33b2db03e0c.png)

## github workflow設定ファイル

### Masterマージ
`.github/workflows/restart_service_on_push_main.yml`

```
name: restart_servcie_on_push_main

on:
  push:
    branches: [main]
    paths:
      - '.github/workflows/restart_service_on_push_main.yml'
      - 'infra/resources/**'

jobs:
  build:
    runs-on: [self-hosted]
    steps:
      - uses: actions/checkout@v2
      - name: restart servcie
        run: |
          sudo rm -rf /usr/share/nginx/public
          sudo cp -R infra/resources/usr/share/nginx/public /usr/share/nginx/public
          sudo cp infra/resources/etc/nginx/sites-available/default /etc/nginx/sites-available
          sudo service nginx restart
          sudo cp infra/resources/etc/supervisor/conf.d/* /etc/supervisor/conf.d
          sudo supervisorctl reread
          sudo supervisorctl update
          sudo supervisorctl restart all
```

### batch cron定期実行
`.github/workflows/cron_weekday_19.yml`

```
name: cron_weekday_19

on:
  schedule:
    - cron: '50 9 * * 1-5'

jobs:
  build:
    runs-on: [self-hosted]
    steps:
      - uses: actions/checkout@v2
      - run: ./infra/cron/batch19.sh
```

## まとめ

### よかった点
- Afterのぽんち絵はあまりすっきりした感じがしないですが、多分私の絵の描き方が悪いだけで、Jenkinsがなくなってイミュータブルになりだいぶすっきりしました (jenkins動かすとメモリ消費するのでその分のメモリが開放されるのも嬉しいです)
- バッチのcron定義やシェル部分がgithubの同一リポジトリ内でyamlの定義ファイルとして管理されてわかりやすくなりました(jenkinsの場合はサーバに入って確認)
- github actionsのself hosted runnerとしてVPSを登録すると、いくらgithub actionsを動かしても無料。実行結果もjenkinsと比べても見劣りせずわりと見やすいです
- githubのmasterマージで、supervisordやnginxの再起動させるのもgithub actionsの機能そのままつかえばよく、一行再起動のコードを書くだけなので、簡単わかりやすい
- github actionsとVSCode remoteを使うことで、今どきな構成になったと思います
- windowsベースのlocal実行環境がなくなり、ローカル環境とサーバ環境の差異がなくなった

### 課題
- python部分はvenvでlocal環境と本番環境で別versionにできますが、aptで更新するようなモジュールはlocal環境と本番環境が同じになるなので、割り切った分逆に運用が難しくなる局面もあるかも

VPSの契約期間の関係でまだ建て直していなくてUbuntu14のままですが、イミュータブルじゃない部分はsqlite3のデータの部分ぐらいなので、比較的簡単にUbuntu20に建て直しできると思っています。
(建て直す時は、今のVPSサーバはそのままで、新しいサーバを建てて構築完了したら、self hosted runnerの登録を新サーバに変えて旧サーバ廃止する予定です)