[Container-tools] Atomic Developer Bundle and OpenShift
Langdon White
langdon at redhat.com
Tue Nov 3 16:46:09 UTC 2015
On 11/03/2015 10:23 AM, Max Rydahl Andersen wrote:
>
>> * a method for docker images to be pre-loaded on to the vagrant
>> boxes: As you probably agree, we would really like the v-up
>> experience of the ADB to be as quick and painless as possible. One of
>> things that will make that possible is to "pre-install" the docker
>> images for OpenShift, AtomicApp, v2c, etc. However, the build tooling
>> (koji) does not allow a build to access the general internet. As a
>> result, "docker pull" is not an option (at least from docker-hub). We
>> have a couple options here:
>> * stand up a docker registry in the build environment that the builds
>> can access: While this seems like a good idea, the timeline to make
>> this happen is probably on the order of months not days
>> * auto-rpm-ify the docker images: Build the images in koji, use koji
>> to rpm-ify the binary images, pull the rpms as per normal, extract
>> the rpm and inject them in to the docker-images storage. Likely, this
>> is the most viable solution. However, it may run in to problems with
>> docker-registry-v2 (doesn't support import at this time).
>> Is anyone owning testing and resolving this issue?
>
> I can say from the Developer Tooling we would probably "pre-pull" a
> very different set of images than you are listing.
> i.e. we would be into getting the EAP images pre-seeded.
>
> Thus I would actually suggest that the "base" ADB/CDK don't do this by
> default but maybe just have a preloaded command users or an additional
> installer can run to easily "pre-load" the set they are interested in.
I just suggested investigating adding docker support to
vagrant-cachier[1] in another thread. I wonder if this is a further
argument. We *certainly* don't want to be pulling a whole mess of docker
images on v-up.
[1]: http://fgrehm.viewdocs.io/vagrant-cachier/
>
>> * OpenShift needs dns to allow a user to access their applications:
>> For OpenShift to give a good user experience, it needs to manage some
>> wildcard domain. In other words, when a user sets up an application,
>> they need to give it a name and they access the application from
>> their host web browser at something like "myCoolApp.myADB.lcl".
>> OpenShift uses host-headers to route the browser to the correct app.
>> However, this means, if OpenShift is running in a VM, the host
>> machine needs to know to route *.myADB.lcl to the VM and then to
>> OpenShift. As the VM will come up on an (likely) unknowable IP, we
>> planned to use vagrant-landrush, a plugin for vagrant that manages a
>> DNS server for this type of use case. Currently, this plugin still
>> has some problems on windows and has never been tested in this exact
>> use case. Is someone working on:
>> 1) testing that this setup will actually work with OpenShift (even on
>> mac or linux where, i believe, v-landrush is known to work)
>> 2) looking in to the issues on windows?
>
> I don't have confirmation on QE working on this yet but this is
> definitely on our todo list to verify.
>
> Yes, we plan on using land rush since that at least seem to work on
> Linux for the main VM+openshift, but on Mac and Windows I believe it
> will only work for the main VM - it won't work for the dynamically
> created apps by openshift.
>
> I was hoping there would be one on the CDK team that knew enough about
> vagrant to tell if it would be possible to write a vagrant plugin that
> would somehow run in the background and either listen or poll
> frequently if openshift added new routes, and if yes - write back to
> the main host "/etc/host" (diff location on win) file to add them.
>
> Alternatively (and I don't know if this actually possible) I was
> wondering if CDK could host a dns or similar that we could configure
> Windows to use as fallback when it otherwise couldn't resolve the host
> names ?
vagrant-landrush is a dns.. .I think that was the point. We could write
a new vagrant plugin to do dns, but why not just improve the existing
one? I believe openshift can work with a wildcard dns. Mind you, this is
*not* the dns that openshift uses internally, which I am expecting we
will be getting in the container(s) from the openshift team. We only
want to use landrush (or some host provided dns) for the apps themselves
and, I thought, wildcard would work with openshift so openshift wouldn't
need to interact with the dns server.
>
>> * allow for k8s + docker to work independently of OpenShift: In the
>> plans for ADB we wanted to allow a developer to use k8s+docker
>> directly as well as OpenShift. However, this is not quite as easy as
>> it seems as the k8s version on CentOS and the k8s version in
>> OpenShift are not the same. As a result, even if they are installed
>> separately (see installation bullets elsewhere), they need to be
>> listening on different IP bindings to allow them to listen on the
>> same port. Does someone own testing and ensuring the setup of these
>> conflicting services?
>
> This one i'm interested in too - not because I want to actually work
> with k8s + docker raw, but so this is at least kept very separate so
> there is no conflicts.
>
answering this in the other thread...
> /max
> http://about.me/maxandersen
More information about the Container-tools
mailing list