dockercon14が終わって、僕が注目したいのは、DockerHubとLibswarmです。

僕は、LibswarmとDockerHubの関係に関してgitとgithubの関係に似ているような気がしています。[速報]Docker Hub発表。ビルド、テスト、デプロイの自動化、Dockerイメージの管理など。Dockerのプラットフォーム化を推進(Publickey)にも書かれているように、“実行可能なアプリケーションのDockerイメージを管理する機能などを備えたサービス”なんだとすると、そのDockerイメージをCLIやプログラム内から使い倒すの必要なのがlibswarmではないかと思います。

DockerHub&libswarm共に未だ発表されて間もないしので検索してもあまり情報が見つからないのですが、次の幾つかのサイトを見ていると、新しい時代の幕開けが目の前で始まっている感じがし、ワクワクしてしかたがない。

• Docker: the road ahead
• Orchard + libswarm demo from DockerCon
• libswarm – Docker Orchestration Announced
• libswarm – Docker Orchestration Announced

そしてPublickeyの記事のまとめで、“ここから見えてくるのは、Docker社のチャレンジは単にLinuxのコンテナ技術を製品化するだけでなく、これまで主にOSベンダーが築いてきたOSを中心とした開発ツールやアプリケーションベンダーとのエコシステムを、コンテナ型仮想化技術を核に再構築しようとしているところです。いまのDockerの勢いを見ていると、このエコシステムの構築とDockerのプラットフォーム化の実現は一定のに説得力があるように思います。”って、非常に意味のある言葉のような気がしています。(僕は、”OSベンダー”を、”インフラ提供者”と理解してまとめに共感しています。)

githubエコシステムができたことで”コードに対する価値感”や”開発の進め方”が大きく変わったように、Dockerエコシステムが形成されていくことで、開発運用の方法が根底から変わっていくのではないかと思います。

そしてクラウドインフラの利用者側として、僕が今感じているのは、「今までのやり方は時代遅れになる、できるところから地道に次の準備を始めるしかない!」ってことかなぁと思う。

- 「時代遅れが、通用しない」とは言っておりません。
- インフラ供給者側の視点は、怖くて書けません…。

さすがにdcokercon14が開催されているということもあって、Dockerネタで2日連続で記事を掲載してきたか…。 ということで、この記事も日本語訳してみることにする。(超訳っぽいところは、寛大な心をもって読んでください。)

尚この記事を読む前にDcokerのドキュメントのRuntime Privilege and LXC Configurationの部分に目を通しておくと良いかもしれない。Datadog agentをインストールするコンテナは、このPrivilege機能を使って他のコンテナの情報にアクセスしていると思う。

Docker-ize Datadog with agent containers

Docker-ize Datadog with agent containers (原文)

Docker is an exciting technology that offers a different approach to building and running applications thanks to a clever combination of linux containers (good for ops) and a git-like approach to packaging software (good for dev) so that your containers have everything they need to run without dependencies.

Dockerは、アプリケーションシステムを構築し運用するための刺激的なテクノロジーです。 このテクノロジーは、Linuxコンテナとgitのようなソフトウェアパッケージングの巧みな組み合わせのおかげで、他に依存することなくそれ自身で完全に動作することができます。

Many of you who are using Docker are embracing the Docker way and taking a container-only approach. As we release our new Docker integration, we don’t want to force you to break from a container-only strategy because of the traditional Datadog agent architecture. Instead, we’ve also embraced the Docker way and we’re pleased to announce a Docker-ized Datadog agent deployed in a container.

Dockerを採用しているユーザーは、Dockerの一般的な用法(the Docker way)に従い自分たちのアプリケーション用コンテナのみを起動するアプローチ(container-only approach)を採用しているでしょう。 DatadogがDocker用の新しいIntegrationをリリースしたのは、旧バージョンのDatadog agentのアーキテクチャの問題で、Datadogユーザーが、container-onlyアプローチを断念してほしくなかったからです。DatadogではDocker用の新しいIntegrationにとどまらず、Dockerの一般的な用法(the Docker way)に従い、Datadog agentをインストールしたコンテナも準備しました。

The Docker philosophy

First, a brief introduction on how infrastructure is set up with Docker. In Docker, each of your applications is isolated in its own container. The blueprint for a container is its DockerFile which is a set of steps to create the container. These steps build the standard binaries and libraries and install your application’s code and its dependencies such as Python, Redis, Postgres, etc.

