[RFE] Teach COPR build layered Docker images

[Václav Pavlín]

Hi list,

We came up with an idea how to use Docker in copr at Env&Stacks WG meeting:

Let's say you are a maintainer of few packages or you just want to try 
to change/fix something in some packages. You decide to use copr for 
building these changed packages.

At the moment, when your build is done, you have to install them on your 
system or to some virtual machine which requires some additional typing, 
time and can cause potential problems if you've broken something in the 
code.

My idea would be to enhance copr so that it is able to build layered 
Docker image which would contain newly built packages. User could then 
download/pull the image and run it as container - that could mean either 
run bash there, some specific command or even some automatic test.

I am not sure about the build process yet - we need to discuss it - copr 
can either require Dockerfile from user or the Dockerfile could be 
probably constructed dynamically. Basic Dockerfile would need to add 
repo files and install/update built packages in the image. If we want to 
get it further we could think of adding some configuration, run specific 
command on container start or let user select base image he would like 
to use, but these are implementation details.

Another question that needs to be answered is in what way the built 
image would be provided to the user - it can be either *.tar.gz which he 
could download and call docker load -i or we can have docker registry 
for these images and push them there. User would then be able to run 
docker pull to get the image.

What do you think? Do you think this makes sense for copr?

Thanks & regards,
Vaclav

[Nick Coghlan]

On 07/23/2014 01:42 AM, Václav Pavlín wrote:
> What do you think? Do you think this makes sense for copr?

If we could use COPR to make Beaker packages for Fedora and EPEL *and*
upload Dockerfiles to generate Docker images for the various components,
that would be seriously cool. On the other hand, it might make more
sense as a separate service that reacts to fedmsg events indicating new
COPR builds are available.

Cheers,
Nick.

[Richard Marko]

On 07/23/2014 10:44 AM, Nick Coghlan wrote:
> On 07/23/2014 01:42 AM, Václav Pavlín wrote:
> > What do you think? Do you think this makes sense for copr?
>
> If we could use COPR to make Beaker packages for Fedora and EPEL *and*
> upload Dockerfiles to generate Docker images for the various components,
> that would be seriously cool. On the other hand, it might make more
> sense as a separate service that reacts to fedmsg events indicating new
> COPR builds are available.

+1 for separate service.

[Václav Pavlín]

On St 23. červenec 2014, 13:33:06 CEST, Richard Marko wrote:
> On 07/23/2014 10:44 AM, Nick Coghlan wrote:
> > On 07/23/2014 01:42 AM, Václav Pavlín wrote:
> > > What do you think? Do you think this makes sense for copr?
> >
> > If we could use COPR to make Beaker packages for Fedora and EPEL *and*
> > upload Dockerfiles to generate Docker images for the various components,
> > that would be seriously cool. On the other hand, it might make more
> > sense as a separate service that reacts to fedmsg events indicating new
> > COPR builds are available.
>
> +1 for separate service.

I am not against separate service. The separate service would probably 
simply mean running Docker in some cloud instance and call it's API 
through docker-python bindings and then collect the results.

Vaclav

--

Lead Infrastructure Engineer
Developer Experience
Brno, Czech Republic

[Václav Pavlín]

Could you please have a look at attached diagram briefly describing 
potential architecture of the image building service? Would this be a 
viable solution?

https://vpavlin.fedorapeople.org/copr-docker.svg

Vaclav

On 24.7.2014 10:42, Václav Pavlín wrote:
> On St 23. červenec 2014, 13:33:06 CEST, Richard Marko wrote:
> > On 07/23/2014 10:44 AM, Nick Coghlan wrote:
> > > On 07/23/2014 01:42 AM, Václav Pavlín wrote:
> > > > What do you think? Do you think this makes sense for copr?
> > >
> > > If we could use COPR to make Beaker packages for Fedora and EPEL *and*
> > > upload Dockerfiles to generate Docker images for the various 
> > > components,
> > > that would be seriously cool. On the other hand, it might make more
> > > sense as a separate service that reacts to fedmsg events indicating new
> > > COPR builds are available.
> >
> > +1 for separate service.
>
> I am not against separate service. The separate service would probably 
> simply mean running Docker in some cloud instance and call it's API 
> through docker-python bindings and then collect the results.
>
> Vaclav
>
> --
>
> Lead Infrastructure Engineer
> Developer Experience
> Brno, Czech Republic

