目的
- ORACLEの wercker を使ったときのメモ
- 使い始めの最初の取っ掛かりとして参考になれば。
なお、アカウント名がサービスにより違っていたりするが、アカウント登録のタイミングによって名前がかぶっていて、止む無く他のアカウントにしているので統一感がなくなっている。
揃えておくのが分かりやすいが、仕方ない。
使い始めにやること
アカウント作成、ログイン
- wercker で、アカウント名、メールアドレス、パスワードの登録。
- パスワード強度のチェックが意外と強め。
- 登録したメールアドレスにWelcomeメールが来ているので、アカウントをActivateし、ログイン。
- 自分のアカウント画面 を確認。
リポジトリの準備
アプリケーションの登録
- ログイン後の画面の右上のほうに「＋」マークがあるので、そこから「Add Application」により登録
- やることは4段階。Select SCM, Select Repository, Configure Access, Review.
- Select SCMではGitHub, GitLab, Oracle Developer Cloud ServiceとOther gitから選べる
- 私はGitHubを選択。OAuthによる認可（クライアントがwercker, 認可サーバ＋リソースサーバがGitHub）を実行
- GitHubの中で、CI対象とするリポジトリを選択する。
- Setup SSH keyでは、ssh鍵を使わないコードチェックアウトと、deploy keyを使う方法から選べる。前者を選択
- 最後に設定内容確認画面。問題なければMake my app publicにチェックし（もしくはチェックせずに）Createボタン押下。これでCI対象のアプリケーションの登録が完了。
アプリケーション画面の確認
- タブが5つあり、Runs, Workflows, Access, Environment, Optionsとあるので、どのような内容が含まれるか確認しておく
- Runsタブではパイプラインの実行結果が分かるようになっている
- Workflowsタブにてpipelineを追加してbuild, test, deployなどのCI/CD処理の部品を追加していき、その各処理の詳細をリポジトリのwercker.ymlに記載していくことになる。
- Accessでは、自分のアプリにアクセスできるユーザを決めることができる
- Environmentでは、自分のアプリケーションで使える環境変数を定義できる
- Optionsは、そのアプリケーションの画面で使う色や、他の人から見えるかどうか等、各種設定ができる
box用のリポジトリ作成
- werckerではboxというCI/CDタスク実行環境を自作できるので、これを作る。GitLabでいうexecutorを知っていれば分かりやすいはず
- ドキュメントにはqiitaで見かけるようなboxの作り方がなかったように思う。Dockerhubに入れてあるものを使うことはできるようなので、GitHubにて box作成用のDockerfile を置き、そこから作ったイメージを Dockerhubのkura2i/wercker-box-test に置くことにした
- GitHub上でファイル作成。Dockerfile以外にも必要なものがあれば作っておく
dockerhubでのboxの準備
- Dockerhub のアカウントがまだない場合は作成しておく
- DockerhubはGitHubとOAuthで連携させる
- Dockerhub上でリポジトリを新規に作成し、上記で作ったDockerfileのビルド結果を入れるのに使う。
- OAuthで認可されていれば、GitHub上の自分のリポジトリ（さらに特定のブランチやタグの指定も可能）をAutobuild対象にでき、git pushされたときにDockerfileからイメージを自動作成できる
- 上記により、GitHubのniiku-y/wercker-box-testから、Dockerhubのkura2i/wercker-box-testをbox用イメージとして作成できるようになった
- ねんのため、イメージが作成できたら他のサーバでdocker pull kura2i/wercker-box-test:latestなど実行してみて、ちゃんと使えるかの確認くらいはしておいたほうがよい。
アプリケーション側でのCI/CDタスク定義
- 上記まででboxは準備できたので、いよいよアプリケーションのリポジトリにwercker.ymlをおいて、そこでCI/CDタスクを定義する
- アプリケーションは、今回練習なので何でもよい。 自分のリポジトリ でどれか選ぶ
- wercker.yml には、実行環境のboxを上述のものを指定したうえで、build, test, deploy というパイプラインを書き、その下にそれぞれstepをぶら下げている
- 今回stepは再利用可能なようにしていないが、werckerはこのstep(複数コマンドの集合)に名前をつけて再利用できる点がよいので、本来そういうふうに作っていくのがよかろう
- タスクはコンテナとして実行されるので、この例の場合、WERCKER_OUTPUT_DIRを介してパイプライン間で成果物の受け渡しをしないと、ビルド結果のコマンドを実行できない点に注意する
- wercker.ymlを直すたびにCIが実行され、結果はRunsに出てくるので、結果を見ながら修正していく。
- デフォルトではパイプラインはbuildしかなかった。deployなどはwercker.ymlに記載しても自動で検出されないようだったので、自分でpipeline追加をGUI(Workflowsタブ)でやらないといけなさそう。
- werckerのアカウント登録に使ったメールアドレスにビルド結果が飛んでいる。通知は適宜うまく利用すること。
