review and edit, jenkins-ignore

Author: rosemarymarano

docs-source/content/userguide/cicd/_index.md

@@ -2,63 +2,63 @@
 title: "CI/CD"
 date: 2019-04-11T13:01:55-04:00
 weight: 5
-description: "Learn about managing Domain images with CI/CD."
+description: "Learn about managing domain images with CI/CD."
 draft: false
 ---
 
-### Overview 
+### Overview
 
-In this section, we will discuss recommended techniques for managing the evolution
+In this section, we will discuss the recommended techniques for managing the evolution
 and mutation of Docker images to run WebLogic in Kubernetes.  There are several
-approaches and techniques available, and the choice of which to use depends very 
-much on your particular requirements.  We will start with a review of the "problem 
-space," and then talk about the considerations that would lead us to choose various 
-approaches.  We will provide details about several approaches to implementing 
+approaches and techniques available, and the choice of which to use depends very
+much on your particular requirements.  We will start with a review of the "problem
+space," and then talk about the considerations that would lead us to choose various
+approaches.  We will provide details about several approaches to implementing
 CI/CD and links to examples.
 
-### Review of the problem space 
+### Review of the problem space
 
-Kubernetes makes a fundamental assumption that Docker images are immutable, 
-that they contain no state, and that updating them is as simple as throwing 
-away a pod/container and replacing it with a new one that uses a newer version 
-of the Docker image.  These assumptions work very well for microservices 
-applications, but for more traditional workloads, we need to do some extra 
-thinking and some extra work to get the behavior we want. 
+Kubernetes makes a fundamental assumption that Docker images are immutable,
+that they contain no state, and that updating them is as simple as throwing
+away a pod/container and replacing it with a new one that uses a newer version
+of the Docker image.  These assumptions work very well for microservices
+applications, but for more traditional workloads, we need to do some extra
+thinking and some extra work to get the behavior we want.
 
-CI/CD is an area where the standard assumptions don't always suit.  In the 
-microservices architecture, you typically minimize dependencies and build 
-images from scratch with all of the dependencies in them.  You also typically 
-keep all of the configuration outside the image, for example in Kubernetes config 
-maps or secrets, and all of the state outside of the image too.  This makes 
-it very easy to update running pods with a new image. 
+CI/CD is an area where the standard assumptions aren't always suitable.  In the
+microservices architecture, you typically minimize dependencies and build
+images from scratch with all of the dependencies in them.  You also typically
+keep all of the configuration outside of the image, for example, in Kubernetes config
+maps or secrets, and all of the state outside of the image too.  This makes
+it very easy to update running pods with a new image.
 
