[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [atomic-devel] atomic-reactor and building in a container
- From: Tomas Tomecek <ttomecek redhat com>
- To: Muayyad AlSadi <alsadi gmail com>, atomic-devel projectatomic io
- Subject: Re: [atomic-devel] atomic-reactor and building in a container
- Date: Thu, 03 Sep 2015 10:07:34 +0200
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]