Monasca 服务在 Docker 中

本故事的主要任务是将所有 Monasca 组件的 Docker 镜像的构建和发布从 https://github.com/monasca/monasca-docker 迁移到各自的 OpenStack 仓库。

问题描述

目前，Monasca 组件的 Docker 镜像是从 monasca-docker 仓库 中提供的 Dockerfile 构建的。构建和发布镜像的过程需要显式触发，并且描述在 这里。由于镜像定义和实际的上游代码分离，它们很容易出现偏差。

用例

支持并标准化使用 Docker 部署 Monasca 服务的方式。

从开发角度来看，变化非常小。

开发人员编写代码并将其放入 Gerrit，然后自动流程测试 Docker 镜像是否可以正确构建。

这些镜像可以在 OpenStack CI 中的集成测试中使用。

最终用户不应看到任何变化。

部署者拥有更多一种支持的 Monasca 部署方式。

提议的变更

每个包含组件的仓库都将包含一个额外的 docker 文件夹，其中包含构建 Docker 镜像所需的所有文件。

示例文件

• Dockerfile

• README

• 启动脚本，它将模板化所需的配置文件，等待其他所需的组件可用（如 Keystone），并在 Docker 镜像运行时启动服务。

• 配置文件的模板、用于配置数据库模式的引导脚本等。

该过程应在提交推送到 git 仓库后启动（因此所有测试都通过）。目标是完全自动化的流程，无需人工干预。每个镜像都应该有一种简单且标准化的方式来获取其构建的 Monasca 组件版本信息（对于 master 和 latest 标签来说绝对是必需的）。每个 Dockerfile 都在单独的仓库中，因此需要对这些文件进行标准化，以便它们看起来大致相同。存在用于 Dockerfile 的 lint 工具，需要选择一个并添加到测试流程中（这将有助于 Dockerfile 的标准化，检查 Kolla 作业）。

镜像将使用 Python 3.5 构建。如果任何 Monasca 服务不支持 Python 3，我们将等待支持后再为其创建容器。

镜像将发布到 https://hub.docker.com/u/monasca/

每个镜像都应该包含一个 RST 格式的 README 文件，其中包含有关运行特定组件的信息。

我们将支持 Docker 的实际稳定版本和前两个版本。

所有稳定分支都将拥有构建镜像的特定 Docker 版本，并且这些版本将在从 master 分支时冻结。Master 分支将使用 3 个最新的 Docker 版本构建。

所有镜像都将基于自定义的 monasca-base 镜像构建，该镜像使用 Alpine Linux 上的官方 Python 以节省磁盘空间。我们将使用来自其他基础镜像示例中的想法进行最小配置（例如基于 Ubuntu https://github.com/phusion/baseimage-docker 或基于 Alpine https://github.com/blacklabelops/baseimages）。

所有镜像都应以尝试使其尽可能小的的方式创建，而不会影响功能。可以在以下文章中找到减小镜像大小的可能方法

https://blog.codeship.com/alpine-based-docker-images-make-difference-real-world-apps/

https://docs.container.net.cn/develop/develop-images/dockerfile_best-practices/

所有镜像都标准化使用 Jinja2 模板化配置文件，使用以下工具

• https://github.com/Aisbergg/python-templer - Python3 命令行工具，用于在 shell 脚本中进行模板化，利用 Jinja2 库

  • 允许使用环境变量

  • 支持 YAML 数据源

  • LGPL 许可证，但我们不是链接到它，只是使用 CLI

备选方案

作为 CI 配置的示例，我们可以使用 Kolla 创建 Docker 镜像的过程：https://github.com/openstack/kolla https://hub.docker.com/u/kolla/。但是，它对于我们的需求来说过于复杂，因此应该仅作为参考使用。

用于模板化

• https://github.com/wrouesnel/p2cli - 命令行工具，用于渲染 pongo2（类似于 Django 语法，类似于 Jinja2）模板（Go 二进制文件，如果镜像中已经有 Python，则大小小 4 倍）

  • 允许使用环境变量

  • 支持 YAML、JSON 数据源

• https://github.com/jwilder/dockerize - 用于简化在 docker 容器中运行应用程序的实用程序（Go 二进制文件）

  • 在容器启动时从模板和容器环境变量生成应用程序配置文件

  • 将多个日志文件输出到 stdout 和/或 stderr

  • 使用 TCP、HTTP(S)、unix 等待其他服务可用，然后再启动主进程。

数据模型影响

无

REST API 影响

无

安全影响

所有服务都将在 Docker 容器中关闭。

其他最终用户影响

无

性能影响

由于额外的 Docker 层，服务可能会运行得更慢。

其他部署者影响

部署应该更容易，因为部署者只需要创建配置，并且所有依赖项都将包含在 Docker 镜像中。

开发者影响

添加新依赖项或更改 Monasca 组件安装方式的功能必须反映在 Docker 镜像定义中。

实现

负责人

主要负责人

dobroslaw-zybort <dobroslaw.zybort@ts.fujitsu.com>

工作项

需要什么

• 为 Gerrit 中的每次更改构建测试镜像。

  • 自动流程在每次 git 提交时构建镜像并将其推送到 Docker Hub。

  • 自动流程在每次标记时构建镜像并将其推送到 Docker Hub。

  • 自动流程在 OpenStack 发布时构建镜像并将其推送到 Docker Hub（可能是第二步）。

• 添加带有镜像源代码信息（例如构建日期、提交 sha1）的标签。

• 在每次代码提交时运行集成测试以验证 Docker 二进制文件。使用 Docker Compose 的单节点部署设置。

  • Tempest 测试。

  • Smoke 测试。

Docker Hub 上的五种标签

• 在每次新发布/标记时。

• latest 指向最后一个标签。

• master 指向最后的 git 提交 - 有助于测试最新的更改/修复程序。

• 指向稳定 OpenStack 版本（queens、rocky 等）的最后一个提交的标签 - 有助于测试最新的更改/修复程序。

可选

• 使用 Python 3.6 构建所有镜像并测试稳定性。

• 使用 Kubernetes Helm 运行多节点部署集成测试。

需要记住（为了更容易维护）

• 使用正确的 init 进程。

• 安装过程后清理。

• 所有仓库中启动脚本的名称相同。

• 在所有仓库中使用相同的配置模板化机制。

• 所有组件都应从 Git 仓库下载，并能够更改分支以构建 Docker 镜像（对于测试 Gerrit 中提出的更改很有用）。

本故事的非目标（可能是下一步）

• 自动流程在特定过去的提交时构建镜像并将其推送到 Docker Hub。

• 将 Devstack 迁移到 Monasca 的 Docker 镜像。

依赖项

应该移动到哪里

• https://github.com/monasca/monasca-docker/tree/master/monasca-agent-base => https://github.com/openstack/monasca-agent

• https://github.com/monasca/monasca-docker/tree/master/monasca-agent-collector => https://github.com/openstack/monasca-agent

• https://github.com/monasca/monasca-docker/tree/master/monasca-agent-forwarder => https://github.com/openstack/monasca-agent

• https://github.com/monasca/monasca-docker/tree/master/monasca-api-python => https://github.com/openstack/monasca-api

• https://github.com/monasca/monasca-docker/tree/master/monasca-client => https://github.com/openstack/python-monascaclient

• https://github.com/monasca/monasca-docker/tree/master/monasca-log-api => https://github.com/openstack/monasca-log-api

• https://github.com/monasca-docker/monasca-notification => https://github.com/openstack/monasca-notification

• https://github.com/monasca/monasca-docker/tree/master/monasca-persister-python => https://github.com/openstack/monasca-persister

• https://github.com/monasca/monasca-docker/tree/master/monasca-python => https://github.com/openstack/monasca-common

• https://github.com/monasca/monasca-docker/tree/master/monasca-thresh => https://github.com/openstack/monasca-thresh

  • 还需要 https://github.com/monasca/monasca-docker/tree/master/storm => https://github.com/openstack/monasca-thresh

• https://github.com/monasca/monasca-docker/tree/master/tempest-tests => https://github.com/openstack/monasca-tempest-plugin

不在范围内

• https://github.com/monasca/monasca-docker/monasca-alarms - 此镜像包含一个容器，可用于创建 Monasca 通知和告警定义。

• https://github.com/monasca/monasca-docker/monasca-log-agent - Logstash 输出 monasca_log_api 插件。

• https://github.com/monasca/monasca-docker/monasca-log-metrics - 包含 Logstash 配置，用于根据日志的严重程度将日志转换为指标。

• https://github.com/monasca/monasca-docker/monasca-log-persister - 包含 Logstash 配置，用于将日志保存到 log-db（即 ElasticSearch）中。

• https://github.com/monasca/monasca-docker/monasca-log-transformer - 镜像包含 Logstash 配置，用于检测日志的严重程度。

测试

目前，https://github.com/monasca/monasca-docker 的 CI 在每次更改时运行两种类型的测试

• tempest-tests https://github.com/monasca/monasca-docker/tree/master/tempest-tests

• smoke-tests https://github.com/monasca/monasca-docker/tree/master/smoke-tests

  • https://github.com/monasca/smoke-test

两者目前都在 Monasca 堆栈的指标部分上运行。

测试应考虑测试的服务是否已启动并在构建和运行的 Docker 容器中行为正确。我们需要决定是否要在每次更改时在整个 Monasca 堆栈上运行所有测试，或者是否应该为每个单独的服务创建一些较小的测试。

文档影响

应在此处添加基本安装说明 [1] 并发布到 https://docs.openstack.org

[1] https://opendev.org/openstack/monasca-api/src/branch/master/doc/source/install

现在高级文档存储在：https://github.com/monasca/monasca-docker/tree/master/docs

单独的镜像也有 README.md 文件，其中包含较低级别的信息。

文档应包含有关如何配置和运行所有服务的所有必要信息。

参考资料

• https://github.com/monasca/monasca-docker

• http://eavesdrop.openstack.org/meetings/monasca/2018/monasca.2018-01-10-15.00.log.html

历史记录

可选部分，旨在每次更新规范时描述新的设计、API 或任何数据库模式更新。有助于让读者了解发生的事情。

修订版

发布名称	描述
Rocky	引入