https://www.terraform.io/

Terraform

Use Infrastructure as Code to provision and manage any cloud, infrastructure, or service

Terraform：简介

在 DevOps 实践中，基础设施即代码如何落地是一个绕不开的话题。像 Chef，Puppet 等成熟的配置管理工具，都能够满足一定程度的需求，但有没有更友好的工具能够满足我们绝大多数的需求？笔者认为 Terraform 是一个很有潜力的工具，目前各大云平台也都支持的不错，尤其是使用起来简单明了。本文会简单的介绍一下 Terraform 相关的概念，然后通过一个小 demo 带大家一起进入 Terraform 的世界。说明：本文的演示环境为 ubuntu 16.04。

Terraform 是什么？

Terraform 是一种安全有效地构建、更改和版本控制基础设施的工具(基础架构自动化的编排工具)。它的目标是 "Write, Plan, and create Infrastructure as Code", 基础架构即代码。Terraform 几乎可以支持所有市面上能见到的云服务。具体的说就是可以用代码来管理维护 IT 资源，把之前需要手动操作的一部分任务通过程序来自动化的完成，这样的做的结果非常明显：高效、不易出错。

Terraform 提供了对资源和提供者的灵活抽象。该模型允许表示从物理硬件、虚拟机和容器到电子邮件和 DNS 提供者的所有内容。由于这种灵活性，Terraform 可以用来解决许多不同的问题。这意味着有许多现有的工具与Terraform 的功能重叠。但是需要注意的是，Terraform 与其他系统并不相互排斥。它可以用于管理小到单个应用程序或达到整个数据中心的不同对象。

Terraform 使用配置文件描述管理的组件(小到单个应用程序，达到整个数据中心)。Terraform 生成一个执行计划，描述它将做什么来达到所需的状态，然后执行它来构建所描述的基础结构。随着配置的变化，Terraform 能够确定发生了什么变化，并创建可应用的增量执行计划。

Terraform 是用 Go 语言开发的开源项目，你可以在 github 上访问到它的源代码。

Terraform 核心功能

• 基础架构即代码(Infrastructure as Code)
• 执行计划(Execution Plans)
• 资源图(Resource Graph)
• 自动化变更(Change Automation)

基础架构即代码(Infrastructure as Code)
使用高级配置语法来描述基础架构，这样就可以对数据中心的蓝图进行版本控制，就像对待其他代码一样对待它。

执行计划(Execution Plans)
Terraform 有一个 plan 步骤，它生成一个执行计划。执行计划显示了当执行 apply 命令时 Terraform 将做什么。通过 plan 进行提前检查，可以使 Terraform 操作真正的基础结构时避免意外。

资源图(Resource Graph)
Terraform 构建的所有资源的图表，它能够并行地创建和修改任何没有相互依赖的资源。因此，Terraform 可以高效地构建基础设施，操作人员也可以通过图表深入地解其基础设施中的依赖关系。

自动化变更(Change Automation)
把复杂的变更集应用到基础设施中，而无需人工交互。通过前面提到的执行计划和资源图，我们可以确切地知道 Terraform 将会改变什么，以什么顺序改变，从而避免许多可能的人为错误。

安装 Terraform

Terraform 的安装非常简单，直接把官方提供的二进制可执行文件保存到本地就可以了。比如笔者习惯性的把它保存到 /usr/local/bin/ 目录下，当然这个目录会被添加到 PATH 环境变量中。完成后检查一下版本号：

通过 -h 选项我们可以看到 terraform 支持的所有命令：

在 Azure 上创建一个 Resource Group

要让 Terraform 访问 Azure 订阅中的资源，需要先创建 Azure service principal，Azure service principa 允许你的 Terraform 脚本在 Azure 订阅中配置资源。请参考这里创建 Azure service principal。

配置 Terraform 环境变量
若要配置 Terraform 使用 Azure service principal，需要设置以下环境变量：

• ARM_SUBSCRIPTION_ID
• ARM_CLIENT_ID
• ARM_CLIENT_SECRET
• ARM_TENANT_ID
• ARM_ENVIRONMENT

