From 9883e9e433a4be998494f4fd80fc4062b510cd21 Mon Sep 17 00:00:00 2001 From: Bri <92327786+briwylde08@users.noreply.github.com> Date: Wed, 17 Jan 2024 11:51:45 -0700 Subject: [PATCH] Grammar in Running section --- docs/run-platform-server/running.mdx | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/docs/run-platform-server/running.mdx b/docs/run-platform-server/running.mdx index e8dcf21d9..a63ad9f0f 100644 --- a/docs/run-platform-server/running.mdx +++ b/docs/run-platform-server/running.mdx @@ -9,13 +9,13 @@ Once you have [established the Horizon database](./configuring.mdx#initialize-ho If you chose bare metal installation, run the `stellar-horizon` binary with the [appropriate environment parameters](./configuring.mdx#parameters) set (or `stellar-horizon-cmd serve` if you [installed via the package manager](./installing.mdx#package-manager), which will automatically import your configuration from `/etc/default/stellar-horizon`). -If you chose containerized installation, you don't execute the horizon binary directly, instead the [stellar/stellar-horizon](https://hub.docker.com/r/stellar/stellar-horizon) image has a pre-defined entrypoint that will start running horizon at image startup time. The horizon process will get all configuration settings from container environment variables. +If you chose containerized installation, you don't execute the Horizon binary directly, instead the [stellar/stellar-horizon](https://hub.docker.com/r/stellar/stellar-horizon) image has a pre-defined entrypoint that will start running Horizon at image startup time. The Horizon process will get all configuration settings from container environment variables. -- To run the image as a container on docker daemon of host, use `docker run stellar/stellar-horizon: --env-file `, and specify each horizon configuration flag identified during [Configuring](./configuring.mdx) as separate line in `` of `HORIZON_CONFIG_PARAM=value`. +- To run the image as a container on Docker daemon of host, use `docker run stellar/stellar-horizon: --env-file `, and specify each Horizon configuration flag identified during [Configuring](./configuring.mdx) as a separate line in `` of `HORIZON_CONFIG_PARAM=value`. -- To run on Kubernetes using helm chart, ensure you have followed the [pre-requisite](./installing.mdx#helm-chart-installation) of installing the Helm cli tool and adding the Stellar chart repo to helm client: +- To run on Kubernetes using Helm Chart, ensure you have followed the [pre-requisite](./installing.mdx#helm-chart-installation) of installing the Helm CLI tool and added the Stellar chart repo to Helm client: - The horizon process [requires access to a Postgres 12 database](./configuring.mdx#preparing-the-database). First use the common kubernetes cli tool `kubectl` from your workstation to create a kubernetes secret on the intended namespace of the kubernetes cluster which will hold the horizon database url. + The Horizon process [requires access to a Postgres 12 database](./configuring.mdx#preparing-the-database). First use the common Kubernetes CLI tool `kubectl` from your workstation to create a Kubernetes secret on the intended namespace of the Kubernetes cluster which will hold the Horizon database URL. @@ -32,7 +32,7 @@ If you chose containerized installation, you don't execute the horizon binary di - Now deploy horizon onto the cluster using the helm chart: + Now deploy Horizon onto the cluster using the Helm Chart: @@ -55,12 +55,12 @@ If you chose containerized installation, you don't execute the horizon binary di - This example of helm chart usage, highlights some key aspects: + This example of Helm Chart usage highlights some key aspects: - - uses the `global.network=[testnet|pubnet]` parameter, this automates generation of all the horizon configuration parameters specific to network such as archive urls, captive core config, etc and other parameters as mentioned on [Configuring](./configuring.mdx). - - `global.image.horizon.tag` should be set to one of docker hub tags published on [stellar/stellar-horizon](https://hub.docker.com/r/stellar/stellar-horizon) - - enables all roles on the deployment instance: ingesting, and web api(includes transaction submission). If you choose to have a multi-instance deployment with each instance performing a single role of just web api or ingestion, then you will do two helm installations, one for each role: `my-horizon-ingestion-installation` and `my-horizon-api-installation`. Each of these helm installations will set `ingest.enabled`, `web.enabled`, `ingest.replicaCount`, `web.replicaCount` respectively for the role they are performing. - - to customize further, the best approach is to download the [horizon helm chart values.yaml](https://github.com/stellar/helm-charts/blob/main/charts/horizon/values.yaml), update the settings in your local copy of values.yaml, and pass to helm install, rather than have many individual `--set` on helm install: + - Uses the `global.network=[testnet|pubnet]` parameter, this automates generation of all the Horizon configuration parameters specific to the network such as archive urls, captive core config, and other parameters mentioned in [Configuring](./configuring.mdx). + - `global.image.horizon.tag` should be set to one of the Docker Hub tags published on [stellar/stellar-horizon](https://hub.docker.com/r/stellar/stellar-horizon) + - Enables all roles on the deployment instance: ingesting and web API (includes transaction submission). If you choose to have a multi-instance deployment with each instance performing a single role of just web API or ingestion, then you will do two Helm installations, one for each role: `my-horizon-ingestion-installation` and `my-horizon-api-installation`. Each of these Helm installations will set `ingest.enabled`, `web.enabled`, `ingest.replicaCount`, `web.replicaCount` respectively for the role they are performing. + - To customize further, the best approach is to download the [Horizon Helm Chart values.yaml](https://github.com/stellar/helm-charts/blob/main/charts/horizon/values.yaml), update the settings in your local copy of values.yaml, and pass to Helm install, rather than have many individual `--set` on Helm install: @@ -72,13 +72,13 @@ If you chose containerized installation, you don't execute the horizon binary di - - specific to customizing network configuration parameters, if you want to connect to a network other than presets of `testnet` or `pubnet`, then you won't use `global.network`, instead, use local copy of [values.yaml](https://github.com/stellar/helm-charts/blob/main/charts/horizon/values.yaml) and set `ingest.coreConfig`, and refer to [\_core-config.tpl](https://github.com/stellar/helm-charts/blob/main/charts/horizon/templates/_core-config.tpl) for example of all the key/value pairs to include. + - Specific to customizing network configuration parameters, if you want to connect to a network other than presets of `testnet` or `pubnet`, then you won't use `global.network`, instead, use local copy of [values.yaml](https://github.com/stellar/helm-charts/blob/main/charts/horizon/values.yaml) and set `ingest.coreConfig`, and refer to [\_core-config.tpl](https://github.com/stellar/helm-charts/blob/main/charts/horizon/templates/_core-config.tpl) for example of all the key/value pairs to include. - - minimum resource limits, verify whether `LimitRange` defaults are defined on the target namespace in kubernetes for deployment, if so, ensure that the defaults provide at least minimum resource limits of `6Gi` of memory and `1` cpu. Otherwise, define the limits explicitly on the helm install via the `ingest.resources.limits.*` shown in example, to ensure the deployed pods have adequate resources. + - Minimum resource limits, verify whether `LimitRange` defaults are defined on the target namespace in Kubernetes for deployment, if so, ensure that the defaults provide at least minimum resource limits of `6Gi` of memory and `1` cpu. Otherwise, define the limits explicitly on the helm install via the `ingest.resources.limits.*` shown in example, to ensure the deployed pods have adequate resources.
-Once the horizon process starts it will emit logging to standard out. When run, you should see output similar to: +Once the Horizon process starts, it will emit logging to standard out. When run, you should see output similar to: @@ -112,4 +112,4 @@ Next, you can confirm that Horizon is responding correctly by loading the root r -Refer to [Monitoring](./monitoring.mdx) for more details on horizon runtime logging and metrics available. +Refer to [Monitoring](./monitoring.mdx) for more details on Horizon runtime logging and metrics available.