New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Docker image #17
Comments
Hi Ximon, First of all, thanks for sharing this and for your patience waiting for this response. We were actually working on a docker image, but there's no need for you to apologize, since your contribution helped us to tweak it 😉
We really appreciate this, and will ask you if you could take a look at our image proposal, currently located at a personal repository: pcarana/docker-images/tree/master/FORT-validator. If you have any suggestions or comments about it, please let us know to address them. Once we have your comments, we're planning to send the image to QA team so that we can make it official. Also, regarding the requested changes you made, here is the response to each of them:
Done. The image first installs compile dependencies and compiles from source code, once terminated, the binaries are copied into the final image, which will be lighter since it doesn't have all the dependencies needed to compile.
Done.
We've done the same (use tini), apparently this is a common issue at containers and tini seems the way to handle the signal. We didn't knew it, so thanks for the guidance.
Done. This improvement is part of v1.1.2 (this is the current version, utilized by the image), here's the doc for the new argument
As you will see, the image still doesn't include the TALs (only the fort binary and man are included). But maybe, at the packages, you missed them: 4 of the TALs are included at the packages (at directory Best regards. |
Hi, No problem, the delay is understandable. I took a look, built the image locally and tried it out and it looks great! Well done! Happy I could help. Ximon |
Thanks for the quick feedback. We'll send this to QA and will keep you posted at this same issue. The issue will remain open until we "officially" offer the image. |
Update: the docker image seems now closer to reality, since an unknown behaviour that it had seems to be fixed (see #35). Hopefully, soon enough we'll be uploading the "official" version of FORT Validator docker image. |
Finally this has been fixed and released 😃 The Dockerfile can be found at the docker directory. We had a problem using Alpine (and therefore, musl libc) image, fixed at 273720e. This fix was released on the previous version 1.3.0, but it was until now that we could offer the docker image. |
Hi @pcarana, First, great work, thanks for getting this done. However, I'm a bit confused/surprised, as unless I missed something you haven't actually provided a publically available Docker image, you've only provided a Thanks, Ximon Update: I have published a 1.4.0 tag in my Update: I just noticed that in the repository the 1.4.0 tag version of the Dockerfile contains |
Hi @ximon18 ,
Certainly you didn't missed something, the official image wasn't available (until now 😉 ). We've uploaded it to nicmx/fort-validator and also I've updated the docs a few moments ago, so, now you can just pull the image:
Thanks for this!
Yep, my bad. I uploaded the fix directly to the master branch a couple of days ago. The main idea is not to override the FORT_VERSION arg, since it should be already the latest version, that's why it isn't mentioned at the docs. |
Great, I'll use your image and get rid of mine! |
Glad to help! 👍 |
FYI I've added this at the top of my Docker Hub Fort Validator image description:
|
@pcarana: It might be good to link from the description of your image on Docker Hub to your project or GitHub page, at present there's no link back to anywhere. |
Nice! Thanks for the reference.
You're right. We've updated the README to link back to our docs. |
Hello there,
For my own use I created a Docker image based on the Debian FORT Validator package. See:
If you've already got this in-progress or sorted and I missed it my apologies, I can switch to using your image and get rid of mine.
I would be happy to donate it to you in some way, either as-is or perhaps to help you time permitting (e.g. via a Pull Request) to add a Dockerfile (and if needed any supporting files) into your own GH repo (e.g. for auto-building via Docker Hub).
However I can imagine that you might want to make some changes, e.g.:
Base it on building from sources using COPY . . or similar in your own GitHub repo, instead of downloading and installing a Debian package (only happens once when the image is built, users of the image don't care how the FORT Validator was installed in the image, but you can't build from a GH branch directly instead only after a DEB package has been produced).
Base it on Alpine base image instead of Debian (seems to be the "in" trendy thing to do in the Docker image world, mainly I think to reduce the image size).
Tweak FORT Validator to behave correctly when running as PID 1 (in my testing when run inside a Docker container I was unable to CTRL-C the running container presumably because when running as PID 1 it does not respond to signals as Docker requires). I worked around this by using tini.
Tweak FORT Validator to not require syslog when not in standalone mode but instead log to stdout/stderr which is then visible via
docker logs
when running in-d
mode with Docker, or via the console when running without-d
. I worked around this by installingrsyslog
in the image and by symbolically linking/var/log/syslog
to/proc/1/fd/1
which is a bit of a hack.I chose to include the TAL files that you host in your GitHub repo, you may not wish to as you do not appear to bundle them with FORT Validator packages (did I miss them?). You may want to look at how Routinator handles this in its Docker image (see here) - disclaimer: I work for NLnet Labs, the developers of Routinator.
Best wishes,
Ximon
The text was updated successfully, but these errors were encountered: