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

Run More Stuff in Docker

jonathan.bergknoff.com

Post reply on HN
Print view View original

271–280 of 293 posts

Re: Run More Stuff in Docker

#271

Post by u801e »

jillesvangurp wrote: post #265
u801e wrote: post #248

Earlier quoted context omitted.

What problem does Docker solve that using a VM cannot solve?

The infrastructure for creating and sharing e.g. virtual box images does not exist. With docker I can run just about any server product you can name with a single command line invocation. Those commands don't exist for vmware, virtual box or other common virtual machine. That infrastructure simply does not exist.

> The infrastructure for creating and sharing e.g. virtual box images does not exist.

vagrant [1] provides this feature based on my understanding.

[1] https://www.vagrantup.com/docs/cli/cloud

Re: Run More Stuff in Docker

#272

Post by cmckn »

RedShift1 wrote: post #258
cmckn wrote: post #250

Earlier quoted context omitted.

RAM is the same situation as disk for me — I have plenty to waste. Again, not advocating Chrome in a container, I don’t even run Chrome outside of a container. I just think it’s odd to get hung up on these sorts of resource requirements given the state of computing.

You may have plenty of resources but there are many that have to "make due" with 8 GB, 4 GB or even less RAM.

Totally fair, but I think the Venn diagram of folks that use Docker and folks that have 4GB of RAM is pretty slim. If the resources are that limited, Docker might not be the best choice for running anything.

Related: Chrome on 4GB of RAM sounds painful. Thoughts and prayers to those folks.

Re: Run More Stuff in Docker

#273

Post by AtlasBarfed »

bayindirh wrote: post #264
piaste wrote: post #260

Earlier quoted context omitted.

> However a nice SSD with a respectable TBW value is not still cheap. a 860 Pro is almost twice the cost of a 860 Evo. Pro provides twice the TBW value. TBW is almost never a concern for desktop users. The Evo has 600 TBW endurance per TB of storage, that would be a full disk rewrite every day for two years. You will never download enough Docker images for personal use to burn out your 860 Evo before you would have r…

> TBW is almost never a concern for desktop users. You're right however, most of the people who'll use this kind of setup is not ordinary desktop users. My desktop has 4 disks (2 SSDs and 2 HDDs). My write rate for "Home" SSD is 3TB/yr. To keep the value low, I've moved VMs, big downloads and other stuff to one of the HDDs. System is on another SSD and it's cumulative write was about 3TB in 8 years but, I moved logs…

So, are these the numbers?

TBW is 600 TB, but you do 3TB/year across four disks, and I'll be generous and say you do .75/SSD/year.

so in 750 years you'll hit the rated TBW?

If you did a full 3TB/year on the one SSD, you hit it in 200 years?

Re: Run More Stuff in Docker

#274

Post by sverhagen »

Kwpolska wrote: post #249
sverhagen wrote: post #163

Earlier quoted context omitted.

I fully agree with the original premise (to run more stuff in Docker). But if I maintain two tools, both using Docker, let's say they're both built in Python, they'll both be in their own Git repository, and their build pipelines will come up with independent Docker images for whomever wants to use those tools, and it seems like frivolous maintenance, if not an anti-pattern, to make sure that these tools are always u…

Both of your Python projects will likely have `python:latest` (or such) as their base image. Sure, they will diverge after that (with further layers for dependencies and your code), but at least the base system will be shared.

Even if they used python:latest (as if that is the only flavor), they're only "latest" when I do my build. So, now I have to coordinate builds and releases. Unlikely to happen, and, again, an anti-pattern.

Re: Run More Stuff in Docker

#275

Post by bayindirh »

AtlasBarfed wrote: post #273
bayindirh wrote: post #264

Earlier quoted context omitted.

> TBW is almost never a concern for desktop users. You're right however, most of the people who'll use this kind of setup is not ordinary desktop users. My desktop has 4 disks (2 SSDs and 2 HDDs). My write rate for "Home" SSD is 3TB/yr. To keep the value low, I've moved VMs, big downloads and other stuff to one of the HDDs. System is on another SSD and it's cumulative write was about 3TB in 8 years but, I moved logs…

