rebuild.fmの今回のゲストはCoreOS Meetup Tokyoの@deeetさんでした。最近、CoreOS Meetup が話題になっていて、僕もCoreOS Meetup Tokyo #1で発表することになっているから、今回の rebuild.fm に興味深く聴きました。 僕が気になっていたのがこんな感じです。 Appc は一つのコンテナに複数のプロセスを実行できる これは確かに Appc と Docker の大きな哲学的な違いだね。複数のプロセスが同じマシンでともに動くというデザインパターンが多いのが複数の関係の強いプロセスをともに動かせるユースケースだと思います。これは確かにそうで、1周間で20億のコンテナを立ち上げるGoogleでは確かにこうパターンをよく使っている。けど、僕はどっちかというとDockerのコンテナとプロセスが１対１のパターンのほうが正しいと思っている。

Dockerの諸問題とRocket登場の経緯 Rocketはリリースした直後にちょっと触ってそのまま放置していた．App containerの一連のツールとRocketが現状どんな感じかをざっと触ってみる．まだまだ全然使えると思えないが今後差分だけ追えるようにしておく． なお，今回試した一連のツールをすぐに試せるVagrantfileをつくったので触ってみたいひとはどうぞ． https://github.com/tcnksm/vagrant-appc 概要 App Container SpecやRocketが登場の経緯は前回書いたのでここでは省略し，これらは一体何なのかを簡単に書いておく． まず，App Container（appc）Specはコンテナで動くアプリケーションの"仕様"である．なぜ仕様が必要かというと，コンテナという概念は今まで存在したが曖昧なものだったため．namespac

2014年の後半あたりからDocker，Docker Inc.への批判を多く見かけるようになった（もちろんもともと懸念や嫌悪を表明するひとはいた）．それを象徴する出来事としてCoreOSチームによる新しいコンテナのRuntimeであるRocketのリリースと，オープンなアプリケーションコンテナの仕様の策定を目指したApp Containerプロジェクトの開始があった． CoreOS is building a container runtime, Rocket 批判は，セキュリティであったり，ドキュメントされていない謎の仕様やバグだったり，コミュニティの運営だったり，と多方面にわたる．これらは具体的にどういうことなのか？なぜRocketが必要なのか？は具体的に整理されていないと思う．これらは，今後コンテナ技術を使っていく上で，オーケストレーションとかと同じくらい重要な部分だと思うので，ここ

Zero Downtime Deployments IntroductionAt Quay.io we are firm believers in Linux containers, after all, we have built our business around them. It is therefore natural that we use Docker extensively in our own infrastructure. We believe that using Docker and Quay.io greatly simplifies the task of deploying applications to production; in fact, we ourselves host the official Quay.io images on Quay.io

Cloud ComputingRed Hat Advanced Cluster Management for KubernetesRed Hat® Advanced Cluster Management for Kubernetes controls clusters and applications from a single console, with built-in security policies. Extend the value of Red Hat OpenShift® by deploying apps, managing multiple clusters, and enforcing policies across multiple clusters at scale. Red Hat’s solution ensures compliance, monitors

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

TerraformでCoreOSクラスタを構築する CoreOSはDigitalOceanやAmazon EC2，OpenStackなどあらゆるクラウドサービスやプラットフォームで動かすことができる．1つのCoreOSクラスタを複数のクラウドサービスや自社のベアメタルサーバーにまたがって構築することもできるし，それが奨励されている．また，クラスタのマシンの数はサービスの成長や負荷状況によって増減させる必要もある． このようなCoreOSクラスタの構築を簡単に，かつInfrastructure as Code的に再現可能な形で行いたい場合，HashicorpのTerraformを使うのがよさそう（個人的に試しているだけなので数百規模のマシンではなく，数十規模の話．もし膨大なマシン数になったときにどうするのがよいのか知見があれば知りたい）． 以下では，Terraformを使ってDigitalO

Interesting takeaways from the post:* Despite Brandon Philips (CoreOS CTO) serving on the Docker governance board, Docker has aggressively expanded their scope well beyond their original container manifesto. * CoreOS believes the Docker runtime is now too unwieldy and "fundamentally flawed"; the unwritten word that really sprung to mind was that Docker was getting "greedy." * CoreOS reaffirms thei

本記事はDocker Advent Calendar 2014の1日目の記事です． Dockerによるコンテナ化はリソース隔離として素晴らしい技術である．しかし，通常は1つのコンテナに全ての機能を詰め込むようなことはしない．マイクロサービス的にコンテナごとに役割を分け，それらを接続し，協調させ，全体として1つのサービスを作り上げるのが通常の使い方になっている． コンテナ同士の接続と言っても，シングルホスト内ではどうするのか，マルチホストになったときにどうするのかなど様々なパターンが考えられる．Dockerが注目された2014年だけでも，とても多くの手法や考え方が登場している． 僕の観測範囲で全てを追いきれているかは分からないが，現状見られるDockerコンテナの接続パターンを実例と共にまとめておく． なお今回利用するコードは全て以下のレポジトリをcloneして自分で試せるようになっている．

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