GitOps(Argo CD) Fundamentals Course Notes

To Get Certified for GitOps with Argo, check out: https://besttechreads.blogspot.com/2022/07/get-certified-for-gitops-with-argo.html

────────────────────────────────────────────────

Argo CD:

Practice repo: https://github.com/kishoreuppala/gitops-certification-examples-kuppala/

Argo CD Installation:

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

Expose the Argo CD UI:

cat service.yml

apiVersion: v1
kind: Service
metadata:
  labels:
    app: argocd-server
  managedFields:
  name: argocd-server-nodeport
  namespace: argocd
spec:
  ports:
  - nodePort: 30443
    port: 8080
    protocol: TCP
  selector:
    app.kubernetes.io/name: argocd-server
  type: NodePort

-->kubectl apply -f service.yml  (to create node port service)

Note: In prod, we have to configure clusterIP for better security.

Log in the Argo CD UI:

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d > admin-pass.txt

Argo CD CLI:

Install CLI:
curl -sSL -o /usr/local/bin/argocd https://github.com/argoproj/argo-cd/releases/download/v2.1.5/argocd-linux-amd64
chmod +x /usr/local/bin/argocd

Test CLI: argocd help

Login with the CLI:

argocd login localhost:30443 --insecure     #In prod we should not use --insecure option

Creating an Argo CD application with CLI:

argocd app create {APP NAME} \
--project {PROJECT} \
--repo {GIT REPO} \--path {APP FOLDER} \
--dest-namespace {NAMESPACE} \
--dest-server {SERVER URL}

{APP NAME} is the name you want to give the application
{PROJECT} is the name of the project created or "default"
{GIT REPO} is the url of the git repository where the gitops config is located
{APP FOLDER} is the path to the configuration for the application in the gitops repo
{DEST NAMESPACE} is the target namespace in the cluster where the application will be deployed
{SERVER URL} is the url of the cluster where the application will be deployed. Use https://kubernetes.default.svc to reference the same cluster where Argo CD has been deployed

Check status:

argocd app list
argocd app get {APP NAME}   #For more detailed view

Sync application:

argocd app sync {APP NAME}
kubectl -n {NAMESPACE} get all  #To see application status in kubernetes

cli commands:deploy app

argocd app list
argocd app get demo
argocd app history demo

delete the app

argocd app delete demo

deploy app using cli: Create

argocd app create demo2 \
--project default \
--repo https://github.com/codefresh-contrib/gitops-certification-examples \
--path "./simple-app" \
--dest-namespace default \
--dest-server https://kubernetes.default.svc

sync app:

argocd app sync demo2

argocd app sync demo      #Sync an application to its target state
argocd app wait demo      #Wait for an application to reach a synced and healthy state

Quiz Argo CD basics:

What is Argo CD?
A) A GitOps Agent
Which other Argo products does Argo CD need to function correctly?
A) None. Argo CD is a standalone project. It works great with the other Argo projects, but it does not depend on them.
How does ArgoCD interact with clusters?
A) You can have any combination of clusters and ArgoCD instances. ArgoCD can deploy applications on the cluster it is installed on, or other external clusters that are authenticated correctly
How can you install ArgoCD on your cluster?
A) You can use any of the above including other community methods
What is the relationship between the ArgoCD Web interface and the Argo CD Command line executable?
A) The Argo CD UI and the CLI can be used interchangeably according to your needs.

By default, the sync period is 3 minutes. This means that every 3 minutes Argo CD will:

• Gather all applications that are marked to auto-sync.
• Fetch the latest Git state from the respective repositories.
• Compare the Git state with the cluster state.
• Take an action:
• If both states are the same, do nothing and mark the application as synced.
• If states are different mark the application as "out-of-sync".

Edit default sync period (heartbeat): You can change the default period by editing the argocd-cm configmap found on the same namespace as Argo CD.

