分类 系统运维 下的文章

这个开源解决方案可以简单而有效地监控你的云基础设施。

Sensu 是一个开源的基础设施和应用程序监控解决方案,它可以监控服务器、相关服务和应用程序健康状况,并通过第三方集成发送警报和通知。Sensu 用 Ruby 编写,可以使用 RabbitMQRedis 来处理消息,它使用 Redis 来存储数据。

如果你想以一种简单而有效的方式监控云基础设施,Sensu 是一个不错的选择。它可以与你的组织已经使用的许多现代 DevOps 组件集成,比如 SlackHipChatIRC,它甚至可以用 PagerDuty 发送移动或寻呼机的警报。

Sensu 的模块化架构意味着每个组件都可以安装在同一台服务器上或者在完全独立的机器上。

结构

Sensu 的主要通信机制是 Transport。每个 Sensu 组件必须连接到 Transport 才能相互发送消息。Transport 可以使用 RabbitMQ(在生产环境中推荐使用)或 Redis。

Sensu 服务器处理事件数据并采取行动。它注册客户端并使用过滤器、增变器和处理程序检查结果和监视事件。服务器向客户端发布检查说明,Sensu API 提供 RESTful API,提供对监控数据和核心功能的访问。

Sensu 客户端执行 Sensu 服务器安排的检查或本地检查定义。Sensu 使用数据存储(Redis)来保存所有的持久数据。最后,Uchiwa 是与 Sensu API 进行通信的 Web 界面。

 title=

安装 Sensu

条件

  • 一个 Linux 系统作为服务器节点(本文使用了 CentOS 7)
  • 要监控的一台或多台 Linux 机器(客户机)

服务器侧

Sensu 需要安装 Redis。要安装 Redis,启用 EPEL 仓库:

$ sudo yum install epel-release -y

然后安装 Redis:

$ sudo yum install redis -y

修改 /etc/redis.conf 来禁用保护模式,监听每个地址并设置密码:

$ sudo sed -i 's/^protected-mode yes/protected-mode no/g' /etc/redis.conf
$ sudo sed -i 's/^bind 127.0.0.1/bind 0.0.0.0/g' /etc/redis.conf
$ sudo sed -i 's/^# requirepass foobared/requirepass password123/g' /etc/redis.conf

启用并启动 Redis 服务:

$ sudo systemctl enable redis
$ sudo systemctl start redis

Redis 现在已经安装并准备好被 Sensu 使用。

现在让我们来安装 Sensu。

首先,配置 Sensu 仓库并安装软件包:

$ sudo tee /etc/yum.repos.d/sensu.repo << EOF
[sensu]
name=sensu
baseurl=https://sensu.global.ssl.fastly.net/yum/\$releasever/\$basearch/
gpgcheck=0
enabled=1
EOF

$ sudo yum install sensu uchiwa -y

让我们为 Sensu 创建最简单的配置文件:

$ sudo tee /etc/sensu/conf.d/api.json << EOF
{
  "api": {
        "host": "127.0.0.1",
        "port": 4567
  }
}
EOF

然后,配置 sensu-api 在本地主机上使用端口 4567 监听:

$ sudo tee /etc/sensu/conf.d/redis.json << EOF
{
  "redis": {
        "host": "<IP of server>",
        "port": 6379,
        "password": "password123"
  }
}
EOF


$ sudo tee /etc/sensu/conf.d/transport.json << EOF
{
  "transport": {
        "name": "redis"
  }
}
EOF

在这两个文件中,我们将 Sensu 配置为使用 Redis 作为传输机制,还有 Reids 监听的地址。客户端需要直接连接到传输机制。每台客户机都需要这两个文件。

$ sudo tee /etc/sensu/uchiwa.json << EOF
{
   "sensu": [
        {
        "name": "sensu",
        "host": "127.0.0.1",
        "port": 4567
        }
   ],
   "uchiwa": {
        "host": "0.0.0.0",
        "port": 3000
   }
}
EOF

在这个文件中,我们配置 Uchiwa 监听每个地址(0.0.0.0)的端口 3000。我们还配置 Uchiwa 使用 sensu-api(已配置好)。

出于安全原因,更改刚刚创建的配置文件的所有者:

$ sudo chown -R sensu:sensu /etc/sensu

启用并启动 Sensu 服务:

$ sudo systemctl enable sensu-server sensu-api sensu-client
$ sudo systemctl start sensu-server sensu-api sensu-client
$ sudo systemctl enable uchiwa
$ sudo systemctl start uchiwa

尝试访问 Uchiwa 网站:http://<服务器的 IP 地址>:3000

对于生产环境,建议运行 RabbitMQ 集群作为 Transport 而不是 Redis(虽然 Redis 集群也可以用于生产环境),运行多个 Sensu 服务器实例和 API 实例,以实现负载均衡和高可用性。

Sensu 现在安装完成,让我们来配置客户端。

客户端侧

要添加一个新客户端,你需要通过创建 /etc/yum.repos.d/sensu.repo 文件在客户机上启用 Sensu 仓库。

$ sudo tee /etc/yum.repos.d/sensu.repo << EOF
[sensu]
name=sensu
baseurl=https://sensu.global.ssl.fastly.net/yum/\$releasever/\$basearch/
gpgcheck=0
enabled=1
EOF

启用仓库后,安装 Sensu:

$ sudo yum install sensu -y

要配置 sensu-client,创建在服务器中相同的 redis.jsontransport.json,还有 client.json 配置文件:

$ sudo tee /etc/sensu/conf.d/client.json << EOF
{
  "client": {
        "name": "rhel-client",
        "environment": "development",
        "subscriptions": [
        "frontend"
        ]
  }
}
EOF

name 字段中,指定一个名称来标识此客户机(通常是主机名)。environment 字段可以帮助你过滤,而 subscriptions 定义了客户机将执行哪些监视检查。

