Hacker News Reader

fatherlinnuxon Goodbye Docker and Thanks for all the Fish

The OCI standards make it so that it doesn't matter if you switch or not. Your images will work anywhere with any tool (aka Cloud Providers, Kubernetes, Podman, Buildah, etc.) Everybody has OCI compliant tools, even Docker - Docker founded the OCI.

fatherlinnuxon Goodbye Docker and Thanks for all the Fish

1. GitHub was struggling badly. They had lay-offs, etc.

2. Google still makes the lion's share of it's money from search/ads. Google Compute is struggling and being subsidized by search/ads.

IMHO, Docker's only exit strategy is to sell. They don't have enough time left to grow an organic business. Silicon Valley money always wants paid back, sooner rather than later.

The layoffs and new CFO at Docker, IMHO, are all about cleaning up the finances so that a sale is possible at a good price.

Their last round of investment barely averted a down round. The value bump was minimal and the investors are mostly from a bank in Brazil that likely doesn't understand exactly what they bought into (a lot of uneducated money out there right now because there is no place to put it). None of the original investors participated which shows they don't believe in the company anymore.

Their most valuable asset is Windows support. Hence, the most likely aquirerer would be Microsoft. I'll bet a paycheck they sell for somewhere between 1.5B and 2.5B. Keep this thread for posterity :-)

It's painfully obvious to anybody that has been in this game for a while...

(opinions and analysis my own)

fatherlinnuxon Goodbye Docker and Thanks for all the Fish

Exactly, when will Silicon valley investors understand that Open Source:

1. Doesn't grow revenue at the speeds they want returns 2. Isn't "free marketing" (dear God I have seen this one too many times, CTOs even write it out in blogs sometimes) 3. Only really makes sense when you get out more than you put in, aka is community drive . Community driven open source is really the only profitable open source.

fatherlinnuxon Podman and Buildah available in RHEL 7.6 and RHEL 8 Beta

We get this question all the time, and I totally understand the frustration. In a nutshell, here's the breakdown. I will highlight this in blog entries as RHEL8 comes out and emphasizes podman, buildah and skopeo, so you will see more :-)

If you break containers down into three main jobs, with a sort of forth meta-job:

RUN (& FIND) - podman BUILD - Buildah SHARE - Skopeo

If you think about it, that's what made docker special, it was the ability to FIND, RUN, BUILD, and SHARE containers easily. So, that's why we have small tools that map to those fairly easily.

fatherlinnuxon Podman and Buildah available in RHEL 7.6 and RHEL 8 Beta

LOVE to hear this! The podman team thanks you for your feedback ;-)

fatherlinnuxon Podman and Buildah available in RHEL 7.6 and RHEL 8 Beta

Yeah, basically the "sudo" commands all over the Internet are just legacy. Historically, root was required (like docker - most people don't understand they are talking to a daemon which has root), but recently we added running as a user (aka rootless). Still the vast majority of docs you will see will refer to running with sudo or as root.

That should change as rootless matures.

fatherlinnuxon Let Google do the patching with new managed base images

Yeah, it's called Red Hat Enterprise Linux ;-) It's available on all the cloud providers and has a better API/ABI guarantee as well as very, very well defined commitments to patching and lifecycle :-)

fatherlinnuxon Roadmap for CoreOS Integration with Red Hat OpenShift

In Fedora, there is the Fedora Tools container [1], in RHEL, there is the RHEL Tools container. I don't envision either of those going away because they allow you to do all kinds of fancy stuff including things that require kernel compatibility, like SystemTap, core dumps, etc.

I am a product manager for containers/rhel/CoreOS at Red Hat, and I very much foresee a similar container for Red Hat CoreOS which will provide similar functionality for troubleshooting kernel, and user space (aka other containers) problems.

[1]: https://www.projectatomic.io/blog/2015/09/introducing-the-fe... [2]: https://developers.redhat.com/blog/2015/03/11/introducing-th...

fatherlinnuxon A Practical Introduction to Container Terminology

We are building a lot of tools to simplify run/build move [1][2][3]:

[1]: Run within Kubernetes: https://github.com/kubernetes-incubator/cri-o [2]: Run Standalone: https://github.com/projectatomic/libpod/blob/master/docs/pod... [3]: Build: https://www.projectatomic.io/blog/2017/11/getting-started-wi... [4]: Move: https://rhelblog.redhat.com/2017/05/11/skopeo-copy-to-the-re...

fatherlinnuxon Evolution of Linux containers

Really good background from Dan Walsh who has lived through this entire journey for the last 5ish years. Many times, people don't understand all of the moving pieces, but this article explains it well...

fatherlinnuxon When Should I Break My Application into Multiple Containers?

This is again, getting to the right answer for the wrong reason. You could keep these code bases separate whether they run in the same JVM in one container or in separate JVMs in different containers. As long as you enforce communication over something like REST, you will never have a problem.

In fact, the application was already written this way and it was never enforced. This makes no sense to enforce if it wasn't already broken.

fatherlinnuxon When Should I Break My Application into Multiple Containers?

My argument is, if two different processes are doing completely different things in the same JVM, I am skeptical that they will share memory pages well, etc. I simply don't know without testing, but I don't have any reason to believe they would.

On the other had, if I was running multiple threads that all cached data from the same data store, it is quite likely that scaling up threads in the same JVM would have a massive advantage over splitting them into multiple JVMs.

