Grafana 是一个有着丰富指标的开源控制面板。在可视化大规模测量数据的时候是非常有用的。根据不同的指标数据，它提供了一个强大、优雅的来创建、分享和浏览数据的方式。

它提供了丰富多样、灵活的图形选项。此外，针对 数据源 （ Data Source ） ，它支持许多不同的存储后端。每个数据源都有针对特定数据源的特性和功能所定制的查询编辑器。Grafana 提供了对下述数据源的正式支持：Graphite、InfluxDB、OpenTSDB、 Prometheus、Elasticsearch 和 Cloudwatch。

每个数据源的查询语言和能力显然是不同的，你可以将来自多个数据源的数据混合到一个单一的仪表盘上，但每个 面板 （ Panel ） 被绑定到属于一个特定 组织 （ Organization ） 的特定数据源上。它支持验证登录和基于角色的访问控制方案。它是作为一个独立软件部署，使用 Go 和 JavaScript 编写的。

在这篇文章，我将讲解如何在 Ubuntu 16.04 上安装 Grafana 并使用这个软件配置 Docker 监控。

先决条件

• 安装好 Docker 的服务器

安装 Grafana

我们可以在 Docker 中构建我们的 Grafana。 有一个官方提供的 Grafana Docker 镜像。请运行下述命令来构建Grafana 容器。

root@ubuntu:~# docker run -i -p 3000:3000 grafana/grafana

Unable to find image 'grafana/grafana:latest' locally
latest: Pulling from grafana/grafana
5c90d4a2d1a8: Pull complete
b1a9a0b6158e: Pull complete
acb23b0d58de: Pull complete
Digest: sha256:34ca2f9c7986cb2d115eea373083f7150a2b9b753210546d14477e2276074ae1
Status: Downloaded newer image for grafana/grafana:latest
t=2016-07-27T15:20:19+0000 lvl=info msg="Starting Grafana" logger=main version=3.1.0 commit=v3.1.0 compiled=2016-07-12T06:42:28+0000
t=2016-07-27T15:20:19+0000 lvl=info msg="Config loaded from" logger=settings file=/usr/share/grafana/conf/defaults.ini
t=2016-07-27T15:20:19+0000 lvl=info msg="Config loaded from" logger=settings file=/etc/grafana/grafana.ini
t=2016-07-27T15:20:19+0000 lvl=info msg="Config overriden from command line" logger=settings arg="default.paths.data=/var/lib/grafana"
t=2016-07-27T15:20:19+0000 lvl=info msg="Config overriden from command line" logger=settings arg="default.paths.logs=/var/log/grafana"
t=2016-07-27T15:20:19+0000 lvl=info msg="Config overriden from command line" logger=settings arg="default.paths.plugins=/var/lib/grafana/plugins"
t=2016-07-27T15:20:19+0000 lvl=info msg="Path Home" logger=settings path=/usr/share/grafana
t=2016-07-27T15:20:19+0000 lvl=info msg="Path Data" logger=settings path=/var/lib/grafana
t=2016-07-27T15:20:19+0000 lvl=info msg="Path Logs" logger=settings path=/var/log/grafana
t=2016-07-27T15:20:19+0000 lvl=info msg="Path Plugins" logger=settings path=/var/lib/grafana/plugins
t=2016-07-27T15:20:19+0000 lvl=info msg="Initializing DB" logger=sqlstore dbtype=sqlite3

t=2016-07-27T15:20:20+0000 lvl=info msg="Executing migration" logger=migrator id="create playlist table v2"
t=2016-07-27T15:20:20+0000 lvl=info msg="Executing migration" logger=migrator id="create playlist item table v2"
t=2016-07-27T15:20:20+0000 lvl=info msg="Executing migration" logger=migrator id="drop preferences table v2"
t=2016-07-27T15:20:20+0000 lvl=info msg="Executing migration" logger=migrator id="drop preferences table v3"
t=2016-07-27T15:20:20+0000 lvl=info msg="Executing migration" logger=migrator id="create preferences table v3"
t=2016-07-27T15:20:20+0000 lvl=info msg="Created default admin user: [admin]"
t=2016-07-27T15:20:20+0000 lvl=info msg="Starting plugin search" logger=plugins
t=2016-07-27T15:20:20+0000 lvl=info msg="Server Listening" logger=server address=0.0.0.0:3000 protocol=http subUrl=

我们可以通过运行此命令确认 Grafana 容器的工作状态 docker ps -a 或通过这个URL访问 http://Docker IP:3000。

所有的 Grafana 配置设置都使用环境变量定义，在使用容器技术时这个是非常有用的。Grafana 配置文件路径为 /etc/grafana/grafana.ini。

理解配置项

Grafana 可以在它的 ini 配置文件中指定几个配置选项，或可以使用前面提到的环境变量来指定。

配置文件位置

通常配置文件路径：

• 默认配置文件路径 : $WORKING_DIR/conf/defaults.ini
• 自定义配置文件路径 : $WORKING_DIR/conf/custom.ini

PS：当你使用 deb、rpm 或 docker 镜像安装 Grafana 时，你的配置文件在 /etc/grafana/grafana.ini。

理解配置变量

现在我们看一些配置文件中的变量：

• instance_name：这是 Grafana 服务器实例的名字。默认值从 ${HOSTNAME} 获取，其值是环境变量HOSTNAME，如果该变量为空或不存在，Grafana 将会尝试使用系统调用来获取机器名。

• [paths]：这些路径通常都是在 init.d 脚本或 systemd service 文件中通过命令行指定。

  • data：这个是 Grafana 存储 sqlite3 数据库（如果使用）、基于文件的会话（如果使用），和其他数据的路径。
  • logs：这个是 Grafana 存储日志的路径。

• [server]

  • http_addr：应用监听的 IP 地址，如果为空，则监听所有的接口。
  • http_port：应用监听的端口，默认是 3000，你可以使用下面的命令将你的 80 端口重定向到 3000 端口：$iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3000
  • root_url : 这个 URL 用于从浏览器访问 Grafana 。
  • cert_file : 证书文件的路径（如果协议是 HTTPS）。
  • cert_key : 证书密钥文件的路径（如果协议是 HTTPS）。

• [database]：Grafana 使用数据库来存储用户和仪表盘以及其他信息，默认配置为使用内嵌在 Grafana 主二进制文件中的 SQLite3。

  • type：你可以根据你的需求选择 MySQL、Postgres、SQLite3。
  • path：仅用于选择 SQLite3 数据库时，这个是数据库所存储的路径。
  • host：仅适用 MySQL 或者 Postgres。它包括 IP 地址或主机名以及端口。例如，Grafana 和 MySQL 运行在同一台主机上设置如： host = 127.0.0.1:3306。
  • name：Grafana 数据库的名称，把它设置为 Grafana 或其它名称。
  • user：数据库用户（不适用于 SQLite3）。
  • password：数据库用户密码（不适用于 SQLite3）。
  • ssl_mode：对于 Postgres，使用 disable，require，或 verify-full 等值。对于 MySQL，使用 true，false，或 skip-verify。
  • ca_cert_path：（只适用于 MySQL）CA 证书文件路径，在多数 Linux 系统中，证书可以在 /etc/ssl/certs 找到。
  • client_key_path：（只适用于 MySQL）客户端密钥的路径，只在服务端需要用户端验证时使用。
  • client_cert_path：（只适用于 MySQL）客户端证书的路径，只在服务端需要用户端验证时使用。
  • server_cert_name：（只适用于 MySQL）MySQL 服务端使用的证书的通用名称字段。如果 ssl_mode 设置为 skip-verify 时可以不设置。

