Hi,
How can I tell juju to use my local lxd image server for units that needs lxd machine?
This might be worth asking on https://discuss.linuxcontainers.org/ - pointing a nested (inner-host) image server to it’s outer host?
Previously to speed up testing of various Juju setups, I’ve done the following, which allows a nested container to also manage a out-host LXD:
lxc config device add <container-name> lxdsocket proxy connect=unix:/var/snap/lxd/common/lxd/unix.socket listen=unix:/var/snap/lxd/common/lxd/unix.socket bind=container uid=0 gid=108 mode=0660 security.uid=65534 security.gid=130
Let me explain my situation:
I have a MAAS server with bunch of ready machines to be deployed with juju.
I want to use juju to install openstack with a regular bundle. so far it is fine.
the bundle provisions 3 nodes and within each node, installs some lxd containers.
the problem arises here where lxd tries to pull/download images from the internet every time.
I want to make juju obtain images from a local server.
I have seen this topic
but I don’t know if it works with MAAS.
Each machine (0, 1, etc) has it’s very own LXD, which means that it has it’s very own image server. So nested deployments talk to that LXD to create the individual container (0/lxd/<container>, 1/lxd/<container>, etc). Currently we don’t set up any unique outer-host image server for all inner-host LXDs to talk to. This is why you’re forced to re-download the focal image every time.
This is a feature request that you could open a bug for so we can prioritise correctly.
Note: there are issues around ingress/egress rules on how we can talk to that image server for all scenarios that would need to understand, hence why it’s not been done before. If you can work out how to configure the outer-host image server for a LXD then point the inner-host LXDs then you should be good.
Yea, you are right,
Now lets look at this scenario:
what do you think if I create a custom ubuntu/focal image and then install lxd and add the image into lxd images then use the custom OS in MAAS as default commissioning image, will it work ?
I mean the container within my Custom OS will use the local image ?
Have a look at the model configuration values for:
- container-image-metadata-url
- container-image-stream
There are some hoops to jump through here. To use your own custom images you need to serve a streams file that points to image blobs.
The default location, https://cloud-images.ubuntu.com/releases/streams/v1/index.json serves as an example.
The LP bug you linked only applies to the LXD provider, not to containers managed on Juju machines. In that case it is simple. Just add the image you want to use and add the appropriate alias.
I’ve also seen this solved as a juju model-config cloudinit-userdata setting for new machines to download and install their lxd images via curl and lxc image commands at a machine’s initial creation (you can change these URLs to point to images you’re hosting). This was used specifically due to a proxy blocking older juju go libraries from making this call with old TLS versions through a secure proxy. We’ve since swapped most of these sites over to use the container-image-metadata-url method described above.
$ juju model-config cloudinit-userdata
postruncmd:
- if hostname |grep -qv lxd; then wget --tries=15 --retry-connrefused --timeout=15 --random-wait=on -O /home/ubuntu/ubuntu-16.04-server-cloudimg-amd64-lxd.tar.xz https://cloud-images.ubuntu.com/releases/xenial/release/ubuntu-16.04-server-cloudimg-amd64-lxd.tar.xz; fi
- if hostname |grep -qv lxd; then wget --tries=15 --retry-connrefused --timeout=15 --random-wait=on -O /home/ubuntu/ubuntu-18.04-server-cloudimg-amd64-lxd.tar.xz https://cloud-images.ubuntu.com/releases/xenial/release/ubuntu-18.04-server-cloudimg-amd64-lxd.tar.xz; fi
- if hostname |grep -qv lxd; then wget --tries=15 --retry-connrefused --timeout=15 --random-wait=on -O /home/ubuntu/ubuntu-16.04-server-cloudimg-amd64.squashfs https://cloud-images.ubuntu.com/releases/xenial/release/ubuntu-16.04-server-cloudimg-amd64.squashfs; fi
- if hostname |grep -qv lxd; then wget --tries=15 --retry-connrefused --timeout=15 --random-wait=on -O /home/ubuntu/ubuntu-18.04-server-cloudimg-amd64.squashfs https://cloud-images.ubuntu.com/releases/xenial/release/ubuntu-18.04-server-cloudimg-amd64.squashfs; fi
- sleep 30 # it seems there is race condition in system lxd startup and cloud init.
- if hostname |grep -qv lxd; then lxc image import /home/ubuntu/ubuntu-16.04-server-cloudimg-amd64-lxd.tar.xz /home/ubuntu/ubuntu-16.04-server-cloudimg-amd64.squashfs --alias juju/xenial/amd64; fi
- if hostname |grep -qv lxd; then lxc image import /home/ubuntu/ubuntu-18.04-server-cloudimg-amd64-lxd.tar.xz /home/ubuntu/ubuntu-18.04-server-cloudimg-amd64.squashfs --alias juju/bionic/amd64; fi
- lxc image list