** 说明 ：这是chronograf镜像的amd64架构构建的"per-architecture"仓库——更多信息请参见镜像文档中的"非amd64架构？"和*镜像FAQ中的"Git中镜像源已更改，该怎么办？"。

快速参考

-** 维护者 **：
InfluxData

-** 获取帮助 **：
Docker社区Slack、Server Fault、Unix & Linux或Stack Overflow

支持的标签及对应的Dockerfile链接

• 1.7, 1.7.17

• 1.7-alpine, 1.7.17-alpine

• 1.8, 1.8.10

• 1.8-alpine, 1.8.10-alpine

• 1.9, 1.9.4

• 1.9-alpine, 1.9.4-alpine

• 1.10, 1.10.8, latest

• 1.10-alpine, 1.10.8-alpine, alpine

快速参考（续）

-** 提交issue的地址 ：
[*]

-** 支持的架构 **：(更多信息)
amd64、arm32v7、arm64v8

-** 镜像 artifact 详情 **：
repo-info仓库的repos/chronograf/目录（历史记录）
（镜像元数据、传输大小等）

-** 镜像更新 **：
official-images仓库的library/chronograf标签
official-images仓库的library/chronograf文件（历史记录）

-** 本描述的来源 **：
docs仓库的chronograf/目录（历史记录）

Chronograf

Chronograf是InfluxData的开源Web应用。将Chronograf与TICK技术栈的其他组件配合使用，可实现基础设施监控、告警管理、数据可视化和数据库管理。

!logo

使用本镜像

运行容器

Chronograf运行在8888端口。可通过暴露该端口来运行并访问容器：

console
$ docker run -p 8888:8888 amd64/chronograf

挂载卷

Chronograf镜像在/var/lib/chronograf下暴露共享卷，因此可将主机目录挂载到该路径以访问持久化的容器数据。典型的容器启动命令如下：

console
$ docker run -p 8888:8888 \
      -v $PWD:/var/lib/chronograf \
      amd64/chronograf

将$PWD修改为您希望存储Chronograf容器相关数据的目录。

您也可以使用命名卷让Docker管理卷挂载点：

console
$ docker run -p 8888:8888 \
      -v chronograf:/var/lib/chronograf \
      amd64/chronograf

与InfluxDB一起使用

此处说明与telegraf配合influxdb使用的方式非常相似。以下示例假设您使用Docker的内置服务发现功能。为此，我们首先创建一个新网络：

console
$ docker network create influxdb

接下来，启动名为influxdb的InfluxDB容器：

console
$ docker run -d --name=influxdb \
      --net=influxdb \
      influxdb

现在可以启动引用此数据库的Chronograf容器：

console
$ docker run -p 8888:8888 \
      --net=influxdb \
      amd64/chronograf --influxdb-url=[***]

尝试将其与Telegraf结合使用，几分钟内即可获得基础设施的仪表盘！

以root用户运行

从v1.10.5开始，Chronograf默认不再以root用户运行。如果用户希望恢复此行为，可将环境变量CHRONOGRAF_AS_ROOT设置为true。

***文档

有关创建可视化的信息，请参见***文档。

镜像变体

amd64/chronograf镜像有多种版本，每种版本针对特定用例设计。

amd64/chronograf:<version>

这是默认镜像。如果您不确定自己的需求，可能需要使用此版本。它既可用作临时容器（挂载源代码并启动容器以运行应用），也可用作构建其他镜像的基础。

amd64/chronograf:<version>-alpine

此镜像基于流行的Alpine Linux项目，来自alpine***镜像。Alpine Linux比大多数发行版基础镜像小得多（约5MB），因此通常会生成更精简的镜像。

当最终镜像大小是首要考虑因素时，此变体非常有用。需要注意的是，它使用musl libc而非glibc及相关库，因此软件可能会因对libc的依赖/假设深度而遇到问题。有关可能出现的问题及使用Alpine-based镜像的优缺点比较，请参见此Hacker News评论线程。

为最小化镜像大小，Alpine-based镜像通常不包含额外的相关工具（如git或bash）。以此镜像为基础，可在您自己的Dockerfile中添加所需工具（如果不熟悉如何安装软件包，请参见alpine镜像描述中的示例）。

许可

查看此镜像中包含的软件的许可信息。

与所有Docker镜像一样，这些镜像可能还包含其他软件，这些软件可能受其他许可（如基础发行版中的Bash等，以及主要软件的任何直接或间接依赖项）约束。

一些能够自动检测到的额外许可信息可能位于repo-info仓库的chronograf/目录中。

至于任何预构建镜像的使用，镜像用户有责任确保对该镜像的任何使用符合其中包含的所有软件的相关许可。