Open rchincha opened 1 year ago
@dfr Noticed that the images you are pushing to dockerhub are docker images and not OCI. Is this intended? For example official ubuntu images are pushed as OCI images.
Not sure - I'm just building them using 'buildah mount' and 'buildah commit', using FreeBSD packaging tools to install things into the images.
How do I tell that they are docker images, not OCI? I don't see the difference when I compare one of my images with e.g. library/ubuntu using skopeo.
@dfr There are many tools. For example,
https://github.com/google/go-containerregistry/tree/main/cmd/crane
crane manifest <image> | jq .
$ crane manifest dougrabson/freebsd-minimal:13.2 | jq .
{
"schemaVersion": 2,
"mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
In comparison, ubuntu
$ crane manifest ubuntu:latest | jq .
{
"manifests": [
{
"digest": "sha256:c9cf959fd83770dfdefd8fb42cfef0761432af36a764c077aed54bbc5bb25368",
"mediaType": "application/vnd.oci.image.manifest.v1+json",
@dfr So you are pushing docker images to dockerhub. Not sure if this was intentional - from what I understand, FreeBSD is standardizing on OCI?
This is strange - I pushed the same image to both docker.io and quay.io but the manifest type on dockerhub is different.
$ crane manifest docker.io/dougrabson/freebsd13.2-static:13.2p2 | jq .
{
"schemaVersion": 2,
"mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
"manifests": [
{
"mediaType": "application/vnd.oci.image.manifest.v1+json",
"size": 1130,
"digest": "sha256:4378443a2023c8804997bca2f5e8c33944085e2102e192af0dcea943053b59bb",
"platform": {
"architecture": "amd64",
"os": "freebsd"
}
},
{
"mediaType": "application/vnd.oci.image.manifest.v1+json",
"size": 1132,
"digest": "sha256:cc62ec2301fdfab24d0e3976ff86ba16938ead54d638acdee1436d3ff5a3c1f9",
"platform": {
"architecture": "arm64",
"os": "freebsd"
}
}
]
}
$ crane manifest quay.io/dougrabson/freebsd13.2-static:13.2p2 | jq .
{
"schemaVersion": 2,
"mediaType": "application/vnd.oci.image.index.v1+json",
"manifests": [
{
"mediaType": "application/vnd.oci.image.manifest.v1+json",
"digest": "sha256:4378443a2023c8804997bca2f5e8c33944085e2102e192af0dcea943053b59bb",
"size": 1130,
"platform": {
"architecture": "amd64",
"os": "freebsd"
}
},
{
"mediaType": "application/vnd.oci.image.manifest.v1+json",
"digest": "sha256:cc62ec2301fdfab24d0e3976ff86ba16938ead54d638acdee1436d3ff5a3c1f9",
"size": 1132,
"platform": {
"architecture": "arm64",
"os": "freebsd"
}
}
]
}
@dfr
Ah I see. So you are pushing a multi-arch image index (which is docker media-type) but the individual image manifests in that image index are all OCI.
Perhaps your buildah
(if that is what you are using) version needs to be a more recent one. There are some known breakages with older versions.
https://github.com/containers/buildah/issues/4395
buildah push --all -f oci ...
The image manifests above were built with buildah-1.31.0 which is after the bug you linked was fixed, as far as I can tell. Thanks for the link though - next time I push things to dockerhub and quay.io, I'll use the most recent buildah release and see if that helps.
@dfr do you have an anticipated time frame for an official freebsd image release? Asking so we can coordinate our release window accordingly if possible.
I can't give a very clear answer but conservatively, Q1 2024 is quite possible. One of the main blocking factors should be resolved with the upcoming 14.0 FreeBSD release and I plan to work with the release engineers after that to integrate my image building scripts into their process.
@dfr FYI, 2.0.0-rc7 released.
https://github.com/project-zot/project-zot.github.io/blob/main/docs/general/whats-new.md ^ docs preview.
Is your feature request related to a problem? Please describe.
PR #1660 adds support for freebsd binaries. This issue is being filed so that we track the remaining step of releasing freebsd container images for zot once an official freebsd-minimal image is available.
cc: @dfr
Describe the solution you'd like
No response
Describe alternatives you've considered
No response
Additional context
No response