最后,启用并启动服务并签入 Uchiwa,因为客户机会自动注册:

$ sudo systemctl enable sensu-client
$ sudo systemctl start sensu-client

Sensu 检查

Sensu 检查有两个组件:一个插件和一个定义。

Sensu 与 Nagios 检查插件规范兼容,因此无需修改即可使用用于 Nagios 的任何检查。检查是可执行文件,由 Sensu 客户机运行。

检查定义可以让 Sensu 知道如何、在哪以及何时运行插件。

客户端侧

让我们在客户机上安装一个检查插件。请记住,此插件将在客户机上执行。

启用 EPEL 并安装 nagios-plugins-http

$ sudo yum install -y epel-release
$ sudo yum install -y nagios-plugins-http

现在让我们通过手动执行它来了解这个插件。尝试检查客户机上运行的 Web 服务器的状态。它应该会失败,因为我们并没有运行 Web 服务器:

$ /usr/lib64/nagios/plugins/check_http -I 127.0.0.1
connect to address 127.0.0.1 and port 80: Connection refused
HTTP CRITICAL - Unable to open TCP socket

不出所料,它失败了。检查执行的返回值:

$ echo $?
2

Nagios 检查插件规范定义了插件执行的四个返回值:

插件返回码状态
0OK
1WARNING
2CRITICAL
3UNKNOWN

有了这些信息,我们现在可以在服务器上创建检查定义。

服务器侧

在服务器机器上,创建 /etc/sensu/conf.d/check_http.json 文件:

{
  "checks": {
    "check_http": {
      "command": "/usr/lib64/nagios/plugins/check_http -I 127.0.0.1",
      "interval": 10,
      "subscribers": [
        "frontend"
      ]
    }
  }
}

command 字段中,使用我们之前测试过的命令。interval 会告诉 Sensu 这个检查的频率,以秒为单位。最后,subscribers 将定义执行检查的客户机。

重新启动 sensu-apisensu-server 并确认新检查在 Uchiwa 中可用。

$ sudo systemctl restart sensu-api sensu-server

接下来

Sensu 是一个功能强大的工具,本文只简要介绍它可以干什么。参阅文档了解更多信息,访问 Sensu 网站了解有关 Sensu 社区的更多信息。


via: https://opensource.com/article/18/8/getting-started-sensu-monitoring-solution

作者:Michael Zamot 选题:lujun9972 译者:MjSeven 校对:wxy

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

创建统一管理的,具备灵活性的云原生生产部署来部署一个个性化的数据库即服务(DBaaS)。

 title=

通过在 Kubernetes 上运行 PostgreSQL 数据库,你能创建统一管理的,具备灵活性的云原生生产部署应用来部署一个个性化的数据库即服务为你的特定需求进行量身定制。

对于 Kubernetes,使用 Operator 允许你提供额外的上下文去管理有状态应用。当使用像PostgreSQL 这样开源的数据库去执行包括配置、扩展、高可用和用户管理时,Operator 也很有帮助。

让我们来探索如何在 Kubernetes 上启动并运行 PostgreSQL。

安装 PostgreSQL Operator

将 PostgreSQL 和 Kubernetes 结合使用的第一步是安装一个 Operator。在针对 Linux 系统的Crunchy 的快速启动脚本的帮助下,你可以在任意基于 Kubernetes 的环境下启动和运行开源的Crunchy PostgreSQL Operator

快速启动脚本有一些必要前提:

  • Wget 工具已安装。
  • kubectl 工具已安装。
  • 在你的 Kubernetes 中已经定义了一个 StorageClass
  • 拥有集群权限的可访问 Kubernetes 的用户账号,以安装 Operator 的 RBAC 规则。
  • 一个 PostgreSQL Operator 的 命名空间

执行这个脚本将提供给你一个默认的 PostgreSQL Operator 部署,其默认假设你采用 动态存储和一个名为 standard 的 StorageClass。这个脚本允许用户采用自定义的值去覆盖这些默认值。

通过下列命令,你能下载这个快速启动脚本并把它的权限设置为可执行:

wget <https://raw.githubusercontent.com/CrunchyData/postgres-operator/master/examples/quickstart.sh>
chmod +x ./quickstart.sh

然后你运行快速启动脚本:

./examples/quickstart.sh

在脚本提示你相关的 Kubernetes 集群基本信息后,它将执行下列操作:

  • 下载 Operator 配置文件
  • $HOME/.pgouser 这个文件设置为默认设置
  • 以 Kubernetes Deployment 部署 Operator
  • 设置你的 .bashrc 文件包含 Operator 环境变量
  • 设置你的 $HOME/.bash_completion 文件为 pgo bash_completion 文件

在快速启动脚本的执行期间,你将会被提示在你的 Kubernetes 集群设置 RBAC 规则。在另一个终端,执行快速启动命令所提示你的命令。

一旦这个脚本执行完成,你将会得到提示设置一个端口以转发到 PostgreSQL Operator pod。在另一个终端,执行这个端口转发操作;这将允许你开始对 PostgreSQL Operator 执行命令!尝试输入下列命令创建集群:

pgo create cluster mynewcluster

你能输入下列命令测试你的集群运行状况:

pgo test mynewcluster

现在,你能在 Kubernetes 环境下管理你的 PostgreSQL 数据库了!你可以在官方文档找到非常全面的命令,包括扩容,高可用,备份等等。

这篇文章部分参考了该作者为 Crunchy 博客而写的在 Kubernetes 上开始运行 PostgreSQL


via: https://opensource.com/article/19/3/how-run-postgresql-kubernetes

作者:Jonathan S. Katz 选题:lujun9972 译者:arrowfeng 校对:wxy

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

Docker 作为一款容器化应用的新兴软件,被大多数 IT 公司使用来减少基础设施平台的成本。