まず、Dockerでどのようにシステムインフラがセットアップされるか簡単に紹介します。 Dockerでは、各アプリケーションはコンテナごとに隔離されています。 各コンテナの設計図であるDockerFileには、コンテナの中身を設定していく手順が記述されています。 この設定手順には、標準的なバイナリやライブラリをビルドしたり、アプリケーションのコードとそのアプリケーションが依存するPython、Redis、Postgresなどの依存ファイルをインストールする手順が記述されています。

The Docker engine then creates the actual container to run using namespaces and cgroups. These are two features found in recent versions of the Linux kernel used to isolate system calls and resource usage (CPU, memory, disk I/O, etc.) directly on your server. The end result is multiple containers on the server with each application thinking it is in its own machine by itself, without the overhead associated with fully-virtualized machines.

Dockerエンジンは、名前空間とcgroupsを使用し実行用の実コンテナを準備します。 最近のLinuxカーネルは、これらの名前空間とcgroupsの機能を使い、システムコールの隔離とホストサーバ上のリソース(CPU, memory, disk I/O, etc.) に対する利用制限を実現しています。結果従来型の仮想化技術のようなパフォーマンス低下の影響をうけることなく、ホストサーバ上の個々コンテナ内のアプリケーションは、個別のマシンを占有し動作しているのと同じ状態になります。

The traditional Datadog set-up

Until Docker arrived, applications were built in virtual servers or directly on raw servers. In this case, you install the agent on your server and decide what applications and services you want to monitor in Datadog. If you want to send custom metrics to Datadog, you instrument your application with our Datadog version of StatsD, called DogStatsD. This set-up is illustrated below.

Dockerが一般化する以前は、アプリケーションは物理サーバか従来型仮想サーバ上に構築されていました。このような場合では、各サーバにDatadog agentをインストールし、監視対象のアプリケーションやサービスを決めていきます。任意のメトリックス(指標)をDatadogに転送したないなら、DogStatsD(DatadogバージョンのStatsD)を使って、アプリケーションにメトリック(指標)採取用のコードを追記することになります。

Datadog agentの配置は、次のような配置になります。

The traditional Datadog set-up in the Docker environment means the Datadog agent runs next to the Docker engine.

Docker環境での伝統的なDatadogのセットアップでは、Datadog agentをDokcerエンジンのとなりで起動していました。

Datadog the Docker Way

Because the Docker philosophy is to isolate applications to a container, we have built a “Docker-ized” installation of the Datadog agent. We have isolated the agent into two kinds of Docker containers. Both of the container installations can be illustrated by the diagram below.

Dockerの哲学がアプリケーションをコンテナに収納しそれぞれを隔離することなので、Datadogでも“Docker-ized”(コンテナに収納)したDatadog agentを作ってみました。

下記に示すdd-agent&dogstatsdコンテナ又はdogstatsdコンテナは、次の図のような配置になります。

The first container includes the Datadog agent plus DogStatsD. The Datadog agent is responsible for sending us both native host and container-specific metrics, like number of containers, load, memory, disk usage, and latency. DogStatsD will send us custom metrics you have instrumented in containerized applications. Again, you can read more about what exactly Datadog monitors in Docker in our Monitor Docker with Datadog post.

最初に紹介するコンテナには、Datadog agentとDogStatsDがインストールされています。 このコンテナのDatadog agentは、Dokcerをホストしているサーバとコンテナ固有のメトリック(指標)の両方を送信します。例えば、コンテナ数、負荷、メモリ、ディスク使用量、レーテンシー時間等が含まれます。DogStatsDは、コンテナ内に収めたアプリケーションに設定した任意のメトリックス(指標)を転送します。Datadogが、Dockerに関し収集しているメトリックスの詳細を調べる方法を知りたい場合は、Monitor Docker with Datadogの記事を参照してください。

1
2
3
4

FROM datadog/docker-dd-agent

# Set your API key
RUN sed -i -e"s/^.*api_key:.*$/api_key: EXAMPLE_API_KEY/" /etc/dd-agent/datadog.conf

If you only want to monitor custom metrics in containerized applications, the other Datadog container isolates DogstatsD so that you can send us custom metrics to monitor.

コンテナ内のアプリケーションの任意のメトリックス(指標)のみを監視したい場合は、DogstatsDを収納した別のDatadogコンテナ(dogstatsdコンテナ)を利用します。 このコンテナを利用することで、任意のメトリックス(指標)をDatadogに送信することができるようになります。

1
2
3
4

FROM datadog/docker-dogstatsd

# Set your API key
RUN sed -i -e"s/^.*api_key:.*$/api_key: EXAMPLE_API_KEY/" /etc/dd-agent/datadog.conf

For detailed documentation on how to install the Docker-ized Datadog containers, please visit our Docker installation guide.

Docker-ized Datadogコンテナのインストール方法に関する詳細は、Docker installation guideを参照してください。

