[lxc-users] Advice on LXC usage (python3 binding)

[Ranjib Dey]

- for the composite instructions, write all those instructions in a
temporary file, and execute it as a bash script inside the container.
- you can use s3 or self hosted minio.io or something else straight for
storing container images. LXC itself is not repo aware, templates can
abstract the logic of image repo, and you can use a custom template the
gran images from s3 and expand them.
I use nut [1] to build LXC containers from Dockerfile. You can check out
the source code for how this is achieved in golang. Note: LXD provides the
publishing workflow as well.

[1]https://github.com/pagerduty/nut




On Wed, May 11, 2016 at 4:27 PM, Journeyman <jman at storiepvtride.it> wrote:

> Hello,
>
> I just started using LXC containers in Ubuntu Xenial, my background with
> containers is with Docker, I'm trying to compare the two starting with a
> minimal personal toy project.
>
> I'm interested namely in scripting my container workflow using the LXC
> Python3 binding, which is a great tool and I hope that it will become more
> and more complete as LXC development advances.
>
> Documentation is somewhat minimal, but the API is pretty straightforward
> so I relied on a couple of tutorials by Stéphan Graber (thank you!) and
> scripted a tool that creates and provision an LXC container for continuous
> integration.
>
> What this tool does is basically (using the Python API):
> - lxc-create -t download
> - lots of: container.attach_wait(lxc.attach_run_command, ['this',
> 'this_and_that']
> - lots of: container.attach_wait(lxc.attach_run_command, ['start',
> 'service', 'x_and_y']
>
> Example:
>
> def provision_container(container_name):
>
>     def _configure_and_run_tests():
>         # ... BASH instructions to set ENV variables, then run tests
>         os.chdir('src_directory')
>         ret_code = call(['source', 'virtual/bin/activate'])
>         ret_code = call(['python', 'manage.py', 'tests'])
>         # export this and that ....
>         print("Tests returned {}: {}".format(ret_code)
>
>     container = lxc.Container(container_name)
>     start_container(container)
>
>     # install and configure stuff
>     container.attach_wait(lxc.attach_run_command,
>         ["apt-get", "update"])
>     container.attach_wait(lxc.attach_run_command,
>         ["apt-get", "dist-upgrade", "-y"])
>     container.attach_wait(lxc.attach_run_command,
>         ['apt-get', 'install', '-qy', 'python-pip', 'python-dev'])
>     container.attach_wait(lxc.attach_run_command,
>         ['pip', 'install', '--upgrade', '-q', 'pip'])
>     container.attach_wait(lxc.attach_run_command,
>         ['pip', 'install', '--upgrade', '-q', 'virtualenv'])
>     container.attach_wait(lxc.attach_run_command,
>         ['apt-get', 'install', '-qy', 'rabbitmq-server'])
>     # and so on ...
>
>     # start services
>     container.attach_wait(lxc.attach_run_command,
>        ['sudo ', 'service', 'svcname', 'start'])
>     # etc...
>     container.attach_wait(_configure_and_run_tests)
>
>
> I have a couple a questions:
>
> - some instructions are one-liners (e.g. APT installs), others require to
> "cd" into a dir, "export" variables and run other BASH commands before
> executing the real task. When I have such composite instructions - in the
> above example _configure_and_run_tests() - the only way I understand to run
> a block of instructions atomically is creating a subroutine and use it to
> run that block altogether. In this respect I kind of miss the Docker recipe
> file that allows scripting (and caching) every instruction without losing
> its context. Is there a cleaner way to accomplish the above?
>
> - Also I miss a repository like DockerHub to distribute and deploy my
> containers around. If I want to distribute my LXC containers, currently I
> can do that by means of a BASH script that basically packs the rootfs and
> uploads it to a remote server. The destination server should download the
> tar.gz, stop the container, unpack and restart.
> Is there a better/cleaner way to accomplish this too?
>
> Sorry for the lengthy email and thanks for any suggestion and comment; I
> like LXC and I'm looking forward to seeing further development.
>
> Regards,
> Antonio
> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20160512/7b11152d/attachment.html>