ghcr vs docker hub

[keighrim]

@mrharpo I wonder if there was a specific reason to use ghcr instead of docker hub in the app CD action.
Docker hub images are free and open by default, while ghcr images are not public by default.

[mrharpo]

@keighrim I defaulted to ghcr because it has a very nice integration with github actions, through the {{ secretes.GITHUB_TOKEN }}. This way, we don't have to maintain login secrets for docker hub.

The action can also be overridden with an environment variable to a different container registry at runtime.

  env:
    REGISTRY: docker.io

ghcr images are not public by default

I forgot about this step. I need Admin level access to change that. I don't have the Package settings button for this org.

Compared to our organization:

Can you make me an Owner of clamsproject? I'll take care of setting them all public.

[keighrim]

I'm not sure whether defaulting to ghcr is a good idea, as not all folks at Brandeis are CLI-fluent, hence having a little help from GUI (docker-desktop) and hub.docker.com web search interface won't be any harm for some.

I already set up a secret for docker hub a while ago, have been publishing base images (shipped with SDK and base system libraries) using it. I'd like to propose we stick to the docker hub for app images as well.

@marcverhagen what do you think?

[keighrim]

Well, here comes a new twist.

discussion threads

• https://news.ycombinator.com/item?id=35154025&ref=upstract.com
• https://forums.docker.com/t/docker-team-organization-sunsetting/135089
• Free team being sunset, no way to convert to a regular account docker/hub-feedback#2314

Given our "free team" on dockerhub is given to live only 2 months from now, I guess our two options now have more implications;

1. continue using dockerhub,
   1. and pay $9 (or more)/month OR
   2. retire clamsproject dockerhub org
   3. switch clamsbot user to clamsproject user
      ( not sure reusing a retired org name is actually possible )
   4. re-upload all old versions of clams-python base images to the new user account
   5. during this migration, pulling clams-python base images won't be possible
   6. this will ensure FROM clamsproject/clams-python:x.y.z line in other dockerfiles continues to work
   7. pray that docker as a company does not subset the free user account tier (possibly timed with their IPO) before our project concludes.
2. switch to ghcr and,
   1. have better integration with github repos, but worse integration with docker-desktop app (fine by me, they don't even support linux anyway)
   2. keep enjoying the free tier until MS change their mind (which, I believe, is extremely unlikely, given MS's BM based on OSS and wide adoption of github in the developer community)
   3. drop support for old dockfiles that have FROM clamsproject/clams-python:x.y.z lines (should then be FROM ghcr.io/clamsproject/clams-python:x.y.z)

For its sustainability and less workload, I vote for option 2, but option 1 should ensure backward compatibility (but there's a big IF - only works when reusing the retiring organization namespace is possible).

I may be wrong in some of those bullet points. Please correct me if so.

[keighrim]

@mrharpo I made you an owner, and enabled "public" packages in the org settings, but couldn't figure out how to push a new image with public visibility programmatically (I can manually set one public after it's pushed and available on the web interface). Any idea?

[mrharpo]

@keighrim I manually set the app-barsdetection package to visible, at the bottom of the package settings page.

The github docs say:

When you first publish a package, the default visibility is private.

But I assumed that's what the Inherit access option was for in the clamsproject Setting > Packages:

Maybe you enabled it, but because the package was created before the setting was enabled, it stayed private?

In any case, it's public now, and even if we have to do it once per app, I think that should be fine, as long as we remember to do it for new apps.

[mrharpo]

2. switch to ghcr

I agree. Docker has been removing (moving) functionality from fee tiers for a while, while MS has demonstrated a strong and growing commitment to FOSS recently.

I could even see keeping both, as long as docker hub is free or cheap, and we have an auto build workflow.

[keighrim]

I did some experiments and it seems that the inheritance of visibility only works when an image is built and pushed via an actions WF.

If I do something like this;

$ cat Dockerfile
FROM clamsproject/clams-python:0.5.2
LABEL org.opencontainers.image.source https://github.com/clamsproject/clams-python

$ dk build -t ghcr.io/clamsproject/clams-python-torch:0.5.2 .
Sending build context to Docker daemon  2.048kB
Step 1/2 : FROM clamsproject/clams-python:0.5.2
 ---> 26afd491908b
Step 2/2 : LABEL org.opencontainers.image.source https://github.com/clamsproject/clams-python
 ---> Using cache
 ---> 717c1388721b
Successfully built 717c1388721b
Successfully tagged ghcr.io/clamsproject/clams-python-torch:0.5.2

$ dk push ghcr.io/clamsproject/clams-python-torch:0.5.2
The push refers to repository [ghcr.io/clamsproject/clams-python-torch]
ca828d1b5ef3: Layer already exists
654c0165da3b: Layer already exists
e68fa10b1051: Layer already exists
ba4dc145b4ac: Layer already exists
01423d4e7de7: Layer already exists
801cd8c51d7a: Layer already exists
0.5.2: digest: sha256:4c74a6c9b8edc873d1ce97611b98e574f77eb3e214f7489f77361052c150cc93 size: 1582

$

The newly pushed image knows who's its daddy (which is a public repo), but is set to private by default.

But it should work for future images that are to be pushed via actions, and as you said, even if we need to do that manually once in a while, it shouldn't be a huge burden. Most of clams app repos will only have a single package to be published.

To conclude, I guess we will enjoy a big reduction in financial and technical cost as well as some piece of mind by moving to ghcr for future images. But we still need to decide what to do with legacy images (mostly just zero-versions of clams-python base images), and I still want to hear from @marcverhagen about that, so I'll keep this open for now.

[keighrim]

Old images on DH is now migrated to ghcr (clamsproject/clams-python#113). Future images (apps and SDK) will be pushed to ghcr by GHA workflow (clamsproject/clams-python#115).

Closing the issue as resolved.