Update Runner content

NimRegev · NimRegev · commit 117e1f84bb48 · 2023-09-06T14:07:49.000+03:00
Moved arch to main architecture section; changed title of Runner behind firewall topic
diff --git a/_docs/installation/behind-the-firewall.md b/_docs/installation/behind-the-firewall.md
@@ -1,5 +1,5 @@
 ---
-title: "Runner installation behind firewalls"
+title: "Runner behind firewalls"
 description: "Run Codefresh pipelines in your own secure infrastructure"
 group: installation
 redirect_from:
@@ -8,8 +8,8 @@ redirect_from:
 toc: true
 ---
 
-As described in [installation options]({{site.baseurl}}/docs/installation/installation-options/), Codefresh offers Runner and GitOps options for hybrid installations.
-This articles focuses on the Runner installation option and its advantages.
+As described in [installation options]({{site.baseurl}}/docs/installation/installation-options/), Codefresh offers the Hybrid Runner option for Codefresh pipelines.
+This articles focuses on how the Runner works within infrastructure behind firewalls.
 
 ## Running Codefresh in secure environments
 
@@ -19,7 +19,7 @@ and improvements done in the platform must also be transferred to the customer p
 
 Hybrid Runner installs the Runner within the customer premises, while the UI (and management platform) stays in Codefresh.
 
-Here is the overall architecture:
+Here is a visual representation of the CI/CD flow between the Runner in the customer environment and Codefresh client in the public internet:
 
 {% include image.html
   lightbox="true"
@@ -30,22 +30,22 @@ Here is the overall architecture:
   max-width="100%"
     %}   
 
-The advantages for this scenario are multi-fold. 
+The advantages for this scenario are multi-fold: 
 
-Regarding platform maintenance:
+**Regarding platform maintenance** 
 
  1. Codefresh is responsible for the heavy lifting for platform maintenance, instead of the customer.
  1. Updates to the UI, build engine, integrations etc., happen automatically, without any customer involvement.
  1. Actual builds run in the customer premises under fully controlled conditions.
  1. Codefresh Runner is fully automated. It handles volume claims and build scheduling on its own within the Kubernetes cluster it is placed.
 
-Regarding security of services:
+**Regarding security of services**
 
  1. Pipelines can run in behind-the-firewall clusters with internal services.
  1. Pipelines can use integrations (such as Docker registries) that are private and secure.
  1. Source code does not ever leave the customer premises.
 
-Regarding firewall security:
+**Regarding firewall security**
 
  1. Uni-directional, outgoing communication between the Runner and Codefresh. The Runner polls the platform for jobs. 
  1. Codefresh never connects to the customer network. No ports need to be open in the customer firewall for the runner to work.
@@ -67,16 +67,16 @@ You can easily create pipelines that:
  * Create infrastructure such as machines, load balancers, auto-scaling groups etc.
 
  Any of these pipelines will work out the box without extra configuration. In all cases,
- all data stays witin the private local network and does not exit the firewall.
+ all data stays within the private local network and does not exit the firewall.
 
- >Notice that [long-running compositions]({{site.baseurl}}/docs/pipelines/steps/composition/) (preview test environments) are not yet available via the Codefresh Runner.
+ >**INFO**:  
+ [Long-running compositions]({{site.baseurl}}/docs/pipelines/steps/composition/) (preview test environments) are not yet available via the Codefresh Runner.
 
 
 
 ### Checking out code from a private GIT repository
 
