@scottalanmiller sorry I wanted to answer @flaxking but ended up replying to yours reply xD

@flaxking said in Check my 2 min audio theory on Containers:

@scottalanmiller said in Check my 2 min audio theory on Containers:

@flaxking said in Check my 2 min audio theory on Containers:

What you're talking about is one aspect of part of implementing DevOps that is often misinterpreted to mean the whole of it. And yes, it is stupid to call that DevOps. That's just Ops using different tools.

I see it as the opposite. Patrick's core DevOps...

"Thanks to the devopsdays conference, the idea of devops seems to live on. While talking with other people about it, I realize that it is difficult to frame it within the current IT landscape. At lot of the ideas are coming from different kinds of emerging technologies (T) and process management (P) approaches.

For me the two most important observations are:

there is a increase in feedback loops between business, all parts of the delivery process and operations thanks to this feedback loops we increase the quality and speed up the flow"

This is the core of DevOps, not well described, but pretty clearly about IT, not development. This is the core. Very, very loosely defined to the point of useless, sure.

Then things like DevOps talking dev itself is the extra, the tack on later. It's not "part of" devops, any more than it is of any operations. And just how operations doesn't cease to exist without developers, neither does DevOps.

I believe everything on that page is all meant to be within the context of companies doing development. But I agree, the core of DevOps is about Ops and Business practices. However, I firmly believe the name DevOps comes from Ops and Development working together, and thus the reason why discussions of DevOps implementation specifics centre around companies doing software development. Though just based on that page, I could see why someone could still take a different view. However, I consider The DevOps Handbook to be the definitive source, rather than notes on the initial discussions.

I think doing that makes DevOps a pointless, useless concept. Hopefully that's not what he intended. As an ops practice, it has tremendous value. As a merger of dev and ops, it's just bluster.

This one seems to make more sense since its installed from a snap like what Ubuntu does by default.

https://www.cyberciti.biz/faq/how-to-install-setup-lxd-on-fedora-linux/

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

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

@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

@Dashrender said:

I've already told Scott I would love to see one of the first major projects on the new NTG lab be to setup a ZT network.

I like this idea. We could use the ZT Network for the NTG lab as a management network or something.