当記事はさくらインターネット Advent Calendar 2017の12日目の記事となります。
さて、この度めでたく「リソースマネージャー」機能がリリースされました。
さくらのクラウドニュース: リソースマネージャー
当記事ではこのリソースマネージャーでも利用されている「Terraform for さくらのクラウド」や公式CLIである「Usacloud」についてどのようにリリースを行なっているのかについてご紹介いたします。
なお、今回ご紹介する構成用のTerraform定義ファイル類(tfファイル)は以下で公開しています。
概要
sacloudのプロダクトでは開発/リリースに主に以下のようなサービス/プロダクトを利用しています。
- Slack(コミュニティ内でのやり取りやリリース用BOTなど)
- GitHub
- TravisCI/AppVeyor(CI/CD)
- Docker Hub
- Terraform + Terraform for さくらのクラウド
- Usacloud
- さくらのクラウド(リリースサイト用)
この中でも今回はリリースの流れについてフォーカスを当てたいと思います。
リリースの全体像としては以下のような感じです。
順番にご紹介していきます。
(1) Slack BOTへリリース準備をお願いする
リリースを行う場合、まずはsacloudコミュニティのSlackワークスペースのリリース用チャンネルでBOTに対してリリース依頼を行います。
こちらの記事で紹介しているSlack BOTを用いており、BOTに声をかけるとGitHub APIから現在リリース済みの最新バージョンを取得して、次にリリースするバージョンの候補を表示してくれるようになっています。
(2) Slack BOTがリリース用ブランチを作成 & push
Slack上でリリースするバージョンを選択するとGitHub上にリリース用のブランチを作成&pushされます。
リリース用のブランチ名をbump-version-nn.nn.nn(nn.nn.nnはリリースするバージョン)としておくことで後続プロセスでどのバージョンとしてリリースするのかが決定されます。
(3) TravisCI上にてPullRequest作成
ブランチのpushを契機にTravisCI上でジョブが起動します。
TravisCIではscriptプロバイダを用いて独自のデプロイ用スクリプトを起動します。
deploy:
- provider: script
script: scripts/usacloud-release.pl --task=create-pullrequest --current-branch=$TRAVIS_BRANCH
skip_cleanup: true
on:
all_branches: true
condition: "$TRAVIS_BRANCH =~ ^bump-version-.*$"
conditionの部分でブランチ名がbump-version-で始まるものを対象にしているのがポイントです。
デプロイ用スクリプト
デプロイ用スクリプトにてPullRequestの作成を行っています。
Usacloudでのデプロイ用スクリプト:usacloud-release.pl
このスクリプトは少し前のMackerelのリリース用スクリプトを参考にしたもので、GitのコミットログからCHANGELOGなどを組み立ててリリース用のPullRequestを作成してくれます。
なお、この部分は近いうちにGoで書きなおす予定です。
(4) リリース & 各種ソースの更新
リリース用のPullRequestをマージすると実際のリリース作業が行われます。
この作業もTravisCI上で行われます。
before_deploy:
- if [ "$TRAVIS_BRANCH" == "master" ]; then
make docker-build;
docker pull sacloud/rpm-build:latest;
docker pull sacloud/deb-build:latest;
make rpm deb;
fi
deploy:
- provider: script
script: scripts/usacloud-release.pl --task=upload-to-github-release && scripts/usacloud-release.pl
--task=upload-master-to-github-release && scripts/release_homebrew.sh && scripts/release_docker_image.sh
&& scripts/release_website.sh
skip_cleanup: true
on:
branch: master
ここでは以下のような処理が行われます。
- 各プラットフォーム用にビルド&アーカイブ
- rpm/debパッケージ作成&署名
- GitHubリリースページへのファイルのアップロード
-
homebrew用のソースの更新&コミット - 配布用Dockerfileの更新&コミット
- リリースサイト用Dockerfileの更新&コミット
sacloudプロダクトは基本的にGitHubリリースページにて配布しています。
TravisCI上で配布用のファイル類をビルド&アーカイブしGitHubリリースページにアップロードしています。
加えてsacloudプロダクトはDockerイメージでも配布しているため、リリース時にDockerイメージをビルドしタグづけしておくようにしています。
また、パッケージマネージャから利用するリポジトリやインストール用スクリプトなどを配布するため、別途リリース用サイト(releases.usacloud.jp)も用意しています。このリリースサイト用のコンテンツについてもDockerイメージとしているためリリース時にイメージのビルドが必要です。
このために、TravisCI上でのデプロイ処理の中でDockerHubのAutomation buildを構築済みのリポジトリに対しDockerfileをコミットすることでDockerHubへ通知&イメージのビルドを行っています。
(5) DockerHubでのDockerイメージビルド
GitHubにてDockerfileが変更&コミットされるとDockerHub上でDockerイメージのビルドが行われます。
DockerHubでは以下のようにビルド設定しておくことで、GitHub上にタグがpushされたら対応するタグを持つイメージをビルドしてくれるようになっています。
ビルド後はWebhookでリリース用サイトに通知されるように設定しています。
(6) リリース用サイトのdocker stack更新
DockerHubからのWebhookを受けてリリースサイトのコンテンツの更新が行われます。
リリースサイトは以下のような構成でdocker stackを利用しており、Webhookを受けるとdocker stack deployコマンドを実行して利用するイメージを順次更新していきます。
各サーバのOSにはRancherOSを利用しており、Webhookの受信はRancherOSの「サービス」としてdockerコンテナとして実行しています。docker stackとは別でコンテナ起動している部分がポイントですね。
このリリースサイトはTerraform for さくらのクラウドで環境構築しています。
Terraform定義ファイル類は以下で公開していますので、詳細はコードを参照してみてください。
あまり整理できてない生々しいコードになっていますが、ある程度停止時間の許容できる甘めの運用要件しかないサイトなのでちょっと手を抜いてます。
とはいえdocker swarm initの実行やRancherOSのプロビジョニングなどの実例となっていますので
Terraform for さくらのクラウドの一活用例としてみていただければと思います。
以上でリリース処理が完了となります。
今回はsacloudプロダクトでのリリースの流れをご紹介しました。
ピタゴラ装置のように色々と組み合わせることでリリースパイプラインを構築する例でした。
どなたかの参考になれば幸いです。
以上です。