background

The concept of GitOps originated in a blog post by Weaveworks co-founder Alexis, GitOps – Operations by Pull Request, published in August 2017. It is a fast and secure way for developers and operations to go live in a cluster and update complex applications running on Kubernetes. Alexis’ article describes how Weaveworks engineers deploy, manage, and monitor Kubernetes-based SaaS applications using Git as the only true source of facts.

Core:

  • GitOps is an operational model for K8s and other cloud native technologies, providing a set of best practices for unified deployment, management, and monitoring of container clusters and applications.
  • Both the end-to-end CICD pipeline and git workflow are used to operate and develop a developer experience path to managed applications;

Git Commit/Reserve is an easy way to publish Git commit/ Reserve and roll back Git.

An overview of

1.1 When will Argo CD be

Argo CD is a declarative, Gitops continuous integration tool for K8S.

1.2 Why use Argo CD

Application definitions/configurations and environments should be declared and versioned, and application deployment and lifecycle management should be automated, auditable, and easy to understand.

1.3 the use of

1.3.1 Working mode

The Argo CD follows the GitOps pattern, which uses a Git repository as a real source for defining the required application state. Kubernetes listings can be specified in several ways:

  • kustomize applications
  • helm charts
  • ksonnet applications
  • jsonnet files
  • Plain directory of YAML/json manifests
  • Any custom config management tool configured as a config management plugin

The Argo CD automatically deploys the required application state in the specified target environment. Application deployment can track updates to branches, tags, or fixed to a specific version of a manifest at Git commit time. For more information about the different tracing policies available, see Tracing Policies.

1.3.2 architecture

The Argo CD is implemented as a Kubernetes controller that continuously monitors the running application and compares the current active state to the desired target state (specified in the Git repository). Deployed applications that are active and off-target are considered OutOfSync. The Argo CD reports and visualizes differences while providing the ability to automatically or manually synchronize real-time state back to the desired target state. Any changes made to the desired target state in the Git repository are automatically applied and reflected in the specified target environment.

Ii basic Concepts

Before using Argo CDS effectively, it is important to understand the underlying technologies on which the platform is based. You also need to understand the features that are provided to you and how to use them. The following sections provide some useful links to help you understand.

2.1 Basics

2.1.1K8S knowledge points

  • A Beginner-Friendly Introduction to Containers, VMs and Docker
  • Introduction to Kubernetes
  • Tutorials
  • Hands on labs

2.1.2 Customizing templates

  • Kustomize
  • Helm
  • Ksonnet

2.1.3 Jenkins integration

  • Jenkins User Guide

Three Core concepts

It is assumed that you are familiar with the core Git, Docker, Kubernetes, continuous delivery, and GitOps concepts.

  • Application: A set of Kubernetes resources defined by the manifest. This is a custom resource definition (CRD).
  • Application Source Type: Which tool to use to build the Application
  • Target State: The desired state of the application, represented by a file in a Git repository.
  • Live State: Real-time status of the application. What pods are deployed, etc.
  • Sync Status: Indicates whether the real-time status matches the target status. Is the deployed application what Git says it is?
  • Sync: The process of moving an application to its target state. For example. By applying the changes to the Kubernetes cluster.
  • Refresh: Compares the latest code in Git to the live state. Find out what the difference is.
  • Health: Is the Health of the application healthy? Does it satisfy the request?
  • Tool: a Tool for creating lists from file directories. For example. Kustomize or Ksonnet. See application source types.

4 Installation and Deployment

4.1 Installing the Argo CD

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
Copy the code

This will create a new namespace, argocd, in which the Argo CD service and application resources will reside.

4.2 Downloading the Argo CD CLI

From github.com/argoproj/ar… CD tools

  • The MAC can be installed in the following ways
brew tap argoproj/tap
brew install argoproj/tap/argocd
Copy the code
  • Linux installation
VERSION=$(curl --silent "https://api.github.com/repos/argoproj/argo-cd/releases/latest" | grep '"tag_name"' | sed -E 's/.*"([^"]+)".*/\1/')
curl -sSL -o /usr/local/bin/argocd https://github.com/argoproj/argo-cd/releases/download/$VERSION/argocd-linux-amd64
chmod +x /usr/local/bin/argocd
Copy the code

IO/Argo -cd/cli…

4.3 Accessing the Argo CD API Server

