mastouille.fr est l'un des nombreux serveurs Mastodon indépendants que vous pouvez utiliser pour participer au fédiverse.
Mastouille est une instance Mastodon durable, ouverte, et hébergée en France.

Administré par :

Statistiques du serveur :

620
comptes actifs

#Dockerhub

0 message0 participant0 message aujourd’hui

If you rely on Docker images (as in `docker.io/library/docker`) in CI or elsewhere:

it looks like the images pushed yesterday on hub.docker.com/_/docker have a problem (the content-type of the manifest seems to be application/json instead of something like application/vnd.oci.image.manifest.v1+json).

Temporary workaround until my former coworkers get to it: use 27.3 images (e.g. docker:27.3-dind for Docker-in-Docker).

hub.docker.com
A répondu dans un fil de discussion

@warthog9 @kwf Granted, I doubt anyone's gonna #mirror OS/1337 anytime soon and I do want some fallback to enshure that if #GitHub were to ever pull a #DockerHub, nothing would impact the end-users...

But that's more of a hypothetical as of now.

Still I do find this insightful and yes, if I had the €€€€€ upfront to get it started I would've lilely offered people #upcycled #ThinClients and #MiniPC's as cheap #Servers long ago - it's just that #Colocation amd Hardware ain's free...

I'll keep that conversation in mind.
After all, any #netboot #infrastructure would require me to setup classic #mirrors anyway...
github.com/OS-1337/netboot

GitHubGitHub - OS-1337/netboot: Network / Internet Boot Configurations needed to boot OS/1337 via Network and/or Internet using iPXENetwork / Internet Boot Configurations needed to boot OS/1337 via Network and/or Internet using iPXE - OS-1337/netboot
Suite du fil

Btw, any other recommendations for less standard packages in, for instance, #github or docker images in #dockerhub or #quayio would be appreciated. At least docker hub has a sort of tag for the images built by a verified or official source. Can that be a security assurance? Any sources are appreciated!

Anyone else having trouble pulling #docker images from #dockerhub right now?

$ docker pull debian:latest
Error response from daemon: Head "registry-1.docker.io/v2/librar": Get "auth.docker.io/token?scope=rep": EOF

$ curl registry-1.docker.io/v2/librar
{"errors":[{"code":"UNAUTHORIZED","message":"authentication required","detail":[{"Type":"repository","Class":"","Name":"library/debian","Action":"pull"}]}]}

I *really* hope this is just an error and not deliberate ...

A répondu dans un fil de discussion

@bookstack

It's OK with :
* The LinuxServerIO/Bookstack image from #DockerHub : ibit.ly/qpVq
* The database #MariaDB in an other container : shared with others webapps

I changed my DockerFile for my Docker Stack to include the Bookstack's container.

I changed the port 80 to 443, I adapted the variable : APP_URL for corresponding with my configuration.
My #Certeurope certificates are used by #Bookstack : OK.

Same the configuration SMTP "Brevo" : a SMTP in a SAAS, it's OK.

hub.docker.comDocker

Hello All,

With DockerHub removing its free tier and potential for future shenanigans, people are looking to move away from them for free and personal use.

To me, there seems to be a couple straight forward solutions:

* quay.io: open source but still centralized and ran by single for profit
* Gitlab.com registry: open source but still centralized and ran by single for profit
* GitHub.com registry: Same boat as DockerHub but larger corporation
* Running your own personal registry: Additional work for each party involved, low discovery options.

Now with the boring, straightforward solutions mentioned, and the bar set, I am going to suggest that we take this opportunity to push for a better long term solution.
Push for decentralized storage of OCI images and federated metadata support. The only urgency I see is that, because of the bone headiness of the latest Docker decision, frogs are actually jumping out of the pot, and I fear they might turn down the temp to a slower boil, or people might just jump into a slower cooker like github. Either way, the status quo looks to be a slow boiling away of the common infrastructure we are used today.

Here some decentralized options and strategies I've found so far:

## nerdctl ipfs support

[nerdctl](github.com/containerd/nerdctl/) supports IPFS for both image pulling and pushing, including encrypted images and eStargz lazy pulling. For building, the current method is a locally hosted translator so that the traditional pulls can be converted to work over IPFS. They even have docs on running it on k8s node, though if my reading is correct this isn't exactly a cloud native approach (running systemd services on each node...).

## IPDR: InterPlanetary Docker Registry

[IPDR](github.com/ipdr/ipdr) is a service to allow for images stored on IPFS to be accessible over Docker Registry HTTP API V2 Spec

## ociipfs OCI layer to IPFS content translation

[ociipfs](github.com/mkmik/ocipfs) this is tool to be able to translate to IPFS stored layers as the expected OCI layers and pulls found in the Docker build system.

## My thoughts
If you notice, the same thing I noticed in this list is that most of these are workarounds to support the web2 api on IPFS. There is a pull in draft for [BuildKit](github.com/moby/buildkit/pull/) that may make native IPFS image support better on the image build side. With the work on the nerdctl side being the most direct support for images for pushing and pulling images with IPFS hashes.

The last piece I hope you noticed is that none of these answer the discoverability question, and with none human friendly name spacing on the hashes do not serve well for code readability on either the ops or build side of the house. IPNS could serve to help the latter, but I think that something like an ActivityPub/Fediverse enabled site may better serve as a hosting point for images, allowing for multiple actors to better curate images, tags, Cosign, ipfs links, and other metadata for end users to select from.

Lastly, this is just some last minute research on my part and would love to hear more people's thoughts!

Edit 1 some points made in discussion:

Having a hard requirement on running a full IPFS daemon and node would be barriar to entry for a lot of people, and so if IPFS is used it should more ideally be used in a totally contained way.

[Gitea](nlnet.nl/project/Gitea/) and it's fork [Forgejo](forgejo.org/) both have federation via ForgePub in work and registry support, and thus maybe solid points targets for a federated/decentralized platform.

[Reddit post](reddit.com/r/ipfs/comments/11t)

GitHubnerdctl/ipfs.md at main · containerd/nerdctlcontaiNERD CTL - Docker-compatible CLI for containerd, with support for Compose, Rootless, eStargz, OCIcrypt, IPFS, ... - nerdctl/ipfs.md at main · containerd/nerdctl