macのVMの仮想ディスクの場所を変えられるようになるようです。macでDocker.qcow2というファイルが肥大化する件Docker便利ですね。macが出てからは、もうmac上には環境を作らないなんて運用も可能じゃないかというくらいです。実際、サーバサイド系の環境はほぼ全てDockerで運用してます。gulpとかでブラウザのオートリロードとかしたい場合はさすがに難しいので、そこはmac上に環境を作っておりますが。macを使っていくとディスク容量が日々減っていくのが実感出来るかと思います。macも実体はVMでありVMのディスクとして仮想ディスクがありこの仮想ディスクが~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linuxに作成されています。rmiでイメージを消したら良いのでは?と思うのですがそこはVM、仮想ディスクは一度領域を広げたら、通常運用では領域を解放してくれません。この仮想ディスクを手で小さくしてあげないといけないです。defaultsを選ぶこと。この仮想ディスクをクリアするコマンドでは、今までpullしたイメージや起動させたコンテナなども消してしまいます。Dockerの運用ではあまりないかとは思いますがコンテナにその場限りではあるけど変更を持っててコンテナとかを消したくない、といった場合はこの方法をとると大切な変更が失われてしまいます。そこで、仮想ディスクをshrinkする方法をとることで現状を維持したまま仮想ディスクを小さくする、といったことが可能になります。qemuでqemuというツールをインストールします。このqemuというのは、仮想マシンの一種になります。仮想マシンで有名なところですとVirtualBoxとかVMwareあたりになると思いますが、これらと似たソフトウェアになります。macで使用している仮想ディスクのフォーマットはこのqemuのディスクイメージフォーマットを採用しております。仮想ディスクのファイル名がDocker.qcow2となっています。qemuのインストールが完了したらこのツールの中の仮想ディスクを操作するコマンドがあるのでそのコマンドを使ってDocker.qcow2を変換かけます。変換をかける前に、考慮する部分があり通常ディスク上でファイルを削除した場合にはインデックス上で削除したという情報を管理して、実体は消えていない状態ですが通常の場合だとそこに上書きすることになるので、容量があるという見え方になりますが、仮想ディスクはそのインデックス上では削除されているけれど、実体がある場合も、ディスク容量として消費していることになります。この削除されているけれど実体がある部分を綺麗にしてから変換をすることで、効率よくファイルを小さくする事が出来ます。いうことで、実際に変換するためのコマンドは以下のようにします。これを実行する際に、いらないコンテナ、イメージは全て削除しておくことをお勧めします。-aで一覧表示されるコンテナの中からいらないものを全て削除します。imagesで表示されるイメージで不要そうなものを全て削除します。tty仮想ディスク内で削除されているファイル群を削除します。macのディスク上限)になるまでゼロ埋めファイルを作ってからそのファイルを消すということをやるので、macの容量が少ない場合は結構難しいです。自分の場合は、ddでサイズ指定(例えば、Docker.qcow2の現在のファイルサイズの半分くらい)をして、消してます。inをoffにしてquitしてmacを再起動してます。それから仮想ディスクファイルをshrinkします。Docker.qcow2.new実行時間は、そこそこ長いです。実行が終わると、Docker.qcow2.newというファイルが出来上がっていると思います。Docker.qcow2.new半分位になりましたね。出来上がったら、一応ですが古い方はリネームしておいて新しいものに差し替えます。無事に起動して、dockerコマンドが通るようになれば、問題なくshrinkが完了しました。古い方のDocker.qcow2を削除しましょう。これで、溜まりに溜まったDocker.qcow2のディスクが綺麗になりました。SYSTEMという仕組みで、バッテリーを長持ちにさせる代わりにグラフィックをIntelのチップセットのもを使うようにしたり、ハイパフォーマンスにしてNVIDIAを使うようにしたり、という設定がスイッチで付います。10にアップした後に撮ったので、LEDが点灯してないですが、本当はスイッチの向いてる方向のLEDが点灯します。これのおかげでモバイル用途もOKでゲームも楽しめるという贅沢な機種でした。10対応のドライバ類は提供されず。アップグレードのダイアログは出るもののディスプレイドライバが対応していません。(正式には忘れてしまいましたが)というワーニングが出るので自動アップデートはかけられない状態でした。10にしてもNVIDIAを使う事が出来そう、ということで意を決してアップグレードしてみました。このページを参考にさせていただきました。現在のNVIDIAの最新のドライバだと若干違う部分がありました。10で起動する訳ですが普通にIntelのグラフィックドライバで画面が表示されるので見た目的には問題なさそうな感じがします。NVIDIA使いたいので、インストーラをダウンロードして参考にさせていただいたページのようにドライバの情報を書き換え、さらに起動オプションでドライバ署名無効にしてインストール。半信半疑のままやってみたわけですが、一応使えるようにはなったみたい。なっていてそこをNVIDIAのに変えたらうまくいきました。ssh2のキーが見たことないフォーマットだった時の対処の仕方ある日、委託の方にサーバへのアクセス権を付与するためにSSHのキーをくださいと言ったら以下のようなフォーマットで送られてきた。----SECSH形式?という解らない形式のものらしい。思ってよくよく調べたら本来のSSHキーはこのような形式のようだ。(本当か??)今までOpenSSHに慣れすぎて来たという事なのかな。~/.ssh/authorized_keyとしてやれば良い。cloneすると他のブランチの情報とかも管理ディレクトリに持ってきている状態なのでディスク容量も食うし、cloneする時間もかかる。cloneするのが良い。[リポジトリ]こうすると、ブランチの最新のリビジョンだけを持ってきてくれる。今年の夏は暑い!そして、スマホも熱くなる!そんなときはこのタオルでサッと熱をとるといいかも今年は暑くてたまらないですね。スマホライフも熱との戦いとなりそうです。ゲームをするとさらに熱くなること間違いなしですね。機種によっては熱によってすぐに機能停止になったりするのもあるようです。ゲームなど割と長時間プレイする場合はバッテリーがもたずに充電しながらのプレイになるときも多々あるかと思います。充電しながらだと、非常に熱くなって持っているのもしんどくなるので、スマホの両端をつまむようにして持ちながらプレイしてたりします。そんなスタイルがちょっと辛かったのでなんとかして熱を取る事が出来ないか?と考えておりました。扇風機に当てるのも良いけどもう少しなんかさっと取れたりするといいなぁと。冷感敷きパッドというベッドに敷くタイプの安眠グッズがありそこでスマホをスリスリしてみました。したら、驚くほどスマホの熱が冷感敷きパッドに吸収されて、スマホの体感温度がすごく下がりました。それ以来、充電しながらスマホでゲームする場合は、冷感敷きパッドの上でスリスリしながらプレイしてます。外に出たときにも少しスリスリしたいなぁ。いうことで、今度はタオル状の冷感グッズを探してみました。[今治タオルの冷感グッズ]価格:1296円(税込、送料別)こんなのを見つけました。これは、見たところ冷感敷きパッドと同じタイプの素材で作られているようなので早速ぽちって見ました。※弱めのLEDスポットライトの部屋なので、色が変です。このタオルは、表が普通のタオル生地になっていて、裏側が冷感素材になっていました。こいつの裏側で、熱くなったスマホをスリスリ。スリスリ、スリスリスリスリスリスリスリ。スマホ持っても熱くない!でも、一つだけ欠点を見つけてしまった。タオルでスリスリしながらゲームプレイしてると、ゲームに実が入らない。ゲーム中以外でも発熱してきた場合に、このタオルでサッと熱を吸熱してスマホを冷ます事が出来るので発熱でバッテリーが心配、なんて感じるときは使ってみるといいかも?と思いました。あと、さすがに冷感敷きパッドのように広大な面積がある訳では無いので瞬時に吸熱出来る熱量も冷感敷きパッドには負けます。Exceeded」と言われる事が多くなり、定期的にワーカーの再起動をしたいと思ってました。見る限り、swapも出てしまい、レスポンスも遅くなっているようです。このような場合、heroku以外だと、unicornを使うので、unicorn_worker_killerを入れるのですがherokuだとpuma推薦なのでpuma使っていました。killer系の物があるのかな?と探してたところpuma_worker_killerがあるようなので、使ってみました。Restarts」というのを使うのが推薦のようなのでその設定で行ってみました。hoursendデフォルトだと6時間ごとに再起動ということになるので、ひとまず様子見で3時間に設定してみます。以下が、3時間でリスタートがかかるようにした設定になります。PumaWorkerKiller.enable_rolling_restartendこちらを設定したところピーク時は少しswapが出る時もあるものの、割と落ち着いたのかなと思います。この状態で様子見をし、アラートがまた増えるような感じであれば再度調整という事にしようと思います。ベンチャー・中小企業における開発チームの維持ベンチャー・中小企業における開発チームの維持と言うことで、またいくつかキーワードを挙げてみます。経営の視点から考えたとき、開発チームとして維持したい事は収益性のある機能について継続的に改修、機能追加が出来る事。将来に備えてスケール出来る仕組みを常に考えられるようにする。経営判断での急な対応も出来る。いったあたりがとくに重要となる。開発チーム視点から考えたときは、上記に加えメンバーのモチベーション維持。あたりが重要となりそうです。今回は開発チーム視点中心に少し考えてみます。モチベーション維持、これはメンバーそれぞれに異なるやる気スイッチが有るように思います。理想的なのは、その得意領域にそれぞれ割り当てするのがチームとしては最も効率が良くなります。サービスが軌道に乗るまでは、俗人化するのはある程度許容する事で、コミュニケーションコストが下げられ、本人はやりたい領域の事が出来、効率は上がります。前回も書きましたが、逆にモチベーションが下がる要因というのを排除していく事も重要となります。大きく影響するのはやはり人間関係で、信頼される事で大きく貢献出来るようにもなるし、本来以上の力を発揮出来ることもありますが、信頼されない状況があると、周囲にも影響があるので、ここは出来るだけ改善するようにしたいところです。これはおそらくどこの会社でもある問題ではあると思います。改善していくのか、ある時期に一気にリプレースするのか。これはどちらかが良いというのは、おそらくなくて、プロジェクトの状況や会社の収益なども影響してくると思います。そこがクリアになったとしてもチームとして技術的負債を改善していく空気が無ければ進まないので、日頃から少しでも改善していくための時間を作ったりTDDの意識をメンバーに持たせるようにするなりをしていく必要があります。そのための時間が必要と言うことをチーム外にも理解してもらう努力も必要です。新技術への挑戦や、新しいバージョンへのアップグレードが推奨される環境は、新しいことがやれている、という気持ちが持て、そこから社外にも知見共有などによってモチベーション維持とともに開発チームの技術力の底上げに貢献する事になります。知見の共有は、メンバーへの刺激になるとともに、自身の習得レベルの向上にも繋がるので推進したい所です。公式エンジニアブログなどは、上記に加え、会社としての技術のアピールも出来、意識の高いエンジニアが応募してくる可能性は上がるかもしれないため、将来の投資にもなりそうです。技術領域が公開されるため、スキルのミスマッチもある程度防げそうな気がします。bataがリリースされ、早速インストールしてみました。アプリケーションディレクトリに入れて、このアイコンをダブルクリックするだけでDockerの環境が自動的に構築されるようです。メニューバーにはDockerのアイコンが表示されるようになります。ToolboxでDockerを使っていた場合、この初回の起動時に既存環境を新しい環境で使えるように変換が行われます。(yesにした場合)今回は、全く新しい環境にインストールをしているので変換も何もなく、すぐにインストールが終わりました。変換した場合には、既存環境に応じて、それなりのディスク消費があるのでディスクの空きが少ない場合は要注意です。Dockerの環境としては、まだこれから試してみる事はたくさんありそうですがここで出てきた問題が、タイトルの通りpowと相性が悪そう、という点です。powは、Rackサーバで、ローカルでバーチャルホストを提供します。test-appというプロジェクトであれば、http://test-app.devでアクセスができるようになりますがtest-app.devは127.0.0.1になるので、localhostです。Macもポートを80番で指定してコンテナを起動したりするとhttp://localhost/でアクセスができるようになります。toolboxとは違いMac上でネイティブにハイパーバイザーを使って環境を構築しているようです。標準の設定のままだと、これらが衝突し、Dockerのコンテナにアクセスできない、といった状況が発生します。自分でもこのあたりが今出来る設定で回避可能なのかどうかは、調査中ではありますが覚書として書いてみました。Evernoteが値上げ!今ここでOneNoteと比較してみるEvernoteが値上げ&無料のベーシック版にさらに制限がつくようだ。ここで、今一度、自分なりにEvernoteとOneNoteの無料版の比較をしてみたいと思う。以前あったSkitchというアプリの機能がEvernoteのアプリに取り込まれているので、Evernoteアプリ内で簡単なドローツールやコメント追記などが出来る。制限なしここまで見て、個人的にはもうEvernoteしか無い訳ですが有料版になってくると少し違った考え方になる必要がありそうだ。Evernoteの有料版は、2種類あるが、プレミアムを想定して考える。有用な機能を上げてみるとPDF内の文字を検索Office文書の文字を検索ノートの履歴閲覧など。過去にミスってノートの中身を消してしまったことがあったが、履歴から戻せて事なきをえた経験からこの履歴閲覧は必須と思っている。Office1TB1274円/月いずれにしても月間の通信量制限はない。soloを契約することで、OneDriveが1TB付いてくると言う脅威のパフォーマンスが発揮される。1274円/月でOfficeとOneDriveが1TB付いてくるのであれば、これはお得だと思う。1TBを取るか両者どちらか一方だけを選ぶことが出来ず、自分の場合は両方選んでしまった。ウェブクリップ、通常のメモ用途としてのEvernoteOfficeや1TBのオンラインドライブとしてのOneDrive比較対象にあげたOneNoteは結局使っていない。サブシステム一式が削除出来るようだ。ユーザーを構成します。ユーザーが存在しない場合は作成されます。ユーザーを構成します。ユーザーが存在しない場合は作成されます。PreviewをONにしてみた最近、MacとWindowsの両方で似たような環境を作って作業することが多くなった訳ですが、どうもMacと比べると色々とWindowsの場合は開発環境といった面では劣る部分が多いというのを改めて感じました。これ、Windows10は開発用途以外の場合、結構使いやすいOSだと思っています。自分の場合はノートPCでタッチ画面付きのものなので、マウスが無くても、サッと画面をタッチできたりして便利です。ブラウジング用途でも手でスクロール出来る&拡大縮小が出来るというのは使ってみるとかなり便利な部分です。ブラウジングの操作がスマホでなれているというのもあるかもしれません。そこでMacを触ると、ついつい画面に手が行ってしまいがちです。あ、タッチ出来ないのか。思いつつタッチパッドをスルスルする訳です。10を開発環境として見た場合に、圧倒的に足りないのがコマンド操作周りだと感じました。昔はCygwinやらCoLinuxからVirtualPCやVMwareなど、仮想環境は結構手を出してきていましたがシームレスな環境というのはなかなか見つかりませんでした。最近はDockerを入れてコンテナ起動ですが、結局は裏でVirtualboxが起動しています。Windowsなる環境が試せるという話を聞き、これは入れるしかない。思いつつも要はベータなので、最悪環境が吹っ飛ぶかも?というところで躊躇してましたがふっきれました。ONにしちゃいましたよ。いうのも、最近Windowsがブルースクリーンになることが多く、どっちにしろリセットするなら、という気持ちが強くなってきました。あとは純粋に試したい!という事で。さっきONにしたわけですが、しばらく待たないと入らないようなので、続きはまたしばらく待ったあとにアップしたいと思います。Updateとして降ってきました。入れたらまた別途追記します。追記2早速bashをONにしてみます。(Bata)というところにチェックを付けてOKを押します。ここで、一度再起動します。コマンドプロンプトでbashと入力してリターンです。すると、インストールするかどうかを聞かれるので、yと入力します。アカウントとパスワードを最初に入力すると、文字は化けますが正常にインストールされたようです。Windowsという項目が出来ています。これを起動するとbashが使えるようです。Dockerfileを作っている最中にデバッグするときの基本的な手順Dockerfileを作っている最中に動作確認中に途中で落ちてしまって、その状態でイメージの中身を確認したい時とかが多々あるかと思いますが今回はそんなやり方、定番かもしれないですが書いてみようと思います。適当なDockerfileを作ってビルドします。.このビルド時にエラーが出てイメージの作成が止まったという想定です。imagesにはというイメージが出来ています。こいつはDockerfile上のタスク(RUNとかADDとかの単位)で正常に処理が完了した状態が一時的にイメージ化されているものです。-aで表示される停止しているコンテナが持っています。このコンテナに入ることが出来れば、失敗の原因を調べる事ができそうですね。startしてしまうと、このコマンドが動いて終わるのでこのコンテナを一時的にイメージにしちゃいます。buildで失敗した時点のコンテナに入る事が出来ました。watchの機能をフルに使ったデプロイになります。watchで起動されるデプロイツールがstretcherになります。s3://example/manifest.ymlクラスタリスタートさせる場合/etc/consul.d/web.confに定義出来るnameservicetagsの設定で頑張る事でなんとかなりそう。s3://example/manifest-prerelease.ymlとして手で叩くでも良い。prereleaseとすると、サーバ1だけにイベントが飛びます。productionとすると、サーバ1とサーバ2にイベントが飛びます。stagingとすると、サーバ3だけにイベントが飛びます。reloadすれば、設定が更新されます。s3://example/manifest-prerelease.ymlとすれば、1台だけリリース可能。全台デプロイを検知する仕組みとしてconsulの持つKey/Valueの仕組みを利用すると実現可能。http://localhost:8500/v1/kv/deployFailureをしておく。http://localhost:8500/v1/kv/deployFailure/{`hostname`}としておく。http://localhost:8500/v1/kv/deploy/?keysを監視。http://localhost:8500/v1/kv/deployFailure/?keysを取得しエラーがないことをチェックしてデプロイフローの完了となる。感想という事で、イベントを送る先をtagsで良い感じに制御出来ればconsulとstretcherによるデプロイは良さそうな気がします。全台デプロイ完了の検知は、consulのイベントとかステータスとかだけでやりたかった。引き続き良い方法があれば調べたい。manifest.ymlはデプロイスクリプト(capistrano?)で自動で更新されるようにしたいため、ここにhook処理が羅列されるのは嬉しくない。ソースを固めてs3に上げてmanifest.ymlを作るという部分はまだ考慮しきれていない。各サーバでserviceにcheckという設定(このページではconsulの基本的な設定のweb.json)を付けると、指定したチェックが通るまではserviceとしては追加されないのでロードバランサにぶら下げるときにもconsulのヘルスチェックを見てゴニョゴニョ出来たらいいのかと思ったりしました。gendosu.jpのデザインを修正しました実は、一つまえのgendosu.jpは、全体的に字が大きくてお年寄り向けになっていた(おい!!)気がしたので今回思い切って新しいデザインに変えてみました。こんな感じから.......こんな感じへ。アイキャッチ画像も出るようにしました。なんかヘッダ周辺、最近っぽくないですか??個人的にはなんか良い感じになったと思います。検索もボタンが付いてわかりやすい。レスポンシブなので、スマホで見てもタブレットで見てもそれらしく表示されます。これでアクセスがアップ!となれば良いのですが。ま、ただのテーマ変えですが。開発サイクルをブースト!するかもしれない。Dokku触ってみた(初期編)開発環境って、一度作るとあとはそれほどいじらないのでいいんですが適当に作ったけど適当に社内で公開したい場合にお気軽にデプロイしたい。Capistrano使ったりするのもいいんだけど...。それに、小さめのツール類が多いんだけど、毎回nginx立ててポート変えてとかconfでゴニョゴニョして公開するの、面倒。デプロイしたら即公開みたいな環境ないかなー。herokuみたいな。思って探したらdokkuというのがあったので、触ってみました。dokkuとはOSSのherokuライクなPaaS実装。dokkuを入れたサーバに対してgitでプッシュするだけでデプロイ完了します。バックエンド(MySQLとかRedisとか)はプラグインで対応。公式https://github.com/dokku/dokku調査まずは手元で動作確認。vagrantを使っての動作確認をしていきます。何も入っていないvagrantのvmを起動します。バージョン違いで動かないのは嫌なので、公式通りUbuntu14使います。--no-provisionとしてください。upしばらく待つと起動する。起動したらvmにログインします。ssh続いて、dokkuのインストール。公式にある通りにコマンドを入れます。bootstrap.shで初期設定画面が待機しているので、開いてこれが完了すると、http://[dokkuを入れたサーバのIP]/id_rsa.pubのキーとドメイン名を設定して初期設定します。初期設定画面で入れるドメインは、とりあえず触る程度であればドメイン名にIPを含ませて叩くと常にそのIPを返してくれるというxip.ioというサービスがあるので、これを使います。dokkuを本番に組み込むようなことがある場合、自分でワイルドカードドメインを設定する必要があると思います。いうことで、vagrantで起動したvmのIPを使ってドメイン名を作ります。dokku.172.28.128.5.xip.ioこんな感じになるかと思います。Setupボタンを押すと、設定が完了します。続いて、ローカルのマシンの方にdokkuのクライアントを入れていきます。公式のshellでやるのが手っ取り早いので、そのままコマンド実行します。dokku='$HOME/.dokku/contrib/dokku_client.sh'ローカルに適当にテスト用のrailsプロジェクトを作ってデプロイしてみましょう。これでローカルのマシンでdokkuコマンドが使えるようになりました。Applicationからサンプルリポジトリを使ってデプロイします。ruby-rails-sampleサーバに入って、postgreSQLのプラグインを入れておきます。https://github.com/dokku/dokku-postgres.git再びローカルで、postgresqlサービスを作成して、アプリにリンクさせておきます。ruby-rails-sampleデプロイはherokuとほとんど一緒です。これで、デプロイ準備は整いました。-vvでdokkuが追加されていると思います。apps:createで作成される)このリポジトリに対してpushするだけでアプリがデプロイ出来ます。master早速デプロイされたアプリにアクセスしてみます。dokku.192.168.1.1.xip.io以上です。cloneそのままという印象。裏でdockerが動いているが、ほぼ意識しなくて良い。dokkuはスタンドアローンな仕組みなので、スケールさせるサービスには向かないと思います。社内で適当にサイトを立ち上げてプレビューするとか外部公開でも絶対にアクセスが増えないとかローカルだけどherokuみたいに気軽にデプロイしてサーバで動いているのを確認したいとかそーいう用途向きのプロダクトに感じました。スケールさせることが前提なのであればdeisやflynnといったプロダクトを使ってみるのがいいかもしれません。Mesosあたりを試してみるのもいいかもしれません。gitにExcelファイルあげちゃった。gitにExcelファイルあげちゃった。エンジニア以外にもgithubを使い出しているところが増えつつありますが、このような要望が少なくありません。エンジニアとしては、それはExcelがちょっと・・・という感じかもしれませんが非エンジニアとしてはExcelが自分の仕事の表現手段、というかやはり操作感は他のツールとは別格かと思います。そこにエンジニア目線で別のツールを押しつけるのもどうかと思ったりもします。※別のツールを提供した方が効率が上がるケースももちろんあるので、その場合は提供した方が良いです。いうことで、Excelファイルをgitにあげて管理したい、しかも差分も見たいと言った場合gitの設定を少しいじると雑ですが差分が出るようにはなります。PATH=$PATH:~/git-xlsx-textconv/bin"~/.gitconfigを開きます。cloneしたリポジトリの直下に.gitattributeファイルを作成します。diff=xlsxを追記します。これでxlsxの結果が比較できるようになりました。Yahooボックスの無制限プランから移行されたプランがよい以前、Yahooボックスで無制限プランが存在した頃、加入したのは良いけど色々不具合がたえなく、いくつかファイルも失い、今に至る訳ですが、無制限プランが終了するというタイミングで、プランに加入しているユーザー限定ではありますが、という感じに基本プランの容量が1.5TBに拡張されておりました。今の所、基本プランの容量拡張プランがという価格設定なので、旧無制限プランの1.5TB追加は歪んだ状態と言えそうです。将来のどこかでOneDriveのようにプランの整理をするタイミングが来る気がします。一時的にでも使えるのであれば使って行きたいと思っています。Editorで、プロジェクト内のファイルが多すぎてキーワード検索をかけると結果が多すぎて、そこからさらに検索かけたくなったりします。このディレクトリ内だけ検索したい、なんて感じで条件が指定出来れば随分絞り込めると思います。Project普段、検索する時はこんな感じで検索画面が開くと思います。この3段目、検索する場所を絞る設定になっています。lib配下だけを検索したい場合にはここにlib1libと入れれば良い訳です。複数の場所から検索したい場合はlib,app,public1lib,app,publicとすれば、libとappとpublicのディレクトリから検索出来ます。publicの下に無駄に大きいassetsのautocompile結果が同時に格納されていたとしてその下は検索したくない、なんていう時はlib,app,public,!public/assets1lib,app,public,!public/assetsとすれば、public/assets配下は無視されるようになります。応用で、gitでsubmoduleを多用している場合、.git配下も検索対象になってしまいますが!.git1!.gitとしておくだけで、.git配下は無視するようになります。*という感じでしょうか。Dockerを使っていく上で避けて通れないChef,ansibleとの付き合い方こんにちは。最近はローカルの開発環境も、ほとんどDockerに移行した感じです。そこで、本番も見据えたDockerという事で気になることの一つ構成管理ツールchef、ansibleなどなどとの兼ね合い、どうするかな?と言ったところ考えてみようと思います。Dockerはコンテナ作成・管理ツールという性質上、コンテナ内部のパッケージやアプリの配備などをDockerfileで行う仕組みになっています。いうことは、端的に言ってしまうとchef、ansibleなどがなくてもコンテナを作れてしまいます。Dockerで作ったコンテナに対してchefを流して環境を作る、とか意味がありません。Dockerfileの中でChefを呼ぶのはありか?という所ですが個人的にはこれもあまり嬉しくないなと思います。Dockerfileを見るだけで、そのコンテナがどんな環境になるのか、というのが一発でわかるようにしたいです。構成管理ではないですが、Dockerでシェル叩いていたり、起動する単一プロセスに構成設定のシェルを指定しているDockerfileが割と多かったりしますが、これも実際何しているのか?というのをシェル見ないと分からなくなってしまうので避けるようにしています。使わないのか?と言われると、NOでDockerをそもそも動かすホストマシン側の構成管理についてはChef、ansibleが使える物と思っています。swarmあたりのインストールを自動化しとくのが良いと思います。することで、ホストマシンが自前だろうがAWSだろうがIDCFだろうがさくらだろうがさらにOSがUbuntuでもCentOSでも、ホストマシンを自動で構築することも可能になってきます。engineさえ入っていればコンテナが動くわけです。docker-machineを使う場合、docker-machineが対応しているクラウドサービスの場合は構成管理しなくても良い位手軽に起動する事が出来たりします。これは、docker-machineのcreateで作成されるホストには、docker-machineが自動で上記のモジュール類を入れて環境設定してしまうためです。Dockerを本気で使っている方々には当然の内容ではありますが、以上、一つの考え方として参考にしていただけたらと思います。