────────
apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cm
  namespace: argocd
  labels:
    app.kubernetes.io/name: argocd-cm
    app.kubernetes.io/part-of: argocd
data:
  timeout.reconciliation: 240s
────────

This example changes the sync period to 4 minutes. After you change the manifest, you need to redeploy the argocd-repo-server service.You can disable the sync functionality completely by setting the timeout.reconciliation period to 0.

Using Webhooks is very efficient, as now your Argo CD installation will never delay when you commit something to Git. If you only use the default way of polling, then you might have to wait up to 3 minutes (or whatever time you have set as sync period) for Argo CD to detect the changes. With Webhooks, as soon as there is any change in Git, Argo CD will run the sync process.

Application Health

Apart from the synced/out-of-sync status, Argo CD also keeps track of the service health for each deployed application. The health status is shown in the UI and can also be retrieved by the CLI.

The possible values are:

“Healthy” -> Resource is 100% healthy
“Progressing” -> Resource is not healthy but still has a chance to reach healthy state
“Suspended” -> Resource is suspended or paused. The typical example is a cron job
“Missing” -> Resource is not present in the cluster
“Degraded” -> Resource status indicates failure or resource could not reach healthy state in time
“Unknown” -> Health assessment failed and actual health status is unknown

Kubernetes health:

• The decision whether an application is healthy or not depends on the type of underlying Kubernetes resources.
• Deployments, ReplicaSets, StatefulSets, and Daemon sets are considered “healthy” if observed generation is equal to desired generation.
• For a service of type Loadbalancer or Ingress, the resource is healthy if the status.loadBalancer.ingress list is non-empty, with at least one value for hostname or IP.

For custom Kubernetes resources, health is defined in Lua scripts. Some examples of resources that have custom health definitions are:

Argo Rollout (and associated Analysis and Experiments)

Bitnami Sealed secrets

Cert Manager

Elastic Search

Jaeger

Kafka

CrossPlane provider

Sync Strategies:

There are 3 parameters that you can change when defining the sync strategy:

1. Manual or automatic sync.
2. Auto-pruning of resources - this is only applicable for automatic sync.
3. Self-Heal of cluster - this is only applicable for automatic sync.

Manual or automatic sync defines what Argo CD does when it finds a new version of your application in Git. If set to automatic, Argo CD will apply the changes then update/create new resources in the cluster. If set to manual, Argo CD will detect the change but will not change anything in the cluster.

Auto-pruning defines what Argo CD does when you remove/delete files from Git. If it is enabled, Argo CD will also remove the respective resources in the cluster as well. If disabled, Argo CD will never delete anything from the cluster.

Self-heal defines what Argo CD does when you make changes directly to the cluster (via kubectl or any other way). Note that doing manual changes in the cluster is not recommended if you want to follow GitOps principles (as all changes should pass from Git). If enabled, then Argo CD will discard the extra changes and bring the cluster back to the state described in Git.

policy                     A                  B               C                    D                    E
──────      ──────    ──────  ──────     ──────     ──────
sync strategy   Manual              Auto           Auto              Auto              Auto
Auto-prune      N/A                 Disabled    Enabled           Disabled      Enabled
Self-heal           N/A                Disabled    Disabled          Enabled       Enabled

Policy A (nothing is done by Argo CD) is probably how you should start adopting Argo CD , especially if you want to apply GitOps on an existing project. This is your chance to see how Argo CD works, without actually affecting your deployments.

Policy B (auto-sync) is the first step towards following GitOps with its automation capabilities. As soon as any change happens in Git, your cluster will auto-update. Disabling auto-prune means that you must still delete resources manually, and disabled self-heal means that you can still make manual changes to the cluster (if you want to have a migration period).

Policies C and D are orthogonal and can act as stepping stones to Policy E, which is the one you should look up to.

Under that policy, everything is automated both ways. Changes in Git are also reflected automatically to the cluster (including removals of resources), and manual changes in the cluster are simply discarded.

