Linux编译过程

Perfect Assistant 软件助手使用Docker 编译Linux项目,编译之后就可以部署到众多云服务中去。本文介绍了该编译过程,便于用户理解软件助手的能力和局限。

Docker 使用方法

如果没有Docker 支持,PA软件助手就仅仅能够调用SPM软件包管理器编译macOS本地应用。在Docer正确安装之后,软件助手就能够自动解析Ubuntu Apt组件依存关系并实现二进制可执行文件的编译,以达到部署到不同云服务器上的目标。

通过软件助手完成Docker安装后,Docker能够从其服务器上下载一个或者多个基础镜像,这些镜像剪裁了操作系统的不必要内容,只保留Ubuntu 16.04操作系统及兼容的Swift工具链用于项目编译。

这些基础镜像可以从此处获取:。编译目标所需要的对应编译器版本通常会有一些差异,但是都是在Ubuntu 16.04基础之上完成,因为该系统被标记为LTS,即获官方长期支持。

Docker 编译

当软件助手执行Linux编译或者调试时,首先会利用上述的Swift工具链镜像之一创建一个临时的Docker容器。该容器会把本地macOS工程文件夹一同加载到其`.build`编译临时文件目录,该目录对应的本地操作系统隐藏目录为`.build_lin`。这样所有的Linux编译结果都会放到这个文件夹里面去。

Linux Apt 组件依存关系

软件助手会首先在容器中进行`swift package fetch`操作,也就是下载本项目相关所有组件。操作完成后软件助手会扫描所有已下载组件包裹,并分析每个组件对服务器是否有特定的Ubuntu Apt应用函数库有依赖关系,这一步通过以下两种方式之一实现:

  • Package.swift "providers" 栏目
    • 该标准栏目用于说明操作系统层面上是否需要特定Apt(Linux)或 Homebrew(macOS)函数库。
  • PADockerfile 脚本
    • 尽管该脚本不属于Swift 及其SPM软件包管理器的标准内容,该脚本能够进一步简化Docker镜像Apt安装指令,用于在项目编译之前预装软件。比如,MySQL客户端需要一个特殊的.pc文件,并且在SPM编译之前要修改这个文件内容。
软件助手在取得项目的git资源库后首先扫描是否存在PADockerfile,如果有这个脚本就直接调用。如果不存在这个脚本,则软件助手会扫描Package.swift的providers变量,进行软件预装。

二者共同作用的结果是依存关系操作能够在编译之前实现完整的安装指令清单,用于部署时执行服务器安装初始化,比如部署到EC2 弹性计算。

项目本身的 PADockerfile 脚本

如果待编译的项目文件夹根目录下面就有一个PADockerfile脚本(这种情况并不常见),则该文件会被作为基础文件用于生成PADockerfile_build脚本和一个PADockerfile_deploy脚本。如果项目本身没有这个脚本,软件助手会自动生成一个临时文件PADockerfile脚本用于上述操作。其初衷只在于配合Docker基础镜像的编译过程。所有的具体安装操作都会自动追加到这个文件上用于其余所有操作,比如调试、发行和部署。

PADockerfile_deploy 和 PADockerfile_build 这两个脚本会保存在项目文件夹下用于后续运行测试和安装部署。如果存在这些文件则软件助手就会自动调用。

完成编译

全部依存关系下载完成后,软件助手会到基础镜像中调用Swift工具链,比如`perfectlysoft/perfectassistant:3.1`(具体标签会根据软件助手中选择有所不同)。所有项目都会根据其订制的镜像进行编译。该镜像会包含所有项目编译前的预装步骤,并根据工程名称自动为镜像其一个标准化名称。比如项目名称为“PerfectTemplate”,则针对该项目的Linux Docker新镜像就会自动设置为“perfectassistant/perfecttemplate”。当选择编译待部署镜像时,所有发行版本的二进制编译结果会被拷贝到目标部署镜像,然后该部署镜像名称会被设置为“perfectassistant/perfecttemplate:deploy”

源代码镜像和编译目标镜像会在您本地的Docker系统中维持上述名称注记。如果编译目标镜像已经存在,则软件助手会直接使用这个镜像用于容器类服务器的部署,比如谷歌云应用引擎。如果部署目标为基于虚拟机系统时,软件助手仍然会生成目标容器,但是会将编译生成的二进制文件拷贝到目标主机。软件助手会使用之前自动生成的预装软件清单脚本,在目标主机上执行全部安装操作,以确保目标服务器能够正常运行。

Next: Managing Deployments