[jbosstools-issues] [JBoss JIRA] (JBDS-3258) Docker Tooling (Advanced Integration)

[Burr Sutter (JIRA)]

    [ https://issues.jboss.org/browse/JBDS-3258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13042157#comment-13042157 ] 

Burr Sutter commented on JBDS-3258:
-----------------------------------

It is certainly possible that we can merge these jiras and my learning has grown over the last couple of months - I will attempt to "rewrite" them via this comment:
0) assumes boot2docker has been dowloaded and installed - if the end-user has not yet downloaded and installed boot2docker, then we assume the end-user has remote Docker Daemon and will need to point to a URL for the Docker Daemon running on another machine on the network. I do not believe the Docker Daemon has much in the way of security but we will need to consider that when talking to a remote docker

1) boot2docker init - handled by boot2docker - end-user will be responsible for running this themselves outside of the IDE
2) boot2docker up - handled by boot2docker - end-user will be responsible for running this themselves outside of the IDE
3) boot2docker ip run by the end-user manually, outside of JBDS.  The end-user is responsible for making note of this ip address has he/she will need it to run tests of his/her web apps. boot2docker currently provides a start.sh that works on Mac and Windows that handles "init", "up" and "ip" and on Windows it also issues a "ssh" so that the end-user is dropped into the boot2docker-vm shell.  Basically this shell (command prompt) will be open in the background IF the end-user is running a local copy of Docker (via boot2docker).
4)  I, the Java developer, need to browse a docker registry (either DockerHub or private registry), identify the image that I wish to have local and download (docker pull) for that image+tag.
5) docker ps - allows me to see all the currently running containers
6) docker rm - allows me to remove (may require a stop/kill) a particular running container
7) docker images - allows me to see all the available (on the particular docker daemon) docker images
8) docker rmi - allows me to remove a particular image (provides an error if there is still a container associated with the image)
9) docker pull - allows me to pull a docker image from the previously designated docker registry (local, public, private)
10) docker run -it -p 8080:8080 -p 9990:9990 --link mysqldb:mydatabaseserver centos/wildfly 
assumes we have a way to let the end-user see the logs
11) docker run -p 8080:8080 -p 9990:9990 --link mysqldb:mydatabaseserver centos/wildfly -d
12) if run with -d, then we need to support "docker logs container_id"
13) I can then deploy my .war or .ear to the running app server
14) I can restart the running app server in debug mode and run the debugger
15) I can undeploy and redeploy my .war or .ear 
16) I can stop/restart the running, embedded app server
17) I can then commit (docker commit)
18) then I can publish my changes (docker push) to the previously configured registrry
19) also, I can use "docker build" with a previously created Dockerfile and "docker push" its output

> Docker Tooling (Advanced Integration)
> -------------------------------------
>
>                 Key: JBDS-3258
>                 URL: https://issues.jboss.org/browse/JBDS-3258
>             Project: Developer Studio (JBoss Developer Studio)
>          Issue Type: Feature Request
>          Components: openshift, requirements
>            Reporter: Burr Sutter
>            Assignee: Xavier Coulon
>
> Once significant delta between the "basic" and advanced scenarios is that here I wish to custom craft my own docker images instead of using an existing one - where my custom crafted image includes my .war or .ear.  
> In addition to the basic integrations of pull, run, stop, commit and push 
> boot2docker init 
> boot2docker up
> boot2docker down
> boot2docker ip
> docker run -d 
> docker ps
> docker rm
> docker rmi
> docker build
> End-user steps:
> 0) assumes boot2docker has been dowloaded and installed
> 1) boot2docker init : required to to insure boot2docker-vm is properly initialized 
> 2) boot2docker up : starts the VirtualBox boot2docker-vm 
> 3) boot2docker ip : returns the IP address - this will be vital when it comes to testing - it would need to be integrated with our Run - As on Docker capability.
> 4) docker run -i -t -p 80:8080 jboss/wildfly -d : the -d means detached, I may need to run N containers simultaneously
> 5) docker ps : allows me to see all my currently running containers
> 6) docker rm : allows me to kill a currently running container
> 7) docker rmi : allows me to remove a local image
> 8) docker build : assumes that I have crafted a Dockerfile - this will create the local image - with my .war or .ear embedded
> 9) docker run : this new created image
> The docker build scenario can be triggered via a Maven plugin
> The docker build scenario can also be triggered via an Eclipse menu option (like a Maven install)
> We need to figure out the file-system layout so that the Dockerfile and the maven project are all nicely checked into git/svn.  So that Jenkins can pick up this repository and perform an automated "docker build" (post Maven install) and then run all the appropriate unit, integration and functional tests.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)