Sync Strategies:

we can enable "auto sync" , by click on ... (app details)-->sync strategies-->Auto sync-->enable

Enable auto-prune

Even after having auto-sync on and self-heal on, Argo CD will never delete resources from the cluster if you remove them in Git.
To enable this behavior you need to enable the "auto-prune" option.

Scroll down and find the "Sync policy section". Click on the "Prune resources" button to enable it.

Managing Secrets

But what about secrets? How can you use secrets with GitOps?
If you already have a solid solution in place such as HashiCorp vault, then it would make sense to use that even though technically it is against GitOps practices.If you are starting from scratch on a new project, there are ways to store secrets in Git so that you can manage them using GitOps principles as well.

The Bitnami Sealed secrets controller is a Kubernetes controller you install on the cluster that performs a single task. It converts sealed secrets (that can be committed to Git) to plain secrets (that can be used in your application).

Installing the controller is straightforward:

• helm repo add sealed-secrets https://bitnami-labs.github.io/sealed-secrets
• helm repo update
• helm install sealed-secrets-controller sealed-secrets/sealed-secrets

Once installed, the controller creates two keys on its own:

1. The private key is used for secret decryption. This key should stay within the cluster, and you should never give it to anyone.
2. The public key is used for secret encryption. This can (and will) be used outside the cluster, so it is ok to give it to somebody else.

Encrypting your secrets

We have seen how the controller decrypts secrets. But how do we encrypt secrets in the first place? The controller comes with the associated kubeseal executable that is created for this purpose.

Kubeseal does the opposite operation from the controller. It takes an existing Kubernetes secret and encrypts it. Kubeseal requests the public key that was created during the installation process from the cluster and encrypts all secrets with that key.

This means that:

Kubeseal needs access to the cluster in order to encrypt secrets. (It expects a kubeconfig like kubectl.)
Encrypted secrets can only be used in the cluster that was used for the encryption process.

The last point is very important as it means that all secrets are cluster specific.
The namespace of the application is also used by default, so secrets are cluster and namespace specific.

If you want to use the same secret for different clusters, you need to encrypt it for each cluster individually.

To use kubeseal, just take any existing secret in yaml or json format and encrypt it:

kubeseal -n my-namespace <.db-creds.yml> db-creds.json

This creates a SealedSecret which is a custom Kubernetes resource specific to the controller.This file is safe to commit in Git or store in another external system.
You can then apply the secret on the cluster: 

kubectl apply -f db-creds.json -n my-namespace

The secret is now part of the cluster and will be decrypted by the controller when an application needs it.

SealedSecrets The full process is the following:

1. You create a plain Kubernetes secret locally. You should never commit this anywhere.
2. You use kubeseal to encrypt the secret in a SealedSecret.
3. You delete the original secret from your workstation and apply the sealed secret to the cluster.
4. You can optionally commit the Sealed secret to Git.
5. You deploy your application that expects normal Kubernetes secrets to function. (The application needs no modifications of any kind.)
6. The controller decrypts the Sealed secrets and passes them to your application as plain secrets.
7. The application works as usual.

By using the Sealed Secrets controller, we can finally store all our secrets in Git (in an encrypted form) right along the application configuration.

Encrypt your plain Kubernetes secrets and convert them to encrypted secrets

kubeseal < unsealed_secrets/db-creds.yml > sealed_secrets/db-creds-encrypted.yaml -o yaml
kubeseal < unsealed_secrets/paypal-cert.yml > sealed_secrets/paypal-cert-encrypted.yaml -o yaml

Declarative Setup
Argo CD comes with its own custom resources that can be stored in Git, and applied in a cluster using kubectl or even better Argo CD itself.

For example when you create an application in Argo CD, essentially you are creating a grouping between:

1. A Git repository that holds your manifest
2. An Argo CD project
3. A cluster
4. Several other custom settings (extra parameters, target namespace etc.)

