Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sample scripts to create an image with an applicaiton running on a ma… #401

Merged
merged 9 commits into from
Jul 20, 2017

Conversation

aseembajaj
Copy link
Member

…naged server running in MSI mode (Managed Server Independence mode)

…naged server running in MSI mode (Managed Server Independence mode)
Copy link
Member

@Djelibeybi Djelibeybi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are some changes that need to be made to make the resulting image more efficient.


# Environment variables required for this build (do NOT change)
# -------------------------------------------------------------
ENV MW_HOME="$ORACLE_HOME"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These three ENV directives should be combined into a single directive/layer.

# Copy scripts
# --------------------------------
USER oracle
COPY container-scripts/provision-domain-for-msi.py /u01/oracle/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These three COPY directives should be combined into a single directive/layer.


# Scripts and parameters for launching
# -----------------------------------
COPY container-scripts/launcher.sh /u01/oracle/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This COPY directive should be included in the previous COPY so that it's contained in the same layer.


EXPOSE 8011
WORKDIR $ORACLE_HOME/wlserver/samples/domains/msi-sample
ENTRYPOINT "/usr/bin/bash" "/u01/oracle/launcher.sh" "$ORACLE_HOME/wlserver/samples/domains/msi-sample" "ms1" "weblogic" "weblogic1" $number_of_ms
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please do not use bash as the ENTRYPOINT. You should be calling launcher.sh and providing the command-line parameters via a CMD directive. You should also switch this to use the JSON representation.

https://docs.docker.com/engine/reference/builder/#understand-how-cmd-and-entrypoint-interact

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi Avi. I have removed the use of bash as entry point. But I need to use shell form of Entrypoint because I need variable replacement that is otherwise unavailable in exec form. So, I can't split this into ENTRYPOINT and CMD. Nor can I switch to JSON form. Using either of these causes variable replacement to stop working.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your launcher.sh should just be able to read the environment variable as you're setting it higher in the Dockerfile. You don't need to pass it as a parameter here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, you are right. So, I'll be making these changes for this particular suggestion that you made:

  • No use of bash, invoke launcher.sh directly
  • Use JSON format
  • No parameter needed, so no need to specify CMD

Here is what the updated directive will look like:

ENTRYPOINT ["/u01/oracle/launcher.sh"]


# Arguments
# ---------
ARG name
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These three ARG directives should be combined into a single directive/layer.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi Avi. I can't seem to find an ARG directive that can be used to declare multiple arguments:
https://docs.docker.com/engine/reference/builder/#arg
Can you please point me to it? Thanks

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, you're right. Was getting confused with ENV directives.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should these ARG directives not get default values then?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that's right Avi. These are arguments that specify what application to deploy and from where. So there can't be any defaults for these.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How can there not be defaults? What happens if these are not provided? Your launcher/entrypoint will need to handle the case of being run without any ARG values gracefully.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are not options, these are more like required arguments. How can we default on the application directory to be added?

I can make them default to the application bundled in the sample directory (like the way it was before these arguments were introduced). What do you say?

Arguments

---------

ARG name=summercamps
ARG source=apps/summercamps.ear
ARG simple_filename=summercamps.ear

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That seems fine. Or your container should throw an error and refuse to start if the required arguments are not provided. Whatever you feel is the best outcome.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi Avi,

I'll go with default. These are sample scripts. Customers might have to change the script anyways to add more parameters to deployment, they can choose their own defaults at that time. We can use the default based on samples bundled in this directory.

# Copy scripts
# --------------------------------
USER oracle
COPY container-scripts/add-app-to-domain.py /u01/oracle/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please combine the two COPY directives into a single directive/layer.

@@ -0,0 +1,19 @@
#! /usr/bin/bash
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This launcher.sh script has no handlers for stop/start. You need to add handlers so that users can use docker stop effectively.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi Avi,

By handlers for stop, did you mean something like trapping (using trap) SIGKILL and SIGTERM and passing them on to server process?

What do you mean by a handler for start? Isn't launcher the script that will run when we start the container?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, sorry. I meant handlers for SIGKILL and SIGTERM (which are what docker stop calls).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi Avi,

