Live data from Hacker News

Basically Everyone Should Be Avoiding Docker

lukesmith.xyz

91–100 of 103 posts

Re: Basically Everyone Should Be Avoiding Docker

#91
post #58

Why would you edit or delete files inside a running container? It’s ephemeral and supposed to be used stateless. You can attach volumes from host system if you need persistence.

At least one use case I've seen for Docker is to replicate the massively microservice oriented system. If your app is deployed across 200 different containers in prod, you're going to be testing it by spinning up the same basic containers with Docker in dev. That means a lot of incremental changes-- trivial stuff like adding transient logging or bypassing default flows-- inside the container as part of the developmen…

> Then you get into politics: you might need change XYZ for your feature, but you don't own that common image and have to rely on someone else to deploy it, so until then it's manual patches.

Or just make your own patched image of XYZ and use that as a base.

Re: Basically Everyone Should Be Avoiding Docker

#92
post #44
post #38

Containerization is amazingly great for scientific computing. I don’t ever want to go back to doing the make && make install dance and praying I’ve got my dependency ducks in a row.

The only real feature of Docker is the ability to keep unmaintained software running as the world around it moves forward. Academics could do the same thing by just distributing read only VMs as well.

Surely containers make it far easier to deploy/distribute maintained software as it makes it so much easier for people to switch to a newer version without needing to worry about incompatible versions of libraries etc. that can break something else. It can be used for pinning a specific older version of software for "reasons", but I think that's less common.

Consider people using a containerised NgINX webserver as a reverse proxy - it's so much easier to keep it up to date compared to using a distribution's version of NgINX.

Re: Basically Everyone Should Be Avoiding Docker

#95

Earlier quoted context omitted.

Kata containers is a nice compromise. Each container is run as a microvm

On the surface, Kata appears to be a variation of LXC/LXD.

LXC/LXD still shares the same host kernel. Kata runs a full instance of qemu including its own kernel.

FWIW, here's an slightly redacted example qemu instance launched by kata

/opt/kata-3.18.0/bin/qemu-system-x86_64 -name sandbox-FOO -uuid FOO -machine q35,accel=kvm,nvdimm=on -cpu host,pmu=off -qmp unix:fd=3,server=on,wait=off -m 2048M,slots=10,maxmem=1032958M -device pci-bridge,bus=pcie.0,id=pci-bridge-0,chassis_nr=1,shpc=off,addr=2,io-reserve=4k,mem-reserve=1m,pref64-reserve=1m -device virtio-serial-pci,disable-modern=false,id=serial0 -device virtconsole,chardev=charconsole0,id=console0 -chardev socket,id=charconsole0,path=/run/vc/vm/FOO/console.sock,server=on,wait=off -device nvdimm,id=nv0,memdev=mem0,unarmed=on -object memory-backend-file,id=mem0,mem-path=/opt/kata-3.18.0/share/kata-containers/kata-ubuntu-noble.image,size=268435456,readonly=on -device virtio-scsi-pci,id=scsi0,disable-modern=false -object rng-random,id=rng0,filename=/dev/urandom -device virtio-rng-pci,rng=rng0 -device vhost-vsock-pci,disable-modern=false,vhostfd=4,id=vsock-FOO,guest-cid=FOO -chardev socket,id=char-FOO,path=/run/vc/vm/FOO/vhost-fs.sock -device vhost-user-fs-pci,chardev=char-FOO,tag=kataShared,queue-size=1024 -rtc base=utc,driftfix=slew,clock=host -global kvm-pit.lost_tick_policy=discard -vga none -no-user-config -nodefaults -nographic --no-reboot -object memory-backend-file,id=dimm1,size=2048M,mem-path=/dev/shm,share=on -numa node,memdev=dimm1 -kernel /opt/kata-3.18.0/share/kata-containers/vmlinux-6.12.28-157 -append tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k cryptomgr.notests net.ifnames=0 pci=lastbus=0 root=/dev/pmem0p1 rootflags=dax,data=ordered,errors=remount-ro ro rootfstype=ext4 console=hvc0 console=hvc1 quiet systemd.show_status=false panic=1 nr_cpus=88 selinux=0 systemd.unit=kata-containers.target systemd.mask=systemd-networkd.service systemd.mask=systemd-networkd.socket scsi_mod.scan=none cgroup_no_v1=all systemd.unified_cgroup_hierarchy=1 -pidfile /run/vc/vm/FOO/pid -smp 1,cores=1,threads=1,sockets=88,maxcpus=88

Re: Basically Everyone Should Be Avoiding Docker

#97

Earlier quoted context omitted.

Kata containers is a nice compromise. Each container is run as a microvm

thanks! so they achieve the convenience of docker with the added security of full-blown kvm? trading some perf and resource-use? https://katacontainers.io/

Yes. Microvms are stripped down to the basic hardware needed (AWS' Firecracker for example), so they 'boot' really fast, in the tenths of seconds for my containers, but you do have the extra resource overhead of running a second kernel and the performance reduction of the VM context switches. That said, it's minor enough that I feel the security tradeoff is well worth it.

Re: Basically Everyone Should Be Avoiding Docker

#98
The limitations and gotchas of Docker containers are now well-known.

- Doesn't have the same resource isolation guarantees of quality type 1 hypervisors.

- Makes installation of cross-cutting concerns (monitoring and security agents) more difficult.

- Hand-waves away system administration.

- Challenges in assuring proper supply chain integrity.

But what it does is make infrastructure more accessible, repeatable, and standardized more simply than what came before, for better or worse. That's a giant dev UX win.

Them's called tradeoffs and choosing the right tool(s) in the toolbox for the particular purpose. Many of the concerns above can be mitigated with extra attention to detail.

Re: Basically Everyone Should Be Avoiding Docker

#99

The limitations and gotchas of Docker containers are now well-known. - Doesn't have the same resource isolation guarantees of quality type 1 hypervisors. - Makes installation of cross-cutting concerns (monitoring and security agents) more difficult. - Hand-waves away system administration. - Challenges in assuring proper supply chain integrity. But what it does is make infrastructure more accessible, repeatable, and…

Mkdir solves 90% of the problems docker did and the other 10% were solved with chroot.

Re: Basically Everyone Should Be Avoiding Docker

#100
post #83

Earlier quoted context omitted.

By default there is no assurance that any external resource you use is going to be the same every time. Whether that's another image, a package you install, etc. This is something you have to ensure yourself if you want it to be actually reproducible. Specifying a specific version or hash of an external resource can help get you there.

Thanks - that makes sense now. I was thinking of "reproducible" as in it does the same thing each time, but as you say, that can lead to different outcomes - usually updated or patched versions of base images etc.

[deleted]
Post reply on HN