Adams前回のブログで、さくらVPSにGatsbyで生成したサイトをデプロイすることはできるようになりました。Actionsを使って自動デプロイの仕組みを構築しました。やったことは至って普通なのですが、セキュリティに拘った結果rsyncコマンドの中身とサーバーの設定で少し時間を溶かしてしまいました。今回シェルスクリプトを書いてみて、勉強してみたいと思うきっかけになってよかったです。前にシェル芸はやめよう。みたいなツイートがバズっていましたが、時代の流れに逆行し一流シェル芸人になりたい気持ちが高まってきています。今回やったことビルド⇨デプロイまでの作業を以下のように変えました。設定前ビルドするプッシュするマージするrsyncでデプロイする設定後プッシュするマージする工程が半分になりました。タイトルにはカッコつけて「CI/CDパイプライン構築」と書いていますが、今回導入した仕組みではビルド&デプロイの自動化しかしておらず、まだテストは導入できていません。次デザインをガラッと変えたくなった時にでも、Storybookを入れようかなと思っています。詳細ここからは、備忘録も兼ねて詳細を記載していきます。私は今までビルドファイルをコミットしない派だったのですが、ビルドファイルをコミットする派もあるようでした。Actionsに登録するワークフローが増える&ビルド結果が異なってバグが起きたりしたら面倒だなーと思い、ならば手元でビルドしたファイルをGitHubにもプッシュして、それをそのままデプロイするようにすればいいじゃないか。思ったのが始まりです。Actions上でビルド&デプロイを行うことにしました。理由は、「push前にビルドすることを忘れそうだから」の1点だけです。push~~しているのでどう考えても間違えてしまいそうということで却下しました。},スクリプトを呼び出す際は、ハイフン2つを入れて、そのあとスペースを開けるとスクリプトに続く引数を渡すことができます。これで、ビルドしてからプッシュすることができるようになるのですが絶対間違える自信があります。branch-name一方、1人で開発している場合にはビルドファイルをコミットすることには以下のメリットもあるなと思ったので、今後の選択肢からはまだ消えていません。デバックを早くしたい時とかにはローカルでビルドした方が早いのでいいかもしれません。開発しているのは自分1人だし今後も1人なので、最新とリリース用が離れてコンフリクトなどは起こりにくい。Actionsで依存関係をインストールして、ビルドしてという作業が不要になるので設定が楽。ローカルだと依存関係のインストールが都度都度は不要でビルドが早い。基本的にはCI/CD回している間放置でいいのであまり問題にならないはずだが、デバッグする際には早くて楽。workflow.yamlを作るここからが今回の本題です。ファイルを作りそこに設定を定義していく必要があります。ファイルを作成しました。最終的なファイルは以下で、シェルスクリプトだけ別で1つ書きました。条件は色々と設定できます。今回は1で設定しましたが、2やその他より細かくブランチを指定した条件も作り込むことが可能です。記法はこちらに紹介されています。${{secrets.SERVER_DESTINATION}}yamlファイルの中では環境変数を設定して、使用することが可能です。16.xNode.jsはバージョン16系を活用しています。actions/checkout@v2はリポジトリのコンテンツにアクセス可能にするためのライブラリです。}}-yarn-actions/cacheから詳細は確認できますが、依存とビルド結果をキャッシュしてワークフローの実行を高速化するための設定をしています。キャッシュした時としていない時とでどのぐらい速度に差が出るのかはテストしていないので不明ですが、気になるところです。./sync.shこれが今回の肝です。./sync.shファイルを実行。スクリプト内で環境変数を使って鍵を作成して、rsyncでデプロイ。最後に鍵を削除して終了。いう流れになっています。ビルドまではスルーして、その先から見ていきましょう。./sync.shワークフロー内でファイルに定義したコードを実行するためには、実行権限を付与する必要があります。./sync.shに対する実行権限を付与しています。./sync.shここでは、./sync.shに書いた以下のシェルスクリプトを実行しています。$HOME/.sshシェルスクリプトは今まで真面目に調べたり活用したりしてこなかったので、今回は入門としていい経験になりました。わるサードパーティー製ライブラリもあったのですが、記述量があるわけではない&ちょうどいい練習になりそうということで、今回は自作しました。#!/bin/shとShebangを書きます。Shebangだよ!で紹介してくださっていますが、ただのコメントではないということを初めて知りました。-euでシェルの設定を変えます。今回はeでコマンドが1つでもエラーになったら直ちにシェルを終了して。uで設定していない環境変数があったらエラーになるようにしています。"$KEYPATH"fiGitHubデフォルトの環境変数である$HOMEを使ってKEYPATHディレクトリが存在していなかったらディレクトリを作成するようにしています。作成したディレクトリに鍵を格納します。Nginxでホストで設定したrsyncコマンド用の鍵の中身を設定しておきます。鍵の中身は以下のようになっているかと思いますが、最初の行と最後の行も含めて全部設定しておく必要があります。"$KEYPATH/key"で読み込み権限を付与しています。$user_name@$server_ip:$server_destination"前回設定したコマンドに近いのですが、環境変数と--deleteオプションを追加して、デプロイで存在しないファイルがリモートにあった際に削除するようにしています。StrictHostKeyChecking=noを設定しておかないとワークフローからデプロイすることができません。このオプションをnoにしていると、鍵情報が漏れた際に別のPCなどからssh接続ができるようになってしまうのでできればしたくないのですが、前回のブログでも書いた通り、rootではrsyncコマンド以外実行できないようにしているので、今回はワークフローを構築するために許容しています。root権限で実行可能なコマンドを制御していない場合には、StrictHostKeyChecking=noにしない方が良さそうです。sshのホスト鍵を無視する方法を読ませていただきました。$HOME/.ssh最後にデプロイが終わったら、念の為鍵を削除しておきます。これで、設定は終わりな気がしますが、このままワークフローを実行するとエラーになってしまいます。mismatch~~というような内容を含むエラーメッセージが出るはずです。前回は自分のローカルからrsyncした結果とprotocolを合わせるために登録していたので、今回も合わせてやる必要があります。$user_name@$server_ip:$server_destination"-vvオプションをrsyncに追加して処理中の経過ファイル名を表示するようにしておきます。その状態でワークフローを実行すると以下のようなエラーメッセージが追加されているはずです。**これから、vvオプションを取り除いて、remoteの/root/.ssh/authorized_keys先頭のcommandに追加します。・これで問題なく実行できるはずです。余計なファイル名が表示されないよう、再度-vvオプションを削除して完了です。macos-latestにしてみたところ、処理にめちゃくちゃ時間がかかり終わりませんでした。どのプロセスが遅いのか、どこかに問題があったのかなど、今回は調査できていないのですが気になるところです。機会があれば調べてみたいと思います。シェル芸人に俺はなる。withGatsby。