launcher.sh invokes startManagedWebLogic.sh. This script (startManagedWebLogic.sh) like startWebLogic.sh used by other docker samples is created during WebLogic domain creation. I think these scripts communicate these signals to the underlying JVM (or not at the very least not inhibit the transmission of signal to the underlying JVM). WLS running in JVM handles SIGTERM and SIGKILL correctly.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have you tested and confirmed that the signal handlers still work as expected?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi Avi,

Following up on your question about behavior of docker stop with WLS, I experimented and found the following.

About docker stop

  1. docker stop sends a SIGTERM to the main process initially and then sends a SIGKILL after some time. This is a configurable value, defaults to 10 seconds.
  2. WebLogic java process handles SIGTERM to perform a forceShutdown() of the server, cleaning up a few things.
  3. When we launch WebLogic using generated shell scripts, sending SIGTERM to the pid of shell script doesn’t invoke the hook mentioned in Add Coherence Dockerfiles and scripts #2
  4. However if we find the pid of the java process (JVM that is running the server) and send a SIGTERM to it, shutdown hook mentioned in Add Coherence Dockerfiles and scripts #2 is invoked
  5. Trying to replicate Project description #3 in Docker image is equally ineffective. More specifically we can try and capture the pid of the process for the WLS startup script being launched as a part of docker container, but trapping SIGTERM (on docker stop) and forwarding to that captured pid is ineffective (like Project description #3)
  6. Perhaps we can replicate Reestruction of folders and scripts #4 in docker image i.e. try to trap SIGTERM and translate to a SIGTERM to all running java processes. But I am having trouble with this because we use oracle slim image in PS2 docker image and “ps” is not available.
  7. For WLS MSI docker image, I have been using the generated WLS script called startManagedWebLogic.sh. But I believe that observations in Project description #3 and Revised work  #5 will be the same if we use startWebLogic.sh for admin server in a regular WLS docker image

About docker kill

docker kill results in a SIGKILL signal. There is no way to intercept or trap it. That is also the case when we send a SIGKILL signal to a WLS server started with shell scripts (outside docker)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this behaviour replicated in the base WebLogic image or introduced by your addition of the launcher.sh script? If the former, please open another issue so that @mriccell can look into that. If the latter, you'll need to reimplement the handlers so that the SIGTERM is sent to the right pid.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi Avi,

As suspected, docker stop isn't converted to a forceShutdown request for WLS server. Here is what I tried:
docker pull container-registry.oracle.com/middleware/weblogic:12.2.1.1
docker run container-registry.oracle.com/middleware/weblogic:12.2.1.1

And then on the side I issued a docker stop request using a generated container name

docker stop epic_meitner

I can see that shutdown hook is not invoked, and the container stopped after 10 seconds (the default difference between the time SIGTERM and SIGKILL are sent to the container process)

Had it worked, I would have expected to see something like the following on stdout of the container:

<Jun 5, 2017 3:18:30,533 PM PDT>
<Jun 5, 2017 3:18:30,534 PM PDT> <Server shutdown has been requested by .>
<Jun 5, 2017 3:18:30,538 PM PDT>
<Jun 5, 2017 3:18:30,549 PM PDT>
<Jun 5, 2017 3:18:30,549 PM PDT>
<Jun 5, 2017 3:18:30,561 PM PDT>
<Jun 5, 2017 3:18:30,601 PM PDT> <JMX Connector Server stopped at service:jmx:iiop://10.147.117.136:7001/jndi/weblogic.management.mbeanservers.edit.>
<Jun 5, 2017 3:18:30,602 PM PDT> <JMX Connector Server stopped at service:jmx:iiop://10.147.117.136:7001/jndi/weblogic.management.mbeanservers.domainruntime.>
<Jun 5, 2017 3:18:30,666 PM PDT> <JMX Connector Server stopped at service:jmx:iiop://10.147.117.136:7001/jndi/weblogic.management.mbeanservers.runtime.>
Stopping Derby server...
Derby server stopped.

Copy link
Member

@Djelibeybi Djelibeybi Jun 6, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please open a new issue for this, so that @mriccell can take a look?

@aseembajaj
Copy link
Member Author

Hi Avi,

Other than the issue about stop / start, I have incorporated all your feedback and updated the pull request.

@mriccell
Copy link
Member

