6 ms·

Does everything really need to be Docker these days? Specially "network stuff". I mean, it really makes me want to go and grow potatoes instead doing any "IT"

by amar0c 3y ago

deleted 3y ago
[deleted]
toomuchtodo 3y ago
It makes life so much easier. Time is non renewable, and if you want to pull a project apart for whatever reason, you still can. “docker pull”, deploy, and one can move on to the next whatever. You can deploy this to a Synology NAS, a Raspberry Pi, or Heroku with a few clicks (or even an appropriately configured router that supports containers if you’re not running something providing this functionality natively). (DevOps/infra monkey before moving to infosec, embrace the container concept)
- NexRebular 3y ago
  > It makes life so much easier. If running an OS that supports docker...
  - byteknight 3y ago
    If you're running an OS that doesnt support docker you have a very esoteric use case.
- xorcist 3y ago
  Let's not overstate things here. It may well look like "docker pull", deploy, nothing, ok, how do I configure this thing, oh goodie here's the uncommented yaml, deploy again, strange error, headscratch, oh it's dependent on using the .68.x network which I've already used elsewhere, let's rename those docker networks, deploy again, what?, oh it must have initialized a temporary password to the database when it didn't come up, let's wipe it all clean and pull again because I have no idea what kind of state is in those persistent volumes, deploy, rats! forgot the network renumbering, wipe clean, confiure again, deploy again, yay! Provided you already turned off everything that can interfere with this stuff, including IPv6, any security like SELinux, grsecurity and friends, and you let it administer your netfilter firewall for you. Don't forget to check if you accidentally exposed some redis instance to the public Internet. (And yes, I have embraced the concept and work daily with similar things, albeit in a larger scale. Let's just not kid ourselves it's easier than it is though. Just because an out of the box deploy goes sideways doesn't mean you are dumb.)
  - byteknight 3y ago
    To be fair none of those operations require a re-pull; not a single one.
    - xorcist 3y ago
      That's the spirit!
      - byteknight 3y ago
        Not sure the intention but I still don't see how debugging config in docker is inherently different than native.
  - RussianCow 3y ago
    Almost none of what you just mentioned has anything to do with Docker, and you can easily have that much trouble just running a binary. (In fact, I've found that many projects have better documentation for their Docker image than for running it natively.) Yes, there are some Docker-specific things you sometimes have to debug (especially with networking), but I've had far more trouble getting software running natively on my machine due to mismatches in local configuration, installed library versions, directory conventions, etc vs what's expected. It's also far easier to blow away all the containers and volumes and start over with Docker; no need to hunt down that config file in an obscure place that's still messing with the deployment.
    - enneff 3y ago
      This is a strange argument to me. It’s essentially that the additional complexity of docker compose is acceptable because other things are unnecessarily complex. The problem is complexity. There are many great projects that are just “build the binary, edit config file, and run it,” and why should things be more complex than that? It’s wild to me what people will put up with.
      - RussianCow 3y ago
- vincentkriek 3y ago
  To add to this, for me it's not specifically about the ease of setup which isnt that much easier (although it's nice that it's standardized). It's more about the teardown if it's not something for you. Services can leave a lot of residuals in the system, files in different places, unwanted dependencies, changes in system configuration. Removing a docker container is very clean, with the remaining stuff easily identifiable. Makes trying new stuff a way less troublesome.
- magicalhippo 3y ago
  I upgraded my PiHole running on an Allwinner H3 SBC last year. It wouldn't start, turned out some indirect dependency wasn't compiled for the ARMv7 platform. No worries, just specify the previous version in my launch script, literally changing a couple of digits, and I'm back up and running in seconds. I'm sure I could get it done using apt, but it was literally changing some numbers in a script and rerunning it. As someone who just wants things to work, Docker has made things significantly better.
- pdntspa 3y ago
  Can't deploy to a BSD server :( Give me raw source code or binaries and a configuration file in /etc or $HOME any day of the week.
byteknight 3y ago
Can I ask why ease of deployment makes you want to turn from IT? The speed of deployment cant be beat. Earnestly interested in your take.
- amar0c 3y ago
  Can you easily debug stuff? Can you tail -f /var/fing/log and see what X or Y does not work (without introducing another container/whatever just for this) ? I know I am minority.. but whole concept This runs X and This runs Y but storage/data is over there having nothing to do with both X or Y is F'd up. Yeah, you can easily pull and run things but you have no idea how or what it does and when things break whole idea is pull it again and run. I have nothing against containers.. real system ones (LXC for example)
  - byteknight 3y ago
    It seems there's a bit of a misunderstanding about how containers work. Firstly, debugging in containers is not inherently more difficult than on a traditional system. You can indeed `tail -f /var/log/...` within a container just as you would on the host system. Tools like Docker provide commands like `docker exec` to run commands within a running container, making debugging straightforward. The concept of separating runtime (X or Y) from data storage is not unique to containers; it's a best practice in software design called separation of concerns. This separation makes applications more modular, easier to scale, and allows for better resource optimization. The "pull it again and run" mentality is a simplification. While containers do promote immutability, where if something goes wrong you can restart from a known good state, it's not the only way to troubleshoot issues. The idea is to have a consistent environment, but it doesn't prevent you from debugging or understanding the internals. Lastly, while there are differences between application containers (like Docker) and system containers (like LXC), they both leverage Linux kernel features to provide isolation. It's more about the use case and preference than one being "real" and the other not.
    - tryauuum 3y ago
      I'm not the original poster but with default config logs are worse with docker. Running `docker exec` to check the /var/log in a container is pointless, application writes to stdout. So you do `docker logs` And by default logs are stored in a json format in a single file per container, grepping `docker logs` feels slower than grepping a file. And the option to read logs for n last hours is incredibly slow -- I think it reads file from the beginning until it reaches the desired timestamp
notatoad 3y ago
no, not everything has to be docker. for example, none of wireguard, pihole, or unbound have to be docker. you are welcome to install all those things yourself. but the whole project here is to wrap up a bunch of other projects in a way that makes them easy to install and configure with minimal fuss. docker is perfect for that. if you want to be fussy and complain about the tools other people choose, then projects like this probably aren't much interest to you.
api 3y ago
If the Linux ecosystem could get its act together, standardize, and consolidate all the totally needless and pointless distribution fragmentation we could challenge this. Docker took off because there is no Linux. There are 50 different slightly incompatible OSes. So the best way to distribute software is to basically tar up the entire filesystem and distribute that. Dependency management has failed because there’s just too much sprawl. One illustrative example: OpenSSL has divergent naming and versioning schemes across different versions of distributions that use the same Debian package manager. So you either build your packages at least four or five times, Dockerize, or statically link OpenSSL. That’s just for dpkg based distros too! Then there is RPM, APK, and several others I can’t recall right now. BTW Windows has a bit of the same disease and being from one company has a lot less of an excuse. OS standardization and dependency standardization is very hard to get right, especially at scale. Apple macOS is the only OS you can ship software for without statically linking or bundling everything and be reasonably sure it will work… as long as you are not going back more than two or three versions.
- amar0c 3y ago
  I have feeling whole Docker (or application containers) took of when "non Linux people" (read: developers) tried to be sys admins too and failed. Best thing after sliced bread is apps/software packed in single GO binary. Runs everywhere, you only need to rsync/scp it to million of other places and it "acts" (usually) as normal Linux program/daemon
  - api 3y ago
    That’s true but IMHO that’s an indictment if Linux not them. It’s 2023 and there is no reason system administration should be this hard unless you are doing very unusual things. The Go approach is just static linking. Rust often does the same though it’s not always the default like in Go, and you can do the same with C and C++ for all but libc with a bit of makefile hacking. Statically linking the world is the alternative approach to containers.
    - djbusby 3y ago
soneil 3y ago
It seems the canned deployment is the entire value-add here. It’s existing components that you can already deploy yourself if you prefer. I much prefer this over the old method of canned deployment where you ran a script and prayed it didn’t hose the host too badly.
- byteknight 3y ago
  You have absolutely hit the nail on the head. My view is this: There is a myriad of amazing toolage out there that the everyday person could greatly benefit from in their day-to-day life. A lot of that has a very high barrier to entry for technical knowledge. By simplifying this setup down to a simple Docker compose file I believe that I have allowed the lay person to play and experiment in the freedom of their own home with technology they may have otherwise been eyeing.
  - babyeater9000 3y ago
    I completely agree and want to add that the readme file does a good job of letting me know what this thing is and why I should use it. I really appreciate when developers take the time to be inclusive by writing for a less technical audience. I will at least try it out and see what it is all about. I have been looking to add more services to my pihole.
    - byteknight 3y ago
      Let me know if you need help. My Twitter is on the repo.
spandextwins 3y ago
Docker is great, with docker volumes I can move things between different machines with ease. Do pretty much everything with docker compose these days. Also it doesn’t clutter up my base install, and it’s a lot lighter weight than a virtual machine.
Fnoord 3y ago
Hopefully the dependency is OCI compatible container instead of specifically Docker.

Does everything really need to be Docker these days? Specially "network stuff". I mean, it really makes me want to go and grow potatoes instead doing any "IT"

by amar0c 3y ago

Does everything really need to be Docker these days? Specially "network stuff". I mean, it really makes me want to go and grow potatoes instead doing any "IT"

deleted 3y ago

[deleted]

toomuchtodo 3y ago

It makes life so much easier. Time is non renewable, and if you want to pull a project apart for whatever reason, you still can. “docker pull”, deploy, and one can move on to the next whatever. You can deploy this to a Synology NAS, a Raspberry Pi, or Heroku with a few clicks (or even an appropriately configured router that supports containers if you’re not running something providing this functionality natively). (DevOps/infra monkey before moving to infosec, embrace the container concept)

NexRebular 3y ago
> It makes life so much easier. If running an OS that supports docker...
- byteknight 3y ago
  If you're running an OS that doesnt support docker you have a very esoteric use case.
xorcist 3y ago
Let's not overstate things here. It may well look like "docker pull", deploy, nothing, ok, how do I configure this thing, oh goodie here's the uncommented yaml, deploy again, strange error, headscratch, oh it's dependent on using the .68.x network which I've already used elsewhere, let's rename those docker networks, deploy again, what?, oh it must have initialized a temporary password to the database when it didn't come up, let's wipe it all clean and pull again because I have no idea what kind of state is in those persistent volumes, deploy, rats! forgot the network renumbering, wipe clean, confiure again, deploy again, yay! Provided you already turned off everything that can interfere with this stuff, including IPv6, any security like SELinux, grsecurity and friends, and you let it administer your netfilter firewall for you. Don't forget to check if you accidentally exposed some redis instance to the public Internet. (And yes, I have embraced the concept and work daily with similar things, albeit in a larger scale. Let's just not kid ourselves it's easier than it is though. Just because an out of the box deploy goes sideways doesn't mean you are dumb.)
- byteknight 3y ago
  To be fair none of those operations require a re-pull; not a single one.
  - xorcist 3y ago
    That's the spirit!
    - byteknight 3y ago
      Not sure the intention but I still don't see how debugging config in docker is inherently different than native.
- RussianCow 3y ago
  Almost none of what you just mentioned has anything to do with Docker, and you can easily have that much trouble just running a binary. (In fact, I've found that many projects have better documentation for their Docker image than for running it natively.) Yes, there are some Docker-specific things you sometimes have to debug (especially with networking), but I've had far more trouble getting software running natively on my machine due to mismatches in local configuration, installed library versions, directory conventions, etc vs what's expected. It's also far easier to blow away all the containers and volumes and start over with Docker; no need to hunt down that config file in an obscure place that's still messing with the deployment.
  - enneff 3y ago
    This is a strange argument to me. It’s essentially that the additional complexity of docker compose is acceptable because other things are unnecessarily complex. The problem is complexity. There are many great projects that are just “build the binary, edit config file, and run it,” and why should things be more complex than that? It’s wild to me what people will put up with.
    - RussianCow 3y ago
vincentkriek 3y ago
To add to this, for me it's not specifically about the ease of setup which isnt that much easier (although it's nice that it's standardized). It's more about the teardown if it's not something for you. Services can leave a lot of residuals in the system, files in different places, unwanted dependencies, changes in system configuration. Removing a docker container is very clean, with the remaining stuff easily identifiable. Makes trying new stuff a way less troublesome.
magicalhippo 3y ago
I upgraded my PiHole running on an Allwinner H3 SBC last year. It wouldn't start, turned out some indirect dependency wasn't compiled for the ARMv7 platform. No worries, just specify the previous version in my launch script, literally changing a couple of digits, and I'm back up and running in seconds. I'm sure I could get it done using apt, but it was literally changing some numbers in a script and rerunning it. As someone who just wants things to work, Docker has made things significantly better.
pdntspa 3y ago
Can't deploy to a BSD server :( Give me raw source code or binaries and a configuration file in /etc or $HOME any day of the week.

byteknight 3y ago

Can I ask why ease of deployment makes you want to turn from IT? The speed of deployment cant be beat. Earnestly interested in your take.

amar0c 3y ago
Can you easily debug stuff? Can you tail -f /var/fing/log and see what X or Y does not work (without introducing another container/whatever just for this) ? I know I am minority.. but whole concept This runs X and This runs Y but storage/data is over there having nothing to do with both X or Y is F'd up. Yeah, you can easily pull and run things but you have no idea how or what it does and when things break whole idea is pull it again and run. I have nothing against containers.. real system ones (LXC for example)
- byteknight 3y ago
  It seems there's a bit of a misunderstanding about how containers work. Firstly, debugging in containers is not inherently more difficult than on a traditional system. You can indeed `tail -f /var/log/...` within a container just as you would on the host system. Tools like Docker provide commands like `docker exec` to run commands within a running container, making debugging straightforward. The concept of separating runtime (X or Y) from data storage is not unique to containers; it's a best practice in software design called separation of concerns. This separation makes applications more modular, easier to scale, and allows for better resource optimization. The "pull it again and run" mentality is a simplification. While containers do promote immutability, where if something goes wrong you can restart from a known good state, it's not the only way to troubleshoot issues. The idea is to have a consistent environment, but it doesn't prevent you from debugging or understanding the internals. Lastly, while there are differences between application containers (like Docker) and system containers (like LXC), they both leverage Linux kernel features to provide isolation. It's more about the use case and preference than one being "real" and the other not.
  - tryauuum 3y ago
    I'm not the original poster but with default config logs are worse with docker. Running `docker exec` to check the /var/log in a container is pointless, application writes to stdout. So you do `docker logs` And by default logs are stored in a json format in a single file per container, grepping `docker logs` feels slower than grepping a file. And the option to read logs for n last hours is incredibly slow -- I think it reads file from the beginning until it reaches the desired timestamp

notatoad 3y ago

no, not everything has to be docker. for example, none of wireguard, pihole, or unbound have to be docker. you are welcome to install all those things yourself. but the whole project here is to wrap up a bunch of other projects in a way that makes them easy to install and configure with minimal fuss. docker is perfect for that. if you want to be fussy and complain about the tools other people choose, then projects like this probably aren't much interest to you.

api 3y ago

If the Linux ecosystem could get its act together, standardize, and consolidate all the totally needless and pointless distribution fragmentation we could challenge this. Docker took off because there is no Linux. There are 50 different slightly incompatible OSes. So the best way to distribute software is to basically tar up the entire filesystem and distribute that. Dependency management has failed because there’s just too much sprawl. One illustrative example: OpenSSL has divergent naming and versioning schemes across different versions of distributions that use the same Debian package manager. So you either build your packages at least four or five times, Dockerize, or statically link OpenSSL. That’s just for dpkg based distros too! Then there is RPM, APK, and several others I can’t recall right now. BTW Windows has a bit of the same disease and being from one company has a lot less of an excuse. OS standardization and dependency standardization is very hard to get right, especially at scale. Apple macOS is the only OS you can ship software for without statically linking or bundling everything and be reasonably sure it will work… as long as you are not going back more than two or three versions.

amar0c 3y ago
I have feeling whole Docker (or application containers) took of when "non Linux people" (read: developers) tried to be sys admins too and failed. Best thing after sliced bread is apps/software packed in single GO binary. Runs everywhere, you only need to rsync/scp it to million of other places and it "acts" (usually) as normal Linux program/daemon
- api 3y ago
  That’s true but IMHO that’s an indictment if Linux not them. It’s 2023 and there is no reason system administration should be this hard unless you are doing very unusual things. The Go approach is just static linking. Rust often does the same though it’s not always the default like in Go, and you can do the same with C and C++ for all but libc with a bit of makefile hacking. Statically linking the world is the alternative approach to containers.
  - djbusby 3y ago

soneil 3y ago

It seems the canned deployment is the entire value-add here. It’s existing components that you can already deploy yourself if you prefer. I much prefer this over the old method of canned deployment where you ran a script and prayed it didn’t hose the host too badly.

byteknight 3y ago
You have absolutely hit the nail on the head. My view is this: There is a myriad of amazing toolage out there that the everyday person could greatly benefit from in their day-to-day life. A lot of that has a very high barrier to entry for technical knowledge. By simplifying this setup down to a simple Docker compose file I believe that I have allowed the lay person to play and experiment in the freedom of their own home with technology they may have otherwise been eyeing.
- babyeater9000 3y ago
  I completely agree and want to add that the readme file does a good job of letting me know what this thing is and why I should use it. I really appreciate when developers take the time to be inclusive by writing for a less technical audience. I will at least try it out and see what it is all about. I have been looking to add more services to my pihole.
  - byteknight 3y ago
    Let me know if you need help. My Twitter is on the repo.

spandextwins 3y ago

Docker is great, with docker volumes I can move things between different machines with ease. Do pretty much everything with docker compose these days. Also it doesn’t clutter up my base install, and it’s a lot lighter weight than a virtual machine.

Fnoord 3y ago

Hopefully the dependency is OCI compatible container instead of specifically Docker.