这些环境变量的值都可以从前面创建 Azure service principal 的过程中获得。方便起见，我们把设置这些环境变量的步骤可以写到脚本文件 azureEnv.sh 中：

#!/bin/sh
echo "Setting environment variables for Terraform"
export ARM_SUBSCRIPTION_ID=your_subscription_id
export ARM_CLIENT_ID=your_appId
export ARM_CLIENT_SECRET=your_password
export ARM_TENANT_ID=your_tenant_id
# Not needed for public, required for usgovernment, german, china
export ARM_ENVIRONMENT=public

这样在执行 Terraform 命令前通过 source 命令执行该脚本就可以了！

创建 Terraform 配置文件
为了在 Azure 上创建一个 Resource Group，我们创建名称为 createrg.tf 的配置文件，并编辑内容如下：

provider "azurerm" {
}
resource "azurerm_resource_group" "rg" {
        name = "NickResourceGroup"
        location = "eastasia"
}

用 init 命令用来初始化工作目录
把当前目录切换到 createrg.tf 文件所在的目录，然后执行 init 命令：

$ terraform init 

其实就是把 createrg.tf 文件中指定的驱动程序安装到当前目录下的 .terraform 目录中：

通过 plan 命令检查配置文件
plan 命令会检查配置文件并生成执行计划，如果发现配置文件中有错误会直接报错：

$ . azureEnv.sh
$ terraform plan

通过 plan 命令的输出，我们可以清楚的看到即将在目标环境中执行的任务。

使用 graph 命令生成可视化的图表
其实 graph 命令只能生成相关图表的数据(dot 格式的数据)，我们通过 dot 命令来生成可视化的图表，先通过下面的命令安装 dot 程序：

$ sudo apt install graphviz

然后生成一个图表：

$ terraform graph | dot -Tsvg > graph.svg

上图描述了我们通过 azurerm 驱动创建了一个 Resource Group。

使用 apply 命令完成部署操作
在使用 apply 命令执行实际的部署时，默认会先执行 plan 命令并进入交互模式等待用户确认操作，我们已经执行过 plan 命令了，所以可以使用 -auto-approve 选项跳过这些步骤直接执行部署操作：

$ terraform apply -auto-approve

到 Azure 站点上检查一下，发现名称为 NickResourceGroup 的 Resource Group 已经创建成功了。

总结

Terraform 支持的平台非常多，像 AWS，Azure 等大厂自然是不用说了，一些小的厂商也可以通过提供 provider 支持 Terraform，从而让整个生态变得非常活跃。如果大家想在 DevOps 实践中引入基础设施即代码，无论是面对的是公有云还是私有云，相信 Terraform 都不会让你失望。

参考：
Introduction to Terraform
Terraform github
安装和配置 Terraform

Prometheus : 入门

Prometheus 是一个开源的监控系统。支持灵活的查询语言(PromQL)，采用 http 协议的 pull 模式拉取数据等特点使 Prometheus 即简单易懂又功能强大。

Prometheus 的主要特点

• 多维度数据模型

• 灵活的查询语言

• 不依赖分布式存储，单个服务器节点是自主的

• 通过 pull 方式采集时序数据

• 可以通过中间网关进行时序列数据推送

• 通过服务发现或者静态配置来发现目标服务对象

• 支持多种界面展示方案，比如 grafana 等

Prometheus 由 server, client, push gateway, exporter, alertmanager 等核心组件构成。Prometheus server 主要用于抓取和存储数据。Client libraries 可以用来连接 server 并进行查询等操作。Push gateway  用于批量，短期的监控数据的汇总节点，主要用于业务数据汇报等。不同的 exporter 用于不同场景下的数据收集，如收集主机信息的 node_exporter，收集 MongoDB 信息的 MongoDB exporter 等等。下图是 Prometheus 官方提供的架构图：