[Radek Vokal]

Vasku, I like the idea  and the workflow. If I understand the workflow right - the layered image will build on top of base image picked in COPR (eg. Fedora20 or CentOS7)? Also would it make sense to run our own docker registry and have in connected to docker.io?

Radek

----- Original Message -----
> Could you please have a look at attached diagram briefly describing
> potential architecture of the image building service? Would this be a
> viable solution?
>
> https://vpavlin.fedorapeople.org/copr-docker.svg
>
> Vaclav
>
> On 24.7.2014 10:42, Václav Pavlín wrote:
> > On St 23. červenec 2014, 13:33:06 CEST, Richard Marko wrote:
> > > On 07/23/2014 10:44 AM, Nick Coghlan wrote:
> > > > On 07/23/2014 01:42 AM, Václav Pavlín wrote:
> > > > > What do you think? Do you think this makes sense for copr?
> > > >
> > > > If we could use COPR to make Beaker packages for Fedora and EPEL *and*
> > > > upload Dockerfiles to generate Docker images for the various
> > > > components,
> > > > that would be seriously cool. On the other hand, it might make more
> > > > sense as a separate service that reacts to fedmsg events indicating new
> > > > COPR builds are available.
> > >
> > > +1 for separate service.
> >
> > I am not against separate service. The separate service would probably
> > simply mean running Docker in some cloud instance and call it's API
> > through docker-python bindings and then collect the results.
> >
> > Vaclav
> >
> > --
> >
> > Lead Infrastructure Engineer
> > Developer Experience
> > Brno, Czech Republic
>
> --
>
> Lead Infrastructure Engineer
> Developer Experience
> Brno, Czech Republic
>
> copr-devel mailing list
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/copr-devel

[Václav Pavlín]

On St 6. srpen 2014, 16:13:34 CEST, Radek Vokál wrote:
> Vasku, I like the idea  and the workflow. If I understand the workflow right - the layered image will build on top of base image picked in COPR (eg. Fedora20 or CentOS7)? Also would it make sense to run our own docker registry and have in connected to docker.io?

My idea was to "guess" base image automatically from the 
os-version(-arch) selected by user in COPR - so if the copr build is 
for fedora-20-x86_64, we can say yes, it's 64bit, and use fedora:20 as 
base image.

If we really want to build images, it would make sense to serve them in 
private registry. On the other hand, I've changed my mind since I sent 
this proposal - I am not sure if Fedora infrastructure can/will handle 
building and storing possibly hundreds or thousands of images. I'd like 
to start with a feature that will prepare and let you download a 
Dockerfile which you can then modify locally and build your image.

I need to talk about this with Mirek and people from Fedora 
Infrastructure probably.

Vaclav
> Radek
>
> ----- Original Message -----
> > Could you please have a look at attached diagram briefly describing
> > potential architecture of the image building service? Would this be a
> > viable solution?
> >
> > https://vpavlin.fedorapeople.org/copr-docker.svg
> >
> > Vaclav
> >
> > On 24.7.2014 10:42, Václav Pavlín wrote:
> > > On St 23. červenec 2014, 13:33:06 CEST, Richard Marko wrote:
> > > > On 07/23/2014 10:44 AM, Nick Coghlan wrote:
> > > > > On 07/23/2014 01:42 AM, Václav Pavlín wrote:
> > > > > > What do you think? Do you think this makes sense for copr?
> > > > >
> > > > > If we could use COPR to make Beaker packages for Fedora and EPEL *and*
> > > > > upload Dockerfiles to generate Docker images for the various
> > > > > components,
> > > > > that would be seriously cool. On the other hand, it might make more
> > > > > sense as a separate service that reacts to fedmsg events indicating new
> > > > > COPR builds are available.
> > > >
> > > > +1 for separate service.
> > >
> > > I am not against separate service. The separate service would probably
> > > simply mean running Docker in some cloud instance and call it's API
> > > through docker-python bindings and then collect the results.
> > >
> > > Vaclav
> > >
> > > --
> > >
> > > Lead Infrastructure Engineer
> > > Developer Experience
> > > Brno, Czech Republic
> >
> > --
> >
> > Lead Infrastructure Engineer
> > Developer Experience
> > Brno, Czech Republic
> >
> > copr-devel mailing list
> > [e-mail]
> > https://lists.fedorahosted.org/mailman/listinfo/copr-devel
>
> copr-devel mailing list
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/copr-devel

