New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add systemd-nspawn connection driver #14334

Closed
wants to merge 1 commit into
base: devel
from

Conversation

Projects
None yet
9 participants
@larsks
Contributor

larsks commented Feb 5, 2016

This commit adds a connection driver built on top of systemd-nspawn.
This is similar to the existing chroot driver, except that nspawn
offers a variety of additional services. For example, it takes care of
automatically mounting /proc and /sys inside the chroot environment,
which will make a variety of tools work correctly that would otherwise
fail.

You can take advantage of other system-nspawn features to perform more
complicated tasks. For example, on my x86_64 system I have a Raspberry
Pi disk image mounted on /rpi. I can't use chroot with this because
the binaries contained in the image are for the wrong architecture.
However, I can use the systemd-nspawn --bind option to automatically
insert the appropriate qemu-arm binary into the container using an
inventory file like this:

pi ansible_host=/rpi ansible_nspawn_extra_args='--bind /usr/bin/qemu-arm --bind /lib64'

See http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html
for more information about systemd-nspawn itself.

@jimi-c jimi-c added this to the 2.1.0 milestone Feb 5, 2016

add systemd-nspawn connection driver
This commit adds a connection driver built on top of systemd-nspawn.
This is similar to the existing `chroot` driver, except that nspawn
offers a variety of additional services. For example, it takes care of
automatically mounting `/proc` and `/sys` inside the chroot environment,
which will make a variety of tools work correctly that would otherwise
fail.

You can take advantage of other system-nspawn features to perform more
complicated tasks.  For example, on my x86_64 system I have a Raspberry
Pi disk image mounted on `/rpi`.  I can't use `chroot` with this because
the binaries contained in the image are for the wrong architecture.
However, I can use the systemd-nspawn `--bind` option to automatically
insert the appropriate qemu-arm binary into the container using an
inventory file like this:

    pi ansible_host=/rpi ansible_nspawn_extra_args='--bind /usr/bin/qemu-arm --bind /lib64'

See http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html
for more information about systemd-nspawn itself.
@larsks

This comment has been minimized.

Contributor

larsks commented Feb 8, 2016

Made a short write-up of this driver here

@gdamjan

This comment has been minimized.

Contributor

gdamjan commented Jun 13, 2016

Any future to this PR?

@larsks

This comment has been minimized.

Contributor

larsks commented Jun 13, 2016

@gdamjan don't know; there's been no interest from the ansible side...

@bcoca bcoca modified the milestones: 2.2.0, stable-2.1 Jun 13, 2016

@bcoca

This comment has been minimized.

Member

bcoca commented Jun 13, 2016

There is a huge backlog, which means we don't always get to pay attention to every ticket. We have been reducing it but have not had time to look at this in depth.

@@ -286,6 +286,8 @@ def base_parser(usage="", output_opts=False, runas_opts=False, meta_opts=False,
help="specify extra arguments to pass to scp only (e.g. -l)")
connect_group.add_option('--ssh-extra-args', default='', dest='ssh_extra_args',
help="specify extra arguments to pass to ssh only (e.g. -R)")
connect_group.add_option('--nspawn-extra-args', default='', dest='nspawn_extra_args',
help="specify extra arguments to pass to systemd-nspawn only (e.g. --bind)")

This comment has been minimized.

@bcoca

bcoca Jun 13, 2016

Member

i would prefer to not add more connection specific arguments

sftp_extra_args = ('ansible_sftp_extra_args',),
scp_extra_args = ('ansible_scp_extra_args',),
ssh_extra_args = ('ansible_ssh_extra_args',),
nspawn_extra_args = ('ansible_nspawn_extra_args',),

This comment has been minimized.

@bcoca

bcoca Jun 13, 2016

Member

this really does not need to be here, the connection plugin itself can look for it

_timeout = FieldAttribute(isa='int', default=C.DEFAULT_TIMEOUT)
_shell = FieldAttribute(isa='string')
_nspawn_args = FieldAttribute(isa='string', default=C.ANSIBLE_NSPAWN_ARGS)
_nspawn_extra_args = FieldAttribute(isa='string')