从这个架构图，我们可以看出它的运行逻辑大概是这样的：
Prometheus server 定期从数据源拉取数据，然后将数据持久化到磁盘。Prometheus 可以配置 rules，然后定时查询数据，当条件触发的时候，会将 alert 推送到配置的 Alertmanager。Alertmanager 收到警告的时候，可以根据配置，聚合，去重，降噪，最后发送警告。同时还可以使用 API， Prometheus Console 或者 Grafana 查询和聚合数据。

本文将介绍在 ubuntu 16.04 系统中安装 Prometheus Server，并配置它从一台主机上拉取监控信息，然后通过 Prometheus Server 提供的简易 UI 查询数据。

在 Ubuntu 16.04 中安装 Prometheus Server

请从 Prometheus 官方下载 linux 版的二进制压缩包。注意在下载前要选择操作系统为 linux。
执行下面的命令把 prometheus server 安装到 /usr/local/share/prometheus 目录：

$ tar -xf prometheus-1.7.2.linux-amd64.tar.gz
$ sudo mv prometheus-1.7.2.linux-amd64 /usr/local/share/prometheus

理论上来说这样就算是安装完成了，但是无论如何这都太简陋了。因为每次启动 Prometheus server 都需要手动执行命令：

$ /usr/local/share/prometheus/prometheus -config.file=/usr/local/share/prometheus/prometheus.yml

这实在是太不方便了！应该把它配置成服务，用 systemd 来管理。

先创建一个名为 prometheus 的用户：

$ sudo adduser prometheus

把目录 /usr/local/share/prometheus/ 的所有者设置为 prometheus 用户：

$ sudo chown -R prometheus:prometheus /usr/local/share/prometheus/

然后创建文件 /etc/systemd/system/prometheus.service，内容如下：

[Unit]
Description=Prometheus Server
Documentation=https://prometheus.io/docs/introduction/overview/
After=network.target

[Service]
User=prometheus
Restart=on-failure
WorkingDirectory=/usr/local/share/prometheus/
ExecStart=/usr/local/share/prometheus/prometheus \
          -config.file=/usr/local/share/prometheus/prometheus.yml

[Install]
WantedBy=multi-user.target

好了，现在可以通过 systemd 来控制 Prometheus 服务了，先启动服务：

$ sudo systemctl daemon-reload
$ sudo systemctl start prometheus

再把服务配置为开机时启动：

$ sudo systemctl enable prometheus

检查一下服务的状态：

$ sudo systemctl status prometheus

到此为止 Prometheus Server 已经开始运行了。接下来我们就可以收集数据了。

使用 Node Exporter 收集主机信息

数据收集的任务由不同的 exporter 来完成，如果要收集 linux 主机的信息，可以使用 node exporter。然后由 Prometheus Server 从 node exporter 上拉取信息。接下来我们介绍如何安装并配置 node exporter。
请从 Prometheus 官方下载 node exporter 的二进制压缩包。执行下面的命令把 node exporter 安装到 /usr/local/share/ 目录：

$ tar -xf node_exporter-0.14.0.linux-amd64.tar.gz
$ sudo cp node_exporter-0.14.0.linux-amd64/node_exporter /usr/local/sbin/

同样的我们把 node exporter 也配置成通过 systemd 管理。创建文件 /etc/systemd/system/node-exporter.service，内容如下：

[Unit]
Description=Prometheus Node Exporter
After=network.target

[Service]
ExecStart=/usr/local/sbin/node_exporter
User=nobody

[Install]
WantedBy=multi-user.target

执行下面的命令设置为开机启动并启动服务：

$ sudo systemctl daemon-reload
$ sudo systemctl enable node-exporter
$ sudo systemctl start node-exporter

node exporter 默认监听 9100 端口，让我们检查一下端口的监听情况：

$ ss -tunl

Node exporter 已经可以收集主机上的信息了，接下来我们还需要配置 Prometheus Server 从 node exporter 那里拉取数据。

配置 Prometheus 从 Node Exproter 拉取数据