• [security]

  • admin_user：这个是 Grafana 默认的管理员用户的用户名，默认设置为 admin。
  • admin_password：这个是 Grafana 默认的管理员用户的密码，在第一次运行时设置，默认为 admin。
  • login_remember_days：保持登录/记住我的持续天数。
  • secret_key：用于保持登录/记住我的 cookies 的签名。

设置监控的重要组件

我们可以使用下面的组件来创建我们的 Docker 监控系统。

• cAdvisor：它被称为 Container Advisor。它给用户提供了一个资源利用和性能特征的解读。它会收集、聚合、处理、导出运行中的容器的信息。你可以通过这个文档了解更多。
• InfluxDB：这是一个包含了时间序列、度量和分析数据库。我们使用这个数据源来设置我们的监控。cAdvisor 只展示实时信息，并不保存这些度量信息。Influx Db 帮助保存 cAdvisor 提供的监控数据，以展示非某一时段的数据。
• Grafana Dashboard：它可以帮助我们在视觉上整合所有的信息。这个强大的仪表盘使我们能够针对 InfluxDB 数据存储进行查询并将他们放在一个布局合理好看的图表中。

Docker 监控的安装

我们需要一步一步的在我们的 Docker 系统中安装以下每一个组件：

安装 InfluxDB

我们可以使用这个命令来拉取 InfluxDB 镜像，并部署了 influxDB 容器。

root@ubuntu:~# docker run -d -p 8083:8083 -p 8086:8086 --expose 8090 --expose 8099 -e PRE_CREATE_DB=cadvisor --name influxsrv tutum/influxdb:0.8.8
Unable to find image 'tutum/influxdb:0.8.8' locally
0.8.8: Pulling from tutum/influxdb
a3ed95caeb02: Already exists
23efb549476f: Already exists
aa2f8df21433: Already exists
ef072d3c9b41: Already exists
c9f371853f28: Already exists
a248b0871c3c: Already exists
749db6d368d0: Already exists
7d7c7d923e63: Pull complete
e47cc7808961: Pull complete
1743b6eeb23f: Pull complete
Digest: sha256:8494b31289b4dbc1d5b444e344ab1dda3e18b07f80517c3f9aae7d18133c0c42
Status: Downloaded newer image for tutum/influxdb:0.8.8
d3b6f7789e0d1d01fa4e0aacdb636c221421107d1df96808ecbe8e241ceb1823

    -p 8083:8083 : user interface, log in with username-admin, pass-admin
    -p 8086:8086 : interaction with other application
    --name influxsrv : container have name influxsrv, use to cAdvisor link it.

你可以测试 InfluxDB 是否安装好，通过访问这个 URL http://你的 IP 地址:8083，用户名和密码都是 ”root“。

我们可以在这个界面上创建我们所需的数据库。

安装 cAdvisor

我们的下一个步骤是安装 cAdvisor 容器，并将其链接到 InfluxDB 容器。你可以使用此命令来创建它。

root@ubuntu:~# docker run --volume=/:/rootfs:ro --volume=/var/run:/var/run:rw --volume=/sys:/sys:ro --volume=/var/lib/docker/:/var/lib/docker:ro --publish=8080:8080 --detach=true --link influxsrv:influxsrv --name=cadvisor google/cadvisor:latest -storage_driver_db=cadvisor -storage_driver_host=influxsrv:8086
Unable to find image 'google/cadvisor:latest' locally
latest: Pulling from google/cadvisor
09d0220f4043: Pull complete
151807d34af9: Pull complete
14cd28dce332: Pull complete
Digest: sha256:8364c7ab7f56a087b757a304f9376c3527c8c60c848f82b66dd728980222bd2f
Status: Downloaded newer image for google/cadvisor:latest
3bfdf7fdc83872485acb06666a686719983a1172ac49895cd2a260deb1cdde29
root@ubuntu:~#

    --publish=8080:8080 : user interface
    --link=influxsrv:influxsrv: link to container influxsrv
    -storage_driver=influxdb: set the storage driver as InfluxDB
    Specify what InfluxDB instance to push data to:
    -storage_driver_host=influxsrv:8086: The ip:port of the database. Default is ‘localhost:8086’
    -storage_driver_db=cadvisor: database name. Uses db ‘cadvisor’ by default

你可以通过访问这个地址来测试安装 cAdvisor 是否正常 http://你的 IP 地址:8080。 这将为你的 Docker 主机和容器提供统计信息。

安装 Grafana 控制面板

最后，我们需要安装 Grafana 仪表板并连接到 InfluxDB，你可以执行下面的命令来设置它。

root@ubuntu:~# docker run -d -p 3000:3000 -e INFLUXDB_HOST=localhost -e INFLUXDB_PORT=8086 -e INFLUXDB_NAME=cadvisor -e INFLUXDB_USER=root -e INFLUXDB_PASS=root --link influxsrv:influxsrv --name grafana grafana/grafana
f3b7598529202b110e4e6b998dca6b6e60e8608d75dcfe0d2b09ae408f43684a

现在我们可以登录 Grafana 来配置数据源. 访问 http://你的 IP 地址:3000 或 http://你的 IP 地址（如果你在前面做了端口映射的话）:

• 用户名 - admin
• 密码 - admin

一旦我们安装好了 Grafana，我们可以连接 InfluxDB。登录到仪表盘并且点击面板左上方角落的 Grafana 图标（那个火球）。点击 数据源 （ Data Sources ） 来配置。

现在你可以添加新的 图形 （ Graph ） 到我们默认的数据源 InfluxDB。

我们可以通过在 测量 （ Metric ） 页面编辑和调整我们的查询以调整我们的图形。

关于 Docker 监控，你可用从此了解更多信息。 感谢你的阅读。我希望你可以留下有价值的建议和评论。希望你有个美好的一天。

via: http://linoxide.com/linux-how-to/monitor-docker-containers-grafana-ubuntu/

作者：Saheetha Shameer 译者：Bestony 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

我在红帽工作的期间，每天在 Fedora Atomic host 上使用 Docker 容器。 来自 原子项目 （ Project Atomic ） 的 原子主机 （ Atomic Host ） 是一个轻量级容器操作系统，可以以 Docker 格式运行 Linux 容器。它专门为提高效率而定制，使其成为用于云环境的 Docker 运行时系统的理想选择。

幸运的是，我发现一个很好的方式来管理在主机上运行的容器：Cockpit。 它是一个具有漂亮的 Web 界面的 GNU/Linux 服务器远程管理工具。它可以帮我管理在主机上运行的服务器和容器。你可以在从之前发布在这里的这篇概述中了解 Cockpit 的更多信息。不过，我也希望在主机上可以自动运行容器，我可以使用 Ansible 来完成这个工作。

