Hacker News new | ask | show | jobs
by byteknight 972 days 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.

3 comments

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)

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.

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

you can tail -f the container logs, which are in /var/lib/docker I think

I've recently come across a talk related to running openstack in kubernetes. Which sounded like a crazy idea, openstack needs to do all kinds of things not allowed by default for containers, e.g. create network interfaces and insert kernel modules. But people still did it for some reason -- on of them was that it's easier to find someone with k8 experience than with openstack one. And they liked the self-healing properties of k8.

I don't know what the bottom line is

docker logs -f containername docker exec -it containername /bin/sh

I’m by no means a docker evangelist, but it does work and it simplifies deployment and management quite a bit.

My personal biggest peeve is how Docker still doesn't play well with a VPN running on the host. It's incredibly annoying and an issue I frequently run into on my home setup.

It's crazy to me that people push it so much given this issue, aren't VPNs even more common in corporate settings, especially with remote work nowadays?

I find it easier to just spin up a full VM than deal with docker's sensitivities, and it feels a bit ridiculous to run a VM and then setup docker within it instead of just having appropriate VM images.

I think that has more to do with not understanding routing and firewalls. Vpns usually have something called a kill switch that force tunnels all traffic to avoid leaks.

While I can see it does at times make it more difficult to do certain things with the proper permissions, know how and set up there is nothing it cannot do.

So we're back to where we started, just tinker "a little" with the setup to try to make it work, exactly the issue Docker claimed to be aimed at solving.

I tried running a docker based setup for a year on my homeserver, thinking that using it for some time would help me get over my instinctive revulsion towards software that makes Docker the only way to use it, the way that forcing myself to use Python had helped me get over disdain for it back during the early days of the transition from 2 to 3. Didn't help at all, it was still a pita to rely on. Went back to proper installs, couldn't be happier.

How is that any different than any software? Configuration and trial and error is the name of the game no matter your stack...
> The speed of deployment cant be beat.

The sound of someone who hasn't used Nix.

What Nix provides in reproducibility and ease of deployment, it certainly makes up for with poor documentation and opaque error messages. I've been trying to learn it for the past few weeks in my spare time for a personal project, and I still struggle with basic things. I love the idea but they really need to invest in better docs, tutorials, and error messages.
You'd be correct.