はじめに
本記事はGCP環境にてCloud Buildでパイプラインを構築し、GCEの仮想マシンインスタンスに静的コンテンツをデプロイする方法について解説しています。
DevOps
DevOpsは価値を提供することを目的に、迅速にデプロイを行い品質を担保するための仕組みであり、文化です。
開発 (Development) と運用 (Operations) を組み合わせて、技術的要素だけではなく、体制を整備し、サイロ化を作り込まないことが重要です。
DevOpsを組織に導入することで、俗人化されていたデプロイ作業をパイプラインに置き換えて、誰でもビルド・デプロイできる仕組みを提供します。
本記事ではDevOpsの真髄となるCI/CDの自動化を実現する手段として、GCPのCloud Buildについて学びます。
何故、パイプラインを構築するのか？
DevOpsにおいて、Cloud Buildなど自動化ツールを導入することは目的はありません。
As-Is/To-Beを基に、DevOpsの必要性について理解しましょう。
- As-Is
- ソースの変更を反映させる場合、手動のデプロイ作業が必要になるため、オペレーションミスのリスクや、デプロイに時間がかかる。
- 少人数の組織の場合、デプロイ作業が俗人化して作業のサイロ化を生みやすい。
- To-Be
- ソースコードの変更を反映させる場合、自動でデプロイ作業を行い、冪等性を確保し品質向上や、迅速にデプロイを行う。
- Gitにpushするなど、何らかのコンテキストをトリガーにすることで誰でもデプロイを行うことができ、作業のサイロ化を発生させない。
上記、運用に関わる課題を解決するための手段がパイプラインの構築であり、ベネフィットはデプロイ自動化による工数削減及び品質向上になります。
パイプラインの構築
クラウドサービスにおいて、パイプラインを構築するためには以下の様な仕組みが必要です。
- パイプライン
- Gitなどのバージョン管理システムにソースコードをプッシュすると、パイプラインのトリガーが起動し、ソースコードの変更を検出
- ビルド・テスト
- 必要に応じて、アプリケーションのビルドの実施
- ソースコードに対する静的テストや動的テストの実施
- デプロイ
- Gitなどのバージョン管理システムで指定したmainブランチなどから、最新のソースコードを取得し、仮想マシンやコンテナなどの実行環境にデプロイする
- 必要に応じてコマンドによる命令の実行
- デプロイ終了後の完了通知を行うための仕組み
本記事で紹介するCloud Buildは、パイプラインからデプロイまで、一気通貫でデプロイすることができます。ちなみに1日120分までは無料枠として利用することができます。
なお、本記事の内容をAWS環境で実行する場合は、AWS CodePipelineと、AWS CodeDeployの組み合わせが必要です。
補足としてGoogle Cloud Deployは、GKEに対するマネージド型の継続的デリバリーサービスになります。現在は、GKEのみサポートしています。
パイプラインの仕組みを理解し、デプロイを実現する手段として、クラウドサービスの仕様が要件を満たしているか確認することが重要です。
Cloud Build
Cloud Buildでパイプラインを構築し、GCEの仮想マシンインスタンスにデプロイするための方法について以下に記載します。
本記事では以下の構成でCloud Buildを軸に、パイプラインを構築します。また、ソースコードの脆弱性を保護するために、Snykを利用しています。
ソースコードをGitHubにプッシュすると、Cloud Buildのトリガーがソースコードの変更を検知し、最新のindex.htmlファイルをデプロイ先のサーバに配備します。デプロイ後、Slackに通知を行います。
※本記事ではテストについては対象外としています。
パイプラインの構築
前提条件：
デプロイ先である仮想マシンインスタンスのVPCネットワークのファイアウォール設定は、トラフィックの送信元を識別するためのソースフィルタについて、Cloud Buildから仮想マシンインスタンス宛のSSHのトラフィックが許可されている必要があります。
Cloud Buildで必要な作業は以下になります。
- Cloud Buildの設定
- トリガーの作成
- Cloud Build APIの有効化
- サービスアカウント権限の設定（IAM）
- cloudbuild.yamlファイルの作成
Cloud Buildの設定
Cloud Build画面のトリガーペインより、「トリガーを作成」を選択し、名前など必要な項目を入力します。また、ソースからリポジトリを選択します。リポジトリ選択は初回のみ、認証を行います。
保存をクリックして、設定を保存します。
Cloud Build画面の設定ペインより、「APIを表示」をクリックします。
Cloud Build API画面に遷移後、Cloud Build APIを有効にするため、「有効にする」をクリックします。
Cloud Build画面の設定ペインより、サービスアカウント権限の「Compute Engine」について、ステータスを「有効にする」に変更します。
画面の様なポップアップが表示されるので、「すべてのサービスアカウントにアクセス権を付与」をクリックします。
サービスアカウント権限の「Compute Engine」と、「Service Accounts」のステータスが有効になったことが確認できます。合わせてIAMのCloud Buildで使用するサービスアカウントに、ロールが追加されたことが確認できます。
cloudbuild.yamlファイルの作成
Cloud Buildにてデプロイ実行時のタスクを制御するための命令は、cloudbuild.yamlファイルに記述します。cloudbuild.yamlファイルは、リポジトリ直下に配備します。
Cloud Buildに実行させるアクションはstepsに記述します。
以下の場合、最初のステップでcloud-sdkのイメージをビルドし、ビルドされたコンテナからgcloudコマンドのscpを用いて、GCEの仮想マシンの/var/www/htmlディレクトリにindex.htmlファイルをコピーします。
次のステップで、Slackで指定したワークスペースのtestという名前のチャンネルに、curlコマンドを用いて、メッセージを通知します。
- cloudbuild.yaml
steps:
- name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
entrypoint: gcloud
args: ['compute', 'scp', '--project', 'unique-sentinel-XXXXXX', '--zone', 'us-west1-a', 'index.html', '＜ユーザー名＞@＜ホスト名＞:/var/www/html', '--port', '＜指定したポート番号＞']
- name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
entrypoint: bash
args:
- '-c'
- |
curl -X POST --data-urlencode "payload={\"channel\": \"#test\", \"username\": \"webhookbot\", \"text\": \"Deploy Done\", \"attachments\": [{\"color\": \"#36a64f\", \"title\": \"Deploy notification\"}]}" https://hooks.slack.com/services/XXXXXXXXXXX/XXXXXXXXXXX/XXXXXXXXXXXXXXXXXXXXXXXX
デプロイ時にgcloudのscpを使うメリットは、コードの中でSSH秘密鍵などのクレデンシャル情報を持つ必要がないため、セキュアな運用が実現できます。
gcloudコマンドライン ツールには SCP ファイル転送ユーティリティが備わっています。このユーティリティは初回接続時に SSH 認証鍵ペアを作成します。秘密鍵はローカル デバイスに保存され、対応する公開鍵はプロジェクト メタデータまたは VM インスタンス メタデータにコピーされます。
デプロイ検証
ローカル環境でソースコードを変更後、Gitでcommit及びpushを実行すると、Cloud Buildによる自動デプロイが行われます。
デプロイ終了後、Slackのtestチャンネルに通知が行われます。通知によりデプロイ完了が確認できます。
また、Cloud Build画面のダッシュポードペインより、ビルド成功と表示され、サーバでもindex.htmlが反映されたことが確認できます。
ロギング
ビルド時のログは、Cloud LoggingのLogs Explorerからも確認できます。
Cloud Buildのログは、ログバケットの_Defaultに保存されます。
デフォルト設定で使用し続ける場合は、基本的に料金は無料ですが、デフォルトの保持期間30日を超える場合は、課金が発生するため、注意が必要です。
Snyk
SnykはDevSecOpsを実現するためのソリューションとして、コードを保護することを目的としています。
Snyk及びDevSecOpsについては、以前書いたSnykではじめるDevSecOpsを参照。
Snykのスキャンはオンデマンドでも実行することができますが、CI/CDにも対応しているため、パイプラインに組み込むことができます。
本記事ではSnykのCI/CDの組み込み方法や、ソースコードをスキャンするための簡単な使い方について記載しています。
Snyk Code
Snykを使用するためには、GitHubとSnykを連携します。
Projectsに保護したいリポジトリを登録したタイミングで、自動的にスキャンが行われます。
また、Snykは各リポジトリ毎に、自動スキャンを行ないます。各リポジトリ毎の設定のSettingsタブから、スキャンスケジュールの設定が確認ができます。
デフォルトはTest weeklyになっているので、週次でスキャンが行われてレポートがメールで通知されます。日時でスキャンを行いたい場合は、Test dailyを選択します。
スキャンされた脆弱性に対して、自動でPull Requestも行ってくれるので、Snykは開発者の負担を軽減します。
CI/CDへの組み込み
SnykのCI/CDへの組み込みは以下、4パターン存在します。
- ネイティブプラグインの使用
- パイプラインスクリプトから、npmを使用してSnyk CLIをインストール
- パイプラインスクリプトから、npmを使用できない場合、CLIバイナリをインストール
- パイプラインから、SnykのDockerイメージをダウンロードし、コンテナのデプロイ
環境に応じてCI/CDにSnykのスキャンを組み込むことで、スキャンで問題が検出された場合は、デプロイを行わないなど、DevOpsにセキュリティを融合できます。
おわりに
GCEの仮想マシンインスタンスについても無料で利用することができます。詳細については以前書いたこれから始めるGCP（GCE） 安全に無料枠を使い倒せを参照。
DevOpsはこれからも重要なスキルです。GCPの無料枠を最大限に活用し、DevOpsについて学びましょう。
参考
DevOps
- How to begin your DevOps journey
- What is DevOps? REALLY understand it
- What don't people understand about DevOps (yet)?