静的サイトジェネレーター（SSG）で作ったサイトをGitHub Actionsを使ってサーバに公開するところまでの手順をまとめます。
2~3年目の自分向けに詳細に書いてます。

![nuxt-hosting](/images/posts/260/nuxt-hosting.png)
▲ 構成の全体図。masterを更新したらGitHub actionsでビルドしてさくらのVPSにデプロイします。GitHub actionsからサーバへはrsyncで接続しているため、サーバにNodeがなくてもOK。サーバではNginxとLet's Encriptを利用して配信してます。

以上の構成を建てるところまで順に紹介していきます。

[Nuxtjs](https://ja.nuxtjs.org/)で作りましたが、[Next](https://nextjs.org/)や[Gatsby](https://www.gatsbyjs.com/)などのSSG、SPAも同様にデプロイできます。

また、サーバも[さくらのVPS](https://vps.sakura.ad.jp/)でなくEC2や他のサーバも大丈夫です。

初のCIなので不備があるかもしれません。ご指摘頂けるとありがたいです。

## Table of Contents

## デプロイするアプリの概要

今回は[Nuxt/content](https://content.nuxtjs.org/ja/)で作ったサイトをデプロイします。

- 完成品: <https://nuxt-content-sample.suzu6.net/>
- コード: [GitHub](https://github.com/suzu6/nuxt-content-sample)

デプロイで必要な実行するコマンド。

1. `yarn install`: 必要なnode_modulesを追加する。
2. `yarn lint`: Lintをチェック。
3. `yarn test`: Jetでユニットテスト。
4. `yarn generate`: 静的サイトを生成する。

yarnを利用している。`./dist`ディレクトリに生成されるので、これをサーバにアップロードする必要がある。また、`GENERATED_BY`という環境変数をトップページで使います。

サイトの作り方は[nuxt/contentでブログを作る](https://www.suzu6.net/posts/264-nuxt-content/)で紹介してます。

## rsync出来るようにサーバを設定する

GitHub actionsで生成したサイトをサーバに設置するのにrsyncを使います
（GitHub actionsのワークフローでmarketplaceの[ssh-deploy](https://github.com/marketplace/actions/ssh-deploy)を利用しており、その中でrsyncを利用している）。そのため、外部からrsync出来るようにサーバを設定します。SSHには公開鍵認証を利用します。

今回、さくらのVPSにCentOS7を建ててホスティングします。
5つの手順でrsync出来るところまでサーバをたてます。

1. さくらのVPSでCentOS 7を建てる
2. rsync用のユーザを追加
3. 公開鍵の作成と登録をする
4. sshd_configの設定
5. SSHのポート番号の変更

サーバにデプロイする設定までです。
別の記事でNginxとLet's Encriptの設定をします。

### 1. さくらのVPSでCentOS 7を建てる

さくらのVPSの概要は公式の[入門講座](https://vps.sakura.ad.jp/)を参照してください。
[ネコでもわかる！さくらのVPS講座 ～第二回「サーバーをさわってみよう！」](https://knowledge.sakura.ad.jp/8218/)で契約からSSH接続まで紹介されてます。

作成したユーザでSSHのパスワード接続が出来ていていればOK。
もしくはこれからの手順でユーザが追加できる。

### 2. rsync用のユーザを追加

rsync用のユーザを作成する。
ユーザグループとパスワードはsudo実行のために付けたが、設定が終われば外してよさそう。

```bash
## ユーザ追加
# useradd rsync_user
## ユーザグループに追加
# gpasswd -a rsync_user wheel
## パスワード設定
# passwd $user
```

`visudo`でrsyncするときroot権限で実行できるように設定する

```sh
# visudo

rsync_user ALL=(ALL) NOPASSWD:/usr/bin/rsync
```

※ 公開先のディレクトリのパーミッションをちゃんと設定すれば、root権限渡さなくても良いかも。

### 3. 公開鍵の作成と登録をする

rsync_userの公開鍵を作成します。

```bash
$ sudo su rsync_user
$ ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

# 次の二つが出来る。
# /home/rsync_user/.ssh/id_rsa
# /home/rsync_user/.ssh/id_rsa.pub　
```

[ssh-deploy](https://github.com/marketplace/actions/ssh-deploy)が対応していないため、パスフレーズは設定しない。
`id_rsa.pub`をこのユーザの公開鍵として、`id_rsa`がGitHub actionsに登録する秘密鍵とします。ローカルで鍵を作った方は適宜読み替えてください。

rsync_userの公開鍵を登録します。

```bash
# authorized_keysを作成
$ cd /home/rsync_user/.ssh/
$ cp id_rsa.pub authorized_keys

# 権限を変更
$ sudo chmod 700 /home/rsync_user/.ssh
$ sudo chmod 600 /home/rsync_user/.ssh/authorized_keys
```

`authorized_keys`が既に登録済みの場合は、末尾に公開鍵を追加する。
`.ssh`ディレクトリと`authorized_keys`の権限をそれぞれ`700`と`600`にする。

ここまでで、ssh接続ができるようになっているはず。

```bash
# サーバの中から
$ ssh rsync_user@localhost -i /home/rsync_user/.ssh/id_rsa

# ローカルのPCから
> ssh rsync_user@{サーバのIP・ホスト名} -i path/to/id_rsa
```

接続出来ない場合は`authorized_keys`の権限と`sshd`を確認する。
サーバの中からできて外部から出来ない場合は、さくらのVPSの場合[パケットフィルタ](https://manual.sakura.ad.jp/vps/network/packetfilter.html)のポートとIPを確認する。

参考: [お前らのSSH Keysの作り方は間違っている](https://qiita.com/suthio/items/2760e4cff0e185fe2db9#%E6%96%B0%E3%81%97%E3%81%84ssh-key%E3%81%AE%E4%BD%9C%E6%88%90)

```bash
rsync -avz rsync://rsync_user1@10.0.1.108/tmp /var/www/test
```

### 4. sshd_configを設定する

セキュリティを高めるための設定です。
rsyncに直接関係ないので後からでもよい。

まず、sshd_configをバックアップはしておく。消しちゃったら建て直せばいい。

```bash
cd /etc/ssh
sudo cp sshd_config sshd_config.org
```

`sshd_config`を編集する。

```bash
$ sudo vi sshd_config

PermitRootLogin no
PasswordAuthentication no
AuthorizedKeysFile .ssh/authorized_key
```

`PermitRootLogin no` はrootユーザでのログインを拒絶する。
`PasswordAuthentication no`はパスワードでのログインを拒絶する。
どちらもセキュリティを高めるための設定です。
`AuthorizedKeysFile .ssh/authorized_key`は公開鍵のパスを指定している。デフォルトで変更の必要ないはず。

sshdの設定を更新する。

```bash
$ sudo systemctl restart sshd
$ sudo systemctl status sshd
* sshd.service - OpenSSH server daemon
 Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled)
 Active: active (running) since Tue 2020-12-22 22:27:56 JST; 1 day 1h ago
 Docs: man:sshd(8)
 man:sshd_config(5)
 Main PID: 20149 (sshd)
 CGroup: /system.slice/sshd.service
 `-20149 /usr/sbin/sshd -D
```

参考: [ネコでもわかる！さくらのVPS講座 ～第二回「サーバーをさわってみよう！」](https://knowledge.sakura.ad.jp/8218/)

### 5. SSHのポート番号の変更

SSHのポートを2022に変更してみる。

```bash
$ sudo vi sshd_config
Port 2022
```

sshdの設定を更新する。

```bash
sudo systemctl restart sshd
```

ポートの変更では`firewalld`のsshの設定も変更します。

```bash
$ cd /usr/lib/firewalld/services/
# コピーする
$ sudo cp ssh.xml ssh.xml.org

# firewallの設定を変更する
$ vi /usr/lib/firewalld/services/ssh.xml
22 -> 1022
```

ポートを変更したら`firewalld`を再起動する。

```bash
$ sudo systemctl restart firewalld.service
success

$ sudo systemctl status firewalld.service
* firewalld.service - firewalld - dynamic firewall daemon
 Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2020-12-21 22:41:40 JST; 2 days ago
 Docs: man:firewalld(1)
```

ここまでで、22での接続が出来ず、2022での接続が確認できる。

```bash
# サーバの中から
$ ssh rsync_user@localhost -p 2022 -i /home/rsync_user/.ssh/id_rsa

# ローカルのPCから
> ssh rsync_user@{サーバのIP・ホスト名} -p 2022 -i path/to/id_rsa
```

参考: [CentOS 7 firewalld よく使うコマンド](https://qiita.com/kenjjiijjii/items/1057af2dddc34022b09e)

さくらのVPSの場合はパケットフィルタの設定も行う。

- カスタムTCP
- ポート: 2022
- すべて許可する

[Sakura VPS Docs パケットフィルタ](https://manual.sakura.ad.jp/vps/network/packetfilter.html)

## GitHub actions

[GitHub actions](https://github.co.jp/features/actions)のワークフローの設定と環境変数を設定します。

### ワークフローの設定

generateまではNuxt.jsのプロジェクトを作成したときに出来たワークフローです。
サーバへデプロイするところは、マーケットプレイスの[ssh-deploy](https://github.com/marketplace/actions/ssh-deploy)を利用しています。

[nuxt-content-sample/.github/workflows/ci.yml](https://github.com/suzu6/nuxt-content-sample/blob/master/.github/workflows/ci.yml)に全文があります。

理解したことをブロック単位で説明を添えてみます。

```yml:ci.yml
on:
 push:
 branches:
 - master
 pull_request:
 branches:
 - master
```

▲ トリガーとなる動作。masterへのプッシュとプルリクエストでCIが動き出す。ブランチごとにテスト用とか分けられる。

ワークフローの確認には手動で実行できる[workflow_dispatch](https://docs.github.com/ja/free-pro-team@latest/actions/reference/events-that-trigger-workflows#workflow_dispatch)もあるるようです。

```yml
jobs:
 ci:
 runs-on: ${{ matrix.os }}

 strategy:
 matrix:
 os: [ubuntu-latest]
 node: [14]
```

▲ ここからワークフローのジョブを定義する。`runs-on`で動作する環境を選ぶ。`Ubuntu`の最新版で`Node v14`の環境でビルドします。

```yml
 steps:
 - name: Checkout 🛎
 uses: actions/checkout@master
```

▲ リポジトリからチェックアウト。

```yml
 - name: Setup node env 🏗
 uses: actions/setup-node@v2.1.2
 with:
 node-version: ${{ matrix.node }}
```

▲ Nodeのバージョンを定義する。`strategy`でセットしたパラメータが使える。

```yml
 - name: Get yarn cache directory path 🛠
 id: yarn-cache-dir-path
 run: echo "::set-output name=dir::$(yarn cache dir)"

 - name: Cache node_modules 📦
 uses: actions/cache@v2
 id: yarn-cache # use this to check for `cache-hit` (`steps.yarn-cache.outputs.cache-hit != 'true'`)
 with:
 path: ${{ steps.yarn-cache-dir-path.outputs.dir }}
 key: ${{ runner.os }}-yarn-${{ hashFiles('**/yarn.lock') }}
 restore-keys: |
 ${{ runner.os }}-yarn-

 - name: Install dependencies 👨🏻‍💻
 run: yarn
```

▲ node-modulesのキャッシュを定義して、yarnでインストールする。
キャッシュがあると次回のビルドでnode-modulesのインストール時間を軽減できる。
初心者にこの設定を組むのは厳しいので、Nuxt.jsのプリセットが有って助かった！

```yml
 - name: Run linter 👀
 run: yarn lint

 - name: Run tests 🧪
 run: yarn test

 - name: Run generate
 run: yarn generate
```

▲ lintとテストとビルドを実行している。
lintとテストでエラーが出た場合はちゃんとワークフローも止まります。
ちゃんとプッシュする前に確認する習慣がつきそう。

```yml
 - name: Deploy to Server
 uses: easingthemes/ssh-deploy@v2.1.5
 env:
 SSH_PRIVATE_KEY: ${{ secrets.SERVER_SSH_KEY }}
 ARGS: "-rltgoDzvO --delete"
 SOURCE: "dist/"
 REMOTE_HOST: ${{ secrets.REMOTE_HOST }}
 REMOTE_USER: ${{ secrets.REMOTE_USER }}
 REMOTE_PORT: ${{ secrets.REMOTE_PORT }}
 TARGET: ${{ secrets.REMOTE_TARGET }}

```

▲ サーバへデプロイする[ssh-deploy](https://github.com/marketplace/actions/ssh-deploy)の処理です。
generateで生成した`./dist`ディレクトリ以下を`secrets.REMOTE_TARGET`に置きます。
サーバの`secrets.REMOTE_TARGET`のパスからNginxがホスティングしている。
`rsync`のコマンドを自由度高めに設定できる。

`secrets`はリポジトリで設定した環境変数です。${{ secrets.REMOTE_HOST }}`のようにして使えます。

<https://github.com/marketplace/actions/ssh-deploy>

- [GitHubの新機能「GitHub Actions」で試すCI/CD](https://knowledge.sakura.ad.jp/23478/)

### 環境変数を設定

ワークフローの中で利用できる環境変数は、リポジトリの`Setting`　→ `Secrets`　→ `New repository secret`から追加できる。

![secret](/images/posts/260/secret.png)

ワークフローでは${{ secrets.REMOTE_HOST }}`のように使える。

どうも`Environment secrets`と`Repository secrets`があって使い分け出来る。
`Repository secrets`の方が暗号化されていて個人ではリポジトリのオーナーだけ見られるようです。

[暗号化されたシークレット](https://docs.github.com/ja/free-pro-team@latest/actions/reference/encrypted-secrets)

## おわりに

以上でさくらのVPSにNuxt.jsの静的サイトをデプロイまでの手順を紹介しました。

１記事にまとめましたがかなり手順があって大変です。前回[NetlifyからVercelへの移行を検討した話](https://www.suzu6.net/)という話を書いた。Netlifyが遅い点をディスったが、Netlifyの無料で手軽にデプロイできるのは凄いことだなと改めて感じた。

マルチドメインで使えるようなNginxのバーチャルホストの設定や、Let’s EncriptでのSSL対応もしたのでこちらも記事にします。

とうとう自分のサーバを契約してブログだけでは持て余してしまう。
アプリを作りたいが、リソース管理やセキュリティの方面も学んでいきたい。
来年は使い倒していく。

GitHub Actionsで静的サイトジェネレーターをサーバにデプロイする

Markdownのリストで段組みを揃えて改行する方法が分かったので共有します。

- どういうことかというと 
こんな感じに
 - 段組みを揃えて 
改行できるよ

## 環境

確認できた対応している環境は以下の通り

- GitHub
- Qiita
- Visual Studio Code の [Markdown All in One](https://marketplace.visualstudio.com/items?itemName=yzhang.markdown-all-in-one)のプレビュー
- npm の [markdown-it](https://github.com/markdown-it/markdown-it)

恐らく他のMarkdown対応のエディタやサービスも書けると思います。

## 書き方

リストの行末に改行タグをつけて、次の行は素のテキストを書けばよいです。
改行タグは半角スペース二つ` `か、HTMLの改行タグの` `です。

例（半角スペースはわかりづらいので` `で）

```md
- リンゴ 
Apple
- オレンジ 
Orange
- イチゴ 
Strawberry
```

- リンゴ 
Apple
- オレンジ 
Orange
- イチゴ 
Strawberry


なぜこれで改行できるかと言うと、HTMLを見ると分かりやすいです。

```html
<ul>
 <li>リンゴ Apple</li>
 <li>オレンジ Orange</li>
 <li>イチゴ Strawberry</li>
</ul>
```

上のように`<li></li>`タグの中で改行コードがつくため、行頭を揃えて段組みできるようになります。

## その他にも使える

### 番号付きリスト

```md
> 1. 第一条 
> ロボットは人間に危害を加えてはならない。また、その危険を看過することによって、人間に危害を及ぼしてはならない。 
> 2. 第二条 
> ロボットは人間にあたえられた命令に服従しなければならない。ただし、あたえられた命令が、第一条に反する場合は、この限りでない。 
> 3. 第三条 
> ロボットは、前掲第一条および第二条に反するおそれのないかぎり、自己をまもらなければならない。 
> 
> — 2058年の「ロボット工学ハンドブック」第56版、『[われはロボット](https://amzn.to/301dvm6)』より
```

> 1. 第一条 
> ロボットは人間に危害を加えてはならない。また、その危険を看過することによって、人間に危害を及ぼしてはならない。 
> 2. 第二条 
> ロボットは人間にあたえられた命令に服従しなければならない。ただし、あたえられた命令が、第一条に反する場合は、この限りでない。 
> 3. 第三条 
> ロボットは、前掲第一条および第二条に反するおそれのないかぎり、自己をまもらなければならない。 
> 
> — 2058年の「ロボット工学ハンドブック」第56版、『[われはロボット](https://amzn.to/301dvm6)』より

※ `>`は引用

### 表組み

```md
| 言語 | フレームワーク |
|--------|-------------------------------|
| Python | Flask Django pyramid |
| PHP | Laravel CakePHP Symfony |
| Java | Struts Spring |
```


| 言語 | フレームワーク |
|--------|-------------------------------|
| Python | Flask Django pyramid |
| PHP | Laravel CakePHP Symfony |
| Java | Struts Spring |