通常,没有 GUI 的 Docker 软件对于 Linux 管理员来说很容易,但是对于开发者来就有点困难。当把它搬到生产环境上来,那么它对 Linux 管理员来说也相当不友好。那么,轻松管理 Docker 的最佳解决方案是什么呢?

唯一的办法就是提供 GUI。Docker API 允许第三方应用接入 Docker。在市场上有许多 Docker GUI 应用。我们已经写过一篇关于 Portainer 应用的文章。今天我们来讨论另一个应用,Rancher。

容器让软件开发更容易,让开发者更快的写代码、更好的运行它们。但是,在生产环境上运行容器却很困难。

推荐阅读: Portainer:一个简单的 Docker 管理图形工具

Rancher 简介

Rancher 是一个全面的容器管理平台,它可以让容器在各种基础设施平台的生产环境上部署和运行更容易。它提供了诸如多主机网络、全局/本地负载均衡和卷快照等基础设施服务。它整合了原生 Docker 的管理能力,如 Docker Machine 和 Docker Swarm。它提供了丰富的用户体验,让 DevOps 管理员在更大规模的生产环境上运行 Docker。

访问以下文章可以了解 Linux 系统上安装 Docker。

推荐阅读:

Rancher 特性

  • 可以在两分钟内安装 Kubernetes。
  • 一键启动应用(90 个流行的 Docker 应用)。
  • 部署和管理 Docker 更容易。
  • 全面的生产级容器管理平台。
  • 可以在生产环境上快速部署容器。
  • 强大的自动部署和运营容器技术。
  • 模块化基础设施服务。
  • 丰富的编排工具。
  • Rancher 支持多种认证机制。

怎样安装 Rancher

由于 Rancher 是以轻量级的 Docker 容器方式运行,所以它的安装非常简单。Rancher 是由一组 Docker 容器部署的。只需要简单的启动两个容器就能运行 Rancher。一个容器用作管理服务器,另一个容器在各个节点上作为代理。在 Linux 系统下简单的运行下列命令就能部署 Rancher。

Rancher 服务器提供了两个不同的安装包标签如 stablelatest。下列命令将会拉取适合的 Rancher 镜像并安装到你的操作系统上。Rancher 服务器仅需要两分钟就可以启动。

  • latest:这个标签是他们的最新开发构建。这些构建将通过 Rancher CI 的自动化框架进行验证,不建议在生产环境使用。
  • stable:这是最新的稳定发行版本,推荐在生产环境使用。

Rancher 的安装方法有多种。在这篇教程中我们仅讨论两种方法。

  • 以单一容器的方式安装 Rancher(内嵌 Rancher 数据库)
  • 以单一容器的方式安装 Rancher(外部数据库)

方法 - 1

运行下列命令以单一容器的方式安装 Rancher 服务器(内嵌数据库)

$ sudo docker run -d --restart=unless-stopped -p 8080:8080 rancher/server:stable
$ sudo docker run -d --restart=unless-stopped -p 8080:8080 rancher/server:latest

方法 - 2

你可以在启动 Rancher 服务器时指向外部数据库,而不是使用自带的内部数据库。首先创建所需的数据库,数据库用户为同一个。

> CREATE DATABASE IF NOT EXISTS cattle COLLATE = 'utf8_general_ci' CHARACTER SET = 'utf8';
> GRANT ALL ON cattle.* TO 'cattle'@'%' IDENTIFIED BY 'cattle';
> GRANT ALL ON cattle.* TO 'cattle'@'localhost' IDENTIFIED BY 'cattle';

运行下列命令启动 Rancher 去连接外部数据库。

$ sudo docker run -d --restart=unless-stopped -p 8080:8080 rancher/server \
 --db-host myhost.example.com --db-port 3306 --db-user username --db-pass password --db-name cattle

如果你想测试 Rancher 2.0,使用下列的命令去启动。

$ sudo docker run -d --restart=unless-stopped -p 80:80 -p 443:443 rancher/server:preview

通过 GUI 访问 & 安装 Rancher

浏览器输入 http://hostname:8080http://server_ip:8080 去访问 rancher GUI.

怎样注册主机

注册你的主机 URL 允许它连接到 Rancher API。这是一次性设置。

接下来,点击主菜单下面的 “Add a Host” 链接或者点击主菜单上的 “INFRASTRUCTURE >> Add Hosts”,点击 “Save” 按钮。

默认情况下,Rancher 里的访问控制认证禁止了访问,因此我们首先需要通过一些方法打开访问控制认证,否则任何人都不能访问 GUI。

点击 “>> Admin >> Access Control”,输入下列的值最后点击 “Enable Authentication” 按钮去打开它。在我这里,是通过 “local authentication” 的方式打开的。

  • “Login UserName”: 输入你期望的登录名
  • “Full Name”: 输入你的全名
  • “Password”: 输入你期望的密码
  • “Confirm Password”: 再一次确认密码

注销然后使用新的登录凭证重新登录:

现在,我能看到本地认证已经被打开。

怎样添加主机

注册你的主机后,它将带你进入下一个页面,在那里你能选择不同云服务提供商的 Linux 主机。我们将添加一个主机运行 Rancher 服务,因此选择“custom”选项然后输入必要的信息。

在第 4 步输入你服务器的公有 IP,运行第 5 步列出的命令,最后点击 “close” 按钮。

$ sudo docker run -e CATTLE_AGENT_IP="192.168.56.2"  --rm --privileged -v /var/run/docker.sock:/var/run/docker.sock -v /var/lib/rancher:/var/lib/rancher rancher/agent:v1.2.11 http://192.168.56.2:8080/v1/scripts/16A52B9BE2BAB87BB0F5:1546214400000:ODACe3sfis5V6U8E3JASL8jQ