This comment has been minimized.

@bcoca

bcoca Jun 13, 2016

Member

again, these items should be restricted to the connection plugin itself

@gdamjan

This comment has been minimized.

Contributor

gdamjan commented Jun 13, 2016

I guess any additional settings nspawn needs can be specified in the environment? what about a section in ansible.cfg?

@bcoca

This comment has been minimized.

Member

bcoca commented Jun 13, 2016

The section in ansible.cfg is fine, as well as inventory connection vars, they just need to be queried from the connection plugin (i believe winrm has good example of this).

@@ -244,6 +244,7 @@ def load_config_file():
ANSIBLE_SSH_PIPELINING = get_config(p, 'ssh_connection', 'pipelining', 'ANSIBLE_SSH_PIPELINING', False, boolean=True)
ANSIBLE_SSH_RETRIES = get_config(p, 'ssh_connection', 'retries', 'ANSIBLE_SSH_RETRIES', 0, integer=True)
PARAMIKO_RECORD_HOST_KEYS = get_config(p, 'paramiko_connection', 'record_host_keys', 'ANSIBLE_PARAMIKO_RECORD_HOST_KEYS', True, boolean=True)
ANSIBLE_NSPAWN_ARGS = get_config(p, 'nspawn_connection', 'nspawn_args', 'ANSIBLE_NSPAWN_ARGS', '-q')

This comment has been minimized.

@bcoca

bcoca Jun 13, 2016

Member

I would add (commented out) example in examples/ansible.cfg

@dacresni

This comment has been minimized.

dacresni commented on e8aeb31 Sep 3, 2016

are you going to rebase this like they ask?

@ansibot ansibot added the affects_2.3 label Dec 13, 2016

@ansibot ansibot added needs_rebase and removed needs_rebase labels Jan 2, 2017

@ansibot

This comment has been minimized.

Contributor

ansibot commented Jan 5, 2017

@larsks This PR was tested by travis-ci.org, which is no longer used. Please rebase your branch to trigger running of current tests.

click here for bot help

@ansibot

This comment has been minimized.

Contributor

ansibot commented Jan 6, 2017

@larsks This PR was tested by travis-ci.org, which is no longer used. Please rebase your branch to trigger running of current tests.

click here for bot help

@bcoca

This comment has been minimized.

Member

bcoca commented Mar 9, 2017

so while adding a 'clean' version i realized systemd-nspawn is only useful to create a new instance and not a way to send commands to existing instances (machinectl might fit the bill but return codes seem a mess).

In it's current form this does not qualify as a connection plugin as only the 1st command sent can work, the rest will fail as the instance is 'already running', the first will also fail if that was the case.

@bcoca bcoca unassigned abadger and bcoca Mar 9, 2017

@gdamjan

This comment has been minimized.

Contributor

gdamjan commented Mar 10, 2017

how do you mean it'll be running?

systemd-nspawn -D /path/to/container command will run the command and exit, nothing is left running. in the non-boot (-b) form nspawn is a glorified chroot.

@bcoca

This comment has been minimized.

Member

bcoca commented Mar 10, 2017

@gdamjan which makes it impossible to actually modify a container when it has an a running service/command, which is expected to be possible via the connection plugins, also this limits access to a single instance, while no other connection does this.

@gdamjan

This comment has been minimized.

Contributor

gdamjan commented Mar 11, 2017

ok, I understand. My usecase was mainly about "containers" that are not running (yet) when configured by ansible, but I see how that's not complete.

@ansibot

This comment has been minimized.

Contributor

ansibot commented Apr 11, 2017

@larsks Greetings! Thanks for taking the time to open this pullrequest. In order for the community to handle your pullrequest effectively, we need a bit more information.

Here are the items we could not find in your description:

  • issue type

Please set the description of this pullrequest with this template:
https://raw.githubusercontent.com/ansible/ansible/devel/.github/PULL_REQUEST_TEMPLATE.md

click here for bot help

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment