Quantcast

Docker integration?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Docker integration?

frenchyan
Administrator
Hi guys

I am curious to know whether any of you has any experience with Docker,  "an open platform for distributed applications for developers and sysadmins"

I wanted also to get feedback/interest of whether you think this would be good for glu to support Docker. I could imagine 2 integration levels:

* glu is itself a "Dockerized" app (meaning, you would install glu self contained, so no more issue with java version mismatch and whatnot since it would run in its own sandbox), in other words starting an agent would be something like (note that I am not an expert of Docker... I simply read a few of their documentation page, so what I say may not be accurate...)

   docker run pongasoft/glu-agent:5.5.1

* glu supports deploying and monitoring of "Dockerized" app

This is by any mean a small project so I would like to gauge interest before doing it.

Thanks
Yan
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Docker integration?

harel.eran
We're going to start researching our options with regards to moving to Docker.

Obviously currently Glu is not an option, so we will need to look for a new orchestration solution if Glu doesn't support docker container deployments.

So yes, item 2 is of interest, at least to us.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Docker integration?

Pascal
In reply to this post by frenchyan
Docker support is definitely an interesting feature. 

On Sep 8, 2014, at 13:20, "frenchyan [via glu]" <[hidden email]> wrote:

Hi guys

I am curious to know whether any of you has any experience with Docker,  "an open platform for distributed applications for developers and sysadmins"

I wanted also to get feedback/interest of whether you think this would be good for glu to support Docker. I could imagine 2 integration levels:

* glu is itself a "Dockerized" app (meaning, you would install glu self contained, so no more issue with java version mismatch and whatnot since it would run in its own sandbox), in other words starting an agent would be something like (note that I am not an expert of Docker... I simply read a few of their documentation page, so what I say may not be accurate...)

   docker run pongasoft/glu-agent:5.5.1

* glu supports deploying and monitoring of "Dockerized" app

This is by any mean a small project so I would like to gauge interest before doing it.

Thanks
Yan


If you reply to this email, your message will be added to the discussion below:
http://glu.977617.n3.nabble.com/Docker-integration-tp4026688.html
To start a new topic under glu, email [hidden email]
To unsubscribe from glu, click here.
NAML
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Docker integration?

frenchyan
Administrator
In reply to this post by harel.eran
I am not entirely sure why you say that glu is not an option. glu can install and deploy any kind of app.. I can imagine something like this right now without any change:

class MyGluScriptWithDocker {
  def start = {
    shell.exec("docker run ${params.myapp}")
  }
}

When I was talking about solution 2, I meant deeper integration so that you would not have to issue shell commands, but without changing anything I just don't see why glu could not run a dockerized app.

Yan
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Docker integration?

harel.eran
Where will the agent run?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Docker integration?

frenchyan
Administrator
This is based on my short read and I am sure there may be other cases but the way I understood Docker is that it lets you "dockerize" or "containerize" an application... instead of deploying a war file a tar file or whatnot (which ends up running on the machine it is deployed, hence inherit all the config and changes tot he os), you deploy a full os with the app in it => that way your app is isolated and does not use the OS on which the container is deployed.

So on a given machine, there is a docker (daemon) and a docker client (the executable binary) running. 

My point was: if you issue a command like this (taken from their tutorial):

docker run ubuntu:14.04 /bin/echo 'Hello world'
you are obviously issuing this command on a host which has docker daemon and client installed... what this does is create a full blown os to run the command in it. If glu is also installed on the same host, then you can obviously create a glu scrip that does this:

class HelloWorldDockerGluScript
{
  def start = {
    shell.exec("docker run ubuntu:14.04 /bin/echo 'Hello world'")
  }
}

As far as I can tell, docker is not a deployment solution. It is a solution that lets you package an application in such a way that what you deploy it as a full os with the app in it. That way for example, the java version of your app can be totally different from the java version that is installed on the physical host where docker is installed. It seems that the very interesting concepts of docker is that there is some versioning attached to it and it seems that you can describe a container with a few lines (Dockerfile) (see https://docs.docker.com/userguide/dockerimages/#creating-our-own-images). The power is now what you give to qa, what you test on your dev machine, what you run in prod, is the exact same thing unlike when you package an app as a war for example and distribute the war only (whatever run the war, will most likely be different from env to env, including java version, container container version, os, etc...)

This section: https://docs.docker.com/introduction/understanding-docker/#what-is-dockers-architecture actually talks about the fact that a client can connect and talk to a remote Docker daemon and so can install containers on remote hosts (granted they run the docker daemon). If the glu agent is also running on the host where the docker daemon is installed (and this is where my point #1 would be great because you could install the glu agent on the remote host using docker...) then you can issue docker command directly on the host (using something like the example glu script) with all the power that comes with glu (modeling your deployment, knowing what is installed, where, the ui, the security, etc...)

I guess it should be possible to build a deployment (and monitoring solution) like glu using Docker (where the glu agent is the Docker Daemon): the console/orchestration engine talks to the docker daemon directly vs talking to a glu agent. Maybe that would be another entry on my list of "integrating with Docker" :)

Yan
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Docker integration?

lukestephenon
Hi Yan,

I agree with your assessment that Docker is not a deployment solution, so glu as an orchestration layer still offers the same benefits as today.  I'd expect the glu scripts to become more consistent / smaller as a result of deploying consistently packaged containers.

While I'm a fan of java, one of my onlike dislikes of the agent is that as a result of the large memory footprint of java, shell.exec is slow and places a lot of load on the host.  If the docker daemon exposes a socket, then the glu agent can potentially communicate with it over that with very little overhead rather than the expensive shell.exec.  That said, I've been considering docker and initially I was just planning on calling docker commands with shell.exec like your example.

While the console server could potentially integrate directly with the docker daemon, determining if a process is up would involve polling the daemon.  I prefer the current architecture where this is reported back via zookeeper.

There are some other products to deploy to docker containers.  I've not looked into them yet, but many appear to be inspired by heroku's git push to publish model (which I'm not sold on).
http://deis.io/overview/
https://flynn.io/

Luke
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Docker integration?

sodul
Luke, I avoid the 'groovy' issue by having a simple 'generic' groovy script that shell exec a python script (glu.py). That python script is in turn application agnostic but has all the logic on how to fetch artifacts from our binary repository and other custom logic that is specific to our company. All the app specific logic is in a set of python script (or any other language really): install.py, configure.py, start.py, stop.py, monitor.py, etc ...

I've implemented this at two companies now and this has given us great flexibility, including for development where i can simply 'import configure' from the python shell and debug thing on development/QA hosts that are Glu managed, without the need to package then deploy in progress logic from the glu console. We have dozens of applications that are deployed through Glu, the unique Groovy script we use is about 200 lines, the shared python script about 700 lines, the custom deployment scripts are several thousands of lines.

One improvement I plan to do is to replace all the shell.execs() to the python script to a single one and do interprocess communication so that the Agent will now only shell exec during the install phase.

I have shared the generic groovy script we use a couple of years ago in this forum. The current version we use is almost the same.
Loading...