added Bill's pipeline stuff, renamed install topics per Sheng's request

2026-09-24 20:18:18 +00:00 · 2018-05-01 13:30:19 -07:00
parent 4889c1a63d
commit da32b2fde4
7 changed files with 71 additions and 30 deletions
@@ -28,7 +28,8 @@ Rancher provides an intuitive user interface for DevOps engineers to manage thei

 The following figure illustrates the role Rancher plays in IT and DevOps organizations. Each team deploys their applications on the public or private clouds they choose. IT administrators gain visibility and enforce policies across all users, clusters, and clouds.

-{{< figure src="assets/platform.png" title="Rancher Platform">}}
+![placeholder]({{< baseurl >}}/img/rancher/platform.png)
+

 ## What's New?

@@ -70,9 +71,9 @@ We now cover high-level Rancher architecture.

 Majority of Rancher 2.0 software runs on the Rancher server.  Rancher server includes all the software components used to manage the entire Rancher deployment.

-Figure 2 illustrates the high-level architecture of Rancher 2.0. The figure depicts a Rancher server installation that manages two Kubernetes clusters: one Kubernetes cluster created by RKE and another Kubernetes cluster created by GKE.
+The figure below illustrates the high-level architecture of Rancher 2.0. The figure depicts a Rancher server installation that manages two Kubernetes clusters: one Kubernetes cluster created by RKE and another Kubernetes cluster created by GKE.

-{{< figure src="assets/rancher-architecture.png" title="Rancher Architecture">}}
+![placeholder]({{< baseurl >}}/img/rancher/rancher-architecture.png)

 In this section we describe the functionalities of each Rancher server components.

@@ -94,17 +95,17 @@ The cluster controller and cluster agents implement the business logic required

 Cluster agents perform the following activities:

-1.  Manage workload. This includes, for example, creating pods and deployments in each cluster.
+-  Manage workload. This includes, for example, creating pods and deployments in each cluster.

-2.  Applying roles and bindings that are defined in global policies into every cluster.
+-  Applying roles and bindings that are defined in global policies into every cluster.

-3.  Propagate information from cluster to rancher server: events, stats, node info, and health.
+-  Propagate information from cluster to rancher server: events, stats, node info, and health.

 The cluster controller performs the following activities:

-1.  Configures access control policies to clusters and projects.
+-  Configures access control policies to clusters and projects.

-2.  Provisions clusters by invoking the necessary Docker machine drivers and invoking Kubernetes engines like RKE and GKE.
+-  Provisions clusters by invoking the necessary Docker machine drivers and invoking Kubernetes engines like RKE and GKE.

 #### Authentication Proxy

@@ -1,13 +1,17 @@
 ---
-title: CI/CD Pipelines
+title: Pipelines
 weight: 2350
 ---

-# CI/CD Pipelines
+# Pipelines
+
+Pipelines help you automate the software delivery process. You can integrate Rancher with GitHub to create a pipeline.
+
+You can set up your pipeline to run a series of stages and steps to test your code and deploy it.

 <dl>
 	<dt>Pipelines</dt>
-	<dd>Contain a series of stages and steps. Out of the box the pipelines feature supports fan out and in capabilities.</dd>
+	<dd>Contain a series of stages and steps. Out-of-the-box, the pipelines feature supports fan out and in capabilities.</dd>
 	<dt>Stages</dt>
 	<dd>Executed sequentially. The next stage will not execute until all of the steps within the stage execute.</dd>
 	<dt>Steps</dt>
@@ -0,0 +1,9 @@
+---
+title: Air Gap Installation
+weight: 345
+draft: true
+---
+
+# Air Gap Installation
+
+If you want to set up Rancher in a network that's disconnected from the Internet (i.e. an air gap installation), you can do so using a private registry.
@@ -1,10 +1,10 @@
 ---
-title: Install Using Docker
+title: Single Node Install
 weight: 250
 description: For development environments, we recommend installing Rancher by deploying a single Docker container.
 ---

-# Install by Docker
+# Single Node Rancher Server Install

 For development environments, we recommend installing Rancher by deploying a single Docker container. In this installation scenario, you'll install Docker on a single Linux host, and then install Rancher on your host using a single Docker container.

@@ -1,8 +1,8 @@
 ---
