Shelter是一個(gè)幫助用戶管理docker registry的產(chǎn)品，為了做這個(gè)東西，有必要分析比較現(xiàn)有一些類似產(chǎn)品的核心模型，借鑒其優(yōu)缺點(diǎn)
hub.docker.com
模型說(shuō)明
模型圖
補(bǔ)充說(shuō)明
- organization與namespace對(duì)應(yīng)，用戶每添加一個(gè)organization，實(shí)際上就創(chuàng)建了一個(gè)同名的namespace
- user和organization類似，每個(gè)用戶缺省會(huì)有一個(gè)同名的namespace
- 還有一個(gè)叫做team的概念，但是我一直沒(méi)弄明白它的用法，而且這個(gè)team只能添加不能刪除，很奇怪，所以這里就不寫了
分析討論
這個(gè)模型圖本身看起來(lái)似乎沒(méi)問(wèn)題，但是從用戶的角度看namespace會(huì)覺得很冗余，實(shí)際上，namespace在用戶界面上只是一個(gè)偶爾被提到的概念，系統(tǒng)本來(lái)是可以不讓用戶知道的。然而設(shè)計(jì)者顯然沒(méi)有太注意這一點(diǎn)，而一旦添加了它，用戶就需要理解namespace與organization和user的關(guān)系，結(jié)果大大增加了用戶（所能感知）的模型復(fù)雜度。
Harbor
模型說(shuō)明
模型圖
補(bǔ)充說(shuō)明
- project由用戶管理，它就是registry所看到的namespace，另外，用戶缺省是沒(méi)有project的
- 在harbor的文檔中，namespace下層的模型有時(shí)用repository，有時(shí)用image，懷疑harbor在這里有些地方?jīng)]想清楚
分析討論
harbor的模型是最簡(jiǎn)單的，但是project這個(gè)名字非常具有誤導(dǎo)性。
一般的理解中，project通常是在一個(gè)時(shí)間段內(nèi)進(jìn)行的計(jì)劃，一般是周或者月為單位，很少有跨年的，然而實(shí)際上模型中提供的是一個(gè)“公共namespace”機(jī)制，這是為了團(tuán)隊(duì)協(xié)作而產(chǎn)生的模型，其時(shí)效應(yīng)該和團(tuán)隊(duì)相當(dāng)，這里出現(xiàn)了模型的設(shè)計(jì)偏差。
在實(shí)踐中也確實(shí)遇到了這樣的問(wèn)題，有的團(tuán)隊(duì)直接將自己的產(chǎn)品切割為很多個(gè)project，然而這些project其實(shí)只是一個(gè)團(tuán)隊(duì)做的同一個(gè)東西的不同組成部分，只是工作中需要有所區(qū)分而已。
另外，由于harbor的設(shè)計(jì)，用戶在創(chuàng)建project時(shí)會(huì)認(rèn)為這是當(dāng)前用戶所控制的范圍，因此不會(huì)考慮和其他用戶的project是否存在同名沖突，但實(shí)際上project名稱需要保持全局唯一性，這給用戶帶來(lái)了不小的認(rèn)知負(fù)擔(dān)。
Portus
模型說(shuō)明
模型圖
補(bǔ)充說(shuō)明
- team用來(lái)管理一群人，例如統(tǒng)一為多個(gè)人設(shè)定權(quán)限等
- namespace就是docker registry地址里面的namespace
- docker registry的鏡像在這里被稱為repository
分析討論
Portus的模型是相對(duì)比較復(fù)雜而且有些僵化的，它在namespace之上添加了一個(gè)team的概念，使得用戶創(chuàng)建namespace之前必須要?jiǎng)?chuàng)建一個(gè)team，這給管理員增加了麻煩。
這么做還有一個(gè)副作用，普通用戶（非管理員）如果想管理自己臨時(shí)做的鏡像，需要添加一個(gè)namespace，并因此要先創(chuàng)建一個(gè)team，這個(gè)team實(shí)際上只有一個(gè)成員（就是用戶自己），這會(huì)大大增加用戶的心智成本，可能導(dǎo)致用戶不愿意或者不習(xí)慣使用自建鏡像做一些探索性工作。
github.com
模型說(shuō)明
模型圖
補(bǔ)充說(shuō)明
- repository是以u(píng)ser或者organization名字進(jìn)行分類組織的，但是github.com并沒(méi)有抽出一個(gè)namespace的概念，當(dāng)用戶要?jiǎng)?chuàng)建repository的時(shí)候，系統(tǒng)會(huì)提示他選擇owner，然后根據(jù)這個(gè)owner（可能是用戶自己，也可能是organization）決定namespace
- github.com也有team的概念，它是在organization之下用來(lái)管理user的，由于它和repository無(wú)關(guān)，而且它對(duì)于github.com不是必要的核心模型，因此就不列出來(lái)了
設(shè)計(jì)討論
github的模型相對(duì)比較簡(jiǎn)單，它對(duì)用戶可見的模型只有三個(gè)，而且無(wú)論是user還是organization都是用戶很容易理解的概念。對(duì)shelter來(lái)說(shuō)，只有一個(gè)地方可能需要討論，就是對(duì)于repository的命名。
github面對(duì)的是代碼倉(cāng)庫(kù)的管理，而shelter管理的是registry里面的鏡像，雖然我們期望它們一一對(duì)應(yīng)，但實(shí)際上它們是不同的模型，如果混為一談，可能對(duì)用戶的理解也是不利的，另外，如果需要對(duì)于image和repository在commit id上進(jìn)行映射，這可能也有問(wèn)題。
最終的結(jié)論
經(jīng)過(guò)上述的分析，目前比較認(rèn)可github.com的模型，下面是原因。
顯然，用戶對(duì)于user和organization的概念是天生就能理解的，因此最好的對(duì)策是將namespace“隱藏”在這兩個(gè)概念中，當(dāng)用戶創(chuàng)建organization或者user的時(shí)候，系統(tǒng)就產(chǎn)生了一個(gè)（且僅有一個(gè)）namespace與其對(duì)應(yīng)。
這個(gè)做法有沒(méi)有問(wèn)題呢？需要考慮兩個(gè)方面：
- 這種 user+organization 的結(jié)構(gòu)是否足以支持研發(fā)團(tuán)隊(duì)本身的組織架構(gòu)，或者說(shuō)，復(fù)雜的研發(fā)組織是否可以通過(guò)本模型進(jìn)行支持？
- 是否存在一個(gè)user（或者organization）需要多個(gè)namespace的情況？
對(duì)于問(wèn)題1，壞消息是——不能，更深的研發(fā)組織層級(jí)是不能用這種模式進(jìn)行完全支持的。
不過(guò)，還有一個(gè)好消息——其實(shí)，我們不必支持過(guò)于復(fù)雜的組織結(jié)構(gòu)。
軟件開發(fā)領(lǐng)域，多種管理風(fēng)格共存，我們的軟件不可能符合所有的管理風(fēng)格，所以我們只服務(wù)相同理念風(fēng)格的團(tuán)隊(duì)和組織，這個(gè)理念就是小團(tuán)隊(duì)和扁平化，我們認(rèn)為這是未來(lái)的趨勢(shì)，值得堅(jiān)持走下去，而在這個(gè)思路指導(dǎo)下，現(xiàn)有模型在組織復(fù)雜度上是完全夠用的。
那么，是否還可以再進(jìn)一步簡(jiǎn)化？比如將user和organization合并，把后者看作一種特殊的前者？實(shí)際上我一開始也有這個(gè)考慮，但是后來(lái)發(fā)現(xiàn)是不合理的，關(guān)鍵在于user要承擔(dān)一個(gè)身份識(shí)別的責(zé)任，簡(jiǎn)單說(shuō)，它是用戶用來(lái)登錄的東西，而group在任何時(shí)候都不會(huì)有一個(gè)“登錄”的行為，所以區(qū)分這兩者還是有必要的。
接下來(lái)說(shuō)問(wèn)題2，我們會(huì)發(fā)現(xiàn)，對(duì)于user/organization之下建立多個(gè)namespace的情形，本質(zhì)上是一種歸類需要，而歸類需求其實(shí)不需要這么僵硬的模型支持，namespace的重點(diǎn)應(yīng)該registry上表現(xiàn)為一個(gè)授權(quán)單元，用戶可以在這個(gè)粒度上進(jìn)行權(quán)限控制。
歸類需求是資源和信息管理的常見需要，不過(guò)現(xiàn)在很多管理方式都趨向于輕量級(jí)的思路。比如，簡(jiǎn)單場(chǎng)景下可以直接讓用戶自己約定前綴命名法，系統(tǒng)只要提供autocomplete search 就可以了；而如果是復(fù)雜場(chǎng)景，還可以用tag，都比僵化單一的分類目錄要更方便
對(duì)于小團(tuán)隊(duì)和扁平化管理來(lái)說(shuō)，授權(quán)的邊界就是organization的邊界（我們不需要在小團(tuán)隊(duì)內(nèi)部再建立權(quán)限區(qū)分，而是應(yīng)該鼓勵(lì)他們作為一個(gè)整體完成任務(wù)和承擔(dān)責(zé)任），所以namespace在本質(zhì)上就應(yīng)該和organization/user是一一對(duì)應(yīng)的。
這樣，在用戶的視角看來(lái)，沒(méi)有什么namespace，只有image按照管理者不同而進(jìn)行的歸類，有些屬于個(gè)人，有些屬于團(tuán)隊(duì)，如此而已。
最后再簡(jiǎn)單吐槽一下repository這個(gè)概念的命名，我認(rèn)為目前大家的概念在這里有點(diǎn)混亂，github.com上管理的確實(shí)就是repository，起這個(gè)名字很合理，但是portus等系統(tǒng)就顯得很奇怪了，它們管理的就是docker鏡像，顯然稱為image更為合理。詳細(xì)查看registry的api，發(fā)現(xiàn)這里也叫repository，文檔中是這么說(shuō)的：
Images are stored in collections, known as a repository
看來(lái)這個(gè)repository和代碼倉(cāng)庫(kù)無(wú)關(guān)，是指image的存放之處，不過(guò)我覺得這個(gè)api命名很不好，因?yàn)閞epository這種概念完全是內(nèi)部問(wèn)題，對(duì)外統(tǒng)一叫image才符合用戶理解，這樣可以讓鏡像管理系統(tǒng)相對(duì)“干凈”些，但是既然官方有這個(gè)命名，我們就先和它保持一致吧，最終模型就是github.com的圖
