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

Merge pull request #1474 from arthurdm/patch-11 

Clarify WebSphere Liberty Spring usage
This commit is contained in:
yosifkit 2019-05-08 15:46:31 -07:00 committed by GitHub
parent 876c025fd9 ff0e1aa8c7
commit 7f8d4fb6b8
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 6 additions and 46 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

52
websphere-liberty/content.md
View File

@ -78,25 +78,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.
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 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 %%IMAGE%%: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
```
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.
## 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.
@ -122,19 +108,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.
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.
```console
$ docker run -d -p 8080:9080 \
-v /tmp/hellospringboot.jar:/config/dropins/spring/hellospringboot.jar \
%%IMAGE%%: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.
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.
```dockerfile
FROM %%IMAGE%%: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.
@ -146,29 +124,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.
For example, run the following command to thin the `hellospringboot.jar` application.
```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 \
%%IMAGE%%: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.
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
FROM %%IMAGE%%:springBoot2 as staging
COPY hellospringboot.jar /staging/myFatApp.jar
COPY --chown=1001:0 hellospringboot.jar /staging/myFatApp.jar
RUN springBootUtility thin \
--sourceAppPath=/staging/myFatApp.jar \
--targetThinAppPath=/staging/myThinApp.jar \