4 ms·
If the goal of the test is to debug a sad linux server, containers are going to severely limit what ways the server can be sad in, isn't it?
by paulfurtado 4y ago
If the goal of the test is to debug a sad linux server, containers are going to severely limit what ways the server can be sad in, isn't it?
- BossingAround 4y agoCan you give me an example of some of the severe limitations you're mentioning?
- nijave 4y agoI don't think the DNS exercise would behave the same although that probably depends on how the container was setup. Docker usually controls /etc/resolv.conf. Another exercise is "try to figure out if you're in a container or VM so that'd definitely be different"
- BossingAround 4y agoThe question is not if the exercises would behave identically, but if you can test the objective in a container. For example, you can totally test, screw up, and fix DNS in a container. I would think that "try to figure out if you're in a container or VM" would be exactly the same as it is right now.
- mmh0000 4y agoI can give you a bunch of things that can't be simulated in a container: * Boot problems, such as: GRUB config/install errors, kernel parameters, init startup errors, blocking processes * Many network scenarios, such as: PXE issues, multipath, load-balacing, anything requiring configuring network interface settings, firewall configuration. * Resetting an unknown root password * Booting directly to bash * Filesystem mounts through fstab or systemd mounts There's probably more I could think of, but I think that's a good list.