请注意，我们不能在原子主机上使用 dnf 命令。原子主机并没有设计为通用操作系统，而是更适合容器和其他用途。但在原子主机上设置应用程序和服务仍然非常容易。这篇文章向您展示了如何自动化和简化这个过程。

设置组件

开始之前，请确保你的系统上安装了 Ansible。

sudo dnf -y install ansible

首先，我们需要在原子主机上运行 cockpit 容器。在你的机器上从 https://github.com/trishnaguha/fedora-cloud-ansible 下载它的源代码。

$ git clone https://github.com/trishnaguha/fedora-cloud-ansible.git

现在切换到 cockpit 的目录，并如下编辑 inventory 文件：

$ cd fedora-cloud-ansible
$ cd cockpit
$ vim inventory

完成如下修改：

1. 使用你的原子主机的 IP 替换掉 IP_ADDRESS_OF_HOST。
2. 用您的 SSH 私钥文件的路径替换 ansible_ssh_private_key_file ='PRIVATE_KEY_FILE' 行中的PRIVATE_KEY_FILE。

然后保存并退出 inventory 文件编辑。

接下来，编辑 ansible 配置文件：

$ vim ansible.cfg

替换 remote_user=User 中 User 为你的原子主机上的远程用户名。然后保存并退出文件编辑。

结合起来

现在是运行 Ansible 的 PlayBook 的时候了。此命令开始运行原子主机上的 Cockpit 容器：

$ ansible-playbook cockpit.yml

Cockpit 现在运行在原子主机上了。使用浏览器去访问你的实例的公网 IP 的 9090 端口——这是 Cockpit 的默认端口。举个例子，如果该实例的 IP 地址是 192.168.1.4，就去访问 192.168.1.4:9090，你将会看到如下的 Web 界面：

管理你的容器

使用原子主机的登录信息或以 root 用户身份登录。然后访问 Cockpit 管理器上的 Containers 部分来查看原子主机上运行的容器。在下面的示例中，您会看到我还设置了其他容器，如 httpd 和 redis：

注意，该界面允许您直接在 Cockpit 管理器中使用 Run 和 Stop 按钮启动和停止容器。您还可以使用 Cockpit 管理器管理您的原子主机。转到 Tools -> Terminals，在这里里你可以使用原子主机的终端：

如果您打算在原子主机上部署容器化的应用程序，则可以简单地为其编写一个 PlayBook。然后，您可以使用 ansible-playbook 命令进行部署，并使用 Cockpit 来管理容器。

欢迎你对这个仓库进行分支或添加容器的 PlayBook。

via: https://fedoramagazine.org/deploy-containers-atomic-host-ansible-cockpit/

作者：trishnag 译者：Bestony 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

如果你正在运行 Swarm 模式的集群，或者只运行单台 Docker，你都会有下面的疑问：

我如何才能监控到它们都在干些什么？

这个问题的答案是“很不容易”。

你需要监控下面的参数：

1. 容器的数量和状态。
2. 一台容器是否已经移到另一个节点了，如果是，那是在什么时候，移动到哪个节点？
3. 给定节点上运行着的容器数量。
4. 一段时间内的通信峰值。
5. 孤儿卷和网络（LCTT 译注：孤儿卷就是当你删除容器时忘记删除它的卷，这个卷就不会再被使用，但会一直占用资源）。
6. 可用磁盘空间、可用 inode 数。
7. 容器数量与连接在 docker0 和 docker_gwbridge 上的虚拟网卡数量不一致（LCTT 译注：当 docker 启动时，它会在宿主机器上创建一个名为 docker0 的虚拟网络接口）。
8. 开启和关闭 Swarm 节点。
9. 收集并集中处理日志。

本文的目标是介绍 Elasticsearch + Kibana + cAdvisor 的用法，使用它们来收集 Docker 容器的参数，分析数据并产生可视化报表。

阅读本文后你可以发现有一个监控仪表盘能够部分解决上述列出的问题。但如果只是使用 cAdvisor，有些参数就无法显示出来，比如 Swarm 模式的节点。

如果你有一些 cAdvisor 或其他工具无法解决的特殊需求，我建议你开发自己的数据收集器和数据处理器（比如 Beats），请注意我不会演示如何使用 Elasticsearch 来集中收集 Docker 容器的日志。

“你要如何才能监控到 Swarm 模式集群里面发生了什么事情？要做到这点很不容易。” —— @fntlnz

我们为什么要监控容器？

想象一下这个经典场景：你在管理一台或多台虚拟机，你把 tmux 工具用得很溜，用各种 session 事先设定好了所有基础的东西，包括监控。然后生产环境出问题了，你使用 top、htop、iotop、jnettop 各种 top 来排查，然后你准备好修复故障。

现在重新想象一下你有 3 个节点，包含 50 台容器，你需要在一个地方查看整洁的历史数据，这样你知道问题出在哪个地方，而不是把你的生命浪费在那些字符界面来赌你可以找到问题点。

什么是 Elastic Stack ？

Elastic Stack 就一个工具集，包括以下工具：

• Elasticsearch
• Kibana
• Logstash
• Beats

我们会使用其中一部分工具，比如使用 Elasticsearch 来分析基于 JSON 格式的文本，以及使用 Kibana 来可视化数据并产生报表。

另一个重要的工具是 Beats，但在本文中我们还是把精力放在容器上，官方的 Beats 工具不支持 Docker，所以我们选择原生兼容 Elasticsearch 的 cAdvisor。

cAdvisor 工具负责收集、整合正在运行的容器数据，并导出报表。在本文中，这些报表被到入到 Elasticsearch 中。

cAdvisor 有两个比较酷的特性：

• 它不只局限于 Docker 容器。
• 它有自己的 Web 服务器，可以简单地显示当前节点的可视化报表。

设置测试集群，或搭建自己的基础架构

和我以前的文章一样，我习惯提供一个简单的脚本，让读者不用花很多时间就能部署好和我一样的测试环境。你可以使用以下（非生产环境使用的）脚本来搭建一个 Swarm 模式的集群，其中一个容器运行着 Elasticsearch。

如果你有充足的时间和经验，你可以 搭建自己的基础架构 （ Bring Your Own Infrastructure，BYOI ） 。

如果要继续阅读本文，你需要：

• 运行 Docker 进程的一个或多个节点（docker 版本号大于等于 1.12）。
• 至少有一个独立运行的 Elasticsearch 节点（版本号 2.4.X）。

重申一下，此 Elasticsearch 集群环境不能放在生产环境中使用。生产环境也不推荐使用单节点集群，所以如果你计划安装一个生产环境，请参考 Elastic 指南。

对喜欢尝鲜的用户的友情提示

我就是一个喜欢尝鲜的人（当然我也已经在生产环境中使用了最新的 alpha 版本），但是在本文中，我不会使用最新的 Elasticsearch 5.0.0 alpha 版本，我还不是很清楚这个版本的功能，所以我不想成为那个引导你们出错的关键。

