diff --git a/docs/getting_started.md b/docs/getting_started.md index eaaff9fc30..c6da77455c 100644 --- a/docs/getting_started.md +++ b/docs/getting_started.md @@ -84,7 +84,7 @@ kubectl get svc argocd-server -n argocd -o=jsonpath='{.status.loadBalancer.ingre Follow the [ingress documentation](operator-manual/ingress.md) on how to configure Argo CD with ingress. ### Port Forwarding -Kubectl port-forwarding can also be used to connect to the API server without exposing the service. +`kubectl port-forward` can also be used to connect to the API server without exposing the service. ```bash kubectl port-forward svc/argocd-server -n argocd 8080:443 @@ -93,7 +93,7 @@ kubectl port-forward svc/argocd-server -n argocd 8080:443 The API server can then be accessed using https://localhost:8080 -## 4. Login Using The CLI +## 4. Log in Using The CLI The initial password for the `admin` account is auto-generated and stored as clear text in the field `password` in a secret named `argocd-initial-admin-secret` @@ -111,7 +111,7 @@ argocd admin initial-password -n argocd > safely be deleted at any time. It will be re-created on demand by Argo CD > if a new admin password must be re-generated. -Using the username `admin` and the password from above, login to Argo CD's IP or hostname: +Using the username `admin` and the password from above, log in to Argo CD's IP or hostname: ```bash argocd login @@ -126,7 +126,7 @@ Change the password using the command: argocd account update-password ``` -## 5. Register A Cluster To Deploy Apps To (Optional) +## 5. Register a Cluster to Deploy Apps To (Optional) This step registers a cluster's credentials to Argo CD, and is only necessary when deploying to an external cluster. When deploying internally (to the same cluster that Argo CD is running in), @@ -161,7 +161,7 @@ An example repository containing a guestbook application is available at ### Creating Apps Via CLI -First we need to set the current namespace to argocd running the following command: +First, set the current namespace to argocd by running the following command: ```bash kubectl config set-context --current --namespace=argocd diff --git a/docs/operator-manual/ingress.md b/docs/operator-manual/ingress.md index 921c242dd0..f93316d720 100644 --- a/docs/operator-manual/ingress.md +++ b/docs/operator-manual/ingress.md @@ -13,7 +13,7 @@ There are several ways how Ingress can be configured. The Ambassador Edge Stack can be used as a Kubernetes ingress controller with [automatic TLS termination](https://www.getambassador.io/docs/latest/topics/running/tls/#host) and routing capabilities for both the CLI and the UI. The API server should be run with TLS disabled. Edit the `argocd-server` deployment to add the `--insecure` flag to the argocd-server command, or simply set `server.insecure: "true"` in the `argocd-cmd-params-cm` ConfigMap [as described here](server-commands/additional-configuration-method.md). Given the `argocd` CLI includes the port number in the request `host` header, 2 Mappings are required. -Note: Disabling TLS in not required if you are using grpc-web +Note: Disabling TLS is not required if you are using grpc-web ### Option 1: Mapping CRD for Host-based Routing ```yaml @@ -881,12 +881,12 @@ http { ## Gateway API Example This section discusses using Gateway API to expose the Argo CD server in various TLS configurations, -accomodating both HTTP and gRPC traffic, possibly using HTTP/2. +accommodating both HTTP and gRPC traffic, possibly using HTTP/2. ### TLS termination at the Gateway Assume the following cluster-wide `Gateway` resource, -that terminates the TLS conection with a certificate stored in a `Secret` in the same namespace: +that terminates the TLS connection with a certificate stored in a `Secret` in the same namespace: ```yaml apiVersion: gateway.networking.k8s.io/v1 @@ -1000,7 +1000,7 @@ server: servicePortHttpsAppProtocol: kubernetes.io/h2c ``` -##### Routing gRPC and HTTP on through the same domain +##### Routing gRPC and HTTP through the same domain Although officially [discouraged](https://gateway-api.sigs.k8s.io/api-types/grpcroute/#cross-serving), attaching the `HTTPRoute` and `GRPCRoute` to the same domain may be supported by some implementations. @@ -1033,7 +1033,7 @@ spec: TLS can also be configured to terminate at the Argo CD API server. -This require attaching a `TLSRoute` to the gateway, +This requires attaching a `TLSRoute` to the gateway, which is part of the [Experimental](https://gateway-api.sigs.k8s.io/reference/1.4/specx/) Gateway API CRDs. ```yaml diff --git a/docs/operator-manual/installation.md b/docs/operator-manual/installation.md index e8b7eb3331..6eb4bef059 100644 --- a/docs/operator-manual/installation.md +++ b/docs/operator-manual/installation.md @@ -1,6 +1,6 @@ # Installation -Argo CD has two type of installations: multi-tenant and core. +Argo CD has two types of installations: multi-tenant and core. ## Multi-Tenant @@ -11,9 +11,9 @@ The end-users can access Argo CD via the API server using the Web UI or `argocd` Two types of installation manifests are provided: -### Non High Availability: +### Non-High Availability: -Not recommended for production use. This type of installation is typically used during evaluation period for demonstrations and testing. +Not recommended for production use. This type of installation is typically used during an evaluation period for demonstrations and testing. * [install.yaml](https://github.com/argoproj/argo-cd/blob/stable/manifests/install.yaml) - Standard Argo CD installation with cluster-admin access. Use this manifest set if you plan to use Argo CD to deploy applications in the same cluster that Argo CD runs @@ -30,7 +30,7 @@ Not recommended for production use. This type of installation is typically used on inputted cluster credentials. An example of using this set of manifests is if you run several Argo CD instances for different teams, where each instance will be deploying applications to external clusters. It will still be possible to deploy to the same cluster (kubernetes.svc.default) - with inputted credentials (i.e. `argocd cluster add --in-cluster --namespace `). + with provided credentials (i.e. `argocd cluster add --in-cluster --namespace `). With the default roles included, you will only be able to deploy Argo CD resources (Applications, ApplicationSets and AppProjects) in the same cluster, as it's only supporting the GitOps mode with real deployments being done to external clusters. @@ -60,13 +60,13 @@ The Argo CD Core installation is primarily used to deploy Argo CD in headless mode. This type of installation is most suitable for cluster administrators who independently use Argo CD and don't need multi-tenancy features. This installation includes fewer components -and is easier to setup. The bundle does not include the API server or +and is easier to set up. The bundle does not include the API server or UI, and installs the lightweight (non-HA) version of each component. Installation manifest is available at [core-install.yaml](https://github.com/argoproj/argo-cd/blob/stable/manifests/core-install.yaml). For more details about Argo CD Core please refer to the [official -documentation](./core.md) +documentation](./core.md). ## Kustomize