Blog post: Dependency Proxy to Core + a minor breaking change

Closes #9529 (closed)

This MR proposes a blog post to announce the move of the Dependency Proxy to Core and a minor breaking change for folks that are currently using the feature.

Move to Core

When determining if a feature should be Paid-only or included in Core, we ask ourselves who benefits from this feature. When considering the Dependency Proxy, it's clear that proxying and caching images from Docker Hub is common practice for all types of organizations and buyers. In fact, as we consider expanding this feature to allowing proxying and caching of packages from external repositories, such as npmjs.com or maven-central, this functionality should also be included in Core as these are common workflows for all individual contributors.

Minor breaking change

The impact of the breaking change should be minimal. Both in terms of surface area and remediation. 3275 groups have the dependency proxy enabled, but only 13 groups have any cached data in the dependency proxy, the largest having 103 blobs, which is estimated as about 10-30 images. So, this really only impacts a small audience.

To remediate the issue the owner of the pipeline using the proxy will have to log in to Docker first.

The other benefit of talking about this now is that Docker Hub is announcing changes to their rate-pulling policy and so this is a good chance for us to create some visibility for GitLab's Container Registry/Dependency Proxy features.

Checklist for writer

• Link to issue added, and set to close when this MR is merged
• Due date and milestone (e.g. Blogs October 2020) added for the desired publish date
• Please add links to three related blog posts, GitLab issues, documentation or other related content so the reader can learn more at the bottom of the post. (We will take care of the formatting.)
• If time sensitive
  • Added ~"priority" label
  • Mentioned @rebecca to give her a heads up ASAP
• Blog post file formatted correctly, including any accompanying images
• All relevant frontmatter included
• Review app checked for any formatting issues
• Reviewed by fellow team member
• If approval before publishing is required
  • Any required internal or external approval for this blog post has been granted (please leave a comment with details)
• Assign to the Editorial team member who reviewed your pitch issue for final review (If they are on PTO and your post is time sensitive, please share your MR in #content on Slack to ask for another reviewer.)

After the blog has been published:

• Share on your social media channels
  • Add ?utm_medium=social&utm_campaign=blog&utm_content=advocacy to the end of the blog URL when you share on social media, for data tracking. Your link should look like this:https://about.gitlab.com/blog/20xx/xx/xx/blog-title/?utm_medium=social&utm_campaign=blog&utm_content=advocacy
• After you've shared on your social media profiles, select one of the posts and link it in the #social_media_posts Slack channel for everyone to engage with your post. The GitLab social team may engage or even share your social media post to amplify the work.
• To learn more about how to use your own social media channels for GitLab, check out our team member social media guidelines here.