Re: [lxc-users] Looking for LXD-2.4.1 Static IP Setup Documentation
Hello > ATM what I do is either use dnsmasq to provide DHCP or stop the > container and push a preconfigured interfaces file... > > lxc file push interfaces.tmp CONTAINER/etc/network/interfaces Same approach we are using, but with Ansible as our "bootstrapper/configurer". I've been successfully able to do the following: 1. generate instance-specific config in the form of a cloud-init file 2. create container 3. take down network on the container by running lxc exec ... ifdown -a 4. generate the container's nw config file on the LXD host via ansible and push it to the container via "lxc push" (and remove the default configs if necessary) 5. bring up network on the container by running lxc exec ... ifup -a The cloud-init config is used to inject the ssh key, setup the ssh daemon+config and create an ansible-remote user. That user is necessary for ansible to do later more complex configs by directly accessing the container over ssh, as you would do for a normal ansible host. Something cleaner would be cool, possibly integrated in cloud-init itself. I guess this is somehow possible by creating your custom images and customizing the templates section of the metadata.yaml file, as outlined in the last part of this article https://www.stgraber.org/2016/03/30/lxd-2-0-image-management-512/ CONFIDENTIALITY NOTICE: This email message (and any attachment) is intended only for the individual or entity to which it is addressed. The information in this email is confidential and may contain information that is legally privileged or exempt from disclosure under applicable law. If you are not the intended recipient, you are strictly prohibited from reading, using, publishing or disseminating such information and upon receipt, must permanently delete the original and destroy any copies. We take steps to protect against viruses and other defects but advise you to carry out your own checks and precautions as Kambi does not accept any liability for any which remain. Thank you for your co-operation. ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] inventory / dashboard tool to manage LXD containers' lifecycle
Thank you all for the tips. I wasn't aware Ansible introduced the lxd module. I knew they were working on it, good to know! It is not a full lifecycle solution but probably better than nothing. I'd love to see this integrated into Foreman, eventually. CONFIDENTIALITY NOTICE: This email message (and any attachment) is intended only for the individual or entity to which it is addressed. The information in this email is confidential and may contain information that is legally privileged or exempt from disclosure under applicable law. If you are not the intended recipient, you are strictly prohibited from reading, using, publishing or disseminating such information and upon receipt, must permanently delete the original and destroy any copies. We take steps to protect against viruses and other defects but advise you to carry out your own checks and precautions as Kambi does not accept any liability for any which remain. Thank you for your co-operation. ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
[lxc-users] inventory / dashboard tool to manage LXD containers' lifecycle
Hello, everyone. As per subject: is there any existing project able to manage the lifecycle of LXD containers via some form of frontend/webgui? I am very pleased by what Foreman can do for VMs: It can assign a random or predictable hostname, deploy a VM on a host of choice (or in the cloud), kickstart/preseed it and then keep track of its existence for all its life. When done with the vm it can be destroyed and removed from the database. Ansible tower is providing a very similar feature via system tracking and even allowing the users to setup their own hosts via self-service (surveys). I am not aware of any support to LXD provided by Foreman and Ansible, and I am honestly surprised since LXD is such a powerful piece of technology. Anyone out there who managed to integrate these tools and LXD? I would be cool to do for LXD what has been done for VMs. Thanks! Nicola CONFIDENTIALITY NOTICE: This email message (and any attachment) is intended only for the individual or entity to which it is addressed. The information in this email is confidential and may contain information that is legally privileged or exempt from disclosure under applicable law. If you are not the intended recipient, you are strictly prohibited from reading, using, publishing or disseminating such information and upon receipt, must permanently delete the original and destroy any copies. We take steps to protect against viruses and other defects but advise you to carry out your own checks and precautions as Kambi does not accept any liability for any which remain. Thank you for your co-operation. ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] Unable to list remote images
On 04/01/2016 12:23 PM, Muneeb Ahmad wrote: Hi, I get the following error when I run ‘lxc image list images:’ command. error: json: cannot unmarshal string into Go value of type int64 I’m using ubuntu 15.10. Any help would be appreciated. Hello, Have you upgraded all your lxc packages too, in addition to the lxd ones? That was the issue for me. Nicola CONFIDENTIALITY NOTICE: This email message (and any attachment) is intended only for the individual or entity to which it is addressed. The information in this email is confidential and may contain information that is legally privileged or exempt from disclosure under applicable law. If you are not the intended recipient, you are strictly prohibited from reading, using, publishing or disseminating such information and upon receipt, must permanently delete the original and destroy any copies. We take steps to protect against viruses and other defects but advise you to carry out your own checks and precautions as Kambi does not accept any liability for any which remain. Thank you for your co-operation. ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] Eth devices to host bridges association seems unpredictable
On 03/31/2016 11:10 AM, Fajar A. Nugraha wrote: > Can you add the key "name"? So it becomes like this > devices: >eth1: > name: eth1 > nictype: bridged > parent: br23 > type: nic > > lxd docs: https://github.com/lxc/lxd/blob/master/doc/configuration.md#type-nic Hello Fajar, That did indeed do the trick. I'll follow the git docs more closely since I tend to rely exclusively on the cli help at the moment. Thank you for the quick reply and for the solution. Nicola CONFIDENTIALITY NOTICE: This email message (and any attachment) is intended only for the individual or entity to which it is addressed. The information in this email is confidential and may contain information that is legally privileged or exempt from disclosure under applicable law. If you are not the intended recipient, you are strictly prohibited from reading, using, publishing or disseminating such information and upon receipt, must permanently delete the original and destroy any copies. We take steps to protect against viruses and other defects but advise you to carry out your own checks and precautions as Kambi does not accept any liability for any which remain. Thank you for your co-operation. ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
[lxc-users] Eth devices to host bridges association seems unpredictable
Hey everyone,
I'm seeing a strange behavior when using lxd profiles to attach the container
eth devices to the host bridges.
I see some inconsistency: I made two bridges on my host and want to use the
profiles to associate the container eth0 to one bridge, and eth1 to the other.
Somehow, the eth0 and eth1 end up being assigned to the wrong bridges (swapped).
Here's the full output from lxd, showing the profiles and the bridges. At the
end you'll see each of the container interfaces attached to the wrong bridge:
#
me@host:~$ lxc profile show dev_br23
name: dev_br23
config: {}
description: ""
devices:
eth1:
nictype: bridged
parent: br23
type: nic
me@host:~$ lxc profile show dev_br250
name: dev_br250
config: {}
description: ""
devices:
eth0:
nictype: bridged
parent: br250
type: nic
me@host:~$ lxc profile apply lbng1-internal dev_br23,dev_br250
Profile dev_br23,dev_br250 applied to lbng1-internal
me@host:~$
me@host:~$ lxc config show lbng1-internal
name: lbng1-internal
profiles:
- dev_br23
- dev_br250
config:
boot.autostart: "true"
volatile.base_image:
5bcef3ad83936c18d45cd866f38cd2cab53bcd28fa38478166a57c404537ec1f
volatile.eth0.hwaddr: 00:16:3e:75:5c:3d
volatile.eth0.name: eth1
volatile.eth1.hwaddr: 00:16:3e:9d:8f:c7
volatile.eth1.name: eth0
volatile.last_state.idmap:
'[{"Isuid":true,"Isgid":false,"Hostid":231072,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":231072,"Nsid":0,"Maprange":65536}]'
devices:
root:
path: /
type: disk
ephemeral: false
me@host:~$ brctl show
bridge name bridge id STP enabled interfaces
br238000.5254001c2c55 no eth2
vethASE3RF
vethB03UPX
br250 8000.525400256f8e no eth1
veth5AYAW8
vethAB1VM9
vethH2QO2P
vethUA3SUE
vethYPM4BL
me@host:~$ lxc info lbng1-internal
Name: lbng1-internal
Architecture: x86_64
Created: 2016/03/31 08:23 UTC
Status: Running
Type: persistent
Profiles: dev_br23, dev_br250
Pid: 17528
Processes: 27
Ips:
eth0: inet10.35.15.28 vethASE3RF
eth0: inet6 fe80::216:3eff:fe9d:8fc7vethASE3RF
eth1: inet6 fe80::216:3eff:fe75:5c3dvethH2QO2P
lo: inet127.0.0.1
lo: inet6 ::1
Am I missing something very obvious?
Thanks!
CONFIDENTIALITY NOTICE: This email message (and any attachment) is intended
only for the individual or entity to which it is addressed. The information in
this email is confidential and may contain information that is legally
privileged or exempt from disclosure under applicable law. If you are not the
intended recipient, you are strictly prohibited from reading, using, publishing
or disseminating such information and upon receipt, must permanently delete the
original and destroy any copies. We take steps to protect against viruses and
other defects but advise you to carry out your own checks and precautions as
Kambi does not accept any liability for any which remain. Thank you for your
co-operation.
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] lxd images error
Hello, you need to upgrade all lxd and lxc packages, not only the lxd ones. That will solve the compatibility issues. On 03/01/2016 09:07 PM, 술욱 wrote: > Hello, > > upgraded to what? I'm running wily and I have the same error: > > error: json: cannot unmarshal string into Go value of type int64 > > > Thanks, > Norberto > > > > 2016-02-25 9:36 GMT-03:00 laurent ducos <laurentdu...@gmail.com > <mailto:laurentdu...@gmail.com>>: > > ok i have upgraded lxd and all is ok now. Sorry for the noise > > Le jeu. 25 févr. 2016 à 09:08, laurent ducos > <laurentdu...@gmail.com <mailto:laurentdu...@gmail.com>> a écrit : > > sorry for the first post. > The error is > lxc image list images: error: json: cannot unmarshal string > into Go value of type int64 > Same error when i want to launch a image. > > Le mer. 24 févr. 2016 à 10:23, laurent ducos > <laurentdu...@gmail.com <mailto:laurentdu...@gmail.com>> a écrit : > > Hello i have a problem with lxd this morning : > > lxc list images: error: not found > > However images.linuxcontainers.org > <http://images.linuxcontainers.org> is correctly setting > > lxc remote list > > +-+-++ > | NAME | URL | PUBLIC | > > +-+-++ > | images | https://images.linuxcontainers.org:8443 | YES | > | local (default) | unix:// | NO | > > +-+-++ > > > I'm on ubuntu wily. lxd --version 2.0.0.beta3 > > > > > > ___________ > lxc-users mailing list > lxc-users@lists.linuxcontainers.org > <mailto:lxc-users@lists.linuxcontainers.org> > http://lists.linuxcontainers.org/listinfo/lxc-users > > -- Nicola Volpini Infrastructure Engineer i...@nicolavolpini.net www.nicolavolpini.net LinkedIn: http://lnkd.in/bEZjiJh ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] move from LXC (custom templates) to LXD
On 02/09/2016 11:38 AM, Flo wrote: > Dear list, > > > > As we've got a company policy to host all software > we do use in-house > we have to create our own LXD image server. Is there any documentation > about how to do so? How to create those images? Hello, I'm interested in some form of documentation as well. Right now I'm placing the images on a repository that serves the tgz images over http, so I can wget and import them. I'd like to replicate the catalog+repo structure of http://images.linuxcontainers.org/. -- Nicola Volpini Infrastructure Engineer i...@nicolavolpini.net www.nicolavolpini.net LinkedIn: http://lnkd.in/bEZjiJh ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] lxc exec - is there a way to run command in the background?
On 01/29/2016 07:24 AM, Serge Hallyn wrote: > Hm, well at least > > nohup lxc exec container -- sleep 2h & > > works for me. I would have expected --mode=non-interactive to > work, but it doesn't. I was wondering the very same thing yesterday evening. I noticed the non-interactive mode actually does something different: if you ctrl-c, the stdout output will stop but the command will keep running inside the container. The command dies on ctrl-c if you use the default mode. Now, if only all commands had a "silent" or "quiet" mode... I'm using this to generate a dhparams file via openssl and there's no "silent" mode. -- Nicola Volpini Infrastructure Operations Engineer CONFIDENTIALITY NOTICE: This email message (and any attachment) is intended only for the individual or entity to which it is addressed. The information in this email is confidential and may contain information that is legally privileged or exempt from disclosure under applicable law. If you are not the intended recipient, you are strictly prohibited from reading, using, publishing or disseminating such information and upon receipt, must permanently delete the original and destroy any copies. We take steps to protect against viruses and other defects but advise you to carry out your own checks and precautions as Kambi does not accept any liability for any which remain. Thank you for your co-operation. ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
[lxc-users] Thoughts on containers to virtualize a Load Balancer's virtual contexts
Hello, I've been closely observing LXC's development and I'm thrilled by how fast it grew. Well done! We are currently planning to deploy a software load balancer solution. The LB will serve various VIPs, some exposed to the internet, some used internally. Based on this, we would like to use LXC unprivileged containers to isolate the load balancer processes, in a setup like this: Host: Br0 - connected to the internal network Br1 - exposed to the internet Container0: eth0 - attached to br0 Container1 (internet facing): eth0 - attached to br0 eth1 - attached to br1 I initially ruled out LXD since it's apparently very young and wanted to base everything on LXC, solid and tested. Playing with LXD, though, I realized how much more convenient it is from an automation point of view: we could configure our containers in non-modal mode via ansible instead of creating/editing files, and stuff like that. So, a few questions: 1. would the setup layout described above make sense? 2. would it be a risky bet to base the project on LXD instead of pure LXC? Since LXD uses LXC, I can't see any big security/stability risks. I suppose the only concern would be related to changes in the file format or in the CLI in later versions. 3. would it be convenient to build our own templates? I need to be able to preseed certain files like the monitoring agent, the authentication, and so on into the containers during the installation. An alternative would be to use Ansible but that would require me to specify the initial users anyway, one way or another. 4. related to templates: I can't find any documentation in the wild. Any good resource you can point me to, so I can start studying? Thank you! CONFIDENTIALITY NOTICE: This email message (and any attachment) is intended only for the individual or entity to which it is addressed. The information in this email is confidential and may contain information that is legally privileged or exempt from disclosure under applicable law. If you are not the intended recipient, you are strictly prohibited from reading, using, publishing or disseminating such information and upon receipt, must permanently delete the original and destroy any copies. We take steps to protect against viruses and other defects but advise you to carry out your own checks and precautions as Kambi does not accept any liability for any which remain. Thank you for your co-operation. ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] Thoughts on containers to virtualize a Load Balancer's virtual contexts
On 01/22/2016 04:09 PM, Steve Hayman wrote: > I'm currently running 1270 LXC containers in my production > environment, all serving a similar function to that which you describe. Hello Steve, Nice, I suppose you're happy with the stability, considering the number of containers you run :) > 3.Ansible/bash and the LXC clone function are extremely useful for this! > 4.We specifically have some ansible scripts that create the base > container on each new host, pre-seeded with all the other keys and > setup scripts. When we need a new container we clone this one and then > execute the setup scripts passing in the relevant variables. Seems like a sane approach, I like it. Do you do the pre-seed of all the necessary packages by means of a series of "lxc-execute" commands on the host, by chance? I was thinking of pushing a bash script to the container and running it from inside, but that becomes a bit unreadable. I'd rather have the "lxc-execute" commands listed one by one in ansible and run the playbook against the host, if possible. I wonder if that's the approach you use. Thanks for the helpful reply, I'll be happily get in contact with you in case of questions! > > I'd be happy to go into greater detail if you were interested in > hearing more granular details about how we make it all work! > > Thanks, > -Steve > > On Fri, Jan 22, 2016 at 4:46 AM, Nicola Volpini > <nicola.volp...@kambi.com <mailto:nicola.volp...@kambi.com>> wrote: > > Hello, > > I've been closely observing LXC's development and I'm thrilled by how > fast it grew. Well done! > > We are currently planning to deploy a software load balancer solution. > The LB will serve various VIPs, some exposed to the internet, some > used > internally. > Based on this, we would like to use LXC unprivileged containers to > isolate the load balancer processes, in a setup like this: > > Host: > Br0 - connected to the internal network > Br1 - exposed to the internet > > Container0: > eth0 - attached to br0 > > Container1 (internet facing): > eth0 - attached to br0 > eth1 - attached to br1 > > I initially ruled out LXD since it's apparently very young and > wanted to > base everything on LXC, solid and tested. > Playing with LXD, though, I realized how much more convenient it > is from > an automation point of view: we could configure our containers in > non-modal mode via ansible instead of creating/editing files, and > stuff > like that. > > So, a few questions: > 1. would the setup layout described above make sense? > 2. would it be a risky bet to base the project on LXD instead of pure > LXC? Since LXD uses LXC, I can't see any big security/stability > risks. I > suppose the only concern would be related to changes in the file > format > or in the CLI in later versions. > 3. would it be convenient to build our own templates? I need to be > able > to preseed certain files like the monitoring agent, the > authentication, > and so on into the containers during the installation. An alternative > would be to use Ansible but that would require me to specify the > initial > users anyway, one way or another. > 4. related to templates: I can't find any documentation in the > wild. Any > good resource you can point me to, so I can start studying? > > Thank you! > > > CONFIDENTIALITY NOTICE: This email message (and any attachment) is > intended only for the individual or entity to which it is > addressed. The information in this email is confidential and may > contain information that is legally privileged or exempt from > disclosure under applicable law. If you are not the intended > recipient, you are strictly prohibited from reading, using, > publishing or disseminating such information and upon receipt, > must permanently delete the original and destroy any copies. We > take steps to protect against viruses and other defects but advise > you to carry out your own checks and precautions as Kambi does not > accept any liability for any which remain. Thank you for your > co-operation. > ___ > lxc-users mailing list > lxc-users@lists.linuxcontainers.org > <mailto:lxc-users@lists.linuxcontainers.org> > http://lists.linuxcontainers.org/listinfo/lxc-users > > > > > -- > > Stephen Hayman | Zoey Commerce | Ops > > http://www.zoeycommerce.com > ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
