Docker is ok. But please do not over use it.
It's not really portable, it only runs decently on Linux, on other platforms it's a kludge.
Run More Stuff in Docker
281–290 of 293 posts
Re: Run More Stuff in Docker
#282Earlier quoted context omitted.
Except Mac apps don’t each ship a libSystem.
Because unlike Linux they don't have to, since MacOS actually defines the concept of a stable base system that can be targeted by applications. Docker exists in part because the Linux world has no such concept.
Thats the point here. The two aren't similar at all.
MacOS apps contain all the app. Mac Apps leverage all of the OS functionality they can. They are strongly tied to MacOS and rely on it for most functionality. When I upgraded to Big Sur, the Mac Apps that run on my computer adapt to the changed OS libraries and often present differently.
Docker apps contain their own complete environment. They are deliberately engineered to disassociate from the base OS.
Electron is a sort of middle ground largely ignoring many system libraries, but using others.
The only thing Docker has in Common with Mac Apps is the fact that they keep associated files bundled together.
Re: Run More Stuff in Docker
#283Many 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…
Nevermind, I realized that rebase is exactly that. I had misunderstood the docs.
Re: Run More Stuff in Docker
#284Earlier quoted context omitted.
> and to most virtualbox machines (including the hidden one running the fake docker linux host on docker-for-mac) docker-for-mac does not use virtualbox.
Docker For Mac does use a virtual machine to run the Docker machine, though. It's complicated to access the automatically generated mount point on Docker's mac when you create a virtual folder but don't bind it anywhere.
But does Docker for Mac give unlimited access to the host’s usb bus like GP claims? I don’t see any evidence that it’s true, and the mistaken claim that d4m uses virtualbox increases my skepticism.
Re: Run More Stuff in Docker
#285Earlier quoted context omitted.
Docker For Mac does use a virtual machine to run the Docker machine, though. It's complicated to access the automatically generated mount point on Docker's mac when you create a virtual folder but don't bind it anywhere.
But does Docker for Mac give unlimited access to the host’s usb bus like GP claims? I don’t see any evidence that it’s true, and the mistaken claim that d4m uses virtualbox increases my skepticism.
I have no knowledge on that matter, I’m sorry
Re: Run More Stuff in Docker
#286Earlier quoted context omitted.
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.
Anything “supports HTTPS” if you count putting an HTTPS proxy in front of it. In other words, S3 does not support HTTPS, but you can work around that limitation by combining it with other services.
My personal website is low-traffic, it’s not going to be very hot in any CDN caches. Based on my experiences with S3 performance, adding another layer of cache misses in front of it is probably just going to slow things down.
Re: Run More Stuff in Docker
#287I recall someone building a docker image specifically for the purpose of setting up a development environment.
A large amount of inter-connected projects for a SaaS-like service, all mounted inside the docker container, with some very specific libraries pre-compiled in the docker image, that used to take 30+ minutes to build.
And now they're just in a docker image, that will work on linux and mac and I guess windows too.
Nice idea in theory.
Re: Run More Stuff in Docker
#288TLDR: 1. You already have that on Linux. 2. Make your builds portable. If you are running mainstream Linux(Debian-based/Arch-based, probably other), most of the Docker profits can be achieved with already installed and configured systemd and your distro's package manager. Sandboxed? systemd. Simple, uniform interface? Your distro has packages, and most likely services that can and should be sandboxed already run in s…
The easy option always wins in the end. You could do all that, or you could write one Dockerfile and not care. Obviously this is not the goal of Docker, but it fulfills a need that many big companies have and will fund its continued development, while also kind of fitting in as a general reproducible environment service. It's not ideal, but the ideal version isn't as easy.
But then you have to write aliases for mounts and etc. meanwhile repositories come without any additional costs, and sysyemd units aren't more complex than dockerfiles, and usually already written by package maintainers. You are just one `apt install $packagename` away.
Re: Run More Stuff in Docker
#289Earlier quoted context omitted.
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…
Nevermind, I realized that rebase is exactly that. I had misunderstood the docs.
Don't hesitate to reach out on Slack if you have more questions: https://slack.buildpacks.io
A few tips on rebase:
(1) If you want to rebase without pulling the images first (so there's no appreciable data transfer in either direction), you currently have to pass `--publish`.
(2) If you need to rebase against your own copy of the runtime base image (e.g., because you relocated the upstream copy to your own registry), you can pass `--run-image `.
Re: Run More Stuff in Docker
#290Earlier 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…
As a Ruby, Node or Python language user, you may want to try rbenv, nodenv or pyenv respectively.
Or the ASDF version manager that covers all of them, and much more.