sealer是阿里巴巴開源的一款集羣鏡像技術實現。可以把整個集羣打成像docker鏡像一樣的鏡像包，安裝生態任何軟件都可以sealer run xxx搞定，保障整個集羣緯度的交付一致性。是專有云和離線交付利器，當然普通開發者可以用它來快速實踐雲原生生態軟件，比如你要安裝k8s 或者prometheus或者高可用的mysql都可以做到一鍵搞定。
與helm的區別是，helm只編排不打包，這很多helm國內環境下載鏡像就是個問題，而sealer不存在這個問題，所有依賴都會被打包，而且整個集羣整體打包。
| 用sealer安裝一個k8s集羣
sealer run kuberetes:v1.19.9 \
--master 192.168.0.2,192.168.0.3,192.168.0.4 \
--node 192.168.0.5,192.168.0.6 -p 123456
```
對比sealos有沒有發現命令行更簡約更乾淨，多一分則嫌多，少一分則嫌少？優雅的像藝術品。
kuberentes:v1.19.9我們稱之爲集羣鏡像，它很神奇，和Docker鏡像類似本質是一坨安裝整個集羣所需要的所有文件的集合，在sealos裏面可能就是個tar包，而sealer裏面做了分層和兼容docker registry的設計，意味着我們可以把這個集羣鏡像放到docker registry裏面進行交付。
對接公有云更簡單，安裝時只需要指定機器數量
export ACCESSKEYID=xxx # 指定AK SK export ACCESSKEYSECRET=xxx
運行3master 3node
sealer run kuberetes:v1.19.9 -m 3 -n 3
想定義更多參數？ 定義Clusterfile即可：
apiVersion: sealer.aliyun.com/v1alpha1 kind: Cluster metadata: name: my-cluster spec: image: registry.cn-qingdao.aliyuncs.com/sealer-io/kubernetes:v1.19.9 provider: ALI_CLOUD masters: cpu: 4 memory: 4 count: 3 systemDisk: 100 dataDisks: - 100 nodes: cpu: 4 memory: 4 count: 3 systemDisk: 100 dataDisks: - 100
apiVersion: sealer.aliyun.com/v1alpha1 kind: Config metadata: name: calico spec: path: etc/calico-values.yaml data: | # in use NIC name interface: eth0 # Network plug-in name cniName: calico podCIDR: 100.64.0.0/10 svcCIDR: 10.96.0.0/22 withoutCNI: false
# | 一個安裝工具而已嘛，有什麼了不起？
安裝只是sealer的一個部分，sealer是一個《集羣鏡像》的實現，也就是如何通過一定的技術手段把整個集羣打包！這一點上相比sealos是一個質的提升。
sealer賦予了用戶Build的能力，用非常簡單的方式讓用戶進行自定義集羣鏡像:
我們想定義一個包含mysql ELK redis wordpress的集羣，並把所有的依賴打包在一起，sealer就可以通過極簡單方式幫助你做到這一點：
> 1. 定義Kubefile
FROM kuberentes:v1.19.9 # 集羣鏡像基礎鏡像，sealer官方提供 COPY mysql . # mysql 編排文件 COPY ELK . COPY redis . COPY wordpress . CMD kubectl apply -f . # 集羣啓動後執行的命令
> 2. Build自定義鏡像
`sealer build -t mysql-redis-elk:latest .`
然後需要部署一個新集羣只需要
`sealer run mysql-redis-elk:latest --master 192.168.0.2 -p 123456`
這個集羣run完就包含了mysql redis等
你還可以把集羣鏡像推送到私有鏡像倉庫中：
sealer login hub.docker.io -u xxx -p xxx sealer push mysql-redis-elk:latest 還可以pull下來save成tar到客戶環境中load:
sealer pull mysql-redis-elk:latest sealer save -o mysql-redis-elk.tar mysql-redis-elk:latest sealer load -i mysql-redis-elk.tar # 客戶離線環境
**| 從此以後**
大部分雲原生生態軟件落地：
sealer run rook:latest sealer run prometheus:latest sealer run ingress:latest sealer run istio:latest
...
一切變得如此簡單...
| sealer設計思想
sealer設計是極其優秀的，其實把整個集羣製作成鏡像並非一件簡單的事，sealer的牛掰之處就在於把複雜的事通過優雅的設計讓其足夠大道至簡，這也是幾乎我所有產品的特點，犧牲複雜度換取的功能寧可不要。
> kubefile設計
這是核心亮點，它以一個非常簡單的用戶接口讓用戶實現自定義集羣鏡像的能力。
用怎樣的一種描述語言可以用來描述整個集羣所需要的文件，並且還要簡單？在sealer誕生之前這其實是個複雜的問題，受Dockerfile啓發，爲何不把單機容器鏡像上升到集羣緯度？
於是便有了Kubefile。
docker可以通過Dockerfile構建一個docker鏡像，使用compose就可以運行容器。
sealer通過Kubefile構建一個CloudImage,使用Clusterfile啓動整個集羣。
這是個非常亮眼的想法和設計。那Kubefile中應該包含哪些指令？
`FROM kubernetes:v1.19.9`
FROM指定基礎鏡像，它可以是一個很乾淨的k8s基礎鏡像，也可以一個用戶已經打包了一些服務的自定義鏡像，對於使用者來說不需要關心裏面的細節，就像用docker時不用關心centos rootfs裏面有哪些文件一樣。
COPY my-chart . RUN wget helm.sh/download/helm-v3 && mv helm-v3 /usr/bin/helm
COPY指令可以像Docker一樣把build工作目錄的文件拷貝到集羣鏡像中。
RUN指令會在Build的時候執行，執行的過程中產生的文件都會緩存到集羣鏡像的一個layer中，比如上面在集羣鏡像中打包helm二進制
`CMD helm install app my-chart`
CMD指令在k8s集羣拉起後執行，它可以有多個。
這樣在Build的過程中sealer會拉起一個臨時的k8s集羣，然後在裏面執行Kubefile定義的指令，最終把這些指令產生的所有文件打包。
> 容器鏡像緩存設計
緩存容器鏡像可不是件輕鬆的事，這其中有一些難點問題:
如何知道分佈式軟件中有哪些容器鏡像，因爲我們需要把這些鏡像緩存下來，不管是掃描用戶的yaml文件還是用helm template之後掃描都是不完美的，首先不能確定用戶的編排方式是什麼，其次有些軟件甚至不把鏡像地址寫在編排文件中，而是通過自己的程序去拉起。無法保證build成功運行就一定沒問題。
容器鏡像是需要被存儲到私有倉庫中打包在集羣鏡像裏，那容器鏡像倉庫地址勢必和編排文件中寫的不一樣，特別是怎麼保證用戶alwayPull的時候還是能夠在私有倉庫中下載到鏡像。
這裏就體現sealer build的過程起一個臨時k8s集羣的優勢了，最終集羣會讓docker去pull鏡像，我們在pull的過程中攔截鏡像並緩存，透明的支持了容器鏡像存儲
如此做到了你Build的產物一致性會非常好，到了其它環境部署幾乎無需更改。
> 配置文件管理
很多交付場景會有大量的業務配置文件要向外透出，sealer可以非常友好的讓用戶透出這些配置到Clusterfile中。典型的情況是用戶希望集羣鏡像裏面的helm values能夠在部署時修改。
用戶只需要在Clusterfile中定義一個Config即可：
apiVersion: sealer.aliyun.com/v1alpha1 kind: Config metadata: name: mysql-values.yaml spec: path: etc/mysql-chart/values.yaml data: | mysql-user: root mysql-passwd: xxx
data中的內容就會覆蓋掉默認的mysql chart的values
> 插件機制
還有一些場景比如希望通過sealer去修改主機名，或者升級內核，或者同步時間這些“本不該”由sealer去做的事情，那麼我們可以啓用插件的方式來完成，以修改主機名插件爲例：
apiVersion: sealer.aliyun.com/v1alpha1 kind: Plugin metadata: name: HOSTNAME spec: data: | 192.168.0.2 master-0 192.168.0.3 master-1 192.168.0.4 master-2 192.168.0.5 node-0 192.168.0.6 node-1 192.168.0.7 node-2
只需要定義上面插件就可以幫助用戶把集羣中節點的主機名修改中data中定義的名字
當然還有一些其它的插件如打標籤插件，執行shell命令插件等.
> 不同runtime支持
未來你可以FROM k3s FROM k0s FROM ACK等等，而完全不用關心他們之間的安裝差異。
> 對接公有云
現在很多用戶都希望在雲端運行自己的集羣鏡像，sealer自帶對接公有云能力，sealer自己實現的基礎設施管理器，得益於我們更精細的退避重試機制，30s即可完成基礎設施構建(阿里雲6節點)性能是同類工具中的佼佼者，且API調用次數大大降低，配置兼容Clusterfile。
| 何種場景適合使用sealer
如果你要整體交付你的分佈式SaaS，請用sealer
如果你要集成多個分佈式服務在一起，如數據庫消息隊列或者微服務運行時，請用sealer
如果你要安裝一個分佈式應用如mysql主備集羣，請用sealer
如果你需要安裝/管理一個kubernetes高可用集羣，請用sealer
如果你要初始化多個數據中心，保持多個數據中心狀態強一致，請用sealer
如果你需要在公有云上實現上述場景，請用sealer
| 心得
sealer最值得我們自豪的地方是把複雜的東西變簡單了，將近使用了一年的時間去思考User Interface，怎麼在用戶視角看不損失功能還能簡單，這非常難，Kubefile的設計草稿被推翻了不知道多少次，千錘百煉最終打造出sealer這個項目。
還想說一下sealer和sealos的淵源，其實sealos是我很早開源的一個很受歡迎的項目，一步一步迭代，真的把安裝k8s集羣這件事做到了接近完美。然而有很多理由讓我必須要做一個大的改變了：
sealos背後其實有一整套自動化構建離線包能力的平臺，但是這些東西非常專用，基本是給我們自己發佈新的離線包使用的而一般的開發者根本沒有辦法複用到這些能力，如何“優雅的開放這些能力”一直是我思考的。sealer完美的給出了答案！
可能用過sealos的知道sealos有個install命令，可以安裝其它app如prometheus ingress dashboard這些，然而這塊的設計我一直不滿，但是又找不到更優雅的設計，只能說sealos的app包是沒有技術含量的，首先鏡像靠load，這樣yaml裏面always pull就涼了，其次打包麻煩，需要用戶自己save鏡像再tar，簡直太low，而sealer一個Kubefile完全解決，這得益於底層鏡像緩存技術的創新。
sealos不會產生一個生態，很簡單我們做東西給開發者使用，是一個一對多的關係，而sealer的出現，任何人都可以成爲生產者和消費者，生態的崛起纔有可能。
sealos的代碼現在看來簡直就是一坨SHIT(自我批評一下)，很早的時候我只重視User interface而不重視用戶看不到的地方，想着一個安裝工具而已，隨手寫寫，只要命令好用誰管你裏面是什麼樣，PR只要迴歸測試沒問題我也基本都全合併，現在證明這樣是大錯特錯！這種心態會讓你失去對自己作品的愛最終只能滅亡或者重構，好在sealer算是涅槃重生了。
我在怎麼把事情變簡單的道路上一直有着很多的探索和很多非常棒的想法，並且最終把它變爲現實，sealos就是個例子，然而那隻能是個業餘興趣項目，而sealer不一樣，融入了更多的思考，以及整個社區的共同努力。當初大家還以爲集羣鏡像只是個空洞的概念，而今天大家都可以切實體驗到它變成了現實!
[kubernetes一鍵安裝](https://sealyun.com)