Even though the action is performed by the UI by clicking buttons, it is better if you create the following Argo CD application:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: canary-demo
spec:
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: demo
  project: default
  source:
    repoURL: 'https://github.com/kostis-codefresh/summer-of-k8s-app-manifests
    path: ./
    targetRevision: HEAD

Apart from applications, all other Argo CD entities have the respective Kubernetes resource such as:

-Projects
-Secrets
-RBAC configuration
-Git repositories
-Etc.

This means that in all scenarios, it is much better to fully adopt GitOps and work exclusively via Kubernetes resources and git commits instead of GUI actions. The GUI of Argo CD is best used for verifying and inspecting resources instead of changing them by hand.

ArgoCD declarative format

cat my-application.yml

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: demo
  # You'll usually want to add your resources to the argocd namespace.
  namespace: argocd
  # Add a this finalizer ONLY if you want these to cascade delete.
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  # The project the application belongs to.
  project: default

  # Source of the application manifests
  source:
    repoURL: https://github.com/codefresh-contrib/gitops-certification-examples.git
    targetRevision: HEAD
    path: ./declarative/manifests

    # directory
    directory:
      recurse: false
  # Destination cluster and namespace to deploy the application
  destination:
    server: https://kubernetes.default.svc
    namespace: default

  # Sync policy
  syncPolicy:
    automated: # automated sync by default retries failed attempts 5 times with following delays between attempts ( 5s, 10s, 20s, 40s, 80s ); retry controlled using `retry` field.
      prune: true # Specifies if resources should be pruned during auto-syncing ( false by default ).
      selfHeal: true # Specifies if partial app sync should be executed when resources are changed only in target Kubernetes cluster and no git change detected ( false by default ).
      allowEmpty: false # Allows deleting all application resources during automatic syncing ( false by default ).

Create application:

kubectl apply -f my-application.yml

Delete application:

kubectl delete -f my-application.yml

Deploying with Helm
Helm is a package manager for Kubernetes. It’s a convenient way for packaging collections of YAML files with a Helm chart for the Kubernetes application and allowing distribution with a Helm repository.

When using Helm, there are some powerful commands you will find useful.

To install a new package:

helm install release_name and name_of_chart_you_want_to_install

The chart install performs the Kubernetes deployment and service creation of the application. The chart is essentially a collection of files used to describe a set of Kubernetes resources, and Helm manages the creation of these resources.

To confirm the deployment and view the currently deployed release:

helm list
or
helm ls

To view revision numbers for a particular release:

helm history release_name

To execute a rollback:

helm rollback release_name revision_id

To upgrade a release:

helm upgrade release_name chart_name

Something important to note is that Argo CD provides native support for Helm, meaning you can directly connect a packaged Helm chart and Argo CD will monitor it for new versions. When this takes place, the Helm chart will no longer function as a Helm chart and instead, is rendered with the Helm template when Argo is installed, using the Argo CD application manifest.

Argo CD then deploys and monitors the application components until both states are identical. The application is no longer a Helm application and is now recognized as an Argo app that can only operated by Argo CD.
----------------Hence if you execute the "helm list" command, you should no longer be able to view your helm release because the Helm metadata no longer exists.------------

Once you setup ArgoCD application with helm - Note that if you use any of the helm commands such as helm list you will not see anything at all. A Helm chart deployed by ArgoCD no longer registers as a Helm deployment. This is because ArgoCD doesn't include the Helm payload information. When deploying a Helm application, Argo CD runs "helm template" and deploys the resulting manifests.

Deploying with Kustomize
Kustomize is a CLI configuration manager for Kubernetes objects with a kustomization.yaml file. It is integrated with kubectl and allows you to customize raw, template-free YAML files for multiple purposes declaratively. Kustomize relies on the following configuration layering to enable reusability:

1) Base Layer: This layer specifies the most common resources.
2) Overlays: This layer specifies use-case specific resources by utilizing patches to override other kustomization files and Kubernetes manifests.

