Linux containers (LXC) on Red Hat/CentOS EL6 - lxc-create versus libvirt?

Question

I'm trying to implement some JavaScript in my Rails 6 app, I have no idea if I'm going about it the right way but so far everything I've tried has been wrong.

I have a file javascripts/form_helpers/submit.js for now it just looks like this:

const submit_action() {
  console.log("hello world");
}

In javascripts/application.js I have

require("form_helpers"); 
# I've also tried require("form_helpers/submit.js") but I thought I could just include the directory which seems to be what Rails ships with for channels

Then in the actual view I have a form_with tag:

  <%= submit_tag 'Submit', class: "button button-create button-log-radius", onclick: "submit_action()" %>

I always get a reference error when I click the submit button that submit_action is not defined. Am I on the right track here? Am I way off base? I'm a little confused by this new javascript folder, am I using it right or should I be putting scripts like this into the assets directory?

BTW I've seen this question asked before on here and the answer had to do with appending window before your function name (here) but that feels hacky to me.

Solution 1

What's the conventional wisdom regarding LXC and RHEL-like systems today?

Personally, I find the current setup somewhat lacking. LXC seems more at the forefront -- certainly more maintained.

How are you implementing them?

In terms of offering it as a virtualization option I am not. I find the current technological setup lacking.

• No username namespace.
• Certain mountpoints are not namespace aware (cgroups, selinux)
• Values in /proc are misleading system globals that dont account for the resource partitioning in namespaces.
• Breaks audit.

I do find it really nice tool for application level containment however. We use namespaces and cgroups directly to contain network and IPC resources for certain user-ran web applications. We provide our own interface to control it. In RHEL7 I'm considering moving this functionality to libvirt-lxc as the newer revisions of libvirt support the concept of user ACLs.

For virtualization in terms of a fully initialized system I'm waiting to wee what is offered in RHEL7, but in all honesty, I feel we might only see a good enough solution once we're on a later minor release of RHEL7 and then perhaps only on a technology preview state.

Keep your eye out on systemd-nspawn something tells me in the next 18 months or so it might take its place is the best tool to do fully linux contained virtualization, be it that the systemd authors make it clear its not secure right now! I wouldnt be surprised if libvirt drops libvirt-lxc eventually and just offers a wrapper around systemd-nspawn with systemd slices defined.

Also, be wary theres been a lot of talk over the last 6 months in regards to re-implementing cgroups as a kernel programmer interface rather than a filesystem interface (perhaps using netlink or something, haven't checked) so systemd should be very hot on the tail of getting that right very quickly.

Are there any advantages to one approach versus the other?

I think the LXC option (not libvirt-lxc) is better maintained. Having read the libvirt-lxc sourcecode, it feels rushed. Traditional LXC certainly has newer features whicih have been better tested. Both require a degree of compatibility by the init system being ran in them, but I suspect that you'll find LXC slightly more "turn-key" than the libvirt-lxc option particularly in regards getting distros to work in them.

Can these coexist?

Sure, remember that for all intents and purposes, both are doing the same thing. Organizing namespaces, cgroups and mount points. All the primitives are dealt with by the kernel itself. Both lxc implementations just offer a mechanism for interfacing with the kernel options available.

Solution 2

Red Hat is making a huge containerization push. They're building an entire new product, Red Hat Enterprise Linux Atomic Host, around it.

For a less radical approach, take a look at their RHEL7 beta Resource Management and Linux Containers Guide; you'll notice it pushes libvirt-lxc and makes no mention of the lxc tools.

Solution 3

The lxc-* executables are packaged in the lxc package in EPEL. However it's the old "long term support" release. You don't even have the "-f" option in lxc-ls. I'd simply install Ubuntu for my LXC hosts.

The RHEL way to manage LXC seems to be via libvirt-lxc but it's apparently deprecated.

Noted that Ubuntu is supporting many of the new lxc/lxd development while Redhat is focusing in KVM and docker.

Comments

[iSee]

libvirt has a LXC container driver and only controls it, it's not a virtualization/containerization solution per se.

[ewwhite]

Thanks for this. The RHEL Atomic Host looks to rely heavily on Docker.io. Does that indicate that Docker and related tools are the right path forward?

[sciurus]

Red Hat is definitely investing heavily in docker, but they're also the primary developers of libvirt-lxc. I'd look at the capabilities they each provide and see which better fits your needs.

[Susinthiran]

Yes @ewwhite The following Redhat doc mentions exactly that: access.redhat.com/articles/1365153

[taharqa]

The question is RHEL 6 related, the deprecation stands for RHEL 7 «The following libvirt-lxc packages are deprecated starting with Red Hat Enterprise Linux 7.1:» so this can be used