mriccell commented Jun 2, 2017 via email

Djelibeybi
Djelibeybi previously approved these changes Jun 5, 2017
@Djelibeybi
Copy link
Member

I have approved this PR. Just waiting on @brunoborges and @mriccell to complete their review.

@Djelibeybi
Copy link
Member

@aseembajaj I see the new commit you just added, but wouldn't this make more sense as a seperate PR for the upstream createAndStartEmptyDomain.sh script instead?

@aseembajaj
Copy link
Member Author

Hi Avi,

This change only handles MSI server image. The changes to be made for non-MSI setups could be similar, but different.

  • The managed servers in that setup must have been started using NodeManager, so we have to find another way to initiate forceShutdown on those servers
  • The admin server in that setup could be forceShutdown in the same manner. But I would assume that we would want to make a coherent change for both cases that setup

@Djelibeybi
Copy link
Member

@aseembajaj it would be great if you could work with @mriccell to see if you can come up with a more global solution that would work across all downstream images that extend the base WLS image.

@aseembajaj
Copy link
Member Author

Sure, I'll work with Monica and give her inputs about how we can implement this so that all images benefit.


EXPOSE 8011
WORKDIR $ORACLE_HOME/wlserver/samples/domains/msi-sample
ENTRYPOINT "/usr/bin/bash" "/u01/oracle/launcher.sh" "$ORACLE_HOME/wlserver/samples/domains/msi-sample" "ms1" "weblogic" "weblogic1" $number_of_ms
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tge RUN command provision-domain-for-msi.sh parameters such as weblogic weblogic1 8001 ms1 8011 dev $number_of_ms should be set with ENV directive in the dockerfile.

@brunoborges
Copy link
Contributor

Can launcher.sh live on the top level image? If yes, maybe that should be a script for ENTRYPOINT

@aseembajaj
Copy link
Member Author

Hi Bruno,

You are right in that there could be come collaboration in the startup scripts, one for the base image (that helps all extending images) and the ones specific for scenarios (like MSI). Monica and I had a meeting yesterday. Among other things, we decided that I will try to reuse code around container stop. This will involve slight change in base image too (to allow for reusability). But we still need a separate script for extending images (like MSI) because there are some other tasks that are done specific to the image.

brunoborges
brunoborges previously approved these changes Jun 19, 2017
@brunoborges
Copy link
Contributor

@mriccell Monica, mind to follow up on this when possible?

@Djelibeybi
Copy link
Member

Can you please rebase this pull request from master? Some of the files have changed since it was submitted.

@aseembajaj
Copy link
Member Author

Hi Avi, Bruno & Monica,

Based on a meeting with Monica, we had identified 5 changes that I had to make to this. I have been unable to work on those changes as I have been involved with other work. I'll re-submit this request after I make changes.

@Djelibeybi
Copy link
Member

You don't need to resubmit, just push the required changes to your branch and this PR will automatically update and notify us.

@aseembajaj
Copy link
Member Author

Hi Avi, Bruno & Monica,

I have updated the pull request, to incorporate Monica's feedback. Here are my notes from the review:

  • Add a sentence or two about MSI in introduction, running in Docker
  • Environment variable declaration using ENV, move to all arguments
  • managed name prefix as argument
  • Readme.md : A little segment about parameters like default name and default port
  • Try to re-use trap command from base image

Note that for the last item, Monica asked me to comment out my "trap" logic since it is being built into the base image.

Can you please re-review and accept the pull request if you are okay with it? Thanks.

Copy link
Member

@Djelibeybi Djelibeybi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some minor changes required, but some great improvements.

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
cf579fd131fc 12212-msiserver "/u01/oracle/launc..." 2 minutes ago Up 2 minutes 0.0.0.0:8011->8011/tcp vigilant_volhard

$ docker exec -it cf579fd131fc bash
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should never need to exec bash into a container. If you need the user to know something, that log file should be sent to stdout at runtime so that the user can use docker logs (or any of the logging drivers) to get the output.


$ docker exec -it cf579fd131fc bash

$ cat servers/ms3/logs/ms3.log | grep BEA-150018
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As above. You should be tailing this log to stdout by default. Take a look at the Database and other Dockerfiles for examples of this.

