I'd be interested to know if Jess Frazelle, linked in the post still maintains her Dockerize-everything setup. I remember a few years ago her write-up on that stuff.
Would be good to hear her thoughts a few years on
Run More Stuff in Docker
231–240 of 293 posts
Re: Run More Stuff in Docker
#232Earlier quoted context omitted.
I think the base images that are commonly used are just as bad; likely some random snapshot of upstream repositories at arbitrary times. You can refer to the sha256 of base images to avoid things changing, but I've never seen anyone do that. (The advice is "never use 'latest' because that could change out from under you", but other tags are just as mutable, and so that isn't real advice. You can follow the advice and…
In production, the companies I work with certainly do rely on SHA256 checksums to specify the base images.
Do they just build their own images for open source things? I have never seen a dockerfile that does that.
Re: Run More Stuff in Docker
#233I get that doing APIs right is hard and that when you're trying to release a proprietary product having to worry about what libraries every system comes with may be a struggle and that if you're developing a webapp you may want everyone to have a consistent test environment regardless of what flavour of archlinux they're running but I really do NOT want to have to spend 2 hours downloading 300GiB of software updates when OpenSSL wets the bed and has a critical vulnerability. The nice thing about libraries and shared objects is that when I get an email saying: "Critical CVE found in something important that may actually affect you" I want to be able to run an update command which fetches a few libraries including the vulnerable one, reboot and be back in business.
I also don't really care for the "we have so much space now" argument. I certainly don't, I don't put in expensive 2TB SSDs in my laptop because I don't need them, and I don't want half of my 500GiB disk to be taken up by giant blobs of unoptimized docker images for the same reason that I don't want to run 10 copies of chrome at the same time to use a text editor, an email client, a web browser, a media player, a debugger, the thing I'm writing, three chat clients, and a partridge in a pear tree. I have extra space and extra processing power on my computer so that a: I can use it for the things I actually want to use it for and b: so that I have a snappy machine which can take an unexpected load (be it disk load or processing load) without problems.
Re: Run More Stuff in Docker
#234Earlier quoted context omitted.
Not really. Containerization has clear and obvious advantages over the traditional bare-metal approach.
For security purposes as used since the early days in mainframes and big iron UNIX, surely. As workaround for broken dependency management, not really.
Whats the alternative?
Re: Run More Stuff in Docker
#235TLDR: 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.
Re: Run More Stuff in Docker
#236Earlier quoted context omitted.
I had a conversation a couple months ago where some guy was telling me that I should run my personal website using Kubernetes. It’s a static website served with Nginx! I just about lost my mind trying to talk to this guy, and he kept trying to convince me to try Kubernetes for my personal website.
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.
Re: Run More Stuff in Docker
#237Earlier quoted context omitted.
Basic steps. Welcome to the long September of Docker. Whereas most folks who use it regularly know basic maintenance patterns, new users (myself included) must wade through inscrutable documentation or (worse) poorly written blogfarm posts in order to bootstrap up to a level of proficiency that passes interview smell tests.
Do you have any documentation (or blogs) on a higher level that you would recommend? I too have been using Docker for a while, and recently also for certain programs on my desktop (mainly firefox, github cli, azure cli, aws cli, terraform). I like to think I am somewhat proficient in using Docker correctly by now, but I am still discovering new tidbits of practical knowledge, tips and good practices every few weeks.…
Itamar Turner-Trauring's blog has a number of good articles on Docker best practices:
Re: Run More Stuff in Docker
#238Re: Run More Stuff in Docker
#239Earlier quoted context omitted.
What's the alternative to docker? And by that, I mean a solution that a team can reasonably use across Linux, Windows, and Mac. The simple reality is that, there is Docker and absolutely nothing else that comes close to working everywhere. Yes, it's not perfect but everything else is far less perfect. Static binaries are far too limited; most software requires lots of files spread all around the file system. I did a…
> What's the alternative to docker? And by that, I mean a solution that a team can reasonably use across Linux, Windows, and Mac. Virtual Machines. VirtualBox in combination with vagrant works reasonably well cross-platform.
Doesn't solve the same problem. You can use that to run docker of course.
Re: Run More Stuff in Docker
#240Earlier quoted context omitted.
For security purposes as used since the early days in mainframes and big iron UNIX, surely. As workaround for broken dependency management, not really.
Whats the alternative?
Fix the dependencies story in what concerns Ruby and Python.
Native binaries can easily do with static linking (fix glibc or replace it with proper libc like musl).
Other platforms are doing quite fine without containers.