はじめに
AWSにしろAzureにしろ、クラウドベースの開発でよく「CI/CD」(継続的インティグレーション/継続的デリバリー)が取り入れられていると思います。
そして、Git連携(=gitの特定リポジトリ/ブランチにpushしたら、連動してデプロイが実施される)を導入するケースも多いです。
実際にAWSなら、「AWS CodeBuild」「AWS CodePipeline」のようなCI/CD支援サービスも提供されています。
今回のブログは、そのCI/CD&Git連携を、Serverless Frameworkのダッシュボードのみで実現する方法です。
前提
- Serverless Frameworkの1.48.0以降のバージョンが必要なので、必要に応じて事前にバージョンアップをしてください。(最新版なら問題なし)
- 公式ページ(https://serverless.com)から、サインアップを済ませておいてください。(右上の「Sign-Up-Free」から)
- 事前にGit連携対象のGitHubリポジトリ&ブランチを作成しておいてください。(ブランチは「master」でもOK)
初期設定
初回ログイン時、まずは作成するアプリの設定を行います。
下記3種類から選びます。(今回は「Serverless Framework Existing Project」前提で進めます)
項目 | 説明 | 備考 |
---|---|---|
Node.js Rest API | Node.jsのRest APIプロジェクトの新規作成 | |
Python Rest API | PythonのRest APIプロジェクトの新規作成 | |
Serverless Framework Existing Project | 既存のServerless Frameworkプロジェクトから選択 | 新規作成せず、既存のプロジェクトを使用する場合はこちら。(まだAWSにデプロイしていなくてもOK) |
また、初回のみ「GitHub連携」及び「AWSアカウント連携」の設定を行う必要があります。
それぞれ、ボタンをクリックするとGitHub/AWSのログインページが表示されますので、GitHubのレポジトリ連携/AWSサインインを行えば、自動でダッシュボード画面に戻ります。
アプリを登録する
まず、CI/CD導入対象のアプリを登録する必要があります。 まずダッシュボードにサインインします。
公式ページ右上の「Sign-in」からサインインすると、自分のダッシュボードが表示されます。
※下記CLIコマンドでサインイン画面を開くことができます。(もちろん自分でブラウザを開いても問題なし)
> serverless login
※その他、一度サインインすれば、CLIから下記コマンドでダッシュボードを開くことができます。
> serverless dashboard
ダッシュボードが表示されたら、[apps] - [add app]から、必要項目を設定して、[add app]ボタンをクリックすると、アプリを登録できます。(設定できる項目は以下の通り)
項目 | 説明 | 備考 |
---|---|---|
name | アプリの名前 | |
profile | デプロイに使用するprofile | ※1 |
※1:profileは右上の[アカウント名]-[org settings]-[DEPLOYMENT PROFILES]から設定できます。(細かくは別記事で書きます)
とりあえずは「default」でOK
その後、登録した[apps]から登録したアプリ名をクリックすると、「Deploy Your Service」項目が表示されますが、まずは先に下記の「デプロイステージの登録」を行います。
デプロイステージの登録
[app settings]-[stage]を選択すると、デプロイ先のステージを登録できます。 デフォルトで「default」が登録されていますが、「dev」「stg」など、明確にステージ名が決まっている場合、ここで事前に登録しておきます。
なお、設定項目は下記2つです。
項目 | 説明 | 備考 |
---|---|---|
stage name | ステージ名 | |
deployment profile | デプロイに使用するプロファイル |
CD/CDの選択
ここまで設定したら、登録した[apps]から登録したアプリ名をクリック後、下記いずれかの方法でCI/CDの設定を行います。
- 「Deploy Your Service」画面で「Deploy Your GitHub」をクリックする※
- [ci/cd settings]タブをクリックする
※ちなみに「Deploy From the CLI」を選択すると、CLIから登録したアプリをデプロイする方法が表示されます。
この方法ではGitHubレポジトリ・ブランチ連携デプロイは出来ませんが、登録したアプリのモニタリング&デプロイ履歴の確認などは出来ます。(この辺も別記事で書きます)
※「Deploy From the CLI」の場合、ログイン後、下記コマンドで登録したアプリと表示中のプロジェクトの紐づけを行うことができます。
> serverless --org (アカウント名) --app (登録したアプリ名) # 例 > serverless --org makky12 --app my-app
設定できる項目は、以下の通りです。
項目 | 説明 | 備考 |
---|---|---|
connection | 連携するGitHubレポジトリ名 | GitHubリポジトリを未設定の場合、まずGitHub側でリポジトリ設定が必要(ここで設定可能) |
preview deploys | テスト&デプロイ対象のブランチ(?) | ※1 |
branch deploys | デプロイトリガ元のブランチ&デプロイステージ | |
region | デプロイ先のAWSリージョン | ここからは「advanced settings」の項目※2 |
service | デプロイ対象のサービス名 | ※3 |
runtime | デプロイ対象のプログラムランタイム | 「node.js」「python」など※3 |
trigger directions | デプロイトリガ元のブランチの中で、実際にトリガを起動するフォルダ・ファイル | 「Always trigger a deployment」にチェックを入れると、該当ブランチをpushしたらデプロイが実行される。 チェックを入れなかった場合、指定したフォルダ・ファイルの変更がpushされた場合のみデプロイが実行される。 |
preview deploys | プレビュー対象のステージ(?) | [app settings]-[stage]で設定したステージ、または「use branch name as stage」を選択。 後者を選んだ場合、ブランチ名がそのままステージ名になる。 また「Destroy stage and resources when branch is deleted」で「ブランチを削除したら、該当ステージ&リソースを削除するかどうか」を設定できる。※1 |
※1:てか、なんで同じ名前なの...(誤記ではなく、本当に同じ名前)
※2:「advanced settings」とあるけど、リージョンってかなり重要なような...
※3:初期設定で「Serverless Framework(Existing Project)」を選択した場合、設定済&指定不可
実行
ここまで設定したら、実際に設定したレポジトリ・ブランチに該当プロジェクトをpushしてみます。
設定に問題なければ、pushに連動してデプロイが実行されるはずです。 ※左上の「ci/cd」の隣に青い●マークがつき、クリックすると「実行中」みたいな感じで円がグルグル回っているはずです。
デプロイ終了すると、結果に応じたアイコンが表示されるので、クリックするとデプロイのレポート・及びログを確認できます。
あとは実際に動かしてみて、正しくデプロイされている&変更が反映されている事を確認してください。
デプロイ失敗理由(僕の場合)
- serverless.ymlの変数値の設定に必要なファイルがpushされていなかった
- node_modulesフォルダがpushされていなかった
しょうもない理由といえばしょうもない理由なんですが、ログを追って原因が分かった時、「あ、そうか、CI/CDだとそうなんだ」と思いました。
というのは、(前者はともかく後者は)今の業務で開発しているプロジェクトだと、node_modulesフォルダ一式はGitの管理対象外にしてたからです。(そうそう自分で直接変更なんてしないし、事前にnpm installすればOKなので)
でもCI/CDだと、当然Gitにpushしないと動かないので(Lambda実行時に「●●のモジュールがない」とエラーが出る)、Gitの管理対象にしないといけないんだ、と分かりました。
とはいえ、ここはうまい方法があるかもしれないので(それこそCodeBuildの「buildspec」ファイルみたいな機能を使うとか)、そのあたりも調べて、別記事で書きたいです。
まとめ
というわけで、Serverless FrameworkのダッシュボードだけでCI/CDを実現する方法でした。
AWS CodeBuildやAWS CodePipeline、及び各種CI/CD用ツールはありますが、Serverless Frameworkのダッシュボードだけでも、簡単なCI/CDを実現できますので、有効に活用していきたいですね。
また、今回記載できなかった
- プロファイル設定
- ビルドコマンド設定
- アプリのモニタリング&各種通知設定
なんかについても、後日別記事で書きたいと思います。
それでは、かなり久々な記事でしたが、今回はこの辺で。