Run update.sh

This commit is contained in:
Docker Library Bot 2016-03-01 10:45:38 -08:00
parent 2ebb4503cd
commit e83d45e7cb
2 changed files with 22 additions and 23 deletions

19
debian/README.md vendored
View File

@ -1,22 +1,21 @@
# Supported tags and respective `Dockerfile` links
- [`8.3`, `8`, `jessie`, `latest` (*jessie/Dockerfile*)](https://github.com/tianon/docker-brew-debian/blob/8913a3ebafdfa6a2e54ca265983252edcbbb76a6/jessie/Dockerfile)
- [`jessie-backports` (*jessie/backports/Dockerfile*)](https://github.com/tianon/docker-brew-debian/blob/8913a3ebafdfa6a2e54ca265983252edcbbb76a6/jessie/backports/Dockerfile)
- [`oldstable` (*oldstable/Dockerfile*)](https://github.com/tianon/docker-brew-debian/blob/8913a3ebafdfa6a2e54ca265983252edcbbb76a6/oldstable/Dockerfile)
- [`oldstable-backports` (*oldstable/backports/Dockerfile*)](https://github.com/tianon/docker-brew-debian/blob/8913a3ebafdfa6a2e54ca265983252edcbbb76a6/oldstable/backports/Dockerfile)
- [`8.3`, `8`, `jessie`, `latest` (*jessie/Dockerfile*)](https://github.com/tianon/docker-brew-debian/blob/d431f09a3730996c0f759eb446bff454f715a321/jessie/Dockerfile)
- [`jessie-backports` (*jessie/backports/Dockerfile*)](https://github.com/tianon/docker-brew-debian/blob/d431f09a3730996c0f759eb446bff454f715a321/jessie/backports/Dockerfile)
- [`oldstable` (*oldstable/Dockerfile*)](https://github.com/tianon/docker-brew-debian/blob/d431f09a3730996c0f759eb446bff454f715a321/oldstable/Dockerfile)
- [`oldstable-backports` (*oldstable/backports/Dockerfile*)](https://github.com/tianon/docker-brew-debian/blob/d431f09a3730996c0f759eb446bff454f715a321/oldstable/backports/Dockerfile)
- [`sid` (*sid/Dockerfile*)](https://github.com/tianon/docker-brew-debian/blob/15a046ef540d8956940fff853ef6c8c3feab8d0a/sid/Dockerfile)
- [`6.0.10`, `6.0`, `6`, `squeeze` (*squeeze/Dockerfile*)](https://github.com/tianon/docker-brew-debian/blob/8913a3ebafdfa6a2e54ca265983252edcbbb76a6/squeeze/Dockerfile)
- [`stable` (*stable/Dockerfile*)](https://github.com/tianon/docker-brew-debian/blob/8913a3ebafdfa6a2e54ca265983252edcbbb76a6/stable/Dockerfile)
- [`stable-backports` (*stable/backports/Dockerfile*)](https://github.com/tianon/docker-brew-debian/blob/8913a3ebafdfa6a2e54ca265983252edcbbb76a6/stable/backports/Dockerfile)
- [`stable` (*stable/Dockerfile*)](https://github.com/tianon/docker-brew-debian/blob/d431f09a3730996c0f759eb446bff454f715a321/stable/Dockerfile)
- [`stable-backports` (*stable/backports/Dockerfile*)](https://github.com/tianon/docker-brew-debian/blob/d431f09a3730996c0f759eb446bff454f715a321/stable/backports/Dockerfile)
- [`stretch` (*stretch/Dockerfile*)](https://github.com/tianon/docker-brew-debian/blob/15a046ef540d8956940fff853ef6c8c3feab8d0a/stretch/Dockerfile)
- [`testing` (*testing/Dockerfile*)](https://github.com/tianon/docker-brew-debian/blob/15a046ef540d8956940fff853ef6c8c3feab8d0a/testing/Dockerfile)
- [`unstable` (*unstable/Dockerfile*)](https://github.com/tianon/docker-brew-debian/blob/15a046ef540d8956940fff853ef6c8c3feab8d0a/unstable/Dockerfile)
- [`7.9`, `7`, `wheezy` (*wheezy/Dockerfile*)](https://github.com/tianon/docker-brew-debian/blob/8913a3ebafdfa6a2e54ca265983252edcbbb76a6/wheezy/Dockerfile)
- [`wheezy-backports` (*wheezy/backports/Dockerfile*)](https://github.com/tianon/docker-brew-debian/blob/8913a3ebafdfa6a2e54ca265983252edcbbb76a6/wheezy/backports/Dockerfile)
- [`7.9`, `7`, `wheezy` (*wheezy/Dockerfile*)](https://github.com/tianon/docker-brew-debian/blob/d431f09a3730996c0f759eb446bff454f715a321/wheezy/Dockerfile)
- [`wheezy-backports` (*wheezy/backports/Dockerfile*)](https://github.com/tianon/docker-brew-debian/blob/d431f09a3730996c0f759eb446bff454f715a321/wheezy/backports/Dockerfile)
- [`rc-buggy` (*debian/rc-buggy/Dockerfile*)](https://github.com/tianon/dockerfiles/blob/22a998f815d55217afa0075411b810b8889ceac1/debian/rc-buggy/Dockerfile)
- [`experimental` (*debian/experimental/Dockerfile*)](https://github.com/tianon/dockerfiles/blob/22a998f815d55217afa0075411b810b8889ceac1/debian/experimental/Dockerfile)
[![](https://badge.imagelayers.io/debian:latest.svg)](https://imagelayers.io/?images=debian:8.3,debian:jessie-backports,debian:oldstable,debian:oldstable-backports,debian:sid,debian:6.0.10,debian:stable,debian:stable-backports,debian:stretch,debian:testing,debian:unstable,debian:7.9,debian:wheezy-backports,debian:rc-buggy,debian:experimental)
[![](https://badge.imagelayers.io/debian:latest.svg)](https://imagelayers.io/?images=debian:8.3,debian:jessie-backports,debian:oldstable,debian:oldstable-backports,debian:sid,debian:stable,debian:stable-backports,debian:stretch,debian:testing,debian:unstable,debian:7.9,debian:wheezy-backports,debian:rc-buggy,debian:experimental)
For more information about this image and its history, please see [the relevant manifest file (`library/debian`)](https://github.com/docker-library/official-images/blob/master/library/debian). This image is updated via pull requests to [the `docker-library/official-images` GitHub repo](https://github.com/docker-library/official-images).

View File

@ -15,7 +15,7 @@ For detailed information about the virtual/transfer sizes and individual layers
# Overview
The images in this repository contain IBM WebSphere Application Server Liberty for Developers and the IBM Java Runtime Environment. See the license section below for restrictions relating to the usage of this image. For more information on WebSphere Application Server Liberty, see the [WASdev](https://developer.ibm.com/wasdev/docs/category/getting-started/) site.
The images in this repository contain IBM WebSphere Application Server Liberty for Developers and the IBM Java Runtime Environment. See the license section below for restrictions relating to the use of this image. For more information about WebSphere Application Server Liberty, see the [WASdev](https://developer.ibm.com/wasdev/docs/category/getting-started/) site.
# Images
@ -29,13 +29,13 @@ COPY server.xml /config/
RUN installUtility install --acceptLicense defaultServer
```
The `common` image adds a set of features that are expected to be of use for a typical production scenario. These features are: `appSecurity-2.0`, `collectiveMember-1.0`, `localConnector-1.0`, `ldapRegistry-3.0`, `monitor-1.0`, `requestTiming-1.0`, `restConnector-1.0`, `sessionDatabase-1.0`, `ssl-1.0` and `webCache-1.0`. This image is the basis for the `webProfile6` and `webProfile7` images.
The `common` image adds a set of features that are expected to be of use for a typical production scenario. These features are: `appSecurity-2.0`, `collectiveMember-1.0`, `localConnector-1.0`, `ldapRegistry-3.0`, `monitor-1.0`, `requestTiming-1.0`, `restConnector-1.0`, `sessionDatabase-1.0`, `ssl-1.0`, and `webCache-1.0`. This image is the basis for the `webProfile6` and `webProfile7` images.
The `webProfile6` image contains the features required for Java EE6 Web Profile compliance. It also pulls in additional features to bring the contents in to line with the features available for download via the runtime JAR, most notably the features required for OSGi applications.
The `webProfile6` image contains the features required for Java EE6 Web Profile compliance. It also pulls in additional features to bring the contents in to line with the features available for download by using the runtime JAR, most notably the features required for OSGi applications.
The `webProfile7` image contains the features required for Java EE7 Web Profile compliance. The `javaee7` image extends this image and adds the features required for Java EE7 Full Platform compliance. The `javaee7` image is also tagged with `latest`.
There are also corresponding image tags that contain the version number of the Liberty release contained within the image. These are primarily to signpost the current version in use and will be replaced when a subsequent release becomes available. Consequently, only use these tags if you explicitly want your build to break when a new release becomes available. The Liberty zero migration policy means that you can use the non-version specific tags with the confidence that your application will continue to work when a new release becomes available.
There are also corresponding image tags that contain the version number of the Liberty release contained within the image. These are primarily to signpost the current version in use and will be updated when a subsequent release becomes available. Consequently, use these tags only if you explicitly want your build to break when a new release becomes available. The Liberty zero migration policy means that you can use the non-version specific tags knowing that your application will continue to work when a new release becomes available.
# Usage
@ -45,7 +45,7 @@ The images are designed to support a number of different usage patterns. The fol
<httpEndpoint host="*" httpPort="9080" httpsPort="-1"/>
```
1. Each image contains a default server configuration that specifies the corresponding features and exposes ports 9080 and 9443 for HTTP and HTTPS respectively. A WAR file can therefore be mounted in to the `dropins` directory of this server and run. The following example starts a container in the background running a WAR file from the host file system with the HTTP and HTTPS ports mapped to 80 and 443 respectively.
1. Each image contains a default server configuration that specifies the corresponding features and exposes ports 9080 and 9443 for HTTP and HTTPS respectively. A .WAR file can therefore be mounted in the `dropins` directory of this server and run. The following example starts a container in the background running a .WAR file from the host file system with the HTTP and HTTPS ports mapped to 80 and 443 respectively.
```console
$ docker run -d -p 80:9080 -p 443:9443 \
@ -53,11 +53,11 @@ The images are designed to support a number of different usage patterns. The fol
websphere-liberty:webProfile6
```
Once the server has started, you can browse to http://localhost/Sample1/SimpleServlet on the Docker host.
When the server is started, you can browse to http://localhost/Sample1/SimpleServlet on the Docker host.
Note: If you are using the boot2docker virtual machine on OS X or Windows, you'll need to get the IP of the virtual host using the command `boot2docker ip` instead of using localhost.
Note: If you are using the boot2docker virtual machine on OS X or Windows, you need to get the IP of the virtual host by using the command `boot2docker ip` instead of by using localhost.
2. For greater flexibility over configuration, it is possible to mount an entire server configuration directory from the host and then specify the server name as a parameter to the run command. Note that this particular example server configuration only provides HTTP access.
2. For greater flexibility over configuration, it is possible to mount an entire server configuration directory from the host and then specify the server name as a parameter to the run command. Note: This particular example server configuration provides only HTTP access.
```console
$ docker run -d -p 80:9080 \
@ -65,7 +65,7 @@ The images are designed to support a number of different usage patterns. The fol
websphere-liberty:webProfile6
```
3. It is also possible to build an application layer on top of this image using either the default server configuration or a new server configuration. Here we have copied the `Sample1.war` from `/tmp/DefaultServletEngine/dropins` to the same directory as the following Dockerfile.
3. You can also build an application layer on top of this image by using either the default server configuration or a new server configuration. In this example, we have copied the `Sample1.war` from `/tmp/DefaultServletEngine/dropins` to the same directory as the following Dockerfile.
```dockerfile
FROM websphere-liberty:webProfile6
@ -79,7 +79,7 @@ The images are designed to support a number of different usage patterns. The fol
$ docker run -d -p 80:9080 -p 443:9443 app
```
4. Lastly, it is possible to mount a data volume container containing the application and the server configuration on to the image. This has the benefit that it has no dependency on files from the host but still allows the application container to be easily re-mounted on a newer version of the application server image. The example assumes that you have copied the `/tmp/DefaultServletEngine` directory in to the same directory as the Dockerfile.
4. You can mount a data volume container that contains the application and the server configuration on to the image. This has the benefit that it has no dependency on files from the host but still allows the application container to be easily re-mounted on a newer version of the application server image. This example assumes that you have copied the `/tmp/DefaultServletEngine` directory in to the same directory as the Dockerfile.
Build and run the data volume container:
@ -103,7 +103,7 @@ The images are designed to support a number of different usage patterns. The fol
# Using IBM JRE Class data sharing
The IBM JRE provides a feature [Class data sharing](http://www-01.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.lnx.80.doc/diag/understanding/shared_classes.html) which offers transparent and dynamic sharing of data between multiple Java Virtual Machines running on the same host using shared memory backed by a file. When running the Liberty Docker image, it looks for the file at `/opt/ibm/wlp/output/.classCache`. To benefit from Class data sharing, this location needs to be shared between containers either via the host or a data volume container.
The IBM JRE provides a feature [Class data sharing](http://www-01.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.lnx.80.doc/diag/understanding/shared_classes.html) which offers transparent and dynamic sharing of data between multiple Java Virtual Machines running on the same host by using shared memory backed by a file. When running the Liberty Docker image, it looks for the file at `/opt/ibm/wlp/output/.classCache`. To benefit from Class data sharing, this location needs to be shared between containers either through the host or a data volume container.
Taking the application image from example 3 above, containers can share the host file location (containing the shared cache) `/tmp/websphere-liberty/classCache` as follows:
@ -112,14 +112,14 @@ docker run -d -p 80:9080 -p 443:9443 \
-v /tmp/websphere-liberty/classCache:/opt/ibm/wlp/output/.classCache app
```
Alternatively, create a named data volume container that exposes a volume at the location of the shared file:
Or, create a named data volume container that exposes a volume at the location of the shared file:
```console
docker run -e LICENSE=accept -v /opt/ibm/wlp/output/.classCache \
--name classcache websphere-liberty true
```
Then run the WebSphere Liberty image with the volumes from the data volume container classcache mounted as follows:
Then, run the WebSphere Liberty image with the volumes from the data volume container classcache mounted as follows:
```console
docker run -d -p 80:9080 -p 443:9443 --volumes-from classcache app