所以本文中涉及的 Elasticsearch 版本为最新稳定版 2.4.0。

测试集群部署脚本

前面已经说过，我提供这个脚本给你们，让你们不必费神去部署 Swarm 集群和 Elasticsearch，当然你也可以跳过这一步，用你自己的 Swarm 模式引擎和你自己的 Elasticserch 节点。

执行这段脚本之前，你需要：

• Docker Machine – 最终版：在 DigitalOcean 中提供 Docker 引擎。
• DigitalOcean API Token: 让 docker 机器按照你的意思来启动节点。

创建集群的脚本

现在万事俱备，你可以把下面的代码拷到 create-cluster.sh 文件中：

#!/usr/bin/env bash
#
# Create a Swarm Mode cluster with a single master and a configurable number of workers

workers=${WORKERS:-"worker1 worker2"}

#######################################
# Creates a machine on Digital Ocean
# Globals:
#   DO_ACCESS_TOKEN The token needed to access DigitalOcean's API
# Arguments:
#   $1 the actual name to give to the machine
#######################################
create_machine() {
  docker-machine create \
    -d digitalocean \
    --digitalocean-access-token=$DO_ACCESS_TOKEN \
    --digitalocean-size 2gb \
    $1
}

#######################################
# Executes a command on the specified machine
# Arguments:
#   $1     The machine on which to run the command
#   $2..$n The command to execute on that machine
#######################################
machine_do() {
  docker-machine ssh $@
}

main() {

  if [ -z "$DO_ACCESS_TOKEN" ]; then
    echo "Please export a DigitalOcean Access token: https://cloud.digitalocean.com/settings/api/tokens/new"
    echo "export DO_ACCESS_TOKEN=<yourtokenhere>"
    exit 1
  fi

  if [ -z "$WORKERS" ]; then
    echo "You haven't provided your workers by setting the \$WORKERS environment variable, using the default ones: $workers"
  fi

  # Create the first and only master
  echo "Creating the master"

  create_machine master1

  master_ip=$(docker-machine ip master1)

  # Initialize the swarm mode on it
  echo "Initializing the swarm mode"
  machine_do master1 docker swarm init --advertise-addr $master_ip

  # Obtain the token to allow workers to join
  worker_tkn=$(machine_do master1 docker swarm join-token -q worker)
  echo "Worker token: ${worker_tkn}"

  # Create and join the workers
  for worker in $workers; do
    echo "Creating worker ${worker}"
    create_machine $worker
    machine_do $worker docker swarm join --token $worker_tkn $master_ip:2377
  done
}

main $@

赋予它可执行权限：

chmod +x create-cluster.sh

创建集群

如文件名所示，我们可以用它来创建集群。默认情况下这个脚本会创建一个 master 和两个 worker，如果你想修改 worker 个数，可以设置环境变量 WORKERS。

现在就来创建集群吧。

./create-cluster.sh

你可以出去喝杯咖啡，因为这需要花点时间。

最后集群部署好了。

现在为了验证 Swarm 模式集群已经正常运行，我们可以通过 ssh 登录进 master：

docker-machine ssh master1

然后列出集群的节点：

docker node ls

ID                           HOSTNAME  STATUS  AVAILABILITY  MANAGER STATUS
26fi3wiqr8lsidkjy69k031w2 *  master1   Ready   Active        Leader
dyluxpq8sztj7kmwlzs51u4id    worker2   Ready   Active
epglndegvixag0jztarn2lte8    worker1   Ready   Active

安装 Elasticsearch 和 Kibana

注意，从现在开始所有的命令都运行在主节点 master1 上。

在生产环境中，你可能会把 Elasticsearch 和 Kibana 安装在一个单独的、大小合适的实例集合中。但是在我们的实验中，我们还是把它们和 Swarm 模式集群安装在一起。

为了将 Elasticsearch 和 cAdvisor 连通，我们需要创建一个自定义的网络，因为我们使用了集群，并且容器可能会分布在不同的节点上，我们需要使用 overlay 网络（LCTT 译注：overlay 网络是指在不改变现有网络基础设施的前提下，通过某种约定通信协议，把二层报文封装在 IP 报文之上的新的数据格式，是目前最主流的容器跨节点数据传输和路由方案）。

也许你会问，“为什么还要网络？我们不是可以用 link 吗？” 请考虑一下，自从引入用户定义网络后，link 机制就已经过时了。

以下内容摘自 Docker 文档：

在 Docker network 特性出来以前，你可以使用 Docker link 特性实现容器互相发现、安全通信。而在 network 特性出来以后，你还可以使用 link，但是当容器处于默认桥接网络或用户自定义网络时，它们的表现是不一样的。

现在创建 overlay 网络，名称为 monitoring：

docker network create monitoring -d overlay

Elasticsearch 容器

docker service create --network=monitoring \
  --mount type=volume,target=/usr/share/elasticsearch/data \
  --constraint node.hostname==worker1 \
  --name elasticsearch elasticsearch:2.4.0

注意 Elasticsearch 容器被限定在 worker1 节点，这是因为它运行时需要依赖 worker1 节点上挂载的卷。

Kibana 容器

docker service create --network=monitoring --name kibana -e ELASTICSEARCH_URL="http://elasticsearch:9200" -p 5601:5601 kibana:4.6.0

如你所见，我们启动这两个容器时，都让它们加入 monitoring 网络，这样一来它们可以通过名称（如 Kibana）被相同网络的其他服务访问。

现在，通过 routing mesh 机制，我们可以使用浏览器访问服务器的 IP 地址来查看 Kibana 报表界面。

获取 master1 实例的公共 IP 地址：

docker-machine ip master1

打开浏览器输入地址：http://[master1 的 ip 地址]:5601/status

所有项目都应该是绿色：

让我们接下来开始收集数据！

收集容器的运行数据

收集数据之前，我们需要创建一个服务，以全局模式运行 cAdvisor，为每个有效节点设置一个定时任务。

这个服务与 Elasticsearch 处于相同的网络，以便于 cAdvisor 可以推送数据给 Elasticsearch。

docker service create --network=monitoring --mode global --name cadvisor \
  --mount type=bind,source=/,target=/rootfs,readonly=true \
  --mount type=bind,source=/var/run,target=/var/run,readonly=false \
  --mount type=bind,source=/sys,target=/sys,readonly=true \
  --mount type=bind,source=/var/lib/docker/,target=/var/lib/docker,readonly=true \
  google/cadvisor:latest \
  -storage_driver=elasticsearch \
  -storage_driver_es_host="http://elasticsearch:9200"

注意：如果你想配置 cAdvisor 选项，参考这里。

现在 cAdvisor 在发送数据给 Elasticsearch，我们通过定义一个索引模型来检索 Kibana 中的数据。有两种方式可以做到这一点：通过 Kibana 或者通过 API。在这里我们使用 API 方式实现。

我们需要在一个连接到 monitoring 网络的正在运行的容器中运行索引创建命令，你可以在 cAdvisor 容器中拿到 shell，不幸的是 Swarm 模式在开启服务时会在容器名称后面附加一个唯一的 ID 号，所以你需要手动指定 cAdvisor 容器的名称。

