wercker を使ってこのブログをビルドしていますが、 Dockerベースのものに移行した時にちょっと分からないことがあって手間取りました。
werckerの環境が良くわからないのでwecker.ymlに色々werckerのチェックを入れて pushしてウェブで確認みたいなことをしてましたが、 ちょっと色々やりたい時にそれだと面倒なので、 ローカルで直接タスクを実行する Wercker CLI を試してみました。
Wercker CLI
Wercker CLI: http://www.wercker.com/wercker-cli
はWerckerのタスクをローカルマシンで実行したり
サーバー側で実行した結果をチェックしたり出来る
コマンドラインツールです。
Werckerは現在Dockerベースになっているため、ローカルで回すにはDockerの環境が必要になります。
今回はその辺も含めてMacでHomebrewを用いて環境を作りました。
Dockerをインストール
HomebrewでDockerを探してみると
$ brew search docker
boot2docker docker-compose docker-machine-nfs
docker docker-gen docker-machine-parallels
docker-clean docker-machine docker-swarm
docker-cloud docker-machine-driver-xhyve
homebrew/completions/boot2docker-completion Caskroom/cask/docker-toolbox
homebrew/completions/docker-completion Caskroom/cask/docker
homebrew/completions/docker-compose-completion Caskroom/versions/boot2docker-status-beta
homebrew/completions/docker-machine-completion Caskroom/versions/docker-beta
homebrew/emacs/dockerfile-mode
何やら沢山出てきますが、dockerとなっているものは 所謂dockerコマンドをインストールするだけになります。
docker-machineなどもそのコマンドのインストールです。
Boot2docker は軽量Linuxで、Dockerのコンテナを走らせるのに使いますが、 上のリストにあるものはこれを管理するためのコマンドラインツールです。
その後使われていたのがDocker Toolbox
で、VirtualBoxも同時にインストールします。
この中にdockerやdocker-macihne等のコマンドも入っています。
で、現在はさらに新しいDockerのツールが出ています。
新しいDocker for Mac ではVirtualBoxなど使わずに直接Virtual Machineを管理する様な感じになっていて 大分高速化されてるとのこと。
また、dockerコマンドだけで色々作業するようになっています。
Macだけではなく、 やDocker for Ubuntu など各環境用のものが用意されています。
HomebrewではこのDocker for Macは Caskroom/cask/dockerになります。
ということで、
$ brew cask install docker
これで/Applications/Docker.appがインストールされるので 立ち上げてみると権限の付与の許可などを聞かれます。
また、最初の起動時に /usr/local/bin/docker等に ~/Library/Group\ Containers/group.com.docker/bin/docker等へのシンボリックリンクが 作られます。 これらはさらに /Applications/Docker.app/Contents/Resources/bin/dockerなどへのシンボリックリンクになっていてここに実体があります。 /usr/local/binに入れるにはちょっと気持ち悪い感じで なんで直接Docker.appの中へリンクしないのか非常に謎ですが。。。
取り敢えず一度立ち上げるとdockerコマンドがコマンドから実行できる様になります。
Get started with Docker for Mac - Docker に簡単な例があるのでちょっとやってみます。
docker psで現在動いているコンテナ一覧。docker ps -aすると現在存在するコンテナ一覧。docker stop <NAME>で該当コンテナをストップ。docker rm -f <NAME>で該当コンテナを(動いていればストップして )削除。
という感じ。実際やってみると、
$ docker run -d -p 80:80 --name webserver nginx
f06061ab544b27318b18eb7d36f2dc155c852fe187f2594a90ba0ac92a44325b
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f06061ab544b nginx "nginx -g 'daemon ..." 10 seconds ago Up 9 seconds 0.0.0.0:80->80/tcp, 443/tcp webserver
$ docker run hello-world
Hello from Docker!
This message shows that your installation appears to be working correctly.
To generate this message, Docker took the following steps:
1. The Docker client contacted the Docker daemon.
2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
3. The Docker daemon created a new container from that image which runs the
executable that produces the output you are currently reading.
4. The Docker daemon streamed that output to the Docker client, which sent it
to your terminal.
To try something more ambitious, you can run an Ubuntu container with:
$ docker run -it ubuntu bash
Share images, automate workflows, and more with a free Docker ID:
https://cloud.docker.com/
For more examples and ideas, visit:
https://docs.docker.com/engine/userguide/
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f06061ab544b nginx "nginx -g 'daemon ..." 24 seconds ago Up 22 seconds 0.0.0.0:80->80/tcp, 443/tcp webserver
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
be7c0d7616a6 hello-world "/hello" 5 seconds ago Exited (0) 4 seconds ago ecstatic_ardinghelli
f06061ab544b nginx "nginx -g 'daemon ..." 26 seconds ago Up 25 seconds 0.0.0.0:80->80/tcp, 443/tcp webserver
$ docker stop webserver
webserver
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
be7c0d7616a6 hello-world "/hello" 24 seconds ago Exited (0) 23 seconds ago ecstatic_ardinghelli
f06061ab544b nginx "nginx -g 'daemon ..." 45 seconds ago Exited (0) 6 seconds ago webserver
$ docker rm -f webserver
webserver
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
be7c0d7616a6 hello-world "/hello" 32 seconds ago Exited (0) 31 seconds ago ecstatic_ardinghelli
$ docker rm -f ecstatic_ardinghelli
ecstatic_ardinghelli
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
$
こんな感じです。
Wercker CLIをインストール
こちらもHomebrewで
$ brew search wercker
Caskroom/cask/wercker-cli Caskroom/cask/wercker
の2つのCaskが見つかりますが、werckerとなってる方は サーバー側で行ったタスクをブラウザ以外で見たい時に使う 管理ツールみたいな感じですが、 ちょっと使ってみた所上手く動いてくれませんでした。
取り敢えず置いておいて、今回使うのは*wercker-cli**の方ですが、 実はCaskではなくてFormulaが Wercker CLIのInstallation で紹介されています。
両方見てみましたが、CaskもFormulaも全く同じものを入れていました。
- homebrew-wercker/wercker-cli.rb
homebrew-cask/wercker-cli.rb: https://github.com/caskroom/homebrew-cask/blob/master/Casks/wercker-cli.rb
Caskの方が後に作られてますが、Werckerの人ではない人たちがOfficial Formulaを知らずに入れた感じなのかな?という感じ。
ただし、アップデートがあったときはFormulaの方ではないと 自動でアップデートされないのでFormulaの方をいれておきます。
$ brew install wercker/wercker/wercker-cli
これでwerckerコマンドが使えるようになります。
今回は直接使いませんが、
wecker loginというコマンドでログインしてサーバー側の
情報を取ってこれる様になれます。
この際、GitHubのアカウントを遣った認証だとちょっと面倒です。
GitHbuアカウントを使って普段ログインしている場合でも、 SettingsPasswordから パスワードを設定できるのでコマンドラインベースでサーバー側の結果も色々管理したい場合には パスワード設定しておいた方が便利だと思います。
Weckerをローカルで走らせてみる
走らせる前にDocker.appを起動させて置く必要があります。 特にVMを自分で作っておいたりする必要はありません。
取り敢えず簡単なテストとして適当なディレクトリを作って 中に以下の様なwercker.ymlを作ります。
1 2 3 4 5 6 | |
このディレクトリはGitのリポジトリでなくても構いません。 実行されるときはそのディレクトリの中身がコピーされる形になります。
buildのステップを実行して見るにはwercker buildを実行します。
$ wercker build
--> No Docker host specified, checking: /var/run/docker.sock
--> Executing pipeline
--> Running step: setup environment
Pulling from library/ruby: latest
Digest: sha256:6fce3ee90439d2d052495c2bb09b0a6303c608951b49dc2c6762a1b35c082bf6
Status: Image is up to date for ruby:latest
--> Copying source to container
--> Running step: wercker-init
--> Running step: Test run
Linux 09a3e28ddf7e 4.9.4-moby #1 SMP Wed Jan 18 17:04:43 UTC 2017 x86_64 GNU/Linux
--> Steps passed: 4.33s
--> Pipeline finished: 5.34s
Linux 09….の部分がuname -aコマンドの出力ですが
Macの中ですがLinuxが動いているのが分かります。
deployならwercker deployでテストできます。
Dockerベースなものだとこれら以外にも任意の名前でpipelineが作れるのですが、
Wercker CLIだとまだbuildとdeployしかサポートされてないみたいです。
Octopressのサイトのビルドでちょっとトラブル
準備が出来たのでこのブログのビルドのテストをしてみました。
$ wercker build
--> No Docker host specified, checking: /var/run/docker.sock
--> Executing pipeline
open /Users/user/Documents/octopress/.wercker/builds: no such file or directory
--> Running step: setup environment
...
Status: Downloaded newer image for ruby:latest
--> Copying source to container
--> Running step: wercker-init
--> Running step: Initialize git submodules
fatal: Not a git repository: /Users/user/Documents/octopress/.git/modules/.themes/octogray/modules/.plugins/octopress-hatebu-posts
Unable to find current revision in submodule path '.themes/octogray/.plugins/octopress-hatebu-posts'
Failed to recurse into submodule path '.themes/octogray'
--> Step failed: Initialize git submodules 1.49s
--> Pipeline failed: 68.12s
WARNING Box container has already stopped.
FATAL Step failed: Initialize git submodules
なにやらSubmoduleの設定あたりでおかしくなってる模様。
ちょっと調べてみると、
/Users/user/Documents/octopress/.themes/octogray/.plugins/octopress-hatebu-posts/.git
の内容が
gitdir: /Users/user/Documents/octopress/.git/modules/.themes/octogray/modules/.plugins/octopress-hatebu-posts
にとなってました。 GitでSubmoduleになるとそこには.gitディレクトリは出来ずに、 親の.gitディレクトリでまとめて管理するためにそこへのリンクが記述されています。 (この場合は親のoctograyのさらに親のoctopressのディレクトリの.git。)
これを見ると絶対パスを指定しています。 当然のことながらこれだとLinuxのコンテナにコピーされた後にこれを見ると 存在しないパスになってしまいます。
一方他のSubmodulesは
gitdir: ../../../../.git/modules/.themes/octogray/modules/.plugins/octopress-hatebu-posts
な感じで相対ディレクトリになっています。 ということでoctopress-hatebu-posts/.gitを上の様に書き直して やってみた所無事通りました。
この様な問題を持ってるものがoctograyのSubmodulesの中に 2つだけありましたがなぜなのか謎。
ただし、これらのSubmodulesはここでsubmodules addしてそのまま使い続けてるので
その辺で登録時に何か特殊ななことをしたのかも。
他でoctopressレポジトリなりoctograyレポジトリをcloneして Submodulesを取ってくると全て相対ディレクトリになっていました。
まとめ
MacでHomebrewを用いて環境を作るには
$ brew cask install docker
$ brew install wercker/wercker/wercker-cli
として必要な物をインストールし、 /Applications/Docker.appを起動。
これでwercker.ymlのあるディレクトリに行って、
$ wercker build
とすればbuildの内容をローカルで実行することが出来ます。
また、最初の例にある通り、ローカルで走らせる分にはGitのレポジトリで無くてもなんでも構いません。 コンテナも自分で作る事もできるわけで、 Webサービスとは別に自前のテスト環境を作ったりするのにもWercker CLIは有用なツールだと思います。