Why would you care about K8S? K8S does Docker, and Docker is *so* obsolete
now that Red Hat is dropping it. </sarc>
(So if anyone was silly enough to suspect that IBM wouldn't fuck up Red Hat as fast as they could ...)
(So if anyone was silly enough to suspect that IBM wouldn't fuck up Red Hat as fast as they could ...)
What I actually said is that K8S is not my tool of choice. I'm trying to stay away from it until somebody crams it down my throat.
Ok, but you're still using Docker containers, right? All that's in question
is the orchestration platform?
Even with Openshift, you're still orchestrating Docker containers. But not
for long.
Red Hat has decided to drop support for Docker entirely. In its place they are pushing "Podman". So basically if you're interested in downloading and running pre-built Docker containers, you're not going to be doing it on Red Hat anymore.
I have a container project coming up later this year. Docker support is pretty much a strict requirement. It would be difficult to recommend anything other than K8S for orchestration. Red Hat has pretty much put themselves out of the running here, and I intend to tell them so the next time we meet with their people.
Red Hat has decided to drop support for Docker entirely. In its place they are pushing "Podman". So basically if you're interested in downloading and running pre-built Docker containers, you're not going to be doing it on Red Hat anymore.
I have a container project coming up later this year. Docker support is pretty much a strict requirement. It would be difficult to recommend anything other than K8S for orchestration. Red Hat has pretty much put themselves out of the running here, and I intend to tell them so the next time we meet with their people.
Docker is dying a slow death it seems.... Docker fails because it isn't an
orchestration tool. A container is a container. Who cares if it's Docker?
From where I sit, everyone seems to want to run Docker containers. Software
that ships as a pre-built Docker container can be loaded into Kubernetes and/or
any cloud provider that supports Docker.
Saying otherwise sounds to me like the equivalent of "A binary is a binary.
Who cares it if it's Windows?" (If that were true we'd all be in a better world, right?)
Saying otherwise sounds to me like the equivalent of "A binary is a binary.
Who cares it if it's Windows?" (If that were true we'd all be in a better world, right?)
Sure, and OS/2 could run Win16 programs too. We all know how difficult it
is to paddle upstream when the industry has already selected the winner.
It's straightforward enough to get people to use an arbitrary orchestration
system, but to tell them they can't use Docker? That sounds like a tough
sell.
2020-01-20 11:11 from IGnatius T Foobar
Ok, but you're still using Docker containers, right? All that's in
question is the orchestration platform?
Yes.
LOL, docker is not going away any time soon, no, given the typical lifecycle of datacenter deployments.
Guys, rumors of docker's death are greatly exaggerated. podman ingests docker images, and in a few short months docker will have cgroupsv2 support and run on the latest redhat unmodified. The difference? You'll download your docker RPMs from a non-redhat repo, but people are already doing that *anyway*
Right ... and I don't think anyone is suggesting that Docker is going away.
Quite the opposite, in fact. I am suggesting that these happenings may mean that Red Hat Linux may not be the best choice for a Docker-centric container infrastructure. Perhaps it never was. I am certainly turned off. Although I was never big on Ubuntu for servers, they support both Docker and Kubernetes out of the box, so I might give that another look.
Podman being able to run Docker images sounds suspiciously like OS/2 being able to run Win16 images ... but IBM probably fired anyone old enough to remember :)
Quite the opposite, in fact. I am suggesting that these happenings may mean that Red Hat Linux may not be the best choice for a Docker-centric container infrastructure. Perhaps it never was. I am certainly turned off. Although I was never big on Ubuntu for servers, they support both Docker and Kubernetes out of the box, so I might give that another look.
Podman being able to run Docker images sounds suspiciously like OS/2 being able to run Win16 images ... but IBM probably fired anyone old enough to remember :)
Ubuntu does support Docker out of the box, but their packages lag a bit behind what's current. That's less true in Ubuntu 19.10, but Ubuntu 18.04 is still shipping docker 18.09.7.
This might not be a big deal for you, but some of us have been running the `docker-ce` package from Docker's own Ubuntu repo for some time now.
(I've been working here since 2018-Nov, and my initial dev env that I built at that time was Ubuntu 18.04. Ubuntu LTS did not start shipping a current (v18 or newer) version of docker until 9 months later.)
((Why am I nesting my parentheses?))
K8S is a funny thing. It's highly opinionated about how to build your network infrastructure... it's fine if your applications are aware of it, but I think it'll have trouble with some legacy workloads, i.e. anything that wants to just look at its local network stack and assume that the IP addresses it sees are actually routable from clients.
K8S has pluggable CNI so what you get for a network depends on what module
you choose for the networking. If you pick something basic like Flannel you
aren't going to get much other than what Docker provides on the individual
hosts. Attaching to a fabric using something like VMware PKS and NSX-T would
make the containers first class citizens on a real network (subject to whatever
microsegmentation you have in place, of course).
For lift-and-shift workloads, it is, as you suggest, a bit of a hassle. In a perfect world you're going to have some sort of pub-sub infrastructure in place where a container announces to the load balancer what service it is providing, and the actual location on the network no longer matters. (Ragnar - this is what I was trying to suggest for the flexible and spherical project we worked on years ago, but no one had software that could do it. We were ahead of our time -- and ahead of the people we were working with.)
For lift-and-shift workloads, it is, as you suggest, a bit of a hassle. In a perfect world you're going to have some sort of pub-sub infrastructure in place where a container announces to the load balancer what service it is providing, and the actual location on the network no longer matters. (Ragnar - this is what I was trying to suggest for the flexible and spherical project we worked on years ago, but no one had software that could do it. We were ahead of our time -- and ahead of the people we were working with.)
It's kinda like a Swiss Army Knife with some empty slots for tools that might exist 2 years from now...
Ahh, I thought this didn't exist yet, I stand corrected (or at least updated): https://docs.aws.amazon.com/eks/latest/userguide/pod-networking.html
Still I think it may not support the increased limits as per AWS VPC Trunking on ECS. Which we are using here, as of last week. They'll get there eventually, I guess.
too bad this only works on linux hosts, but this is what we need for decent virtualization performance on desktop workloads:
https://github.com/intel/gvt-linux/wiki/GVTg_Setup_Guide
for me, the whole point would be to run it on a windows host.
Linux is still a little raw on this Ice Lake laptop. I've got one kernel that appears to have stable video drivers and completely broken iwlwifi; another has stable iwlwifi and slightly wonky DisplayPort. So it goes...
Out of curiosity. Anybody here has faced ugly issues by performing backups
and restores via dump on a BSD system?
I currenty back my mini servers up live with drump. I cheat a bit and sequentially disable services before their stuff is backed up. I have had some successful disaster recoveries already. However, the documentation I have been finding online latelly suggests dump is Hugo Chavez (aka Satan) incarnate which makes me wonder.
I currenty back my mini servers up live with drump. I cheat a bit and sequentially disable services before their stuff is backed up. I have had some successful disaster recoveries already. However, the documentation I have been finding online latelly suggests dump is Hugo Chavez (aka Satan) incarnate which makes me wonder.