拿到 shell：

docker exec -ti <cadvisor-container-name> sh

创建索引：

curl -XPUT http://elasticsearch:9200/.kibana/index-pattern/cadvisor -d '{"title" : "cadvisor*",  "timeFieldName": "container_stats.timestamp"}'

如果你够懒，可以只执行下面这一句：

docker exec $(docker ps | grep cadvisor | awk '{print $1}' | head -1) curl -XPUT http://elasticsearch:9200/.kibana/index-pattern/cadvisor -d '{"title" : "cadvisor*",  "timeFieldName": "container_stats.timestamp"}'

把数据汇总成报表

你现在可以使用 Kibana 来创建一份美观的报表了。但是不要着急，我为你们建了一份报表和一些图形界面来方便你们入门。

访问 Kibana 界面 => Setting => Objects => Import，然后选择包含以下内容的 JSON 文件，就可以导入我的配置信息了：

[
  {
    "_id": "cAdvisor",
    "_type": "dashboard",
    "_source": {
      "title": "cAdvisor",
      "hits": 0,
      "description": "",
      "panelsJSON": "[{\"id\":\"Filesystem-usage\",\"type\":\"visualization\",\"panelIndex\":1,\"size_x\":6,\"size_y\":3,\"col\":1,\"row\":1},{\"id\":\"Memory-[Node-equal->Container]\",\"type\":\"visualization\",\"panelIndex\":2,\"size_x\":6,\"size_y\":4,\"col\":7,\"row\":4},{\"id\":\"memory-usage-by-machine\",\"type\":\"visualization\",\"panelIndex\":3,\"size_x\":6,\"size_y\":6,\"col\":1,\"row\":4},{\"id\":\"CPU-Total-Usage\",\"type\":\"visualization\",\"panelIndex\":4,\"size_x\":6,\"size_y\":5,\"col\":7,\"row\":8},{\"id\":\"Network-RX-TX\",\"type\":\"visualization\",\"panelIndex\":5,\"size_x\":6,\"size_y\":3,\"col\":7,\"row\":1}]",
      "optionsJSON": "{\"darkTheme\":false}",
      "uiStateJSON": "{}",
      "version": 1,
      "timeRestore": false,
      "kibanaSavedObjectMeta": {
        "searchSourceJSON": "{\"filter\":[{\"query\":{\"query_string\":{\"query\":\"*\",\"analyze_wildcard\":true}}}]}"
      }
    }
  },
  {
    "_id": "Network",
    "_type": "search",
    "_source": {
      "title": "Network",
      "description": "",
      "hits": 0,
      "columns": [
        "machine_name",
        "container_Name",
        "container_stats.network.name",
        "container_stats.network.interfaces",
        "container_stats.network.rx_bytes",
        "container_stats.network.rx_packets",
        "container_stats.network.rx_dropped",
        "container_stats.network.rx_errors",
        "container_stats.network.tx_packets",
        "container_stats.network.tx_bytes",
        "container_stats.network.tx_dropped",
        "container_stats.network.tx_errors"
      ],
      "sort": [
        "container_stats.timestamp",
        "desc"
      ],
      "version": 1,
      "kibanaSavedObjectMeta": {
        "searchSourceJSON": "{\"index\":\"cadvisor*\",\"query\":{\"query_string\":{\"analyze_wildcard\":true,\"query\":\"*\"}},\"highlight\":{\"pre_tags\":[\"@kibana-highlighted-field@\"],\"post_tags\":[\"@/kibana-highlighted-field@\"],\"fields\":{\"*\":{}},\"fragment_size\":2147483647},\"filter\":[]}"
      }
    }
  },
  {
    "_id": "Filesystem-usage",
    "_type": "visualization",
    "_source": {
      "title": "Filesystem usage",
      "visState": "{\"title\":\"Filesystem usage\",\"type\":\"histogram\",\"params\":{\"addLegend\":true,\"addTimeMarker\":false,\"addTooltip\":true,\"defaultYExtents\":false,\"mode\":\"stacked\",\"scale\":\"linear\",\"setYExtents\":false,\"shareYAxis\":true,\"times\":[],\"yAxis\":{}},\"aggs\":[{\"id\":\"1\",\"type\":\"avg\",\"schema\":\"metric\",\"params\":{\"field\":\"container_stats.filesystem.usage\",\"customLabel\":\"USED\"}},{\"id\":\"2\",\"type\":\"terms\",\"schema\":\"split\",\"params\":{\"field\":\"machine_name\",\"size\":5,\"order\":\"desc\",\"orderBy\":\"1\",\"row\":false}},{\"id\":\"3\",\"type\":\"avg\",\"schema\":\"metric\",\"params\":{\"field\":\"container_stats.filesystem.capacity\",\"customLabel\":\"AVAIL\"}},{\"id\":\"4\",\"type\":\"terms\",\"schema\":\"segment\",\"params\":{\"field\":\"container_stats.filesystem.device\",\"size\":5,\"order\":\"desc\",\"orderBy\":\"1\"}}],\"listeners\":{}}",
      "uiStateJSON": "{\"vis\":{\"colors\":{\"Average container_stats.filesystem.available\":\"#E24D42\",\"Average container_stats.filesystem.base_usage\":\"#890F02\",\"Average container_stats.filesystem.capacity\":\"#3F6833\",\"Average container_stats.filesystem.usage\":\"#E24D42\",\"USED\":\"#BF1B00\",\"AVAIL\":\"#508642\"}}}",
      "description": "",
      "version": 1,
      "kibanaSavedObjectMeta": {
        "searchSourceJSON": "{\"index\":\"cadvisor*\",\"query\":{\"query_string\":{\"analyze_wildcard\":true,\"query\":\"*\"}},\"filter\":[]}"
      }
    }
  },
  {
    "_id": "CPU-Total-Usage",
    "_type": "visualization",
    "_source": {
      "title": "CPU Total Usage",
      "visState": "{\"title\":\"CPU Total Usage\",\"type\":\"area\",\"params\":{\"shareYAxis\":true,\"addTooltip\":true,\"addLegend\":true,\"smoothLines\":false,\"scale\":\"linear\",\"interpolate\":\"linear\",\"mode\":\"stacked\",\"times\":[],\"addTimeMarker\":false,\"defaultYExtents\":false,\"setYExtents\":false,\"yAxis\":{}},\"aggs\":[{\"id\":\"1\",\"type\":\"avg\",\"schema\":\"metric\",\"params\":{\"field\":\"container_stats.cpu.usage.total\"}},{\"id\":\"2\",\"type\":\"date_histogram\",\"schema\":\"segment\",\"params\":{\"field\":\"container_stats.timestamp\",\"interval\":\"auto\",\"customInterval\":\"2h\",\"min_doc_count\":1,\"extended_bounds\":{}}},{\"id\":\"3\",\"type\":\"terms\",\"schema\":\"group\",\"params\":{\"field\":\"container_Name\",\"size\":5,\"order\":\"desc\",\"orderBy\":\"1\"}},{\"id\":\"4\",\"type\":\"terms\",\"schema\":\"split\",\"params\":{\"field\":\"machine_name\",\"size\":5,\"order\":\"desc\",\"orderBy\":\"1\",\"row\":true}}],\"listeners\":{}}",
      "uiStateJSON": "{}",
      "description": "",
      "version": 1,
      "kibanaSavedObjectMeta": {
        "searchSourceJSON": "{\"index\":\"cadvisor*\",\"query\":{\"query_string\":{\"query\":\"*\",\"analyze_wildcard\":true}},\"filter\":[]}"
      }
    }
  },
  {
    "_id": "memory-usage-by-machine",
    "_type": "visualization",
    "_source": {
      "title": "Memory [Node]",
      "visState": "{\"title\":\"Memory [Node]\",\"type\":\"area\",\"params\":{\"shareYAxis\":true,\"addTooltip\":true,\"addLegend\":true,\"smoothLines\":false,\"scale\":\"linear\",\"interpolate\":\"linear\",\"mode\":\"stacked\",\"times\":[],\"addTimeMarker\":false,\"defaultYExtents\":false,\"setYExtents\":false,\"yAxis\":{}},\"aggs\":[{\"id\":\"1\",\"type\":\"avg\",\"schema\":\"metric\",\"params\":{\"field\":\"container_stats.memory.usage\"}},{\"id\":\"2\",\"type\":\"date_histogram\",\"schema\":\"segment\",\"params\":{\"field\":\"container_stats.timestamp\",\"interval\":\"auto\",\"customInterval\":\"2h\",\"min_doc_count\":1,\"extended_bounds\":{}}},{\"id\":\"3\",\"type\":\"terms\",\"schema\":\"group\",\"params\":{\"field\":\"machine_name\",\"size\":5,\"order\":\"desc\",\"orderBy\":\"1\"}}],\"listeners\":{}}",
      "uiStateJSON": "{}",
      "description": "",
      "version": 1,
      "kibanaSavedObjectMeta": {
        "searchSourceJSON": "{\"index\":\"cadvisor*\",\"query\":{\"query_string\":{\"query\":\"*\",\"analyze_wildcard\":true}},\"filter\":[]}"
      }
    }
  },
  {
    "_id": "Network-RX-TX",
    "_type": "visualization",
    "_source": {
      "title": "Network RX TX",
      "visState": "{\"title\":\"Network RX TX\",\"type\":\"histogram\",\"params\":{\"addLegend\":true,\"addTimeMarker\":true,\"addTooltip\":true,\"defaultYExtents\":false,\"mode\":\"stacked\",\"scale\":\"linear\",\"setYExtents\":false,\"shareYAxis\":true,\"times\":[],\"yAxis\":{}},\"aggs\":[{\"id\":\"1\",\"type\":\"avg\",\"schema\":\"metric\",\"params\":{\"field\":\"container_stats.network.rx_bytes\",\"customLabel\":\"RX\"}},{\"id\":\"2\",\"type\":\"date_histogram\",\"schema\":\"segment\",\"params\":{\"field\":\"container_stats.timestamp\",\"interval\":\"s\",\"customInterval\":\"2h\",\"min_doc_count\":1,\"extended_bounds\":{}}},{\"id\":\"3\",\"type\":\"avg\",\"schema\":\"metric\",\"params\":{\"field\":\"container_stats.network.tx_bytes\",\"customLabel\":\"TX\"}}],\"listeners\":{}}",
      "uiStateJSON": "{\"vis\":{\"colors\":{\"RX\":\"#EAB839\",\"TX\":\"#BF1B00\"}}}",
      "description": "",
      "savedSearchId": "Network",
      "version": 1,
      "kibanaSavedObjectMeta": {
        "searchSourceJSON": "{\"filter\":[]}"
      }
    }
  },
  {
    "_id": "Memory-[Node-equal->Container]",
    "_type": "visualization",
    "_source": {
      "title": "Memory [Node=>Container]",
      "visState": "{\"title\":\"Memory [Node=>Container]\",\"type\":\"area\",\"params\":{\"shareYAxis\":true,\"addTooltip\":true,\"addLegend\":true,\"smoothLines\":false,\"scale\":\"linear\",\"interpolate\":\"linear\",\"mode\":\"stacked\",\"times\":[],\"addTimeMarker\":false,\"defaultYExtents\":false,\"setYExtents\":false,\"yAxis\":{}},\"aggs\":[{\"id\":\"1\",\"type\":\"avg\",\"schema\":\"metric\",\"params\":{\"field\":\"container_stats.memory.usage\"}},{\"id\":\"2\",\"type\":\"date_histogram\",\"schema\":\"segment\",\"params\":{\"field\":\"container_stats.timestamp\",\"interval\":\"auto\",\"customInterval\":\"2h\",\"min_doc_count\":1,\"extended_bounds\":{}}},{\"id\":\"3\",\"type\":\"terms\",\"schema\":\"group\",\"params\":{\"field\":\"container_Name\",\"size\":5,\"order\":\"desc\",\"orderBy\":\"1\"}},{\"id\":\"4\",\"type\":\"terms\",\"schema\":\"split\",\"params\":{\"field\":\"machine_name\",\"size\":5,\"order\":\"desc\",\"orderBy\":\"1\",\"row\":true}}],\"listeners\":{}}",
      "uiStateJSON": "{}",
      "description": "",
      "version": 1,
      "kibanaSavedObjectMeta": {
        "searchSourceJSON": "{\"index\":\"cadvisor*\",\"query\":{\"query_string\":{\"query\":\"* NOT container_Name.raw: \\\\\\\"/\\\\\\\" AND NOT container_Name.raw: \\\\\\\"/docker\\\\\\\"\",\"analyze_wildcard\":true}},\"filter\":[]}"
      }
    }
  }
]