As mentioned in the Monitor Docker with Datadog post, if you would like to alert on and visualize Docker metrics, you can sign-up for a 14-day free trial of Datadog. Docker metrics will be available immediately after installing the Datadog agent in its traditional format or as a container.

先のMonitor Docker with Datadogの記事でも書いたように、Dockerのメトリックス(指標)を使って状況の可視化や通知をしたい場合は、14日間のフリートライアルを試してみてください。 Datadog agentをインストールした後、直ちにDockerエンジン、コンテナ、ホストマシンのメトリックス(指標)を監視できるようになります。

by ZAHEDA HAIDRI (Datadog, Inc)

「今日は、dockercon14がサンフランシスコで開催されているな〜」と思っていたら、Datadog blogからもDocker関連の面白い記事が掲載されました。

Datadog agent 4.3.1をDockerホストOS上で起動し、他のアプリと同じようにIntegration用のYAMLファイルを設定することでDcoker内の各コンテナの状態をモニターリングできるということです。

Datadogの@alqが「もちろん翻訳してもいいよ〜! (Yes! Of course.)」言ってくれているので、次に日本語で同記事を転載します。

その前に次のシリーズを読んでおくと、Datadogはどうやってメトリックスを集めようしているのかが理解できると思います。

• 第3回　Linuxカーネルのコンテナ機能［2］ ─cgroupとは？（その1）
• 第2回　コンテナの仕組みとLinuxカーネルのコンテナ機能［1］名前空間とは？
• 第1回　LXCとコンテナの基本

Monitor Docker with Datadog

Monitor Docker with Datadog(原文)

Docker is an emerging platform to build and deploy software using lightweight, pared-down virtual machines known as containers. By delivering easy-to-provision recipes for developers and bit-for-bit compatibility between environments, Docker is a popular solution to solve continuous delivery in modern infrastructure.

Dockerは、既存の仮想環境から贅肉を削ぎ落とし軽量化したLinuxコンテナという仕組みを使用し、ソフトウェアシステムを構築&展開するための新たなプラットフォームです。Dockerは、アプリ開発者に簡単にプロビジョニングできるレシピを提供することと環境間の再現性を上げることで、現代インフラでの継続的デリバリーを実現する最も人気のある方法になりました。

Like virtual machines before them, containers require a new monitoring approach. Luckily, if you are a Datadog user, you can now take advantage of our newest integration: Docker.

従前の仮想マシンと同様に、Linuxコンテナでも新しい監視アプローチが必要にまります。Datadogユーザーであれば幸いなことに、最新のDocker Integrationの恩恵を受けることができます。

With our Docker integration you can monitor containers by running version 4.3.1 of the Datadog agent. The integration configuration is, like all other agent-based integrations, a simple YAML file.

バージョン4.3.1のDatadog agentを導入することで、Docker Integrationを使ってコンテナを監視することができるようになります。 Docker Integrationの設定方法は、今まであった他のアプリケーションのIntegrationと同じように簡単なYAMLファイル形式になっています。

How Docker monitoring works

The simplest way to monitor Docker containers is to run the Datadog Agent on the host, where it can access container statistics. This is especially true if you are deploying Docker on existing, full-fledged Host OSes, along existing applications such as databases.

Dcokerコンテナを監視するための最も簡単な方法は、コンテナのスタティック情報にアクセスできるホスト上でDatadog Agentを実行することです。本格的なホストOSにデータベースなどの既存のアプリケーションと共にDockerを展開するなら、尚更この方法は有効です。

Since Docker uses existing kernel constructs (namespaces and cgroups) in order to run containers, the Datadog Agent uses the native cgroup accounting metrics to gather CPU, memory, network and I/O metrics of the containers every 15 seconds before they are forwarded to Datadog.

Dockerは、コンテナを実行するために既存のカーネル構成体（名前空間とcgroup）を使用しています。 Datadog agentは、このカーネル構造体のcgroupか提供するトリックス(指標)を使ってCPU、メモリ、ネットワーク、15秒ごとのコンテナI/Oの情報を収集し、Datadogに転送しています。

Monitor many containers efficiently with tags

With easy-to-use, lightweight containers, you will likely dial up several times more running containers than the number of underlying physical or virtual hosts in your infrastructure. How do you then keep track and monitor them without spending time chasing after every single one of them? With tags.

簡単に使用でき軽量なコンテナを使うと、インフラストラクチャ内にある物理マシンまたは仮想ホストの数の数倍のコンテナを起動することになるでしょう。あなたらな、どのように時間をかけずに追跡し又監視しますか?　タグを使っては、どうでしょう!

