mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-25 12:38:05 +00:00
Vincent Fiduccia
+32
-12
@@ -10,18 +10,38 @@ weight: 1
|
||||
|
||||
Rancher is a container management platform built for organizations that deploy containers in production. Rancher makes it easy to run Kubernetes everywhere, meet IT requirements, and empower DevOps teams.
|
||||
|
||||
Run Kubernetes Everywhere. Kubernetes is not only the de-facto container orchestration standard, it is rapidly becoming a form of standard infrastructure available from all cloud and virtualization vendors. Rancher users have the choice of creating Kubernetes clusters with Rancher Kubernetes Engine (RKE), cloud Kubernetes services like GKE, AKS, and EKS. Rancher users can also import and manage their existing Kubernetes clusters created using any Kubernetes distributions or installers.
|
||||
### Run Kubernetes Everywhere
|
||||
|
||||
Meet IT Requirements. Rancher supports centralized authentication for all Kubernetes clusters under management. An employee of a large enterprise, for example, can use his corporate Active Directory credential to gain access to Kubernetes clusters in GKE. IT administrators can setup and enforce access control and security policies across all users, groups, projects, clusters, and clouds. IT administrators have a single-pane-of-glass view of the health and capacity of all their Kubernetes clusters.
|
||||
Kubernetes has become the container orchestration standard. Most cloud and virtualization vendors now offer it as standard infrastructure. Rancher users have the choice of creating Kubernetes clusters with Rancher Kubernetes Engine (RKE) or cloud Kubernetes services, such as GKE, AKS, and EKS. Rancher users can also import and manage their existing Kubernetes clusters created using any Kubernetes distribution or installer.
|
||||
|
||||
### Meet IT requirements
|
||||
|
||||
Rancher supports centralized authentication for all Kubernetes clusters under its control. For example, you can:
|
||||
|
||||
- Use your Active Directory credentials to access Kubernetes clusters hosted by cloud vendors, such as GKE.
|
||||
- Setup and enforce access control and security policies across all users, groups, projects, clusters, and clouds.
|
||||
- View the health and capacity of your Kubernetes clusters from a single-pane-of-glass.
|
||||
|
||||
### Empower DevOps Teams
|
||||
|
||||
Rancher provides an intuitive user interface for DevOps engineers to manage their application workload. The user does not need to have in-depth knowledge of Kubernetes concepts to start using Rancher. Rancher catalog contains a set of useful DevOps tools. Rancher is certified with a wide selection of cloud native ecosystem products, including, for example, security tools, monitoring systems, container registries, and storage and networking drivers.
|
||||
|
||||
Empower DevOps Teams. Rancher provides an intuitive user interface for DevOps engineers to manage their application workload. The user does not need to have in-depth knowledge of Kubernetes concepts to start using Rancher. Rancher catalog contains a set of useful DevOps tools. Rancher is certified with a wide selection of cloud native ecosystem products, including, for example, security tools, monitoring systems, container registries, and storage and networking drivers.
|
||||
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">}}
|
||||
|
||||
|
||||
|
||||
## What's New?
|
||||
|
||||
The previous version, Rancher 1.6, was a container management platform built on docker. Rancher 2.0 build on the success and experience of Rancher 1.6 but bulk of the system has been rearchitected to work on Kubernetes. Rancher 2.0 retains the ease-of-use of Rancher 1.6 UI and catalog. Rancher 2.0 includes many new features such as the built-in CI pipeline, alerts and log aggregation, multi-cluster management, RKE, and integration with cloud Kubernetes services such as GKE, EKS, and AKS.
|
||||
The previous version of Rancher, version 1.6, was a container management platform built on Docker. Rancher 2.0 builds on the success and experience of Rancher 1.6.
|
||||
|
||||
However, for version 2.0, most of Rancher has been redesigned to work on Kubernetes. Rancher 2.0 retains the user-friendly features of version 1.6, such as the UI and catalog. However, 2.0 now includes many new features such as:
|
||||
|
||||
- Built-in CI pipeline
|
||||
- Alerts and log aggregation
|
||||
- Multi-cluster management
|
||||
- Rancher Kubernetes Engine (RKE)
|
||||
- Integration with cloud Kubernetes services, such as GKE, EKS, and AKS.
|
||||
|
||||
# Rancher Architecture
|
||||
|
||||
@@ -51,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">}}
|
||||
|
||||
|
||||
In this section we describe the functionalities of each Rancher server components.
|
||||
|
||||
@@ -75,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
|
||||
|
||||
|
||||
Reference in New Issue
Block a user