Add registry v2 to Bay nodes
Add the registry v2 to each node of a Bay to allow OpenStack cloud operators to reduce or eliminate the dependency on the Docker public image registry in order to produce working containers in Magnum.
Discussion on Vancouver design summit: https:/
Blueprint information
- Status:
- Not started
- Approver:
- Steven Dake
- Priority:
- Undefined
- Drafter:
- Steven Dake
- Direction:
- Approved
- Assignee:
- Hua Wang
- Definition:
- Approved
- Series goal:
- None
- Implementation:
-
Deferred
- Milestone target:
- None
- Started by
- Completed by
Related branches
Related bugs
Sprints
Whiteboard
Our plan is to include Docker Distribution [1] (registry v2) on each Bay node that uses Docker:
The Swift backend for Docker [2] should be used so the storage features of the cloud are leveraged without creating a storage hotspot on the Bay's master node. Once this code has been merged, we can proceed with this feature. This approach allows each node to access registry on localhost, removing the need to secure this service using tls / ssl.
[1] https:/
[2] https:/
--
In addition to the above, we should check to verify that Docker Distribution can be configured to use the Docker Public Registry as an upstream resource and create local cached copies of the upstream images in its local (swift) image storage. Note that some cloud operators will want this capability turned on, and others will want it turned off, and use a batch process to fetch, test, and import upstream images only after they have been tested to meet acceptance criteria (security, license, etc.).
(hongbin) The swift backend pull request is unlikely to be merged and released at l1, so I push the target to l2.
Gerrit topic: https:/
Addressed by: https:/
Add registry to api and db
Addressed by: https:/
Add registry to template
(devkulkarni): I was wondering how would one push custom docker images to the docker registry on each node of a bay? Or, that is not necessary as the custom image can be stored in swift and Docker Distribution magic will make it appear in the docker registry on each node?
(adrian_otto): Devdatta, the Distribution (registryv2) service does not hold any local state. It persists everything to the backing store (swift). This means that anywhere you run the service on a common backing store, you have access to the same data. It relies on the backing store's features for scale-out of the data storage tier. So, if you are running one on every bay node on the same port, then your registry address can always be on the same localhost:port throughout the bay. In fact, the Distribution service should bind to 127.0.0.1, rather than *. This will narrow the attack surface, and simplify the protection of it.
Addressed by: https:/
Add registry_address to db and api
Addressed by: https:/
Add registry_trust_id to bay
Addressed by: https:/
Create trust_id for bay
Addressed by: https:/
Hide user credentials
Addressed by: https:/
Add docker registry support in template definition
Addressed by: https:/
Enable swift services
Addressed by: https:/
Configure docker registry in devstack
Addressed by: https:/
Add docs for docker registry
Addressed by: https:/
Add support for docker registry
Addressed by: https:/
Config docker registry in devstack
Addressed by: https:/
wip
Addressed by: https:/
Add docker registry support for swarm
Addressed by: https:/
Heat params are different in swarm master and swarm node
