Closed ximon18 closed 4 years ago
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 :wink:
I would be happy to donate it to you in some way, either as-is or perhaps to help you time permitting {...}
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:
Base it on building from sources using COPY {...}
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.
Base it on Alpine base image instead of Debian {...}
Done.
Tweak FORT Validator to behave correctly when running as PID 1 {...}
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.
Tweak FORT Validator to not require syslog when not in standalone mode {...}
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 --log.output
.
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?) {...}
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 ./tal
) and also at the debian package (installed at /etc/fort/tal
). About the missing one (ARINs TAL), as of today we are still recommending to download it manually, but we're working on something to fetch it (similar to what you do with routinator).
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 :smiley: The Dockerfile can be found at the docker directory.
We had a problem using Alpine (and therefore, musl libc) image, fixed at 273720e473273d1605615ddc164b085a525ba5fd. 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 Dockerfile
from which an image can be built. I was expecting to find a NICMx/fort or so image on Docker Hub. Do you plan to publish an official image?
Thanks,
Ximon
Update: I have published a 1.4.0 tag in my ximoneighteen/fortvalidator
repository on Docker Hub using your Dockerfile from the v1.4.0 GitHub tag in this repository without any modifications. See: https://hub.docker.com/repository/docker/ximoneighteen/fortvalidator
Update: I just noticed that in the repository the 1.4.0 tag version of the Dockerfile contains ARG FORT_VERSION=1.3.0
. I thus mistakenly built an image containing the wrong FORT Validator version. I have now corrected this. Anyone building the image would get the wrong FORT Validator version too as your instructions don't say to override the FORT_VERSION arg when building, i.e. --build-arg FORT_VERSION=1.4.0
.
Hi @ximon18 ,
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 Dockerfile from which an image can be built. I was expecting to find a NICMx/fort or so image on Docker Hub. Do you plan to publish an official image?
Certainly you didn't missed something, the official image wasn't available (until now :wink: ). 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:
docker pull nicmx/fort-validator:latest
Update: I have published a 1.4.0 tag in my ximoneighteen/fortvalidator repository on Docker Hub using your Dockerfile from the v1.4.0 GitHub tag in this repository without any modifications. See: https://hub.docker.com/repository/docker/ximoneighteen/fortvalidator
Thanks for this!
Update: I just noticed that in the repository the 1.4.0 tag version of the Dockerfile contains ARG FORT_VERSION=1.3.0. I thus mistakenly built an image containing the wrong FORT Validator version. I have now corrected this. Anyone building the image would get the wrong FORT Validator version too as your instructions don't say to override the FORT_VERSION arg when building, i.e. --build-arg FORT_VERSION=1.4.0.
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! :+1:
FYI I've added this at the top of my Docker Hub Fort Validator image description:
USE nicmx/fort-validator INSTEAD !
NO NEW VERSIONS OF THIS IMAGE WILL BE PUBLISHED - INSTEAD PLEASE USE THE NEW OFFICIAL
nicmx/fort-validator
IMAGE
@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.
FYI I've added this at the top of my Docker Hub Fort Validator image description:
Nice! Thanks for the reference.
@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.
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