search

truenas / charts

TrueNAS SCALE Apps Catalogs & Charts
BSD 3-Clause "New" or "Revised" License
311 stars 297 forks source link

Phase out docker.io for ghcr.io #2595

Closed Apprisco closed 2 months ago

Apprisco commented 5 months ago

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 commented 5 months ago

Hello, Not all containers exist in ghcr. But there is also the other side of the issue https://github.com/truenas/charts/issues/1112

Apprisco commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 3 months ago

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 commented 2 months ago

Closing this in favor of https://github.com/truenas/charts/issues/1112

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