|
作者 | Mathias Gug等，Lyft Level 5 软件工程师 译者 | Lucy 编纂 | 夕颜 出品 | AI科技大本营（ID:rgznai100）
挑战 在 Level 5 中，硬件团队会在内部运营本身的 AV 车队。由于现在 AV 成长仍处于早期阶段，因此车队必需提供两种大相径庭的用例。一个是运营团队执行诸如班车服务和数据采集等任务的不乱平台，另一个则是为不竭改良仓库的软件工程师的开发平台。这两组用户的要求彻底分歧：运营团队必要具备最少选项和高度可预测举动的一站式设备平台，而工程师必要最大的机动性，以便他们能够快速迭代。 作者从一个基于 Salt 的简略配置经管系统起头，该系统凭据必要车辆的用户类型配置车辆。操纵方式是首先复制该软件，在汽车中从新配置高机能计较机（HPC），并从源代码构建。同样，工程师能够凭据本身的必要提取分支，构建和从新配置 HPC。这种方式因为开发很早，汽车不会被频繁使用，在初期汽车数量不多的时候能正常工作，可使用汽车 HPC 来构建软件仓库。跟着 AV 车队扩展规模，软件仓库繁杂性增加，每当任务类型产生变革时，就会挥霍大量时间来从新配置和构建数十辆汽车。显然，该方式另有待晋升！ 磁盘互换与网络传输 在研发 Level 5 车辆初期，作者讨论了磁盘互换与网络毗连在删除记实传感器数据方面的优缺点。凭据每天每台车发送数据巨细作者选择了磁盘互换。选择该方式的原因有不少，包含高速以太网电缆和毗连器的机器刚性，以及无法包管车库中的高速网络端口。最重要的是，车辆的周转时间对车队的出产率至关重要。我们能够在任何处所在 30 秒内改换驱动器，但使用 50 Gbps 以太网毗连收受 4TB 的驱动器必要大约 10 分钟。别的，车库能够快速建造并移动到任何位置。由于磁盘能够邮寄，因此对高速网络其实不是一项硬性要求。 这就是作者采纳一种流程来互换数据驱动器进出汽车的原因。作者采纳雷同的方式在启动驱动器上摆设软件。 解决方案 简而言之，Flexo 构建了引导驱动器。这是一个硬件和软件解决方案，可使用完整的软件刻录数十个相同的硬盘，从 Linux 引导加载法式到每天构建的自动驾驶汽车软件的特定版本，并为任务类型设置配置信息。 在高条理上，Flexo 是一个尺度的 Ubuntu 18.04 服务器系统，使用以下方式构建：
Flexo 示意图 Flexo 摆设平台将 git 存储库中托管的源代码转换为能够在 AV 计较机上引导的磁盘映像。其能够分化为以下功能组件：
图像构建器 Flexo 的主要任务是构建和经管图像。图像只是完整可启动文件系统的tar压缩存档，然后使用图像刻录机来刻录启动驱动器。这些图像通常约为 100 多 GB，因为图像中包含高清（HD）地图。Lyft 已使用容器多年，因此选择 Docker 作为构建图像的自然选择东西。Docker 界说了一种成熟且机动的语言和东西链，用于构建容器图像。在用例中，作者只使用 Docker 作为构建映像的东西，而不运行 Docker。因此，作者必要手动安装引导加载法式（grub），内核及容器内的初始虚拟内存盘。 作者使用几种分歧的 Dockerfiles，具体取决于对图像的配置。下面是文中使用的 Dockerfiles 的大致内容：
现在，发布司理通常只要批准了新版本的出产用途，就会手动起头构建图像。作者正在寻找方式将这一进程尺度化。由于使用了容器技能，映像构建组件与其运行的主机分手。 车辆特有数据 图像构建彻底与车辆无关，因为从硬件角度来看，同代的所有车辆都是相同的，甚至在运行时也会处置代际差别。可是，作者必要保存一些车辆特有的数据，包含车辆的身份（以便跟踪记实的数据和日志），加密密钥和证书以及校准参数。由于 Flexo 建立的启动驱动器均可以安装到任何车辆中，因此添加了永远不会以 USB 记忆棒的形式从汽车中移除的当地存储。 图像刻录机 映像刻录机组件负责将可启动文件系统构建到多个硬盘驱动器上。该组件必要处置 20 多个硬盘驱动器，这些硬盘驱动器在系统打开时由操纵员插入和拔出。
每个硬盘驱动器由独一的 sync_all_image_to_disk @ sd * systemd 单位经管。鉴于能够随时添加和删除硬盘驱动器，作者哄骗 udev-- Linux 内核使用的通用设备经管器，支持 udev 而不是cron 功课，以便作者能够在插入磁盘后当即启动图像刻录进程。作者使用 udev 规则为每个硬盘驱动器启动系统功课： ENV{DEVTYPE}==”disk”, ENV{ID_PART_TABLE_UUID}==”00000000-*”, TAG+=”systemd”, ENV{SYSTEMD_WANTS}+=”sync_all_images_to_disk@$kernel.service” 该规则使用 $ kernel udev 替换 systemd 单位实例到硬盘设备路径。systemd 单位通过 ％i 标识符将设备路径传递给 sync_all_images_to_disk 剧本： ExecStart=/usr/local/bin/sync_all_images_to_disk /dev/%i 这意味着刻录进程与构建进程彻底分手，是在插入驱动器时启动的。作者为操纵员建立了一种精简的方法来果断什么时候筹备停当，这在下面的硬件部门中有所概述。看成者开发系统时，擦除了Flexo 系统自己的 O / S 驱动器，标识表记标帜 Flexo 应该使用的硬盘。每个 Flexo 驱动器都有一个以 00000000 开首的磁盘 GUID。udev 规则使用基于 ID_PART_TABLE_UUID 情况变量的附加过滤器，仅为标识表记标帜为 Flexo 驱动器的磁盘启动 sync_all_images_to_disk @功课： ENV{ID_PART_TABLE_UUID}==”00000000-*” 标识表记标帜驱动器也有助于解决操纵员的操纵毛病。但若毛病插入非 Flexo 驱动器，则不会笼盖该驱动器。 图像选择器和启动盘布局 每个 Flexo 硬盘驱动器都支持多个版本的完整软件仓库。作者使用 GRUB 作为操纵员的主要 UI，以便在任务起头时选择要引导的映像：
主 GRUB 配置维护硬盘驱动器的每个分区中可用的映像列表。每个映像都提供带有内核和初始虚拟内存盘配置的辅助 GRUB 引导加载法式。图像从主引导加载法式链式加载，尽量地分手每个图像。而且一个映像中的毛病配置不会影响硬盘驱动器的其他映像。
从上图中能够看出，每种分区类型都使用 UUID 前缀来指示它是什么类型的分区。作者还为文件系统添加了 UUID 前缀。值得注意的是，让 Flexo 的这部门不乱是很是耗时的。今天的图像刻录机流程不到 1000 行 BASH，可是每一行都必要做不少工作才气做到正确，因为这些初级东西的文档记实机能很差，相关论坛和博客也不多。 比方，Linux 支持动态安装文件系统，因为我们在每个驱动器上建立多达 12 个分区，而系统中最多有 24 个驱动器，而为了连结内核始终是最新的，会致使内核和系统级此外大量资源争用。作者不能不使用大量的读/写锁，并在最终变得不乱之前对 partprobe 进行显式挪用以更新内核的新分区视图。 避免漂移：overlayroot 作者在设计 Flexo 之前遇到的一个痛点是，每个启动盘的状态会跟着时间的推移而漂移，因为启动盘将留在车内并由接连的任务重用。而要完本钱文中的任务，必需要将之前的任务清除，以便之前的任务不会对下一个任务发生影响。为此，作者使用 overlayroot 包在现有图像的顶部提供可写层。硬盘驱动器上的笼盖分区用作在运行时存储图像更改的姑且位置。作者使用带有随秘密码的 crypt 后端来确保在从新启动时擦除及时系统期间所做的任何更改。对付所有操纵目标图像，GRUB 配置中的 overlayroot 设置已打开： overlayroot=”crypt:dev=/dev/disk/by-partuuid/55555555-<DISK_ID>-555555555555,mkfs=1,fstype=ext4,recurse=0" 此功能与操纵团队老是在任务之间从新启动计较机的指令相连系，大大削减了工程师花在支持运营团队上的时间。 用kvm测试图像 在开发 Flexo 系统时，作者很如意识到将硬盘从一个系统移动到另一个系统进行测试会致使迭代周期延长。作者起头哄骗 kvm 和 OVMF 来加快开发。OVMF提供雷同于汽车中的计较机的UEFI bios。此虚拟化测试情况还包含用于汽车标识的当地 USB 驱动器。通过雷同于以下的 kvm 命令启动给定硬盘驱动器的测试情况： kvm -m 4096 -bios OVMF.fd -drive format=raw,file=/dev/sdk -drive format=raw,file=”car_data.img” — vnc :59 作者能够测试从 BIOS 到 Flexo 系统自己的 AV 软件仓库（包含图形部门）的实际启动的完整启动次序。甚至能够包含车辆特定USB记忆棒的虚拟版本（上面的 car_data.img）。并不是所有项都能在 VM 中正确启动，但足以验证大大都系统设置。 硬件 由于每辆车至少必要一个启动盘（作者通常会保存多个启动盘，以便在一个启动盘在使历时没必要期待新的启动盘），每个 Flexo 系统都是尺度的机架势服务器，有 24 个驱动器托架，允许批量互换驱动器，并为每个寄存汽车的站点保存了几个系统。 I / O 吞吐量是最重要的指标。将整个工作集保留在 RAM 中对付高速刻录磁盘至关重要，因此作者为 Flexo 计较机提供尽量多的 RAM。由于 Flexo 系统的磁盘刻录部门是自运行的，作者使用 ledmon 来节制机箱 LED 以指示磁盘状态。插入磁盘后，LED 会变暗，然后在刻录进程中起头快速闪烁。最后，亮红灯暗示驱动器已筹备好被取出并移动到车辆上。 简化工作流程以缩短反馈循环 Lyft 所有的汽车和 AV 运营商现在都在使用 Flexo 摆设平台。由于可启动图像彻底可工作，任务启动时间大幅削减，开发人员也不再对 O / S 的状态存疑。不乱的情况使得其在妨碍排除进程中能够削减变革因素。 下一步 跟着车队的扩大，Flexo 摆设平台将摆设到多个系统。Lyft 正在斟酌将图像构建器组件移动到云端，以确保所有 Flexo 系统中的图像都相同。Lyft 还但愿扩大 Flexo，使其可以为特定开发人员构建映像，并在云中不竭测试映像。在加快开发循环并尽量快地向开发人员提供反馈方面，Flexo 摆设流程将阐扬关头作用。 原文链接： https://medium.com/lyftlevel5/flexo-a-car-deployment-platform-a8dafc79b4ca (*本文为 AI科技大本营翻译文章，转载请关联微信 1092722531) ◆ ◆ |
