[Container-tools] Docker developer tooling

[Tomas 'Sheldon' Radej]

Hi,

On 23/07/15 21:07, Carl Trieloff wrote:
>
> Pete,
>
> Here is a utube....
>
> http://stef.thewalter.net/cockpit-kubernetes-dashboard.html
>
> Here is the pull request
> https://github.com/cockpit-project/cockpit/pull/2332
>
> Note that the Dan Walsh has accepted the changes needed for AtomicTool,
> but these still need to be released in the next version of AtomicHost.
>
> (Basically, AtomicApp runs in a container with a REST API as a service
> which Cockpit connects to.)

Just FYI, DevAssistant will use a very similar architecture to that, so 
we could cooperate on it (more on the next cabal).

> Dan also suggests we do a golang imp, of atomicApp so that it becomes OS
> agnostic
>
> Carl.
>
>
> On 07/23/2015 02:00 PM, Pete Muir wrote:
>> 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.
>>>>
>>>> ![](cid:DAA600B7-99E8-4CF5-9C17-A4C832103B76 at redhat.com
>>>> "PastedImage.png")
>>>>
>>>> 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
>
> _______________________________________________
> Container-tools mailing list
> Container-tools at redhat.com
> https://www.redhat.com/mailman/listinfo/container-tools
>

-- 
Tomas 'Sheldon' Radej