fatherlinnux

18 ms·

61.
by fatherlinnux 11y ago
I feel you
62.
by fatherlinnux 11y ago
Which is why I like your rhel7-update-date methodology to solve this....
63.
by fatherlinnux 11y ago
Also, though I love Alpine, it uses Musl instead of Glibc. Some giant amount of the supply chain uses Glibc. You could convert everything to Musl, but then you would probably have performance hits on all kinds of things, so you would be tra
64.
by fatherlinnux 11y ago
Careful, it's not the base image size. It's the environment size. If you don't put enough in your base image, you will have bloat everywhere. If you put too much, it will cause slow start (caching takes a while). It's a
65.
by fatherlinnux 11y ago
That solves part of the problem. The problem with base images, are they are the root - I call them Adam and Eve images. They do not solve all of the supply chain problems. Layered images such as Apache and Nginx still may be maintained by o
66.
by fatherlinnux 11y ago
Again, this is recursion, if the upstream maintainer for the Apache and Nginx images is doing their job, the "yum update" should do nothing. Though, I agree, it's very important to highlight that too much branching can cause
67.
by fatherlinnux 11y ago
Agreed, that's why I published this: http://rhelblog.redhat.com/2016/02/24/container-tidbits-can-...
68.
by fatherlinnux 11y ago
The large yum update is a symptom, not the problem: 1. The upstream base image maintainers aren’t doing their job of keeping the image up to date, so it is huge. If the upstream maintainer had this base image updated, there would be no upda
69.
by fatherlinnux 11y ago
Yeah, the problem is getting them from each process in the container, then get them to the centralized logging. It can be done either way though. Especially with the syslog driver in Docker...
70.
by fatherlinnux 11y ago
I think they mean this: https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zomb...
71.
by fatherlinnux 11y ago
Agreed, I was trying to help a friend implement the Actor model inside a container, and if you want to put every process in a different container, you basically have to talk tot he Kubernetes Daemon to do it (not fun). I am fine with servic
72.
by fatherlinnux 11y ago
Or systemd /me ducks and runs :-)
73.
Container Tidbits: Can Good Supply Chain Hygiene Mitigate Base Image Sizes?(rhelblog.redhat.com)
4 points by fatherlinnux 11y ago|0 comments
74.
docker pull myfinger(crunchtools.com)
2 points by fatherlinnux 11y ago|0 comments
75.
by fatherlinnux 11y ago
I just wish there was a -v during build and that -v supported any arbitrary mount like fstab. It would be nice if -v mapped directly to the mount namespace so could do things like: iscsi:/data /data nfs://10.0.0.1:/
76.
by fatherlinnux 11y ago
Have fun with that. The Linux User Space will not work on a BSD kernel, so you would be forced into a BSD user space. Now you are back at Square Zero. There is nothing wrong with the BSD, but it's just another different thing to learn
77.
by fatherlinnux 11y ago
Red Hat does not use a FUSE based file system. It's LVM Thin-p based....
78.
by fatherlinnux 11y ago
Just add registry server, that's where the magic is.
79.
by fatherlinnux 11y ago
Yeah, but the layered images and copy on write nature of Docker has not and IMHO, that is what is novel about this new wave of containers.
80.
by fatherlinnux 12y ago
OpenStack????
81.
by fatherlinnux 12y ago
The current version of OpenShift (2.X) is essentially Linux container based (selinux, cgroups, kernel namespaces). OpenShift 2.X has been running in production for years now (openshift.com). The reason something like Docker wasn't use
82.
by fatherlinnux 12y ago
Well I, for one, want to thank you for all of this work. I have done some benchmarks in the past, and they take a ton of work!!! It's easy to sit back and armchair quarterback about performance, but it's WAY more work to sit down