$ ~/demoApp
├── base
│   ├── configMap.yaml
│   ├── deployment.yaml
│   ├── kustomization.yaml
│   └── service.yaml
└── overlays
      ├── production
      │   ├── deployment.yaml
      │   └── kustomization.yaml
      └── staging
            ├── kustomization.yaml
            └── map.yaml

The base folder holds common resources, such as the deployment.yaml, service.yaml, and configuration files. The overlays folder houses environment-specific overlays, which use patches to allow YAML files to be defined and overlaid on top of the base for any changes.

You can generate a customized YAML file:

kustomize build name_of_application

This file/resources can then be applied to a cluster:

kustomize build name_of_application | kubectl apply -k or --kustomize

This then creates all 3 resources previously mentioned: ConfigMap, Deployment, and Service.

Both Kustomize and Argo CD are declarative tools for Kubernetes that follow the GitOps pattern and work well together. Argo CD supports Kustomize and has the ability to read a kustomization.yaml file. To deploy Kustomize with Argo CD, ensure the Kubernetes cluster is set up and you are logged into Argo CD so that these resources are provided and can be deployed.

Create a namespace in the cluster:

kubectl create ns kustomize

Reference the Git repository with the Kustomize file to create an Argo CD app:

argocd app create name_of_application --repo repo_url --revision kustomize --path path_for_your_kustomize_files --dest-server server-url --dest-namespace kustomize

Sync deployment managed by Argo CD:

argocd app sync application_name

Check status of deployment:

argocd app get application_name

Each time a new kustomize.yaml file is created or the file changes, Argo CD can detect those and make updates to the deployment.

Create application through kustomize:

argocd app create demo \
--project default \
--repo https://github.com/codefresh-contrib/gitops-certification-examples \
--path ./kustomize-app/overlays/staging \
--sync-policy auto \
--dest-namespace default \
--dest-server https://kubernetes.default.svc

What is Progressive Delivery
Progressive Delivery is the practice of deploying an application in a gradual manner allowing for minimum downtime and easy rollbacks. There are several forms of progressive delivery such as blue/green, canary, a/b and feature flags.

Blue Green Deployments
Blue/Green deployments are one of the simplest ways to minimize deployment downtime. Blue/Green deployments are not specific to Kubernetes and can be used even for traditional applications that reside on Virtual Machines.

Canary Deployments
Blue/Green deployments are great for minimizing downtime after a deployment, but they are not perfect. If your new version has a hidden issue that manifests itself only after some time (i.e. it is not detected by your smoke tests), then all your users will be affected because the traffic switch is all or nothing.

An improved deployment method is canary deployments. This functions similar to blue/green, but instead of switching 100% of live traffic all at once to the new version, you can instead move only a subset of users.

Note that canary deployments are more advanced than blue/green ones and are also more complex to set up. The load balancer is now much smarter as it can handle two streams of traffic at the same time with different destinations of different weights. You also need a way (usually an API) to instruct the load balancer to change the weight distribution of the traffic streams. If you are just getting started with progressive delivery, we suggest you master blue/green deployments first, before adopting canary ones.

Argo Rollouts
Argo Rollouts is a progressive delivery controller created for Kubernetes. It allows you to deploy your application with minimal/zero downtime by adopting a gradual way of deploying instead of taking an “all at once” approach.

Argo Rollouts supercharges your Kubernetes cluster and in addition to the rolling updates you can now do:

Blue/green deployments

Canary deployments

A/B tests

Automatic rollbacks

Integrated Metric analysis

Blue/Green with Argo Rollouts
Even though Argo Rollouts supports the basic blue/green pattern described in the previous section, it also offers a wealth of customization options. One of the most important additions is the ability to “test” the upcoming color by introducing a “preview” Kubernetes service, in addition to the service used for live traffic. This preview service can be used by the team that performs the deployment to verify the new version before actually switching the traffic.