INFO: Running Agent Registration Process, CATTLE_URL=http://192.168.56.2:8080/v1
INFO: Attempting to connect to: http://192.168.56.2:8080/v1
INFO: http://192.168.56.2:8080/v1 is accessible
INFO: Configured Host Registration URL info: CATTLE_URL=http://192.168.56.2:8080/v1 ENV_URL=http://192.168.56.2:8080/v1
INFO: Inspecting host capabilities
INFO: Boot2Docker: false
INFO: Host writable: true
INFO: Token: xxxxxxxx
INFO: Running registration
INFO: Printing Environment
INFO: ENV: CATTLE_ACCESS_KEY=9946BD1DCBCFEF3439F8
INFO: ENV: CATTLE_AGENT_IP=192.168.56.2
INFO: ENV: CATTLE_HOME=/var/lib/cattle
INFO: ENV: CATTLE_REGISTRATION_ACCESS_KEY=registrationToken
INFO: ENV: CATTLE_REGISTRATION_SECRET_KEY=xxxxxxx
INFO: ENV: CATTLE_SECRET_KEY=xxxxxxx
INFO: ENV: CATTLE_URL=http://192.168.56.2:8080/v1
INFO: ENV: DETECTED_CATTLE_AGENT_IP=172.17.0.1
INFO: ENV: RANCHER_AGENT_IMAGE=rancher/agent:v1.2.11
INFO: Launched Rancher Agent: e83b22afd0c023dabc62404f3e74abb1fa99b9a178b05b1728186c9bfca71e8d

等待几秒钟后新添加的主机将会出现。点击 “Infrastructure >> Hosts” 页面。

怎样查看容器

只需要点击下列位置就能列出所有容器。点击 “Infrastructure >> Containers” 页面。

怎样创建容器

非常简单,只需点击下列位置就能创建容器。

点击 “Infrastructure >> Containers >> Add Container” 然后输入每个你需要的信息。为了测试,我将创建一个 latest 标签的 CentOS 容器。

在同样的列表位置,点击 “ Infrastructure >> Containers”。

点击容器名展示容器的性能信息,如 CPU、内存、网络和存储。

选择特定容器,然后点击最右边的“三点”按钮或者点击“Actions”按钮对容器进行管理,如停止、启动、克隆、重启等。

如果你想控制台访问容器,只需要点击 “Actions” 按钮中的 “Execute Shell” 选项即可。

怎样从应用目录部署容器

Rancher 提供了一个应用模版目录,让部署变的很容易,只需要单击一下就可以。 它维护了多数流行应用,这些应用由 Rancher 社区贡献。

点击 “Catalog >> All >> Choose the required application”,最后点击 “Launch” 去部署。


via: https://www.2daygeek.com/rancher-a-complete-container-management-platform-for-production-environment/

作者:Magesh Maruthamuthu 译者:arrowfeng 校对:wxy

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

五种优化 Linux 容器大小和构建更小的镜像的方法。

Docker 近几年的爆炸性发展让大家逐渐了解到容器和容器镜像的概念。尽管 Linux 容器技术在很早之前就已经出现,但这项技术近来的蓬勃发展却还是要归功于 Docker 对用户友好的命令行界面以及使用 Dockerfile 格式轻松构建镜像的方式。纵然 Docker 大大降低了入门容器技术的难度,但构建一个兼具功能强大、体积小巧的容器镜像的过程中,有很多技巧需要了解。

第一步:清理不必要的文件

这一步和在普通服务器上清理文件没有太大的区别,而且要清理得更加仔细。一个小体积的容器镜像在传输方面有很大的优势,同时,在磁盘上存储不必要的数据的多个副本也是对资源的一种浪费。因此,这些技术对于容器来说应该比有大量专用内存的服务器更加需要。

清理容器镜像中的缓存文件可以有效缩小镜像体积。下面的对比是使用 dnf 安装 Nginx 构建的镜像,分别是清理和没有清理 yum 缓存文件的结果:

# Dockerfile with cache
FROM fedora:28
LABEL maintainer Chris Collins <[email protected]>

RUN dnf install -y nginx

-----

# Dockerfile w/o cache
FROM fedora:28
LABEL maintainer Chris Collins <[email protected]>

RUN dnf install -y nginx \
        && dnf clean all \
        && rm -rf /var/cache/yum

-----

[chris@krang] $ docker build -t cache -f Dockerfile .  
[chris@krang] $ docker images --format "{{.Repository}}: {{.Size}}" 
| head -n 1
cache: 464 MB

[chris@krang] $ docker build -t no-cache -f Dockerfile-wo-cache .
[chris@krang] $ docker images --format "{{.Repository}}: {{.Size}}"  | head -n 1
no-cache: 271 MB

从上面的结果来看,清理缓存文件的效果相当显著。和清除了元数据和缓存文件的容器镜像相比,不清除的镜像体积接近前者的两倍。除此以外,包管理器缓存文件、Ruby gem 的临时文件、nodejs 缓存文件,甚至是下载的源码 tarball 最好都全部清理掉。

层:一个潜在的隐患

很不幸(当你往下读,你会发现这是不幸中的万幸),根据容器中的层的概念,不能简单地向 Dockerfile 中写一句 RUN rm -rf /var/cache/yum 就完事儿了。因为 Dockerfile 的每一条命令都以一个层的形式存储,并一层层地叠加。所以,如果你是这样写的:

RUN dnf install -y nginx
RUN dnf clean all
RUN rm -rf /var/cache/yum

你的容器镜像就会包含三层,而 RUN dnf install -y nginx 这一层仍然会保留着那些缓存文件,然后在另外两层中被移除。但缓存实际上仍然是存在的,当你把一个文件系统挂载在另外一个文件系统之上时,文件仍然在那里,只不过你见不到也访问不到它们而已。

在上一节的示例中,你会看到正确的做法是将几条命令链接起来,在产生缓存文件的同一条 Dockerfile 指令里把缓存文件清理掉:

RUN dnf install -y nginx \
        && dnf clean all \
        && rm -rf /var/cache/yum

