Comments (4)
Just for reference the simplified process for a single docker container by its name:
%%{init: {"flowchart": {"htmlLabels": false}} }%%
flowchart TD
classDef code fill:#bbf,stroke:#f66,stroke-width:2px,color:#fff,stroke-dasharray: 5 5
begin([BEGIN]) --> iterate
subgraph iterate["For each container by name"]
repourl["get image ($RepoUrl) by $name`"] --> local_hashes["get local hashes ($LocalHash) by $RepoUrl"]
repourl -.- repourl_example["mariadb:10.11.6"]:::code
local_hashes -.- local_hashes_example["[mariadb@sha256:692… mariadb@sha256:d86…]"]:::code
local_hashes --> remote_hash["get remote hash ($RegHash) by $RepoUrl"]
remote_hash -.- remote_hash_example["sha256:e84…"]:::code
remote_hash --> contains{"is remote hash within local hashes?"}
contains -- yes --> update["add name to updatable list ($GotUpdates)"]
contains -- no --> no_update["add name to non-updatable list ($NoUpdates)"]
end
iterate --> end2([END])
from dockcheck.
Thank you for a clear and detailed post!
While I agree this would be a very nice addition - it requires a lot of work and testing and I'm not really sure it's possible to achieve cleanly and consistently, due to the very different ways of handling tags.
If you see my answers in this current FR: [FEATURE REQUEST] Add Link to GitHub repo #67
I'll keep digging in the future, but right now I've not got a clear idea for how to solve it.
As you can see (from what you've linked) the naming of versions and how recent they are are not very clear or generic - so pretty hard to build logic to present it in a fail-safe way.
You can explore with commands like
curl --silent "https://registry.hub.docker.com/v2/repositories/linuxserver/wireguard/tags?page_size=100" | jq -r ".results[].name" | sort --version-sort
Or regctl tag ls linuxserver/wireguard
To see how many tags (and unclear naming) there's for a specific image.
And if you run this
for i in $(docker ps --format '{{.Names}}') ; do printf "$i - " && docker inspect "$i" --format='{{ index .Config.Labels "org.opencontainers.image.version" }}' ; done
You'll see how many of your current containers that don't have a version label and how different naming they use.
Sorry for being negative - but this is how far I came when digging into this recently. I wont give up, but I don't have the time nor energy to invest further in this right now.
from dockcheck.
Sorry for being negative - but this is how far I came when digging into this recently. I wont give up, but I don't have the time nor energy to invest further in this right now.
Thank you for your detailed reply! That's just the situation in reality, no need to shoot the postman for the bad news 🙂 I was half afraid of that situation.
Maybe we can still try to approach a working POC. It's two things that are required: the current version and the latest sane version label. If I understood your reply in the other post correctly then currently your algorithm works like this:
- hash = hashed digest of the image of a running container
- latest_hash = retrieve the latest tag of that image on its respective container registry (how do you know which one this is?)
- update_available = hash != latest_hash
Now an attempt for a solution could work with the assumption the project uses semantic versioning. This regex could be used to filter out the sanitized tags from the registry:
^(v?\d+(\.\d+)*(-.+)?)
The local version could be fetched by this command:
$ docker inspect netbox-redis-1 --format "{{ .Config.Image }}"
redis:6.2.7-alpine
This of course requires the image to be reverenced by the precise version tag (e.g. 6.2.7-alpine
) instead of the magic latest
.
Now what's left required is an algorithm which compares the two versions. This could be a bit tricky due to the fact that this project uses Bash. But there might be existing solutions for this. But maybe this isn't even required if only the tag of the image from latest_hash
could just be shown.
What do you think?
from dockcheck.
I'm glad that you keep on brainstorming and helps suggesting solutions!
- hash = hashed digest of the image of a running container
- latest_hash = retrieve the latest tag of that image on its respective container registry (how do you know which one this is?)
Well currently this is it:
1.
docker image inspect "codeberg.org/forgejo/forgejo:1.20" --format '{{.RepoDigests}}'
Giving the result:
[codeberg.org/forgejo/forgejo@sha256:c2e782fdf876e4e7f179819a43b0e729aab59c37aa67a71d09f76dd2c7b2a214]
regctl image digest --list codeberg.org/forgejo/forgejo:1.20
Giving the result:
sha256:c2e782fdf876e4e7f179819a43b0e729aab59c37aa67a71d09f76dd2c7b2a214
Then they're just compared, if the sha256:value from the newest exists in the local - it's already latest.
So if you've got the version tag 1.20
(as in the example above) you'd only check for updates for that specific tag - that's the reason behind having the tags set in the first place compared to using :latest
.
And if you're using :latest
- then tags and versions are not taken into account at all.
Now what's left required is an algorithm which compares the two versions. This could be a bit tricky due to the fact that this project uses Bash.
This is easily done once I've got two tags to compare. The hard thing is getting the tags extracted reliably - both from local images and from the registry.
from dockcheck.
Related Issues (20)
- [FEATURE REQUEST] save preference regarding updates (git/curl) HOT 1
- [FEATURE REQUEST] Add option do define/use multiple .env-files HOT 10
- Progress bar fails with -s option HOT 3
- [FEATURE REQUEST] Automatically download latest in use notification add-on HOT 3
- [Feature] Add -v flag for version number printing of dockcheck HOT 1
- [FEATURE REQUEST] Add Link to GitHub repo HOT 5
- [FEATURE REQUEST] Telegram notification HOT 3
- [FEATURE REQUEST] Minimal Output HOT 6
- Readme: add install instructions HOT 5
- [Feature Request] - Web Interface Productivity Improvements / Updates Suggestions HOT 2
- Idea: package the repo into an container HOT 1
- dockcheck hangs when checking for updates HOT 10
- Everything times out and fails on non amd64 / arm64 HOT 3
- coreutils HOT 10
- timeout: unrecognized option '--foreground' error message HOT 5
- cd: /data/compose/62: No such file or directory HOT 11
- Gotify template HOT 2
- ssmtp is considered abandoned and should be depreciated. HOT 2
- Running with -a -y still ends with interaction (pruning images) HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dockcheck.