Fix scripts in yaml and doc

pull/6/head
Harry Zhang 2015-09-22 17:37:15 +08:00
parent 56809f056e
commit 00f5206627
3 changed files with 35 additions and 29 deletions

View File

@ -45,33 +45,33 @@ This sidecar mode brings a new workflow for Java users:
![](workflow.png?raw=true "Workflow") ![](workflow.png?raw=true "Workflow")
As you can see, user can create a `sample:v2` container as sidecar to "provide" war file to Tomcat by copying it to the shared `emptyDir` volume. And Pod will make sure the two containers compose a "atomic" scheduling unit, which is perfect for this case. Thus, your application version management will be totally seperated from web server management. As you can see, user can create a `sample:v2` container as sidecar to "provide" war file to Tomcat by copying it to the shared `emptyDir` volume. And Pod will make sure the two containers compose an "atomic" scheduling unit, which is perfect for this case. Thus, your application version management will be totally seperated from web server management.
For example, if you gonna change the configurations of your Tomcat: For example, if you are going to change the configurations of your Tomcat:
``` ```sh
docker exec -it <tomcat_container_id> /bin/bash $ docker exec -it <tomcat_container_id> /bin/bash
# do your change, and then commit it to a new image # make some change, and then commit it to a new image
docker commit <tomcat_container_id> mytomcat:7.0-dev $ docker commit <tomcat_container_id> mytomcat:7.0-dev
``` ```
Done! The new Tomcat image **will not** mess up with your `sample.war` file. Done! The new Tomcat image **will not** mess up with your `sample.war` file. You can re-use your tomcat image with lots of different war container images for lots of different apps without having to build lots of different images.
You can also upgrade your app to new version seperately, without creating a new "Tomcat plus app" image (and this image will become huge as unionfs will keep all the old war files in its layers). Also this means that rolling out a new Tomcat to patch security or whatever else, doesn't require rebuilding N different images.
**Why don't put my `sample.war` in a host dir and mount it to tomcat container?** **Why not put my `sample.war` in a host dir and mount it to tomcat container?**
You have to **manage the volumes** in this case, for example, when you restart or scale the Pod on another Node, your contents is not ready on that host. You have to **manage the volumes** in this case, for example, when you restart or scale the pod on another node, your contents is not ready on that host.
Generally, we have to set up a distributed file system (NFS at least) volume to solve this (if we do not have GCE PD volume). But seriously, it's a overkill. Generally, we have to set up a distributed file system (NFS at least) volume to solve this (if we do not have GCE PD volume). But this is generally unnecessary.
### How To ### How To Set this Up
In Kubernetes a [_Pod_](../../docs/user-guide/pods.md) is the smallest deployable unit that can be created, scheduled, and managed. Its a collocated group of containers that share an IP and storage volume. In Kubernetes a [_Pod_](../../docs/user-guide/pods.md) is the smallest deployable unit that can be created, scheduled, and managed. It's a collocated group of containers that share an IP and storage volume.
Here is the config [javaweb.yaml](javaweb.yaml) for Java Web pod: Here is the config [javaweb.yaml](javaweb.yaml) for Java Web pod:
NOTE: you should define `war` contaienr **first** as it is the "provider". NOTE: you should define `war` container **first** as it is the "provider".
<!-- BEGIN MUNGE: javaweb.yaml --> <!-- BEGIN MUNGE: javaweb.yaml -->
@ -98,6 +98,7 @@ spec:
hostPort: 8001 hostPort: 8001
volumes: volumes:
- name: app-volume - name: app-volume
emptyDir: {}
``` ```
<!-- END MUNGE: EXAMPLE --> <!-- END MUNGE: EXAMPLE -->
@ -110,21 +111,21 @@ ADD sample.war sample.war
CMD "sh" "mv.sh" CMD "sh" "mv.sh"
``` ```
And the content inf `mv.sh` is: And the contents of `mv.sh` is:
```sh ```sh
cp /sample.war /app cp /sample.war /app
tail -f /etc/hosts tail -f /dev/null
``` ```
#### Explaination #### Explanation
1. 'war' container only contains the `war` file of your app 1. 'war' container only contains the `war` file of your app
2. 'war' container's CMD try to copy `sample.war` to the `emptyDir` volume path 2. 'war' container's CMD tries to copy `sample.war` to the `emptyDir` volume path
3. The last line of `tailf -f` is just used to hold the container, as RC does not support one-off task 3. The last line of `tailf -f` is just used to hold the container, as Replication Controller does not support one-off task
4. 'tomcat' container will load the `sample.war` from volume path 4. 'tomcat' container will load the `sample.war` from volume path
What's more, if you don't want to add a build in `mv.sh` script in the `war` container, you can use Pod lifecycle handler to do the copy work, here's a example [javaweb-2.yaml](javaweb-2.yaml): What's more, if you don't want to enclose a build-in `mv.sh` script in the `war` container, you can use Pod lifecycle handler to do the copy work, here's a example [javaweb-2.yaml](javaweb-2.yaml):
<!-- BEGIN MUNGE: javaweb-2.yaml --> <!-- BEGIN MUNGE: javaweb-2.yaml -->
@ -159,6 +160,7 @@ spec:
hostPort: 8001 hostPort: 8001
volumes: volumes:
- name: app-volume - name: app-volume
emptyDir: {}
``` ```
<!-- END MUNGE: EXAMPLE --> <!-- END MUNGE: EXAMPLE -->
@ -168,13 +170,13 @@ And the `resouer/sample:v2` Dockerfile is quite simple:
``` ```
FROM busybox:latest FROM busybox:latest
ADD sample.war sample.war ADD sample.war sample.war
CMD "tail" "-f" "/etc/hosts" CMD "tail" "-f" "/dev/null"
``` ```
#### Explaination #### Explanation
1. 'war' container only contains the `war` file of your app 1. 'war' container only contains the `war` file of your app
2. 'war' container's CMD use `tail` to hold the container, nothing else 2. 'war' container's CMD uses `tail -f` to hold the container, nothing more
3. The `postStart` lifecycle handler will do `cp` after the `war` container is started 3. The `postStart` lifecycle handler will do `cp` after the `war` container is started
4. Again 'tomcat' container will load the `sample.war` from volume path 4. Again 'tomcat' container will load the `sample.war` from volume path
@ -185,18 +187,18 @@ Done! Now your `war` container contains nothing except `sample.war`, clean enoug
Create the Java web pod: Create the Java web pod:
```sh ```sh
kubectl create -f examples/javaweb-tomcat-sidecar/javaweb-2.yaml $ kubectl create -f examples/javaweb-tomcat-sidecar/javaweb-2.yaml
``` ```
Check status of the pod: Check status of the pod:
```sh ```sh
kubectl get -w po $ kubectl get -w po
NAME READY STATUS RESTARTS AGE NAME READY STATUS RESTARTS AGE
javaweb-2 2/2 Running 0 7s javaweb-2 2/2 Running 0 7s
``` ```
Wait for the status to `2/2` and `Running`. Then you can visit "Hello, World" on `http://localhost:8001/sample/index.html` Wait for the status to `2/2` and `Running`. Then you can visit "Hello, World" page on `http://localhost:8001/sample/index.html`
You can also test `javaweb.yaml` in the same way. You can also test `javaweb.yaml` in the same way.
@ -205,7 +207,7 @@ You can also test `javaweb.yaml` in the same way.
All resources created in this application can be deleted: All resources created in this application can be deleted:
```sh ```sh
kubectl delete -f examples/javaweb-tomcat-sidecar/javaweb-2.yaml $ kubectl delete -f examples/javaweb-tomcat-sidecar/javaweb-2.yaml
``` ```

View File

@ -26,4 +26,6 @@ spec:
- containerPort: 8080 - containerPort: 8080
hostPort: 8001 hostPort: 8001
volumes: volumes:
- name: app-volume - name: app-volume
emptyDir: {}

View File

@ -19,4 +19,6 @@ spec:
- containerPort: 8080 - containerPort: 8080
hostPort: 8001 hostPort: 8001
volumes: volumes:
- name: app-volume - name: app-volume
emptyDir: {}