-title: Install Using Kubernetes
+title: HA Server Install
 weight: 275
 ---
-# Install Using Kubernetes
+# High Availability Rancher Server Install

 You can deploy Rancher in a high-availability (HA) configuration using the Rancher Kubernetes Engine (RKE). RKE is Rancher's own fast and light-weight Kubernetes installer. Use RKE to set up a new cluster that deploys Rancher as an addon.

@@ -27,11 +27,23 @@ weight: 3700

 6. Select Branch options.

-	Only the branch {BRANCH NAME}: Only events triggered by changes to this branch will be built.
-	Evertyhing but {BRANCH NAME}: Build any branch that triggered an event EXCEPT events from this branch.
-	All branches: Regardless of the branch that triggered the event always build.
+	-	Only the branch {BRANCH NAME}: Only events triggered by changes to this branch will be built.

-7. Click Add button.
+	-	Evertyhing but {BRANCH NAME}: Build any branch that triggered an event EXCEPT events from this branch.
+
+	-	All branches: Regardless of the branch that triggered the event always build.
+
+	>**Note:** If you want one path for master, but another for PRs or development/test/feature branches, create two separate pipelines.
+
+7. Select the build trigger events. By default, builds will only happen by manually clicking build now in Rancher UI.
+
+	- Automatically build this pipeline whenever there is a git commit. (This respects the branch selection above)
+
+	- Automatically build this pipeline whenever there is a new PR.
+
+	- Automatically build the pipeline. (Allows you to configure scheduled builds similar to Cron)
+
+8. Click Add button.

 	By default, Rancher provides a three stage pipeline for you. It consists of a build stage where you would compile, unit test, and scan code. The publish stage has a single step to publish a docker image.

@@ -46,18 +58,18 @@ weight: 3700

 11. Click Save to persist the changes.

-Click the “publish an image’ box under the “Publish” stage.
+12. Click the “publish an image’ box under the “Publish” stage.

+13. Set the location of the Dockerfile. By default it looks in the root of the workspace. Instead, set the build context for building the image relative to the root of the workspace.

-Set the location of the Dockerfile, by default it looks in the root of the workspace.
-Set the build context for building the image relative to the root of the workspace.
+14. Set the image information.

-Set the image information:
-The registry is the remote registry URL. It is defaulted to Docker hub.
-Repository is the <org>/<repo> in the repository.
-Finally select the Tag. You can hard code a tag like ‘latest’ or select from a list of available variables.
+	The registry is the remote registry URL. It is defaulted to Docker hub.
+	Repository is the `<org>/<repo>` in the repository.

-Finally, if this is the first time using this registry, you can add the username/password for pushing the image. You must click save for the registry credentials AND also save for the modal.
+15. Select the Tag. You can hard code a tag like ‘latest’ or select from a list of available variables.
+
+16. If this is the first time using this registry, you can add the username/password for pushing the image. You must click save for the registry credentials AND also save for the modal.



@@ -68,7 +80,7 @@ Finally, if this is the first time using this registry, you can add the username

 2. Provide a name for the stage.

-3. Click save
+3. Click save.


 ## Creating a New Step
@@ -80,13 +92,28 @@ Finally, if this is the first time using this registry, you can add the username
 3. Fill out the form as detailed above


-### Adding a Build Script
+## Environment Variables
+
+For your convenience the following environment variables are available in your build steps:
+
+Variable Name           | Description
+------------------------|------------------------------------------------------------
+CICD_GIT_REPO_NAME      | Repository Name (Stripped of Github Organization)
+CICD_PIPELINE_NAME      | Name of the pipeline
+CICD_GIT_BRANCH         | Git branch of this event
+CICD_TRIGGER_TYPE       | Event that triggered the build
+CICD_PIPELINE_ID        | Rancher ID for the pipeline
+CICD_GIT_URL            | URL of the Git repository
+CICD_EXECUTION_SEQUENCE | Build number of the pipeline
+CICD_EXECUTION_ID       | Combination of {CICD_PIPELINE_ID}-{CICD_EXECUTION_SEQUENCE}
+CICD_GIT_COMMIT         | Git commit ID being executed.
+<!--### Adding a Build Script

 Coming Soon

 ### Publishing an Image

-Coming Soon
+Coming Soon-->

 ## Importing a Pipeline From YAML