@vrms I didnt try macvlan at all. I was happy with bridge - it served my purpose. once bridged - there is no need ofd proxying or port forwarding. container behaves like a stand-alone machine in the network.
Nice to know about snap for lxd. weill hv to try it sometime…
thanks @kirthi
for anybody who’s interested in this here is a pretty neat how-to for putting macvlan into play with LXD containers LXC Containers - Exposing Ports & Port Forwarding - YouTube
it takes a more simple approach then @laymonk, attaching the macvlan directly to the default network interface of you host machine. @laymonk do you have any opinion about why your approach would be preferable over this one?
btw: a "good-to-know: fact about lxd from snap can be found here: Lxc from snap - where is /var/lib/lxd? - LXD - Linux Containers Forum
@vrms, the only difference between what was shown in that video, and my suggested setup is that the host’s ip address is attached to the underlying ethernet device in the video, while my example config attaches the host’s ip to the macvlan bridge interface on the host.
The consequence of that is that as setup in the video, the container would not be able to talk to the host and vice versa, I reckon.
Having said that, it is possible the host and container may be able to talk on L3, but will first traverse the network (ie, their awareness of each other will be determined by the external network switch, as against a local commuination within the host alone) … I guess I need to test that out to be sure.
I don’t think ‘preference’ is relevant here … just roll with what works for your needs. I have gotten used to putting the ip on the macvlan interface, and it makes logical sense to me …
it looks like…
this furthermore says … “The transition from deb to snap will be done through a script which will let you move your existing environment to the snap without loosing anything. We’ll initially just prompt users on package upgrade, suggesting that they switch to the snap.”
@vrms - given your experience in working with lxd and mine - we can probably create a document or a presentation at the conference to explain the advantages of using lxd. I have immensely benefitted from using lxd and I think a lot of users who installed erpnext in ubuntu will also benefit from that. I can help with content creation in any format that you may suggest. Plz let me know.
yes, that’s a great idea. I think the best format would be this topic here, or alternatively and md file on github.
I won’t be able to make it to the conference though I am afraid (even if I’d very much like to be there).
But we still could work this out together. Would you be able to give the presentation?
Ideally we would be able to convince Frappe or the Foundation to issue and maintain an official LXD image, so one could just say lxc launch erpnext:8.x
EDIT: Actually my experience is rather small. I just have publish everything I just have discovered
how about that? the date of the Conference is getting closer and there was just released a call for presentations . Would you be able to deliver a talk about ERPNext/LXD?
Hi,
For your information, I’ve test to install ERPNext under LXC. But this error happened after running sudo python install.py --production using ubuntu user.
Traceback (most recent call last):
File “install.py”, line 388, in
install_bench(args)
File “install.py”, line 114, in install_bench
run_playbook(‘production/install.yml’, sudo=True, extra_vars=extra_vars)
File “install.py”, line 326, in run_playbook
success = subprocess.check_call(args, cwd=os.path.join(cwd, ‘playbooks’))
File “/usr/lib/python2.7/subprocess.py”, line 541, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command ‘[‘ansible-playbook’, ‘-c’, ‘local’, ‘production/install.yml’, ‘-e’, ‘@/tmp/extra_vars.json’, ‘–become’, ‘–become-user=frappe’]’ returned non-zero exit status 2
I also tried to install on host OS and it went smoothly without error.
Trying to install frappe bench in lxc container (ubuntu 16.04) under Proxmox 5.1, and I am geting What a PITA to install frappe bench (including frappe_docker):
TASK [locale : Check current locale] ********************************************************************************
fatal: [localhost]: FAILED! => {“changed”: true, “cmd”: “localectl”, “delta”: “0:00:25.026238”, “end”: “2017-12-30 11:41:38.663161”, “failed”: true, “rc”: 1, “start”: “2017-12-30 11:41:13.636923”, “stderr”: “Could not get properties: Connection timed out”, “stderr_lines”: [“Could not get properties: Connection timed out”], “stdout”: “”, “stdout_lines”: []}
to retry, use: --limit @/tmp/.bench/playbooks/develop/install.retry
PLAY RECAP **********************************************************************************************************
localhost : ok=5 changed=0 unreachable=0 failed=1
Traceback (most recent call last):
File “install.py”, line 388, in
install_bench(args)
File “install.py”, line 111, in install_bench
run_playbook(‘develop/install.yml’, sudo=True, extra_vars=extra_vars)
File “install.py”, line 326, in run_playbook
success = subprocess.check_call(args, cwd=os.path.join(cwd, ‘playbooks’))
File “/usr/lib/python2.7/subprocess.py”, line 541, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command ‘[‘ansible-playbook’, ‘-c’, ‘local’, ‘develop/install.yml’, ‘-e’, ‘@/tmp/extra_vars.json’, ‘–become’, ‘–become-user=frappe’]’ returned non-zero exit status 2
root@frappe:~# localectl
Could not get properties: Connection timed out
I’ve just successfully installed ERPNext in a LXC debian 9/jessie container. It was indeed a PITA, the common install notes are not really useful for setting this up in LXC containers or similar. Among the many things I encountered issues with, I can tell you about two issues:
/proc/sys without writing permissions to change swappiness (which the isntall script does). To solve this you have to run the command mount /proc/sys -o remount,rw as root (or with sudo).
localectl failing to connect (timing out). This was solved following instructions here: [lxc-users] Failed at step NAMESPACE spawning: Invalid argument
Another tip is when studying errors it’s useful to go several lines up, not just the python traceback but many others up, or pasting the complete install log if possible.
Last but not least, I had to install several packages by hand in the LXC container for the install script to work, the following link is a list of packages installed in the debian container if that helps, check if you don’t have something you may need: ERPNext in Debian LXC - packages · GitHub
I hope this helps.
When I wrote this guide a while ago I have not seen any of those issues. Main problem, if I recall it correctly, was to get container networking right.
I’m using pure LXC and the problems are basically issues or common things you expect from containers (the swappiness and localectl issues I talked about earlier, specifically), the problem is that the easy install script from ERPNext doesn’t expect these to be this way, but it’s the expected way for LXC containers as said in the links of the issues I posted, at least for some/most of the host OS.
This was using the latest ERPNext version (10.1.31) and latest LXC version (3.0.0) on an archlinux host.
did this by any chance happen on a proxmox server? I see something very similar right now on a proxmox system (ubuntu 16.04 container).
And, as I am not 100% sure whether the Container templates on proxmox are identical with the ‘original’ LXC templates, was wondering whether this zould be a proxmox thing.
We have set up a linux server which hosts several ERPNext sites as LXD containers. The trick is to use NAT (network address translation). You can use iptables to accomplish that.
First you need to create firewall rules which specify:
Then you need to create NAT rules which specify:
iptables/NAT example:
iptables -A PREROUTING -i eth0 -p tcp -m tcp --dport 5001 -j DNAT --to-destination 10.0.12.2:80
This assumes your ethernet interface is eth0 and the original port was 5001. All packets to eth0’s port 5001 are then forwarded to 10.0.12.2 port 80.
You can check which IP addresses are assigned to LXD containers by entering the command: lxc list
wow, thanks @tatu. It’s always phantastic to see issues are being picked up even after a long time.
Would you mind to specify the version of LXD you are using? I’m pretty certain that LXD networking is going though some changes between different version of yet young LXD.
good news for all LXD/LXC fans.
Thanks to @codingCoffee a PR, which makes the EasyInstall script LXD/LXC ready again, is waiting to be merged.
Was a document or presentation created? I will appreciate if this is available. Thank you.
An LXD image will be awesome to have. Was there any progress on this?