TravisCIからのテスト成功時の自動デプロイの書き方がまずかったので直す

TravisCIでGitHubフローをやるために、masterブランチの場合のみデプロイする。
 以前に、TravisCIから、テスト成功時に自動でデプロイするためにスクリプトを書いた。
# !/bin/sh -x

if test "$TRAVIS_BRANCH" = "master"; then
doDeploy
else
echo "$TRAVIS_BRANCH branch"
fi


 上記のは条件が一つ足りていなくて危なかった。masterへのコミット時にTravisCIでのビルド成功時に実行されるが、masterにプルリクを投げた時も同様にビルド成功時にスクリプトが走ってしまう。プルリクをはじかなければいけない。
# !/bin/sh -x

if [ "$TRAVIS_BRANCH" = "master" ] && [ "$TRAVIS_PULL_REQUEST" = "false" ]; then
doDeploy
else
echo "$TRAVIS_BRANCH branch"
fi
comment: 0

Azure FunctionsでGithubでCIを考えてみた

 定期実行したいジョブがあったが、ちゃんとバージョン管理をしておきたいと考えていた。バージョン管理をしないなら、VPSに入れてCRONでという方法ですぐにできたのだが。ここにAzure Functionsを使ってみたところ、実によく目的を遂げてくれたしコストも大したことなかったというハナシ。


 Azure Functionsにはバージョン管理ソフトを使ったデプロイ方法が用意されている。画面の指示に従ってポチポチとやっていく。Githubを選んだ場合にはpullするブランチも選べるようになっている。Githubフローでいけば、masterから切ったブランチでゴリゴリ開発していって、そのテストはCIサービス上でやる。テストにとおっていたら、プルリクでmasterにマージすれば、バージョン管理+CIはそれでOK。

 じっさいのところまだテストは入れていないのだが、定期実行処理はすでにAzureFunctionsに入れて運用している。RSSを取ってきてちょいと加工して、MongoDBに入れるという処理。3時間に一度の実行で、週に2円ぐらいのコスト。
 VPSを用意して、バージョン管理の仕組みを構築して、月額費用を払ってとやっていると運用で時間も金も消費していくのだが、AzureFunctionsのおかげで、最初の二日で定期実行処理のコードを書いてデプロイまでやって、あとはGithub連携がちゃんと動いていることを確認したら、週2円程度のコストで動いるものを安心して放置している。サーバレスなのでOS管理の必要もないし。やっすいしバージョン管理もできているので、いい仕組みでかなり満足している。
comment: 0

Github - TravisCI - DockerHub連携

 Webアプリをコンテナに入れて、それで運用できるようにしておくのが昨今のお気に入り。環境構築とか管理を手軽に済ませたいので。
 API keyなどのパブリックにしたらまずい情報は環境変数から読むようにしているので、コンテナを含めたもろもろのコードはGithubでパブリックにして管理している。結果物として出てくるDockerイメージは、これまでは手元でビルドしたものを自分でDockerHubへプッシュしていた。はい、自分でDockerHubにプッシュするのめんどい。


Github - DockerHub連携を使う
============================
Docker Hubを使ってGitHubにあるDockerfileからimageを自動生成する
 手っ取り早い。

CI環境でビルドしてDockerHubへプッシュ
=====================================
 たとえばTravisCI上でDockerイメージをビルドし、そいつをDockerHubへプッシュする。GithubとDockerHubの直接の連携より手間は増えるが、テストが可能になる。少し前、GoogleがDockerイメージに対するテスト自動化フレームワークとか公開してたし。

 TravisCIを使ったDockerHubへの自動プッシュの組み方を。TravisCIの前段にはGithubがあり、リポジトリの変更でTravisCIにコードが渡るように連携しておく。そしてTravisCIのSettingsの環境変数に、公開されないようにDockerHubのアカウントとパスワードを入れる。
 .travis.ymlを書く。以下のように書いたが、わりと最小構成に近いと思う。タグでTravisCIのビルド番号を使ってバージョンを変更しつつ、latestとしてもプッシュしている。テストは入れていない。
.travis.yml

services:
- docker

script:
- docker build -t matoba/cdcc:${TRAVIS_BUILD_NUMBER} .

after_success:
- docker login -u="${DOCKER_USERNAME}" -p="${DOCKER_PASSWORD}"
- docker push matoba/cdcc:${TRAVIS_BUILD_NUMBER}
- docker tag matoba/cdcc:${TRAVIS_BUILD_NUMBER} matoba/cdcc:latest
- docker push matoba/cdcc:latest


実行結果




 また開発の手間を一つ減らすことができた。
comment: 0

Dockerが隆盛な状況において、コンテナを使った個人的なWebアプリケーションを構築したノウハウ

個人で運用している-web-サービスをどう管理しているか-2018年版-3486f3f69424

 個人でやっているWebサービスの管理方法を、オープンにしてくれている記事を見つけた。サービス選定の考え方とか非常に参考になった。サービス利用料を天秤にかけた判断をやっていて、個人でやるにはそこまではやっぱりねというところで安心したり。
 ぼくも趣味と勉強のためにこのブログのエンジン自体から開発して、ホスティングサービスを選んだりとやってきた。そのあたりで考えてきたことをここでまとめておく。


