[Container-tools] Docker developer tooling
Carl Trieloff
cctrieloff at redhat.com
Thu Jul 23 14:58:50 UTC 2015
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