这里还有很多东西可以玩，你也许想自定义报表界面，比如添加内存页错误状态，或者收发包的丢包数。如果你能实现开头列表处我没能实现的项目，那也是很好的。

总结

正确监控需要大量时间和精力，容器的 CPU、内存、IO、网络和磁盘，监控的这些参数还只是整个监控项目中的沧海一粟而已。

我不知道你做到了哪一阶段，但接下来的任务也许是：

• 收集运行中的容器的日志
• 收集应用的日志
• 监控应用的性能
• 报警
• 监控健康状态

如果你有意见或建议，请留言。祝你玩得开心。

现在你可以关掉这些测试系统了：

docker-machine rm master1 worker{1,2}

via: https://blog.codeship.com/monitoring-docker-containers-with-elasticsearch-and-cadvisor/

作者：Lorenzo Fontana 译者：bazz2 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

从根本上说，几乎所有的主要软件，即使是开源软件，都是在基于镜像的容器技术出现之前设计的。这意味着把软件放到容器中相当于是一次平台移植。这也意味着一些程序可以很容易就迁移，而另一些就更困难。

我大约在三年半前开展基于镜像的容器相关工作。到目前为止，我已经容器化了大量应用。我了解到什么是现实情况，什么是迷信。今天，我想简要介绍一下 Linux 容器是如何设计的，以及谈谈镜像签名。

