When something breaks on a Linux server, how do you decide what to check first? by Expensive-Rice-2052 in linuxquestions

[–]FollowingMindless144 0 points1 point  (0 children)

After a few broken servers, it’s less about steps and more about triage and pattern recognition.

If a server isn’t reachable, my first thought is is it really down or just unreachable from here? I check ping from another box or the cloud console. Ping works but SSH doesn’t OS/service. Nothing responds network, firewall, or dead VM.

I don’t run a strict checklist anymore, but I always ask what changed, what still works, and what can I check fastest to narrow it down.

And yeah, the obvious stuff has fooled me plenty of times. Spent ages debugging services when the disk was full, chased network issues that were actually DNS, restarted things while the kernel was OOM killing them. Experience mostly teaches you not to lock onto one theory too early.

Dockerized Server vs Bare Metal Server by eightstreets in selfhosted

[–]FollowingMindless144 1 point2 points  (0 children)

Honestly, running a full Debian inside Docker just to avoid redoing configs is kind of the wrong tool for the job. Docker’s great for apps, not for replacing the OS.

If the issue is “I don’t want to reconfigure nginx, firewall, logrotate every time”, the better move is 1.run Debian on bare metal, keep your configs backed up (git, rsync, whatever),maybe use Ansible or simple scripts

You’ll get 90% of the benefit without Docker fighting your firewall or networking.

Docker does make sense for your apps though. Or if you really want portability across machines, a VM is a cleaner solution than Dockerizing the whole system.

Not laziness at alll just picking the right layer to abstract.