Also, in the comments I admit that over 10K applications on 1K machines, it's probably better 99% of the time not to use 10K JVMs. There would be a huge CPU/Memory overhead....

fatherlinnuxon When Should I Break My Application into Multiple Containers?

Read the email thread that inspired me to write it and it will become obvious. In the original email, a user asked if they should split an application that was almost exactly what I describe in the blog post, into multiple containers because you "should" only run one process per container. That is a ridiculous reason. That provides zero business value in and of it's self.

The two main business values I have found from splitting something up is 1. independent scaling and 2. independent development teams. Other than that most is preference and philosophy. You can get to the right answer for the wrong reasons, it doesn't mean you were right.... :-(

fatherlinnuxon When Should I Break My Application into Multiple Containers?

Nginx, Apache Prefork, Apache MPM, and PHP FPM all have multiple processes, and I would NEVER try to split up subprocesses of any of these into multiple containers.

It's quite simple if something communicates through shared memory, it should probably be in the same container. If it doesn't then that's NOT a reason to keep it in the the same container, but I don't see how it justifies the work of splitting it up....

fatherlinnuxon When Should I Break My Application into Multiple Containers?

This was exactly why I chose the workload I did. I think independent scaling and possibly enforcing decoupled behavior in the development teams are the only real reason TO decouple.... The rest are all descriptions of things that "might" make decoupling valid :-)

fatherlinnuxon When Should I Break My Application into Multiple Containers?

Fair point, but it's an existing application. I sort of assume it has low coupling already. But, if it already has low coupling, one might fairly ask, why do I need to enforce it?

For some future optimization?

fatherlinnuxon When Should I Break My Application into Multiple Containers?

I would argue, service, not process :-)

fatherlinnuxon When Should I Break My Application into Multiple Containers?

I tend to agree :-) Hopefully, you guys read my comments in the comments section of the article. Quite honestly, I am skeptical how often it makes sense to "force" splitting up an application. I hope that was clear in my article...

fatherlinnuxon When Should I Break My Application into Multiple Containers?

I actually regretted not mentioning the organizational advantage. Basically, scaling and organizational split are really the major two business drivers for splitting an application up!

fatherlinnuxon Things to avoid in Docker containers

@ilsivka: check out:

https://github.com/projectatomic/oci-register-machine

and

https://github.com/projectatomic/oci-systemd-hook

Also, ping Dan Walsh as he is leading work on our (Red Hat) end to get this working.

fatherlinnuxon Things to avoid in Docker containers

I feel you

fatherlinnuxon Things to avoid in Docker containers

Which is why I like your rhel7-update-date methodology to solve this....

fatherlinnuxon Things to avoid in Docker containers

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 trading CPU for Disk. Also, this could take TONS of time and money to figure out what is missing in Musl (including syscall mapping (not even sure it exists in other c libraries), etc)

Nothing is free, nothing. Building a cool new C library (musl) is fun. Maintaining one for 10, 20, or 30 years (glibc) is work (and fun)...

fatherlinnuxon Things to avoid in Docker containers

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 balancing act. It's not easy. But, if you use a package exactly twice in your environment, then putting it in the base image actually makes sense.

Think at scale, not about individual images.

fatherlinnuxon Things to avoid in Docker containers

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 operations or even Middlware teams.

Each team is responsible for making sure they update their piece of the supply chain. If the operations team (or image supplier) doesn't, the "yum upgrade" (or apt-get) downstream (by the developer or middlware maintainer) will bloat the environment.

The problem is, it's a symptom, not the problem. Telling people to NOT do yum updates, just promotes security problems because people upstream aren't keeping up with updates.

All of that said, the ONLY sane way to do all of this is with Automation. Hence, the reason for ImageStreams [1], BuildConfigs, DeployConfigs, and Triggers inside of OpenShift.

When any piece of the spider web detects a change, all of the dependent layers kick off jobs to rebuild themselves. Also, having good tests is critical. Yeah, most people on the planet haven't thought through this. Yes, Docker images make your life more convenient, at the deploy stage, with the downside that you need to do a LOT more thinking (automation and testing) at build phase.

Like shipping containers, we pack them at the factory, but can move them around at will after that. Instead of having dock hands load the ship at the port (which took 45 days in 1906). The supply chain problems are the same either way, but at least Docker gives you a good format to solve them.

[1]: https://docs.openshift.com/enterprise/3.0/architecture/core_...

fatherlinnuxon Things to avoid in Docker containers

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 massive environment bloat and way too many permutations.

If we just tell everyone to do yum updates at their layer this problem goes away. Ahh, recursion...

fatherlinnuxon Things to avoid in Docker containers

Agreed, that's why I published this: http://rhelblog.redhat.com/2016/02/24/container-tidbits-can-...

fatherlinnuxon Things to avoid in Docker containers

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 updates. Not the developer’s fault. Also, if the developer puts it into production, it’s their responsibility to make sure there are no CVE’s in their code, and hence their responsibility to do a yum update. You touched it, you own it.

2. The Docker tools don’t have a way of flattening the image easily (without doing a save/load). This can be fixed down the road.

Telling developers not to do yum updates terrifies me as a security person….

fatherlinnuxon Things to avoid in Docker containers

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...

fatherlinnuxon Things to avoid in Docker containers

I think they mean this: https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zomb...