这样就把几条命令连成了一条命令,在最终的镜像中只占用一个层。这样只会浪费一点缓存的好处,稍微多耗费一点点构建容器镜像的时间,但被清理掉的缓存文件就不会留存在最终的镜像中了。作为一个折衷方法,只需要把一些相关的命令(例如 yum installyum clean all、下载文件、解压文件、移除 tarball 等等)连接成一个命令,就可以在最终的容器镜像中节省出大量体积,你也能够利用 Docker 的缓存加快开发速度。

层还有一个更隐蔽的特性。每一层都记录了文件的更改,这里的更改并不仅仅已有的文件累加起来,而是包括文件属性在内的所有更改。因此即使是对文件使用了 chmod 操作也会被在新的层创建文件的副本。

下面是一次 docker images 命令的输出内容。其中容器镜像 layer_test_1 是在 CentOS 基础镜像中增加了一个 1GB 大小的文件后构建出来的镜像,而容器镜像 layer_test_2 是使用了 FROM layer_test_1 语句创建出来的,除了执行一条 chmod u+x 命令没有做任何改变。

layer_test_2        latest       e11b5e58e2fc           7 seconds ago           2.35 GB
layer_test_1        latest       6eca792a4ebe           2 minutes ago           1.27 GB

如你所见,layer_test_2 镜像比 layer_test_1 镜像大了 1GB 以上。尽管事实上 layer_test_1 只是 layer_test_2 的前一层,但隐藏在这第二层中有一个额外的 1GB 的文件。在构建容器镜像的过程中,如果在单独一层中进行移动、更改、删除文件,都会出现类似的结果。

专用镜像和公用镜像

有这么一个亲身经历:我们部门重度依赖于 Ruby on Rails,于是我们开始使用容器。一开始我们就建立了一个正式的 Ruby 的基础镜像供所有的团队使用,为了简单起见(以及在“这就是我们自己在服务器上瞎鼓捣的”想法的指导下),我们使用 rbenv 将 Ruby 最新的 4 个版本都安装到了这个镜像当中,目的是让开发人员只用这个单一的镜像就可以将使用不同版本 Ruby 的应用程序迁移到容器中。我们当时还认为这是一个虽然非常大但兼容性相当好的镜像,因为这个镜像可以同时满足各个团队的使用。

实际上这是费力不讨好的。如果维护独立的、版本略微不同的镜像中,可以很轻松地实现镜像的自动化维护。同时,选择特定版本的特定镜像,还有助于在引入破坏性改变,在应用程序接近生命周期结束前提前做好预防措施,以免产生不可控的后果。庞大的公用镜像也会对资源造成浪费,当我们后来将这个庞大的镜像按照 Ruby 版本进行拆分之后,我们最终得到了共享一个基础镜像的多个镜像,如果它们都放在一个服务器上,会额外多占用一点空间,但是要比安装了多个版本的巨型镜像要小得多。

这个例子也不是说构建一个灵活的镜像是没用的,但仅对于这个例子来说,从一个公共镜像创建根据用途而构建的镜像最终将节省存储资源和维护成本,而在受益于公共基础镜像的好处的同时,每个团队也能够根据需要来做定制化的配置。

从零开始:将你需要的内容添加到空白镜像中

有一些和 Dockerfile 一样易用的工具可以轻松创建非常小的兼容 Docker 的容器镜像,这些镜像甚至不需要包含一个完整的操作系统,就可以像标准的 Docker 基础镜像一样小。

我曾经写过一篇关于 Buildah 的文章,我想在这里再一次推荐一下这个工具。因为它足够的灵活,可以使用宿主机上的工具来操作一个空白镜像并安装打包好的应用程序,而且这些工具不会被包含到镜像当中。

Buildah 取代了 docker build 命令。可以使用 Buildah 将容器的文件系统挂载到宿主机上并进行交互。

下面来使用 Buildah 实现上文中 Nginx 的例子(现在忽略了缓存的处理):

#!/usr/bin/env bash
set -o errexit

# Create a container
container=$(buildah from scratch)

# Mount the container filesystem
mountpoint=$(buildah mount $container)

# Install a basic filesystem and minimal set of packages, and nginx
dnf install --installroot $mountpoint  --releasever 28 glibc-minimal-langpack nginx --setopt install_weak_deps=false -y

# Save the container to an image
buildah commit --format docker $container nginx

# Cleanup
buildah unmount $container

# Push the image to the Docker daemon’s storage
buildah push nginx:latest docker-daemon:nginx:latest

你会发现这里使用的已经不再是 Dockerfile 了,而是普通的 Bash 脚本,而且是从框架(或空白)镜像开始构建的。上面这段 Bash 脚本将容器的根文件系统挂载到了宿主机上,然后使用宿主机的命令来安装应用程序,这样的话就不需要把软件包管理器放置到容器镜像中了。

这样所有无关的内容(基础镜像之外的部分,例如 dnf)就不再会包含在镜像中了。在这个例子当中,构建出来的镜像大小只有 304 MB,比使用 Dockerfile 构建的镜像减少了 100 MB 以上。

[chris@krang] $ docker images |grep nginx
docker.io/nginx      buildah      2505d3597457    4 minutes ago         304 MB

注:这个镜像是使用上面的构建脚本构建的,镜像名称中前缀的 docker.io 只是在推送到镜像仓库时加上的。

对于一个 300MB 级别的容器基础镜像来说,能缩小 100MB 已经是很显著的节省了。使用软件包管理器来安装 Nginx 会带来大量的依赖项,如果能够使用宿主机直接从源代码对应用程序进行编译然后构建到容器镜像中,节省出来的空间还可以更多,因为这个时候可以精细的选用必要的依赖项,非必要的依赖项一概不构建到镜像中。

Tom Sweeney 有一篇文章《用 Buildah 构建更小的容器》,如果你想在这方面做深入的优化,不妨参考一下。

