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 spelling mistakes in many docs files (#9168)

Browse Source 
* docs: fix spelling mistakes in many docs files

Signed-off-by: Jesse Antoszyk <22500761+jcantosz@users.noreply.github.com>

* Update other instance of ksane -> kasane

Signed-off-by: Jesse Antoszyk <22500761+jcantosz@users.noreply.github.com>

* ran make codegen
This commit is contained in:
Jesse Antoszyk
2022-04-22 11:19:16 -04:00
committed by GitHub
parent acfc396ac0
commit 87d7710175
25 changed files with 104 additions and 104 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
SECURITY.md
View File

@@ -6,7 +6,7 @@ Version: **v1.4 (2022-01-23)**
As a deployment tool, Argo CD needs to have production access which makes
security a very important topic. The Argoproj team takes security very
seriously and is continuously working on improving it.
seriously and is continuously working on improving it.
## A word about security scanners
@@ -60,17 +60,17 @@ We will do our best to react quickly on your inquiry, and to coordinate a fix
and disclosure with you. Sometimes, it might take a little longer for us to
react (e.g. out of office conditions), so please bear with us in these cases.
We will publish security advisiories using the
We will publish security advisories using the
[Git Hub Security Advisories](https://github.com/argoproj/argo-cd/security/advisories)
feature to keep our community well informed, and will credit you for your
findings (unless you prefer to stay anonymous, of course).
Please report vulnerabilities by e-mail to the following address:
Please report vulnerabilities by e-mail to the following address:
* cncf-argo-security@lists.cncf.io
## Securing your Argo CD Instance
See the [operator manual security page](docs/operator-manual/security.md) for
additional information about Argo CD's security features and how to make your
See the [operator manual security page](docs/operator-manual/security.md) for
additional information about Argo CD's security features and how to make your
Argo CD production ready.

2
cmd/argocd/commands/admin/app.go
View File

@@ -86,7 +86,7 @@ func NewGenAppSpecCommand() *cobra.Command {
argocd admin app generate-spec kustomize-guestbook --repo https://github.com/argoproj/argocd-example-apps.git --path kustomize-guestbook --dest-namespace default --dest-server https://kubernetes.default.svc --kustomize-image gcr.io/heptio-images/ks-guestbook-demo:0.1
# Generate declarative config for a app using a custom tool:
argocd admin app generate-spec ksane --repo https://github.com/argoproj/argocd-example-apps.git --path plugins/kasane --dest-namespace default --dest-server https://kubernetes.default.svc --config-management-plugin kasane
argocd admin app generate-spec kasane --repo https://github.com/argoproj/argocd-example-apps.git --path plugins/kasane --dest-namespace default --dest-server https://kubernetes.default.svc --config-management-plugin kasane
`,
Run: func(c *cobra.Command, args []string) {
apps, err := cmdutil.ConstructApps(fileURL, appName, labels, annotations, args, appOpts, c.Flags())

2
cmd/argocd/commands/app.go
View File

@@ -137,7 +137,7 @@ func NewApplicationCreateCommand(clientOpts *argocdclient.ClientOptions) *cobra.
argocd app create kustomize-guestbook --repo https://github.com/argoproj/argocd-example-apps.git --path kustomize-guestbook --dest-namespace default --dest-server https://kubernetes.default.svc --kustomize-image gcr.io/heptio-images/ks-guestbook-demo:0.1
# Create a app using a custom tool:
argocd app create ksane --repo https://github.com/argoproj/argocd-example-apps.git --path plugins/kasane --dest-namespace default --dest-server https://kubernetes.default.svc --config-management-plugin kasane
argocd app create kasane --repo https://github.com/argoproj/argocd-example-apps.git --path plugins/kasane --dest-namespace default --dest-server https://kubernetes.default.svc --config-management-plugin kasane
`,
Run: func(c *cobra.Command, args []string) {
argocdClient := headless.NewClientOrDie(clientOpts, c)

12
docs/developer-guide/code-contributions.md
View File

@@ -4,7 +4,7 @@
The Argo CD project continuously grows, both in terms of features and community size. It gets adopted by more and more organisations which entrust Argo CD to handle their critical production workloads. Thus, we need to take great care with any changes that affect compatibility, performance, scalability, stability and security of Argo CD. For this reason, every new feature or larger enhancement must be properly designed and discussed before it gets accepted into the code base.
We do welcome and encourage everyone to participate in the Argo CD project, but please understand that we can't accept each and every contribution from the community, for various reasons.
We do welcome and encourage everyone to participate in the Argo CD project, but please understand that we can't accept each and every contribution from the community, for various reasons.
If you want to submit code for a great new feature or enhancement, we kindly ask you to take a look at the
enhancement process outlined below before you start to write code or submit a PR. This will ensure that your idea is well aligned with the project's strategy and technical requirements, and it will help greatly in getting your code merged into our code base.
@@ -39,7 +39,7 @@ If you want a quick start contributing to Argo CD, take a look at issues that ar
or
[good first issue](https://github.com/argoproj/argo-cd/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22).
These are issues that were already triaged and accepted.
These are issues that were already triaged and accepted.
If the issue is already attached to next
[version milestone](https://github.com/argoproj/argo-cd/milestones),
@@ -49,7 +49,7 @@ We encourage our community to pick up issues that are labeled in this way *and*
## Triage process
### Overview
### Overview
Our triage process for enhancements proposals ensures that we take a look at all incoming enhancements to determine whether we will accept code submissions to implement them.
@@ -73,9 +73,9 @@ We aim to triage at least 10 proposals a week. Depending on our available time,
### Accepted proposals
When a proposal is considered _Accepted_, it was decided that this enhancement would be valuable to the community at large and fits into the overall strategic roadmap of the project.
When a proposal is considered _Accepted_, it was decided that this enhancement would be valuable to the community at large and fits into the overall strategic roadmap of the project.
Implementation of the issue may be started, either by the proposal's creator or another community member (including maintainers of the project).
Implementation of the issue may be started, either by the proposal's creator or another community member (including maintainers of the project).
The issue should be refined enough by now to contain any concerns and guidelines to be taken into consideration during implementation.
@@ -95,7 +95,7 @@ Also, issues that we find to require a more formal design document will be moved
## Design documents
For some enhancement proposals (especially those that will change behavior of Argo CD substantially, are attached with some caveats or where upgrade/downgrade paths are not clear), a more formal design document will be required in order to fully discuss and understand the enhancement in the broader community. This requirement is usually determined during triage. If you submitted an enhancement proposal, we may ask you to provide this more formal write down, along with some concerns or topics that need to be adressed.
For some enhancement proposals (especially those that will change behavior of Argo CD substantially, are attached with some caveats or where upgrade/downgrade paths are not clear), a more formal design document will be required in order to fully discuss and understand the enhancement in the broader community. This requirement is usually determined during triage. If you submitted an enhancement proposal, we may ask you to provide this more formal write down, along with some concerns or topics that need to be addressed.
Design documents are usually submitted as PR and use [this template](https://github.com/argoproj/argo-cd/blob/master/docs/proposals/001-proposal-template.md) as a guide what kind of information we're looking for. Discussion will take place in the review process. When a design document gets merged, we consider it as approved and code can be written and submitted to implement this specific design.

14
docs/operator-manual/applicationset/Generators-Matrix.md
View File

@@ -1,11 +1,11 @@
# Matrix Generator
The Matrix generator combines the parameters generated by two child generators, iterating through every combination of each generator's generated parameters.
The Matrix generator combines the parameters generated by two child generators, iterating through every combination of each generator's generated parameters.
By combining both generators parameters, to produce every possible combination, this allows you to gain the instrinsic properties of both generators. For example, a small subset of the many possible use cases include:
By combining both generators parameters, to produce every possible combination, this allows you to gain the intrinsic properties of both generators. For example, a small subset of the many possible use cases include:
- *SCM Provider Generator + Cluster Generator*: Scanning the repositories of a GitHub organization for application resources, and targeting those resources to all available clusters.
- *Git File Generator + List Generator*: Providing a list of applicatations to deploy via configuration files, with optional configuration options, and deploying them to a fixed list of clusters.
- *Git File Generator + List Generator*: Providing a list of applications to deploy via configuration files, with optional configuration options, and deploying them to a fixed list of clusters.
- *Git Directory Generator + Cluster Decision Resource Generator*: Locate application resources contained within folders of a Git repository, and deploy them to a list of clusters provided via an external custom resource.
- And so on...
@@ -13,7 +13,7 @@ Any set of generators may be used, with the combined values of those generators
## Example: Git Directory generator + Cluster generator
As an example, imagine that we have two clusters:
As an example, imagine that we have two clusters:
- A `staging` cluster (at `https://1.2.3.4`)
- A `production` cluster (at `https://2.4.6.8`)
@@ -66,7 +66,7 @@ First, the Git directory generator will scan the Git repository, discovering dir
```yaml
- path: /examples/git-generator-directory/cluster-addons/argo-workflows
path.basename: argo-workflows
- path: /examples/git-generator-directory/cluster-addons/prometheus-operator
path.basename: prometheus-operator
```
@@ -75,7 +75,7 @@ Next, the Cluster generator scans the [set of clusters defined in Argo CD](Gener
```yaml
- name: staging
server: https://1.2.3.4
- name: production
server: https://2.4.6.8
```
@@ -98,7 +98,7 @@ Finally, the Matrix generator will combine both sets of outputs, and produce:
path.basename: argo-workflows
- name: production
server: https://2.4.6.8
server: https://2.4.6.8
path: /examples/git-generator-directory/cluster-addons/prometheus-operator
path.basename: prometheus-operator
```

6
docs/operator-manual/applicationset/Generators-Pull-Request.md
View File

@@ -48,7 +48,7 @@ spec:
```
* `owner`: Required name of the GitHub organization or user.
* `repo`: Required name of the Github repositry.
* `repo`: Required name of the Github repository.
* `api`: If using GitHub Enterprise, the URL to access it. (Optional)
* `tokenRef`: A `Secret` name and key containing the GitHub access token to use for requests. If not specified, will make anonymous requests which have a lower rate limit and can only see public repositories. (Optional)
* `labels`: Labels is used to filter the PRs that you want to target. (Optional)
@@ -84,7 +84,7 @@ spec:
```
* `owner`: Required name of the Gitea organization or user.
* `repo`: Required name of the Gitea repositry.
* `repo`: Required name of the Gitea repository.
* `api`: The url of the Gitea instance.
* `tokenRef`: A `Secret` name and key containing the Gitea access token to use for requests. If not specified, will make anonymous requests which have a lower rate limit and can only see public repositories. (Optional)
* `insecure`: `Allow for self-signed certificates, primarily for testing.`
@@ -125,7 +125,7 @@ spec:
* `project`: Required name of the Bitbucket project
* `repo`: Required name of the Bitbucket repository.
* `api`: Required URL to access the Bitbucket REST API. For the example above, an API request would be made to `https://mycompany.bitbucket.org/rest/api/1.0/projects/myproject/repos/myrepository/pull-requests`
* `branchMatch`: Optional regexp filter which should match the source branch name. This is an alternative to labels which are not supported by Bitbucket server.
* `branchMatch`: Optional regexp filter which should match the source branch name. This is an alternative to labels which are not supported by Bitbucket server.
If you want to access a private repository, you must also provide the credentials for Basic auth (this is the only auth supported currently):
* `username`: The username to authenticate with. It only needs read access to the relevant repo.

14
docs/operator-manual/applicationset/Generators-SCM-Provider.md
View File

@@ -46,7 +46,7 @@ spec:
# ...
```
* `organization`: Required name of the GitHub organization to scan. If you have multiple orgs, use multiple generators.
* `organization`: Required name of the GitHub organization to scan. If you have multiple organizations, use multiple generators.
* `api`: If using GitHub Enterprise, the URL to access it.
* `allBranches`: By default (false) the template will only be evaluated for the default branch of each repo. If this is true, every branch of every repository will be passed to the filters. If using this flag, you likely want to use a `branchMatch` filter.
* `tokenRef`: A `Secret` name and key containing the GitHub access token to use for requests. If not specified, will make anonymous requests which have a lower rate limit and can only see public repositories.
@@ -57,7 +57,7 @@ Available clone protocols are `ssh` and `https`.
## Gitlab
The Gitlab mode uses the Gitlab API to scan and organization in either gitlab.com or self-hosted gitlab.
The GitLab mode uses the GitLab API to scan and organization in either gitlab.com or self-hosted GitLab.
```yaml
apiVersion: argoproj.io/v1alpha1
@@ -68,7 +68,7 @@ spec:
generators:
- scmProvider:
gitlab:
# The base Gitlab group to scan. You can either use the group id or the full namespaced path.
# The base GitLab group to scan. You can either use the group id or the full namespaced path.
group: "8675309"
# For GitLab Enterprise:
api: https://gitlab.example.com/
@@ -84,11 +84,11 @@ spec:
# ...
```
* `group`: Required name of the base Gitlab group to scan. If you have multiple base groups, use multiple generators.
* `group`: Required name of the base GitLab group to scan. If you have multiple base groups, use multiple generators.
* `api`: If using GitHub Enterprise, the URL to access it.
* `allBranches`: By default (false) the template will only be evaluated for the default branch of each repo. If this is true, every branch of every repository will be passed to the filters. If using this flag, you likely want to use a `branchMatch` filter.
* `includeSubgroups`: By default (false) the controller will only search for repos directly in the base group. If this is true, it will recurse through all the subgroups searching for repos to scan.
* `tokenRef`: A `Secret` name and key containing the Gitlab access token to use for requests. If not specified, will make anonymous requests which have a lower rate limit and can only see public repositories.
* `tokenRef`: A `Secret` name and key containing the GitLab access token to use for requests. If not specified, will make anonymous requests which have a lower rate limit and can only see public repositories.
For label filtering, the repository tags are used.
@@ -121,7 +121,7 @@ spec:
# ...
```
* `owner`: Required name of the Gitea organization to scan. If you have multiple orgs, use multiple generators.
* `owner`: Required name of the Gitea organization to scan. If you have multiple organizations, use multiple generators.
* `api`: The URL of the Gitea instance you are using.
* `allBranches`: By default (false) the template will only be evaluated for the default branch of each repo. If this is true, every branch of every repository will be passed to the filters. If using this flag, you likely want to use a `branchMatch` filter.
* `tokenRef`: A `Secret` name and key containing the Gitea access token to use for requests. If not specified, will make anonymous requests which have a lower rate limit and can only see public repositories.
@@ -143,7 +143,7 @@ metadata:
spec:
generators:
- scmProvider:
bitbucketServer:
bitbucketServer:
project: myproject
# URL of the Bitbucket Server. Required.
api: https://mycompany.bitbucket.org

18
docs/operator-manual/applicationset/Template.md
View File

@@ -25,10 +25,10 @@ Here is the template subfield from a Cluster generator:
The template subfields correspond directly to [the spec of an Argo CD `Application` resource](../../declarative-setup/#applications):
- `project` refers to the [Argo CD Project](../../user-guide/projects.md) in use (`default` may be used here to utilize the default Argo CD Project)
- `source` defines from which Git repostory to extract the desired Application manifests
- `source` defines from which Git repository to extract the desired Application manifests
- **repoURL**: URL of the repository (eg `https://github.com/argoproj/argocd-example-apps.git`)
- **targetRevision**: Revision (tag/branch/commit) of the repository (eg `HEAD`)
- **path**: Path within the repository where Kubernetes manifests (and/or Helm, Kustomize, Jsonnet resources) are located
- **path**: Path within the repository where Kubernetes manifests (and/or Helm, Kustomize, Jsonnet resources) are located
- `destination`: Defines which Kubernetes cluster/namespace to deploy to
- **name**: Name of the cluster (within Argo CD) to deploy to
- **server**: API Server URL for the cluster (Example: `https://kubernetes.default.svc`)
@@ -39,14 +39,14 @@ Note:
- Referenced clusters must already be defined in Argo CD, for the ApplicationSet controller to use them
- Only **one** of `name` or `server` may be specified: if both are specified, an error is returned.
The `metadata` field of template may also be used to set an Application `name`, or to add labels or annotations to the Application.
The `metadata` field of template may also be used to set an Application `name`, or to add labels or annotations to the Application.
While the ApplicationSet spec provides a basic form of templating, it is not intended to replace the full-fledged configuration management capabilities of tools such as Kustomize, Helm, or Jsonnet.
### Deploying ApplicationSet resources as part of a Helm chart
ApplicationSet uses the same templating notation as Helm (`{{}}`). If the ApplicationSet templates aren't written as
Helm string literals, Helm will throw an error like `function "cluster" not defined`. To avoid that error, write the
ApplicationSet uses the same templating notation as Helm (`{{}}`). If the ApplicationSet templates aren't written as
Helm string literals, Helm will throw an error like `function "cluster" not defined`. To avoid that error, write the
template as a Helm string literal. For example:
```yaml
@@ -58,12 +58,12 @@ This _only_ applies if you use Helm to deploy your ApplicationSet resources.
## Generator templates
In addition to specifying a template within the `.spec.template` of the `ApplicationSet` resource, templates may also be specified within generators. This is useful for overriding the values of the `spec`-level template.
In addition to specifying a template within the `.spec.template` of the `ApplicationSet` resource, templates may also be specified within generators. This is useful for overriding the values of the `spec`-level template.
The generator's `template` field takes precedence over the `spec`'s template fields:
- If both templates contain the same field, the generator's field value will be used.
- If only one of those templates' fields has a value, that value will be used.
- If both templates contain the same field, the generator's field value will be used.
- If only one of those templates' fields has a value, that value will be used.
Generator templates can thus be thought of as patches against the outer `spec`-level template fields.

10
docs/operator-manual/applicationset/Use-Cases.md
View File

@@ -1,6 +1,6 @@
# Use cases supported by the ApplicationSet controller
With the concept of generators, the ApplicationSet controller provides a powerful set of tools to automate the templating and modification of Argo CD Applications. Generators produce template parameter data from a variety of sources, including Argo CD clusters and Git repositories, supporting and enabling new use cases.
With the concept of generators, the ApplicationSet controller provides a powerful set of tools to automate the templating and modification of Argo CD Applications. Generators produce template parameter data from a variety of sources, including Argo CD clusters and Git repositories, supporting and enabling new use cases.
While these tools may be utilized for whichever purpose is desired, here are some of the specific use cases that the ApplicationSet controller was designed to support.
@@ -8,7 +8,7 @@ While these tools may be utilized for whichever purpose is desired, here are som
An initial design focus of the ApplicationSet controller was to allow an infrastructure team's Kubernetes cluster administrators the ability to automatically create a large, diverse set of Argo CD Applications, across a significant number of clusters, and manage those Applications as a single unit. One example of why this is needed is the *cluster add-on use case*.
In the *cluster add-on use case*, an administrator is responsible for provisioning cluster add-ons to one or more Kubernete clusters: cluster-addons are operators such as the [Prometheus operator](https://github.com/prometheus-operator/prometheus-operator), or controllers such as the [argo-workflows controller](https://argoproj.github.io/argo-workflows/) (part of the [Argo ecosystem](https://argoproj.github.io/)).
In the *cluster add-on use case*, an administrator is responsible for provisioning cluster add-ons to one or more Kubernetes clusters: cluster-addons are operators such as the [Prometheus operator](https://github.com/prometheus-operator/prometheus-operator), or controllers such as the [argo-workflows controller](https://argoproj.github.io/argo-workflows/) (part of the [Argo ecosystem](https://argoproj.github.io/)).
Typically these add-ons are required by the applications of development teams (as tenants of a multi-tenant cluster, for instance, they may wish to provide metrics data to Prometheus or orchestrate workflows via Argo Workflows).
@@ -26,7 +26,7 @@ In this use case, we may use either the List, Cluster, or Git generators of the
- *List generator*: Administrators maintain two `ApplicationSet` resources, one for each application (Workflows and Prometheus), and include the list of clusters they wish to target within the List generator elements of each.
- With this generator, adding/removing clusters requires manually updating the `ApplicationSet` resource's list elements.
- *Cluster generator*: Administrators maintain two `ApplicationSet` resources, one for each application (Workflows and Prometheus), and ensure that all new cluster are defined within Argo CD.
- *Cluster generator*: Administrators maintain two `ApplicationSet` resources, one for each application (Workflows and Prometheus), and ensure that all new cluster are defined within Argo CD.
- Since the Cluster generator automatically detects and targets the clusters defined within Argo CD, [adding/remove a cluster from Argo CD](../../declarative-setup/#clusters) will automatically cause Argo CD Application resources (for each application) to be created by the ApplicationSet controller.
- *Git generator*: The Git generator is the most flexible/powerful of the generators, and thus there are a number of different ways to tackle this use case. Here are a couple:
- Using the Git generator `files` field: A list of clusters is kept as a JSON file within a Git repository. Updates to the JSON file, through Git commits, cause new clusters to be added/removed.
@@ -44,7 +44,7 @@ Manifest changes merged into the Git repository should automatically deploy to t
In this example, the infrastructure team maintains a Git repository containing application manifests for an Argo Workflows controller, and a Prometheus operator. Independent development teams also have added additional services they wish to deploy to the cluster.
Changes made to the Git repository -- for example, updating the version of a deployed artifact -- should automatically cause that update to be applied to the corresponding Kubernetes cluster by Argo CD.
Changes made to the Git repository -- for example, updating the version of a deployed artifact -- should automatically cause that update to be applied to the corresponding Kubernetes cluster by Argo CD.
The Git generator may be used to support this use case:
@@ -66,7 +66,7 @@ While this might sound like an effective solution, a major disadvantage is that
Thus in the self-service use case, administrators desire to only allow some fields of the `Application` spec to be controlled by developers (eg the Git source repository) but not other fields (eg the target namespace, or target cluster, should be restricted).
Fortunately, the ApplicationSet controller presents an alternative solution to this use case: cluster administrators may safely create an `ApplicationSet` resource containing a Git generator that restricts deployment of application resources to fixed values with the `template` field, while allowing customization of 'safe' fields by developers, at will.
Fortunately, the ApplicationSet controller presents an alternative solution to this use case: cluster administrators may safely create an `ApplicationSet` resource containing a Git generator that restricts deployment of application resources to fixed values with the `template` field, while allowing customization of 'safe' fields by developers, at will.
```yaml
kind: ApplicationSet

8
docs/operator-manual/applicationset/index.md
View File

@@ -56,8 +56,8 @@ There are multiple generators currently supported by the ApplicationSet controll
- **List generator**: Generates parameters based on a fixed list of cluster name/URL values, as seen in the example above.
- **Cluster generator**: Rather than a literal list of clusters (as with the list generator), the cluster generator automatically generates cluster parameters based on the clusters that are defined within Argo CD.
- **Git generator**: The Git generator generates parameters based on files or folders that are contained within the Git repository defined within the generator resource.
- Files containing JSON values will be parsed and converted into template parameters.
- **Git generator**: The Git generator generates parameters based on files or folders that are contained within the Git repository defined within the generator resource.
- Files containing JSON values will be parsed and converted into template parameters.
- Individual directory paths within the Git repository may be used as parameter values, as well.
- **Matrix generator**: The Matrix generators combines the generated parameters of two other generators.
@@ -75,7 +75,7 @@ After substitution, this `guestbook` `ApplicationSet` resource is applied to the
4. Finally, the Argo CD controller is notified of these `Application` resources and is responsible for handling them.
With the three different clusters defined in our example -- `engineering-dev`, `engineering-prod`, and `finance-preprod` -- this will produce three new Argo CD `Application` resources: one for each cluster.
With the three different clusters defined in our example -- `engineering-dev`, `engineering-prod`, and `finance-preprod` -- this will produce three new Argo CD `Application` resources: one for each cluster.
Here is an example of one of the `Application` resources that would be created, for the `engineering-dev` cluster at `1.2.3.4`:
```yaml
@@ -98,7 +98,7 @@ The Applications are now also visible from within the Argo CD UI:
![List generator example in Argo CD Web UI](../../assets/applicationset/Introduction/List-Example-In-Argo-CD-Web-UI.png)
The ApplicationSet controller will ensure that any changes, updates, or deletions made to `ApplicationSet` resources are automatically applied to the corresponding `Application`(s).
The ApplicationSet controller will ensure that any changes, updates, or deletions made to `ApplicationSet` resources are automatically applied to the corresponding `Application`(s).
For instance, if a new cluster/URL list entry was added to the List generator, a new Argo CD `Application` resource would be accordingly created for this new cluster. Any edits made to the `guestbook` `ApplicationSet` resource will affect all the Argo CD Applications that were instantiated by that resource, including the new Application.

8
docs/operator-manual/declarative-setup.md
View File

@@ -179,7 +179,7 @@ Each repository must have a `url` field and, depending on whether you connect us
!!!warning
When using [bitnami-labs/sealed-secrets](https://github.com/bitnami-labs/sealed-secrets) the labels will be removed and have to be readded as descibed here: https://github.com/bitnami-labs/sealed-secrets#sealedsecrets-as-templates-for-secrets
Example for HTTPS:
```yaml
@@ -304,7 +304,7 @@ In the above example, every repository accessed via HTTPS whose URL is prefixed
In order for Argo CD to use a credential template for any given repository, the following conditions must be met:
* The repository must either not be configured at all, or if configured, must not contain any credential information (i.e. contain none of `sshPrivateKey`, `username`, `password` )
* The URL configured for a credential template (e.g. `https://github.com/argoproj`) must match as prefix for the repository URL (e.g. `https://github.com/argoproj/argocd-example-apps`).
* The URL configured for a credential template (e.g. `https://github.com/argoproj`) must match as prefix for the repository URL (e.g. `https://github.com/argoproj/argocd-example-apps`).
!!! note
Matching credential template URL prefixes is done on a _best match_ effort, so the longest (best) match will take precedence. The order of definition is not important, as opposed to pre v1.4 configuration.
@@ -600,7 +600,7 @@ Resources can be excluded from discovery and sync so that Argo CD is unaware of
* There are many of a kind of resources that impacts Argo CD's performance.
* Restrict Argo CD's access to certain kinds of resources, e.g. secrets. See [security.md#cluster-rbac](security.md#cluster-rbac).
To configure this, edit the `argcd-cm` config map:
To configure this, edit the `argocd-cm` config map:
```shell
kubectl edit configmap argocd-cm -n argocd
@@ -630,7 +630,7 @@ The `resource.exclusions` node is a list of objects. Each object can have:
If all three match, then the resource is ignored.
In addition to exclusions, you might configure the list of included resources using the `resource.inclusions` setting.
By default, all resource group/kinds are included. The `resource.inclusions` setting allows customizing the list of included group/kinds:
By default, all resource group/kinds are included. The `resource.inclusions` setting allows customizing the list of included group/kinds:
```yaml
apiVersion: v1

8
docs/operator-manual/health.md
View File

@@ -21,8 +21,8 @@ with at least one value for `hostname` or `IP`.
### Argocd App
The health assessement of `argoproj.io/Application` CRD has been removed in argocd 1.8 (see [#3781](https://github.com/argoproj/argo-cd/issues/3781) for more information).
You might need to restore it if you are using app-of-apps pattern and orchestrating syncronization using sync waves. Add the following resource customization in
The health assessment of `argoproj.io/Application` CRD has been removed in argocd 1.8 (see [#3781](https://github.com/argoproj/argo-cd/issues/3781) for more information).
You might need to restore it if you are using app-of-apps pattern and orchestrating synchronization using sync waves. Add the following resource customization in
`argocd-cm` ConfigMap:
```yaml
@@ -86,7 +86,7 @@ data:
end
end
end
hs.status = "Progressing"
hs.message = "Waiting for certificate"
return hs
@@ -102,7 +102,7 @@ The custom health check might return one of the following health statuses:
By default health typically returns `Progressing` status.
NOTE: As a security measure, access to the standard Lua libraries will be disabled by default. Admins can control access by
NOTE: As a security measure, access to the standard Lua libraries will be disabled by default. Admins can control access by
setting `resource.customizations.useOpenLibs.<group_kind>`. In the following example, standard libraries are enabled for health check of `cert-manager.io/Certificate`.
```yaml

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

@@ -234,7 +234,7 @@ metadata:
kubernetes.io/ingress.class: nginx
kubernetes.io/tls-acme: "true"
nginx.ingress.kubernetes.io/ssl-passthrough: "true"
# If you encounter a redirect loop or are getting a 307 response code
# If you encounter a redirect loop or are getting a 307 response code
# then you need to force the nginx ingress to connect to the backend using HTTPS.
#
nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
@@ -246,7 +246,7 @@ spec:
- path: /
pathType: Prefix
backend:
service:
service:
name: argocd-server
port:
name: https
@@ -376,7 +376,7 @@ spec:
```
## AWS Application Load Balancers (ALBs) And Classic ELB (HTTP Mode)
AWS ALBs can be used as an L7 Load Balancer for both UI and gRPC traffic, whereas Classic ELBs and NLBs can be used as L4 Load Balancers for both.
AWS ALBs can be used as an L7 Load Balancer for both UI and gRPC traffic, whereas Classic ELBs and NLBs can be used as L4 Load Balancers for both.
When using an ALB, you'll want to create a second service for argocd-server. This is necessary because we need to tell the ALB to send the GRPC traffic to a different target group then the UI traffic, since the backend protocol is HTTP2 instead of HTTP1.
@@ -402,7 +402,7 @@ spec:
type: NodePort
```
Once we create this service, we can configure the Ingress to conditionally route all `application/grpc` traffic to the new HTTP2 backend, using the `alb.ingress.kubernetes.io/conditions` annotation, as seen below. Note: The value after the . in the condition annotation _must_ be the same name as the service that you want traffic to route to - and will be applied on any path with a matching serviceName.
Once we create this service, we can configure the Ingress to conditionally route all `application/grpc` traffic to the new HTTP2 backend, using the `alb.ingress.kubernetes.io/conditions` annotation, as seen below. Note: The value after the . in the condition annotation _must_ be the same name as the service that you want traffic to route to - and will be applied on any path with a matching serviceName.
```yaml
apiVersion: networking.k8s.io/v1
@@ -410,7 +410,7 @@ Once we create this service, we can configure the Ingress to conditionally route
metadata:
annotations:
alb.ingress.kubernetes.io/backend-protocol: HTTPS
# Use this annotation (which must match a service name) to route traffic to HTTP2 backends.
# Use this annotation (which must match a service name) to route traffic to HTTP2 backends.
alb.ingress.kubernetes.io/conditions.argogrpc: |
[{"field":"http-header","httpHeaderConfig":{"httpHeaderName": "Content-Type", "values":["application/grpc"]}}]
alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}]'
@@ -451,7 +451,7 @@ For this we will need these five objects:
- A secret with your SSL certificate
- An Ingress for GKE
If you need detail for all the options available for these Google integrations, you can check the [Google docs on configuring Ingress features](https://cloud.google.com/kubernetes-engine/docs/how-to/ingress-features)
If you need detail for all the options available for these Google integrations, you can check the [Google docs on configuring Ingress features](https://cloud.google.com/kubernetes-engine/docs/how-to/ingress-features)
### Disable internal TLS
@@ -478,7 +478,7 @@ To:
### Creating a service
Now you need an externally accesible service. This is practically the same as the internal service Argo CD has, but with Google Cloud annotations. Note that this service is annotated to use a [Network Endpoint Group](https://cloud.google.com/load-balancing/docs/negs) (NEG) to allow your load balancer to send traffic directly to your pods without using kube-proxy, so remove the `neg` annotation it that's not what you want.
Now you need an externally accessible service. This is practically the same as the internal service Argo CD has, but with Google Cloud annotations. Note that this service is annotated to use a [Network Endpoint Group](https://cloud.google.com/load-balancing/docs/negs) (NEG) to allow your load balancer to send traffic directly to your pods without using kube-proxy, so remove the `neg` annotation it that's not what you want.
The service:
@@ -543,7 +543,7 @@ spec:
---
!!! note
The next two steps (the certificate secret and the Ingress) are described supposing that you manage the certificate yourself, and you have the certificate and key files for it. In the case that your certificate is Google-managed, fix the next two steps using the [guide to use a Google-managed SSL certificate](https://cloud.google.com/kubernetes-engine/docs/how-to/managed-certs#creating_an_ingress_with_a_google-managed_certificate).
The next two steps (the certificate secret and the Ingress) are described supposing that you manage the certificate yourself, and you have the certificate and key files for it. In the case that your certificate is Google-managed, fix the next two steps using the [guide to use a Google-managed SSL certificate](https://cloud.google.com/kubernetes-engine/docs/how-to/managed-certs#creating_an_ingress_with_a_google-managed_certificate).
---
@@ -554,7 +554,7 @@ We need now to create a secret with the SSL certificate we want in our load bala
```
kubectl -n argocd create secret tls secret-yourdomain-com \
--cert cert-file.crt --key key-file.key
```
```
### Creating an Ingress
@@ -653,7 +653,7 @@ spec:
- --rootpath
- /argo-cd
```
NOTE: The flag `--rootpath` changes both API Server and UI base URL.
NOTE: The flag `--rootpath` changes both API Server and UI base URL.
Example nginx.conf:
```

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

@@ -5,7 +5,7 @@ Argo CD has two type of installations: multi-tenant and core.
## Multi-Tenant
The multi-tenant installation is the most common way to install Argo CD. This type of installation is typically used to service multiple application developer teams
in the organization and maintained by a platform team.
in the organization and maintained by a platform team.
The end-users can access Argo CD via the API server using the Web UI or `argocd` CLI. The `argocd` CLI has to be configured using `argocd login <server-host>` command
(learn more [here](../user-guide/commands/argocd_login.md)).
@@ -48,7 +48,7 @@ High Availability installation is recommended for production use. This bundle in
## Core
The core installation is most suitable for cluster administrators who indepently use Argo CD and don't need multi-tenancy features. This installation
The core 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 UI, and installs the lightweight (non-HA) version of each component.
The end-users need Kubernetes access to manage Argo CD. The `argocd` CLI has to be configured using the following commands:

4
docs/operator-manual/notifications/functions.md
View File

@@ -46,7 +46,7 @@ Transforms given GIT URL into HTTPs format.
<hr>
**`repo.FullNameByRepoURL(url string) string`**
Returns repository URL full name `(<owner>/<repoName>)`. Currently supports only Github, Gitlab and Bitbucket.
Returns repository URL full name `(<owner>/<repoName>)`. Currently supports only Github, GitLab and Bitbucket.
<hr>
**`repo.GetCommitMetadata(sha string) CommitMetadata`**
@@ -55,7 +55,7 @@ Returns commit metadata. The commit must belong to the application source reposi
* `Message string` commit message
* `Author string` - commit author
* `Date time.Time` - commit creation date
* `Date time.Time` - commit creation date
* `Tags []string` - Associated tags
<hr>

6
docs/operator-manual/tls.md
View File

@@ -38,7 +38,7 @@ There are two ways to configure the TLS certificates used by `argocd-server`:
* Setting the `tls.crt` and `tls.key` keys in the `argocd-secret` secret to
hold PEM data of the certificate and the corresponding private key. This
method is considered deprecated, and only exists for purposes of backwards
compatiblity. Changing `argocd-secret` should not be used to override the
compatibility. Changing `argocd-secret` should not be used to override the
TLS certificate anymore.
Argo CD decides which TLS certificate to use for the endpoint of
@@ -47,7 +47,7 @@ Argo CD decides which TLS certificate to use for the endpoint of
* If the `argocd-server-tls` secret exists and contains a valid key pair in the
`tls.crt` and `tls.key` keys, this will be used for the certificate of the
endpoint of `argocd-server`.
* Otherwise, if the `argocd-secret` secret contains a valid key pair in the
* Otherwise, if the `argocd-secret` secret contains a valid key pair in the
`tls.crt` and `tls.key` keys, this will be used as certificate for the
endpoint of `argocd-server`.
* If no `tls.crt` and `tls.key` keys are found in neither of the two mentioned
@@ -114,7 +114,7 @@ on how your workloads connect to the repository server.
Both `argocd-server` and `argocd-application-controller` communicate with the
`argocd-repo-server` using a gRPC API over TLS. By default,
`argocd-repo-server` generates a non-persistant, self signed certificate
`argocd-repo-server` generates a non-persistent, self signed certificate
to use for its gRPC endpoint on startup. Because the `argocd-repo-server` has
no means to connect to the K8s control plane API, this certificate is not
being available to outside consumers for verification. Both, the

6
docs/operator-manual/webhook.md
View File

@@ -66,16 +66,16 @@ data:
stringData:
# github webhook secret
webhook.github.secret: shhhh! it's a github secret
webhook.github.secret: shhhh! it's a GitHub secret
# gitlab webhook secret
webhook.gitlab.secret: shhhh! it's a gitlab secret
webhook.gitlab.secret: shhhh! it's a GitLab secret
# bitbucket webhook secret
webhook.bitbucket.uuid: your-bitbucket-uuid
# bitbucket server webhook secret
webhook.bitbucketserver.secret: shhhh! it's a bitbucket server secret
webhook.bitbucketserver.secret: shhhh! it's a Bitbucket server secret
# gogs server webhook secret
webhook.gogs.secret: shhhh! it's a gogs server secret

8
docs/proposals/001-proposal-template.md
View File

@@ -58,10 +58,10 @@ This is where we get down to details of what the proposal is about.
Add a list of detailed use cases this enhancement intends to take care of.
#### Use case 1:
#### Use case 1:
As a user, I would like to understand the drift. (This is an example)
#### Use case 2:
#### Use case 2:
As a user, I would like to take an action on the deviation/drift. (This is an example)
### Implementation Details/Notes/Constraints [optional]
@@ -77,11 +77,11 @@ You may have a work-in-progress Pull Request to demonstrate the functioning of t
### Security Considerations
* How does this proposal impact the security aspects of Argo CD workloads ?
* Are there any unresolved follow-ups that need to be done to make the enhancement more robust ?
* Are there any unresolved follow-ups that need to be done to make the enhancement more robust ?
### Risks and Mitigations
What are the risks of this proposal and how do we mitigate. Think broadly.
What are the risks of this proposal and how do we mitigate. Think broadly.
For example, consider
both security and how this will impact the larger Kubernetes ecosystem.

20
docs/proposals/multiple-sources-for-applications.md
View File

@@ -21,12 +21,12 @@ last-updated: 2022-04-01
Support more than one source for creating an Application.
Related Issues:
Related Issues:
* [Proposal: Support multiple sources for an application](https://github.com/argoproj/argo-cd/issues/677)
* [Helm chart + values from Git](https://github.com/argoproj/argo-cd/issues/2789)
## Open Questions
* Adding external sources to the Application reource would add additional latencies for creation/reconcilation process. Should we add it to the doc in Risks?
* Adding external sources to the Application resource would add additional latencies for creation/reconciliation process. Should we add it to the doc in Risks?
## Summary
@@ -64,13 +64,13 @@ The UI should allow users to add multiple sources while creating the application
The cli would need to support adding a list of resources instead of just one while creating the application. `values` field should allow referencing value files from other sources. We would need a separate proposal for changes to cli.
### Non-goals
*
*
## Proposal
### Add new `sources` field in Application Spec
The proposal is to add a new field `sources` which would allow users to input list of `ApplicationSource`s. We would mark field `source` as deprecated and would ignore the details under `source` with details under `sources` field.
The proposal is to add a new field `sources` which would allow users to input list of `ApplicationSource`s. We would mark field `source` as deprecated and would ignore the details under `source` with details under `sources` field.
Below example shows how the yaml would look like for `source` and `sources` field. We would ignore the `source` field and apply the resources mentioned under `sources` field.
@@ -174,12 +174,12 @@ In scenarios, where you have same resource mentioned multiple times in the appli
Add a list of detailed use cases this enhancement intends to take care of.
#### Use case 1:
#### Use case 1:
As a user, I have an Application that uses the [elasticsearch](https://github.com/helm/charts/tree/master/incubator/elasticsearch) helm chart as source. Today, user needs to create a separate Application to configure the [elasticsearch-exporter](https://github.com/helm/charts/tree/master/stable/elasticsearch-exporter
) to expose Prometheus metrics.
https://github.com/argoproj/argo-cd/issues/677
#### Use case 2:
#### Use case 2:
As per one of the [comment]((https://github.com/argoproj/argo-cd/issues/2789#issuecomment-562495307)) on the issue [Helm chart + values files from Git](https://github.com/argoproj/argo-cd/issues/2789):
```
We have a Helm Chart which is used in 30+ Services and each of them is customized for 3 possible environments.
@@ -191,7 +191,7 @@ Modifying the Application definition is not an option since the whole goal is to
#### Attach multiple sources to the Application
To allow multiple sources to the Application, we would add a new field `sources` which would allow users to input list of `ApplicationSource`s. As part of this update and to support backward compatibilty, we would mark field `source` as deprecated and remove it in later revisions.
To allow multiple sources to the Application, we would add a new field `sources` which would allow users to input list of `ApplicationSource`s. As part of this update and to support backward compatibility, we would mark field `source` as deprecated and remove it in later revisions.
To avoid complexity on the deciding the list of sources, if both `source` and `sources` fields are specified, we would override the source under `source` field with all the sources under `sources` field.
@@ -206,7 +206,7 @@ Argo CD benefits from the assumption of a single repo per application to detect
As we would have multiple sources as part of the same Application, we would need to track updates to each source and reconcile the Application for each source. When one of the sources change, we would need to ensure that target revisions of other sources are up-to-date, e.g. force a simple refresh to see if target revision of the source (e.g. HEAD), still points to revisionX for example.
#### Updates to UI
Today, we allow users to add only one source in the UI. We would need to update the UI to add multiple sources and configure specific
Today, we allow users to add only one source in the UI. We would need to update the UI to add multiple sources and configure specific
#### Updates to cli
@@ -222,7 +222,7 @@ Good unit- and end-to-end tests need to be in place for this functionality to en
#### Uncontrolled number of sources added to Application
The users might add a huge number of external sources to the Application, with a potential performance impact on the Argo CD creation/reconcilation processes. This would apply even for the external value files for Helm projects.
The users might add a huge number of external sources to the Application, with a potential performance impact on the Argo CD creation/reconciliation processes. This would apply even for the external value files for Helm projects.
A possible mitigation to this would be to enforce the number of external sources allowed per Application.
@@ -237,7 +237,7 @@ A possible solution would be to check for the source repository to be whiteliste
Upgrading to a version implementing this proposal should be frictionless and wouldn't require administrators to perform any changes in the configuration to keep the current behaviour. Application created without the new field `.spec.sources` being set will keep their behaviour, since they will allow Application resources to be created the same way they are today.
Downgrading would not be easily possible once users start to make use of the feature and create Applications with the new field `.spec.sources` being set. The Application would no longer be able to recognize the resources and will fail the reconcilation/creation step.
Downgrading would not be easily possible once users start to make use of the feature and create Applications with the new field `.spec.sources` being set. The Application would no longer be able to recognize the resources and will fail the reconciliation/creation step.
## Drawbacks

12
docs/user-guide/app_deletion.md
View File

@@ -1,6 +1,6 @@
# App Deletion
Apps can be deleted with or without a cascade option. A **cascade delete**, deletes both the app and its resources, rather than only the app.
Apps can be deleted with or without a cascade option. A **cascade delete**, deletes both the app and its resources, rather than only the app.
## Deletion Using `argocd`
@@ -28,18 +28,18 @@ To perform a non-cascade delete:
```bash
kubectl delete app APPNAME
```
```
To perform a cascade delete set the finalizer, e.g. using `kubctl patch`:
To perform a cascade delete set the finalizer, e.g. using `kubectl patch`:
```bash
kubectl patch app APPNAME -p '{"metadata": {"finalizers": ["resources-finalizer.argocd.argoproj.io"]}}' --type merge
kubectl delete app APPNAME
kubectl delete app APPNAME
```
# About The Deletion Finalizer
For the technical amongst you, the Argo CD application controller watches for this finalizer:
For the technical amongst you, the Argo CD application controller watches for this finalizer:
```yaml
metadata:
@@ -49,4 +49,4 @@ metadata:
Argo CD's app controller watches for this and will then delete both the app and its resources.
When you invoke `argocd app delete` with `--cascade`, the finalizer is added automatically.
When you invoke `argocd app delete` with `--cascade`, the finalizer is added automatically.

2
docs/user-guide/commands/argocd_admin_app_generate-spec.md
View File

@@ -26,7 +26,7 @@ argocd admin app generate-spec APPNAME [flags]
argocd admin app generate-spec kustomize-guestbook --repo https://github.com/argoproj/argocd-example-apps.git --path kustomize-guestbook --dest-namespace default --dest-server https://kubernetes.default.svc --kustomize-image gcr.io/heptio-images/ks-guestbook-demo:0.1
# Generate declarative config for a app using a custom tool:
argocd admin app generate-spec ksane --repo https://github.com/argoproj/argocd-example-apps.git --path plugins/kasane --dest-namespace default --dest-server https://kubernetes.default.svc --config-management-plugin kasane
argocd admin app generate-spec kasane --repo https://github.com/argoproj/argocd-example-apps.git --path plugins/kasane --dest-namespace default --dest-server https://kubernetes.default.svc --config-management-plugin kasane
```

2
docs/user-guide/commands/argocd_app_create.md
View File

@@ -26,7 +26,7 @@ argocd app create APPNAME [flags]
argocd app create kustomize-guestbook --repo https://github.com/argoproj/argocd-example-apps.git --path kustomize-guestbook --dest-namespace default --dest-server https://kubernetes.default.svc --kustomize-image gcr.io/heptio-images/ks-guestbook-demo:0.1
# Create a app using a custom tool:
argocd app create ksane --repo https://github.com/argoproj/argocd-example-apps.git --path plugins/kasane --dest-namespace default --dest-server https://kubernetes.default.svc --config-management-plugin kasane
argocd app create kasane --repo https://github.com/argoproj/argocd-example-apps.git --path plugins/kasane --dest-namespace default --dest-server https://kubernetes.default.svc --config-management-plugin kasane
```

2
docs/user-guide/kustomize.md
View File

@@ -78,7 +78,7 @@ spec:
Additionally, the application kustomize version can be configured using the Parameters tab of the Application Details page, or using the following CLI command:
```
argocd app set <appyName> --kustomize-version v3.5.4
argocd app set <appName> --kustomize-version v3.5.4
```

2
docs/user-guide/resource_tracking.md
View File

@@ -22,7 +22,7 @@ There are however several limitations:
* Labels are truncated to 63 characters. Depending on the size of the label you might want to store a longer name for your application
* Other external tools might write/append to this label and create conflicts with Argo CD. For example several Helm charts and operators also use this label for generated manifests confusing Argo CD about the owner of the application
* You might want to deploy more than one Argo CD instance on the same cluster (with cluster wide privilages) and have an easy way to identify which resource is managed by which instance of Argo CD
* You might want to deploy more than one Argo CD instance on the same cluster (with cluster wide privileges) and have an easy way to identify which resource is managed by which instance of Argo CD
## Additional tracking methods via an annotation

8
test/remote/README.md
View File

@@ -1,6 +1,6 @@
# End-to-end tests against a real cluster
Using the tools in this directory, you can run the End-to-End testsuite against
Using the tools in this directory, you can run the End-to-End test suite against
a real Argo CD workload, that is deployed to a K8s cluster, instead of running
it against a locally running Argo CD.
@@ -131,7 +131,7 @@ In another shell, do a port-forward to the API server's service:
kubectl -n argocd-e2e port-forward svc/argocd-server 443:4443
```
Set Argo CD Server endport:
Set Argo CD Server port:
```shell
export ARGOCD_SERVER=127.0.0.1:4443
@@ -239,13 +239,13 @@ If the tests fail, just re-run above command. All tests that have been previousl
## Troubleshooting
* On message:
```
time="2021-03-23T09:52:53Z" level=fatal msg="`git push origin master -f` failed exit status 128: fatal: unable to access 'http://127.0.0.1:9081/argo-e2e/testdata.git/': Empty reply from server"
```
Your port-forward is probably not setup correctly or broke (e.g. due to pod restart)
* Make sure `argocd-e2e-cluster` pod is running. If you get a CrashLoopBackoff, ensure that you enabled elevated privs as shown above
* Make sure `argocd-e2e-cluster` pod is running. If you get a CrashLoopBackoff, ensure that you enabled elevated privileges as shown above
* Sometimes, you may run into a timeout especially if the cluster is very busy. In this case, you have to restart the tests. See test recording above.