Everytime I look up advice/details of how to do something on Linux and the project/guide doesn't explain what to do, but instead has a docker image, my resolve to never use docker increases a little bit more.

I get why docker exists and I'm not saying that it's not useful but wow I really do not want the question "How do I do x" to be answered with "Use this docker image"

Honestly if you like docker then that's great but here me out:

Docker on enterprise servers? βœ… Yep
Docker instead of VMs? βœ… Sure why not?
Docker because you want to? βœ… Of course!
Docker on a single board computer for one job? ❌ Nonononono please just tell me the steps involved so I can learn how the system works!

@renbymon I've got a couple of things running in Docker on SBCs that are the ony thing doing anything on that machine. it's kinda overkill, but it allows me to more easily intergrate it into my larger remote management system, and makes monitoring, alerting, and updates a looot easier.

@garrwolfdog Sorry I didn't mean to come across as "never use docker at all" but that I dislike that answers have in some cases become "use this docker image"

For example I want a SBC to monitor the temperature of my hot water tank. The first guide I found said that I should use multiple docker images to provide Prometheus and Grafana, and other guides were similar.

In the end Darac pointed me to Munin and that's exactly what I want. :)

@garrwolfdog Like in your case if you're already au fait with docker and it fits into your network then it makes sense, but for me who's still running servers with multiple services for an internal home network I'd prefer to have the details of how to configure it myself :)

It wouldn't be an issue if it was "here's how to do it from scratch but also there's a docker image if you want" but I keep seeing guides that are "you must use docker"

@renbymon I'm not totally sure I follow. Even if you're using docker you still need to configure things as much as you would if you were setting it up on bare-metal. the only real difference if that you don't need to compile the binarries yourself and it will have kind of sandbox to run in. unless you're wanting to tinker with the source code itself, I guess?
Ooor this might just be confusion about how docker works? it can be alittle unclear, tbh.

@garrwolfdog Sorry let me clarify; I know nothing about docker and the first time I tried to follow one of these guides I ran into a problem with no way of being able to troubleshoot the fault. I couldn't find an easy answer of how to look at the logs or files within the docker so I had no idea what was going on.

That one did have all the code/scripts/etc not in a docker image and the first time I ran all that I found the fault straight away just by looking at the system logs.

@garrwolfdog @garrwolfdog It turned out that the python code was pointing to a folder that didn't exist. Changing that code fixed the problem, but the docker image pulled the code directly from the GitHub so short of forking the project and making my own changes directly from there I wasn't able to find a way to change the files in the docker container

Follow

@garrwolfdog I guess my point is that while I'm futsing around with my own little projects I know how to troubleshoot if it doesn't work. I've no idea how to do that on a docker container and I haven't yet found anything that explains it in a way I can understand, if it even is possible to troubleshoot like one would for a bare metal machine.

Β· Β· 2 Β· 0 Β· 1

@renbymon Ah! I see. yeah, the debug process is alittle different; and honestly, kind of a pain if you're just using straight docker. if you use docker-compose or something like Portainer, then monitoringthe logs is instantly a lot easier and more intuative.

@renbymon @garrwolfdog Really, each container is just a little Linux server running in its own space on top of actual Linux. You can get into it and see the filesystem with 'docker exec <container id|name> -ti /bin/bash’.
Incoming network connections are mapped (on startup) from your host to the container.
Logs may be in /var/log in the container, or sometimes it's set to go to stderr, in which case use 'docker logs <container> -f' to see them.
You know all this, then you can debug. :)

@kootenay @renbymon veeery much this. or, if you use portainer, you can just go to the dashboard and click the 'log' icon; if you're lazy, like me XD

Sign in to participate in the conversation
Computer Fairies

Computer Fairies is a Mastodon instance that aims to be as queer, friendly and furry as possible. We welcome all kinds of computer fairies!