-To check out code from your private Git repository, you need to connect first to Codefresh via  [Git integrations]({{site.baseurl}}/docs/integrations/git-providers/). However, once you define your GIT provider as *on premise* you also
-need to mark it as *behind the firewall* as well:
+To check out code from your private Git repository, you need to connect first to Codefresh via  [Git integrations]({{site.baseurl}}/docs/integrations/git-providers/). However, once you define your GIT provider as *on premise*, you also need to mark it as *behind the firewall* as well:
 
 {% include image.html
   lightbox="true"
diff --git a/_docs/installation/codefresh-runner.md b/_docs/installation/codefresh-runner.md
@@ -11,7 +11,7 @@ toc: true
 
 Install the Codefresh Runner on your Kubernetes cluster to run pipelines and access secure internal services without compromising on-premises security requirements. These pipelines run on your infrastructure, even behind the firewall, and keep code on your Kubernetes cluster secure.
 
-We have transitioned to a Helm-based installation for the Codefresh Runner. All new Runner installations must be installed with Helm. For existing installations, we encourage you to transition to the new Helm installation.
+We have transitioned to a new Helm-based installation for the Codefresh Runner. All new Runner installations must be installed with Helm. For existing installations, we encourage you to transition to the new Helm installation.
 The CLI-based installation is considered legacy and will be deprecated in the coming months. 
 
 
@@ -40,7 +40,7 @@ As the Codefresh Runner is **not** dependent on any special dockershim features,
 To install the Codefresh Runner, follow the [chart installation instructions](https://artifacthub.io/packages/helm/codefresh-runner/cf-runtime#install-chart) in ArtifactHub.
 
 **Existing installations**  
-For existing Runner installations, based on either older Helm installations or CLI-based installations:
+For existing Runner installations, based on either older Helm installations or CLI-based installations:  
 Delete the existing `values` file and reinstall the Codefresh Runner with the new `values` file.
 
 
@@ -182,7 +182,7 @@ After you install the Codefresh Runner, review the [configuration](https://artif
 
 ## Runtime Environment specifications
 
-The following section describes the specfications for the Runtime Environment specification and possible options to modify it.  
+The following section describes the specifications for the Runtime Environment.  
 
 Notice that there are additional and hidden fields that are autogenerated by Codefresh that complete a full runtime spec. You can view and edit these fields only for [Codefresh On-Premises Installation]({{site.baseurl}}/docs/installation/codefresh-on-prem/).
 
@@ -363,8 +363,8 @@ dockerDaemonScheduler:
 ## CLI-based Codefresh Runner installation
 
 >**LEGACY CONTENT**  
-Please be aware that the content in this section is _no longer receiving active updates_.  
-We have transitioned to a [Helm-based installation](https://artifacthub.io/packages/helm/codefresh-runner/cf-runtime){:target="\_blank"} for the Codefresh Runner. As a result, this content will be deprecated in the coming months. 
+Please be aware that the content in this section and subsections is _no longer actively updated_.  
+We have transitioned to a [new Helm-based installation](https://artifacthub.io/packages/helm/codefresh-runner/cf-runtime){:target="\_blank"} for the Codefresh Runner. As a result, this content will be deprecated in the coming months. 
 
 Access to the Codefresh CLI is only needed when installing the Codefresh Runner. After installation, the Runner authenticates on its own using the details provided. You don't need to install the Codefresh CLI on the cluster running Codefresh pipelines.
 
@@ -801,7 +801,7 @@ dockerDaemonScheduler:
 
 Once you have applied the patch, future builds will include the label preventing eviction. 
 
-### Install monitoring component:  only for CLI - each dprecated section should have a reference to the Hel
+### Install monitoring component
 
 If your cluster is located [behind the firewall]({{site.baseurl}}/docs/installation/behind-the-firewall/), you can use the Runner's monitoring component to get valuable information about cluster resources to Codefresh dashboards. For example, to [Kubernetes](https://g.codefresh.io/kubernetes/services/){:target="\_blank"} and [Helm Releases](https://g.codefresh.io/helm/releases/releasesNew/){:target="\_blank"} dashboards.
 
@@ -825,7 +825,7 @@ where:
 * `<CONTEXT>`, `<NAMESPACE>`, '<CLUSTER_NAME>' are the context, namespace, and the name of the cluster to which install the monitoring component.
 * `<TOKEN>`  is the token to authenticate to the cluster. 
 
-### Injecting AWS ARN roles into the cluster: same as above
+### Injecting AWS ARN roles into the cluster
 
 **Step 1** - Make sure the OIDC provider is connected to the cluster
 
diff --git a/_docs/installation/runtime-architecture.md b/_docs/installation/runtime-architecture.md
@@ -31,9 +31,10 @@ The Codefresh Control Plane is the SaaS component in the platform. External to t
 
 ### GitOps Runtime
 The GitOps Runtime is installed on a Kubernetes cluster, and houses the enterprise distribution of the Codefresh Application Proxy and the Argo Project.  
-Depending on the type of GitOps installation, the GitOps Runtime is installed either in the Codefresh platform (Hosted GitOps), or in the customer environment (Hybrid GitOps). Read more in [GitOps Runtime architecture](#gitops-runtime-architecture).
-
+Depending on the type of GitOps installation, the GitOps Runtime is installed either in the Codefresh platform (Hosted GitOps), or in the customer environment (Hybrid GitOps). Read more about it in [GitOps Runtime architecture](#gitops-runtime-architecture).
 
+### Codefresh Runner
+The Codefresh Runner, also known as the Agent, enables running Codefresh pipeline builds in the customer's environment.  It provides a way to run pipeline builds, tests, and deployments within your private network or on-premises environment by making API calls to the Codefresh platform.
 
 ### GitOps Clients
 
@@ -63,9 +64,9 @@ max-width="100%"
 <br>
 
 #### Codefresh Runner
-The Codefresh Runner can be installed on the same cluster as the On-Premises platform or on a remote cluster.  It provides a way to run builds, tests, and deployments within your private network or on-premises environment by making API calls to the Codefresh platform.
+The Codefresh Runner can be installed on the same cluster as the On-Premises platform or on a remote cluster.  It provides a way to run pipeline builds, tests, and deployments within your private network or on-premises environment by making API calls to the Codefresh platform.
 
-Read more about how it works in [Runner installation behind firewalls]({{site.baseurl}}/docs/installation/behind-the-firewall/).
+Read more about how it works in [Runner behind firewalls]({{site.baseurl}}/docs/installation/behind-the-firewall/).
 
 <br>
 
@@ -194,17 +195,54 @@ Each microservice within the Codefresh Pipeline and GitOps modules has its own d
   Stores data for legacy builder and windows nodes.
 
 
-## Codefresh Runner
+## Codefresh Runner architecture
+This section shows a detailed view of the Codefresh Runner architecture, and a description of the components. See [Runner installation behind firewalls]({{site.baseurl}}/docs/installation/behind-the-firewall/).
+
+???
+
+
+The Codefresh Runner includes two main components:
+
+### Runner Agent
+The Codefresh Runner, often referred to as the Agent, is responsible for executing and managing tasks within the Runtime Environment. 
+Main functions include:
+
+Executing and terminating pipeline builds.
+Creating and deleting necessary resources, such as engine and DinD pods, as well as DinD PVCs.
+
+### Runtime Environment
+
+The Runtime Environment is attached to the Codefresh Runner, and includes the following components:
+
+**Volume Provisioner**  
+The Volume Provisioner is the central component that controls all Codefresh services, and performs the following functions:
+Acting as a Persistent Volume (PV) Kubernetes controller 
+Managing DinD Persistent Volume Claim s(PVCs)
+Optimizing Docker caching volumes to enhance cache utilization for Codefresh builds
 
-The most important components are the following:
+<br>
+
+**Volume Cleaners**  
+The Volume Cleaners are responsible for PV management based on the environment setup:
+* LV-Monitor: Installed when local volumes are used to allocate disk space for PVs on the cluster nodes.
+* Dind Volume Cleanup: Installed instead of the LV Monitor when local volumes are not used, to delete PVs according to retention policies. 
 
-**Codefresh VPC:** All internal Codefresh services run in the VPC. Codefresh uses Mongo and PostgreSQL to store user and authentication information.
+<br>
 
-**Pipeline execution environment**:  The Codefresh engine component is responsible for taking pipeline definitions and running them in managed Kubernetes clusters by automatically launching the Docker containers that each pipeline needs for its steps.
+**Cluster Monitor**
+Optional. When installed, provides visibility on cluster resources in Codefresh, through the Kubernetes Services dashboard.
+
+<br>
+
+**App-Proxy**  
+Another optional component, the App-Proxy serves as an extension to the Codefresh platform. Its purpose is to enable remote operations, such as displaying Git repositories for Git providers behind firewalls and creating webhooks, while maintaining security.
+
+
+### Clients
+* API
+Codefresh offers a [public API]({{site.baseurl}}/docs/integrations/codefresh-api/) that is consumed both by the Web user interface and the [Codefresh CLI](https://codefresh-io.github.io/cli/){:target="\_blank"}. The API is also available for any custom integration with external tools or services.
 
-**External actors**. Codefresh offers a [public API]({{site.baseurl}}/docs/integrations/codefresh-api/) that is consumed both by the Web user interface and the <!--should i differentiate between the CI Cli and GitOps CLI -->[Codefresh CLI](https://codefresh-io.github.io/cli/){:target="\_blank"}. The API is also available for any custom integration with external tools or services.
 
-See [Runner installation behind firewalls]({{site.baseurl}}/docs/installation/behind-the-firewall/).
 
 
  
@@ -299,17 +337,18 @@ The Argo Project includes:
 * Argo Workflows as the workflow engine 
 * Argo Events for event-driven workflow automation framework
 
->Codefresh users rely on our platform to deliver software reliably, and predictably without interruption.  
-  To maintain that high standard, we add several weeks of testing and bug fixes to new versions of Argo before making them available within Codefresh.  
-  Typically, new versions of Argo are available within 30 days of release in Argo.
+>**NOTE**:  
+Codefresh users rely on our platform to deliver software reliably, and predictably without interruption.  
+To maintain that high standard, we add several weeks of testing and bug fixes to new versions of Argo before making them available within Codefresh.  
+Typically, new versions of Argo are available within 30 days of release in Argo.
 
 
 
 ### Request Routing Service
 The Request Routing Service is installed on the same cluster as the GitOps Runtime in the customer environment.  
 It receives requests from the the Tunnel Client (tunnel-based) or the ingress controller (ingress-based), and forwards the request URLs to the Application Proxy, and webhooks directly to the Event Sources.  
 
->Important:  
+>**IMPORTANT**:  
   The Request Routing Service is available from Runtime version 0.0.543 and higher.   
   Older Runtime versions are not affected as there is complete backward compatibility, and the ingress controller continues to route incoming requests.
 
