[Container-tools] Docker developer tooling
Pete Muir
pmuir at redhat.com
Thu Jul 23 18:00:39 UTC 2015
Got any links to how it works in Cockpit?
> On 23 Jul 2015, at 15:58, Carl Trieloff <cctrieloff at redhat.com> wrote:
>
>
>
> Coping to container-tools.
>
> Discussion on what Max needs to integrate CDK boxes to the Docker work
> they have done in Eclispe. Once we have this working we should also be
> able to integrate Eclipse with AtomicApp as service in the same way
> Cockpit does .
>
> Carl.
>
>
>
>
> On 07/23/2015 05:25 AM, Max Rydahl Andersen wrote:
>> Heya,
>>
>>> Max has offered to give Brian a deep dive in to the use cases we want
>>> to enable from Eclipse for docker (and by extension, the CDK) whilst
>>> Xavier is out.
>>
>> Hey Brian,
>>
>> Here is a writeup of the critical parts related to CDK tooling.
>>
>> FY: I'm going on PTO from this saturday and 2 weeks forward - thus if
>> any questions let me know ASAP; if not i'm sure Jeff et.al. can help
>> to answer details too.
>>
>> 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)" and it should
>> be possible to easily mount local filesystems.
>>
>> 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