Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dissatisfied with Docker

robert.ocallahan.org

Post reply on HN
Print view View original

61–70 of 229 posts

Re: Dissatisfied with Docker

#61

Post by lojack »

charles_f wrote: post #24
djsumdog wrote: post #20

Earlier quoted context omitted.

I hate how the Docker team called it native. Docker for Mac/Windows still run in a hypervisor because so much of Docker is specific to Linux/cgroups. There was a FreeBSD port of Docker that attempted to implement a lot of the Docker API using zfs+jails but it went unmaintained and was never ported to the newer modular Docker implementation. You're always going to get that performance hit with the hypervisor layer the…

Docker for Windows is coming to use the WSL2, beta is already out.

WSL 2 itself uses a hypervisor though, so this is sort of a moot point.

Re: Dissatisfied with Docker

#62

Post by syrusakbary »

ahnick wrote: post #60
syrusakbary wrote: post #49

Earlier quoted context omitted.

Wasmer is an application-based container while Docker is a OS-based container. Because of that some of the things that you posted are a bit hard to compare. We believe that by having a VM (based on a industry adopted specification such as WebAssembly) we can control much more granularly both execution (CPU, memory) and the runtime interoperability with the system (networking, file system, ...), solving most of the is…

What's the selling point of Wasmer over the JVM or BEAM?

JVM requires almost all your stack to be rewritten for it.

Because WebAssembly permits languages to be usable in the web, almost any other language (C, C++, Rust, Go and even Java) is now working to be compiled to WebAssembly.

Therefore you don’t need to adapt your stack to run it in Wasmer :)

Re: Dissatisfied with Docker

#63

Post by gravypod »

syrusakbary wrote: post #49
gravypod wrote: post #39

Earlier quoted context omitted.

Is there a feature by feature comparison of wasmer to docker? I don't think Wasmer, while interesting, is a container system. It looks more like a bytecode vm. Things I use and love from docker that to me feel "container"-y: 1. OSs as a library (FROM alpine:3.9) 2. Network namespaces so all applications think they are running on a machine with port 80 available 3. Service discovery through DNS 4. CPU and memory share…

Wasmer is an application-based container while Docker is a OS-based container. Because of that some of the things that you posted are a bit hard to compare. We believe that by having a VM (based on a industry adopted specification such as WebAssembly) we can control much more granularly both execution (CPU, memory) and the runtime interoperability with the system (networking, file system, ...), solving most of the is…

I don't think we're using container system similarly. I'm using the term "Container" in the way Docker describes:

>A container is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another. A Docker container image is a lightweight, standalone, executable package of software that includes everything needed to run an application: code, runtime, system tools, system libraries and settings.[0]

If you cannot package system tooling, system libraries, and configuration with your software I don't think what you're building is a container system. If you also loose the sorcery benefits docker's network namespaces and volume drivers you're loosing a lot of functionality that docker provides.

I wouldn't call the JVM, RVM, V8/SpiderMonkey, cPython, and any other language VM a "container system" even though many of them allow you to set up platform isolation, restriction, and sandboxing.

I use "container" to reference a technology that allows me to build, package, ship, and orchestrate the execution of these units.

[0] - https://www.docker.com/resources/what-container

Re: Dissatisfied with Docker

#64

Post by techntoke »

syrusakbary wrote: post #4

The article is completely on point. Because of all the reasons exposed there (and a few more) I started Wasmer, a new container system based on WebAssembly - https://wasmer.io/ Here are some advantages of Wasmer vs Docker: * Much faster startup time * Smaller containers * OS independent containers (they can run in Linux, macOS and Windows) * Chipset independent containers (so they can run anywhere: x86_64, Aarch64/AR…

Some things to note:

- Wasmer isn't available as a package on most distros from what I can tell. Instead they want you to curl a script directly to your shell, which is bad practice.

- They do not have a reproducible benchmark or a test suite to prove that it is actually faster than Docker and it is likely you can't even compare them. The Docker daemon and containers generally have very fast startup times.

- Docker containers are OS independent as well, but rely on Linux kernel features so they run more native on Linux. This isn't a negative. Most microservice apps are Linux-based.

- Adding abstractions for the chipset has always been slower than optimizing and compiling for multiple architectures. This is like someone saying Java is better because it provides a VM that translates everything. Instead Java has a reputation for being clunky and slow because of it. Well built apps and pipelines can easily be compiled for multiple architectures. See Alpine Linux for example.

