Closed AlexisPPLIN closed 1 year ago
@AlexisPPLIN The CVEs are from the outdated alpine image used as the base for autoheal. If you update the Dockerfile for alpine 3.17.3 and build a new copy of autoheal, then you'll pass the trivy scan with no CVEs (for now).
Since latest tag is being built until today, Isn't a good idea use alpine:latest
tag to allow low maintenance and lower surface for CVEs?
This container still mantained - by the way?
@leleobhz No idea if this project is still maintained, but I'm building from alpine:latest
with the tcp docker proxy patch from issue #48. It seems to be working so far, but I haven't had time to really test or publish the work (yet).
Thanks for the precision @tylerpace ! (If you ever release your work and a new built containers, I would love to be informed ❤️)
Like what @leleobhz said, relying on alpine:latest
for new builds would be better for security.
But this project seems abandoned and that's a shame since docker still does not have a native solution to restart unhealthy containers.
@AlexisPPLIN I made a fork at https://github.com/tylerpace/docker-autoheal and merged in most of the PRs here. I'm not making any ongoing maintenance promises yet, but I'll at least get to the point of setting up a basic Github actions pipeline that builds from alpine:latest
and pushes to a public registry for those that want to YOLO my updates. 😁
Hello @tylerpace
I took the place to build you repo weekly at https://github.com/ZenithTecnologia/docker-autoheal-build/ (Zenith Tecnologia is my Organization).
I strongly suggest you to keep 2 Dockerfiles: Dockerfile for pined version and Dockerfile.latest to 'alpine:latest'.
Anyways, this is a fast way to have a minimal updated image in a public registry :)
Hello @tylerpace
I took the place to build you repo weekly at https://github.com/ZenithTecnologia/docker-autoheal-build/ (Zenith Tecnologia is my Organization).
I strongly suggest you to keep 2 Dockerfiles: Dockerfile for pined version and Dockerfile.latest to 'alpine:latest'.
Anyways, this is a fast way to have a minimal updated image in a public registry :)
Why have two Dockerfiles?
The only reason I can see currently to have two Dockerfiles is so that one can have a version which auto generates a pull request to update via dependabot/renovate.
Just set an ARG, default being pinned or latest.
In the pipeline, have two tags, one which handles the default arg, one which passes the latest tag.
It would simplify builds and reduce code sprawl.
An example: Dockerfile with a build pipeline similar to droneci
Another note, it seems that Alpine:latest is not a rolling release like Ubuntu for example, but references the latest tagged version.
Unsure if tagging per Alpine release would be the best solution in this case.
Hello @tylerpace I took the place to build you repo weekly at https://github.com/ZenithTecnologia/docker-autoheal-build/ (Zenith Tecnologia is my Organization). I strongly suggest you to keep 2 Dockerfiles: Dockerfile for pined version and Dockerfile.latest to 'alpine:latest'. Anyways, this is a fast way to have a minimal updated image in a public registry :)
Why have two Dockerfiles?
The only reason I can see currently to have two Dockerfiles is so that one can have a version which auto generates a pull request to update via dependabot/renovate.
Just set an ARG, default being pinned or latest.
In the pipeline, have two tags, one which handles the default arg, one which passes the latest tag.
It would simplify builds and reduce code sprawl.
An example: Dockerfile with a build pipeline similar to droneci
Another note, it seems that Alpine:latest is not a rolling release like Ubuntu for example, but references the latest tagged version.
Unsure if tagging per Alpine release would be the best solution in this case.
Hello!
Idea here is not overengineering it too much, but just keep it updated. In fact I have tons of considerations about Alpine+MUSL but since this is a little bashy tool, the only concern I have is about security fixes.
By my own mind, I prefer using RedHat UBI Minimal, RedHat UBI Micro or VMWare Photon as base image, since they cover security updates quickly than other images and have almost same low footprint as Alpine (Photon have ~15mb):
I agree with everything about the rest and since this image still relevant, I suggest we create a little project with all people here commited with this project to modernize and mantain this still-important tool working well.
I agree with everything about the rest and since this image still relevant, I suggest we create a little project with all people here commited with this project to modernize and mantain this still-important tool working well.
I'd be happy to contribute.
This is my repo (just a fork of @tylerpace's with a few modifications to the Dockerfile + workflow) where I've simplified my above comment, and went back to relying on tags for version control/pinned versions.
I agree with everything about the rest and since this image still relevant, I suggest we create a little project with all people here commited with this project to modernize and mantain this still-important tool working well.
I'd be happy to contribute.
This is my repo (just a fork of @tylerpace's with a few modifications to the Dockerfile + workflow) where I've simplified my above comment, and went back to relying on tags for version control/pinned versions.
I liked you ARG usage for Alpine version because it allows third party builds with other versions w/o maintenance issues (Repo can just be cloned and built against desired version).
I'll attempt some builds for Photon/UBI pushing docker-entrypoint from your master branch to have another basis for autoheal.
This project is necessary - since Docker still not have a rebuild-on-failure feature - and deserves attention and mantainance.
Wow, this issue seems to be quite popular :smile:
AFAIK, we have to following images to replace willfarrell/docker-autoheal
(if not updated) :
modem7/docker-autoheal:1.2.1
quay.io/zenithtecnologia/docker-autoheal:latest
I will be using modem7/docker-autoheal:1.2.1
because tagged versions > latest for my job workflow.
In the long run, maybe it would be easier to have only one repo to re-group all this work and give an easy remplacement of willfarrell/docker-autoheal
. Idk
Great job everyone !
@tylerpace @AlexisPPLIN @leleobhz - May be worthwhile putting everything into one repo, and having multiple maintainers? May be neater that way.
I'm happy to use my CI/CD system to build and deploy the images to dockerhub on my repo if that would help out?
@tylerpace @AlexisPPLIN @leleobhz - May be worthwhile putting everything into one repo, and having multiple maintainers? May be neater that way.
I'm happy to use my CI/CD system to build and deploy the images to dockerhub on my repo if that would help out?
I'm already using your image. I can contribute and maintain too, so how do you think is the best way to we keep maintaining the images?
We'd probably need to get all maintainers who are interested together, then officially request taking over the image (assuming @willfarrell is still active and would give us their blessing).
Once that happens, I can give the above people (including @willfarrell) maintainer access to the repo and go on from there.
Happy to be corrected however!
Once that happens, I can give the above people (including @willfarrell) maintainer access to the repo and go on from there.
I agree if everyone agree. Also this can unify efforts to improve images, create other tags that maybe necessary and keep a proper CI/CD pipeline allowing upstream fixes to be reflected to this image.
This tool is important as Docker does not handle crashes like Kubernetes does - as example - and this tool provides healing without add unecessary complexity to environments.
Once that happens, I can give the above people (including @willfarrell) maintainer access to the repo and go on from there.
I'm all in to help ! Even if my time will be a bit limited during this summer.
I agree that this tool need more love and maintainers. It's incredibly useful for small and medium projects :smile:
I've added all 3 of you. Thanks for your interest in maintaining this repo. I don't currently use this in any active projects which is why I've been so inactive.
@willfarrell @modem7 and @tylerpace - I think this is the time we can get together to check the next steps.
I suggest initially we merge @modem7 repo with here and update main docker image / CI/CD pipeline / etc.
This is a good plan?
No worries @willfarrell, thanks for the help !
I suggest initially we merge @modem7 repo with here and update main docker image / CI/CD pipeline / etc.
+1 to use the @modem7 repo in here. No issues with it in the last 2 month.
And maybe it's also time to open a new issue ?
If @willfarrell has added us to this repo, we may as well use it to avoid confusion for those that aren't checking the updates, and start working on the backlog (either closing or actioning, I'm unfortunately not the best placed for that decision as I have more of a backend skillset).
I would probably need access to dockerhub as well if we're using my CD system (Drone), and we can set it up for releases/tags quite easily (as I have on my repo).
Happy to do whatever is best for all (we can also use github actions as well which may be better in case my system goes down/I leave the project/I get compromised, therefore keeping things "in house", and it's already set up).
Maybe we should start with merging my/@tylerpace's repo into this one as a starting point, and configure renovate or dependabot for basic updates.
+1 to using @modem7's variant as the one to officially merge here. It's the most updated now, I'm using it too!
+1 to keeping this repo as the primary. I'm sure there are plenty of folks out there still running a very outdated autoheal sitting on latest
that would benefit from us publishing an update under this namespace.
+1 to moving CD to Github Actions. That's one less dependency that breaks as maintainers shift on this project. It's also helpful for anyone that forks in the future to get a CD pipeline for 'free'.
@tylerpace and @modem7 I can Write Github Actions. I'll prepare the PR here tomorrow.
@tylerpace and @modem7 I can Write Github Actions. I'll prepare the PR here tomorrow.
Sounds like a plan.
I'll figure out what I've done on my repo, and get a PR made to merge.
Hey !
Do you need any help whatsoever? I have some free time to work on this repo
Sorry this took so long guys. Work has been hectic as hell.
I've created https://github.com/willfarrell/docker-autoheal/pull/112/ which has a lot of @tylerpace's and some of my contributions. It should certainly set a good starting point for the rest of the work.
We can then start working on workflows and closing some of the pull requests that have critical bugs or useful features that we can implement.
At some point, I'd also like to implement S6, but that a future want, not a requirement.
@modem7 I also have issues to address, but notting does any sense if both you and @tylerpace work was not merged here, so let's address https://github.com/willfarrell/docker-autoheal/pull/112 and close this.
@modem7 I also have issues to address, but notting does any sense if both you and @tylerpace work was not merged here, so let's address #112 and close this.
Agreed - let's have a common starting point, and then we can start sorting the rest out, and making/merging/closing PR's as required.
When is it planned to release these CVE fixes please?
My server is currently down right now, so I'll need a bit of time whilst I get replacement parts if we're doing it on my repo.
If we're doing it on the original repo, we should be able to do it via github actions.
@modem7 While I now think https://github.com/willfarrell/docker-autoheal/blob/main/.github/workflows/github-build.yml is good enough (But some changes need to be done), CVE must be ported by upstream in a ideal world.
Apparently fixes comes to releases of Alpine, so I'll ask for pinning to 3.18 instead a explicit release version.
Hi !
When scanning this image with trivy (vulnerability scanner), it found 4 CRITICAL CVE. Here is the complete result for the latest tag :
Could this be addressed somehow ?
Thanks a lot !