Live data from Hacker News

Dissatisfied with Docker

robert.ocallahan.org

191–200 of 229 posts

Re: Dissatisfied with Docker

#191
post #37

I've been using Docker since 2015ish and the container start up / stop speed is really the only thing that bugs me. Everything else is fine for day to day usage IMO (on Windows and Linux at least) and very much worth the trade offs, but having to wait multiple seconds for your app to start is tedious since it plays such a heavy role in both development and even in production. Each second your app is not running is do…

The long startup time is somehow what keeps me from really liking Docker. In the end (if I understood correctly), it is supposed to be the go-to tool for serverless architecture. If my serverless function needs more then a second to startup, it's not usable for me. Even the hello-world container, which is only a few kB in size needs roughly a second to startup.

I'm working on a web service that takes 4-5 minutes to startup because of all the shit it has to warm-up. I'd be happy if it takes even a minute IF I could port it to a newer tech stack and can containerize it.

Re: Dissatisfied with Docker

#192

> In fact, a global system daemon should not be needed. Either users should be able to run their own daemons or container management should avoid having a daemon at all, by storing container state in a shared database. Absolutely love Podman. You can even define registries to work with docker hub, easily. https://podman.io

Yeah but no docker-compose support :/ dealbreaker for us. Theres an alpha podman-compose project but we couldn't get it running.

Both Podman and CRI-O support Pods, which can fill the same use case as docker-compose

Re: Dissatisfied with Docker

#193
post #2

I am currently on this train. Having used rkt in the past, I went to revisit it recently only to find this: https://www.cncf.io/blog/2019/08/16/cncf-archives-the-rkt-pr... I am so extremely disappointed in the CNCF as rkt (at the time, at least) seemed to be more "production ready" than Docker. Are there any real alternatives? Is the answer "find something else that uses containerd in a more friendly way?" Is the ans…

We're implementing CRI-O so we can use Docker and Kata Containers side by side for different workloads. We're hoping if things go well we can fully migrate off Docker after a few years of transition, but it's in early stages.

Re: Dissatisfied with Docker

#194
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…

Low efficiencies. When you work with 1000s of cores, a VM per app instances is literally millions of dollars annually of wasted CPU compared to using a container orchestrator.

Re: Dissatisfied with Docker

#195

Earlier quoted context omitted.

Okay so write your own crappy (excuse me, graceful and elegant) pile of shell scripts that nobody in your company but you understands? Sounds good to me. The second you leave, somebody is gonna rip that crap out and replace it with docker. All while mumbling under their breath...

Nonsense. Applications have a lot of complexity and therefore code around initialization. Adding a little script to deploy them is harmless. It's also the approach used by various FAANGs operating at a large scale.

Sounds kind of like a bug to me.

Re: Dissatisfied with Docker

#196
post #174

Earlier quoted context omitted.

Yeah Docker should get with the times and be assimilated into systemd like everything else

You could argue about many things bundled with systemd, but since containers are just souped-up processes, this is actually an use case that make sense for an init system.

I see them as souped-down virtual machines or the new vServers but with a decent interface. vServers (a bunch of hacks to separate users as if running different Linux instances) were pretty awful.

Re: Dissatisfied with Docker

#197

Earlier quoted context omitted.

Fargate is serverless because the compute is abstracted away completely. A lambda runtime is just a specialized container and they've added similar customizability to it lately with Layers/Runtime configuration.

I know that the definitions of these kinds of buzzwords can be fuzzy sometimes, but I have never heard a definition of serverless that would include Fargate. Here is what Cloudflare uses to describe serverless: > Serverless computing is a method of providing backend services on an as-used basis. Servers are still used, but a company that gets backend services from a serverless vendor is charged based on usage, not a…

How do you come to this conclusion from this pricing page? [0]

I might be missing something but that seems like serverless pricing. You might be thinking of the pricing scheme when Fargate first launched? Or maybe you’re thinking of ECS, which does in fact charge as you described.

[0] https://aws.amazon.com/fargate/pricing/

Re: Dissatisfied with Docker

#198

Earlier quoted context omitted.

those scripts are now built into docker with `docker system prune`

Little changed after I ran this script. My ~/Library/Containers/com.docker.docker/ is a whopping 64.01 GB. Running 'docker system prune' only recovers: Total reclaimed space: 1.986GB But when I check ~/Library/Containers/com.docker.docker/ for size after prune it still says 64.01 GB. Am I doing something wrong or is 'docker system prune' useless?

The 64GB is reserved space for the disk image. It doesn’t actually mean there is 64GB of data inside it.

See here: https://docs.docker.com/docker-for-mac/space/

Re: Dissatisfied with Docker

#199

Earlier quoted context omitted.

I know that the definitions of these kinds of buzzwords can be fuzzy sometimes, but I have never heard a definition of serverless that would include Fargate. Here is what Cloudflare uses to describe serverless: > Serverless computing is a method of providing backend services on an as-used basis. Servers are still used, but a company that gets backend services from a serverless vendor is charged based on usage, not a…

How do you come to this conclusion from this pricing page? [0] I might be missing something but that seems like serverless pricing. You might be thinking of the pricing scheme when Fargate first launched? Or maybe you’re thinking of ECS, which does in fact charge as you described. [0] https://aws.amazon.com/fargate/pricing/

Everything I am reading there screams container service and not serverless. Some Quotes:

> You pay for the amount of vCPU and memory resources consumed by your containerized applications.

How does vCPU fit into serverless architecture?

> Pricing is based on requested vCPU and memory resources for the Task.

Tasks being a collection of Containers. This is simply a container service like ECS or EKS.

> Pricing is calculated based on the vCPU and memory resources used from the time you start to download your container image (docker pull) until the Amazon ECS Task terminates.

This means you pay for the resources that were started for your containers until the container ends. Including all idle time and any overprovisioning you did because you have to tell it which instance type you want. Compare that to the pricing of Lambda where you only pay for the time your functions need to execute when they get called based on external events.

To bring this back to the beginning of the discussion: Complaining about docker because it is not a good tool for serverless architectures is not smart because it is not used in serverless architecture offerings. Fargate uses containers but it is not a serverless service. Fargate is a container service that tries to simplify setup of compute clusters in comparison to ECS, EKS and EC2.

Re: Dissatisfied with Docker

#200

A few things that I would add to that list: o No primitives to deal with secrets. o Terrible disk handling (aufs was just horrid, overlay2 I think misses the point. device mapper is just, silly) o poor speed when downloading and uncompressing images. Of all of them, the most serious is the lack of secrets handling. Basically you have to use environment variables. Yes, you can use docker compose and stuff appears, but…

> the most serious is the lack of secrets handling. Basically you have to use environment variables.

That's how I always handle my secrets. (12 factor app)

Am I missing a better way?

Post reply on HN