--

Lead Infrastructure Engineer
Developer Experience
Brno, Czech Republic

[Radek Vokal]

----- Original Message -----
> On St 6. srpen 2014, 16:13:34 CEST, Radek Vokál wrote:
> > Vasku, I like the idea  and the workflow. If I understand the workflow
> > right - the layered image will build on top of base image picked in COPR
> > (eg. Fedora20 or CentOS7)? Also would it make sense to run our own docker
> > registry and have in connected to docker.io?
>
> My idea was to "guess" base image automatically from the
> os-version(-arch) selected by user in COPR - so if the copr build is
> for fedora-20-x86_64, we can say yes, it's 64bit, and use fedora:20 as
> base image.
>
> If we really want to build images, it would make sense to serve them in
> private registry. On the other hand, I've changed my mind since I sent
> this proposal - I am not sure if Fedora infrastructure can/will handle
> building and storing possibly hundreds or thousands of images. I'd like
> to start with a feature that will prepare and let you download a
> Dockerfile which you can then modify locally and build your image.

Well, not everyone will request to build an image and correct me if I'm wrong, but for updates docker only stores diffs.

R
> I need to talk about this with Mirek and people from Fedora
> Infrastructure probably.
>
> Vaclav
> > Radek
> >
> > ----- Original Message -----
> > > Could you please have a look at attached diagram briefly describing
> > > potential architecture of the image building service? Would this be a
> > > viable solution?
> > >
> > > https://vpavlin.fedorapeople.org/copr-docker.svg
> > >
> > > Vaclav
> > >
> > > On 24.7.2014 10:42, Václav Pavlín wrote:
> > > > On St 23. červenec 2014, 13:33:06 CEST, Richard Marko wrote:
> > > > > On 07/23/2014 10:44 AM, Nick Coghlan wrote:
> > > > > > On 07/23/2014 01:42 AM, Václav Pavlín wrote:
> > > > > > > What do you think? Do you think this makes sense for copr?
> > > > > > If we could use COPR to make Beaker packages for Fedora and EPEL *and*
> > > > > > upload Dockerfiles to generate Docker images for the various
> > > > > > components,
> > > > > > that would be seriously cool. On the other hand, it might make more
> > > > > > sense as a separate service that reacts to fedmsg events indicating new
> > > > > > COPR builds are available.
> > > > >
> > > > > +1 for separate service.
> > > >
> > > > I am not against separate service. The separate service would probably
> > > > simply mean running Docker in some cloud instance and call it's API
> > > > through docker-python bindings and then collect the results.
> > > >
> > > > Vaclav
> > > >
> > > > --
> > > >
> > > > Lead Infrastructure Engineer
> > > > Developer Experience
> > > > Brno, Czech Republic
> > >
> > > --
> > >
> > > Lead Infrastructure Engineer
> > > Developer Experience
> > > Brno, Czech Republic
> > >
> > > copr-devel mailing list
> > > [e-mail]
> > > https://lists.fedorahosted.org/mailman/listinfo/copr-devel
> >
> > copr-devel mailing list
> > [e-mail]
> > https://lists.fedorahosted.org/mailman/listinfo/copr-devel
>
> --
>
> Lead Infrastructure Engineer
> Developer Experience
> Brno, Czech Republic

[Václav Pavlín]