By default, the Argo CD API server is not exposed using an external IP. To access the API server, select one of the following technologies to expose the Argo CD API server:

Port forwarding

[root@master ~]# kubectl port-forward SVC/argocd-server-n argocd --address 0.0.0.0 8080:443Copy the code

4.4 Logging In to Argo through the CLI

The initial password will automatically be generated as the container name of the Argo CD API server. This can be retrieved using the following command:

\

Log in to the IP or host name of the Argo CD using user name admin and the password above:Copy the code
argocd login <ARGOCD_SERVER>
Copy the code

Use the following command to change the password:

argocd account update-password
Copy the code
# argocd login localhost:8080 WARNING: Server certificate had error: X509: certificate signed by unknown authority. Proceed insecurely (y/n)? yes Username: admin Password: 'admin' logged in successfully Context 'localhost:8080' updated # Change password [root@master ~]# argocd account update-password *** Enter current password: *** Enter new password: *** Confirm new password: Password updated Context 'localhost:8080' updatedCopy the code

4.5 (Optional) Registering a cluster to deploy applications to

This step registers the cluster’s credentials with the Argo CD, which is required only when deployed to an external cluster. When deploying internally (to the same cluster where the Argo CD is running), use https://kubernetes.default.svc as the K8s API server address for your application.

Start by listing all cluster contexts currently in kubconfig:

argocd cluster add
Copy the code

The command above installs ServiceAccount (argocd-manager) into the kube-system namespace of the kubectl context and binds the ServiceAccount to the ClusterRole at the administrator level. The Argo CD uses this service account token to perform its administrative tasks (that is, deployment/monitoring).

You can modify the rules of the argocd-manager-role role to have create, update, patch, and delete privileges for a limited set of namespaces, groups, and categories. However, in cluster scope, acquiring, listing, and monitoring privileges are required for Argo CD to function.

4.6 Creating an application from a Git repository

A sample application of GuestBook to warehouse protection to illustrate how Argo CD works: github.com/argoproj/ar…

4.6.1 Creating an APP on the CLI

You can access Argo CD using port forwarding: add --port-forward-namespace argocd flag to every CLI command or set ARGOCD_OPTS environment variable: export ARGOCD_OPTS='--port-forward-namespace argocd':

argocd app create guestbook --repo https://github.com/argoproj/argocd-example-apps.git --path guestbook --dest-server https://kubernetes.default.svc --dest-namespace default
Copy the code

4.6.2 Creating an APP using the Web UI

Open your browser and go to the Argo CD external UI, then log in by accessing the IP/host name in your browser and using the credentials set in Step 4.

Name your application the guestbook, use the project defaults, and leave the synchronization policy as manual:

Connect the github.com/redhatxl/ar… repo to Argo CD by setting repository url to the github repo url, leave revision as HEAD, and set the path to guestbook:

Note: the repository can use the current and changed mirror address of my fork, it can be pulled normally.

For the target, set the cluster to within the cluster and set the namespace to the default:

After filling in the above information, click Create at the top of the UI to create the guestbook application:

4.7 Synchronizing (Deploying) Applications

Having created the guestbook application, you can now view its status:

[root@master ~]# argocd app get guestbook
Name:               guestbook
Project:            default
Server:             https://kubernetes.default.svc
Namespace:          default
URL:                https://localhost:8080/applications/guestbook
Repo:               https://github.com/redhatxl/argocd-example-apps.git
Target:             HEAD
Path:               guestbook
SyncWindow:         Sync Allowed
Sync Policy:        <none>
Sync Status:        OutOfSync from HEAD (4973f15)
Health Status:      Missing

GROUP  KIND        NAMESPACE  NAME          STATUS     HEALTH   HOOK  MESSAGE
       Service     default    guestbook-ui  OutOfSync  Missing        
apps   Deployment  default    guestbook-ui  OutOfSync  Missing
Copy the code
Because the application has not been deployed and Kubernetes resources have not been created, the application state is initially in the OutOfSync state. To synchronize (deploy) the application, run:Copy the code
[root@master ~]# argocd app sync guestbook
TIMESTAMP                  GROUP        KIND   NAMESPACE                  NAME    STATUS    HEALTH        HOOK  MESSAGE
2020-01-24T12:59:13+08:00            Service     default          guestbook-ui  OutOfSync  Missing              
2020-01-24T12:59:13+08:00   apps  Deployment     default          guestbook-ui  OutOfSync  Missing              
2020-01-24T12:59:14+08:00            Service     default          guestbook-ui    Synced  Healthy              

