paulononato/backstage
1
0
Fork 0
Code Issues Pull Requests Actions 44 Packages Projects Releases Wiki Activity

Standarize code fence and wording tweaks (#3285)

Browse Source
This commit is contained in:
Adam Harvey
2020-11-13 02:51:11 -05:00
committed by GitHub
parent c85714807a
commit a51d475899
4 changed files with 27 additions and 26 deletions
Download Patch File Download Diff File Expand all files Collapse all files
contrib/chart/backstage/README.md
+14 -16
View File
@@ -7,7 +7,7 @@ This folder contains Helm charts that can easily create a Kubernetes deployment
These charts depend on the `nginx-ingress` controller being present in the cluster. If it's not already installed you
can run:
```
```shell
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm install nginx-ingress ingress-nginx/ingress-nginx
```
@@ -16,7 +16,7 @@ helm install nginx-ingress ingress-nginx/ingress-nginx
After choosing a DNS name where backstage will be hosted create a yaml file for your custom configuration.
```
```yaml
appConfig:
app:
baseUrl: https://backstage.mydomain.com
@@ -30,12 +30,11 @@ appConfig:
techdocs:
storageUrl: https://backstage.mydomain.com/api/techdocs/static/docs
requestUrl: https://backstage.mydomain.com/api/techdocs
```
Then use it to run:
```
```shell
git clone https://github.com/backstage/backstage.git
cd contrib/chart/backstage
helm dependency update
@@ -54,7 +53,7 @@ After a few minutes Backstage should be up and running in your cluster under the
Make sure to create the appropriate DNS entry in your infrastructure. To find the public IP address run:
```bash
```shell
$ kubectl get ingress
NAME HOSTS ADDRESS PORTS AGE
backstage-ingress * 123.1.2.3 80 17m
@@ -74,10 +73,10 @@ These charts can install or reuse a `clusterIssuer` to generate certificates for
To enable it you need to provide a valid email address in the chart's values:
```
```yaml
issuer:
email: me@example.com
clusterIssuer: "letsencrypt-prod"
clusterIssuer: 'letsencrypt-prod'
```
By default, the charts use `letsencrypt-staging` so in the above example we instruct helm to use the production issuer
@@ -92,7 +91,7 @@ Configuring a connection to an existing PostgreSQL instance is possible through
First create a yaml file with the configuration you want to override, for example `backstage-prod.yaml`:
```bash
```yaml
postgresql:
enabled: false
@@ -122,12 +121,11 @@ lighthouse:
user: <pg user>
password: <password>
database: lighthouse_audit_service
```
For the CA, create a `configMap` named `<release name>-<chart name>-postgres-ca` with a file called `ca.crt`:
```
```shell
kubectl create configmap my-company-backstage-postgres-ca --from-file=ca.crt"
```
@@ -135,7 +133,7 @@ kubectl create configmap my-company-backstage-postgres-ca --from-file=ca.crt"
Now install the helm chart:
```
```shell
cd contrib/chart/backstage
helm install -f backstage-prod.yaml my-backstage .
```
@@ -144,7 +142,7 @@ helm install -f backstage-prod.yaml my-backstage .
The docker images used for the deployment can be configured through the charts values:
```
```yaml
frontend:
image:
repository: <image-name>
@@ -165,7 +163,7 @@ lighthouse:
Create a docker-registry secret
```
```shell
kubectl create secret docker-registry <docker_registry_secret_name> # args
```
@@ -181,7 +179,7 @@ dockerRegistrySecretName: <docker_registry_secret_name>
To install the charts a specific namespace use `--namespace <ns>`:
```
```shell
helm install -f my_values.yaml --namespace demos backstage .
```
@@ -189,7 +187,7 @@ helm install -f my_values.yaml --namespace demos backstage .
To deploy backstage with the pre-loaded demo data disable `backend.demoData`:
```
```shell
helm install -f my_values.yaml --set backend.demoData=false backstage .
```
@@ -244,7 +242,7 @@ This error happens in the backend when it tries to connect to the configured Pos
To uninstall Backstage simply run:
```
```shell
RELEASE_NAME=<release-name> # use `helm list` to find out the name
helm uninstall ${RELEASE_NAME}
kubectl delete pvc data-${RELEASE_NAME}-postgresql-0
docs/api/utility-apis.md
+4 -4
View File
@@ -11,7 +11,7 @@ possible residing within the plugin itself and its backend APIs. There will
however always be a need for plugins to communicate outside of its boundaries,
both with other plugins and the app itself.
Backstage provides two primary methods for plugins to communication across their
Backstage provides two primary methods for plugins to communicate across their
boundaries in client-side code. The first one being the `createPlugin` API and
the registration hooks passed to the `register` method, and the second one being
Utility APIs. While the `createPlugin` API is focused on the initialization
@@ -195,8 +195,8 @@ interface for the API, and create an `ApiRef` using `createApiRef` exported from
`@backstage/core`. Also be sure to provide at least one implementation of the
API, and to declare a default factory for the API in `createPlugin`.
Custom Utility APIs can be either public or private, which it is up to the
plugin to choose. Private APIs do not expose an external API surface, and it's
Custom Utility APIs can be either public or private, which is up to the plugin
to choose. Private APIs do not expose an external API surface, and it's
therefore possible to make breaking changes to the API without affecting other
users of the plugin. If an API is made public however, it opens up for other
plugins to make use of the API, and it also makes it possible for users for your
@@ -243,7 +243,7 @@ The figure below shows the relationship between
The current method for connecting Utility API providers and consumers is via the
React tree using an `ApiProvider`, which is added to the `AppProvider` of the
`App`. In the future there may potentially be more ways to do this, in ways that
are not tied to react. A design goal of the Utility APIs was to not have them
are not tied to React. A design goal of the Utility APIs was to not have them
directly tied to React.
The indirection provided by Utility APIs also makes it straightforward to test
docs/conf/index.md
+2 -2
View File
@@ -28,8 +28,8 @@ development or small tweaks to be able to reuse deployment artifacts in
different environments.
The configuration is shared between the frontend and backend, meaning that
values that are common between the two only needs to be defined once. Such as
the `backend.baseUrl`.
values that are common between the two only need to be defined once. Such as the
`backend.baseUrl`.
For more details, see [Writing Configuration](./writing.md).
docs/conf/writing.md
+7 -4
View File
@@ -74,7 +74,7 @@ Note that if any config flags are provided, the default `app-config.yaml` files
are NOT loaded. To include them you need to explicitly include them with a flag,
for example:
```
```shell
yarn start --config ../../app-config.yaml --config ../../app-config.staging.yaml
```
@@ -99,8 +99,8 @@ order:
## Secrets
Secrets are supported via a special secret keys that are prefixed with `$`,
which in turn provides a number of different ways to read in secrets. To load a
Secrets are supported via special secret keys that are prefixed with `$`, which
in turn provide a number of different ways to read in secrets. To load a
configuration value as a secret, supply an object with one of the special secret
keys, for example `$env` or `$file`. A full list of supported secret keys can be
found below. For example, the following will read the config key
@@ -155,8 +155,11 @@ used to point to a specific value inside the file. Supported file extensions are
```yaml
$data: ./my-secrets.json#deployment.key
```
# my-secrets.json
Example `my-secrets.json` file:
```json
{
"deployment": {
"key": "my-secret-key"