71–80 of 203 posts
Earlier quoted context omitted.
For anyone who want a small image but with glibc, https://github.com/GoogleContainerTools/distroless is a good choice, especially if you are writing in static linked language e.g. Go and Rust.
For Python I'd also highly recommend Clear Linux for raw performance. It's not quite as easy to get started as with something like Ubuntu though.
Earlier quoted context omitted.
I've no idea why you wouldn't use Ubuntu which is only around 40mb, has a sane package manager and a standard glibc.
In particular since the base image is shared among all containers using it. It's 35 mb extra for n containers (n>>1).
Earlier quoted context omitted.
As far as I can tell, the recommended way to run several processes in an Ubuntu container is under supervisord. The default Ubuntu containers don't even include an init system.
Suoervisord is an awful thing to do under a container tbf. Any oom event and it will kill a random process. Not good in a container environment.
I have always been a bit surprised at the popularity of Alpine Linux for docker images. It’s awesome that the images are pretty small, but a wide variety of software has been shown to run noticeably slower on Alpine compared to other distributions, in part due to its usage of musl instead of glibc. I’d think that a few megabytes of disk isn’t as valuable as the extra cpu cycles.
Because it's tiny, I tend to default to Alpine and then move away from it where necessary. Rather than worrying about potential CPU performance requirements upfront - premature optimisation and all that.
> Versions of the Official Alpine Linux Docker images (since v3.3) contain a NULL password for the `root` user. This vulnerability appears to be the result of a regression introduced in December of 2015 . Emphasis mine. If this tells us something is that how inconsequential is that. A lot of software already runs with uid 0 inside a container. So, if you got an RCE in that software, you've got a container root anyway…
It depends how you have things set up, and what the container is actually doing, and what it's linked to. So it may not be as critical as root on the server, but it may also allow some damage that is more than irritating to happen.
I would call it serious, but not critical.
Earlier quoted context omitted.
> Ubuntu which is only around 40mb […] I just downloaded Ubuntu 18.04 and 19.04 and they are not 40MB: $ docker image ls | grep ubuntu ubuntu 19.04 f723e3b6f1bd 76.4MB ubuntu 18.04 d131e0fa2585 102.0MB ubuntu 16.04 a51debf7e1eb 116.0MB How do you get a 40MB Ubuntu Docker image? --- I followed @sofaofthedamned — https://blog.ubuntu.com/2018/07/09/minimal-ubuntu-released But I’m still confused, where are they getting 2…
https://blog.ubuntu.com/2018/07/09/minimal-ubuntu-released Apologies, it's actually 29mb.
Earlier quoted context omitted.
Unless you're behind a load balancer which terminates TLS and the traffic you deal with is purely http.
Please don't do this anymore. End-to-end encryption is extremely easy to set up and maintain. P2PE will absolutely lull you into a false sense of security.
Earlier quoted context omitted.
As far as I can tell, the recommended way to run several processes in an Ubuntu container is under supervisord. The default Ubuntu containers don't even include an init system.
Suoervisord is an awful thing to do under a container tbf. Any oom event and it will kill a random process. Not good in a container environment.
This is not the official Alpine image, it is Glider Labs one.
$ docker run -it alpine head -1 /etc/shadow
root:!::0:::::Earlier quoted context omitted.
Please don't do this anymore. End-to-end encryption is extremely easy to set up and maintain. P2PE will absolutely lull you into a false sense of security.
Eh, don't teach my about the systems I run. I'd love to run TLS end to end but in this one? Nah, not worth it.