Linux 容器是如何设计的

对于基于镜像的 Linux 容器，让大多数人感到困惑的是，它把操作系统分割成两个部分：内核空间与用户空间。在传统操作系统中，内核运行在硬件上，你无法直接与其交互。用户空间才是你真正能交互的，这包括所有你可以通过文件浏览器或者运行ls命令能看到的文件、类库、程序。当你使用ifconfig命令调整 IP 地址时，你实际上正在借助用户空间的程序来使内核根据 TCP 协议栈改变。这点经常让没有研究过 Linux/Unix 基础的人大吃一惊。

过去，用户空间中的类库支持了与内核交互的程序（比如 ifconfig、sysctl、tuned-adm）以及如网络服务器和数据库之类的面向用户的程序。这些所有的东西都堆积在一个单一的文件系统结构中。用户可以在 /sbin 或者 /lib 文件夹中找到所有操作系统本身支持的程序和类库，或者可以在 /usr/sbin 或 /usr/lib 文件夹中找到所有面向用户的程序或类库（参阅文件系统层次结构标准）。这个模型的问题在于操作系统程序和业务支持程序没有绝对的隔离。/usr/bin 中的程序可能依赖 /lib 中的类库。如果一个应用所有者需要改变一些东西，就很有可能破坏操作系统。相反地，如果负责安全更新的团队需要改变一个类库，就（常常）有可能破坏面向业务的应用。这真是一团糟。

借助基于镜像的容器，比如 Docker、LXD、RKT，应用程序所有者可以打包和调整所有放在 /sbin、/lib、/usr/bin 和 /usr/lib 中的依赖部分，而不用担心破坏底层操作系统。本质上讲，容器技术再次干净地将操作系统隔离为两部分：内核空间与用户空间。现在开发人员和运维人员可以分别独立地更新各自的东西。

然而还是有些令人困扰的地方。通常，每个应用所有者（或开发者）并不想负责更新这些应用依赖：像 openssl、glibc，或很底层的基础组件，比如，XML 解析器、JVM，再或者处理与性能相关的设置。过去，这些问题都委托给运维团队来处理。由于我们在容器中打包了很多依赖，对于很多组织来讲，对容器内的所有东西负责仍是个严峻的问题。

迁移现有应用到 Linux 容器

把应用放到容器中算得上是平台移植，我准备突出介绍究竟是什么让移植某些应用到容器当中这么困难。

（通过容器，）开发者现在对 /sbin 、/lib、 /usr/bin、 /usr/lib 中的内容有完全的控制权。但是，他们面临的挑战是，他们仍需要将数据和配置放到 /etc 或者 /var/lib 文件夹中。对于基于镜像的容器来说，这是一个糟糕的想法。我们真正需要的是代码、配置以及数据的隔离。我们希望开发者把代码放在容器当中，而数据和配置通过不同的环境（比如，开发、测试或生产环境）来获得。

这意味着我们（或者说平台）在实例化容器时，需要挂载 /etc 或 /var/lib 中的一些文件或文件夹。这会允许我们到处移动容器并仍能从环境中获得数据和配置。听起来很酷吧？这里有个问题，我们需要能够干净地隔离配置和数据。很多现代开源软件比如 Apache、MySQL、MongoDB、Nginx 默认就这么做了。但很多自产的、历史遗留的、或专有程序并未默认这么设计。对于很多组织来讲，这是主要的痛点。对于开发者来讲的最佳实践是，开始架构新的应用，移植遗留代码，以完成配置和数据的完全隔离。

镜像签名简介

信任机制是容器的重要议题。容器镜像签名允许用户添加数字指纹到镜像中。这个指纹随后可被加密算法测试验证。这使得容器镜像的用户可以验证其来源并信任。

容器社区经常使用“容器镜像”这个词组，但这个命名方法会让人相当困惑。Docker、LXD 和 RKT 推行获取远程文件来当作容器运行这样的概念。这些技术各自通过不同的方式处理容器镜像。LXD 用单独的一层来获取单独一个容器，而 Docker 和 RKT 使用基于开放容器镜像（OCI）格式，可由多层组成。糟糕的是，会出现不同团队和组织对容器镜像中的不同层负责的情况。容器镜像概念下隐含的是容器镜像格式的概念。拥有标准的镜像格式比如 OCI 会让容器生态系统围绕着镜像扫描、签名，和在不同云服务提供商间转移而繁荣发展。

现在谈到签名了。

容器存在一个问题，我们把一堆代码、二进制文件和类库放入其中。一旦我们打包了代码，我们就要把它和必要的文件服务器（注册服务器）共享。代码只要被共享，它基本上就是不具名的，缺少某种密文签名。更糟糕的是，容器镜像经常由不同人或团队控制的各个镜像层组成。每个团队都需要能够检查上一个团队的工作，增加他们自己的工作内容，并在上面添加他们自己的批准印记。然后他们需要继续把工作交给下个团队。

（由很多镜像组成的）容器镜像的最终用户需要检查监管链。他们需要验证每个往其中添加文件的团队的可信度。对于最终用户而言，对容器镜像中的每一层都有信心是极其重要的。

作者 Scott McCarty 于 8 月 24 日在 ContainerCon 会议上作了题为 Containers for Grownups: Migrating Traditional & Existing Applications 的报告，更多内容请参阅报告幻灯片。

via: https://opensource.com/bus/16/8/introduction-linux-containers-and-image-signing

作者：Scott McCarty 译者：Tanete 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

Ben Firshman 最近在 Dockercon 做了一个关于使用 Docker 构建无服务应用的演讲，你可以在这里查看详情（还有视频）。之后，我写了一篇关于如何使用 AWS Lambda 构建微服务系统的文章。

今天，我想展示给你的就是如何使用 Docker Swarm 部署一个简单的 Python Falcon REST 应用。这里我不会使用dockerrun 或者是其他无服务特性，你可能会惊讶，使用 Docker Swarm 部署（复制）一个 Python（Java、Go 都一样）应用是如此的简单。

注意：这展示的部分步骤是截取自 Swarm Tutorial，我已经修改了部分内容，并且增加了一个 Vagrant Helper 的仓库来启动一个可以让 Docker Swarm 工作起来的本地测试环境。请确保你使用的是 1.12 或以上版本的 Docker Engine。我写这篇文章的时候，使用的是 1.12RC2 版本。注意的是，这只是一个测试版本，可能还会有修改。

你要做的第一件事，就是如果你想本地运行的话，你要保证 Vagrant 已经正确的安装和运行了。你也可以按如下步骤使用你最喜欢的云服务提供商部署 Docker Swarm 虚拟机系统。

我们将会使用这三台 VM：一个简单的 Docker Swarm 管理平台和两台 worker。

安全注意事项：Vagrantfile 代码中包含了部分位于 Docker 测试服务器上的 shell 脚本。这是一个潜在的安全问题，它会运行你不能控制的脚本，所以请确保你会在运行代码之前审查过这部分的脚本。

$ git clone https://github.com/chadlung/vagrant-docker-swarm
$ cd vagrant-docker-swarm
$ vagrant plugin install vagrant-vbguest
$ vagrant up