Name:               guestbook
Project:            default
Server:             https://kubernetes.default.svc
Namespace:          default
URL:                https://localhost:8080/applications/guestbook
Repo:               https://github.com/redhatxl/argocd-example-apps.git
Target:             HEAD
Path:               guestbook
SyncWindow:         Sync Allowed
Sync Policy:        <none>
Sync Status:        Synced to HEAD (4973f15)
Health Status:      Progressing

Operation:          Sync
Sync Revision:      4973f150497aa18bc5fbd81b19102db2469eb6f0
Phase:              Succeeded
Start:              2020-01-24 12:59:11 +0800 CST
Finished:           2020-01-24 12:59:12 +0800 CST
Duration:           1s
Message:            successfully synced (all tasks run)

GROUP  KIND        NAMESPACE  NAME          STATUS  HEALTH       HOOK  MESSAGE
       Service     default    guestbook-ui  Synced  Healthy            service/guestbook-ui created
apps   Deployment  default    guestbook-ui  Synced  Progressing        deployment.apps/guestbook-ui created
Copy the code

This command retrieves the manifest from the repository and performs the Kubectl application on the manifest. The guestbook application is now running and you can now view the health status of its resource components, logs, events, and assessments:

Status after deployment:

[root@master ~]# kubectl  get all -l app=guestbook-ui
NAME                                READY   STATUS    RESTARTS   AGE
pod/guestbook-ui-7bc795dc8c-m69fl   1/1     Running   0          3m6s

NAME                                      DESIRED   CURRENT   READY   AGE
replicaset.apps/guestbook-ui-7bc795dc8c   1         1         1       3m6s
Copy the code

Change the access mode of GuestBook to NodePort

5 Operation Manual

5.1 an overview of the

This guide is intended for administrators and operators who want to install and configure Argo CDS for other developers.

5.2 Architecture Overview

5.2.1 API Server

The API server is a gRPC/REST server that exposes the apis used by Web UI, CLI, and CI/CD systems. It has the following responsibilities:

  • Application management and status reporting
  • Apply call operations (synchronous, rollback, user-defined)
  • Warehouse and cluster authentication management
  • Authentication and authentication delegates to external identity providers
  • RBAC mandatory
  • Monitor/forward Git webhook events

5.2.2 Repository Server

The repository service is an internal service that maintains a local Git directory with its manifests, which is used to generate and return kubernetes manifests when providing the following inputs

  • Warehouse URL
  • Versions (COMMIT, Tag, branch)
  • Apply the patch
  • Template Settings

5.2.3 requires Application Controller

Application of the controller is a k8s controller, he is used to continuous monitoring the running of the current state of the application and comparison, and survival state assignment is expectation of target state (from making repo), he detection outofsync application state and optional tasks, it calls any user custom hooks for statement cycle events

5.3 Declaration Settings

5.3.1 Quick Reference

You can use Kubernetes listings to declaratively define Argo CD applications, projects, and Settings.

5.3.2 application

Application CRD is a Kubernetes resource object that represents deployed Application instances in the environment. It is defined by two key pieces of information:

  • Source reference (repository, revision, path, environment) pairs to desired states in Git
  • Target references to target clusters and namespaces.

The minimum application specification is as follows:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/argoproj/argocd-example-apps.git
    targetRevision: HEAD
    path: guestbook
  destination:
    server: https://kubernetes.default.svc
    namespace: guestbook
Copy the code

Refer to application.yaml for additional fields

The namespace must match the namespace of Argo CD, usually argocd.

By default, deleting applications will not perform cascading deletes to remove their resources. If this behavior is required, you must add finalizers — which you probably don’t want to do.

You can create an application that can create other applications, and that application can create other applications. This allows you to declaratively manage a set of applications that can be deployed and configured in a coordinated manner. See cluster boot.

AppProject CRD is a Kubernetes resource object that represents a logical grouping of applications. It is defined by the following key information:

  • SourceRepos references a repository from which the application in the project can extract the manifest.
  • The target refers to the cluster and namespace to which applications in the project can be deployed.
  • A list of roles for an entity and its definition of access to resources in the project.