lxc (and most recently lxd) offers a better way to manage containerization (in other words - VMs) in ubuntu. I’m wondering if anyone in community has done that…we have been on lxc for a while now, and is stable. It makes managing virtual container, backup & restore very easy.
We’d be glad to share our experience with lxc, if anyone is interested. We are also looking to know from others about their experience with lxd.
just bumped over your topic which is quite dated … I am actually experimenting with LXD as my container tool of choice and have manage to install ERPNext for the first time just now
struggling a bit with accessing it from outside my host machine yet … anyway I was wondering whether you are still ‘in the LXC/LXD game’ and whether you might share how you practically run things?
I used it for testing, and it worked fine for me. Didn’t have any problems after learning to use Lxc/lxd, which I think is great. I found it much better and faster than using a VM. Only thing was that I needed was a laundry list of commands to copy and paste, since there didn’t seem to be any gui for lcx/lxd. I didn’t have any problems accessing it remotely across my network, but I think there was some kind of work around to access the site from outside. But I was only using it locally for testing/training purposes.
I couldn’t get my head around docker, so for me it was sufficient.
Try lxc using Proxmox. It’s open source and installs on bare metal bit like Vmware Vsli . It has a full management web gui. It will give you KVM and LXC containers it will setup and manage. I’ve used the lxc for a Nextcloud install, working very well. No reason it won’t work with ERPNEXT
playing around a bit some issues came up. The most pressing one
how do you make ERPNext served from your container accessible to your local network (not yet touching internet access in order to reduce complexity)
LXD host: xubuntu 16.04 (which lives in a VirtualBox VM on my laptop with bridged networking)
I can access the container ERPNext using the browser of my host VM
I can not access ERPNext from any other point within my local network (neither browser, nor ping)
Container’s IP is 10.116.162.xxx
host IP is 172.20.14.yyy
maybe it’s a bad idea to add VirtualBox to the mix in the first place? I did it because our server is still on 14.04 where newest LXD available is only 2.09 (from trusty backports) while 16.04 goes down with 2.12 (soon 2.13).
can anyone help? One thing I heard about was using iptables (which I have no experience whatsoever with) on the host.
@kirthi apart from this initial hurdle I’d be super interested to hear how you …
handle bench update procedures
use Container snapshots (if you do)
publish/use your own image(s) (if you do)
I for now just launched an ubuntu:16.04 container, installed python-minial & ran the easy install script inside of it and go from there. I guess utilizing all tools a LXD container offers can make implementation/maintenance very easy and even scriptable
@vrms - will try to cover the questions as much as possible.
Ubuntu host in a VM - I have not tried that. It definitely sounds like complicated since you have to bridge the containers to the lxd host and the host to your VM host. Already LXD bridging is confusing sometimes. I have a Ubuntu 16.04 host dedicated machine in which the containers are bridged. This link helped me in establishing the networking of containers in LXD - https://insights.ubuntu.com/2016/04/07/lxd-networking-lxdbr0-explained/
If you need help - I can provide the settings I have.
bench update procedures - I do bench updates on a weekly basis and take backup of the ocntainers before I do - This helps in quick restoration in case bench update goes wrong.
Snapshots - Yes I do take snapshots - for regular backups and one just before doing bench update. snapshots are super easy - lxc snapshot container-1 and then you can create a container out of it anytime you need by using ```lxc copy container-1/snap0 container-2
Images - I used them during initial setup of ERPNesxt where I had to create differnt environments for testing production and dev. I dont use them as much anymore. Images are useful when you want to replicate the setup completely. Once a production setup of ERPNext is created - I published an image out of it and used that for creating multiple test environments. It helped save a lot of time.
Scritable - The lxd commands are scriptable. My backups are scripted so that I take a snapshot or a clone of a container on a daily basis. And anytime I need to restore - I can go to the clones and restore it in seconds.
first of all thanks for your feedback, that’s really interesting
Still fighting with networking. Can you kindly specify which of the alternatives given there has worked for you?
I managed to get IP addresses of my LAN to the containers with running…
lxc profile device set default eth0 parent enp0s3
lxc profile device set default eth0 nictype macvlan
… on my host
that looks promising but afterwards I still can not access ERPNext (nor ping the containers) from outside my host and not from inside my host any longer neither. So that hasn’t helped yet really but might be a place to start.
In the host my network interface is configured as below -
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
#auto enp21
#iface enp21 inet dhcp
auto br0
iface br0 inet dhcp
bridge-ifaces enp21
bridge-ports enp21
up ifconfig enp21 up
iface enp21 inet manual
What I have done is - created a bridge in the host and then in the container profile I bind the container network to the bridge created in host.
after doing this - just restart networking service in host or restart the host itself. You will be able to connect to the container from anywhere in your network
thanks for sharing. It seems not to work for me though (which may be due to the fact my host is a Virtual Box machine)
still I have 4 questions about your settings
by default (created by lxd init) the lxd bridged interface is lxdbr0. Have you just named yours differently during the init process? if not, how did you create that bridged interface?
is the package vlan installed on your host?
what’s the IP address of your container (from the 10.116.163.xxx range maybe)? Is it the same your users access it with?
by default (created by lxd init) the lxd bridged interface is lxdbr0. Have you just named yours differently during the init process? if not, how did you create that bridged interface? - I gave the bridge name as br0 while doing lxd init. I didnt use lxdbr0 because I couldnt bridge appropriately.
is the package vlan installed on your host? - No. But I had to install bridge-utils in the host for the bridging to work properly
what’s the IP address of your container (from the 10.116.163.xxx range maybe)? Is it the same your users access it with? what’s the IP range of your internal network? - The ip address range of my containers is the same as that of my host. My users will not know whether they are accessing a lxc container or actual machine.