@@ -0,0 +1,37 @@
#! /usr/bin/bash
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be #!/bin/bash

fi

bin/startManagedWebLogic.sh $ms_name

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the rest of this script is not needed (it's all commented out) then just remove those lines.

This Dockerfile extends the Oracle WebLogic image by creating a domain that configures a managed
server in MSI mode (or Managed Server Independence mode). In this mode, a managed server can run
without the need of an admin server. Such a managed server is not driven by admin server for
configuration or deployment changes. However, it can handle all configuration and deploymnets
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo: should be "deployments"

Using swarm service creation with this image
--------------------------------------------
The image called 12212-summercamps-msiserver can be used for Docker service creation
to scale out to multiple replicas. docker service creation can only be done
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo: "docker" should be "Docker"

registry you can start one locally. More details can be found here
https://docs.docker.com/registry/deploying/

Here are the three steps you'll need to start, use and push to your local registry.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't provide documentation on how to run a registry, because this will get out of date. You already point to the Docker docs, that's sufficient.

Also, a registry is not required for a service, if you have the same image on all the hosts in the Swarm. It's just that the simplest way for that to happen is to use a local registry. :)

docker tag 12212-summercamps-msiserver localhost:5000/12212-summercamps-msiserver
docker push localhost:5000/12212-summercamps-msiserver

Now that your image is published to the registry, start by joining swarm, either a swarm
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please do not provide instructions on how to use Swarm here either. Rather just point to the Swarm documentation.

argument helps identify the source of the application. The source is copied into the image.
So "simple_filename" helps identify the name of the file where the source is copied to

Using swarm service creation with this image
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your instructions should assume that user has a local registry and Swarm running. You don't have to provide documentation on how to do that. You can provide links to the registry and Swarm documentation though.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @Djelibeybi

Thanks for the inputs. I have incorporated all your feedback. Please take a look.

mriccell
mriccell previously approved these changes Jul 18, 2017
Copy link
Member

@mriccell mriccell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aseembajaj thank you so much for following up with requested changes. I am happy with the changes to address my concerns.

@aseembajaj
Copy link
Member Author

aseembajaj commented Jul 18, 2017 via email

Copy link
Member

@Djelibeybi Djelibeybi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are some minor fixes that are required, but the overall Markdown formatting needs to be reviewed. When I view the entire file, it seems like a lot of the code examples are not formatted correctly.

@@ -18,21 +18,14 @@ Next, to build the base msi image, run:

Finally, to start the Managed Server in MSI mode, run:

$ docker run -d -p 8011:8011 12212-msiserver
$ docker run -p 8011:8011 12212-msiserver
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why did you remove the -d here? The image needs to be run in daemon mode, i.e. the background You should then use docker logs to retrieve the stdout from the running container to determine things like the MS name.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @Djelibeybi I removed -d so that stdout can be shown on the console for further investigation. You had mentioned earlier that "exec bash" wasn't a best practice. Anyways, I'll put it back and user "docker logs" as you suggested. Thanks.

}

3. Push to the local registry
Here is an example of how this image can be pushed to the local registry
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please remove lines 95-97. We shouldn't be documenting how to use a local registry. That's handled by our own documentation as well as the upstream documentation and is out of scope here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright @Djelibeybi, I'll remove those 3 lines.

@@ -94,35 +87,18 @@ So "simple_filename" helps identify the name of the file where the source is cop
Using swarm service creation with this image
--------------------------------------------
The image called 12212-summercamps-msiserver can be used for Docker service creation
to scale out to multiple replicas. docker service creation can only be done
using an image from a docker registry. If you don't have publishing rights to a docker
to scale out to multiple replicas. Docker service creation can only be done
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not accurate: Docker service creation can be done either using a local registry or by ensuring the same image is available to all hosts. Using a local registry is just easier, but it's not mandatory.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @Djelibeybi I have removed that line altogether now

Copy link
Member

@Djelibeybi Djelibeybi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work, thanks.

@Djelibeybi
Copy link
Member

I want @mriccell to give her final approval too, then I'll merge.

Copy link
Member

@mriccell mriccell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I approve these changes

@Djelibeybi Djelibeybi merged commit cbf0aed into oracle:master Jul 20, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants