Using ansible and setting up ssh access from a remote machine

This isn’t a question as much as it is a ‘here’s what I’ve found’ post…

I’ve been testing LXD in VirtualBox, along with using ansible as much as possible to automate setup and so on. Ansible let’s you create containers on a host, once you’ve navigated this snap bug, but I’ve not been able to automatically configure a container so that I can ssh into it and carry on using ansible as-is.

I’ve now got ansible working on a container where I run playbooks on my laptop and then the host and containers are in VirtualBox. A combination of lxc exec mycontainer commands setup ssh access on the container and then the ssh config outlined here worked on my local machine.

While the above works fine, I didn’t get any joy with any of the following approaches based on my setup above…

Ansible’s LXD module seems to work best when it’s run from the container’s host and not an external machine. As a result, I never had any joy with things like this…

    - name: install python in container
      delegate_to: mycontainer
      raw: apt-get install -y python
      when: python_install_check.rc == 1

I also never got anywhere with ansible-sshlxd-connection or ansible-lxc-ssh. They both looked useful but I never got them to work. ansible-lxc-ssh may well not work with lxd though?

These two threads on reddit also looked helpful but didn’t prove to be useful.

I also ran into some problems running lxc exec mycontainer commands in a bash script. I would always get lxc: command not found which was kind of baffling as the same commands ran fine at the prompt…

Aside from baking ssh and a key into an lxd image, has anyone else found a way to get ansible working on a container from an external machine in a more automated manner?

This is fixed in version 3.0.2; it will be available in the default bionic repo soon.

Btw I used cloud-init to install packages and add a user with an SSH public key.

Cool, I guess the snap version on Debian will also get this upgrade? We’re talking about an LXD upgrade here as I think Ansible is on 2.7…

Ok, cool, yeah, you can run cloud-init on Debian…

I’m running the snap version of lxd, do you know when that will be updated?

I have no idea, I just know about the fix because I had a similar issue and Stéphan told me about it in that thread.

According to the Weekly status, it should be there soon.

1 Like

If you run the snap version of LXD, then

$ snap info lxd
name:      lxd
summary:   System container manager and API
publisher: Canonical✓
contact:   https://github.com/lxc/lxd/issues
license:   unset
description: |
  LXD is a container manager for system containers.
  
  It offers a REST API to remotely manage containers over the network, using
  an image based workflow and with support for live migration.
  
  Images are available for all Ubuntu releases and architectures as well as
  for a wide number of other Linux distributions.
  
  LXD containers are lightweight, secure by default and a great alternative
  to virtual machines.
commands:
  - lxd.benchmark
  - lxd.buginfo
  - lxd.check-kernel
  - lxd.lxc
  - lxd
  - lxd.migrate
services:
  lxd.activate: oneshot, enabled, inactive
  lxd.daemon:   simple, enabled, active
snap-id:      J60k4JY0HppjwOjW8dZdYc8obXKxujRu
tracking:     candidate
refresh-date: today at 11:23 EEST
channels:                                
  stable:        3.5         (9010) 69MB -
  candidate:     3.6         (9129) 69MB -
  beta:          ↑                       
  edge:          git-948b8f6 (9163) 69MB -
  3.0/stable:    3.0.2       (8715) 65MB -
  3.0/candidate: 3.0.2       (9043) 68MB -
  3.0/beta:      ↑                       
  3.0/edge:      git-624e200 (9167) 68MB -
  2.0/stable:    2.0.11      (8023) 28MB -
  2.0/candidate: 2.0.11      (8023) 28MB -
  2.0/beta:      ↑                       
  2.0/edge:      git-f3e2b11 (9148) 26MB -
installed:       3.6         (9129) 69MB -

This means that if you did not change the tracking, then you are tracking LXD 3.5.
If you are tracking the stable version 3.0/stable, then you are already on LXD 3.0.2.
If you are unsure, post the output of snap info lxd to verify what you are tracking.

This is what I got…

debian@BR-LXD:~$ snap info lxd
name:      lxd
summary:   System container manager and API
publisher: Canonical✓
license:   unset
description: |
  LXD is a container manager for system containers.
  
  It offers a REST API to remotely manage containers over the network, using an image based workflow
  and with support for live migration.
  
  Images are available for all Ubuntu releases and architectures as well as for a wide number of
  other Linux distributions.
  
  LXD containers are lightweight, secure by default and a great alternative to virtual machines.
commands:
  - lxd.benchmark
  - lxd.buginfo
  - lxd.check-kernel
  - lxd.lxc
  - lxd
  - lxd.migrate
services:
  lxd.activate: oneshot, enabled, inactive
  lxd.daemon:   simple, enabled, active
snap-id:      J60k4JY0HppjwOjW8dZdYc8obXKxujRu
tracking:     stable
refresh-date: 3 days ago, at 16:47 SAST
channels:                                
  stable:        3.5         (9010) 69MB -
  candidate:     3.6         (9129) 69MB -
  beta:          ↑                       
  edge:          git-948b8f6 (9163) 69MB -
  3.0/stable:    3.0.2       (8715) 65MB -
  3.0/candidate: 3.0.2       (9043) 68MB -
  3.0/beta:      ↑                       
  3.0/edge:      git-624e200 (9167) 68MB -
  2.0/stable:    2.0.11      (8023) 28MB -
  2.0/candidate: 2.0.11      (8023) 28MB -
  2.0/beta:      ↑                       
  2.0/edge:      git-f3e2b11 (9148) 26MB -
installed:       3.5         (9010) 69MB devmode

I orginally ran sudo snap install lxd and then lxd init to attached to an existing zfs pool…

You are running LXD 3.5 (snap package) then, and not 3.0.2.

Is this fixed in the 3.6 SNAP version as well?

I do not understand what is the issue that you are facing.

There is a mention of some LXD snap bug but the way I see it, it’s just an issue of setting up the proper LXD remote (run lxc remote).

If you can describe a self-contained minimal example that demonstrates the issue, then I can to replicate and possible help you with a solution.

1 Like

Hi @simos , lxc remote is one possible solution but I’m trying to run ansible on my laptop to run playbooks against containers running on a server. I’ve got a manual work-around going which is fine for now, but @adosztal suggested that this bug, although I don’t know what number the bug has, is going to fix this ansible problem in version 3.0.2…

As I’m running from SNAP do you know what the differences are between 3.0.2 and 3.6?

Also, how can I see how much drive space a particular container is using?

sudo zpool list sorts this one out…

Thanks…