Some experiences of registry V2

recently, due to the image warehouse of the PAAs platform in charge of the company, some problems have been summarized in the process of registry V2 doing some research and the image warehouse of PAAs platform developed based on it. First of all, the original image warehouse deployment and build process. Simplest warehouse Build: 1, Docker pull Docker.io/registry 2, Docker run-d-P 5000:5000--restart=always--name Registry Docker.io/registr Y

The above is the simplest warehouse building, but for the actual production environment there are many deficiencies, such as sustainable storage, access control and so on.

Below is a description of sustainable storage:

That is to say, through the Docker bring the volume path in the container to the host function, through the-v parameter to achieve, Registry v2 default storage path is/var/lib/registry, can directly docker run-e xxxx=/var/lib/ Registry This setting, the general word is configured through the configuration file of the native mirror repository.

The image above is about Registry V2 storage related partial configuration, delete configuration means whether to support the deletion of image files, filesystem (Auth server open Source project of course you can choose other storage, I choose the file system storage), RootDirectory is the path of the store, Manitenance is whether the repository is set to read-only, that is, the image cannot be uploaded.

Besides, the more important thing is permission control.

Registry authorization can be selected in three ways silly, token, htpasswd, silly I did not do some rehearsal this time, but token and htpasswd my side of the two ways to say, HTPASSWD is a set of user name password files generated by the HTPASSWD tool provided by Apache, the password is encrypted through the encryption algorithm, in fact, is the N group user name password recorded in a file, through this to do a simple user name control. But not to achieve the purpose of production, the following is mainly about the authority of token control.

First understand the Auth authentication mechanism mentioned in the diagram below, and then we look at the configuration file related configuration items for registry:

Issuer: The publisher must be consistent with the issuer of Auth server.

Realm:auth Server's address

Rootcertbundle: Self-signed certificate path

Service: Any string to use when getting token

The rest of the configuration is the HTTP configuration, addr is the address of registry, TLS is the secure transport protocol, certificate is a self-signed certificate, key is the private key we generate the certificate.

Above is the entire registry that is needed for the present.

Next auth server, in fact, Auth server is the open source project. Https://github.com/cesanta/docker_auth

Specifically, it's configuration,

Where token settings are issuer and registry issuer are consistent, users are the information of the user. Next is the most important permission control

The account is the user name, the service is the service configuration item defined by the Mirror warehouse, type is repository and registry, which is determined by the scope required to registry the V2 interface as requested. Name is the name of the operation. Actions are actions that are performed. Where/.+/is the meaning of the login user, "" is the meaning of the anonymous user.