The important point here is the fact that the normal “active” service still points to the old version while the “preview” service points to the new pods. This means that all active users are still on the old/stable deployment while internal teams can use the “preview” service to test the new deployment.

If everything goes well, the next version is promoted to be the active version.

Having the old version around is a great failsafe, as one can abort the deployment process and switch back all active users to the old deployment in the fastest way possible.

After some time (the exact amount is configurable in Argo Rollouts), the old version is scaled down completely (to preserve resources). We are now back to the same configuration as the initial state, and the next deployment will follow the same sequence of events.

Monitor argo rollouts:

kubectl argo rollouts list rollouts
kubectl argo rollouts status simple-rollout
kubectl argo rollouts get rollout simple-rollout

kubectl argo rollouts get rollout simple-rollout --watch

kubectl get rs

The amount of pods you have in the canary is completely unrelated to the amount of traffic that you send to it. You can have all possible combinations that you can think of (e.g. 10% of traffic to 5 pods, or 50% of traffic to 3 pods and so on). It all depends on the resources used by your application.

Having the old version around is a great failsafe, as one can abort the deployment process and switch back all active users to the old deployment in the fastest way possible by simply telling the load balancer to move 100% of traffic back to the previous version.

We need a Gateway or a Service Mesh for traffic splits in Canary deployments

Install Ambassador
Blue/Green deployments can work on any vanilla Kubernetes cluster. But for Canary deployments you need a smart service layer that can gradually shift traffic to the canary pods while still keeping the rest of the traffic to the old/stable pods.

Argo Rollouts supports several service meshes and gateways for this purpose.

The Argo Rollouts controller will only activate if a change happens in a Rollout resource.

Automated Rollbacks with Metrics
Argo Rollouts offers the powerful capability to look at application metrics and decide automatically if the deployment should continue or not.

The idea behind this approach is to completely automate canary deployments. Instead of having a human running manual smoke tests, or looking at graphs, you can set different thresholds that define if a deployment is “successful” or not.

Argo Rollouts already supports several metric providers such as Prometheus, DataDog, NewRelic, Cloudwatch, etc.

To take advantage of metric evaluation, Argo Rollouts introduces the concept of Analysis. An Analysis is deployed along with your Rollout and defines the thresholds for metrics.

Example:

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  args:
  - name: service-name
  metrics:
  - name: success-rate
    interval: 2m
    count: 2
    # NOTE: prometheus queries return results in the form of a vector.
    # So it is common to access the index 0 of the returned array to obtain the value
    successCondition: result[0] >= 0.95
    provider:
      prometheus:
        address: http://prom-release-prometheus-server.prom.svc.cluster.local:80
        query: sum(response_status{app="{{args.service-name}}",role="canary",status=~"2.*"})/sum(response_status{app="{{args.service-name}}",role="canary"}

This prometheus analysis says that :

    A metric of response status (200 responses vs total) will be fetched for Prometheus.
    If this results in more than 0.95, the deployment will continue with success.
    If the result is less than 0.95, then the canary will fail and the whole deployment will be rolled back automatically.

Using Argo Rollouts & Argo CD:

Argo Rollouts is an independent project that can work on its own. It also works great with Argo CD. Argo Rollouts will react to any manifest change regardless of how the manifest was changed.

Example: Create an Argo Rollout application declaratively with the following Argo CD application:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: canary-demo
spec:
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: demo
  project: default
  source:
    repoURL: 'https://github.com/kostis-codefresh/summer-of-k8s-app-manifests'
    path: ./
    targetRevision: HEAD

Both Argo Rollouts and Argo CD can work fine on their own. You don’t need to install Argo CD in order to use Argo Rollouts (a very common misconception).

Monitor canary deployment:  watch command

kubectl argo rollouts get rollout simple-rollout --watch

Quiz: Progressive Delivery:

1) What is Progressive Delivery?
A) A way to gradually deploy applications minimizing downtime
2) What is Argo Rollouts
A) A Kubernetes controller for progressive delivery
3) What is the relationship between Argo CD and Argo Rollouts
A) Argo CD and Argo Rollouts can either be deployed individually or both at the same time.
4) What are Blue/Green deployments?
A) A deployment method where the new version is launched while the old version is still running. Both version exist during the deployment
5) What are Canary deployments
A) A deployment method where only a subset of live users get access to the new version of the application
6) How does Argo Rollout work?
A) You need to convert your Kubernetes Deployment to a Rollout resource to enable progressive delivery