Prometheus Server 可以从不同的 exporter 上拉取数据，对于上面的 node exporter 我们可以利用 Prometheus 的 static_configs 来拉取 node exporter 的数据。编辑 Prometheus server 的配置文件：

$ sudo vim /usr/local/share/prometheus/prometheus.yml

在 scrape_configs 中添加一个 名称为 node 的 static_configs：

- job_name: "node"
    static_configs:
      - targets: ["127.0.0.1:9100"]

注意，要把上面的 IP 地址替换为运行 node exporter 的主机的 IP。

保存文件然后重启 prometheus 服务！重启后 prometheus 服务会每隔 15s 从 node exporter 上拉取一次数据。

查询数据

Prometheus Server 提供了简易的 WebUI 可以进数据查询并展示，它默认监听的端口为 9090。接下来我们进行一次简单的查询来验证本文安装配置的系统。
在浏览器中访问 Prometheus Server 的 9090 端口：

在下拉菜单中选择 "node_memory_Buffers"，然后点击 "Execute" 按钮：

查询出来的结果略微有些粗犷，连单位都没带。请选择 "Graph" 标签页：

通过图表查看查询结果就好多了！

总结

Prometheus 是当下比较流行的开源监控工具，这里只是简单的介绍了安装过程及一个最基本的用例。但是不难看出 Prometheus 虽然支持灵活的查询语言，但是自身只支持简单的展示能力。如果要友好的展示 Prometheus 的查询结果，还需要使用更专业的展示工具 Grafana。

Ansible 简介

Ansible 是一个开源的基于 OpenSSH 的自动化配置管理工具。可以用它来配置系统、部署软件和编排更高级的 IT 任务，比如持续部署或零停机更新。Ansible 的主要目标是简单和易用，并且它还高度关注安全性和可靠性。基于这样的目标，Ansible 适用于开发人员、系统管理员、发布工程师、IT 经理，以及介于两者之间的所有人。Ansible 适合管理几乎所有的环境，从拥有少数实例的小型环境到有数千个实例的企业环境。

使用 Ansible 无须在被管理的机器上安装代理，所以不存在如何升级远程守护进程的问题，也不存在由于卸载了守护进程而无法管理系统的问题。

Ansible 的主要功能

管理员可以通过 Ansible 在成百上千台计算机上同时执行指令(任务)。
对于管理员来说，经常需要执行下面的任务：

• 维护现存的比较复杂的服务器时，手动登录的方式很容易遗漏一些操作，或者是执行一些未预期的操作。
• 手动初始化新的服务器耗时耗力！

对于这两种情况，如果完全通过 shell 脚本实现。脚本会过于复杂，极难维护。当然我们也可以使用同类的工具，比如 Puppet and Chef。这两个工具的特点是：需要学习新的知识栈(其实 Ansible 也是有学习成本的)。

相比 Puppet 和 Chef 使用 Ansible 可以延续之前使用 shell 脚本的工作习惯和方式，因而其学习成本会低一些。下面是 Ansible 的一些优势：

• 可以逐行的执行 shell 命令。
• 不需要另外的客户端工具(linux 一般会自带 ssh 工具)。
• 相同的配置只被执行一次(多次执行同一配置不会出问题)。

Ansible 的工作方式

使用 Ansible 无须在被管理的客户端电脑上安装代理之类的组件。它通过普通的 SSH 进行通信，以便从远程计算机检索信息、发出命令和复制文件。这是 Ansible 简化服务器管理的一种方式。任何公开 SSH 端口的服务器都可以通过 Ansible 进行配置和管理。

Ansible 采用模块化的设计，所以非常容易扩展到各种特定的使用场景。模块可以用任何语言编写，并使用标准 JSON 进行通信。Ansible 的配置文件是用 YAML 格式编写的，因为它使用起来非常简单，并且与主流的标记语言很相似。除了通过命令行工具 Ansible 还可以通过配置脚本(Playbooks)与客户端交互。

安装 Ansible

本文介绍在 Ubuntu 16.04 环境中安装并使用 Ansible。由于 Ubuntu 官方库提供的版本比较老，所以我们从第三方的库安装，这样就能安装到比较新的版本：

