Docker 自建仓库自行开发管理

xglys

　　Docker 自建仓库面临一个管理镜像的问题，这里写个简单的程序，当作抛砖引玉
　　

• 　　pom.xml需要引入的架包,由于jfinal里面有个封装好的http处理函数，方便简单，所以需要个jfinal包，json包用于解析返回的json结果
  

• 　　<dependency>
  
• 　　    <groupId>com.jfinal</groupId>
  
• 　　    <artifactId>jfinal</artifactId>
  
• 　　    <version>2.2</version>
  
• 　　    </dependency>
  
• 　　
  
• 　　
  
• 　　    <dependency>
  
• 　　    <groupId>com.hynnet</groupId>
  
• 　　    <artifactId>json-lib</artifactId>
  
• 　　    <version>2.4</version>
  
• 　　    </dependency>
  

　　

• 　　简单的代码内容
  

　　

• 　　import com.jfinal.kit.HttpKit;
  
• 　　
  
• 　　import net.sf.json.JSONArray;
  
• 　　import net.sf.json.JSONObject;
  
• 　　
  
• 　　public class Main {
  
• 　　
  
• 　　    // get url 没什么特别，模拟请求URL
  
• 　　public static String httget(String url) {
  
• 　　
  
• 　　String s = HttpKit.get(url);
  
• 　　
  
• 　　return s;
  
• 　　}
  
• 　　
  
• 　　
  
• 　　public static void main(String[] args) {
  
• 　　
  
  
• 　　// http://10.100.112.243:5000 是自建仓库的地址，现在基于V2版本
  
• 　　String baseUrl = "http://10.100.112.243:5000/v2/";
  
• 　　
  
• 　　String catalog = baseUrl + "_catalog";
  
• 　　      
  
• 　　
  
• 　　    // 查看所有镜像名称
  
• 　　      JSONObject obj = JSONObject.fromObject(httget(catalog));
  
• 　　
  
• 　　        // 根据返回的json串，转换成json数组，方便操作
  
• 　　 JSONArray obj_minions = obj.getJSONArray("repositories");
  
• 　　
  
• 　　        // 显示所有内容
  
• 　　for (int i = 0; i < obj_minions.size(); i++) {
  
• 　　
  
• 　　System.out.println( httget(baseUrl + "/" + obj_minions.get(i) + "/tags/list"));
  
• 　　
  
• 　　}
  
• 　　}
  
• 　　}
  

　　

• 　　执行结果
  

• 　　{"name":"apsops/filebeat-kubernetes","tags":["v0.2"]}
  
• 　　
  
• 　　{"name":"bobrik/curator","tags":["latest"]}
  
• 　　
  
• 　　{"name":"busybox","tags":["latest"]}
  

　　

　　

　　上面简单显示了如何调用查看自建仓库内容，也就是实现CURD里面的“C”查看。
　　其它的实现可以参考下面的接口进行开发，至于界面设计，其实用一个表格就可以实现，这里也不多说。
　　

　　

　　常用自建接口(参考1)

method	path	Entity	Description
GET	/v2/	Base	Check that the endpoint implements Docker Registry API V2.
GET	/v2/<name>/tags/list	Tags	Fetch the tags under the repository identified by name.
GET	/v2/<name>/manifests/<reference>	Manifest	Fetch the manifest identified by nameand referencewhere referencecan be a tag or digest. A HEADrequest can also be issued to this endpoint to obtain resource information without receiving all data.
PUT	/v2/<name>/manifests/<reference>	Manifest	Put the manifest identified by nameand referencewhere referencecan be a tag or digest.
DELETE	/v2/<name>/manifests/<reference>	Manifest	Delete the manifest identified by nameand reference. Note that a manifest can only be deleted by digest.
GET	/v2/<name>/blobs/<digest>	Blob	Retrieve the blob from the registry identified bydigest. A HEADrequest can also be issued to this endpoint to obtain resource information without receiving all data.
DELETE	/v2/<name>/blobs/<digest>	Blob	Delete the blob identified by nameand digest
POST	/v2/<name>/blobs/uploads/	Initiate Blob Upload	Initiate a resumable blob upload. If successful, an upload location will be provided to complete the upload. Optionally, if thedigest parameter is present, the request body will be used to complete the upload in a single request.
GET	/v2/<name>/blobs/uploads/<uuid>	Blob Upload	Retrieve status of upload identified byuuid. The primary purpose of this endpoint is to resolve the current status of a resumable upload.
PATCH	/v2/<name>/blobs/uploads/<uuid>	Blob Upload	Upload a chunk of data for the specified upload.
PUT	/v2/<name>/blobs/uploads/<uuid>	Blob Upload	Complete the upload specified by uuid, optionally appending the body as the final chunk.
DELETE	/v2/<name>/blobs/uploads/<uuid>	Blob Upload	Cancel outstanding upload processes, releasing associated resources. If this is not called, the unfinished uploads will eventually timeout.
GET	/v2/_catalog	Catalog	Retrieve a sorted, json list of repositories available in the registry.

　　参考1  http://blog.csdn.net/ztsinghua/article/details/51496658