On St 6. srpen 2014, 16:43:23 CEST, Radek Vokál wrote:
> ----- Original Message -----
> > On St 6. srpen 2014, 16:13:34 CEST, Radek Vokál wrote:
> > > Vasku, I like the idea  and the workflow. If I understand the workflow
> > > right - the layered image will build on top of base image picked in COPR
> > > (eg. Fedora20 or CentOS7)? Also would it make sense to run our own docker
> > > registry and have in connected to docker.io?
> >
> > My idea was to "guess" base image automatically from the
> > os-version(-arch) selected by user in COPR - so if the copr build is
> > for fedora-20-x86_64, we can say yes, it's 64bit, and use fedora:20 as
> > base image.
> >
> > If we really want to build images, it would make sense to serve them in
> > private registry. On the other hand, I've changed my mind since I sent
> > this proposal - I am not sure if Fedora infrastructure can/will handle
> > building and storing possibly hundreds or thousands of images. I'd like
> > to start with a feature that will prepare and let you download a
> > Dockerfile which you can then modify locally and build your image.
>
> Well, not everyone will request to build an image and correct me if I'm wrong, but for updates docker only stores diffs.

I think we should take worst case scenario in account - i.e. we end up 
building image for almost all packages. Second thing is we should 
probably consider building of images from sets of packages as it would 
make a lot of sense in some cases.

IMHO It stores diffs from base image (or actually from image in FROM 
option). One problem we would have to solve is removing unused images 
from registry as that's missing in current registry implementation - 
images (or rather diffs) just stay there forever.

Vaclav
> R
> > I need to talk about this with Mirek and people from Fedora
> > Infrastructure probably.
> >
> > Vaclav
> > > Radek
> > >
> > > ----- Original Message -----
> > > > Could you please have a look at attached diagram briefly describing
> > > > potential architecture of the image building service? Would this be a
> > > > viable solution?
> > > >
> > > > https://vpavlin.fedorapeople.org/copr-docker.svg
> > > >
> > > > Vaclav
> > > >
> > > > On 24.7.2014 10:42, Václav Pavlín wrote:
> > > > > On St 23. červenec 2014, 13:33:06 CEST, Richard Marko wrote:
> > > > > > On 07/23/2014 10:44 AM, Nick Coghlan wrote:
> > > > > > > On 07/23/2014 01:42 AM, Václav Pavlín wrote:
> > > > > > >> What do you think? Do you think this makes sense for copr?
> > > > > > > If we could use COPR to make Beaker packages for Fedora and EPEL *and*
> > > > > > > upload Dockerfiles to generate Docker images for the various
> > > > > > > components,
> > > > > > > that would be seriously cool. On the other hand, it might make more
> > > > > > > sense as a separate service that reacts to fedmsg events indicating new
> > > > > > > COPR builds are available.
> > > > > > >
> > > > > >
> > > > > > +1 for separate service.
> > > > >
> > > > > I am not against separate service. The separate service would probably
> > > > > simply mean running Docker in some cloud instance and call it's API
> > > > > through docker-python bindings and then collect the results.
> > > > >
> > > > > Vaclav
> > > > >
> > > > > --
> > > > >
> > > > > Lead Infrastructure Engineer
> > > > > Developer Experience
> > > > > Brno, Czech Republic
> > > >
> > > > --
> > > >
> > > > Lead Infrastructure Engineer
> > > > Developer Experience
> > > > Brno, Czech Republic
> > > >
> > > > copr-devel mailing list
> > > > [e-mail]
> > > > https://lists.fedorahosted.org/mailman/listinfo/copr-devel
> > >
> > > copr-devel mailing list
> > > [e-mail]
> > > https://lists.fedorahosted.org/mailman/listinfo/copr-devel
> >
> > --
> >
> > Lead Infrastructure Engineer
> > Developer Experience
> > Brno, Czech Republic

--

Lead Infrastructure Engineer
Developer Experience
Brno, Czech Republic

[Stuart Campbell]