Re: Dissatisfied with Docker

#65

Post by lacampbell »

bob1029 wrote: post #44

What's wrong with booting a VM off a standardized base image (e.g. an AMI), and then applying simple deployment scripts for each application you need to run? You could probably replicate 90% of the justification for using docker with some basic scripting. git clone https://github.com/myprofile/my-cool-app cd my-cool-app chmod +x deploy.sh ./deploy.sh That's it. The above script would be responsible for getting your a…

This is what I ended up doing. Don't laugh, but I spent about two weekends furiously learning docker for a side project, only to replace it with a shell script of about 100 lines.

I'm sure containers have valid use cases for larger teams, but for one person I didn't see the point at all - especially as I use the same OS for dev and production.

Re: Dissatisfied with Docker

#66

Post by jordanthoms »

bob1029 wrote: post #44

What's wrong with booting a VM off a standardized base image (e.g. an AMI), and then applying simple deployment scripts for each application you need to run? You could probably replicate 90% of the justification for using docker with some basic scripting. git clone https://github.com/myprofile/my-cool-app cd my-cool-app chmod +x deploy.sh ./deploy.sh That's it. The above script would be responsible for getting your a…

That approach works, but if you are going to go into production with it you might need to support:

- Rollbacks

- Automatic deployment of new releases from CI, rolling releases

- Healthchecks, detecting if/when the server exits and making sure that VM gets killed

- Canary deployments

- Autoscaling (could use an autoscaling instance group for it, but what if you need to scale based on other metrics)

- Log aggregation

- Monitoring

- Service discovery, load balancing between services

- Service mesh

- Fast startup of instances (starting a fresh VM and waiting for it to setup everything from scratch could take ~3-4 minutes, docker is in the ~30s or less range).

- Bin-packing (run a high-cpu low-memory workload colocated with a low-cpu high-memory workload for maximum efficiency)

etc, etc, all of which you get either out of the box or without a huge amount of work if you adopt something like Google Kubernetes Engine (which takes a few clicks to spin up a cluster).

If you don't need any of that stuff and don't want to learn Kubernetes, it's totally justifiable to go that way, but personally I would take Google Kubernetes Engine over something like that any time. There's some up-front cost learning how it works which then pays off very quickly.

Re: Dissatisfied with Docker

#68

Post by judge2020 »

neckardt wrote: post #56

I'm surprised nobody is mentioning LXC[1]. I'm by no means a containers expert, but they claim to be more secure since they default to running as non-root. Unlike docker, I had no trouble installing LXC with apt, while with docker I often got an outdated version. I'm now using LXC for all of my basic container applications (self hosting a wiki and a few other sites). [1]: https://linuxcontainers.org/

Docker isn't up to date on the official Ubuntu (and debian too?) repos for some odd reason. A better way is either snap (snapcraft) or adding docker's own apt repository.

Re: Dissatisfied with Docker

#69

Post by techntoke »

bob1029 wrote: post #44

What's wrong with booting a VM off a standardized base image (e.g. an AMI), and then applying simple deployment scripts for each application you need to run? You could probably replicate 90% of the justification for using docker with some basic scripting. git clone https://github.com/myprofile/my-cool-app cd my-cool-app chmod +x deploy.sh ./deploy.sh That's it. The above script would be responsible for getting your a…

This is way slower than Docker. Rootless containers are already a thing. If you still want VMs then see Kata Containers. Containers have a lot of benefits, the major one for me is reproducibility and application sandboxing. There is a reason containers exist and that every large cloud platform has adopted them, including Microsoft adding support in Windows.

Re: Dissatisfied with Docker

#70

Post by gravypod »

syrusakbary wrote: post #62
ahnick wrote: post #60

Earlier quoted context omitted.

What's the selling point of Wasmer over the JVM or BEAM?

JVM requires almost all your stack to be rewritten for it. Because WebAssembly permits languages to be usable in the web, almost any other language (C, C++, Rust, Go and even Java) is now working to be compiled to WebAssembly. Therefore you don’t need to adapt your stack to run it in Wasmer :)

> "JVM requires almost all your stack to be rewritten for it."

This applies no more to the JVM than to Wasmer. There exists WASM to JVM bytecode transpilers [0].

[0] - https://github.com/cretz/asmble

Post reply on HN