$ sudo apt-add-repository -y ppa:ansible/ansible
$ sudo apt-get update
$ sudo apt-get install -y ansible

安装完成后检查一下版本：

$ ansible --version

2.7.1 是笔者在写本文时的最新版本。

配置客户端主机的 SSH 秘钥

对于自动化来说，最后是通过秘钥进行认证，这样就不会把用户的密码以明文的方式写在脚本里。下面的命令把安装了 ansible 的主机上当前用户的 SSH 公钥安装到了被管理的客户端 192.168.21.145 和 192.168.21.148 上：

$ ssh-copy-id -i ~/.ssh/id_rsa.pub nick@192.168.21.145
$ ssh-copy-id -i ~/.ssh/id_rsa.pub nick@192.168.21.148

说明：这两台被管理的客户端主机运行的也都是 Ubuntu 16.04。

然后尝试通过下面的命令以不输密码的方式连接到远程主机中：

$ ssh nick@192.168.21.145
$ ssh nick@192.168.21.148

如果能够成功登陆，说明 SSH 的配置已经 OK 了。

配置用户执行 sudo 时不需要密码
在我们执行的自动化操作中，有很大一部分是需要 root 权限的，比如执行更新、安装软件等等。这样的操作会因为在以 sudo 方式执行是提升用户输入密码而失败，比如下面的命令：

$ ansible testservers -b -u nick -a "apt update"

-b 选项默认把用户 nick 提升为 root 权限，但是需要输入用户 nick 的密码，所以自动化执行的命令失败了。当然我们可以同时添加 -K 选项，这是 ansible 会停下来与用户交互，等待用户输入密码：

但这真的不是我想要的结果，我需要的是脚本能够自动化的不需要交互的完成任务！

这个问题的解决方法是把用户设置为执行 sudo 命令时不需要输入密码，让我们在客户机 192.168.21.148 上执行下面的命令：

$ sudo visudo

为用户 nick 添加下面的行：

nick    ALL=(ALL)     NOPASSWD: ALL

该行内容配置用户 nick 在执行 sudo 命令时不需要输入密码，保存后让我们再次执行下面的命令：

$ ansible testservers -b -u nick -a "apt update"

这次终于可以执行 root 权限的命令了！

清单(inventory)

清单是 ansible 的一个配置文件，在清单中我们可以指定被管理的客户端机器。Ansible 默认的清单文件为 /etc/ansible/hosts，当然我们也可以通过 -i 选项指定其它的清单文件，比如下面的例子：

$ ansible myservers -i /etc/ansible/myhosts -b -u nick -a "apt update"

在清单文件中，我们可以指定 ansible 命令操作的主机对象。对于单个的主机，可以在清单中写主机域名，也可以直接写 IP 地址：

如果要同时对对个主机进行操作，可以把它们定义在一个组中：

在执行 ansible 命令时，指定清单中定义的主机名称或者组名就可以了。比如我们在 /etc/ansible/hosts 文件中定义了一个名称为 testservers 的组，它包含了两个主机：

然后通过下面的命令分别在这两台主机上执行 df -h 命令：

$ ansible testservers -u nick -a "df -h"

从输出的结果可以看出 df -h 命令在两台目标主机上都执行了。

模块

Ansible 把类似的操作封装到模块中，这样就可以通过插件的方式对 Ansible 进行扩展了。每个模块都能接收参数，几乎所有的模块都接受键值对(key=value)参数，这些参数通过空格进行分隔。也有一些模块不接收参数，只需在命令行输入相关的命令就能调用。如果要执行单个命令，可以使用 command 模块：

$ ansible testservers -m command -u nick -a "df -h"
$ ansible webservers -m command -a "/sbin/reboot -t now"

因为 command 是 ansible 执行命令是使用的默认模块，所以我们可以在命令行中省略它：

$ ansible testservers -u nick -a "df -h"
$ ansible testservers -b -u nick -a "/sbin/reboot -t now"

