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

[4.x] Adds documentation for JENKINS_UC_INSECURE variable #2

Open
wants to merge 3 commits into
base: using-images-jenkins
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 10 additions & 0 deletions _topic_map.yml
Original file line number Diff line number Diff line change
Expand Up @@ -362,6 +362,16 @@ Topics:
File: using-templates
- Name: Using Ruby on Rails
File: templates-using-ruby-on-rails
- Name: Using images
Dir: using_images
Distros: openshift-enterprise,openshift-origin
Topics:
- Name: Using images overview
File: using-images-overview
- Name: Configuring Jenkins images
File: images-other-jenkins
- Name: Jenkins agent
File: images-other-jenkins-agent
---
Name: Applications
Dir: applications
Expand Down
2 changes: 1 addition & 1 deletion modules/builds-build-custom-builder-image.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -29,5 +29,5 @@ $ oc start-build custom-builder-image --from-dir . -F
----
+
After the build completes, your new custom builder image will be
available in your project in an imagestream tag named
available in your project in an imagestreamtag named
`custom-builder-image:latest`.
4 changes: 2 additions & 2 deletions modules/builds-image-source.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@

You can add additional files to the build process with images. Input images are
referenced in the same way the `From` and `To` image targets are defined. This
means both container images and imagestream tags can be referenced. In
means both container images and imagestreamtags can be referenced. In
conjunction with the image, you must provide one or more path pairs to indicate
the path of the files or directories to copy the image and the destination to
place them in the build context.
Expand Down Expand Up @@ -67,6 +67,6 @@ endif::[]

* Custom Strategy
ifndef::openshift-online[]
* ImageStream Tags
* ImageStreamTags
endif::[]
/////
2 changes: 1 addition & 1 deletion modules/builds-using-image-change-triggers.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -15,7 +15,7 @@ latest RHEL base image.
====
Imagestreams that point to container images in
link:http://docs.docker.com/v1.7/reference/api/hub_registry_spec/#docker-registry-1-0[v1
container registries] only trigger a build once when the imagestream tag
container registries] only trigger a build once when the imagestreamtag
becomes available and not on subsequent image updates. This is due to the lack
of uniquely identifiable images in v1 container registries.
====
Expand Down
2 changes: 1 addition & 1 deletion modules/deployments-triggers.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -41,7 +41,7 @@ triggers:
=== ImageChange deployment triggers

