Elgato_dark/argo-cd
1
0
Fork 0
mirror of https://github.com/argoproj/argo-cd synced 2026-04-21 17:07:16 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 22

Update CHANGELOG, docs to use stable tag, and tweak getting started guide (#1005)

Browse source
This commit is contained in:
Jesse Suen 2019-01-10 20:56:04 -08:00 committed by GitHub
parent f732e23488
commit bf5cf3256f
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
4 changed files with 117 additions and 108 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

96
CHANGELOG.md
View file

@ -1,58 +1,67 @@
# Changelog
## v0.11.0
## v0.11.0 (2019-01-10)
This is Argo CD's biggest release ever and introduces a completely redesigned controller architecture.
### New Features
#### New application controller architecture
The application controller has a completely redesigned architecture for better scalability, and
improve performance during application reconciliation. This was achieved by maintaining an
in-memory, live state cache of lightweight Kubernetes object metadata. During reconciliation, the
controller no longer performs expensive, in-line queries of app labeled resources in K8s API server,
instead relying on the metadata in the local state cache. This dramatically improves performance
and responsiveness, and is less burdensome the K8s API server. A second benefit to this, is that the
relationship between object when computing the resource tree, can be displayed, even for custom
resources.
#### Performance & Scalability
The application controller has a completely redesigned architecture which improved performance and
scalability during application reconciliation.
This was achieved by introducing an in-memory, live state cache of lightweight Kubernetes object
metadata. During reconciliation, the controller no longer performs expensive, in-line queries of app
related resources in K8s API server, instead relying on the metadata available in the live state
cache. This dramatically improves performance and responsiveness, and is less burdensome to the K8s
API server.
#### Object relationship visualization for CRDs
With the new controller design, Argo CD is now able to understand ownership relationship between
*all* Kubernetes objects, not just the built-in types. This enables Argo CD to visualize
parent/child relationships between all kubernetes objects, including CRDs.
#### Multi-namespaced applications
Argo CD will now honor any explicitly set namespace in a mainfest. Resources without a namespace
will continue to be deployed to the namespace specified in `spec.destination.namespace`. This
enables support for a class of applications that install to multiple namespaces. For example,
Argo CD now supports the istio helm chart, which deploys some resources to an explit `istio-system`
namespace.
During sync, Argo CD will now honor any explicitly set namespace in a manifest. Manifests without a
namespace will continue deploy to the "preferred" namespace, as specified in app's
`spec.destination.namespace`. This enables support for a class of applications which install to
multiple namespaces. For example, Argo CD can now install the
[prometheus-operator](https://github.com/helm/charts/tree/master/stable/prometheus-operator)
helm chart, which deploys some resources into `kube-system`, and others into the
`prometheus-operator` namespace.
#### Large application support
Full resource objects are no longer stored in the Application CRD object status. Instead, only
lightweight metadata is stored in the status, such as a resource's sync and health status.
This change enables Argo CD to support applications with a very large number of resources
This change enabled Argo CD to support applications with a very large number of resources
(e.g. istio), and reduces the bandwidth requirements when listing applications in the UI.
#### Resource lifecycle hook improvements
Resource hooks are now visible from the UI. Additionally, bare Pods with a restart policy of Never
can now be used as a resource hook, as an alternative to Jobs, Workflows.
Resource lifecycle hooks (e.g. PreSync, PostSync) are now visible/manageable from the UI.
Additionally, bare Pods with a restart policy of Never can now be used as a resource hook, as an
alternative to Jobs, Workflows.
#### K8s recommended application labels
Resource labeling has been changed to use `app.kubernetes.io/instance` as recommended in
[Kubernetes recommended labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/),
(changed from `applications.argoproj.io/app-name`). This will enable applications created by Argo CD
to interoperate with other tooling that are also converging on this labeling, such as the Kubernetes
dashboard. Additionally, Argo CD will no longer inject any tracking labels at the
The tracking label for resources has been changed to use `app.kubernetes.io/instance`, as
recommended in [Kubernetes recommended labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/),
(changed from `applications.argoproj.io/app-name`). This will enable applications managed by Argo CD
to interoperate with other tooling which are also converging on this labeling, such as the
Kubernetes dashboard. Additionally, Argo CD no longer injects any tracking labels at the
`spec.template.metadata` level.
#### External OIDC provider support
Argo CD now supports auth delegation to an existing, external OIDC providers without the need for
Dex (e.g. Okta, OneLogin, Auth0, Microsoft, etc...)
running Dex (e.g. Okta, OneLogin, Auth0, Microsoft, etc...)
The optional, [Dex IDP OIDC provider](https://github.com/dexidp/dex) is still bundled as part of the
default installation, in order to provide a seamless out-of-box experience, and enables Argo CD to
integrate with non-OIDC providers, or to benefit from Dex's full range of
default installation, in order to provide a seamless out-of-box experience, enabling Argo CD to
integrate with non-OIDC providers, and to benefit from Dex's full range of
[connectors](https://github.com/dexidp/dex/tree/master/Documentation/connectors).
#### OIDC group claims bindings to Project Roles
Group claims from the OIDC provider can now be bound to Argo CD project roles. Previously, group
claims were managed at the centralized ConfigMap, `argocd-rbac-cm`. This enables project admins to
self service access to applications within a project.
#### OIDC group bindings to Project Roles
OIDC group claims from an OAuth2 provider can now be bound to a Argo CD project roles. Previously,
group claims could only be managed in the centralized ConfigMap, `argocd-rbac-cm`. They can now be
managed at a project level. This enables project admins to self service access to applications
within a project.
#### Declarative Argo CD configuration
Argo CD settings can be now be configured either declaratively, or imperatively. The `argocd-cm`
@ -65,21 +74,27 @@ which have a dependency to external helm repositories.
### Breaking changes:
* Argo CD's resource names were renamed for consistency. For example, the application-controller
deployment was renamed to argocd-application-controller. When upgrading from v0.10 to v0.11,
the older resources should be pruned to avoid inconsistent state and controller in-fighting.
* As a consequence to moving to recommended kubernetes labels, when upgrading from v0.10 to v0.11,
all applications will immediately be OutOfSync due to the change in labeling techniques. This will
all applications will immediately be OutOfSync due to the change in tracking labels. This will
correct itself with another sync of the application. However, since Pods will be recreated, please
take this into consideration, especially if your applications is configured with auto-sync.
take this into consideration, especially if your applications are configured with auto-sync.
* There was significant reworking of the `app.status` fields to simplify the datastructure and
remove fields which were no longer used by the controller. No breaking changes were made in
`app.spec`.
* There was significant reworking of the `app.status` fields to reduce the payload size, simplify
the datastructure and remove fields which were no longer used by the controller. No breaking
changes were made in `app.spec`.
* An older Argo CD CLI (v0.10 and below) will not be compatible with an Argo CD v0.11. To keep
* An older Argo CD CLI (v0.10 and below) will not be compatible with Argo CD v0.11. To keep
CI pipelines in sync with the API server, it is recommended to have pipelines download the CLI
directly from the API server https://${ARGOCD_SERVER}/download/argocd-linux-amd64 during the CI
pipeline.
### Changes since v0.10:
* Improve Application state reconciliation performance (#806)
* Refactor, consolidate and rename resource type data structures
+ Declarative setup and configuration of ArgoCD (#536)
+ Declaratively add helm repositories (#747)
+ Switch to k8s recommended app.kubernetes.io/instance label (#857)
@ -87,15 +102,18 @@ which have a dependency to external helm repositories.
+ Self service group access to project applications (#742)
+ Support for Pods as a sync hook (#801)
+ Support 'crd-install' helm hook (#355)
+ Use external 'diff' utility to render actual vs target state difference
+ Show sync policy in app list view
* Remove resources state from application CRD (#758)
* Refactor, consolidate and rename resource type data structures
* Improve Application state reconciliation performance (#806)
* API server & UI should serve argocd binaries instead of linking to GitHub (#716)
* Update versions for kubectl (v1.13.1), helm (v2.12.1), ksonnet (v0.13.1)
* Update version of aws-iam-authenticator (0.4.0-alpha.1)
* Ability to force refresh of application manifests from git
* Improve diff assessment for Secrets, ClusterRoles, Roles
- Failed to deploy helm chart with local dependencies and no internet access (#786)
- Out of sync reported if Secrets with stringData are used (#763)
- Unable to delete application in K8s v1.12 (#718)
## v0.10.6 (2018-11-14)
- Fix issue preventing in-cluster app sync due to go-client changes (issue #774)

2
README.md
View file

@ -21,7 +21,7 @@ Application deployment and lifecycle management should be automated, auditable,
```bash
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v0.11.0-rc6/manifests/install.yaml
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
```
Follow our [getting started guide](docs/getting_started.md). Further [documentation](docs/)

2
VERSION
View file

@ -1 +1 @@
0.11.0
0.12.0

125
docs/getting_started.md
View file

@ -1,7 +1,5 @@
# Argo CD Getting Started
An example guestbook application is provided to demonstrate how Argo CD works.
## Requirements
* Installed [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) command-line tool
* Have a [kubeconfig](https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) file (default location is `~/.kube/config`).
@ -9,36 +7,31 @@ An example guestbook application is provided to demonstrate how Argo CD works.
## 1. Install Argo CD
```bash
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v0.11.0-rc6/manifests/install.yaml
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
```
This will create a new namespace, `argocd`, where Argo CD services and application resources will live.
NOTE:
* On GKE with RBAC enabled, you may need to grant your account the ability to create new cluster roles
```bash
kubectl create clusterrolebinding YOURNAME-cluster-admin-binding --clusterrole=cluster-admin --user=YOUREMAIL@gmail.com
```
* On GKE, you will need grant your account the ability to create new cluster roles:
```bash
kubectl create clusterrolebinding YOURNAME-cluster-admin-binding --clusterrole=cluster-admin --user=YOUREMAIL@gmail.com
```
## 2. Download Argo CD CLI
Download the latest Argo CD version:
Download the latest Argo CD version from https://github.com/argoproj/argo-cd/releases/latest.
On Mac:
Also available in Mac Homebrew:
```bash
brew install argoproj/tap/argocd
```
On Linux:
```bash
curl -sSL -o /usr/local/bin/argocd https://github.com/argoproj/argo-cd/releases/download/v0.11.0-rc6/argocd-linux-amd64
chmod +x /usr/local/bin/argocd
```
## 3. Access the Argo CD API server
By default, the Argo CD API server is not exposed with an external IP. To access the API server,
choose one of the following means to expose the Argo CD API server:
choose one of the following techniques to expose the Argo CD API server:
### Service Type LoadBalancer
Change the argocd-server service type to `LoadBalancer`:
@ -51,8 +44,12 @@ kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}
Follow the [ingress documentation](ingress.md) on how to configure Argo CD with ingress.
### Port Forwarding
`kubectl port-forward` can also be used to connect to the API server without exposing the service.
The API server can be accessed using the localhost address/port.
Kubectl port-forwarding can also be used to connect to the API server without exposing the service.
```bash
kubectl port-forward svc/argocd-server 8080:443
```
The API server can then be accessed using the localhost:8080
## 4. Login using the CLI
@ -63,13 +60,12 @@ Argo CD API server. This can be retrieved with the command:
kubectl get pods -n argocd -l app=argocd-server -o name | cut -d'/' -f 2
```
Using the above password, login to Argo CD's external IP:
Using the above password, login to Argo CD's IP or hostname:
```bash
kubectl get svc -n argocd argocd-server
argocd login <EXTERNAL-IP>
argocd login <ARGOCD_SERVER>
```
After logging in, change the password using the command:
Change the password using the command:
```bash
argocd account update-password
```
@ -92,82 +88,77 @@ for docker-for-desktop context, run:
argocd cluster add docker-for-desktop
```
The above command installs an `argocd-manager` ServiceAccount and ClusterRole into the cluster
associated with the supplied kubectl context. Argo CD uses this service account token to perform its
management tasks (i.e. deploy/monitoring).
The above command installs a ServiceAccount (`argocd-manager`), into the kube-system namespace of
that kubectl context, and binds the service account to an admin-level ClusterRole. Argo CD uses this
service account token to perform its management tasks (i.e. deploy/monitoring).
> NOTE: the rules of the `argocd-manager-role` role can be modified such that it only has
`create`, `update`, `patch`, `delete` privileges to a limited set of namespaces, groups, kinds.
However `get`, `list`, `watch` privilges are required at the cluster-scope for Argo CD to function.
## 6. Create an application from a git repository location
## 6. Create an application from a git repository
An example git repository containing a guestbook application is available at
https://github.com/argoproj/argocd-example-apps.git to demonstrate how Argo CD works.
### Creating apps via CLI
```bash
argocd app create guestbook \
--repo https://github.com/argoproj/argocd-example-apps.git \
--path guestbook \
--dest-server https://kubernetes.default.svc \
--dest-namespace default
```
### Creating apps via UI
Open a browser to the Argo CD external UI, and login using the credentials set in step 4, and the
external IP/hostname set in step 4.
Connect a git repository containing your apps if repository is private. An example repository containing a sample
guestbook application is available at https://github.com/argoproj/argocd-example-apps.git.
Open a browser to the Argo CD external UI, and login using the credentials, IP/hostname set in step 4.
Connect the https://github.com/argoproj/argocd-example-apps.git repo to Argo CD:
![connect repo](assets/connect_repo.png)
After connecting a git repository, select the guestbook application for creation:
![select repo](assets/select_repo.png)
![select app](assets/select_app.png)
![select env](assets/select_env.png)
![create app](assets/create_app.png)
### Creating apps via CLI
Applications can be also be created using the Argo CD CLI:
```bash
argocd app create guestbook-default --repo https://github.com/argoproj/argocd-example-apps.git --path ksonnet-guestbook
```
## 7. Sync (deploy) the application
Once the guestbook application is created, you can now view its status:
From UI:
![guestbook app](assets/guestbook-app.png)
From CLI:
```bash
$ argocd app get guestbook-default
Name: guestbook-default
Server: https://kubernetes.default.svc
Namespace: default
URL: https://192.168.64.36:31880/applications/argocd/guestbook-default
Environment: default
Repo: https://github.com/argoproj/argocd-example-apps.git
Path: guestbook
Target: HEAD
$ argocd app get guestbook
Name: guestbook
Server: https://kubernetes.default.svc
Namespace: default
URL: https://10.97.164.88/applications/guestbook
Repo: https://github.com/argoproj/argocd-example-apps.git
Target:
Path: guestbook
Sync Policy: <none>
Sync Status: OutOfSync from (1ff8a67)
Health Status: Missing
KIND NAME STATUS HEALTH
Service guestbook-ui OutOfSync
Deployment guestbook-ui OutOfSync
GROUP KIND NAMESPACE NAME STATUS HEALTH
apps Deployment default guestbook-ui OutOfSync Missing
Service default guestbook-ui OutOfSync Missing
```
The application status is initially in an `OutOfSync` state, since the application has yet to be
The application status is initially `OutOfSync` state, since the application has yet to be
deployed, and no Kubernetes resources have been created. To sync (deploy) the application, run:
```bash
$ argocd app sync guestbook-default
Application: guestbook-default
Operation: Sync
Phase: Succeeded
Message: successfully synced
KIND NAME MESSAGE
Service guestbook-ui service "guestbook-ui" created
Deployment guestbook-ui deployment.apps "guestbook-ui" created
argocd app sync guestbook
```
This command retrieves the manifests from git repository and performs a `kubectl apply` of the
manifests. The guestbook app is now running and you can now view its resource components, logs,
events, and assessed health status:
### From UI:
![guestbook app](assets/guestbook-app.png)
![view app](assets/guestbook-tree.png)
## 8. Next Steps