这样的写法本质上和前面的写法是一样的。

如果要执行其它模块中的命令就需要通过 -m 选项显式的指定模块的名称，比如执行 service 模块中的命令：

$ ansible testservers -m service -a "name=httpd state=started"

如果要把文件从本机拷贝到客户端主机上去，就需要使用 copy 模块：

$ ansible testservers -m copy -u nick  -a "src=./app.js dest=./myapp/app.js"

Ansible 默认内置了很多好用的模块，你可以从其官方文档中的模块部分了解更多模块相关的内容。

playbook

如果 Ansible 的功能仅仅是能够执行当个的命令和脚本就显得太弱了。Ansible 的 laybook 功能支持把命令以 yaml 的格式写在配置文件中，然后一次性执行配置文件中的所有命令(这一点类似于 chef 中的 cookbook)。比如我们可以把前面演示的 df -h 命令以配置文件的方式写在 playbook 中：

---
- hosts: testservers
  become: true
  become_user: root
  tasks:
    - name: check disk
      command: df -h

把上面的代码保存在文件 playbook.yml 中，当然你可以根据自己的喜好命名这个文件。其中 hosts 表示对哪些主机进行操作，become 就是我们在命令行上用过的 -b 选项，这里我们通过 become_user: root 显式的指定把当前用户的权限提升为 root 用户权限来执行命令。下面的 tasks 则是对任务的定义，name 是独一无二的一个任务名(如果有多个同名的 task，只执行第一个)，接着是 task 中的命令，这里我们还是简单的执行 df -h 命令。然后执行下面的命令，注意这次执行的是 ansible-playbook 命令，并且需要指定编辑好的 playbook 的文件名称作为参数：

$ ansible-playbook -u nick playbook.yml

这样一个简单的 playbook 就可以正常工作了，当然实际的生产环境中你可能会把 playbook 编写的非常复杂！

跳过首次 ssh 连接时的确认提示

这是一个在自动化的过程中经常碰到的问题，所以有必要提一下。如果你不是通过 ssh-copy-id 命令把公钥添加到目标机器上的(多数的环境都不是这么做的)，在首次执行 ansible 命令时需要用户确认连接的安全性：

这是非常悲催的，因为我们要实现的目标是自动化的执行命令，而不需要进行交互式的操作。
这个问题的解决方案是配置 ansible，跳过这一步的检查。具体的做法是在配置文件 /etc/ansible/ansible.cfg 中找到行 host_key_checking = False，并去掉行头的注释字符：

然后再执行 ansible 命令就不会提示用户进行交互式验证了。

总结

Ansible 是一个强大的自动化工具，并以其简介的用法，对开发者(系统运维工程师)友好的特点在自动化的流程中占据了一席之地。在这个 devops 已经成为主流的时代，如果能够熟练的使用 ansible ，相信必定会让你的 devops 实践如虎添翼。

用什么监控我们的容器?

本文介绍常见监控工具 zabbix 和 prometheus 的主要特点以及应用于容器监控时各自的优缺点，希望能够帮助同学们选择适合项目的监控工具。
说明：本文介绍的两个工具 zabbix 和 prometheus 都是开源、免费的。

Zabbix 的主要特点

作为老牌监控工具，zabbix 历史悠久，功能全面且强大。下面罗列一些它的主要特点：
数据收集方式灵活全面

• 支持可用性和性能检查
• 支持 SNMP(包括主动轮训和被动获取)，IPMI，JMX，VMware 监控
• 支持自定义检查
• 按照自定义的间隔收集需要的数据
• 支持 server/proxy+agents 的模式

自动发现监控对象

• 自动发现网络设备
• 监控代理自动注册
• 发现文件系统，网络接口等等

高度可配置化的报警

• 支持收敛的报警策略
• 可以使用宏变量让报警通知更加高效
• 在报警的同时可以执行应对策略

强大的模板功能

• 在模板中分组检查
• 模板可以关联其他模板

完善的权限管理系统