On Aug 6, 2014, at 10:50 AM, Václav Pavlín  wrote:
> On St 6. srpen 2014, 16:43:23 CEST, Radek Vokál wrote:
> > ----- Original Message -----
> > > On St 6. srpen 2014, 16:13:34 CEST, Radek Vokál wrote:
> > > > Vasku, I like the idea  and the workflow. If I understand the workflow
> > > > right - the layered image will build on top of base image picked in COPR
> > > > (eg. Fedora20 or CentOS7)? Also would it make sense to run our own docker
> > > > registry and have in connected to docker.io?
> > >
> > > My idea was to "guess" base image automatically from the
> > > os-version(-arch) selected by user in COPR - so if the copr build is
> > > for fedora-20-x86_64, we can say yes, it's 64bit, and use fedora:20 as
> > > base image.
> > >
> > > If we really want to build images, it would make sense to serve them in
> > > private registry. On the other hand, I've changed my mind since I sent
> > > this proposal - I am not sure if Fedora infrastructure can/will handle
> > > building and storing possibly hundreds or thousands of images. I'd like
> > > to start with a feature that will prepare and let you download a
> > > Dockerfile which you can then modify locally and build your image.
> >
> > Well, not everyone will request to build an image and correct me if I'm wrong, but for updates docker only stores diffs.
>
> I think we should take worst case scenario in account - i.e. we end up building image for almost all packages. Second thing is we should probably consider building of images from sets of packages as it would make a lot of sense in some cases.
>
> IMHO It stores diffs from base image (or actually from image in FROM option). One problem we would have to solve is removing unused images from registry as that's missing in current registry implementation - images (or rather diffs) just stay there forever.
>
> Vaclav

I agree, I think as a first step creating the dockerfiles is a good idea.  Managing the potential number of images that we could end up with could become problematic.  I think it would be a good idea to try and quantify the rough amount of capacity we would have within the Fedora Infrastructure to build images - then we would know how much wiggle room we have.

Cheers
Stu
> > R
> > > I need to talk about this with Mirek and people from Fedora
> > > Infrastructure probably.
> > >
> > > Vaclav
> > > > Radek
> > > >
> > > > ----- Original Message -----
> > > > > Could you please have a look at attached diagram briefly describing
> > > > > potential architecture of the image building service? Would this be a
> > > > > viable solution?
> > > > >
> > > > > https://vpavlin.fedorapeople.org/copr-docker.svg
> > > > >
> > > > > Vaclav
> > > > >
> > > > > On 24.7.2014 10:42, Václav Pavlín wrote:
> > > > > > On St 23. červenec 2014, 13:33:06 CEST, Richard Marko wrote:
> > > > > > > On 07/23/2014 10:44 AM, Nick Coghlan wrote:
> > > > > > >> On 07/23/2014 01:42 AM, Václav Pavlín wrote:
> > > > > > >>> What do you think? Do you think this makes sense for copr?
> > > > > > >> If we could use COPR to make Beaker packages for Fedora and EPEL *and*
> > > > > > >> upload Dockerfiles to generate Docker images for the various
> > > > > > >> components,
> > > > > > >> that would be seriously cool. On the other hand, it might make more
> > > > > > >> sense as a separate service that reacts to fedmsg events indicating new
> > > > > > >> COPR builds are available.
> > > > > > >> 
> > > > > > > 
> > > > > > > +1 for separate service.
> > > > > > >
> > > > > >
> > > > > > I am not against separate service. The separate service would probably
> > > > > > simply mean running Docker in some cloud instance and call it's API
> > > > > > through docker-python bindings and then collect the results.
> > > > > >
> > > > > > Vaclav
> > > > > >
> > > > > > --
> > > > > >
> > > > > > Lead Infrastructure Engineer
> > > > > > Developer Experience
> > > > > > Brno, Czech Republic
> > > > >
> > > > > --
> > > > >
> > > > > Lead Infrastructure Engineer
> > > > > Developer Experience
> > > > > Brno, Czech Republic
> > > > >
> > > > > copr-devel mailing list
> > > > > [e-mail]
> > > > > https://lists.fedorahosted.org/mailman/listinfo/copr-devel
> > > >
> > > > copr-devel mailing list
> > > > [e-mail]
> > > > https://lists.fedorahosted.org/mailman/listinfo/copr-devel
> > >
> > > --
> > >
> > > Lead Infrastructure Engineer
> > > Developer Experience
> > > Brno, Czech Republic
>
> --
>
> Lead Infrastructure Engineer
> Developer Experience
> Brno, Czech Republic