对容器镜像的思考和讨论

前言

常言道，startup 有 startup 的好，大厂有大厂的好，那么大厂究竟好在哪呢？拿硅谷老牌大厂们 FLG 来说，如果要问最令人怀念的是什么？Free food 和基础设施(Infrastructure)一定是会上榜的，两者均极大提升了广大应用开发者的幸福指数。那么能不能“让天下没有难做的应用”呢？请大家把目光投向正在兴起的云原生生态。

在云原生生态中，容器服务包括了镜像和容器引擎两个部分。其中容器镜像作为核心的云原生应用制品，打包了完整的操作系统和应用运行环境，应用的迭代也因为使用了这种不可变架构而变得更简单，更频繁。

本文将围绕着容器镜像这一核心，分享它的相关知识和业界的思考与实践。

容器镜像的概念

1）容器镜像

容器镜像有一个官方的类比，"生活中常见的集装箱"，虽然拥有不同的规格，但箱子本身是不可变的（Immutable），只是其中装的内容不同。

对于镜像来说，不变的部分包含了运行一个应用软件（如 mysql）所需要的所有元素。开发者可以使用一些工具（如 Dockerfile）构建出自己的容器镜像，签名并上传到互联网上，然后需要运行这些软件的人可以通过指定名称（如 http://example.com/my-app）下载、验证和运行这些容器。

2）OCI 标准镜像规范

在 OCI 标准镜像规范出台之前，其实有两套广泛使用的镜像规范，分别是 appc 和 docker v2.2，但“合久必分，分久必合”，有意思的是两者的内容已经在各自的发展中逐步同化了，所以 OCI 组织顺水推舟地在 docker v2.2 的基础上推出了 oci image format spec，规定了对于符合规范的镜像，允许开发者只要对容器打包和签名一次，就可以在所有的容器引擎上运行该容器。

这份规范给出了 OCI image 的定义：

This specification defines an OCI Image, consisting of a manifest, 
an image index (optional), a set of filesystem layers, and a configuration.

3）容器的工作流程

一个典型的容器工作流程是从由 developers 制作容器镜像开始的（build），然后上传到镜像存储中心（ship），最后部署在集群中（run）。