Docker Hub announced that all non-paying organizations will see their data deleted on April 14th (see this article). Turns out they won't delete existing public images (all our images are public) but we won't be able to publish new ones.
This has two important consequences:
We won't be able to push to docker.io anymore and our images won't be hosted there anymore. That would be the result of not switching to a Paid Plan.
We won't be able to build any image depending on source ones hosted on docker.io which would also be affected by this change: ie. using Free Teams Plan.
Should we pay?
No. This would only sort the first issue, which is the easiest to address and is probably a good move anyway.
Also, we don't want to support Docker Hub and their aggressive behaviors (it's the the first rude move from their part).
What needs to be done for publication?
All our images must push to ghcr.io only.
READMEs must be updated to point to ghcr.io for links and examples.
READMEs must be updated to badges independent of docker.io
We need to communicate (social media?) that we migrated all our images to ghcr.io
We need to delete our organization accounts (kiwix, openzim) on docker.io.
While docker stated that public images won't be deleted, some people (π) proactively delete their images from docker.ioβ¦
We probably shouldn't worry about that affecting us but it's an opportunity to assess our dependencies.
We should thus Identify all source (it can be chained) images used in all our Dockerfile for their status:
Is an Official Docker Image? Those are safe.
Is from a paid account or a personal or OSS one? Safe for now but heck whether available on another registry. Maybe open a ticket.
Is from a Free Team Organization? Create a ticket to follow-up: find out migration strategy: to another registry? ghcr ? to a personnal docker.io account?
Should it be updated (too old)? Maybe open a ticket.
This is all in reaction to DockerHub's erratic behavior. We'll have all our images stored on GHCR but still depends a lot on docker.io to function⦠but it's still a major part of the Docker ecosystem and it's unlikely to go away suddenly.
Archiving is a concerned. @kelson42 mentioned on Slack that he is βnot convinced there is value in past Docker imagesβ. It means that we wont transfer any docker.io-only image to ghcr.io.
I'd like @kelson42 to use this opportunity to lay out a general Docker image policy for the versioned repos. If we believe past images are useless, then we should be responsible registry users and delete them.
We could integrate that into the docker-publish-action so it's effortless. It could be a combination of age and number of more recent versions for instance.
Docker Hub announced that all non-paying organizations will see their data deleted on April 14th (see this article). Turns out they won't delete existing public images (all our images are public) but we won't be able to publish new ones.
This has two important consequences:
and our images won't be hosted there anymore. That would be the result of not switching to a Paid Plan.Should we pay?
No. This would only sort the first issue, which is the easiest to address and is probably a good move anyway. Also, we don't want to support Docker Hub and their aggressive behaviors (it's the the first rude move from their part).
What needs to be done for publication?
ghcr.io
for links and examples.kiwix
,openzim
) on docker.io.Update docker workflow
Most of our repos uses our docker-publish-action.
uses: openzim/docker-publish-action@v10
. This now defaults toghcr.io
only. If update not wanted, setregistries: ghcr.io
DOCKERIO_*
lines incredentials
. Not mandatory but cleaner as not used anymore.Update badges
img.shields.io doesnt have ghcr.io badges (because it requires API autehnticated/quota requests) yet. In the mean time, we have two alternatives:
Images using
latest
onlyUse a static badge
Versioned images
Use (temporarily) an external service that will most likely not handle traffic at some point
What needs to be done for building?
While docker stated that public images won't be deleted, some people (π) proactively delete their images from docker.ioβ¦ We probably shouldn't worry about that affecting us but it's an opportunity to assess our dependencies.
We should thus Identify all source (it can be chained) images used in all our Dockerfile for their status:
base-httpd
alpine:3
(DOI)captive-portal
alpine:3.16
(DOI)dashboard
caddy:2.6.1-alpine
(DOI)edupi
python:3.8.14-slim-bullseye
(DOI)file-browser
caddy:2.6.1-alpine
(DOI)hwclock
alpine:3.16
(DOI)kiwix-serve
debian:bullseye-slim alpine:3
(DOI)reverse-proxy
caddy:2.6.1-alpine
(DOI)wikifundi
debian:bullseye-slim
(DOI)manager
tiangolo/uwsgi-nginx:python3.8
(CU)scheduler
tiangolo/uwsgi-nginx:python3.8
(CU)worker
rgaudin/python-ubuntu:3.8-18.04
(CU)ubuntu:18.04
(DOI)mcr.microsoft.com/windows/servercore:ltsc2019
python:3.8-slim-buster
(DOI)nginx:1.21.3
(DOI)ghcr.io/offspot/mediawiki:1.36.1
emscripten/emsdk:2.0.25
(CO)alpine:3.16
ubuntu:bionic
fedora:35
ubuntu:focal
ghcr.io/kiwix/kiwix-build_ci_*
ghcr.io/kiwix/kiwix-build_ci_*
debian:bullseye-slim
(DOI)ghcr.io/kiwix/kiwix-build_ci_*
alpine:3.16
(DOI)https://github.com/kiwix/kiwix-tools/pull/608nginx:latest
(DOI)https://github.com/kiwix/kiwix-js-windows/issues/384debian:buster-slim
dropbox
debian:11-slim
(DOI)mirrorbrain
httpd:2.4.43
(DOI)matomo
matomo:4.13.3-fpm
(DOI)matomo-log-analytics
debian:bullseye-slim
(DOI)openzim/surfer
node:16-bullseye
(DOI)bittorrent-tracker
debian:buster-slim
(DOI)netdata
ghcr.io/netdata/netdata:v1.38
netdata/netdata:v1.35
)docker.io/alpine:3
docker.io/mongo:4.2.9
docker.io/mariadb:10.4
docker.io/nginx:1.21
docker.io/postgres:10.4
docker.io/postgres:11
docker.io/mysql:8-debian
docker.io/bitnami/minideb
docker.io/bitnami/nginx:1.21
docker.io/bash:5-alpine3.15
docker.io/varnish:7.1-alpine
(DOI) β οΈdocker.io/gimoh/pureftpd:latest
(CU)docker.io/vimagick/rsyncd:latest
(CU) βdocker.io/kiwix/watcherbot:latest
alpine:3
(DOI)https://github.com/openzim/zim-tools/pull/337emscripten/emsdk:3.1.12
(CO)mysql:5.7
mysql:8.0.30
redis
node:lts-alpine
nginx:stable-alpine
python:3.9
mariadb:10.1
(DOI) β οΈjwilder/nginx-proxy
jrcs/letsencrypt-nginx-proxy-companion
(CU) βghcr.io/kiwix/borg-backup:latest
https://github.com/openzim/wp1/pull/594python:3.8-buster
alpine:edge
python:3.10-alpine
node:14-alpine
library/nginx:mainline-alpine
β οΈrgaudin/uwsgi-nginx:python3.8
(CU) βghcr.io/netdata/netdata:v1.38
(CO)redis
redis:7
(DOI) βghcr.io/openzim/node-redis:18-7
https://github.com/openzim/mwoffliner/pull/1812https://github.com/openzim/mwoffliner/issues/1813node:18
(DOI)python:3.11-bullseye
(DOI)python:3.11-bullseye
(DOI)python:3.8
(DOI)webrecorder/browsertrix-crawler:0.8.1
(CO)node:14-alpine
library/nginx:mainline-alpine
(DOI) β οΈtiangolo/uvicorn-gunicorn:python3.10-slim
(CU)redis:6.2.4-buster
python:3.8-slim
python:3.8
python:3.8
(DOI)python:3.8-slim
(DOI)python:3.8
(DOI)python:3.8-slim
(DOI)python:3.8
(DOI)ubuntu:20.04
(DOI)node:14-alpine
(DOI) β οΈtiangolo/uwsgi-nginx:python3.8
(CU)What's Next?
This is all in reaction to DockerHub's erratic behavior. We'll have all our images stored on GHCR but still depends a lot on docker.io to function⦠but it's still a major part of the Docker ecosystem and it's unlikely to go away suddenly.
Archiving is a concerned. @kelson42 mentioned on Slack that he is βnot convinced there is value in past Docker imagesβ. It means that we wont transfer any docker.io-only image to ghcr.io.
I'd like @kelson42 to use this opportunity to lay out a general Docker image policy for the versioned repos. If we believe past images are useless, then we should be responsible registry users and delete them.
We could integrate that into the docker-publish-action so it's effortless. It could be a combination of age and number of more recent versions for instance.