网站网页怎么压缩,长春专业做网站的公司有哪些,有些网址打不开怎么解决,山东省住房和城乡建设厅网站电话介绍 终于要结束了#xff01;这个大约一年前开始的这系列文章的最后一篇博文。 LXD 入门安装与配置你的第一个 LXD 容器资源控制镜像管理远程主机及容器迁移LXD 中的 DockerLXD 中的 LXD实时迁移LXD 和 JujuLXD 和 OpenStack调试#xff0c;及给 LXD 做贡献如果你从一开始就… 介绍 终于要结束了这个大约一年前开始的这系列文章的最后一篇博文。 LXD 入门安装与配置你的第一个 LXD 容器资源控制镜像管理远程主机及容器迁移LXD 中的 DockerLXD 中的 LXD实时迁移LXD 和 JujuLXD 和 OpenStack调试及给 LXD 做贡献如果你从一开始就关注了这个系列你应该已经使用了 LXD 相当长的时间了并且非常熟悉它的日常操作和功能。 但如果出现问题怎么办你可以做什么来自己跟踪问题如果你不能你应该记录什么信息以便上游可以跟踪问题 如果你想自己解决问题或通过实现你需要的功能来帮助改善LXD怎么办如何构建测试和贡献 LXD 代码库 调试 LXD 并填写 bug 报告 LXD 日志文件 /var/log/lxd/lxd.log 这是 LXD 日志的主文件。为了避免它快速充满你的磁盘默认只会记录 INFO、WARNING 或者 ERROR 级别的日志。你可以在 LXD 守护进程中使用 –debug 改变其行为。 /var/log/lxd/CONTAINER/lxc.conf 每当你启动容器时此文件将更新为传递给 LXC 的配置。 这里会展示容器将如何配置包括其所有的设备、绑定挂载等等。 /var/log/lxd/CONTAINER/forkexec.log 这个文件包含 LXC 命令执行失败时产生的错误。这个情况是非常罕见的因为 LXD 通常会在发生之前处理大多数错误。 /var/log/lxd/CONTAINER/forkstart.log 这个文件包含 LXC 在启动容器时的错误信息。含 LXC 命令执行失败时产生的错误。 CRIU 日志 (对于实时迁移) 如果使用 CRIU 进行容器实时迁移或实时快照则每次生成 CRIU 转储或恢复转储时都会记录额外的日志文件。 这些日志也可以在 /var/log/lxd/CONTAINER/ 中找到并且有时间戳以便你可以找到与你最近的操作所匹配的那些日志。它们包含 CRIU 转储和恢复的所有内容的详细记录并且比典型的迁移/快照错误消息更容器理解。 LXD 调试消息 如上所述你可以使用 -debug 选项将守护进程切换为执行调试日志记录。另一种方法是连接到守护进程的事件接口它将显示所有日志条目而不管配置的日志级别即使是远程工作。 举例说对于 lxc init ubuntu:16.04 xen 来说 lxd.log 会是这样 INFO[02-24|18:14:09] Starting container actionstart created2017-02-24T23:11:450000 ephemeralfalse namexen statefulfalse used1970-01-01T00:00:000000INFO[02-24|18:14:10] Started container actionstart created2017-02-24T23:11:450000 ephemeralfalse namexen statefulfalse used1970-01-01T00:00:000000而 lxc monitor –typelogging 会是 metadata: context: {} level: dbug message: New events listener: 9b725741-ffe7-4bfc-8d3e-fe620fc6e00atimestamp: 2017-02-24T18:14:01.025989062-05:00type: loggingmetadata: context: ip: method: GET url: /1.0 level: dbug message: handlingtimestamp: 2017-02-24T18:14:09.341283344-05:00type: loggingmetadata: context: driver: storage/zfs level: dbug message: StorageCoreInittimestamp: 2017-02-24T18:14:09.341536477-05:00type: loggingmetadata: context: ip: method: GET url: /1.0/containers/xen level: dbug message: handlingtimestamp: 2017-02-24T18:14:09.347709394-05:00type: loggingmetadata: context: ip: method: PUT url: /1.0/containers/xen/state level: dbug message: handlingtimestamp: 2017-02-24T18:14:09.357046302-05:00type: loggingmetadata: context: {} level: dbug message: New task operation: 2e2cf904-c4c4-4693-881f-57897d602ad3timestamp: 2017-02-24T18:14:09.358387853-05:00type: loggingmetadata: context: {} level: dbug message: Started task operation: 2e2cf904-c4c4-4693-881f-57897d602ad3timestamp: 2017-02-24T18:14:09.358578599-05:00type: loggingmetadata: context: ip: method: GET url: /1.0/operations/2e2cf904-c4c4-4693-881f-57897d602ad3/wait level: dbug message: handlingtimestamp: 2017-02-24T18:14:09.366213106-05:00type: loggingmetadata: context: driver: storage/zfs level: dbug message: StoragePoolInittimestamp: 2017-02-24T18:14:09.369636451-05:00type: loggingmetadata: context: driver: storage/zfs level: dbug message: StoragePoolChecktimestamp: 2017-02-24T18:14:09.369771164-05:00type: loggingmetadata: context: container: xen driver: storage/zfs level: dbug message: ContainerMounttimestamp: 2017-02-24T18:14:09.424696767-05:00type: loggingmetadata: context: driver: storage/zfs name: xen level: dbug message: ContainerUmounttimestamp: 2017-02-24T18:14:09.432723719-05:00type: loggingmetadata: context: container: xen driver: storage/zfs level: dbug message: ContainerMounttimestamp: 2017-02-24T18:14:09.721067917-05:00type: loggingmetadata: context: action: start created: 2017-02-24 23:11:45 0000 UTC ephemeral: false name: xen stateful: false used: 1970-01-01 00:00:00 0000 UTC level: info message: Starting containertimestamp: 2017-02-24T18:14:09.749808518-05:00type: loggingmetadata: context: ip: method: GET url: /1.0 level: dbug message: handlingtimestamp: 2017-02-24T18:14:09.792551375-05:00type: loggingmetadata: context: driver: storage/zfs level: dbug message: StorageCoreInittimestamp: 2017-02-24T18:14:09.792961032-05:00type: loggingmetadata: context: ip: method: GET url: /internal/containers/23/onstart level: dbug message: handlingtimestamp: 2017-02-24T18:14:09.800803501-05:00type: loggingmetadata: context: driver: storage/zfs level: dbug message: StoragePoolInittimestamp: 2017-02-24T18:14:09.803190248-05:00type: loggingmetadata: context: driver: storage/zfs level: dbug message: StoragePoolChecktimestamp: 2017-02-24T18:14:09.803251188-05:00type: loggingmetadata: context: container: xen driver: storage/zfs level: dbug message: ContainerMounttimestamp: 2017-02-24T18:14:09.803306055-05:00type: loggingmetadata: context: {} level: dbug message: Scheduler: container xen started: re-balancingtimestamp: 2017-02-24T18:14:09.965080432-05:00type: loggingmetadata: context: action: start created: 2017-02-24 23:11:45 0000 UTC ephemeral: false name: xen stateful: false used: 1970-01-01 00:00:00 0000 UTC level: info message: Started containertimestamp: 2017-02-24T18:14:10.162965059-05:00type: loggingmetadata: context: {} level: dbug message: Success for task operation: 2e2cf904-c4c4-4693-881f-57897d602ad3timestamp: 2017-02-24T18:14:10.163072893-05:00type: logginglxc monitor 的格式有点不同于每个条目都缩合成一行的日志文件但更重要的是你可以看到所有 leveldbug 条目。 如何报告 bug LXD 的 bug 最好报告 bug 的地方是 https://github.com/lxc/lxd/issues。确保完整填写了 bug 报告模板中的内容这些信息可以节省我们我们时间来复现环境。 Ubuntu 的 bug 如果你发现 Ubuntu 包本身有问题无法安装、升级或删除。或者遇到 LXD init 脚本的问题。报告此类错误的最好是在 Launchpad 上。 在 Ubuntu 系统上你可以使用ubuntu-bug lxd 它将自动包括一些日志文件和包信息供我们查看。 CRIU 的 bug 与 CRIU 相关的 Bug你可以通过 CRIU 的错误输出发现你应该在 Launchpad 上报告这些ubuntu-bug criu 请注意通过 LXD 使用 CRIU 属于测试版功能除非你愿意通过 Canonical 的支持合同付费支持要么可能需要一段时间才能查看你的错误报告。 贡献给 LXD LXD 用 Go 写成并托管在 Github。我们欢迎任外部的贡献。为 LXD 贡献不需要 CLA 或类似的法律协议签署只是通常的开发者所有权证书Signed-off-by: 行。 在我们的问题追踪器工具中我们列有许多潜在的功能需求新的贡献者可以以此作为良好的起点。通常最好在开始处理代码先发出 issue这样每个人都知道你正在做这项工作以便我们可以提供一些早期反馈。 从源码源码构建 LXD 这里有上游的维护说明https://github.com/lxc/lxd#building-from-source 你需要在 Github 上 fork 上游仓库然后将你的更改推送到你的分支。我们建议每天 rebase 上游的 LXD因为我们倾向于定期合并更改。 运行测试套件 LXD 维护了两套测试集单元测试和集成测试。你可以用下面的命令测试所有 sudo -E make check要只运行单元测试使用 sudo -E go test ./...要运行集成测试使用 cd testsudo -E ./main.sh后者支持相当多的环境变量来测试各种存储后端、禁用网络测试、使用 ramdisk 或只是调整日志输出。其中一些是 LXD_BACKENDbtrfs、dir、lvm 或 zfs” 之一默认为 dir 运行 LXD 存储驱动程序相关的所有测试。 LXD_CONCURRENTtrue 或 false默认为 false 这启用一些额外的并发测试。 LXD_DEBUGtrue 或 false默认为 false 记录所有 shell 命令并在调试模式下运行所有 LXD 命令。 LXD_INSPECTtrue 或 false默认为 false 测试程序会在故障时挂起以便你可以检查环境。 LXD_LOGS将所有 LXD 日志文件转储到的目录默认为 “” 所有生成的 LXD 守护进程的 logs 目录将被复制到此路径。 LXD_OFFLINEtrue 或 false默认为 false 禁用任何依赖于外部网络连接的测试。 LXD_TEST_IMAGE unified 格式的 LXD 镜像的路径默认为 “” 可以使用自定义测试镜像而不是默认的最小 busybox 镜像。 LXD_TMPFStrue 或 false默认为 false 在 tmpfs 安装中运行整个测试套件这会使用相当多的内存但会使测试速度明显更快。 LXD_VERBOSEtrue 或 false默认为 false 不太极端的 LXD_DEBUG 版本。shell 命令仍然会记录但 -debug 不会传递给 LXC 命令LXD 守护进程只能使用 -verbose 运行。测试程序将在实际运行之前提醒你任何缺失的依赖项。在相当快的机器上运行该测试可在 10 分钟内完成。 原文发布时间为2017-03-09 本文来自云栖社区合作伙伴“Linux中国”