• 安全用户认证
• 特定用户可以限制访问特定的视图

近乎无限的扩展能力

• 支持通过脚本进行扩展

看一眼 zabbix 提供的菜单感受下它的丰富功能：

Prometheus 的主要特点

Prometheus 是一个开源的系统监控和警报工具包，许多公司和组织都采用了 Prometheus，该项目拥有非常活跃的开发人员和用户社区。下面是 prometheus 的一些主要特点：

• 多维度数据模型
• 灵活的查询语言
• 不依赖分布式存储，单个服务器节点是自主的
• 通过 pull 方式采集时序数据
• 可以通过中间网关进行时序列数据推送
• 通过服务发现或者静态配置来发现目标服务对象
• 支持多种界面展示方案，比如 grafana 等

事实上，业界多把 prometheus 用于容器监控的解决方案，比如与 k8s 的集成。使用 cadvisor + prometheus + grafana 搭建容器监控事实上已经成为了中小企业的首选方案。下图是由 grafana 展示的单台主机上运行容器的汇总信息(当然，数据源来自 prometheus)：

其实，prometheus 的扩展性也很好，通过扩展不同的 exporter 可以收集不同应用、设备的信息。

使用 zabbix 监控容器的缺点

Zabbix 的功能非常全面，以至于仅仅用它来监控容器让我们觉着是大材小用了，同时也难免会觉着它不太专业(就监控容器来说)。
事实上 zabbix 监控容器的能力一点也不弱，特别是从版本 4.2 开始，zabbix 也支持 prometheus 做为数据源了。这样一来，zabbix 也就是在视觉展示上比 grafana 差些罢了。
当然 zabbix 还有其它一些问题，比如功能过多(优点有时候也会变成缺点)，如果仅仅需要容器监控功能，会觉着 zabbix 用起来太繁琐了。
Zabbix 使用的是 mysql 数据库，对于时序型的数据，性能上肯定没法和专门的时序型数据库相比。
最后，zabbix 的安装和配置虽然不是很难，但离开箱即用还是有段距离的。

使用 prometheus 监控容器的优缺点

Prometheus 和 zabbix 比起来就轻多了，它就是为容器监控而生的。特别是它使用的是时序型的数据库，对于监控类的场景而言性能非常好。
Prometheus + grafana 做出来的视觉效果非常的棒：

并且多数情况下你都不需要自己动手设计这些图表，下载大家做好的模板，直接就能用，效果棒棒的！
但与 zabbix 相比，grafana 的报警功能却不够灵活。
关于监控信息的收集，zabbix 支持 pull/push 两种模式，而 prometheus 只支持 pull 模式。关于 pull/push 模式，大家的关注点似乎都在性能上。而对于我管理的较小的系统来说基本上没有性能问题，我更关注的是安全性。使用 pull 模式，需要生产环境对外暴露端口号，我们需要为此提供安全性相关的配置，而使用 push 模式则没有这个问题(其实是需要提供监控服务器端的安全配置)。

结论

不管是 zabbix 还是 prometheus 都能够完成容器监控的任务。Zabbix 大而全，在传统的监控领域依然是主流的解决方案。而 prometheus 作为一个轻量级的后起之秀，在性能和展示方面优势比较明显，对容器监控支持的非常好。个人认为，在中小企业中搭建 zabbix 监控平台是非常必要的，它能把大大小小、各式各样的设备管理起来。而对于那些运行在云端的容器，选择 prometheus 搭建独立的监控系统会是个不错的选择。

参考：
Zabbix Documentation 3.4 功能点
Zabbix 4.2 发布：支持 Prometheus 数据收集
《Zabbix 企业级分布式监控系统》
《Zabbix 监控系统深度实践第2版》
Prometheus : 入门
Prometheus and the Debate Over 'Push' Versus 'Pull' Monitoring

https://www.cnblogs.com/sparkdev/category/1092445.html

Vargrant 构建 linux 开发环境

$haohao cd /Users/haohao
$haohao mkdir vagrant

