@scottalanmiller these discussions echo my thoughts exactly. I'm only (hesitantly) learning Docker now, but it feels like it's not a long term answer(I'm possibly too late to the party?), as other approaches are increasing in mind-share.

@devops1 said in Kubernetes (Kubespray) Issue.:

@stacksofplates Thank you very much It works.

No problem!

@black3dynamite said in Installing LXC Containerization on openSuse Tumbleweed:

@scottalanmiller said in Installing LXC Containerization on openSuse Tumbleweed:

@black3dynamite said in Installing LXC Containerization on openSuse Tumbleweed:

@scottalanmiller said in Installing LXC Containerization on openSuse Tumbleweed:

I have to say, though, I prefer the Ubuntu LXD approach much better.

I know Canonical is a big supporter of LXD. Who is the big supporter for LXC?

LXD is just an interface for LXC. So Canonical supports LXC through LXD. The biggest contributors to LXC are Virtuozzo, IBM and Google.

So LXD makes it easier to manage LXC?

Yes

@dashrender said in Getting Started with LXD on Ubuntu 17.04:

@scottalanmiller said in Getting Started with LXD on Ubuntu 17.04:

@dashrender said in Getting Started with LXD on Ubuntu 17.04:

@scottalanmiller said in Getting Started with LXD on Ubuntu 17.04:

@black3dynamite said in Getting Started with LXD on Ubuntu 17.04:

@scottalanmiller
Are you running KVM and LXD on the same machine?

I am, yes.

Wouldn't this be the expectation? in many if not most cases?

If you know my particular case, yes it would be an expectation. In a more common scenario, no, not so much.

Wouldn't you typically have LXD on a hypervisor?

LXD is a Type-C hypervisor, so while having it on top of a Type 1 is common, having it on bare metal is also common.

@AlyRagab

The web UI benefit is that it allowed me to understand why everytime I launch container it spawned a new one and made new generic name for it, and helped me understand more visually.

However You can do much more from it, than stop/start/restart/commit containers, and monitoring them. When it comes to doing edits its advised you do everything from command.

I actually never heard of supervisord until you mentioned it, thus I ran the default which I reckon is each process in a separate container and never had any issues yet.

For me the important thing I learned exploring docker is distinction between application containers and OS containers, and how to approach each.

Since you mentioned centos in docker, you might want to check Alpine Linux images, cause they fit the Just enough OS ideology of docker (or was that VMware Photon).

Registered.

Lots of VMs creates a licensing nightmare. Sure with a Datacenter license that would be no big deal, but I don't have that.

meros-tri.png

@dafyre said:

@scottalanmiller said:

@dafyre said:

@scottalanmiller said:

Yeah, some definitely will.

I wonder what that will do against Virtualization platforms like XenServer, VMware, et al...

if an lxc-container is functionally equivalent to a VM... Would it be possible to run Windows in an lxc-container... That type of thing.

No, we've had those containers for a decade and we are nowhere near having Windows in them. They all share the parents' kernel by definition. So no Windows coming on Linux containers. Much closer to PV Windows on Xen, at least that has been done in a lab.

What about Containerization on Windows? Didn't OpenVZ or Virtuozzo...used to offer something like that?

You can, in theory, make Windows containers on Windows. But you have to be on Windows already.

I find this one a little surprising. When I worked on Wall St. we were rolling out containers in 2006. If these banks are just talking about "looking into" containers now, they are a full decade behind where we were.

For anyone on Xen. . .

Preview of XenServer support for Docker and Container Management