Skip to content
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

Switch from Dockerhub to public VMware Harbor registry (projects.registry.vmware.com) #1555

Closed
1 of 2 tasks
antoninbas opened this issue Nov 13, 2020 · 3 comments
Closed
1 of 2 tasks
Assignees
Labels
area/build-release Issues or PRs related to building and releasing kind/design Categorizes issue or PR as related to design. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release.

Comments

@antoninbas
Copy link
Contributor

antoninbas commented Nov 13, 2020

Describe what you are trying to solve
Docker recently introduced rate limiting for pull requests on DockerHub (https://docs.docker.com/docker-hub/download-rate-limit/), and the rate limiting is only supposed to get more stringent in the future. To avoid rate limiting, users can upgrade to a paid account.

Because Antrea is supported by VMware, we have access to a public Harbor registry hosted by VMware. Images cannot be pushed to the registry from outside of the VMware corporate network. However, the registry supports a Dockerhub mirroring functionality, which we have already enabled for the antrea Docker organization. So we continue pushing images to Dockerhub and they will be available in Harbor after ~15 minutes.

This means that all the antrea images from Dockerhub (antrea/*) can be pulled from the Harbor registry instead (projects.registry.vmware.com/antrea/*).

However, all our manifests / scripts / source code still use the default Docker registry (Dockerhub). This means that developers & users will keep running into rate limiting issues, unless for each image, they 1) pull the image manually from Harbor and 2) re-tag the pulled image so that it matches the name we expect. This is essentially what we started doing for CI jobs (#1521).

Describe the solution you have in mind
We should update all our manifests / scripts / source code to use projects.registry.vmware.com to avoid rate limiting altogether.

  • Move to projects.registry.vmware.com for user-facing image pulls (update manifests) - v0.12.0
  • Move everything to projects.registry.vmware.com if needed (for devs and CI)

Describe how your solution impacts user flows
May be a bit surprising to users at first to see that we do not use the default Docker registry. But the Harbor registry is public so from a user experience perspective there should be no difference at all. There is a small delay (15 minutes) before new tags are actually available in Harbor (periodic sync with Dockerhub) but it should also not be an issue for users.

Alternative solutions that you considered
Paid account for the antrea organization on Dockerhub, but I believe it would only help for organization members. It would not remove rate limiting restrictions for Antrea users:

Rate limits for Docker image pulls are based on the account type of the user requesting the image - not the account type of the image’s owner.

Test plan
N/A

@antoninbas antoninbas added kind/design Categorizes issue or PR as related to design. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. area/build-release Issues or PRs related to building and releasing labels Nov 13, 2020
@antoninbas antoninbas added this to the Antrea v0.12.0 release milestone Nov 13, 2020
@antoninbas
Copy link
Contributor Author

Something to keep an eye on if we run into any issue / limitation with the VMware Harbor registry: https://aws.amazon.com/about-aws/whats-new/2020/12/announcing-amazon-ecr-public-and-amazon-ecr-public-gallery/

antoninbas added a commit to antoninbas/antrea that referenced this issue Dec 4, 2020
All "user-facing" images (antrea/antrea-ubuntu, antrea/antrea-windows,
antrea/octant-antrea-ubuntu) are now pulled from the VMware Harbor
distribution registry (projects.registry.vmware.com) to avoid Docker
pull rate limiting.

The YAML manifests (top-of-tree and releases) now refer to the new
registry.

This is not a complete transition from Dockerhub to Harbor. Images used
for build purposes (e.g. antrea/openvswitch) are still pulled from
Dockerhub by default. Rate limiting is not as much of an issue for these
(not user-facing, Github workflows are not subject to rate limiting, we
have workarounds for the Jenkins CI jobs). One thing to keep is mind is
that we cannot push to the VMware Harbor registry from outside of the
the VMware corporate network. This is why all images are pushed to
the Dockerhub registry, which is then mirrored by the distribution
Harbor registry.

See antrea-io#1555
antoninbas added a commit to antoninbas/antrea that referenced this issue Dec 8, 2020
All "user-facing" images (antrea/antrea-ubuntu, antrea/antrea-windows,
antrea/octant-antrea-ubuntu) are now pulled from the VMware Harbor
distribution registry (projects.registry.vmware.com) to avoid Docker
pull rate limiting.

The YAML manifests (top-of-tree and releases) now refer to the new
registry.

This is not a complete transition from Dockerhub to Harbor. Images used
for build purposes (e.g. antrea/openvswitch) are still pulled from
Dockerhub by default. Rate limiting is not as much of an issue for these
(not user-facing, Github workflows are not subject to rate limiting, we
have workarounds for the Jenkins CI jobs). One thing to keep is mind is
that we cannot push to the VMware Harbor registry from outside of the
the VMware corporate network. This is why all images are pushed to
the Dockerhub registry, which is then mirrored by the distribution
Harbor registry.

See antrea-io#1555
antoninbas added a commit to antoninbas/antrea that referenced this issue Dec 9, 2020
All "user-facing" images (antrea/antrea-ubuntu, antrea/antrea-windows,
antrea/octant-antrea-ubuntu) are now pulled from the VMware Harbor
distribution registry (projects.registry.vmware.com) to avoid Docker
pull rate limiting.

The YAML manifests (top-of-tree and releases) now refer to the new
registry.

This is not a complete transition from Dockerhub to Harbor. Images used
for build purposes (e.g. antrea/openvswitch) are still pulled from
Dockerhub by default. Rate limiting is not as much of an issue for these
(not user-facing, Github workflows are not subject to rate limiting, we
have workarounds for the Jenkins CI jobs). One thing to keep is mind is
that we cannot push to the VMware Harbor registry from outside of the
the VMware corporate network. This is why all images are pushed to
the Dockerhub registry, which is then mirrored by the distribution
Harbor registry.

See antrea-io#1555
antoninbas added a commit to antoninbas/antrea that referenced this issue Dec 9, 2020
All "user-facing" images (antrea/antrea-ubuntu, antrea/antrea-windows,
antrea/octant-antrea-ubuntu) are now pulled from the VMware Harbor
distribution registry (projects.registry.vmware.com) to avoid Docker
pull rate limiting.

The YAML manifests (top-of-tree and releases) now refer to the new
registry.

This is not a complete transition from Dockerhub to Harbor. Images used
for build purposes (e.g. antrea/openvswitch) are still pulled from
Dockerhub by default. Rate limiting is not as much of an issue for these
(not user-facing, Github workflows are not subject to rate limiting, we
have workarounds for the Jenkins CI jobs). One thing to keep is mind is
that we cannot push to the VMware Harbor registry from outside of the
the VMware corporate network. This is why all images are pushed to
the Dockerhub registry, which is then mirrored by the distribution
Harbor registry.

See antrea-io#1555
antoninbas added a commit to antoninbas/antrea that referenced this issue Dec 10, 2020
All "user-facing" images (antrea/antrea-ubuntu, antrea/antrea-windows,
antrea/octant-antrea-ubuntu) are now pulled from the VMware Harbor
distribution registry (projects.registry.vmware.com) to avoid Docker
pull rate limiting.

The YAML manifests (top-of-tree and releases) now refer to the new
registry.

This is not a complete transition from Dockerhub to Harbor. Images used
for build purposes (e.g. antrea/openvswitch) are still pulled from
Dockerhub by default. Rate limiting is not as much of an issue for these
(not user-facing, Github workflows are not subject to rate limiting, we
have workarounds for the Jenkins CI jobs). One thing to keep is mind is
that we cannot push to the VMware Harbor registry from outside of the
the VMware corporate network. This is why all images are pushed to
the Dockerhub registry, which is then mirrored by the distribution
Harbor registry.

See antrea-io#1555
antoninbas added a commit that referenced this issue Dec 11, 2020
* Switch to VMware Harbor registry for Antrea Docker images

All "user-facing" images (antrea/antrea-ubuntu, antrea/antrea-windows,
antrea/octant-antrea-ubuntu) are now pulled from the VMware Harbor
distribution registry (projects.registry.vmware.com) to avoid Docker
pull rate limiting.

The YAML manifests (top-of-tree and releases) now refer to the new
registry.

This is not a complete transition from Dockerhub to Harbor. Images used
for build purposes (e.g. antrea/openvswitch) are still pulled from
Dockerhub by default. Rate limiting is not as much of an issue for these
(not user-facing, Github workflows are not subject to rate limiting, we
have workarounds for the Jenkins CI jobs). One thing to keep is mind is
that we cannot push to the VMware Harbor registry from outside of the
the VMware corporate network. This is why all images are pushed to
the Dockerhub registry, which is then mirrored by the distribution
Harbor registry.

See #1555

* Changes for Jenkins scripts

* Fix issue in generate-manifest.sh when enabling ipsec and coverage
@antoninbas
Copy link
Contributor Author

All "user-facing" images (antrea/antrea-ubuntu, antrea/antrea-windows, antrea/octant-antrea-ubuntu) are now pulled from projects.registry.vmware.com, and the YAML manifests have been updated.

Keeping this issue open as we are still pulling images from Dockerhub as part of the build process, so devs may run into rate-limiting issues when building. Github Actions CI jobs are not affected at this stage.

@antoninbas antoninbas removed this from the Antrea v0.12.0 release milestone Dec 18, 2020
antoninbas added a commit that referenced this issue Dec 23, 2020
* Switch to VMware Harbor registry for Antrea Docker images

All "user-facing" images (antrea/antrea-ubuntu, antrea/antrea-windows,
antrea/octant-antrea-ubuntu) are now pulled from the VMware Harbor
distribution registry (projects.registry.vmware.com) to avoid Docker
pull rate limiting.

The YAML manifests (top-of-tree and releases) now refer to the new
registry.

This is not a complete transition from Dockerhub to Harbor. Images used
for build purposes (e.g. antrea/openvswitch) are still pulled from
Dockerhub by default. Rate limiting is not as much of an issue for these
(not user-facing, Github workflows are not subject to rate limiting, we
have workarounds for the Jenkins CI jobs). One thing to keep is mind is
that we cannot push to the VMware Harbor registry from outside of the
the VMware corporate network. This is why all images are pushed to
the Dockerhub registry, which is then mirrored by the distribution
Harbor registry.

See #1555

* Changes for Jenkins scripts

* Fix issue in generate-manifest.sh when enabling ipsec and coverage
@github-actions
Copy link
Contributor

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment, or this will be closed in 180 days

@github-actions github-actions bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jun 17, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/build-release Issues or PRs related to building and releasing kind/design Categorizes issue or PR as related to design. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release.
Projects
None yet
Development

No branches or pull requests

2 participants