Argo CD usage:

1. If you have enabled the "auto-sync" option in an Argo CD application and something is changed manually in the cluster, then Argo CD will automatically discard the change.
A) false
2. If you have enabled the "auto-sync" option in an Argo CD application and you delete a resource in Git, then Argo CD will automatically delete that resource from the cluster as well.
A) false
3. What is the proper way to handle application secrets via GitOps?
A) Encrypt them and store them in Git. Then decrypt them during runtime.
4. If you use Bitnami Sealed Secrets, then where does encryption and decryption take place?
A) Encryption happens via the kubeseal executable. Decryption happens via the Sealed Secrets controller.
5. You have just logged in the Argo CD UI and created an application using a Git repository that holds your Helm chart. You sync the application, and everything is fine. What is the next step that you should take?
A) Create a declarative file of the application and other resources (e.g. Argo CD project) used and store them in Git.
6. You just created a Helm application using the Argo CD web interface. Now you go the command line and you enter helm list. To your surprise nothing is printed.
A) The helm command will never work no matter what you do in Argo CD
7. What kind of applications can Argo CD deploy?
A) ArgoCD can deploy all of the above

GitOps Fundamental test:

1)  What is GitOps?

2)  How are GitOps and DevOps related?

3)  Is the following statement true or false?

4)  What is the major advantage of GitOps?

5)  What is a major disadvantage of GitOps?

6)  What is Argo CD?

7)  Which other Argo products, Argo CD needs to function correctly?

8)  How can you install Argo CD on your cluster?

9)  Is the following statement true or false?

10) Is the following statement true or false?

11) What is the proper way to handle application secrets via GitOps?

12) You have just logged in the Argo CD UI and created an application using a Git repository that holds your Helm chart. You sync the application and everything is fine. What is the next step that you should take?

13) You just created a Helm application using the Argo CD web interface. You then go to the command line and enter "helm list". To your surprise nothing is printed.

14) What kind of applications can Argo CD deploy?

15) What is Argo Rollouts

16) What is the relationship between Argo CD and Argo Rollouts

17) What are Blue/Green deployments?

18) What are Canary deployments

19) How does Argo Rollout work?

20) What is Progressive Delivery?

21) If you use Bitnami Sealed Secrets then where does encryption and decryption take place?

22) What is the relationship between the Argo CD Web interface and the Argo CD Command line executable?

23) How does Argo CD interact with clusters?

───────── Credits to: codefresh.io ─────────

Tags: gitops, what is gitops, gitops vs devops, gitops kubernetes, argo gitops, gitlab gitops, gitops course, gitops model, gitops principles, gitops workflow,kubernetes gitops, argocd gitops, devops gitops, gitops approach, gitops argocd, gitops best practices, gitops for kubernetes, argo cd,what is argo cd, argo cd kubernetes, free certification, free IT certifications online

DISCLAIMER

The purpose of sharing the content on this website is to Educate. The author/owner of the content do not warrant that the information provided on this website is fully complete and shall not be responsible for any errors or omissions.The author/owner shall have neither liability nor responsibility to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the contents of this website. So, use the content of this website at your own risk.

This content has been shared under Educational And Non-Profit Purposes Only. No Copyright Infringement Intended, All Rights Reserved to the Actual Owner.

For Copyright Content Removal Please Contact us by Email at besttechreads[at]gmail.com