logdyhq
Feature Request: docker image
Hello,
It would be great to have a docker image for this fantastic tool :)
It would make it easier to deploy
Best
Hi @azertylr what would be the use case? Docker image seems like an overhead given that you can download compiled version on Linux, MacOS and Windows from github directly or use a bash script -> docs. If you let me know how Docker image would make your life easier, I'll consider it :)
On top of that, using Logdy through Docker would be cumbersome since Logdy would run inside a container which would prevent it from accessing stdout of other processes outside of it's container. Also accessing logs is complicated as you would have to share a mount point with the host system... That all seems like a complex to setup and then maintain.
Hi @PeterOsinski
Docker allows an easy deployment and flexibility if you need several instances of lodgy. You can for example add directly to the docker compose of the project a container with logdy. It also provides an isolation and a flexible management when you have all of your app running with docker.
I did create a container for testing and it works well, and add it to my docker compose :
services:
caddy:
...
logdy:
image: logdy
container_name: logdy
read_only: true
volumes:
- /home/docker/caddy/logs/access.log:/var/log/access.log:ro
- /home/docker/caddy/logs/error.log:/var/log/error.log:ro
- /home/docker/logdy:/config
restart: unless-stopped
and a very simple dockerfile
FROM alpine:latest
ENV LOGDY_VERSION=0.13.0
ADD "https://github.com/logdyhq/logdy-core/releases/download/v${LOGDY_VERSION}/logdy_linux_amd64" /usr/local/bin/logdy
RUN chmod +x /usr/local/bin/logdy
ENTRYPOINT ["/usr/local/bin/logdy"]
CMD ["--ui-ip", "0.0.0.0", "--config", "/config/logdy.json", "follow", "/var/log/access.log"]
thanks for the input, I'll think about how to best approach it. I'm planning to jump on it in the next 1-2 weeks
Hey, how is the development going? Can I help somehow? I'd happily write the dockerfile and configure the github action to build multiarch images.
@borosr @azertylr you are welcome to submit a PR if you have any specific implementation in mind. I'm having a bit of a busy time these days. Should get more time in around 1-2 weeks.
@PeterOsinski Just submitted #56. Dockerfile tries to be as much generic and unopinionated as possible, to serve as many usage scenarios as possible (e.g. not size-optimized, yet).
It will work for @azertylr's docker-compose.yml scenario, although the service definition will need a command key for passing the command switches and a detailed build section to point to the Dockerfile Github repo URL.
Everyone's welcomed to take it for a spin and provide feedback on the PR.
@azertylr: now that #56 is merged, you might want to tweak your Compose manifest by adding a build section which references this repo's URL and see if it works for you.
See Compose Build Specification for how to make a service build from a repo URL.
Hello,
It is working great :) my docker-compose:
Thanks!
services:
logdy:
build: https://github.com/logdyhq/logdy-core.git
container_name: logdy
read_only: true
volumes:
- /home/docker/caddy/logs:/var/log:ro
- /home/docker/logdy/logdy_caddy2.json:/config/logdy.json
restart: unless-stopped
security_opt:
- no-new-privileges=true
Just something I've just noticed, image is 935.6 MB, versus 87 MB for the exe file :(
Just something I've just noticed, image is 935.6 MB, versus 87 MB for the exe file :(
It is happening because the dockerfile's base image is the golang:1 and this is a big one, i'll try my best to sumbit a pr today with a multistep docker build that reduces the image size.
@azertylr : Glad to know it's working for you and thanks for sharing your Docker Compose snippet. I think it'll make for a good usage example, once Docker usage it's settled. As you noticed, size was not a priority initially and I don't think it should be yet.
@borosr : A size optimization would be a desirable improvement down the road and much appreciated, indeed. But there are a few follow-up improvements which might come later that I think would be easier without the size improvements around yet (to come later). For the full context and rationale of the Dockerfile, check out #56. Even better, if you have any feedback, I think that perhaps there will be a better place to discuss the Docker image implementation details and maybe spin off relevant issues.
@PeterOsinski : Also, to properly scope the Docker efforts from here on, I'd like to know your stance as maintainer on how much you're up to add to the project in terms of future maintenance. Do you prefer keeping it as minimal as possible (ie. just a canonical "just builds :tm:, you figure out usage" Dockerfile in repo, no built public image) or do you want to fully support Docker usage (public image, docs, etc.)?
Needless to say, there's no right answer, as it depends entirely on how much time and effort you feel like to commit to this specific feature in the future.
Hey @pataquets thanks for the input. From my point of view, whatever requires less maintenance the better. Currently I don't have a lot of trace for some special Docker usage with Logdy. Maybe that could change once more docs will be created showing how Logdy can be used with current Dockerfiles you created.
Would you be open on creating some content for docs like this: https://logdy.dev/blog/post/docker-logs-web-browser-ui?
Having more specific Docker docs will hopefully drive more users (SEO) to the landing page, users that are looking for some logging solutions for Docker, which could increase the demand for more specific solutions.
If I understand it correctly the logdy only input is still throught tcp port? In docker mode it could also listen to other containers stdout/stderr output, just like https://dozzle.dev/ do. This way one could embed a log watcher/parser into its docker compose stack