$haohao vagrant box add ubuntu-server-16.04 ubuntu-server-16.04-amd64-vagrant.box
==> box: Box file was not detected as metadata. Adding it directly...
==> box: Adding box 'ubuntu-server-16.04' (v0) for provider:
    box: Unpacking necessary files from: file:///Users/haohao/vagrant/ubuntu-server-16.04-amd64-vagrant.box
==> box: Successfully added box 'ubuntu-server-16.04' (v0) for 'virtualbox'!

$haohao vagrant box list
ubuntu-server-16.04 (virtualbox, 0)

$haohao vagrant init 'ubuntu-server-16.04'
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.

$haohao vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'ubuntu-server-16.04'...
==> default: Matching MAC address for NAT networking...
==> default: Setting the name of the VM: vagrant_default_1524288099752_62326
==> default: Clearing any previously set network interfaces...
.....
==> default: Mounting shared folders...
    default: /vagrant => /Users/haohao/vagrant

$haohao vagrant ssh
Welcome to Ubuntu 16.04.3 LTS (GNU/Linux 4.4.0-98-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

  Get cloud support with Ubuntu Advantage Cloud Guest:
    http://www.ubuntu.com/business/services/cloud

0 packages can be updated.
0 updates are security updates.

Last login: Sat Apr 21 05:28:37 2018 from 10.0.2.2
ubuntu@ubuntu-xenial:~$

ubuntu@ubuntu-xenial:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            490M     0  490M   0% /dev
tmpfs           100M  3.1M   97M   4% /run
/dev/sda1       9.7G  857M  8.8G   9% /
tmpfs           497M     0  497M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           497M     0  497M   0% /sys/fs/cgroup
vagrant         234G   49G  185G  21% /vagrant
tmpfs           100M     0  100M   0% /run/user/1000

# ls 查看该共享目录内容和宿主机内容一致
ubuntu@ubuntu-xenial:~$ ls /vagrant/
ubuntu-xenial-16.04-cloudimg-console.log  Vagrantfile

config.vm.provider "virtualbox" do |v|
  v.customize ["modifyvm", :id, "--name", "ubuntu", "--memory", "1024"]
end

config.vm.network :private_network, ip: "11.11.11.11"

config.vm.hostname = "kubernetes"

# 第一个参数是主机的目录，第二个参数是虚拟机挂载的目录
config.vm.synced_folder  "/Users/haohao/data", "/vagrant_data"

config.vm.network :forwarded_port, guest: 80, host: 8080

$ vagrant global-status                                                                                                                                
id       name    provider   state   directory
------------------------------------------------------------------------
aeb2f19  default virtualbox running /Users/haohao/vagrant
2cd1f42  default virtualbox aborted /Users/haohao/vagrant-test
943c1bf  default virtualbox aborted /Users/haohao/work/vm

$ vagrant ssh-config                                                                                                                                   
Host default
  HostName 127.0.0.1
  User ubuntu
  Port 2222
  UserKnownHostsFile /dev/null
  StrictHostKeyChecking no
  PasswordAuthentication no
  IdentityFile /Users/haohao/vagrant/.vagrant/machines/default/virtualbox/private_key
  IdentitiesOnly yes
  LogLevel FATAL1

Vagrant.configure("2") do |config|
  config.vm.define :web do |web|
    web.vm.provider "virtualbox" do |v|
          v.customize ["modifyvm", :id, "--name", "web", "--memory", "512"]
    end
    web.vm.box = "ubuntu-server-16.04"
    web.vm.hostname = "web"
    web.vm.network :private_network, ip: "11.11.1.1"
  end

  config.vm.define :db do |db|
    db.vm.provider "virtualbox" do |v|
          v.customize ["modifyvm", :id, "--name", "db", "--memory", "512"]
    end
    db.vm.box = "ubuntu-server-16.04"
    db.vm.hostname = "db"
    db.vm.network :private_network, ip: "11.11.1.2"
  end
end

原文地址：https://www.cnblogs.com/Leo_wl/p/11731148.html