在 Docker容器中安装WebSphere 8.5

Steps: 1. 下载Eclipse JEE Luna 2. 安装IBM WDT插件(IBM WebSphere Application Server Developer Tools)（通过wasdev.net可以下载updatesite离线包) 3. 安装Liberty runtime（通过wasdev.net可以下载runtime离线包，这里有视频教程:https://www.youtube.com/watch?v=A6pwGuBgiEI) 4. 安装完整的WAS8.5.5(unzip and sudo ./install) (这是个配置好Installation Manager包1.8.x，大概100多M，可以在http://www.ibm.com/developerworks/downloads/ws/wasdevelopers/下载，　使用Http的方式会比较靠谱)

３和4选任意一个都行。

最终我安装的位置：     Package Group Name: IBM WebSphere Application Server V8.5     Installation Dir: /opt/IBM/WebSphere/AppServer     Shared Resources Dir: /opt/IBM/IMShared

我把/opt/IBM/WebSphere/AppServer设置为了$washome 这个过程需要下载1015.65 MB的文件。好在不需要翻墙。速度还不错。

read here: `http://stackoverflow.com/questions/15516741/websphere-application-server-developer-tools-for-eclipse-how-to?rq=1`

and here

`http://veithen.github.io/2014/11/02/running-was-in-docker.html`

for some ideas.

补充4：解压然后运行sudo ./install安装组件选择

    1. WAS8.5.5.5 for developers    2. WAS Liberty for developers    3. IBM JDK 1.7 for WAS    4. IBM JDK 1.7 for Liberty

后3个组件我开始没选。WAS8.5默认会装IBM JDK6. 重新运行上面的sudo ./install命令可以修改安装内容。重新选择后3个包. 这里有篇文章，如何升级WAS8.5默认JDK到JDK7: http://stackoverflow.com/questions/25223122/java-7-1-in-ibm-websphere/25223414#25223414

两个有用的命令:

    $washome/bin/managesdk.sh -listAvailable     $washome/managesdk.sh -enableProfile -profileName AppSrv02 -sdkname 1.7_64

November 2, 2014(updatedFebruary 24, 2015)

This article describes how to run WebSphere Application Server in a Docker container. We are going to use the developer version of WAS 8.5.5 to create a full profile, but the instructions can easily be adapted to a regular WebSphere version (provided you have an appropriate license) or a different WebSphere 8.x version. Note however that the solution will not work with WAS 7.0 because the installation procedure is completely different.

To create the Docker image, download IBM Installation Manager for Linux x86_64 and use the following Dockerfile, after replacing the-userNameand-userPasswordarguments with your IBM ID:

Note that by executing this Dockerfile you accept the license agreement for IBM Installation Manager and WebSphere Application Server for Developers.

The execution of theimutilscmay fail with the following error, even though you have specified a valid user name and password:

The root cause for that is IBM inability to correctly configure its CDN:

The document has moved here.

The output of these two commands show that a GET request to the repository URL gets redirected with HTTP status 302, while a HEAD request for the same URL results in a 503 error. The problem is thatimutilscuses a HEAD request and therefore fails. The work around this issue, replace the value of theREPOvariable with the location obtained from the 302 response. In the example shown above, this would behttps://www-912.ibm.com/software/repositorymanager/V85WASDeveloperILAN/.

Here are some more details about the Dockerfile:

Only IBM Installation Manager needs to be downloaded before creating the image. The product itself (WebSphere Application Server for Developers 8.5.5) is downloaded by Installation Manager during image creation. Note that this may take a while. ThepreserveDownloadedArtifacts=falsepreference instructs Installation Manager to remove the downloaded packages. This reduces the size of the image.

The Dockerfile creates a default application server profile that is configured to run as a non-root user. The HTTP port is 9080 and the URL of the admin console ishttp://...:9060/ibm/console. New containers should typically be created with the following options:-p 9060:9060 -p 9080:9080. Refer to the Port number settings page in the Knowledge Center for a complete list of ports used by WAS. Note that this page doesn’t mention the default port used for remote debugging, which is 7777.

To see the WebSphere server logs, use the following command (requires Docker 1.3):

Docker assigns a new hostname to every newly created container. This is a problem because theserverindex.xmlfile in the configuration of the WebSphere profile contains the hostname. That is to say that WebSphere implicitly assumes that the hostname is static and not expected to change after the profile has been created. To overcome this problem the Dockerfile adds a script calledupdateConfig.shto the image. That script is executed before the server is started and (among other things) updates the hostnames inserverindex.xmlwhen necessary.

Docker expects the RUN command to run the server process in the foreground (instead of allowing it to detach) and to gracefully stop the server when receiving a TERM signal. WebSphere’sstartServer.shcommand doesn’t meet these requirements. This issue is solved by using the-scriptoption, which tellsstartServer.shto generate a launch script instead of starting the server. This launch script has the desired properties and is used by the RUN command. This has an additional benefit: thestartServer.shcommand itself takes a significant amount of time (it’s a Java process that reads the configuration and then starts a separate process for the actual WebSphere server) and skipping it reduces the startup time.

There is however a problem with this approach. The content of the launch script generated bystartServer.shdepends on the server configuration, in particular the JVM settings specified inserver.xml. When they change, the launch script needs to be regenerated. This can be easily detected and theupdateConfig.shscript added by the Dockerfile is designed to take care of this.

The RUN command is a script that first runsupdateConfig.shand then executes the launch script. In addition to that,updateConfig.shis also executed once during the image creation. This will speed up the first start of a new container created from that image, not only because the launch script will already exist, but also because the very first execution of thestartServer.shscript typically takes much longer to complete.