Herokuの'docker:release'の動き
Herokuの'docker:release'の動き Introducing ‘heroku docker:release’: Build & Deploy Heroku Apps with Docker HerokuがDockerを使ったツールを提供し始めた．一通り触ってコードもちょっと読んでみたので現時点でできること，内部の動きについてまとめる． TL;DR Herokuのデプロイ環境とおなじものをDockerでつくれる Buildpackを使わないでDockerfileからSlugを作れる 自分の好きなDockerイメージをHeroku上で動かせるようになるわけではない． 何ができるのか まず何ができるようになったのかについて簡単に書く．プラグインをインストールするとDockerコマンドが使えるようになる． $ heroku plugins:install heroku-docker
Go言語でプラグイン機構をつくる
dullgiulio/pingo Go言語でのプラグイン機構の提供方法は実装者の好みによると思う（cf. fluentd の go 実装におけるプラグイン構想）．Go言語はクロスコンパイルも含めビルドは楽なのでプラグインを含めて再ビルドでも良いと思う．が，使う人がみなGo言語の環境を準備しているとも限らないし，使い始めてもらう障壁はなるべく下げたい．プラグインのバイナリだけを持ってこればすぐに使えるという機構は魅力的だと思う． Go言語によるプラグイン機構はHashicorpの一連のプロダクトやCloudFoundryのCLIなどが既に提供していてかっこいい．net/rpcを使っているのは見ていてこれを自分で1から実装するのは面倒だなと思っていた． dullgiulio/pingoを使うと実装の面倒な部分を受け持ってくれて気軽にプラグイン機構を作れる． 使い方 サンプルに従ってプラグインを
Content Addressable DockerイメージとRegistry2.0
Content Addressable DockerイメージとRegistry2.0 Docker 1.6: Engine & Orchestration Updates, Registry 2.0, & Windows Client Preview | Docker Blog Docker1.6が出た．コンテナやイメージのラベリング（RancherOSの“Adding Label Support to Docker 1.6”がわかりやすい）や，Logging Driversといった新機能が追加された．今回のリリースで自分的に嬉しいのはDockerイメージがContent-addressableになったこと（#11109）． 今までDocker Regitryを介したイメージのやりとりはイメージの名前とタグ（e.g., tcnksm/golang:1.2）しか使うことができなかった．タグは
CoreOS Meetup Tokyo #1 を開催した
CoreOS Meetup Tokyo #1 を開催した CoreOS Meetup Tokyo #1 - connpass 今回のMeetupは，etcd2.0のリリースやrktの登場，5月のCoreOS Fest 2015，また各社のCoreOSの導入事例の兆しを受けての開催．といってもCoreOSの利用事例はまだ少ないと感じたため，CoreOSだけではなくその関連技術やプラットフォームをテーマとした．それでも20分の発表8本というとても濃いMeetupとなり非常に勉強になった．またそこまで人は集まらないと思っていたところ100人枠に350人の応募があり，注目の高さにも驚いた（次回は抽選にするなど考慮します）． 発表資料は全て，CoreOS Meetup Tokyo #1 - 資料一覧 - connpassにまとめてある．が，簡単にMeetupの内容をまとめておく．各種テーマが散ってい
Go言語のCLIツールのpanicをラップしてクラッシュレポートをつくる
mitchellh/panicwrap Go言語でpanicが発生したらどうしようもない．普通はちゃんとテストをしてそもそもpanicが発生しないようにする（もしくはトップレベルでrecoverする）．しかし，クロスコンパイルして様々な環境に配布することを，もしくはユーザが作者が思ってもいない使いかたをすることを考慮すると，すべてを作者の想像力の範疇のテストでカバーし，panicをゼロにできるとは限らない． panicが発生した場合，ユーザからすると何が起こったか分からない（Go言語を使ったことがあるユーザなら「あの表示」を見て，panicが起こったことがわかるかもしれない）．適切なエラーメッセージを表示できると良い．開発者からすると，そのpanicの詳しい発生状況を基に修正を行い，新たなテストケースを追加して二度とそのバグが発生しないようにしておきたい． mitchellh/panicw
Dockerコンテナ間のlink，database.ymlの書き方
Dockerコンテナ間のlink，database.ymlの書き方 DockerはLinksというコンテナ同士の連携を簡単に行う仕組みをもつ． これは，DB用のコンテナとアプリケーション用のコンテナの連携を行いたいときなどに有用になる． 例えば，1337ポートがEXPOSEされたcontainer1という名前のコンテナとの連携を行いたいとする． このとき以下のように，-link 連携したいコンテナ名:エイリアス名で新しいコンテナを起動すると， そのコンテナ内に連携したいコンテナのポート番号やIPをもった環境変数が現れる． docker run -d -link container1:alias user/sample bash root@48408a38c9b2:/# env ALIAS_PORT_5432_TCP_ADDR=172.17.0.2 ALIAS_PORT=tcp://172.
Serf 虎の巻
Serf 虎の巻 サービスディスカバリーとオーケストレーション用のツールであるSerfについてまとめた．基本的には公式のHPのGetting Startの抄訳．Vagrantで試験環境を立てて実際に触りつつSerfを使い始められるようにした． 目次 Serfとは Gossip protocolとは 試験環境の準備 クラスタの形成 クラスタからの離脱 イベントハンドラ カスタムイベント カスタムクエリ コマンド一覧 参考 Serfとは Serfはサービスディスカバリーやオーケストレーション，障害検出のためのツール．Vagrantの開発者であるMitchell Hashimoto氏により開発が進められている．SerfはImmutable Infrastructureの文脈で登場してきたツールであり，Immutableなシステムアーキテクチャー，デプロイを実現する上で必須のツールである． Imm
Dockerコンテナ接続パターン (2014年冬)
本記事はDocker Advent Calendar 2014の1日目の記事です． Dockerによるコンテナ化はリソース隔離として素晴らしい技術である．しかし，通常は1つのコンテナに全ての機能を詰め込むようなことはしない．マイクロサービス的にコンテナごとに役割を分け，それらを接続し，協調させ，全体として1つのサービスを作り上げるのが通常の使い方になっている． コンテナ同士の接続と言っても，シングルホスト内ではどうするのか，マルチホストになったときにどうするのかなど様々なパターンが考えられる．Dockerが注目された2014年だけでも，とても多くの手法や考え方が登場している． 僕の観測範囲で全てを追いきれているかは分からないが，現状見られるDockerコンテナの接続パターンを実例と共にまとめておく． なお今回利用するコードは全て以下のレポジトリをcloneして自分で試せるようになっている．
Dockerの諸問題とRocket登場の経緯
2014年の後半あたりからDocker，Docker Inc.への批判を多く見かけるようになった（もちろんもともと懸念や嫌悪を表明するひとはいた）．それを象徴する出来事としてCoreOSチームによる新しいコンテナのRuntimeであるRocketのリリースと，オープンなアプリケーションコンテナの仕様の策定を目指したApp Containerプロジェクトの開始があった． CoreOS is building a container runtime, Rocket 批判は，セキュリティであったり，ドキュメントされていない謎の仕様やバグだったり，コミュニティの運営だったり，と多方面にわたる．これらは具体的にどういうことなのか？なぜRocketが必要なのか？は具体的に整理されていないと思う．これらは，今後コンテナ技術を使っていく上で，オーケストレーションとかと同じくらい重要な部分だと思うので，ここ
CoreOSクラスタにDockerコンテナをデプロイする | SOTA
CoreOSクラスタにDockerコンテナをデプロイする Docker Meetup Tokyo #4 CoreOSの概要とDockerを実際に運用しようと思ったときにDockerが抱える問題をCoreOSがどのようにそれを解決するかについて発表した．デモではTerraformを使ってDigitalOcean上にCoreOSクラスタを立てて，デモアプリケーションコンテナを動的にスケールさせる様子を実演した（ソースは全てtcnksm/docker-meetup-4-demoにある）． 雑感 簡単にMeetupの感想を書いておく． 今回はDockerそのものの発表よりも，オーケストレーションやサービスディスカバリーなどの周辺ツールやサービスの発表が多かった．ツール（もしくはDocker専用のOS）では，CoreOS，Kubernetes，RedHad Atomic host，サービスではAma
DockerHubのAutomated Buildsをフックして最新のDockerコンテナをデプロイする
DockerHubのAutomated Buildsをフックして最新のDockerコンテナをデプロイする DockerHubのAutomated Buildsは，GithubやBitbucketへのgit pushをフックしてレポジトリ内のDockerfileを元にDockerイメージをビルドする機能である． イメージを使う側からすれば，それがどのようなDockfileから作られているか可視化され，常に新しいイメージがあることが保証されるので安心感がある．イメージを提供する側からすればDockerfileを更新してgit pushすれば自動でビルドしてくれくれるので楽という利点がある．そのためDockerHubにイメージを上げる場合は，docker pushを使うことはほとんどなくてこのAutomated Buildsを使うのが普通である． このAutomated BuildsはWeb h
Go言語でテストしやすいコマンドラインツールをつくる
本記事はGo Advent Calendar 2014の18日目の記事です． Go言語は，クロスコンパイルや配布のしやすさからコマンドラインツールの作成に採用されることが多い．自分もGo言語でいくつかのコマンドラインツールを作成してきた．例えば，GitHub Releaseへのツールのアップロードを簡単に行うghrというコマンドラインツールを開発をしている． コマンドラインツールをつくるときもテストは重要である．Go言語では標準テストパッケージだけで十分なテストを書くことができる．しかし，コマンドラインツールは標準出力や標準入力といったI/O処理が多く発生する．そのテスト，例えばある引数を受けたらこの出力を返し，この終了ステータスで終了するといったテストは，ちゃんとした手法が確立されているわけではなく，迷うことが多い（少なくとも自分は結構悩んだ）． 本記事では，いくつかのOSSツール（得に
CoreOSクラスタ内のDockerコンテナの動的リンク
CoreOSクラスタ内のDockerコンテナの動的リンク Dynamic Docker links with an ambassador powered by etcd 上記の記事を参考にCoreOSのクラスタ内で複数ホスト間にまたがりDockerコンテナを連携させる方法について検証した． 背景と問題 複数ホストにまたがりDockerのコンテナを接続する方法としてはAmbassador パターンが有名である．これはトラフィックを別ホストへforwardすることに特化したコンテナを立てる方法で，ホストに無駄な設定なし，かつDockerコンテナのみで行えるシンプルな方法である．例えば，あるホストからredis-cliを使って，別ホストで動くredisに接続する場合は以下のように接続する． (redis-cli) --> (ambassador) ---network---> (ambassad
Fleetの使い方，Unitファイルの書き方
Fleetの使い方，Unitファイルの書き方 CoreOSに入門した | SOTA CoreOSではすべてのアプリケーションをDockerで動かす．このとき，コンテナによるサービスをCoreOSクラスタのどのマシンで起動するかをいちいち人手で決めるわけにはいけない．クラスタ内のリソースの状態や動いているサービスに基づき，適切なマシンでコンテナを動かすスケジューリングの仕組みが必要になる． このスケジューリングとコンテナの管理にCoreOSはfleetを用いる． fleetを使うとCoreOSクラスタが1つのinit systemで動いているかのようにそれを扱うことができるようになる．開発者はどのマシンでどのDockerコンテナが動いているかを気にする必要がなくなる． 例えば，5つのコンテナを動かす必要があれば，fleetはクラスタのどこかでその5つのコンテナが動いてることを保証する．もしコ
CoreOSに入門した
CoreOS is Linux for Massive Server Deployments · CoreOS CoreOS + Docker Meetup Tokyo #1に参加してCoreOSにめっちゃ感動したので，CoreOSに入門していろいろ触ってみた． まず，CoreOSの概要とそれを支える技術について説明する．次に実際にDigitalOcenan上にVagrantを使って実際にCoreOSクラスタを立てて，CoreOSで遊ぶ方法について書く． CoreOSとは何か CoreOSは，GoogleやFacebook，Twitterといった企業が実現している柔軟かつスケーラブル，耐障害性の高いインフラの構築を目的としたLinuxディストリビューションである．軽量かつ使い捨てを前提にしており，クラウドなアーキテクチャのベストプラクティスを取り入れている．CoreOSの特徴は大きく4つ挙
Packerを使ってChef/Puppet/AnsibleでDockerのイメージをつくる
Packerを使ってChef/Puppet/AnsibleでDockerのイメージをつくる Packerは，Vagrantの作者であるMitchell Hashimoto氏によって開発が進められているVirtualBoxやVMWare，Amazon EC2などの仮想マシンのテンプレートの作成を行うツール．VagrantのVirtualBox用のBoxを作るveeweeに置き換わるツールとして知られている．最近のアップデートでDockerのイメージのビルドをサポートした． TL;DR Packerを使えばDockerのイメージをDockerfileを使わずビルドすることができる つまり，Dockerfileの特有な記述を使わず，今まで慣れ親しんできたChefやPuppet，Ansibleのようなプロビジョニングツールを使ってDockerのイメージをビルドできる． 参考 Dockerイメージの
複数プロジェクトを抱えるチームでのデプロイ自動化
複数プロジェクトを抱えるチームでのデプロイ自動化 1つのチームで，10以上のプロジェクト，コードベースを抱える場合にどのようにデプロイの自動化を進めたか，工夫したこと，考慮したことなどをまとめておく． デプロイツールには，Python製のfabricを採用しているが，他のツールでも同様のことはできそう．なお，fabricの基本的な使い方などは既にインターネット上に良い記事がたくさんあるので書かない（最後の参考の項を見てください）． fabricの選択 シェルスクリプトとCapistranoを考慮した． まず，シェルスクリプトは人によって書き方が違うため，統一が難しくメンテナンスコストも高い．また共通化も難しい． 次に，Capistranoは，裏でやってくれることが多く，学習コストも高い．プロジェクトによってはかなり特殊な環境へのデプロイも抱えているため，Capistranoの前提から外れる
CI-as-a-ServiceでGo言語プロジェクトの最新ビルドを継続的に提供する
CI-as-a-ServiceでGo言語プロジェクトの最新ビルドを継続的に提供する Go言語で作成したツールのリリース方法について，最近実践していることを書く． リリースは，ローカルから人手で行っている．具体的には，自分のローカル環境でクロスコンパイルし，セマンティック バージョニングによるタグをつけ，CHANGELOG.mdを丁寧に書いた上でリリースをしている．クロスコンパイルにはmitchellh/gox，リリースには自分で作成したtcnksm/ghrを使っている（ghrについては，“高速に自作パッケージをGithubにリリースするghrというツールをつくった”を参考）． その一方で，開発中の最新のビルドも提供するようにしている．例えば，こんな感じで，Pre-Releaseとして提供している．Go言語での開発なので，go getしてくださいと言える．しかし，環境によってビルドが失敗する
Werckerの仕組み，独自のboxとstepのつくりかた
Werckerの仕組み，独自のboxとstepのつくりかた WerckerはTravisCIやDrone.ioのようなCI-as-a-Serviceのひとつ．GitHubへのコードのPushをフックしてアプリケーションのテスト，ビルド，デプロイを行うことができる． Werckerは，TravisCIのように，レポジトリのルートにwercker.ymlを準備し，そこに記述された実行環境と実行コマンドをもとにテスト/ビルドを走らせる． Werckerには，その実行環境をbox，実行コマンド（の集合）をstepとして自作し，あらかじめWercker Directoryに登録しておくことで，様々なテストからそれらを呼び出して使うという仕組みがある．実際，Werkcerで標準とされているboxやstepも同様の仕組みで作成されている（wercker · GitHub）． 今回，WerkcerでのGo
boot2dockerでのVolume問題が解決しそう
boot2dockerでのVolume問題が解決しそう （追記）Docker 1.3がリリースされた．boot2dockerはデフォルトでVirtualBox Guest Additionsをサポートし，boot2docker-cliはinitのときにホストのディレクトリをboot2docker-vm上にマウントするようになった（Docker 1.3: signed images, process injection, security options, Mac shared directories | Docker Blog）． TL;DR OSXやWindowsでboot2dockerを使う場合に特別な操作をしなくても-vオプション（Volume）が使えるようになる． 背景 OSXやWindowsでboot2dockerを使うひとが最も不満に感じるのは-vオプション（Volume）が使
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