Tags are the key to monitoring a lot of containers without additional effort. By default, the agent will monitor your containers and turn the Docker “name”, “image” and “command” attributes into a “tag”.

追加の努力をせずに大量のコンテナを監視するためには、タグ付けが有効な解決策です。何もしなくてもDatadog agentは、Dockerの「名前」,「イメージ名」,「コマンド」の属性をタグに追加します。

Graph specific metrics with tags

In Datadog, you define the metrics shown in dashboards and graphs based on one or many tags. This allows you to track specific metrics for many containers in aggregate. Using tags, you can easily create a graph for a metric drawn from all containers running a given image.

Datadogでは、タグの組み合わせに基づいてダッシュボードやグラフに表示するメトリック(指標)を定義することができます。この複数のタグの組み合わせによって統計的に複数のコンテナの特定のメトリックス(指標)を追跡することができるようになります。又タグを使用すると、同じDockerイメージから起動しているコンテナのメトリックス(指標)を手軽にグラフを描くこともできます。

In the example below, we are showing the amount of CPU consumed, broken down by image.

以下の例では、CPUの消費量をDockerイメージの分類で表示しています。

Alerts

Tags are also very useful to define alerts that span clusters of containers. For instance, let us say that you are running a cluster of Redis containers and you want to be alerted when one of the containers is running out of memory.

タグの使用は、コンテナをクラスター化し、そのクラスターにアラートを定義するのに非常に便利です。たとえば、Redisが起動しているコンテナのクラスターを運用中、クラスタ内のどれかのコンテナにメモリの不足が発生した場合に、アラートを受け取るようにしたいとしましょう​​。

Instead of defining one alert per container, you only have to create a multi-alert on the docker.mem.rss metric and Datadog will trigger an alert if any container misbehaves.

各コンテナごとにアラートの定義する代わりに、docker.mem.rssのメトリックス(指標)を基に、multi-alertを設定します。Datadogでは、この設定によって任意のコンテナでの誤作動によりアラートを送信することができます。

You can also mix and match tags to express more complex conditions. For instance, you can monitor all Redis containers running the redis2.8 image that run on host alq-docker with a simple tag selection:

又タグは、より複雑な条件を設定するためにタグを組み合わせてマッチングさせることができます。たとえば、簡単なタグ選択により、ホスト名alq-docker上で実行されているDockerイメージredis2.8のすべてのRedisのコンテナを監視することができます。

Monitor your containers’ lifecycles

Since containers are designed to be as short-lived (or long-lived) as traditional OS processes, it can be very useful to track particular containers throughout their lifecycles.

コンテナは、伝統的なOSのプロセスのように短期間しか存在しないように設計されています。従って、そのライフサイクルを通して状態を追跡することは非常に重要です。

Much like any other meaningful event in your infrastructure, you can search for Docker container create/start/stop/destroy events using the Events Stream. Simply use “sources:docker” as the search filter.

インフラ内の他の重要な出来事のように、Dockerコンテナのcreate/start/stop/destroy イベントは、Datadogのイベントストリームで検索することができます。検索フィルターでsources:dockerと入力し検索するだけです。

You can also apply the same search to any TimeBoard to visualize Docker container events in the context of Docker and non-Docker metrics. In the following example, we overlay containers starting and stopping over memory and CPU metrics.

更に、Dockerに関連したメトリックス(指標)とそれ以外のメトリック(指標)の検索結果を同一TimeBoardに混在させて表示することができます。次の例では、Dockerコンテナの起動と停止と、ホストマシンのメモリとCPUの消費量を同じTimeBoardで表示しています。

Explore Docker metrics

To explore the Docker metrics that are available, you can use the Metrics Explorer in Datadog and type “docker” in the first drop-down.

利用可能なDockerのメトリックス(指標)は、DatadogのMetrics Explorer画面内の最初のドロップダウンメニューでdockerと入力することで探索することができます。

You can find detailed descriptions about all the metrics in Docker’s Runtime Metrics guide.

これらのメトリックスの詳細に関しては、Docker’s Runtime Metrics guideを参照してください。

If you would like to easily visualize and alert on Docker metrics, try out Datadog for free with a 14-day trial. Metrics for the Docker engine, containers and underlying hosts will be immediately available after installing the Datadog agent.

Dockerのメトリックス(指標)を使って状況の可視化や通知をしたい場合は、14日間のフリートライアルを試してみてください。Datadog agentをインストールした後、直ちにDockerエンジン、コンテナ、ホストマシンのメトリックス(指標)を監視できるようになります。

by ALEXIS LÊ-QUÔC (CTO & co-founder Datadog, Inc)