通过 Buildah 可以构建一个不包含完整操作系统和代码编译工具的容器镜像,大幅缩减了容器镜像的体积。对于某些类型的镜像,我们可以进一步采用这种方式,创建一个只包含应用程序本身的镜像。

使用静态链接的二进制文件来构建镜像

按照这个思路,我们甚至可以更进一步舍弃容器内部的管理和构建工具。例如,如果我们足够专业,不需要在容器中进行排错调试,是不是可以不要 Bash 了?是不是可以不要 GNU 核心套件了?是不是可以不要 Linux 基础文件系统了?如果你使用的编译型语言支持静态链接库,将应用程序所需要的所有库和函数都编译成二进制文件,那么程序所需要的函数和库都可以复制和存储在二进制文件本身里面。

这种做法在 Golang 社区中已经十分常见,下面我们使用由 Go 语言编写的应用程序进行展示:

以下这个 Dockerfile 基于 golang:1.8 镜像构建一个小的 Hello World 应用程序镜像:

FROM golang:1.8

ENV GOOS=linux
ENV appdir=/go/src/gohelloworld

COPY ./ /go/src/goHelloWorld
WORKDIR /go/src/goHelloWorld

RUN go get
RUN go build -o /goHelloWorld -a

CMD ["/goHelloWorld"]

构建出来的镜像中包含了二进制文件、源代码以及基础镜像层,一共 716MB。但对于应用程序运行唯一必要的只有编译后的二进制文件,其余内容在镜像中都是多余的。

如果在编译的时候通过指定参数 CGO_ENABLED=0 来禁用 cgo,就可以在编译二进制文件的时候忽略某些函数的 C 语言库:

GOOS=linux CGO_ENABLED=0 go build -a goHelloWorld.go

编译出来的二进制文件可以加到一个空白(或框架)镜像:

FROM scratch
COPY goHelloWorld /
CMD ["/goHelloWorld"]

来看一下两次构建的镜像对比:

[ chris@krang ] $ docker images
REPOSITORY      TAG             IMAGE ID                CREATED                 SIZE
goHello     scratch     a5881650d6e9            13 seconds ago          1.55 MB
goHello     builder     980290a100db            14 seconds ago          716 MB

从镜像体积来说简直是天差地别了。基于 golang:1.8 镜像构建出来带有 goHelloWorld 二进制的镜像(带有 builder 标签)体积是基于空白镜像构建的只包含该二进制文件的镜像的 460 倍!后者的整个镜像大小只有 1.55MB,也就是说,有 713MB 的数据都是非必要的。

正如上面提到的,这种缩减镜像体积的方式在 Golang 社区非常流行,因此不乏这方面的文章。Kelsey Hightower 有一篇文章专门介绍了如何处理这些库的依赖关系。

压缩镜像层

除了前面几节中讲到的将多个命令链接成一个命令的技巧,还可以对镜像进行压缩。镜像压缩的实质是导出它,删除掉镜像构建过程中的所有中间层,然后保存镜像的当前状态为单个镜像层。这样可以进一步将镜像缩小到更小的体积。

在 Docker 1.13 之前,压缩镜像层的的过程可能比较麻烦,需要用到 docker-squash 之类的工具来导出容器的内容并重新导入成一个单层的镜像。但 Docker 在 Docker 1.13 中引入了 --squash 参数,可以在构建过程中实现同样的功能:

FROM fedora:28
LABEL maintainer Chris Collins <[email protected]>

RUN dnf install -y nginx
RUN dnf clean all
RUN rm -rf /var/cache/yum

[chris@krang] $ docker build -t squash -f Dockerfile-squash --squash .
[chris@krang] $ docker images --format "{{.Repository}}: {{.Size}}"  | head -n 1
squash: 271 MB

通过这种方式使用 Dockerfile 构建出来的镜像有 271MB 大小,和上面连接多条命令的方案构建出来的镜像体积一样,因此这个方案也是有效的,但也有一个潜在的问题,而且是另一种问题。

“什么?还有另外的问题?”

好吧,有点像以前一样的问题,以另一种方式引发了问题。

过头了:过度压缩、太小太专用了

容器镜像之间可以共享镜像层。基础镜像或许大小上有几 Mb,但它只需要拉取/存储一次,并且每个镜像都能复用它。所有共享基础镜像的实际镜像大小是基础镜像层加上每个特定改变的层的差异内容,因此,如果有数千个基于同一个基础镜像的容器镜像,其体积之和也有可能只比一个基础镜像大不了多少。

因此,这就是过度使用压缩或专用镜像层的缺点。将不同镜像压缩成单个镜像层,各个容器镜像之间就没有可以共享的镜像层了,每个容器镜像都会占有单独的体积。如果你只需要维护少数几个容器镜像来运行很多容器,这个问题可以忽略不计;但如果你要维护的容器镜像很多,从长远来看,就会耗费大量的存储空间。

回顾上面 Nginx 压缩的例子,我们能看出来这种情况并不是什么大的问题。在这个镜像中,有 Fedora 操作系统和 Nginx 应用程序,没有缓存,并且已经被压缩。但我们一般不会使用一个原始的 Nginx,而是会修改配置文件,以及引入其它代码或应用程序来配合 Nginx 使用,而要做到这些,Dockerfile 就变得更加复杂了。

如果使用普通的镜像构建方式,构建出来的容器镜像就会带有 Fedora 操作系统的镜像层、一个安装了 Nginx 的镜像层(带或不带缓存)、为 Nginx 作自定义配置的其它多个镜像层,而如果有其它容器镜像需要用到 Fedora 或者 Nginx,就可以复用这个容器镜像的前两层。

[   App 1 Layer (  5 MB) ]          [   App 2 Layer (6 MB) ]
[   Nginx Layer ( 21 MB) ] ------------------^
[ Fedora  Layer (249 MB) ]  

