[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [atomic-devel] atomic-reactor and building in a container



Quoting Muayyad AlSadi (2015-08-28 14:00:33)
> quote from https://github.com/projectatomic/atomic-reactor
> 
> > Features: build inside a docker container (so your builds are separated
> between each other)

The main reason behind this is that we run atomic-reactor in openshift using the
custom build strategy. Not sure if this new method would require changes in
openshift.

> I was consulting with upstream docker and found they have a milestone to
> separate builder outside of docker, ie "docker build" at some point would
> an external app would build an image and pass it to docker daemon to load
> it or push it docker registry

This is what they announced on last Dockercon US.

> they recently introduced CP api that allow docker client to copy files
> between containers/host
> 
> https://docs.docker.com/reference/commandline/cp/
> 
> one of those builders is dockramp
> 
> https://github.com/jlhawn/dockramp

I tried it a couple days ago, unfortunately got tracebacks only.

Other than that, it looks really promising.

> and there we are discussing how to do something similar to atomic-reactor,
> but using extended Dockerfiles only
> 
> we are discussing a way to pivot/switch containers root in away similar to
> rpm's spec-file, the docker file is a usual dockerfile that starts with a
> build image (or stock image followed by yum install gcc golang ...)
> then do the build then switch the root to a minimal/base image (without
> compiler) that is sufficient to run it, with something like this
> 
> RUN make install SERVER_PREFIX=/dest/server CLIENT_PREFIX=/dest/client
> RUN cp /bin/server-extra /dest/server/bin/
> RUN cp /bin/server-replicator /dest/replicator/bin/
> RUN cp /bin/client-extra /dest/client/bin/
> SWITCH_ROOT busybox /dest/server
> TAGGED_SWITCH_ROOT client busybox /dest/client
> TAGGED_SWITCH_ROOT replicator busybox /dest/replicator
> 
> it would build 3 images: foobar, foobar-client, foobar-replicator

So the filesystem of final images would be in `/dest` and TAGGED_SWITCH_ROOT
would do the final commit?

I think I saw a couple of similar ideas in docker's issue tracker.

If you could provide more detailed description of the design, we can talk and
ideally come up with a solution (and implementation).

Thank you for your proposal!


Cheers,
~~
Tomáš Tomeček
Software Engineer
Developer Experience
UTC+2 (CEST)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]