[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