如果使用压缩镜像层的构建方式,Fedora 操作系统会和 Nginx 以及其它配置内容都被压缩到同一层里面,如果有其它容器镜像需要使用到 Fedora,就必须重新引入 Fedora 基础镜像,这样每个容器镜像都会额外增加 249MB 的大小。

[ Fedora + Nginx + App 1 (275 MB)]      [ Fedora + Nginx + App 2 (276 MB) ]  

当你构建了大量在功能上趋于分化的的小型容器镜像时,这个问题就会暴露出来了。

就像生活中的每一件事一样,关键是要做到适度。根据镜像层的实现原理,如果一个容器镜像变得越小、越专用化,就越难和其它容器镜像共享基础的镜像层,这样反而带来不好的效果。

对于仅在基础镜像上做微小变动构建出来的多个容器镜像,可以考虑共享基础镜像层。如上所述,一个镜像层本身会带有一定的体积,但只要存在于镜像仓库中,就可以被其它容器镜像复用。这种情况下,数千个镜像也许要比单个镜像占用更少的空间。

[ specific app   ]      [ specific app 2 ]
[ customizations ]--------------^
[ base layer     ]

一个容器镜像变得越小、越专用化,就越难和其它容器镜像共享基础的镜像层,最终会不必要地占用越来越多的存储空间。

 [ specific app 1 ]     [ specific app 2 ]      [ specific app 3 ]

总结

减少处理容器镜像时所需的存储空间和带宽的方法有很多,其中最直接的方法就是减小容器镜像本身的大小。在使用容器的过程中,要经常留意容器镜像是否体积过大,根据不同的情况采用上述提到的清理缓存、压缩到一层、将二进制文件加入在空白镜像中等不同的方法,将容器镜像的体积缩减到一个有效的大小。


via: https://opensource.com/article/18/7/building-container-images

作者:Chris Collins 选题:lujun9972 译者:HankChow 校对:wxy

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

每天似乎都有一个安全漏洞的新闻报道,说我们的数据会因此而存在风险。尽管 SSH 是一种远程连接系统的安全方式,但你仍然可以使它更安全。本文将向你展示如何做到这一点。

此时 双因子验证 two-factor authentication (2FA)就有用武之地了。即使你禁用密码并只允许使用公钥和私钥进行 SSH 连接,但如果未经授权的用户偷窃了你的密钥,他仍然可以借此访问系统。

使用双因子验证,你不能仅仅使用 SSH 密钥连接到服务器,你还需要提供手机上的验证器应用程序随机生成的数字。

本文展示的方法是 基于时间的一次性密码 Time-based One-time Password (TOTP)算法。Google Authenticator 用作服务器应用程序。默认情况下,Google Authenticator 在 Fedora 中是可用的。

至于手机,你可以使用与 TOTP 兼容的任何可以双路验证的应用程序。Andorid 或 iOS 有许多可以与 TOTP 和 Google Authenticator 配合使用的免费应用程序。本文与 FreeOTP 为例。

安装并设置 Google Authenticator

首先,在你的服务器上安装 Google Authenticator。 $ sudo dnf install -y google-authenticator

运行应用程序:

$ google-authenticator

该应用程序提供了一系列问题。下面的片段展示了如何进行合理的安全设置:

Do you want authentication tokens to be time-based (y/n) y
Do you want me to update your "/home/user/.google_authenticator" file (y/n)? y

这个应用程序为你提供一个密钥、验证码和恢复码。把它们放在安全的地方。如果你丢失了手机,恢复码是访问服务器的唯一方式。

设置手机验证

在你的手机上安装验证器应用程序(FreeOTP)。如果你有一台安卓手机,那么你可以在 Google Play 中找到它,也可以在苹果 iPhone 的 iTunes 商店中找到它。

Google Authenticator 会在屏幕上显示一个二维码。打开手机上的 FreeOTP 应用程序,选择添加新账户,在应用程序顶部选择二维码形状工具,然后扫描二维码即可。设置完成后,在每次远程连接服务器时,你必须提供验证器应用程序生成的随机数。

完成配置

应用程序会向你询问更多的问题。下面示例展示了如何设置合理的安全配置。

Do you want to disallow multiple uses of the same authentication token? This restricts you to one login about every 30s, but it increases your chances to notice or even prevent man-in-the-middle attacks (y/n) y
By default, tokens are good for 30 seconds. In order to compensate for possible time-skew between the client and the server, we allow an extra token before and after the current time. If you experience problems with poor time synchronization, you can increase the window from its default size of +-1min (window size of 3) to about +-4min (window size of 17 acceptable tokens).
Do you want to do so? (y/n) n
If the computer that you are logging into isn't hardened against brute-force login attempts, you can enable rate-limiting for the authentication module. By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting (y/n) y

现在,你必须设置 SSH 来利用新的双路验证。

配置 SSH

在完成此步骤之前,确保你已使用公钥建立了一个可用的 SSH 连接,因为我们将禁用密码连接。如果出现问题或错误,一个已经建立的连接将允许你修复问题。

在你的服务器上,使用 sudo 编辑 /etc/pam.d/sshd 文件。

$ sudo vi /etc/pam.d/ssh

注释掉 auth substack password-auth 这一行:

#auth       substack     password-auth

将以下行添加到文件底部:

auth sufficient pam_google_authenticator.so

保存并关闭文件。然后编辑 /etc/ssh/sshd_config 文件:

$ sudo vi /etc/ssh/sshd_config

找到 ChallengeResponseAuthentication 这一行并将其更改为 yes

ChallengeResponseAuthentication yes

找到 PasswordAuthentication 这一行并将其更改为 no

PasswordAuthentication no

将以下行添加到文件底部:

AuthenticationMethods publickey,password publickey,keyboard-interactive

保存并关闭文件,然后重新启动 SSH:

$ sudo systemctl restart sshd

测试双因子验证

当你尝试连接到服务器时,系统会提示你输入验证码:

[user@client ~]$ ssh [email protected]
Verification code:

验证码由你手机上的验证器应用程序随机生成。由于这个数字每隔几秒就会发生变化,因此你需要在它变化之前输入它。

如果你不输入验证码,你将无法访问系统,你会收到一个权限被拒绝的错误:

[user@client ~]$ ssh [email protected]
Verification code:
Verification code:
Verification code:
Permission denied (keyboard-interactive).
[user@client ~]$

结论

通过添加这种简单的双路验证,现在未经授权的用户访问你的服务器将变得更加困难。


via: https://fedoramagazine.org/two-factor-authentication-ssh-fedora/

作者:Curt Warfield 选题:lujun9972 译者:MjSeven 校对:wxy

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

用 Ansible 自动化你的数据中心的关键点。

Ansible 是一个开源自动化工具,可以从中央控制节点统一配置服务器、安装软件或执行各种 IT 任务。它采用一对多、 无客户端 agentless 的机制,从控制节点上通过 SSH 发送指令给远端的客户机来完成任务(当然除了 SSH 外也可以用别的协议)。

Ansible 的主要使用群体是系统管理员,他们经常会周期性地执行一些安装、配置应用的工作。尽管如此,一些非特权用户也可以使用 Ansible,例如数据库管理员就可以通过 Ansible 用 mysql 这个用户来创建数据库、添加数据库用户、定义访问权限等。

让我们来看一个简单的使用场景,一位系统管理员每天要配置 100 台服务器,并且必须在每台机器上执行一系列 Bash 命令,然后交付给用户。

这是个简单的例子,但应该能够证明:在 yaml 文件里写好命令然后在远程服务器上运行,是一件非常轻松的事。而且如果运行环境不同,就可以加入判断条件,指明某些命令只能在特定的服务器上运行(如:只在那些不是 Ubuntu 或 Debian 的系统上运行 yum 命令)。

Ansible 的一个重要特性是用 剧本 playbook 来描述一个计算机系统的最终状态,所以一个剧本可以在服务器上反复执行而不影响其最终状态(LCTT 译注:即是幂等的)。如果某个任务已经被实施过了(如,“用户 sysman 已经存在”),那么 Ansible 就会忽略它继续执行后续的任务。

定义

  • 任务 task :是工作的最小单位,它可以是个动作,比如“安装一个数据库服务”、“安装一个 web 服务器”、“创建一条防火墙规则”或者“把这个配置文件拷贝到那个服务器上去”。
  • 动作 play : 由任务组成,例如,一个动作的内容是要“设置一个数据库,给 web 服务用”,这就包含了如下任务:1)安装数据库包;2)设置数据库管理员密码;3)创建数据库实例;4)为该实例分配权限。
  • 剧本 playbook :(LCTT 译注:playbook 原指美式橄榄球队的战术手册,也常指“剧本”,此处惯例采用“剧本”译名) 由动作组成,一个剧本可能像这样:“设置我的网站,包含后端数据库”,其中的动作包括:1)设置数据库服务器;2)设置 web 服务器。
  • 角色 role :用来保存和组织剧本,以便分享和再次使用它们。还拿上个例子来说,如果你需要一个全新的 web 服务器,就可以用别人已经写好并分享出来的角色来设置。因为角色是高度可配置的(如果编写正确的话),可以根据部署需求轻松地复用它们。
  • Ansible 星系 Ansible Galaxy :是一个在线仓库,里面保存的是由社区成员上传的角色,方便彼此分享。它与 GitHub 紧密集成,因此这些角色可以先在 Git 仓库里组织好,然后通过 Ansible 星系分享出来。

这些定义以及它们之间的关系可以用下图来描述:

请注意上面的例子只是组织任务的方式之一,我们当然也可以把安装数据库和安装 web 服务器的剧本拆开,放到不同的角色里。Ansible 星系上最常见的角色是独立安装、配置每个应用服务,你可以参考这些安装 mysqlhttpd 的例子。

编写剧本的小技巧

学习 Ansible 最好的资源是其官方文档。另外,像学习其他东西一样,搜索引擎是你的好朋友。我推荐你从一些简单的任务开始,比如安装应用或创建用户。下面是一些有用的指南:

  • 在测试的时候少选几台服务器,这样你的动作可以执行的更快一些。如果它们在一台机器上执行成功,在其他机器上也没问题。
  • 总是在真正运行前做一次 测试 dry run ,以确保所有的命令都能正确执行(要运行测试,加上 --check-mode 参数 )。
  • 尽可能多做测试,别担心搞砸。任务里描述的是所需的状态,如果系统已经达到预期状态,任务会被简单地忽略掉。
  • 确保在 /etc/ansible/hosts 里定义的主机名都可以被正确解析。
  • 因为是用 SSH 与远程主机通信,主控节点必须要能接受密钥,所以你面临如下选择:1)要么在正式使用之前就做好与远程主机的密钥交换工作;2)要么在开始管理某台新的远程主机时做好准备输入 “Yes”,因为你要接受对方的 SSH 密钥交换请求(LCTT 译注:还有另一个不那么安全的选择,修改主控节点的 ssh 配置文件,将 StrictHostKeyChecking 设置成 “no”)。
  • 尽管你可以在同一个剧本内把不同 Linux 发行版的任务整合到一起,但为每个发行版单独编写剧本会更明晰一些。

总结一下

Ansible 是你在数据中心里实施运维自动化的好选择,因为它:

  • 无需客户端,所以比其他自动化工具更易安装。
  • 将指令保存在 YAML 文件中(虽然也支持 JSON),比写 shell 脚本更简单。
  • 开源,因此你也可以做出自己的贡献,让它更加强大!

你是怎样使用 Ansible 让数据中心更加自动化的呢?请在评论中分享您的经验。


via: https://opensource.com/article/18/2/tips-success-when-getting-started-ansible

作者:Jose Delarosa 译者:jdh8383 校对:wxy

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