コンテナホスティングサービス
============================
 VPSとかIaaSとか避けたい。避けたい。
 このブログはDockerを使ってコンテナとして開発したものを、コンテナホスティングサービスを使って運用している。
 なぜコンテナを使ったかと言えば、サーバ構築がすんげー楽だし、構成管理もDockerfileを書けばそれでやっていける。AWS、Azure、GCPなどの巨大クラウドベンダが2017年のうちにこぞってクラウドでコンテナを使えるようにしただけでなく、そのさきの管理サービスを作っていたので、もうコンテナに手を出すのを待っている段階ではなくなったと思っている。コンテナ技術でサーバの用意が楽になるし、もうそれを利用する基盤は整ってきている。もしコンテナがこの世から消えるようなことがあるならどこかのPaaSを利用するまでである。このブログの初期はAzureのPaaSで運用していたので、移行はたいしたコストにならないとわかっている。
 まあそんなことを言ってもAzureなどの主要クラウドは利用料金が高い。ホビーユースはちょっとねというところ。だからさくらインターネットのArukasに期待していたが、ついにはベータから脱皮せずに消えていった。
 コンテナホスティングサービスはHyper.shを使っている。コンテナを動かす仕組みとしてはDockerとは別のものを使っているようなのだが、コマンドなどはDockerとほぼ同じようなもの。Dockerの中の人が「すげーDockerライク」と言うぐらいで、"docker restart mongodb"が"hyper restart mongodb"てな具合。dockerをhyperにしたら動く。
 Hyper.shの料金は、一コンテナ当たり、VPSと同等程度の金額。Price表。このブログはフロントのNginxコンテナと.NETCoreのアプリコンテナを使っていて月額1200円ぐらい。それに加えてVPSで付き600円ぐらいで運用しているデータベースがあるが、これもコンテナにしてしまおうかと考えている。
 Hyper.shの弱点は、まだアジアにリージョンがないことか。ロサンゼルスとドイツのフランクフルト。アジアリージョンは検討中らしい。このブログはロスのサーバを使っている。レイテンシはまあ、あきらめている。それよりコンテナ使いたかったし、ここ以上に手軽に使えるコンテナホスティングサービスが見つけられなかった。
 Hyper.shのいい点は、秒単位課金なこと、コンテナがすぐ立ち上がることあたりか。試験環境を用意するのも速いし、不必要になったタイミングでコンテナを落とせば大したコストはかからないだろう。

 まとめ。このブログはコンテナホスティングサービスで運用している。ちなみにHyper.shでMeltdownとSpectreの影響をフォーラムで質問してみたところ、一週間ぐらい経過してなにも返事がないのでちょっと考えておかなければという状況。


デプロイ
========
 構成管理はDockerの仕組みに任せているので、アプリのコードを整えたらdockerのビルドコマンドを実行するだけでコンテナイメージができあがる。あとはNginxコンテナとWebアプリコンテナをDockerのオーケストレーションツールのComposeのHyper.sh版でオーケストレーションしているので、そのcomposeコマンドを一行実行すればビルド済みイメージを使ったデプロイが行われる。
 アプリのコードはGithubへのプッシュによって、TravisCIへさらにプッシュされ、Seleniumを使った統合テスト的なUIテストが行われる。それにとおった場合かつ、masterブランチへのコミットだった場合のみcomposeでのデプロイが行われる。自動化。だからもうWebアプリに機能追加したくなったりしたら、コード変更してGithubへプッシュ、それをmasterブランチにマージしたらあと自動。楽。


まだ手を付けていないところ
==========================
 コンテナで運用している部分に監視をまだつけていない。データベースサーバにはMackerelを入れているのだが。コンテナの監視はkubernetesが機能多そうながらも便利そうで面白そうなので、これを導入する方向で考えている。
 あとはログの運用。ここは完全未タッチ。Fluentdの運用事例とかが目に入ってくのでそのあたりを参考にしようとは考えている。


まとめ
======
 環境の構築や管理を自動化したかった。コンテナをそれに使ってみてすごく満足いくものができた。あとはコンテナゆえにイミュータブルになっている状況でログをどうするかなど課題は残っているので、そこらの解決をしていきたい。
comment: 0

TravisCIでGitHubフローをやるために、masterブランチの場合のみデプロイする。

 TravisCIでGitHubフローをやるために、masterブランチでテストが成功した場合にのみデプロイを実行する。

・テストが成功した場合の処理
 .travis.ymlのscriptにテストは書いてあるはず。そんでafter_successにデプロイを書いておけばいい。
script:

- runTest

after_success:
- doSomething



・デプロイをmasterブランチの場合のみに絞る
 TravisCIでは環境変数が用意されている(参考)。この中に$TRAVIS_BRANCHという環境変数があって、ここにブランチ名が入っている。それを利用してdeploy.shを書くのが一つのやり方。
script:

- runTest

after_success:
- sh deploy.sh


# !/bin/sh -x

if test "$TRAVIS_BRANCH" = "master"; then
runTest
else
echo "$TRAVIS_BRANCH branch"
fi

comment: 0