docker-library
/
docs
mirror of https://github.com/docker-library/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Run update.sh

This commit is contained in:
Docker Library Bot 2019-05-08 23:20:41 +00:00
parent ad4646d4e1
commit 65b6cd8eca
2 changed files with 34 additions and 120 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

94
open-liberty/README.md
View File

@ -126,9 +126,23 @@ There are also additional images for different JVM combinations. Currently there
# Usage # Usage
The images are designed to support a number of different usage patterns. The following examples assume that [DefaultServletEngine.zip](https://github.com/WASdev/sample.servlet/releases/download/V1/DefaultServletEngine.zip) has been extracted to `/tmp`. The images are designed to support a number of different usage patterns. The following examples are based on the Java EE8 Liberty [application deployment sample](https://developer.ibm.com/wasdev/docs/article_appdeployment/) and assume that [DefaultServletEngine.zip](https://github.com/WASdev/sample.servlet/releases/download/V1/DefaultServletEngine.zip) has been extracted to `/tmp` and the `server.xml` updated to accept HTTP connections from outside of the container by adding the following element inside the `server` stanza (if not using one of the pre-packaged `server.xml` files with our tags):
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. ```xml
<httpEndpoint host="*" httpPort="9080" httpsPort="-1"/>
```
## Application Image
It is a very strong best practice to create an extending Docker image, we called it the `application image`, that encapsulates an application and its configuration. This creates a robust, self-contained and predictable Docker image that can span new containers upon request, without relying on volumes or other external runtime artifacts that may behave different over time.
If you want to build the smallest possible WebSphere Liberty application image you can start with our `kernel` tag, add your artifacts, and run `configure.sh` to grow the set of features to be fit-for-purpose. Please see our [GitHub page](https://github.com/OpenLiberty/ci.docker#building-an-application-image) for more details.
## Using volumes for configuration
This pattern can be useful for quick experiments / early development (i.e. `I just want to run the application as I iterate over it`), but should not be used for development scenarios that involve different teams and environments - for these cases the `Application Image` pattern described above is the way to go.
When using `volumes`, an application file can 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 ```console
$ docker run -d -p 80:9080 -p 443:9443 \ $ docker run -d -p 80:9080 -p 443:9443 \
@ -138,67 +152,25 @@ The images are designed to support a number of different usage patterns. The fol
When the server is 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.
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. 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.
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 ```console
$ docker run -d -p 80:9080 \ $ docker run -d -p 80:9080 \
-v /tmp/DefaultServletEngine:/config \ -v /tmp/DefaultServletEngine:/config \
open-liberty:webProfile8-sfj open-liberty:webProfile8
```
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 open-liberty:webProfile8
COPY Sample1.war /config/dropins/
```
This can then be built and run as follows:
```console
$ docker build -t app .
$ docker run -d -p 80:9080 -p 443:9443 app
```
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:
```dockerfile
FROM open-liberty:webProfile8
COPY DefaultServletEngine /config
```
```console
$ docker build -t app-image .
$ docker run -d -v /config \
--name app app-image true
```
Run the Open Liberty image with the volumes from the data volume container mounted:
```console
$ docker run -d -p 80:9080 \
--volumes-from app open-liberty:webProfile8
``` ```
# Using `springBoot` images # Using `springBoot` images
The `springBoot` images introduce capabilities specific to the support of Spring Boot applications, including the `springBootUtility` used to separate Spring Boot applications into thin applications and dependency library caches. To elaborate these capabilities this section assumes the standalone Spring Boot 2.0.x application `hellospringboot.jar` exists in the `/tmp` directory. The `springBoot` images introduce capabilities specific to the support of Spring Boot applications, including the `springBootUtility` used to separate Spring Boot applications into thin applications and dependency library caches. To elaborate these capabilities this section assumes the standalone Spring Boot 2.0.x application `hellospringboot.jar` exists in the `/tmp` directory.
1. A Spring Boot application JAR deploys to the `dropins/spring` directory within the default server configuration, not the `dropins` directory. Liberty allows one Spring Boot application per server configuration. The following example starts a container running a Spring Boot application. 1. A Spring Boot application JAR deploys to the `dropins/spring` directory within the default server configuration, not the `dropins` directory. Liberty allows one Spring Boot application per server configuration. You can create a Spring Boot application layer over this image by adding the application JAR to the `dropins/spring` directory. In this example we copied `hellospringboot.jar` from `/tmp` to the same directory containing the following Dockerfile.
```console
$ docker run -d -p 8080:9080 \
-v /tmp/hellospringboot.jar:/config/dropins/spring/hellospringboot.jar \
open-liberty:springBoot2
```
Similarly, you can create a Spring Boot application layer over this image by adding the application JAR to the `dropins/spring` directory. In this example we copied `hellospringboot.jar` from `/tmp` to the same directory containing the following Dockerfile.
```dockerfile ```dockerfile
FROM open-liberty:springBoot2 FROM open-liberty:springBoot2
COPY hellospringboot.jar /config/dropins/spring/ COPY --chown=1001:0 hellospringboot.jar /config/dropins/spring/
``` ```
The custom image can be built and run as follows. The custom image can be built and run as follows.
@ -210,29 +182,11 @@ The `springBoot` images introduce capabilities specific to the support of Spring
2. The `springBoot` images provide the library cache directory, `lib.index.cache`, which contains an indexed library cache created by the `springBootUtility` command. Use `lib.index.cache` to provide the library cache for a thin application. 2. The `springBoot` images provide the library cache directory, `lib.index.cache`, which contains an indexed library cache created by the `springBootUtility` command. Use `lib.index.cache` to provide the library cache for a thin application.
For example, run the following command to thin the `hellospringboot.jar` application. You can use the `springBootUtility` command to create thin application and library cache layers over a `springBoot` image. The following example uses docker staging to efficiently build an image that deploys a fat Spring Boot application as two layers containing a thin application and a library cache.
```console
$ <wlp>/bin/springBootUtility thin \
--sourceAppPath=/tmp/hellospringboot.jar \
--targetLibCachePath=/tmp/lib.index.cache \
--targetThinAppPath=/tmp/thinhellospringboot.jar
```
You can run the thin application by mounting both the target application JAR and library cache when starting the container.
```console
$ docker run -d -p 8080:9080 \
-v /tmp/thinhellospringboot.jar:/config/dropins/spring/thinhellospringboot.jar \
-v /tmp/lib.index.cache:/lib.index.cache \
open-liberty:springBoot2
```
Similarly, you can use the `springBootUtility` command to create thin application and library cache layers over a `springBoot` image. The following example uses docker staging to efficiently build an image that deploys a fat Spring Boot application as two layers containing a thin application and a library cache.
```dockerfile ```dockerfile
FROM open-liberty:springBoot2 as staging FROM open-liberty:springBoot2 as staging
COPY hellospringboot.jar /staging/myFatApp.jar COPY --chown=1001:0 hellospringboot.jar /staging/myFatApp.jar
RUN springBootUtility thin \ RUN springBootUtility thin \
--sourceAppPath=/staging/myFatApp.jar \ --sourceAppPath=/staging/myFatApp.jar \
--targetThinAppPath=/staging/myThinApp.jar \ --targetThinAppPath=/staging/myThinApp.jar \

52
websphere-liberty/README.md
View File

@ -153,25 +153,11 @@ The images are designed to support a number of different usage patterns. The fol
It is a very strong best practice to create an extending Docker image, we called it the `application image`, that encapsulates an application and its configuration. This creates a robust, self-contained and predictable Docker image that can span new containers upon request, without relying on volumes or other external runtime artifacts that may behave different over time. It is a very strong best practice to create an extending Docker image, we called it the `application image`, that encapsulates an application and its configuration. This creates a robust, self-contained and predictable Docker image that can span new containers upon request, without relying on volumes or other external runtime artifacts that may behave different over time.
If you want to build the smallest possible WebSphere Liberty application image you can start with our `kernel` tag, add your artifacts, and run `installUtility` to grow the set of features to be fit-for-purpose. Scroll up to the `Tags` section for an example. If you want to build the smallest possible WebSphere Liberty application image you can start with our `kernel` tag, add your artifacts, and run `configure.sh` to grow the set of features to be fit-for-purpose. Please see our [GitHub page](https://github.com/WASdev/ci.docker#building-an-application-image) for more details.
If you want to start with one of the pre-packaged tags you do not need to run `installUtility` if the tag contains all the features you required, and you may not even need to copy a `server.xml` - unless you have updates you want to make. So one example of building an application image that runs a MicroProfile 2.0 application is:
```dockerfile
FROM websphere-liberty:microprofile2
COPY --chown=1001:0 Sample1.war /config/dropins/
```
You can then build and run this image:
```console
$ docker build -t app .
$ docker run -d -p 80:9080 -p 443:9443 app
```
## Using volumes for configuration ## Using volumes for configuration
This pattern can be useful for quick experiments / early development (i.e. `I just want to run the application as I iterate over it`), can should not be used for development scenarios that involve different teams and environments - for these cases the `Application Image` pattern described above is the way to go. This pattern can be useful for quick experiments / early development (i.e. `I just want to run the application as I iterate over it`), but should not be used for development scenarios that involve different teams and environments - for these cases the `Application Image` pattern described above is the way to go.
When using `volumes`, an application file can 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. When using `volumes`, an application file can 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.
@ -197,19 +183,11 @@ For greater flexibility over configuration, it is possible to mount an entire se
The `springBoot` images introduce capabilities specific to the support of Spring Boot applications, including the `springBootUtility` used to separate Spring Boot applications into thin applications and dependency library caches. To elaborate these capabilities this section assumes the standalone Spring Boot 2.0.x application `hellospringboot.jar` exists in the `/tmp` directory. The `springBoot` images introduce capabilities specific to the support of Spring Boot applications, including the `springBootUtility` used to separate Spring Boot applications into thin applications and dependency library caches. To elaborate these capabilities this section assumes the standalone Spring Boot 2.0.x application `hellospringboot.jar` exists in the `/tmp` directory.
1. A Spring Boot application JAR deploys to the `dropins/spring` directory within the default server configuration, not the `dropins` directory. Liberty allows one Spring Boot application per server configuration. The following example starts a container running a Spring Boot application. 1. A Spring Boot application JAR deploys to the `dropins/spring` directory within the default server configuration, not the `dropins` directory. Liberty allows one Spring Boot application per server configuration. You can create a Spring Boot application layer over this image by adding the application JAR to the `dropins/spring` directory. In this example we copied `hellospringboot.jar` from `/tmp` to the same directory containing the following Dockerfile.
```console
$ docker run -d -p 8080:9080 \
-v /tmp/hellospringboot.jar:/config/dropins/spring/hellospringboot.jar \
websphere-liberty:springBoot2
```
Similarly, you can create a Spring Boot application layer over this image by adding the application JAR to the `dropins/spring` directory. In this example we copied `hellospringboot.jar` from `/tmp` to the same directory containing the following Dockerfile.
```dockerfile ```dockerfile
FROM websphere-liberty:springBoot2 FROM websphere-liberty:springBoot2
COPY hellospringboot.jar /config/dropins/spring/ COPY --chown=1001:0 hellospringboot.jar /config/dropins/spring/
``` ```
The custom image can be built and run as follows. The custom image can be built and run as follows.
@ -221,29 +199,11 @@ The `springBoot` images introduce capabilities specific to the support of Spring
2. The `springBoot` images provide the library cache directory, `lib.index.cache`, which contains an indexed library cache created by the `springBootUtility` command. Use `lib.index.cache` to provide the library cache for a thin application. 2. The `springBoot` images provide the library cache directory, `lib.index.cache`, which contains an indexed library cache created by the `springBootUtility` command. Use `lib.index.cache` to provide the library cache for a thin application.
For example, run the following command to thin the `hellospringboot.jar` application. You can use the `springBootUtility` command to create thin application and library cache layers over a `springBoot` image. The following example uses docker staging to efficiently build an image that deploys a fat Spring Boot application as two layers containing a thin application and a library cache.
```console
$ <wlp>/bin/springBootUtility thin \
--sourceAppPath=/tmp/hellospringboot.jar \
--targetLibCachePath=/tmp/lib.index.cache \
--targetThinAppPath=/tmp/thinhellospringboot.jar
```
You can run the thin application by mounting both the target application JAR and library cache when starting the container.
```console
$ docker run -d -p 8080:9080 \
-v /tmp/thinhellospringboot.jar:/config/dropins/spring/thinhellospringboot.jar \
-v /tmp/lib.index.cache:/lib.index.cache \
websphere-liberty:springBoot2
```
Similarly, you can use the `springBootUtility` command to create thin application and library cache layers over a `springBoot` image. The following example uses docker staging to efficiently build an image that deploys a fat Spring Boot application as two layers containing a thin application and a library cache.
```dockerfile ```dockerfile
FROM websphere-liberty:springBoot2 as staging FROM websphere-liberty:springBoot2 as staging
COPY hellospringboot.jar /staging/myFatApp.jar COPY --chown=1001:0 hellospringboot.jar /staging/myFatApp.jar
RUN springBootUtility thin \ RUN springBootUtility thin \
--sourceAppPath=/staging/myFatApp.jar \ --sourceAppPath=/staging/myFatApp.jar \
--targetThinAppPath=/staging/myThinApp.jar \ --targetThinAppPath=/staging/myThinApp.jar \