[arch-general] Building in docker?
For various reasons I'm looking into not using `makechrootpkg` when building the 200+ packages I put into a non-official repo. Obviously it's important to keep the building environment separate from my ordinary system environment. Going to full virtualisation is definitely overkill and the only containers I know of are chroots and docker. Docker has some nice attributes, in particular no need for root access. However, I don't know a whole lot about it, so I wonder are there any aspects to it that makes it a bad choice for building packages? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus Heuristic is an algorithm in a clown suit. It’s less predictable, it’s more fun, and it comes without a 30-day, money-back guarantee. -- Steve McConnell, Code Complete
On 03-09-2014 08:04, Magnus Therning wrote:
For various reasons I'm looking into not using `makechrootpkg` when building the 200+ packages I put into a non-official repo. Obviously it's important to keep the building environment separate from my ordinary system environment. Going to full virtualisation is definitely overkill and the only containers I know of are chroots and docker.
I'm not sure if you are including systemd-nspawn in the chroot category, if not then give it a try. I tend to think of it as chroot on steroids :D -- Mauro Santos
On Wed, Sep 03, 2014 at 09:17:32AM +0100, Mauro Santos wrote:
On 03-09-2014 08:04, Magnus Therning wrote:
For various reasons I'm looking into not using `makechrootpkg` when building the 200+ packages I put into a non-official repo. Obviously it's important to keep the building environment separate from my ordinary system environment. Going to full virtualisation is definitely overkill and the only containers I know of are chroots and docker.
I'm not sure if you are including systemd-nspawn in the chroot category, if not then give it a try. I tend to think of it as chroot on steroids :D
I believe `arch-chroot` uses systemd-nspawn, so in fact it's what I meant with "chroot". :) /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus Perl is another example of filling a tiny, short-term need, and then being a real problem in the longer term. -- Alan Kay
On Wed, Sep 03, 2014 at 09:04:37AM +0200, Magnus Therning wrote:
For various reasons I'm looking into not using `makechrootpkg` when building the 200+ packages I put into a non-official repo. Obviously it's important to keep the building environment separate from my ordinary system environment. Going to full virtualisation is definitely overkill and the only containers I know of are chroots and docker.
If by chroot you mean also nspawn, then it is mostly equivalent to docker and lxc. The only thing bad about systemd-nspawn is its lack of easy config through files (it only supports cmdline switches which is ridiculously cumbersome). Also, docker is more complex than a plain lxc-tools approach. So, I would go with lxc as the simplest and most flexible solution. In fact, that's how I build my packages.
Docker has some nice attributes, in particular no need for root access. However, I don't know a whole lot about it, so I wonder are
Where do you take this from? Rootless containers require a specific host kernel configuration (which -ARCH kernels don't have). Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On Wed, Sep 03, 2014 at 12:36:23PM -0400, Leonid Isaev wrote:
On Wed, Sep 03, 2014 at 09:04:37AM +0200, Magnus Therning wrote:
For various reasons I'm looking into not using `makechrootpkg` when building the 200+ packages I put into a non-official repo. Obviously it's important to keep the building environment separate from my ordinary system environment. Going to full virtualisation is definitely overkill and the only containers I know of are chroots and docker.
If by chroot you mean also nspawn, then it is mostly equivalent to docker and lxc. The only thing bad about systemd-nspawn is its lack of easy config through files (it only supports cmdline switches which is ridiculously cumbersome). Also, docker is more complex than a plain lxc-tools approach.
So, I would go with lxc as the simplest and most flexible solution. In fact, that's how I build my packages.
Oki, I've never looked at lxc, I was under the impression that docker used to build on lxc in the past. Is that not true any longer? Is there a template included for Arch? That would be quite nice because building the docker image for Arch is a bit ugly I'd say.... Finally, what about running a 32bit container on a 64bit host? I've not managed to find any indication that this is officially supported in docker, but it seems to work just fine.
Docker has some nice attributes, in particular no need for root access. However, I don't know a whole lot about it, so I wonder are
Where do you take this from? Rootless containers require a specific host kernel configuration (which -ARCH kernels don't have).
Well, I'm probably imprecise here. What I meant was that after the service has been started (which requires root) any user in the docker group can start images. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus Goto labels should be left-aligned in all caps and should include the programmer's name, home phone number, and credit card number. -- Abdul Nizar
On Wed, Sep 03, 2014 at 10:26:11PM +0200, Magnus Therning wrote:
Oki, I've never looked at lxc, I was under the impression that docker used to build on lxc in the past. Is that not true any longer?
It was true, yes, but I don't think it is now. Although, I can't find a link ATM.
Is there a template included for Arch? That would be quite nice because building the docker image for Arch is a bit ugly I'd say....
Yes. It is a bit messy IMHO because it is being maintaned by several people... So, I always manually create my containers, but then again, I always have a config lying around.
Finally, what about running a 32bit container on a 64bit host? I've not managed to find any indication that this is officially supported in docker, but it seems to work just fine.
This is supported.
Docker has some nice attributes, in particular no need for root access. However, I don't know a whole lot about it, so I wonder are
Where do you take this from? Rootless containers require a specific host kernel configuration (which -ARCH kernels don't have).
Well, I'm probably imprecise here. What I meant was that after the service has been started (which requires root) any user in the docker group can start images.
Yeah, I kinda dislike these "daemon + privileged group" things -- reminds me of polkit. With lxc, you'll need to have a container running and connect to it via SSH or VNC. For me this is OK because my build container is on a desktop and I usually access it from a laptop... HTH, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On Wed, Sep 03, 2014 at 12:36:23PM -0400, Leonid Isaev wrote:
On Wed, Sep 03, 2014 at 09:04:37AM +0200, Magnus Therning wrote:
For various reasons I'm looking into not using `makechrootpkg` when building the 200+ packages I put into a non-official repo. Obviously it's important to keep the building environment separate from my ordinary system environment. Going to full virtualisation is definitely overkill and the only containers I know of are chroots and docker.
If by chroot you mean also nspawn, then it is mostly equivalent to docker and lxc. The only thing bad about systemd-nspawn is its lack of easy config through files (it only supports cmdline switches which is ridiculously cumbersome). Also, docker is more complex than a plain lxc-tools approach.
As always complex doesn't automatically translate to complicated ;) In this particular case I had no issues with following the instructions I found on docker. While when spending the same amount of time on getting lxc to work I get stuck almost immediately: ~~~~ % lxc-create -n test -t archlinux lxc_container: No mapping for container root lxc_container: Error chowning /home/magnus/.local/share/lxc/test/rootfs to container root lxc_container: Error creating backing store type (none) for test lxc_container: Error creating container test ~~~~ And quick googling didn't turn up anything useful. Reading through the Linux Containers page [1] didn't help either. /M [1]: https://wiki.archlinux.org/index.php/Linux_Containers -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus In a hierarchy, every employee tends to rise to his level of incompetence. -- The Peter Principle
Magnus, did you run that lxc-create with root rights? On 4 September 2014 07:24, Magnus Therning <magnus@therning.org> wrote:
On Wed, Sep 03, 2014 at 12:36:23PM -0400, Leonid Isaev wrote:
On Wed, Sep 03, 2014 at 09:04:37AM +0200, Magnus Therning wrote:
For various reasons I'm looking into not using `makechrootpkg` when building the 200+ packages I put into a non-official repo. Obviously it's important to keep the building environment separate from my ordinary system environment. Going to full virtualisation is definitely overkill and the only containers I know of are chroots and docker.
If by chroot you mean also nspawn, then it is mostly equivalent to docker and lxc. The only thing bad about systemd-nspawn is its lack of easy config through files (it only supports cmdline switches which is ridiculously cumbersome). Also, docker is more complex than a plain lxc-tools approach.
As always complex doesn't automatically translate to complicated ;)
In this particular case I had no issues with following the instructions I found on docker. While when spending the same amount of time on getting lxc to work I get stuck almost immediately:
~~~~ % lxc-create -n test -t archlinux lxc_container: No mapping for container root lxc_container: Error chowning /home/magnus/.local/share/lxc/test/rootfs to container root lxc_container: Error creating backing store type (none) for test lxc_container: Error creating container test ~~~~
And quick googling didn't turn up anything useful. Reading through the Linux Containers page [1] didn't help either.
/M
[1]: https://wiki.archlinux.org/index.php/Linux_Containers
-- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus
In a hierarchy, every employee tends to rise to his level of incompetence. -- The Peter Principle
On 4 Sep 2014 20:00, "Neven Sajko" <nsajko@gmail.com> wrote:
Magnus, did you run that lxc-create with root rights?
No, I did not. I thought that might be case, but there were no explicit mentions of this and all the usual visual cues in the docs were missing (no calls to 'sudo' and the prompt was $). But in my search for it I read about configuration of networking with explicit bridge configuration and stuff and I decided to abandon the effort. /M
On Thu, Sep 04, 2014 at 07:24:36AM +0200, Magnus Therning wrote:
As always complex doesn't automatically translate to complicated ;)
In this particular case I had no issues with following the instructions I found on docker. While when spending the same amount of time on getting lxc to work I get stuck almost immediately:
~~~~ % lxc-create -n test -t archlinux lxc_container: No mapping for container root lxc_container: Error chowning /home/magnus/.local/share/lxc/test/rootfs to container root lxc_container: Error creating backing store type (none) for test lxc_container: Error creating container test ~~~~
And quick googling didn't turn up anything useful. Reading through the Linux Containers page [1] didn't help either.
No, this will not work because lxc-create needs root privileges for a variety of things. You'll need to have user_ns enabled in the kernel to accomplish this as a normal user. Note, that docker is not much better, it's just uses a privileged daemon to do things. IIRC, currently running lxc-* as a normal user will work out-of-the-box only on an Ubuntu 14.04 host. Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
I have a very simple container that I use for building Arch packages, just added it to the Docker Hub so others can use it: https://registry.hub.docker.com/u/tazjin/arch-pkgbuild/ It's basically an Arch container that gets updated at image create time and has base-devel installed. When running the container it automatically executes makepkg from /build. To try enter a folder with a PKGBUILD and just run docker run --rm -v $(pwd):/build tazjin/arch-pkgbuild and it'll install the dependencies in the container and build the package. Note that because of the minimal system the build dependencies need to be correct. The mirrorlist in the container is using servers in Sweden, you could replace it though if you wanted. 2014-09-03 9:04 GMT+02:00 Magnus Therning <magnus@therning.org>:
For various reasons I'm looking into not using `makechrootpkg` when building the 200+ packages I put into a non-official repo. Obviously it's important to keep the building environment separate from my ordinary system environment. Going to full virtualisation is definitely overkill and the only containers I know of are chroots and docker.
Docker has some nice attributes, in particular no need for root access. However, I don't know a whole lot about it, so I wonder are there any aspects to it that makes it a bad choice for building packages?
/M
-- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus
Heuristic is an algorithm in a clown suit. It’s less predictable, it’s more fun, and it comes without a 30-day, money-back guarantee. -- Steve McConnell, Code Complete
On Thu, Sep 04, 2014 at 09:11:17PM +0200, Vincent Ambo wrote:
I have a very simple container that I use for building Arch packages, just added it to the Docker Hub so others can use it: https://registry.hub.docker.com/u/tazjin/arch-pkgbuild/
It's basically an Arch container that gets updated at image create time and has base-devel installed. When running the container it automatically executes makepkg from /build.
To try enter a folder with a PKGBUILD and just run
docker run --rm -v $(pwd):/build tazjin/arch-pkgbuild
and it'll install the dependencies in the container and build the package. Note that because of the minimal system the build dependencies need to be correct.
The mirrorlist in the container is using servers in Sweden, you could replace it though if you wanted.
Very nice. I can definitely use it as a base for my building. One thing though, I can't seem to find any pre-built 32-bit image though. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus In a hierarchy, every employee tends to rise to his level of incompetence. -- The Peter Principle
Very nice. I can definitely use it as a base for my building. One thing though, I can't seem to find any pre-built 32-bit image though.
You might have to bootstrap an Arch base container with 32-bit yourself. Should be doable by running the mkimage-arch script in a 32-bit VM: https://github.com/docker/docker/blob/master/contrib/mkimage-arch.sh If you do this and push it to the hub I can build my image with that as the base as well, or you could adapt my Dockerfile and use that. //V
-- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus
In a hierarchy, every employee tends to rise to his level of incompetence. -- The Peter Principle
I have a very simple container that I use for building Arch packages, just added it to the Docker Hub so others can use it: https://registry.hub.docker.com/u/tazjin/arch-pkgbuild/
I just want to share with you my Docker image as well, which adds a couple of features to Vincent's, which are: - Allows to specify the desired uid for generated files at "docker run"- time. This allow to use the image directly from the registry without needing to re-build it. - It specify Git's global user.name and user.email to allow cloning from servers that requires them. Hope it's useful as well for you: https://hub.docker.com/r/aitorpazos/archlinux-docker-makepkg/ Cheers, Aitor Pazos Instant Messaging (Jabber, GTalk): aitor@aitorpazos.es PGP Public Key: http://aitorpazos.es/publickey.asc
participants (6)
-
Aitor Pazos
-
Leonid Isaev
-
Magnus Therning
-
Mauro Santos
-
Neven Sajko
-
Vincent Ambo