[Container-tools] Docker developer tooling
Brian (bex) Exelbierd
bex at pobox.com
Fri Jul 24 08:20:13 UTC 2015
On 07/23/2015 04:58 PM, Carl Trieloff wrote:
> On 07/23/2015 05:25 AM, Max Rydahl Andersen wrote:
>> TL;DR:
>> Eclipse tooling currently just relies on same info as docker cli. CDK
>> needs to allow connection from the host and provide a way to get the
>> connection information easily, e.g. "$(cdk docker-env)"
I believe we should do this similarly to the way boot2docker does it.
1) Expose the port for the docker daemon
2) Generate certificates and share them
3) Set the environment variables
The challenges is:
It appears the only way to expose a port from Vagrant is via a
portforward from the host. Vagrant supports port collision detection and
auto correction, however it doesn't have a programatic way to get to the
new port information. It appears this is going to require a provider
level set of code to fix. We should be able to write a plugin, or
leverage some parts of existing ones to figure this out.
I believe that once we have this, we can write a simple script to
generate the environment variables required,
I am working down this road now.
>> and it should
>> be possible to easily mount local filesystems.
I haven't explored this yet, but my first-blush take is that it is going
to require virtualbox additions for the virtualbox cdk boxes. The
libvirt boxes should be fine, as they can use nfs.
regards,
bex
>>
>> The long version:
>>
>> General challenge
>> -----------------
>>
>> From developer experience side we must all realise that the OS
>> users/developers are running on is *not* a Linux based OS, and if it
>> is Linux it most likely is not RHEL. They will often go to production
>> on RHEL but for sure during development at least 80% of our
>> customers/users are on Windows and the rest on a mixture of Linux and
>> OS X distributions.
>>
>> Furthermore since we want to target enterprise developers most of them
>> prefer to use a UI or if they do use the CLI they prefer being able to
>> use the tools that runs on their own host rather than through a
>> tunnelled shell. This does not mean we should not expose shells nor
>> cli's - just means that we *cannot* ignore the UI and direct access
>> options.
>>
>> In our eclipse tooling we are doing what we can to provide a good UI
>> experience while still coexisting with the CLI tools; preferably
>> thought without *relying* on users to install the cli tools. As an
>> example our Openshift v2 tools required no custom cli setup *at all*
>> on any OS to use, it just worked out of the box. Super easy to setup
>> and get started with.
>>
>> We want to have similar experience in as many usecases as possible for
>> our new generation of CDK/docker/openshift tooling story too.
>>
>> Connection
>> ----------
>>
>> The docker tooling in Eclipse is just accessing docker as if it was
>> any other docker client. It supports accessing docker over tcp and
>> over raw sockets. The raw sockets especially is nice in the sense that
>> it on Linux hosts allow the setup to "just work" on default Linux
>> docker installs.
>>
>> We want to get an equal simple experience on systems where you do not
>> have raw sockets access, such as Windows, OS X or remote docker
>> setups. Thus on such systems we run a little script to try and fetch
>> the following environment variables: `DOCKER_HOST`, `DOCKER_CERT_PATH`
>> and `DOCKER_TLS_VERIFY` and if found we use that as the default setup.
>>
>> This means that if the user has configured docker in his setup it will
>> again "just work".
>>
>> The nice thing about this mechanism is that if you use `boot2docker`
>> you can just add the following line to your setup: `$(boot2docker
>> shellinit)` or if you use the newer `docker-machine` and have a docker
>> setup called `dev` you can add `"$(docker-machine env dev)"`
>>
>> This works because these commands spits out something like:
>>
>> ```
>> export DOCKER_HOST=tcp://192.168.59.103:2376
>> export DOCKER_CERT_PATH=/Users/max/.boot2docker/certs/boot2docker-vm
>> export DOCKER_TLS_VERIFY=1
>> export DOCKER_MACHINE_NAME="dev"
>> ```
>>
>> And this is exactly what docker cli uses and so does the eclipse
tooling.
>>
>> Thus in short, anything that makes it easy to use CDK from the *host*
>> cli will be beneficial for our Eclipse usage too.
>>
>> For now we read environment variables for the setup (which will work
>> with "anything"), but going forward we also would like to
>> add plugins to detect running docker instances available to the user
>> allowing docker for eclipse to find docker setup via boot2docker,
>> docker-machine, openshift connections and in this context a local
>> running CDK.
>>
>> 
>>
>> Volumes
>> -------
>>
>> Above is just about the actual connection to Docker, beyond this is
>> also the importance of efficiently being able to mount volumes from
>> user host into the docker instance.
>>
>> Again, here `boot2docker` and `docker-machine` makes this work `out of
>> the box` by allowing mount of host user filesystems.
>>
>> This is what we utilise in blogs like:
>> http://tools.jboss.org/blog/docker_tooling_eclipse_mars.html and
>>
http://tools.jboss.org/blog/2015-03-02-getting-started-with-docker-and-wildfly.html
>>
>> Thus beyond being able to connect to docker inside the CDK we also
>> need to be able to have support for volume mount.
>>
>> I believe vagrant has *some* support for mounting volumes but last
>> time I tried this that was more a sync rather than an actual mount
>> meaning changes was slow and somewhat unreliable compared to what I've
>> seen with boot2docker and docker-machine.
>>
>> I'm hoping you guys can tell me I'm wrong about this and vagrant can
>> be made to work just as well as boot2docker and docker-machine
>>
>> Docker Actions
>> --------------
>>
>> Currently what I've been able to get info about the CDK the docker
>> connection is only accessible from within the vagrant host by running
>> `vagrant ssh` and there was no (easy nor uniform) way to mount volumes
>> from my local system to docker or any other part of the CDK.
>>
>> Thus for the CDK I see the first task to be that the CDK by default
>> make access to Docker possible from the host running the CDK
>> and then provide a command to dump the environment settings, for
example:
>>
>> ```
>> $ cdk docker-env
>> export DOCKER_HOST=tcp://192.168.59.103:2376
>> export DOCKER_CERT_PATH=/Users/max/.cdk/certs/docker-vm
>> export DOCKER_TLS_VERIFY=1
>> export CDK_DOCKER_NAME="redhat-cdk"
>> ```
>>
>> Then users can add `$(cdk docker-env)` to their setup and Eclipse
>> tooling will just work.
>>
>> Note the presence of access to the host stored DOCKER_CERT_PATH. These
>> cannot be paths *within* the vagrant image since neither a docker cli
>> or eclipse can reach those.
>>
>> And then we need to find a way on how volume mounts will work.
>>
>> Bonus OpenShift
>> ---------------
>>
>> Our OpenShift tooling in eclipse does not (yet) use environment
>> variables but just needs a URL to the OpenShift 3 console and it will
>> figure out how to connect. Thus the OpenShift instance in CDK should
>> also be default exposed and accessible to the running host.
>>
>> Maybe even have a `cdk openshift-env` to get the details.
>>
>>
>> The End.
>>
>> I hope that gives some insights - if any questions do not hesitate to
>> ping me on this mail thread or on irc (nick: maxandersen).
>>
>> /max
>> http://about.me/maxandersen
>
More information about the Container-tools
mailing list