Phase out docker.io for ghcr.io

[Apprisco]

Hi, as it is not possible to edit TrueNAS Community chart docker compose files in Scale, I was wondering if it'd be possible to simply replace all docker.io image references to ghcr.io.

Unfortunately, docker.io tends to fail quite often, especially if behind a VPN of any sort.
As the community chart does not allow adding a network bridge to simulate a new "host", it is impossible to put certain items behind VPN on the community chart without putting the whole server behind the VPN.

It'd be valuable to simply use ghcr.io instead, and all that'd be required is replacing every instance of "docker.io" to "ghcr.io" in the images list.

[stavros-k]

Hello,
Not all containers exist in ghcr.
But there is also the other side of the issue
#1112

[Apprisco]

Hello, I think 99.5% of docker containers do exist on ghcr, and it's the preferred platform for most.
However, i think this will be easily resolved if there's simply a way to change the images used.
Is there any way to edit the docker compose(if it exists) or simply the url for the image on the user end?

Additionally, docker.io has the EXACT same problem as ghcr.io for China so that is not a valid reason to not change.

[stavros-k]

There is currently no way to do that.

Exposing it, will introduce a whole other set of issues.
If a user enters a different tag and underlying code is not compatible with the helm chart / docker-compose (on next major release) it can either fail to deploy or even destroy data.

Also can make opened issues very hard to debug.

Even if we only allow the repo and not the tag to be changed, tags dont always match on both registries.

That being said. I do want to have a solution for that. eg: have a predefined mirror list on each app (where applicable).
But that needs a bit of extra work as CI also need to be adapted to account for those etc.
I can't give any ETA, but I think the priority should be to migrate existing apps with existing functionality to docker-compose (for next major release) and then add new functionality.

[Apprisco]

There is currently no way to do that.

Exposing it, will introduce a whole other set of issues. If a user enters a different tag and underlying code is not compatible with the helm chart / docker-compose (on next major release) it can either fail to deploy or even destroy data.

Also can make opened issues very hard to debug.

Even if we only allow the repo and not the tag to be changed, tags dont always match on both registries.

That being said. I do want to have a solution for that. eg: have a predefined mirror list on each app (where applicable). But that needs a bit of extra work as CI also need to be adapted to account for those etc. I can't give any ETA, but I think the priority should be to migrate existing apps with existing functionality to docker-compose (for next major release) and then add new functionality.

With the docker compose migration this should stop being an issue, as apps should have built in docker compose files which will let us choose the images, or am I wrong?

[stavros-k]

Pre-made apps will continue to function like they do now.

You will be able to use either custom-app or portainer, dockge etc to deploy you custom docker-compose files.

[Casuallynoted]

Constantly running into pull rate limit errors due to the use of docker hub for apps. Is there any way we can choose as users where it pulls the container from?

[stavros-k]

Closing this in favor of #1112

But with updated request:
"Support at least 2 registries when possible"