Announce: docker-buildpackage

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Announce: docker-buildpackage

Enrico Weigelt, metux IT consult-2
Hi folks,


I've written a tool for isolated deb builds in docker containers.
It's a little bit like pbuilder, but using docker for isolation.

https://github.com/metux/docker-buildpackage

Everything written in shellscript, simple config as sh includes.
Not debianized yet, as it might require some local customizations.
(planned for future releases)

I'm also hacking on another tool which automatically clones repos
and calls dck-buildpackage for building whole pipelines - but that's
still experimental and hackish:

https://github.com/metux/deb-pkg


--mtx

--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
[hidden email] -- +49-151-27565287

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Announce: docker-buildpackage

Thomas Goirand-2
On 05/01/2018 03:23 PM, Enrico Weigelt, metux IT consult wrote:

> Hi folks,
>
>
> I've written a tool for isolated deb builds in docker containers.
> It's a little bit like pbuilder, but using docker for isolation.
>
> https://github.com/metux/docker-buildpackage
>
> Everything written in shellscript, simple config as sh includes.
> Not debianized yet, as it might require some local customizations.
> (planned for future releases)
>
> I'm also hacking on another tool which automatically clones repos
> and calls dck-buildpackage for building whole pipelines - but that's
> still experimental and hackish:
>
> https://github.com/metux/deb-pkg
>
>
> --mtx

Hi,

Frankly, I don't see the point in writing this kind of software. Sbuild
works super well with the overlay backend, and already has throw-able
chroots in tmpfs. Adding docker into this doesn't add any new feature,
and in some way, is less flexible than the already existing sbuild.

Instead, I very much would prefer a patch to puiparts so that it could
use sbuild's schroot system instead of tarballs.

Cheers,

Thomas Goirand (zigo)

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Announce: docker-buildpackage

Chow Loong Jin-3
On Wed, May 02, 2018 at 11:23:56AM +0200, Thomas Goirand wrote:
> [...]
> Frankly, I don't see the point in writing this kind of software. Sbuild
> works super well with the overlay backend, and already has throw-able
> chroots in tmpfs. Adding docker into this doesn't add any new feature,
> and in some way, is less flexible than the already existing sbuild.

Something that comes to mind is network isolation, which sbuild still
doesn't seem to have proper support[1] for:

[1] https://wiki.debian.org/sbuild#Disabling_network_access_for_dpkg-buildpackage

--
Kind regards,
Loong Jin

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Announce: docker-buildpackage

Johannes Schauer
Quoting Chow Loong Jin (2018-05-03 06:27:01)

> On Wed, May 02, 2018 at 11:23:56AM +0200, Thomas Goirand wrote:
> > [...]
> > Frankly, I don't see the point in writing this kind of software. Sbuild
> > works super well with the overlay backend, and already has throw-able
> > chroots in tmpfs. Adding docker into this doesn't add any new feature,
> > and in some way, is less flexible than the already existing sbuild.
>
> Something that comes to mind is network isolation, which sbuild still
> doesn't seem to have proper support[1] for:
>
> [1] https://wiki.debian.org/sbuild#Disabling_network_access_for_dpkg-buildpackage
sbuild cannot have or not have support for network isolation. Network isolation
is a feature of the backend and not of sbuild. In this case, the default sbuild
backend (schroot) does not have support for it yet. The bug is even linked in
the wiki section you quote.

If you want network isolation today, just pick one of the other backends that
sbuild supports via autopkgtest (the lxc backend probably supports network
isolation). If you want network isolation with the schroot backend, then you
have to improve schroot and not sbuild.

I also think that, if you want a docker builder today, it would be *much*
easier to just add a docker backend to an existing package building software
like pbuilder or sbuild and thus avoid re-implementing all the "package
building" logic and focus on the docker specific things instead.

Thanks!

cheers, josch

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Announce: docker-buildpackage

Martin Pitt-4
In reply to this post by Chow Loong Jin-3
Chow Loong Jin [2018-05-03 12:27 +0800]:

> On Wed, May 02, 2018 at 11:23:56AM +0200, Thomas Goirand wrote:
> > [...]
> > Frankly, I don't see the point in writing this kind of software. Sbuild
> > works super well with the overlay backend, and already has throw-able
> > chroots in tmpfs. Adding docker into this doesn't add any new feature,
> > and in some way, is less flexible than the already existing sbuild.
>
> Something that comes to mind is network isolation, which sbuild still
> doesn't seem to have proper support[1] for:
>
> [1] https://wiki.debian.org/sbuild#Disabling_network_access_for_dpkg-buildpackage
Not just network, but also process isolation and reducing privileges. schroot
would be way too "leaky" for a production CI system like ci.debian.net or
autopkgtest.ubuntu.com. The existing backend that compare much better to that
are -lxc and -lxd, and IMHO they are superior to docker. lxc and lxd are "full
OS" containers while docker is optimized for application containers and thus
needs some special treatment (like --privileged, which makes the whole thing
rather unsafe and often causes crashes if you try to start udev in the docker
container) to allow really booting a full OS. Usability wise, they are just as
simple as docker too, as linuxcontainers.org has a lot of pre-built OS images
for all kinds of OSes.

So I agree that there is very little point about adding a docker backend other
than "it's possible" (albeit inferior). As long as someone wants to maintain
it, there is little harm in including it.

Martin

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Announce: docker-buildpackage

hugo shepherd
In reply to this post by Johannes Schauer

On Thu, 3 May 2018 at 09:10, Johannes Schauer <[hidden email]> wrote:
Quoting Chow Loong Jin (2018-05-03 06:27:01)
> On Wed, May 02, 2018 at 11:23:56AM +0200, Thomas Goirand wrote:
> > [...]
> > Frankly, I don't see the point in writing this kind of software. Sbuild
> > works super well with the overlay backend, and already has throw-able
> > chroots in tmpfs. Adding docker into this doesn't add any new feature,
> > and in some way, is less flexible than the already existing sbuild.
>
> Something that comes to mind is network isolation, which sbuild still
> doesn't seem to have proper support[1] for:
>
> [1] https://wiki.debian.org/sbuild#Disabling_network_access_for_dpkg-buildpackage

sbuild cannot have or not have support for network isolation. Network isolation
is a feature of the backend and not of sbuild. In this case, the default sbuild
backend (schroot) does not have support for it yet. The bug is even linked in
the wiki section you quote.

If you want network isolation today, just pick one of the other backends that
sbuild supports via autopkgtest (the lxc backend probably supports network
isolation). If you want network isolation with the schroot backend, then you
have to improve schroot and not sbuild.

I also think that, if you want a docker builder today, it would be *much*
easier to just add a docker backend to an existing package building software
like pbuilder or sbuild and thus avoid re-implementing all the "package
building" logic and focus on the docker specific things instead.

Thanks!

cheers, josch
--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel