Pine，基于 OSTree 的 Alpine linux
选择什么 操作系统 在您的服务器上运行是一个方便和熟悉的问题。方便意味着你想要一些给你带来尽可能少麻烦的东西，熟悉意味着你更喜欢 不是 如果您不需要，可以学习其他东西。
我的服务器是 宠物 所以我可以每隔一段时间手动发出一些命令，不需要完全自动化。
试用后 核心操作系统 一年我改用我自己的简化版 发行版 基于高山和 奥斯特里.
这个版本的 alpine 借鉴了 平车 和 项目原子 并且应该作为只读根文件系统安装，更新以原子方式发生，也就是说，要么成功，要么系统交换回以前的状态。为此，系统必须始终至少具有 两张快照 已发布的文件系统版本，可用于存储。
系统将在什么环境下运行？我有针对性 OVZ 和 [KVM]，但总的来说你可以说 集装箱 和 虚拟机 主要区别在于容器不运行自己的内核，特别是它们没有启动过程，它们直接调用 在里面 系统（例如在Dockerfile 它将由CMD 或者ENTRYPOINT 语句），它负责管理保持容器运行的进程树（就像普通会话一样，如果 init 进程终止，则容器终止）。容器也不能配置系统旋钮，并且可以对功能有额外的限制。
图像是如何构建的？
这prepare.sh 脚本处理依赖项，其中大部分是提供常用 cli 工具的包，如coreutils, util-linux, binutils ，与块设备一起操作的实用程序，例如blkid, sfdisk, multipath-tools 和文件系统xfsprogs 和e2fsprogs .这squashfs-tools 最后使用 package 来压缩构建的根文件系统。一种glib 兼容包也是默认安装的，因为alpine是基于musl ，兼容性包通过提供一些针对 .
虚拟机和容器的文件树分别使用make.sh 和make_ovz.sh .这是步骤的简化说明
根据存储库标签设置要构建的版本
为新树创建一个目录并清除环境
创建 ostree 所需的基本目标目录和目录，例如sysroot
创建符号链接以符合 文件系统层次标准
复制自定义服务和自定义配置
使用挂载的系统目录设置 chroot
使用基本包引导高山 rootfs
对 rootfs 应用最少的配置，如凭据、时区、主机名。
由 init 启动的复制服务
使用指定的内核映像设置启动配置
可选择添加自定义内核模块
进行清理
提交 rootfs[1] 到 ostree 存储库
对于容器，顺序是相同的，但配置会发生变化，因为系统不是从 引导程序 ostree 在验证环境时遇到麻烦，我们必须应用一些 变通方法 并设置一些通常由 initramfs 步。这是如何 OVZ 或者 LXC 模板已配置。
一旦我们有了 ostree 提交的文件树build.sh 或者build-update.sh 负责生产将要分发的工件。脚本之间的区别在于更新版本从以前的 ostree 存储库开始，并且 还 生成一个增量工件，运行系统可以将其应用于其 ostree 实例以执行升级。这是构建步骤的简化描述
如果新建
在作为循环设备安装的新映像上创建新分区
别的
挂载先前构建的 sysroot 和引导分区
在安装的构建上清理以前的 ostree 部署（链接农场）
在安装的构建上提交新构建的树
验证完整性和校验和
为升级创建新的增量
执行 ostree 部署以重新生成引导配置
删除旧的 ostree 提交
验证引导分区完整性
卸载新的更新构建映像
生成图像校验和并压缩它（使用squashfs 用于容器）
分区配置通过 fdisk 应用layout.cfg 定义分区大小的文件，我们有一个用于 rootfs 的分区（~430M ), 启动分区 (~40M ) 和一个交换分区 (~40M ）。对于容器，只需跳过将先前构建安装到循环设备上，然后将新的 ostree 提交拉到旧的（提取的）ostree 存储库上。
我在此映像中捆绑了什么（除了已安装的软件包）？
一个小库functions.sh 用于在 shell 中执行的常见任务
基于 ostree 的升级脚本，带有基于 KV 存储的锁定机制
本地 IO 监控脚本（iomon ) 和网络 (tcpmon)
容器运行时的安装脚本，而不是bubblewrap: podman, toolbox
过去是什么，现在不再是什么
sup: 超 用于编排（部署容器）和主机的配置，但后来我切换到 能听懂的 因为 sup 中存在长期存在的 bug 没有修复，所以我从一开始就没有选择 ansible，因为我不想在每台服务器上都安装 python 依赖项，最终我选择了一个二级 alpine chroot 在主机上，位于/opt/alp 我是否安装了其他不太重要的软件。然而，今天，我将再次从 ansible 切换到 pyinfra ， 因为
它是没有样板的python（ansible有伪DSL 这比它解决的问题更令人头疼）
它使用简单的 ssh 命令执行其配方，因此对目标主机没有 python 依赖性要求
containerpilot：容器试点的用例是在没有 shell 脚本的情况下管理容器之间的复杂依赖关系......它停止从 欢乐的 并处于维护模式，我也不喜欢内存要求，并且内存使用量会在长时间正常运行时不断增加。我将它切换为简单的 shell 脚本 领事 ，如果 shell 脚本开始增长太多，我可能会寻找更合适的替代方案。更重的解决方案，如 Kubernetes, 一群 或者 游牧民族 从一开始就被丢弃了。
beegfs ：我曾经发布必要的内核模块 比格夫 但过了一会儿，它破坏了兼容性，而且没有得到适当支持的事实 保险丝 模块完全删除它，我目前没有在我的服务器上运行 [DFS]，但是准备好文件系统以插入网络的可能性仍然很有吸引力。
要安装映像，您可以将其上传到托管服务提供商并从 VNC 安装，以防万一是虚拟机，但我通常会劫持现有安装，因为这总是可能的，只要我已经针对版本测试了安装脚本linux 发行版，通常我使用 debian-8 或 ubuntu-14，尚未测试其他发行版，因为我一直发现这些可用。设置步骤如下
确保 https 支持下载
下载一个busybox版本
安装一个busybox链接场
确定网络配置的 ipv4/ipv6 地址
确保 chroot 功能
下载松树图像并解压
如果虚拟机
闪过目标设备
安装在循环设备上
将本地网络配置写入 被闪现 根文件系统
如果容器
将 init 服务（用于容器）复制到主根挂载点/sbin/init
如果虚拟机
使用标准 (xfs ) 分区
卸载
验证分区完整性
重启
我做了 松树 5 years from time of writing and I am still using it, and I see no reasons to switch to anything else. Alpine as a linux distro is great, simple, and I have never experienced breakage. I can easily deploy on NATed 往往提供超低资源的服务器，实际上我有一个运行的盒子64M 内存，并且仍然拥有我需要的所有功能。
| [1] | 根文件系统 |
