Earlier quoted context omitted.
pro tip: you can use lxc/lxd to run VMs under the same infrastructure. I belive it is something as easy as lxc launch -vm ubuntu/20.04 myvm
What VM software does this make use of? KVM?
Yes. LXD uses Qemu/KVM for VMs.
LXC vs. Docker
121–130 of 147 posts
Re: LXC vs. Docker
#122Apples to oranges. LXC can be directly compared with a small, and quite insignificant, part of Docker: container runtime. Docker became popular not because it can run containers, many tools before Docker could do that (LXC included). Docker became popular because it allows one to build, publish and then consume containers.
I would say docker's killer feature is the Dockerfile. It makes it understandable, reproducible and available to a broad range of people. At least they mentioned it in their apple:oranges comparison. there's also the global namespace thing. "FROM ubuntu:18.04" is pretty powerful. I run a proxmox server with LXC but if I could use a dockerfile or equivalent, my containers would be much much more organized. I wouldn't…
Hashicorp Packer is a nice way to declare container builds as code. The containers are reproducible as far as I can tell. The biggest advantage with Packer though, is that you can create several different types (dozens) of container and VM images (docker/OCI, LXC/LXD, qcow2, AWS, Google cloud, ...) from a single declaration.
Re: LXC vs. Docker
#123Earlier quoted context omitted.
this feels both clever and stupid at the same time - not you but the software games you have to play.
theres a lot of wasted effort in the games we play to make software work in prod.
From being a production engineer for many years I can only agree: some of the brightest people of our generation spend most of their time compensating for the poor design choices of others. Not sure if this is better or worse than advertising.
Re: LXC vs. Docker
#124Earlier quoted context omitted.
It's an annoying that you can only make snapshots on a stopped container. With VMs it works in a running VM.
Also can't do live migrations or backups and moving storage around is a headache. We've pretty much stopped using LXC containers in Proxmox because of all the little issues.
Dumb question, but what have you replaced it with? I’ve been working on setting up Proxmox/LXC on a box at home as we speak — but if it’s not worth the headache I’ll stick to VMs.
Re: LXC vs. Docker
#125At the end the two are different.. why comparing the in the first place?
“ LXC, is a serious contender to virtual machines. So, if you are developing a Linux application or working with servers, and need a real Linux environment, LXC should be your go-to.
Docker is a complete solution to distribute applications and is particularly loved by developers. Docker solved the local developer configuration tantrum and became a key component in the CI/CD pipeline because it provides isolation between the workload and reproducible environment.”
Re: LXC vs. Docker
#126At the end the two are different.. why comparing the in the first place? “ LXC, is a serious contender to virtual machines. So, if you are developing a Linux application or working with servers, and need a real Linux environment, LXC should be your go-to. Docker is a complete solution to distribute applications and is particularly loved by developers. Docker solved the local developer configuration tantrum and became…
What are the fundamental differences?
Re: LXC vs. Docker
#127Earlier quoted context omitted.
Running the same script every time doesn't necessarily guarantee the same result. Lots of docker build scripts have the equivalent of date > file.txt or curl https://www.random.org/integers/?num=1&min=1&max=1000&col=1&base=10&format=plain&rnd=new > file.txt Buried deep somewhere in the code. But yeah I don't see any reason why you couldn't theoretically make a reproducible build with Docker.
Would that not be cached? It would not actually run that date command again, right? unless you change that date line itself, in the Dockerfile.
Or if you change anything that comes before that line.
Re: LXC vs. Docker
#128At the end the two are different.. why comparing the in the first place? “ LXC, is a serious contender to virtual machines. So, if you are developing a Linux application or working with servers, and need a real Linux environment, LXC should be your go-to. Docker is a complete solution to distribute applications and is particularly loved by developers. Docker solved the local developer configuration tantrum and became…
What are the fundamental differences?
Linux control groups vs a runtime
Re: LXC vs. Docker
#129Earlier quoted context omitted.
Also can't do live migrations or backups and moving storage around is a headache. We've pretty much stopped using LXC containers in Proxmox because of all the little issues.
Dumb question, but what have you replaced it with? I’ve been working on setting up Proxmox/LXC on a box at home as we speak — but if it’s not worth the headache I’ll stick to VMs.
I'm not who you asked but I use them for different purposes. There are some quirks here and there. Never anything that won't run, but it could potentially add extra troubleshooting.
Things that got me recently, just off the top of my head:
- htop sees memory usage incorrectly
- Docker tries to use overlay2 on ZFS which fails (I think, I needed to create and mount an ext4 volume for reasons)
- Hashicorp Vault needed disable_mlock because I believe LXC blocks the syscall.
On the other hand, I like my Samba file server in a container though, because it is much easier to share storage from the host into LXC than a VM.
LXC and VMs both have pros and cons.
Re: LXC vs. Docker
#130LXD (Canonical's daemon/API front end to lxc containers) is great -- as long as you aren't using the god awful snap package they insist on. The snap is probably fine for single dev machines, but it has zero place in anything production. This is because canonical insists on auto-updating and refreshing the snap at random intervals, even when you pin to a specific version channel. Three times I had to manually recover…
Canonical always backs the wrong horse. Unity, Snap, Mir, Upstart, etc. etc.