-
Notifications
You must be signed in to change notification settings - Fork 85
Use Harbor ourselves #237
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Use Harbor ourselves #237
Conversation
I like the idea, but there probably need to be mitigating measures taken to ensure that if this Harbor instance goes down, that it can come back up right - if it's referencing itself as source of images, there are potential issues. We're in the process of doing something similar at the moment, we're going to use our internal Harbor to store all our platform images, but we're going build in an automatic failover mechanism to pull from (in our case) ACR in the case where Harbor is down. Maybe something to include here in some way/shape/form? |
Yeah it makes sense to replicate to other registries eg. docker hub, or ghcr in case the outage takes to longer to recover. |
The current registry is available in https://registry.goharbor.io, you can already use it to pull Harbor images. We currently replicate images from Docker Hub. |
* 'main' of github.com:goharbor/community: Enhance audit log add proposal for support redisTLS enhancement: extend the p2p preheat policy modify the update permission for robot resolve comments resolve comments resolve comments update the example of db resolve the comments update per comments add proposal for robot permission expansion Update MAINTAINERS.md (goharbor#247) Cleaning up a bit Use the sbom_report instead of scan_report to store the sbom scan overview information (goharbor#241)
* our-own-registry: update change requests. init # Conflicts: # proposals/use-our-own-registry.md
Co-authored-by: Thomas Coudert <[email protected]> Signed-off-by: Vadim Bauer <[email protected]>
Co-authored-by: Thomas Coudert <[email protected]> Signed-off-by: Vadim Bauer <[email protected]>
Our nightly e2e UI and the github merge action based on registry.goharbor.io, in last month, we see lot of fail because of the registry.goharbor.io, it blocks our code merge sometimes. We have spent lots of effort on retry and diagnostics. |
- Since all images from Docker Hub are already in Harbor. | ||
- Replace image references in Documentation | ||
- Replace Image references in Compose | ||
- Replace image references in Helm |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We aim to use this instance as the single source of truth for serving our release images, meaning all network traffic will be redirected from Docker Hub to this instance. The main concern is whether we can provide and ensure the same level of stability as Docker Hub, as well as allocate dedicated resources to monitor and maintain this instance.
Could we set a criterion where, if we don't encounter continuous failures while pulling images in the Harbor CI for three months, we can then consider switching the online package traffic to this instance and eventually to Harbor Helm?
Use of our Harbor registry to distribute our own container images. We should be the first to adopt our own technology. If we are not willing to utilize our own application for day-to-date use, don't expect others to do so.