The `ImageChange` trigger results in a new ReplicationController whenever the
content of an imagestream tag changes (when a new version of the image is
content of an imagestreamtag changes (when a new version of the image is
pushed).

.ImageChange deployment trigger
Expand Down
2 changes: 1 addition & 1 deletion modules/images-getting-info-about-imagestreams.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -38,7 +38,7 @@ Tags: 1
About a minute ago
----

* Get all the information available about particular imagestream tag:
* Get all the information available about particular imagestreamtag:
+
----
$ oc describe istag/<image-stream>:<tag-name>
Expand Down
6 changes: 3 additions & 3 deletions modules/images-imagestream-configure.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -46,6 +46,6 @@ status:

<1> The name of the imagestream.
<2> Docker repository path where new images can be pushed to add/update them in this imagestream.
<3> The SHA identifier that this imagestream tag currently references. Resources that reference this imagestream tag use this identifier.
<4> The SHA identifier that this imagestream tag previously referenced. Can be used to rollback to an older image.
<5> The imagestream tag name.
<3> The SHA identifier that this imagestreamtag currently references. Resources that reference this imagestreamtag use this identifier.
<4> The SHA identifier that this imagestreamtag previously referenced. Can be used to rollback to an older image.
<5> The imagestreamtag name.
2 changes: 1 addition & 1 deletion modules/images-imagestream-import.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@
// * assembly/openshift_images

[id="images-imagestreams-import_{context}"]
= Configuring periodic importing of imagestream tags
= Configuring periodic importing of imagestreamtags

When working with an external container image registry, to periodically
re-import an image, for example to get latest security updates, you can use the
Expand Down
2 changes: 1 addition & 1 deletion modules/images-imagestream-remove-tag.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@
// * assembly/openshift_images

[id="images-imagestreams-remove-tag_{context}"]
= Removing imagestream tags
= Removing imagestreamtags

You can remove old tags from an imagestream.

Expand Down
4 changes: 2 additions & 2 deletions modules/images-imagestream-tag.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@
// * assembly/openshift_images

[id="images-imagestream-tag_{context}"]
== Imagestream tags
== Imagestreamtags

An imagestream tag is a named pointer to an image in an imagestream. An image
An imagestreamtag is a named pointer to an image in an imagestream. An image
stream tag is similar to a container image tag.
2 changes: 1 addition & 1 deletion modules/images-imagestream-trigger.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@
[id="image-stream-trigger_{context}"]
= Imagestream triggers

An imagestream trigger causes a specific action when an imagestream tag
An imagestream trigger causes a specific action when an imagestreamtag
changes. For example, importing can cause the value of the tag to change, which
causes a trigger to fire when there are Deployments, Builds, or other resources
listening for those.
2 changes: 1 addition & 1 deletion modules/images-imagestream-update-tag.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@
// * assembly/openshift_images

[id="images-imagestreams-update-tag_{context}"]
= Updating imagestream tags
= Updating imagestreamtags

You can update a tag to reflect another tag in an imagestream.

Expand Down
10 changes: 5 additions & 5 deletions modules/images-imagestream-use.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -20,7 +20,7 @@ For example, if a Deployment is using a certain image and a new version of that
image is created, a Deployment could be automatically performed to pick up the
new version of the image.

However, if the imagestream tag used by the Deployment or Build is not updated,
However, if the imagestreamtag used by the Deployment or Build is not updated,
then even if the container image in the container image registry is updated, the
Build or Deployment will continue using the previous, presumably known good
image.
Expand All @@ -31,10 +31,10 @@ The source images can be stored in any of the following:
* An external registry, for example `registry.redhat.io` or `hub.docker.com`.
* Other imagestreams in the {product-title} cluster.

When you define an object that references an imagestream tag (such as a Build
or Deployment configuration), you point to an imagestream tag, not the Docker
When you define an object that references an imagestreamtag (such as a Build
or Deployment configuration), you point to an imagestreamtag, not the Docker
repository. When you Build or Deploy your application, {product-title} queries
the Docker repository using the imagestream tag to locate the associated ID of
the Docker repository using the imagestreamtag to locate the associated ID of
the image and uses that exact image.

The imagestream metadata is stored in the etcd instance along with other
Expand All @@ -56,7 +56,7 @@ and/or Deployment flow, depending upon the Build or Deployment configuration.
* You can share images using fine-grained access control and quickly distribute
images across your teams.

* If the source image changes, the imagestream tag will still point to a
* If the source image changes, the imagestreamtag will still point to a
known-good version of the image, ensuring that your application will not break
unexpectedly.

Expand Down
57 changes: 57 additions & 0 deletions modules/images-other-jenkins-agent-env-var.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,57 @@
// Module included in the following assemblies:
//
// * images/using_images/images-other-jenkins-agent.adoc

[id="images-other-jenkins-agent-env-var_{context}"]
= Jenkins agent environment variables

Each Jenkins agent container can be configured with the following environment
variables.

[options="header"]
|===
| Variable | Definition

|`JAVA_MAX_HEAP_PARAM`,
`CONTAINER_HEAP_PERCENT` (default: `0.5`, or 50%),
`JENKINS_MAX_HEAP_UPPER_BOUND_MB`
|These values control the maximum heap size of the Jenkins JVM. If
`JAVA_MAX_HEAP_PARAM` is set (example setting: `-Xmx512m`), its value takes
precedence. Otherwise, the maximum heap size is dynamically calculated as
`CONTAINER_HEAP_PERCENT`% (example setting: `0.5`, or 50%) of the container
memory limit, optionally capped at `JENKINS_MAX_HEAP_UPPER_BOUND_MB` MiB
(example setting: `512`).

By default, the maximum heap size of the Jenkins JVM is set to 50% of the
container memory limit with no cap.

|`JAVA_INITIAL_HEAP_PARAM`,
`CONTAINER_INITIAL_PERCENT`
|These values control the initial heap size of the Jenkins JVM. If
`JAVA_INITIAL_HEAP_PARAM` is set (example setting: `-Xms32m`), its value takes
precedence. Otherwise, the initial heap size may be dynamically calculated as
`CONTAINER_INITIAL_PERCENT`% (example setting: `0.1`, or 10%) of the
dynamically calculated maximum heap size.

By default, the initial heap sizing is left to the JVM.

|`CONTAINER_CORE_LIMIT`
|If set, specifies an integer number of cores used for sizing numbers of internal
JVM threads. Example setting: `2`.

|`JAVA_TOOL_OPTIONS` (default: `-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -Dsun.zip.disableMemoryMapping=true`)
|Specifies options to be heeded by all JVMs running in this container. It is not
recommended to override this.

|`JAVA_GC_OPTS` (default: `-XX:+UseParallelGC -XX:MinHeapFreeRatio=5 -XX:MaxHeapFreeRatio=10 -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90`)
|Specifies Jenkins JVM garbage collection parameters. It is not recommended to
override this.

|`JENKINS_JAVA_OVERRIDES`
|Specifies additional options for the Jenkins JVM. These options are appended to
all other options, including the Java options above, and may be used to override
any of them if necessary. Separate each additional option with a space; if any
option contains space characters, escape them with a backslash. Example
settings: `-Dfoo -Dbar`; `-Dfoo=first\ value -Dbar=second\ value`.

|===
31 changes: 31 additions & 0 deletions modules/images-other-jenkins-agent-gradle.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
// Module included in the following assemblies:
//
// * images/using_images/images-other-jenkins-agent.adoc

[id="images-other-jenkins-agent-gradle_{context}"]
= Jenkins agent Gradle builds

Hosting Gradle builds in the Jenkins agent on {product-title} presents
additional complications, because in addition to the Jenkins JNLP agent and
Gradle JVMs, Gradle spawns a third JVM to run tests if these are specified.


The following settings are suggested as a starting point for running Gradle
builds in a memory constrained Jenkins agent on {product-title}. Settings may be
relaxed subsequently as required.

* Ensure the long-lived Gradle daemon is disabled by adding
`org.gradle.daemon=false` to the `gradle.properties` file.
* Disable parallel build execution by ensuring `org.gradle.parallel=true` is not
set in the `gradle.properties` file and that `--parallel` is not set as a command
line argument.
* Set `java { options.fork = false }` in the `build.gradle` file to prevent
Java compilations running out-of-process.
* Disable multiple additional test processes by ensuring
`test { maxParallelForks = 1 }` is set in the `build.gradle` file.
* Override the Gradle JVM memory parameters by the `GRADLE_OPTS`, `JAVA_OPTS` or
`JAVA_TOOL_OPTIONS` environment.
variables.
* Set the maximum heap size and JVM arguments for any Gradle test JVM by
the maxHeapSize and jvmArgs settings in `build.gradle`, or though the
`-Dorg.gradle.jvmargs` command line argument.
37 changes: 37 additions & 0 deletions modules/images-other-jenkins-agent-images.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,37 @@
// Module included in the following assemblies:
//
// * images/using_images/images-other-jenkins-agent.adoc

[id="images-other-jenkins-agent-images_{context}"]
= Jenkins agent images

The {product-title} Jenkins agent images come in two varieties:

*RHEL 7 Based Images*

RHEL 7 Jenkins images are available through the Red Hat Registry:

----
$ docker pull quay.io/openshift3/jenkins-agent-maven-35-rhel7
$ docker pull quay.io/openshift3/jenkins-agent-nodejs-8-rhel7
----

[NOTE]
====
The RHEL 7 Jenkins images exist as an imagestram in {product-title}.
====

*CentOS 7 Based Images*

These images are available on Docker Hub:

----
//$ docker pull openshift/jenkins-slave-base-centos7
//$ docker pull openshift/jenkins-slave-maven-centos7
//$ docker pull openshift/jenkins-slave-nodejs-centos7
$ docker pull openshift/jenkins-agent-maven-35-centos7
$ docker pull openshift/jenkins-agent-nodejs-8-centos7
----

To use these images, you can either access them directly from these registries
or push them into your {product-title} container image registry.
27 changes: 27 additions & 0 deletions modules/images-other-jenkins-agent-memory.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,27 @@
// Module included in the following assemblies:
//
// * images/using_images/images-other-jenkins-agent.adoc

[id="images-other-jenkins-agent-memory_{context}"]
= Jenkins agent memory requirements

A JVM is used in all Jenkins agents to host the Jenkins JNLP agent, as well as
to run any Java applications such as `javac`, Maven, or Gradle.

For memory efficiency, by default the Jenkins image dynamically uses a 32-bit
JVM if running in a container with a memory limit under 2GiB. The
JVM choice applies by default both for the Jenkins JNLP agent as well as for any
other Java processes within the agent container.

By default the Jenkins JNLP agent JVM uses 50% of the container memory limit for
its heap. This value can be modified by the `CONTAINER_HEAP_PERCENT`
environment variable. It can also be capped at an upper limit or overridden
entirely.

By default any other processes executed in the Jenkins agent container, such as
shell scripts or `oc` commands run from pipelines, may not be able to use more
than the remaining 50% memory limit without provoking an OOM kill.

By default, each further JVM process run in a Jenkins agent container will use
up to 25% of the container memory limit for their heap. It may be necessary to
tune this for many build workloads.
41 changes: 41 additions & 0 deletions modules/images-other-jenkins-agent-pod-retention.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,41 @@
// Module included in the following assemblies:
//
// * images/using_images/images-other-jenkins-agent.adoc

[id="images-other-jenkins-agent-pod-retention_{context}"]
= Jenkins agent pod retention

Jenkins agent pods (also known as slave pods) are deleted by default after the
build completes or is aborted. This behavior can be changed by the Kubernetes
plug-in _Pod Retention_ setting. Pod retention can be set for all Jenkins
builds, with overrides for each pod template. The following behaviors are
supported:

* `Always` keeps the build pod regardless of build result.
* `Default` uses the plug-in value (pod template only).
* `Never` always deletes the pod.
* `On Failure` keeps the pod if it fails during the build.

You can override pod retention in the pipeline Jenkinsfile:

[source,groovy]
----
podTemplate(label: "mypod",
cloud: "openshift",
inheritFrom: "maven",
podRetention: onFailure(), <1>
containers: [
...
]) {
node("mypod") {
...
}
}
----
<1> Allowed values for `podRetention` are `never()`, `onFailure()`, `always()`,
and `default()`.

[WARNING]
====
Pods that are kept may continue to run and count against resource quotas.
====
25 changes: 25 additions & 0 deletions modules/images-other-jenkins-auth.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
// Module included in the following assemblies:
//
// * images/using_images/images-other-jenkins.adoc

[id="images-other-jenkins-auth_{context}"]
= Jenkins authentication

Jenkins authentication is used by default if the image is run directly, without
using a template.

The first time Jenkins starts, the configuration is created along with the
administrator user and password. The default user credentials are `admin` and
`password`. Configure the default password by setting the `JENKINS_PASSWORD`
environment variable when using, and only when using, standard Jenkins
authentication.

.Procedure

* Create a new Jenkins application using standard Jenkins authentication:

----
$ oc new-app -e \
JENKINS_PASSWORD=<password> \
openshift/jenkins-2-centos7
----
Loading