-Let's consider how a WebLogic image is different.  There will of course be a 
-base layer with the operating system; let's assume it is 
-[Oracle Linux "slim"](https://hub.docker.com/_/oraclelinux/).  Then you need 
-a JDK and this is very commonly in another layer.  Many people will use 
-official supported JDK images from the Docker Store, like the 
-[Server JRE image](https://hub.docker.com/_/oracle-serverjre-8), for example.  On 
-top of this, you need the WebLogic Server binaries (the "Oracle Home").  On top 
-of that, you may wish to have some patches or updates installed.  And then 
+Let's consider how a WebLogic image is different.  There will, of course, be a
+base layer with the operating system; let's assume it is
+[Oracle Linux "slim"](https://hub.docker.com/_/oraclelinux/).  Then you need
+a JDK and this is very commonly in another layer.  Many people will use
+the officially supported JDK images from the Docker Store, like the
+[Server JRE image](https://hub.docker.com/_/oracle-serverjre-8), for example.  On
+top of this, you need the WebLogic Server binaries (the "Oracle Home").  On top
+of that, you may wish to have some patches or updates installed.  And then
 you need your domain, that is the configuration.
 
-There is also other information associated with a domain that needs to live 
-somewhere, for example leasing tables, message and transaction stores, and so 
-on.  We recommend that all of these be kept in a database so that they are 
-separate from the Docker image and so that we get all of the management 
+There is also other information associated with a domain that needs to live
+somewhere, for example leasing tables, message and transaction stores, and so
+on.  We recommend that all of these be kept in a database so that they are
+separate from the Docker image and so that we get all of the management
 capabilities offered by a database server.
 
-There are two common approaches on how to structure these components.  The first, 
-which we call "domain on persistent volume," places the JDK and WebLogic binaries 
-in the Docker image, but the domain is kept on a separate persistent storage 
-outside of the image.  The second approach puts the JDK, WebLogic binaries 
-and the domain all in the Docker image.  Both of these approaches are perfectly 
+There are two common approaches on how to structure these components.  The first,
+which we call "domain on persistent volume," places the JDK and WebLogic binaries
+in the Docker image, but the domain is kept on a separate persistent storage
+outside of the image.  The second approach puts the JDK, WebLogic binaries
+and the domain all in the Docker image.  Both of these approaches are perfectly
 valid (and fully supported) and they have various advantages and disadvantages.
 
 We have listed the [relative advantages of these two approaches here]({{< relref "/userguide/managing-domains/choosing-a-model/_index.md" >}}).
 
-One of the key differences between these approaches is how many Docker images 
-you have, and therefore, how you build and maintain them - your image CI/CD 
-process.  Let's take a short detour and talk about Docker image layering. 
+One of the key differences between these approaches is how many Docker images
+you have, and therefore, how you build and maintain them - your image CI/CD
+process.  Let's take a short detour and talk about Docker image layering.
 
 {{% children style="h4" description="true" %}}

docs-source/content/userguide/cicd/choose-an-approach.md

@@ -1,59 +1,59 @@
 ---
-title: "Choose an Approach"
+title: "Choose an approach"
 date: 2019-04-11T13:36:57-04:00
 draft: false
 weight: 3
 decsription: "How to choose an approach."
 ---
 
-Let's review what we have discussed and talk about when we might want to use 
+Let's review what we have discussed and talk about when we might want to use
 various approaches.  We can start by asking ourselves questions like these:
 
 
 - *Can you make the desired change with a configuration override?*  
-  The WebLogic Kubernetes Operator allows you to inject a number of [configuration 
-  overrides]({{< relref "/userguide/managing-domains/configoverrides/_index.md" >}}) 
-  into your pods at startup time.  This allows you to use the same image for multiple 
-  different configurations.  A good example would be changing the settings for a data 
-  source, for example. You may wish to have a larger connection pool in your production 
-  environment than you do in your development/test environments.  You probably also 
-  want to have different credentials.  You may want to change the service name, and 
+  The WebLogic Kubernetes Operator allows you to inject a number of [configuration
+  overrides]({{< relref "/userguide/managing-domains/configoverrides/_index.md" >}})
+  into your pods at startup time.  This allows you to use the same image for multiple
+  different configurations.  A good example would be changing the settings for a data
+  source, for example. You may wish to have a larger connection pool in your production
+  environment than you do in your development/test environments.  You probably also
+  want to have different credentials.  You may want to change the service name, and
   so on.  All of these kinds of updates can be made with configuration overrides.
-  These are placed in a Kubernetes config map, i.e. they are outside the image, so 
-  they do not require rebuilding the Docker image.  If all of your changes fit into 
-  this category, it is probably much better to just use the configuration overrides 
+  These are placed in a Kubernetes config map, that is, they are outside of the image, so
+  they do not require rebuilding the Docker image.  If all of your changes fit into
+  this category, it is probably much better to just use configuration overrides
   instead of building a new image.  
-- *Are you only changing the WebLogic configuration, i.e. deploying or updating an 
-  application, changing a resource configuration in a way that is not supported by 
-  configuration overrides, etc.?*  
-  If your changes fit into this category, and you have used the "domain-in-image" 
-  approach and the Docker layering model, then you only need to update the top layer 
+- *Are you only changing the WebLogic configuration, for example, deploying or updating an
+  application, changing a resource configuration in a way that is not supported by
+  configuration overrides, and such?*  
+  If your changes fit into this category, and you have used the "domain-in-image"
+  approach and the Docker layering model, then you only need to update the top layer
   of your image.  This is relatively easy compared to making changes in lower layers.
-  You could create a new layer with the changes, or your could rebuild/replace the 
-  existing top layer with a new one.  Which approach you choose depends most on 
+  You could create a new layer with the changes, or your could rebuild/replace the
+  existing top layer with a new one.  Which approach you choose depends mainly on
   whether you need to maintain the same domain encryption keys or not.
 - *Do you need to be able to do a rolling restart?*
-  If you need to do a rolling restart, for example to maintain the availability of 
-  your applications, then you need to make sure the new domain layer has the same 
-  domain encryption keys.  You cannot perform a rolling restart of a domain if the 
-  new members have a different encryption key. 
-- *Do you need to mutate something in a lower layer, i.e. patch WebLogic, the JDK or Linux?*  
-  If you need to make an update in a lower layer, then you will need to rebuild that 
-  layer and all of the layers above it.  This means that you will need to rebuild the 
+  If you need to do a rolling restart, for example to maintain the availability of
+  your applications, then you need to make sure the new domain layer has the same
+  domain encryption keys.  You cannot perform a rolling restart of a domain if the
+  new members have a different encryption key.
+- *Do you need to mutate something in a lower layer, for example, patch WebLogic, the JDK, or Linux?*  
+  If you need to make an update in a lower layer, then you will need to rebuild that
+  layer and all of the layers above it.  This means that you will need to rebuild the
   domain layer.  You will need to determine if you need to keep the same domain encryption keys.
 
 The diagram below summarizes these concerns in a decision tree for the “domain in image” case:
 
 ![Decision model for the "domain in image" approach](/weblogic-kubernetes-operator/images/flowchart.png)
 
-If you are using the "domain on persistent storage" approach, many of these concerns become 
-moot, because you have an effective separation between your domain and the Docker image.
-There is still the possibility that an update in the Docker image could affect your domain, 
-for example, if you updated the JDK, you may need to update some of your domain scripts 
+If you are using the "domain on persistent storage" approach, many of these concerns become
+moot because you have an effective separation between your domain and the Docker image.
+There is still the possibility that an update in the Docker image could affect your domain;
+for example, if you updated the JDK, you may need to update some of your domain scripts
 to reflect the new JDK path.  
 
-However, in this scenario, your environment is much closer to what you are probably used 
-to in a traditional (non-Kubernetes) environment, and you will probably find that all of 
-the practices you used from that pre-Kubernetes environment are directly applicable here 
-too, with just some small modifications.  For example, applying a WebLogic patch would 
-now involve building a new Docker image. 
+However, in this scenario, your environment is much closer to what you are probably used
+to in a traditional (non-Kubernetes) environment, and you will probably find that all of
+the practices you used from that pre-Kubernetes environment are directly applicable here
+too, with just some small modifications.  For example, applying a WebLogic patch would
+now involve building a new Docker image.

docs-source/content/userguide/cicd/how-to-copy-domains.md

@@ -1,39 +1,39 @@
 ---
-title: "How to Copy Domains"
+title: "How to copy domains"
 date: 2019-04-11T13:48:15-04:00
 draft: false
 weight: 5
 description: "How to copy domains."
 ---
 
-The recommended approach to save a copy of a domain is to simply zip (or tar) 
-the domain directory.  However there is a very important caveat with this 
-recommendation - when you unzip the domain, it must go back into exactly 
-the same location (Domain Home) in the (new) file system.  Using this 
+The recommended approach to save a copy of a domain is to simply ZIP (or tar)
+the domain directory.  However, there is a very important caveat with this
+recommendation - when you unzip the domain, it must go back into exactly
+the same location (Domain Home) in the (new) file system.  Using this
 approach will maintain the same domain encryption key.  
 
-The best practice/recommended approach is to create a "primordial domain" 
-(as described above) which does not contain any applications or resources, 
-and to create a zip file of this domain before starting any servers.  
+The best practice/recommended approach is to create a "primordial domain"
+(as described previously) which does not contain any applications or resources,
+and to create a ZIP file of this domain before starting any servers.  
 
 
-> The domain zip must be created before starting servers.  
+> The domain ZIP must be created before starting servers.  
 
-When servers are started the first time they will encrypt various other data. 
-Make sure you create the zip file before starting servers for the first time. 
-The primordial domain zip file should be stored in a safe place where the CI/CD 
-can get it when needed, for example in a secured Artifactory repository (or 
-similar).  Remember, anyone who gets access to this zip file can get access 
+When servers are started the first time, they will encrypt various other data.
+Make sure you create the ZIP file before starting servers for the first time.
+The primordial domain ZIP file should be stored in a safe place where the CI/CD
+can get it when needed, for example in a secured Artifactory repository (or
+something similar).  Remember, anyone who gets access to this ZIP file can get access
 to the domain encryption key, so it needs to be protected appropriately.
 
-Every time you run your CI/CD pipeline to create a new mutation of the domain, 
-it should retrieve and unzip the primordial domain first, and then apply changes 
-to that domain using tools like WDT or WLST (see below). 
+Every time you run your CI/CD pipeline to create a new mutation of the domain,
+it should retrieve and unzip the primordial domain first, and then apply changes
+to that domain using tools like WDT or WLST (see below).
 
 
 > Always use external state.
 
-You should always keep state outside the Docker image.  This means that you should 
-use JDBC stores for leasing tables, JMS and Transaction stores, HTTP sessions, 
-EJB timers, JMS queues, and so on.  This ensures that data will not be lost when 
-a container is destroyed. 
+You should always keep state outside the Docker image.  This means that you should
+use JDBC stores for leasing tables, JMS and Transaction stores, HTTP sessions,
+EJB timers, JMS queues, and so on.  This ensures that data will not be lost when
+a container is destroyed.