#skopeo — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #skopeo, aggregated by home.social.
-
Топ-8 опенсорс‑инструментов, которые необходимы разработчику в кубере
Open source инструменты удобны для разработчика: настраиваешь их под себя и не зависишь от чужих правил, ценников и внезапных ограничений. Плюс вокруг них обычно есть живая документация и комьюнити — проблемы и решения редко остаются «в вакууме». Собрали с командой R&D список инструментов, которыми сами пользуемся ежедневно. В подборке — опенсорсные инструменты для разных ситуаций: от работы с Kubernetes и контейнерными реестрами до тестирования API, проверки чужих репозиториев и runtime‑наблюдения за безопасностью контейнеров.
https://habr.com/ru/companies/pt/articles/1009520/
#cybersecurity #backend #runtime #code_review #freelens #k9s #skopeo #bruno #zed
-
Slow claps for Skopeo just completely fucking ignoring an argument and providing zero warning that it's not going to do anything.
Does this manual entry look like it's clear it doesn't *work* for actual image registries?
-
I’ve changed the #GitLab CI pipeline not to immediately push all #Docker tags with #podman build. Instead I added another job to tag pushed images with #skopeo only after all tests passed. Initially images have only the SHA1 Git revision as tag—tags like "latest" are created later with "skopeo copy".
The pipeline:
https://gitlab.com/coocook/coocook/-/pipelines/2085257869The commit making the changes:
https://gitlab.com/coocook/coocook/-/commit/3584da0dcdea293bf13ca185ab1c64d6b719d504 -
-
Does anyone know how to pull multiarch container manifests with #Podman or #Skopeo? I can build them just fine with
podman build --platform, but each and every build tries to pull the base image for anything but my system arch, because that's what the tag points to in local storage. Is there some way to get the multiarch manifest into local storage instead, ideally in a way where per-arch images are only pulled as needed? :neocat_think:
For locally built multiarch manifests using them withpodman runetc. works just fine, so I could probably pull for the relevant arches one by one, record the image IDs, and assemble a multiarch manifest for the tag locally, but that seems rather convoluted. :neocat_laugh_sweat: -
To manage your own registry using the OCI APIs, there's a variety of client tooling.
- I'm the author of #regclient (the regsync command is very useful for mirrors): https://regclient.org
- #Crane is available from Google: https://github.com/google/go-containerregistry/tree/main/cmd/crane
- #Oras was started by Microsoft: https://oras.land/
- #Skopeo is available from RedHat: https://github.com/containers/skopeo/ -
@alxlg your most welcome!
I by no means only use #docker. Far from it. 😎 But it does have a lot of capabilities now. Very much thanks to the outstanding work done on #podman and #buildah.
Heck, yesterday a colleague found out "they" copied #skopeo for image mirroring with "imagetools". The cli design is really noisy, but it does work. 😅
https://docs.docker.com/reference/cli/docker/buildx/imagetools/create/
-
Skopeo can also inspect the configuration of a container, not just what's in the OCI manifest. It's great to get a handle on the default environment variables, working directory, and other defaults. Use the
--configflag to get the configuration of an image as a big JSON file.skopeo inspect --config --override-os="linux" --override-arch="amd64" docker://python:3.12I also needed to specify the OS and CPU architecture I wanted to inspect. Skopeo defaults to what's detected on the host and I'm on an ARM-based Mac. This returns something that's easy to pipe through JQ for just what I need - in this case, the default environment variables of the Python:3.12 image for Intel-based Linux systems.
ᐅ skopeo inspect --config --override-os="linux" --override-arch="amd64" docker://python:3.12 | jq '.config.Env'
[
"PATH=/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"LANG=C.UTF-8",
"GPG_KEY=7169605F62C751356D054A26A821E680E5FA6305",
"PYTHON_VERSION=3.12.7",
"PYTHON_SHA256=24887b92e2afd4a2ac602419ad4b596372f67ac9b077190f459aba390faf5550"
] -
Red Hat to Contribute Comprehensive Container Tools Collection to Cloud Native Computing Foundation https://www.redhat.com/en/blog/red-hat-contribute-comprehensive-container-tools-collection-cloud-native-computing-foundation #RedHat #CNCF #podman #bootc #skopeo #buildah #OpenSource #Linux
-
Today at #KubeCon, Red Hat announced their intent to contribute their container tools such as #Podman, #PodmanDesktop, #Skopeo, #Buildah to the Cloud Native Computing Foundation! Super exciting news & proof of the commitment Red Hat has to the Open Source community.
-
Will I be glad that I found #skopeo? Perhaps this next week will demonstrate.
-
Want to know how big an image is going to be *before* you download it? You can do this with #skopeo and a bit of #bash.
skopeo inspect docker://alpine/openssl:latest | jq '.LayersData[].Size' | paste -s -d+ - | bc | numfmt --to=iec-i --suffix=B
3.6MiB
skopeo inspect docker://ucsb/pstat-134-234:v20231107 | jq '.LayersData[].Size' | paste -s -d+ - | bc | numfmt --to=iec-i --suffix=B
7.6GiB
-
I've just started using #crane instead of #skopeo (both great tools!) in #mindthegap so wrote up a quick blog post showcasing both tools and a few of their differences
https://eng.d2iq.com/blog/a-tale-of-two-container-image-tools-skopeo-and-crane/
-
I love how much of my job is automated via #Ansible #AWX and #Jenkins. I love how amazing the #RedHat #container tools are for supporting it all - #podman, #skopeo, #toolbx, etc. It's all running on a highly versatile and fully #opensource stack.
-
quicktip #19: inspecting remote Windows container images without downloading them using Skopeo.
(to not having to run run a Linux container for Skopeo, we'll build skopeo.exe for Windows).
