diff --git a/CHANGELOG.md b/CHANGELOG.md index b45474a8c0..5f4ea5e106 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -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) diff --git a/README.md b/README.md index 24021ea004..6a4b5a8b0e 100644 --- a/README.md +++ b/README.md @@ -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/) diff --git a/VERSION b/VERSION index d9df1bbc0c..d33c3a2128 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -0.11.0 +0.12.0 \ No newline at end of file diff --git a/docs/getting_started.md b/docs/getting_started.md index aaeb6ff1e7..8861b3ffe9 100644 --- a/docs/getting_started.md +++ b/docs/getting_started.md @@ -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 +argocd login ``` -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: +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