Docker与Perforce Helix Core如何协作

Docker与Perforce Helix Core如何协作文本

来源:Perforce     作者:Robert Cowham     发布时间:2021-09-07 09:50

DevOps正在接管世界,Docker也是如此。本文将详细说明什么是Docker,并分享Docker如何与Perforce Helix Core一起工作。

Docker是什么?

Docker允许您使用容器来创建、部署和运行应用程序。

容器的基本目标是将应用程序及其相关依赖文件打包,包括:

  • 代码
  • 运行
  • 系统库
  • 它需要的任何其他东西

生成的包或容器可以轻松地在不同的环境(如开发、测试、QA、预生产和生产)之间不加修改地运送。

Docker的构建块,如Linux容器和相关技术,如控制组和内核名称空间,已经存在了相当长的时间。但Docker找到了一个有效的关键点,将上述技术以一种更容易使用的方式结合在一起,并且发挥出大于各部分之和作用。

Docker的有趣事实

以下是Docker概述中的一些亮点:

  • 容器具有与虚拟机类似的资源隔离和分配优势。但它们有不同的架构方法,使它们更加便携高效。
  • Docker用户在他们的环境中部署Docker后,交付的软件平均增加了7倍。
  • Docker容器在几秒钟内启动和关闭,这使得它可以随时轻松扩展应用服务,以满足客户的高峰需求。然后,您可以轻松地关闭这些容器,从而只在需要时使用所需的资源。

Docker带来了许多优势。但是在实施时,当然有一些复杂的东西需要理解——特别是对于生产系统。

为什么将Docker与Perforce Helix Core一起使用?

我们已经在Perforce的各种内部项目中成功地使用了Docker容器。一些客户提到了一个长期目标,即“Dockerizing”他们所有的应用程序,可能包括Helix Core Server(和/或复制实例)。所以,我决定调查Docker可能会如何发挥影响。

关于我的发现,以下是一些摘要。继续阅读完整的细节。

  • 在读取/写入底层 db.* 元数据文件(来自与主机共享的目录)时,p4d 在 Docker 容器内的基本性能与容器外非常相似。
  • 当使用基本的Docker网络转发(从容器外部到容器内部的p4d)时,性能可能会显著下降,大约下降2倍,这是由于Docker-proxy进程(并非意外)的原因。然而,一个意想不到的结果是,使用“–net=host”(使用主机系统网络堆)运行Docker容器并没有显著提高性能。
Docker如何与Perforce Helix Core工作

以下主要介绍Docker如何与Perforce Helix Core工作。

1.看看Docker架构

Docker图像是文件系统的静态快照,基于一系列层。每个都有一个唯一的散列(hash)。图像是版本化的,可以被标记(例如Ubuntu:14.04或Ubuntu:latest)。Docker容器是一个正在运行的映像实例。Docker使用AUFS(另一个统一文件系统),每个图像层都是只读的。当容器运行时,将创建一个可写的最顶层文件系统层。

让我们看看容器的历史,它向我们展示了层和它们的大小:

				
					~/benchmark$ docker history p4benchmark
IMAGE CREATED CREATED BY SIZE

bc29eb7387e8 44 hours ago /bin/sh -c #(nop) CMD ["/run_in_docker.sh"] 0 B

fd307858e6ed 44 hours ago /bin/sh -c #(nop) EXPOSE 1777/tcp 0 B

f0e6d83e59e3 46 hours ago /bin/sh -c #(nop) COPY file:1b62b51286d922508 151 B

7b93c7db720b 4 days ago /bin/sh -c #(nop) COPY file:dbaafa84747899a13 114 B

3dfae18d29da 4 days ago /bin/sh -c apt-get update;apt-get instal 65.29 MB

3a1326cf000a 4 days ago /bin/sh -c #(nop) ENV DEBIAN_FRONTEND=noninte 0 B

db005dd7ab5d 12 days ago /bin/sh -c #(nop) MAINTAINER Robert Cowham "r 0 B

b72889fa879c 13 days ago /bin/sh -c #(nop) CMD ["/bin/bash"] 187 MB

:
				
			

大多数层都非常小,尽管有一个层是65 MB(当使用apt-get安装多个包时),基础层是187mb。注意,最后一层(底部)的散列指的是基本的Ubuntu映像,正如我们可以通过下面的命令看到的。

				
					~/benchmark$ docker history ubuntu:14.04
IMAGE CREATED CREATED BY SIZE

b72889fa879c 13 days ago /bin/sh -c #(nop) CMD ["/bin/bash"] 187 MB

:
				
			

这种分层使得在图像(以及容器)之间共享公共层变得很容易,这减少了数据复制,并使基于相同图像的多个容器能更快启动。

2.运行Docker容器并持久化数据

容器通常使用“docker run”命令运行(示例在下文的详细部分中讨论)。然后可以通过“docker ps”查看。

				
					~/benchmark$ docker run -v /home/rcowham/benchmark/p4:/p4 p4benchmark /run_in_docker.sh

~/benchmark$ docker ps

CONTAINER ID        IMAGE         COMMAND               STATUS

51a70c423936        p4benchmark   "/run_in_docker.sh"   Up 2 minutes
				
			

容器实际上是作为主机系统上Docker守护程序(服务器)的子进程运行,这通常使其启动非常快。正常情况下,当您运行容器时,最上面的文件系统层是可写的。但是当容器完成时,任何更改都会被丢弃。这意味着运行任何进程(如数据库)——您希望将写入的数据持久化的进程——都需要以不同的方式处理。

最简单的方法是在容器中的主机系统上挂载一个目录。在上面的“docker run”示例中,我们使用-v标志在容器中以/p4的形式挂载主机目录。

3.设置Docker网络选项

默认情况下,Docker服务器守护进程通过网桥将主机网络连接到容器内的网络。这使得主机端口能轻松转发到容器内的端口。例如,在“docker run”命令中输入“-p 2345:1666”,表示2345主机端口连接到容器内部的1666端口。正如在下面的基准测试中所指出的,这很简单,但有性能成本。

4.获取Helix服务器基准测试

首先,找出你的服务器配置(存储/RAM/操作系统)与性能最佳的Perforce Helix Core配置相比如何。我们的性能实验室设计了一套基准测试,来衡量关键Perforce操作的性能。

出于本文的目的,我使用了两种基准:

  • Branchsubmit:测量文件提交到Perforce Helix Core服务器的速率。
  • Browse:提供一种方法,用于评估Perforce Helix Core服务器的CPU性能和网络利用率,以进行大量小客户端操作(fstat和filelog)。

我稍微定制了它们,以使基准测试更容易在单台机器上运行(特别是浏览默认为在多台机器上运行,多个客户端机器针对单个服务器工作)。你可以下载我的设置,包括脚本,Dockerfiles和环境。

The README.html(.Md是源代码)描述了细节。KB文章还列出了您需要从FTP站点下载的数据集(注意,检查点的大小是1.4GB,生成的数据库需要40GB空闲磁盘才能运行!)

5.分行提交基准测试结果

这个基准测试需要很少的定制,因为它被配置为在服务器机器上运行。我在Linux X86_64上使用16.1 p4d,内存为64 GB。正如基准文档中提到的,运行一次“setup”命令,然后运行两到三次“runme”命令以确保使用了文件系统缓存是值得的。

Native
Docker
Difference
submitCommitTime
2,140
2,176
102%
submitCommitRate
32,712
32,188
98%

文件系统缓存预热后,原生p4d的提交率非常可观,在每秒近33,000个文件的范围内。此结果会将服务器配置放在已发布基准测试结果的第一页!最后,当在Docker内部运行时,误差在几个百分点之内。因此,从容器内部访问主机文件系统的开销不大。

6.浏览基准测试结果

这更有趣,并且花费了更多的配置工作。基本脚本需要多个主机和一个编译过的测试客户端,来生成大量针对p4d的小命令。我修改了脚本,以便在同一台机器上运行客户机和服务器,因为在我的环境中更简单。我不得不调整一个Linux设置,因为测试很快就产生了这么多TCP连接,耗尽了机器上的标准设置——sysctl net.ipv4改变得如此之快。Ip_local_port_range从默认范围“32768 61000”更改为“15000 61000”。

Native
Docker
Different to Native
Docker net=host
Difference to native
totalSeconds
54
135
249%
122
225%
maxFstatSecond
6,660
3,220
48%
3,305
50%
maxFilelogSecond
608
292
48%
302
50%

因此,我们可以看到显著的性能损失(中间列)。使用“top”可以很容易看出docker-proxy进程在测试期间使用了大约50%的CPU (p4d在10-20%范围内),很明显,从主机端口转发到容器内的p4d端口是原因。最后两列显示了我们配置Docker使用主机网络堆栈的相同测试(在“Docker run”命令中使用参数”——net=host “)。

您应该将 Docker与Perforce Helix Core 一起使用吗?

使用Docker容器有很多好处。

用于开发和部署

Docker给开发和部署过程带来巨大的好处。当然,它可能被夸大了。合理的评估、测试和改进是很重要的。如果你查看Docker背后的资源(和相关技术),比如Google with Kubernetes,Amazon Web Services支持,以及微软最近的声明,你会发现这显然是一种受欢迎的趋势。

与Perforce Helix Core一起

Docker对于创建Perforce Helix Core测试环境的好处是显而易见的。

我们正在迁移各种测试和演示场景来使用Docker。以前需要多个虚拟机的工作现在只需通过多个容器来完成。主要的好处是:

  • 启动时间由分变为秒。
  • 在一台主机上运行多个虚拟机的资源开销显著降低。

现在开始使用Perforce Helix Core

今天就开始使用Perforce Helix Core -并测试一下自己的Docker容器。您可以免费使用多达5个用户和20个工作区。

alvpp njc9v

Robert Cowham,首席顾问, Perforce

Robert是Perforce的首席顾问。他长期专注于配置管理和改进跨企业的软件开发实践。他是DevOps专家,也是英国计算机学会变更、配置和发布管理专家小组委员会(前主席)成员。在业余时间,他经营日本合气道武术道。