marcel/argo-cd
1
0
Fork 0
mirror of https://github.com/argoproj/argo-cd.git synced 2026-02-20 01:28:45 +01:00
Code Issues Packages Projects Releases Wiki Activity

docs: fix grammar, typos, and improve clarity in documentation (#26498)

Browse Source 
Signed-off-by: rishabh <rishank69@gmail.com>
Signed-off-by: Rishabh P <32699563+allexistence@users.noreply.github.com>
Co-authored-by: Nitish Kumar <justnitish06@gmail.com>
This commit is contained in:
Rishabh P
2026-02-18 17:13:54 +08:00
committed by GitHub
parent f4852f70af
commit b40a443b6a
3 changed files with 16 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
docs/getting_started.md
View File

@@ -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 <ARGOCD_SERVER>
@@ -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

10
docs/operator-manual/ingress.md
View File

@@ -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

12
docs/operator-manual/installation.md
View File

@@ -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 <CONTEXT> --in-cluster --namespace <YOUR NAMESPACE>`).
with provided credentials (i.e. `argocd cluster add <CONTEXT> --in-cluster --namespace <YOUR 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