Vagrant up 命令需要一些时间才能完成。

SSH 登录进入 manager1 虚拟机：

$ vagrant ssh manager1

在 manager1 的 ssh 终端会话中执行如下命令：

$ sudo docker swarm init --listen-addr 192.168.99.100:2377

现在还没有 worker 注册上来：

$ sudo docker node ls

让我们注册两个新的 worker，请打开两个新的终端会话（保持 manager1 会话继续运行）：

$ vagrant ssh worker1

在 worker1 的 ssh 终端会话上执行如下命令：

$ sudo docker swarm join 192.168.99.100:2377

在 worker2 的 ssh 终端会话上重复这些命令。

在 manager1 终端上执行如下命令：

$ docker node ls

你将会看到：

在 manager1 的终端里部署一个简单的服务。

sudo docker service create --replicas 1 --name pinger alpine ping google.com

这个命令将会部署一个服务，它会从 worker 之一 ping google.com。（或者 manager，manager 也可以运行服务，不过如果你只是想 worker 运行容器的话，也可以禁用这一点）。可以使用如下命令，查看哪些节点正在执行服务:

$ sudo docker service tasks pinger

结果会和这个比较类似：

所以，我们知道了服务正跑在 worker1 上。我们可以回到 worker1 的会话里，然后进入正在运行的容器：

$ sudo docker ps

你可以看到容器的 id 是: ae56769b9d4d，在我的例子中，我运行如下的代码：

$ sudo docker attach ae56769b9d4d

你可以按下 CTRL-C 来停止服务。

回到 manager1，然后移除这个 pinger 服务。

$ sudo docker service rm pinger

现在，我们将会部署可复制的 Python 应用。注意，为了保持文章的简洁，而且容易复制，所以部署的是一个简单的应用。

你需要做的第一件事就是将镜像放到 Docker Hub上，或者使用我已经上传的一个。这是一个简单的 Python 3 Falcon REST 应用。它有一个简单的入口: /hello 带一个 value 参数。

放在 chadlung/hello-app 上的 Python 代码看起来像这样：

import json
from wsgiref import simple_server

import falcon


class HelloResource(object):
    def on_get(self, req, resp):
        try:
            value = req.get_param('value')

            resp.content_type = 'application/json'
            resp.status = falcon.HTTP_200
            resp.body = json.dumps({'message': str(value)})
        except Exception as ex:
            resp.status = falcon.HTTP_500
            resp.body = str(ex)


if __name__ == '__main__':
    app = falcon.API()
    hello_resource = HelloResource()
    app.add_route('/hello', hello_resource)
    httpd = simple_server.make_server('0.0.0.0', 8080, app)
    httpd.serve_forever()

Dockerfile 很简单：

FROM python:3.4.4

RUN pip install -U pip
RUN pip install -U falcon

EXPOSE 8080

COPY . /hello-app
WORKDIR /hello-app

CMD ["python", "app.py"]

上面表示的意思很简单，如果你想，你可以在本地运行该进行来访问这个入口： http://127.0.0.1:8080/hello?value=Fred

这将返回如下结果：

{"message": "Fred"}

在 Docker Hub 上构建和部署这个 hello-app（修改成你自己的 Docker Hub 仓库或者使用这个）：

$ sudo docker build . -t chadlung/hello-app:2
$ sudo docker push chadlung/hello-app:2

现在，我们可以将应用部署到之前的 Docker Swarm 了。登录 manager1 的 ssh 终端会话，并且执行：

$ sudo docker service create -p 8080:8080 --replicas 2 --name hello-app chadlung/hello-app:2
$ sudo docker service inspect --pretty hello-app
$ sudo docker service tasks hello-app

现在，我们已经可以测试了。使用任何一个 Swarm 节点的 IP 来访问 /hello 入口。在本例中，我在 manager1 的终端里使用 curl 命令：

注意，Swarm 中的所有的 IP 都可以，不管这个服务是运行在一台还是更多的节点上。

$ curl -v -X GET "http://192.168.99.100:8080/hello?value=Chad"
$ curl -v -X GET "http://192.168.99.101:8080/hello?value=Test"
$ curl -v -X GET "http://192.168.99.102:8080/hello?value=Docker"

结果：

* Hostname was NOT found in DNS cache
*   Trying 192.168.99.101...
* Connected to 192.168.99.101 (192.168.99.101) port 8080 (#0)
> GET /hello?value=Chad HTTP/1.1
> User-Agent: curl/7.35.0
> Host: 192.168.99.101:8080
> Accept: */*
> 
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Date: Tue, 28 Jun 2016 23:52:55 GMT
< Server: WSGIServer/0.2 CPython/3.4.4
< content-type: application/json
< content-length: 19
< 
{"message": "Chad"}

从浏览器中访问其他节点：

如果你想看运行的所有服务，你可以在 manager1 节点上运行如下代码：

$ sudo docker service ls

如果你想添加可视化控制平台，你可以安装 Docker Swarm Visualizer（这对于展示非常方便）。在 manager1 的终端中执行如下代码：

$ sudo docker run -it -d -p 5000:5000 -e HOST=192.168.99.100 -e PORT=5000 -v /var/run/docker.sock:/var/run/docker.sock manomarks/visualizer

打开你的浏览器，并且访问： http://192.168.99.100:5000/

结果如下（假设已经运行了两个 Docker Swarm 服务）：

要停止运行 hello-app（已经在两个节点上运行了），可以在 manager1 上执行这个代码：

$ sudo docker service rm hello-app

如果想停止 Visualizer， 那么在 manager1 的终端中执行：

$ sudo docker ps

获得容器的 ID，这里是： f71fec0d3ce1，从 manager1 的终端会话中执行这个代码：

$ sudo docker stop f71fec0d3ce1

祝你成功使用 Docker Swarm。这篇文章主要是以 1.12 版本来进行描述的。

via: http://www.giantflyingsaucer.com/blog/?p=5923

作者：Chad Lung 译者：MikeCoder 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

今日关注

两周前，小编曾经报道过，MapQuest停服导致GNOME Maps这一免费应用下架。现在带来一个好消息，GNOME Maps又重新恢复正常使用功能了，这次是通过一个GNOME代理来获取Mapbox的接口，从而为GNOME Maps提供地图相关服务。GNOME Maps 3.21.4 也已经可以进行下载了。

图文摘要

私有云9.1社区版发布，提供了对基于token的身份验证会话和可插入身份验证的支持。另外，9.1版本引入了一项新功能，可以列出所有连接了你个人用户页面的所有设备，你可以对一些特定的会话进行失效操作。当然，还有很多非常棒的功能，感兴趣的用户可以进行下载体验了。

Docker 1.12 正式发布。这一版本引入了内置的编排管弦乐曲，全新的Swarm模式，内置的路由网络以及大量的网络安全完善等。

科幻题材的太空大型多人联机角色扮演游戏 Vendetta Online 更新到了 1.8.381 版本，相比上一个版本，进行了许多完善，比如对VR的完善，对Oculus Rift 1.6 和 Touch 的支持。感兴趣的玩家可以更新体验了。