So, are these the numbers? TBW is 600 TB, but you do 3TB/year across four disks, and I'll be generous and say you do .75/SSD/year. so in 750 years you'll hit the rated TBW? If you did a full 3TB/year on the one SSD, you hit it in 200 years?

No, 600TBW is for a 1TB Evo. For a Pro, it would be 1.200TBW.

Unfortunately, neither of my disks are that big. Home is on a 256GB SSD which boils down to 300TBW. System SSD is a bit older 120GB OCz Vertex 3. This model doesn't have a TBW rating.

As a result, if I don't do anything heavy, it'd last for a century in the best case. I'm not sure about OCz though. It reports 100% life remaining but it's from the skunkworks era of the SSDs so, I can't be sure for anything.

The numbers climb very fast when you start to develop stuff and enter compile -> test -> debug cycle. So, I'd rather have that endurance and use it while developing software rather than eating it while doing daily stuff.

Re: Run More Stuff in Docker

#276

Post by lenkite »

My Macbook fans rev up to the max after starting the Docker VM. And battery life falls like water running downhill.

No, thanks - I shudder at the existential nightmare at being forced to do all development via Docker. Use Docker for deployment, exit the VM and get back to your work.

Re: Run More Stuff in Docker

#277

Post by jbboehr »

klodolph wrote: post #236
indemnity wrote: post #150

Earlier quoted context omitted.

Why even run nginx? My personal website is served out of a private S3 bucket, with CloudFront sitting in front of it. As a former sysadmin, the less actual admin I need to do the better.

S3 has no https and unsatisfactory performance. My website used to be in an S3 bucket, I was unhappy with it.

If you run it behind CloudFront it does support HTTPS.

Re: Run More Stuff in Docker

#278

Post by pjmlp »

piaste wrote: post #261
XorNot wrote: post #170

Earlier quoted context omitted.

I guess that makes me fossilizing, because this is the direction I think we should really be heading. When I stare at docker long enough I wind up at "why couldn't this be a static binary" or "this would be easier to secure if it was it's own VM".

A Docker container is a lot simpler to maintain than a VM, for just about any task you care to mention. A static binary is much better than a Docker container, I agree. Unfortunately a lot of useful apps can't or won't ship as a static binary (Java, Python, PHP apps), and Docker makes them behave much more like a static binary.

Java can certainly be shipped as single static binary, AOT compilers exist since around 2000.

Same applies to Python bundlers like py2exe.

Re: Run More Stuff in Docker

#279

Post by plg- »

sclevine wrote: post #263

Many comments here point out how difficult it is to manage a separate dependency stack for each container when you use Dockerfiles to build them. This problem is just as difficult, time-intensive, and security-critical for microservice apps running on K8s as it is for CLI tools and graphical apps. Worth pointing out that there is an incubating CNCF project that tries to solve this problem by forgoing Dockerfiles enti…

I hadn't heard of Buildpacks before, sounds very interesting.

In particular the out of order layer replacement. I'm interested in switching to Buildpack for the images I maintain for my home cluster. Would make upgrading my base image so much simpler compared to rebuilding all the other images! I read a bunch of docs/articles since reading your comment yesterday but couldn't find any mention of this, or better yet an example. Are there some docs I missed? (I didn't look into the spec.)

Re: Run More Stuff in Docker

#280

Post by zachrose »

dajonker wrote: post #153
remexre wrote: post #143

Earlier quoted context omitted.

I don't know the specific issue, but RH's been trying to push Podman fairly hard...

Fedora is using cgroups v2 by default since last year. This version of cgroups was not supported by docker until a couple of weeks ago. So as a Fedora user you could either use podman or modify your installation to use cgroups v1 instead.

Thank you, I may have misspoke but this is what I was referring to.
Post reply on HN