Open in app

Sign in

Write

Sign in

How ArgoCD’s Advanced Features Streamline Application Deployment and Management

Riyaz S
19 min readMar 21, 2023

--

If you would like to skip the theoretical explanations please feel free to scroll down to the actual configurations and where do the testings!!

Overview

Argo CD is a popular and powerful open-source continuous delivery tool that automates the deployment of applications to Kubernetes clusters. Developed by the Argo community, the tool simplifies the deployment process and ensures that the deployment is consistent across different environments. In this blog, we will discuss the installation of Argo CD and the steps to create a project, followed by an example of a sample application deployment.

What is Argo CD?

Argo CD is a declarative, GitOps continuous delivery tool that provides a simple, automated, and auditable way to deploy applications to Kubernetes clusters. It automates the deployment process by using the GitOps methodology, which is based on the idea of using Git as a source of truth for application configurations and definitions. The tool uses Git repositories to store the application manifests and tracks changes made to the manifests to ensure that the deployed applications are always in sync with the desired state.

Features of Argo CD

Argo CD comes with a range of features that make it a popular choice for continuous delivery. Some of the key features of Argo CD are:

  • Declarative Configuration: Argo CD uses a declarative approach to deployment, which means that it maintains a desired state for the application and automatically reconciles any deviations from the desired state.
  • GitOps Methodology: Argo CD follows the GitOps methodology, which makes it easy to version control and audit changes to the application deployment configurations.
  • Application Synchronisation: Argo CD continuously monitors the Git repository for changes and ensures that the deployed application is in sync with the latest changes in the repository.
  • Rollbacks: Argo CD provides a simple way to rollback to a previous version of the application in case of any issues or errors.
  • Multi-cluster Management: Argo CD allows the management of multiple Kubernetes clusters from a single control plane, simplifying the deployment process and ensuring consistency across different environments.
  • Customisable Deployment Strategies: Argo CD provides a range of deployment strategies such as Blue/Green, Canary, and Progressive deployment, which can be customized to suit the specific needs of the deployment.

Installation Methods

Argo CD can be installed in several ways, including using kubectl, using a Helm chart, or running it as a container. In this tutorial, we will use the kubectl installation method.

*Using a Helm chart

Argo CD also provides a Helm chart that simplifies the installation process. Helm is a package manager for Kubernetes that allows you to deploy applications using pre-configured templates called charts. To install Argo CD using the Helm chart, you can follow these steps:

Add the Argo CD Helm repository:

helm repo add argo https://argoproj.github.io/argo-helm

Update your local Helm chart repository cache:

helm repo update

Install Argo CD using the Helm chart:

helm install argocd argo/argo-cd

Verify that the Argo CD pods are running:

kubectl get pods -n argocd

*Running as a container

Argo CD can also be run as a container using Docker or another container runtime. This method is useful for development environments or when you need to test a new version of Argo CD before upgrading your production environment. To run Argo CD as a container, you can follow these steps:

Pull the Argo CD Docker image:

docker pull argoproj/argocd:latest

Run the Argo CD container:

docker run -p 8080:8080 -p 8081:8081 argoproj/argocd:latest

*Using kubectl

The kubectl installation method involves creating Kubernetes resources by applying YAML manifests. This method requires the installation of kubectl on your local machine. You can download kubectl from the Kubernetes official website.

To install Argo CD using kubectl, you can follow these steps:

Step 1: Create a Namespace

First, we need to create a namespace where we will install Argo CD. You can create a namespace using the following command:

kubectl create namespace argocd

Step 2: Install Argo CD

Next, we need to install Argo CD in the argocd namespace. You can install Argo CD using the following command:

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

This command will create several resources in the argocd namespace, including a deployment, service, and ingress.

Step 3: Expose Argo CD Service

To access Argo CD, we need to expose the service using a forward service. You can create a forward service using the following command:

kubectl port-forward svc/argocd-server -n argocd 8080:443

This command will create a forward service on port 8080 that forwards traffic to the argocd-server service in the argocd namespace.

Step 4: Get the Root Password

To log in to Argo CD, we need to get the root password. You can get the root password using the following command:

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

This command will retrieve the root password and decode it from base64 encoding.

Step 5: Log in to Argo CD

Now that we have the root password, we can log in to Argo CD using the web interface. Open a web browser and navigate to http://localhost:8080. You should see the Argo CD login page.

Enter the username as admin and the password obtained from the previous step.

Congratulations! You have successfully installed and logged in to Argo CD. Now We are going to setup a sample project & application in argocd…..

What is an ArgoCD Project?

An Argo CD project is a logical grouping of Kubernetes resources that are managed together by Argo CD. It is a way to organize your application and its related resources, such as ConfigMaps, Secrets, Deployments, and Services. Projects can be used to control access to specific resources and to enable different teams to manage different parts of an application, which can help you to enforce security best practices.

ArgoCD projects provide the following benefits:

  • They allow you to organize applications and their resources based on their requirements.
  • You can define policies to control access to resources and manage them easily.
  • They allow you to have multiple teams working on different applications within the same cluster.

We can create a new project by following these steps:

Using GUI

the left navigation bar, click on the ‘Settings’ icon. This will direct you to the Settings page, where you can add or remove Git repositories.

On the Settings dashboard, click the option called “Projects”. This opens the Repository management page.

To Create a new project, click the “New Project” button at the top of the screen.

Enter a name for your project. Again, Enter the description that reflects the purpose of your project.

Sync Policy: This determines how often Argo CD will check for updates to your application. The default value is Automatic, which means that Argo CD will automatically synchronize your application with the desired state whenever a change is detected.

Click on the CREATE button to create your new project and application.

Once your project is created, you can start adding resources to it. To add resources, you can either use the Argo CD web interface or define them in a Kubernetes manifest file and then deploy them to your cluster.

Managing an Argo CD Project

Once your Argo CD project is created, you can manage it using the Argo CD web interface. From the web interface, you can view the status of your application, update its configuration, and deploy new versions.

You can also use GitOps to manage your Argo CD project. GitOps is a popular approach to managing infrastructure and applications using Git repositories as the source of truth. With GitOps, you can define your application configuration as Kubernetes manifests and commit them to a Git repository. Argo CD can then monitor the Git repository and automatically deploy updates to your application whenever a change is detected.

here’s an example of a manifest file for an Argo CD project:

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: my-project
spec:
  destination:
    namespace: my-namespace
    server: https://kubernetes.default.svc
  sourceRepos:
  - https://github.com/my-org/my-repo.git
  clusterResourceWhitelist:
  - group: apps/v1
    kind: Deployment
  - group: v1
    kind: Service
  roles:
  - name: my-role
    policies:
    - policy: default
    role: admin

Let’s go through this manifest file line by line:

  • apiVersion: argoproj.io/v1alpha1: This specifies the API version of the Argo CD AppProject resource.
  • kind: AppProject: This specifies the type of the resource, which is an Argo CD project.
  • metadata: name: my-project: This sets the name of the project to my-project.
  • spec: destination: namespace: my-namespace server: https://kubernetes.default.svc: This specifies the destination namespace for the project, which is my-namespace, and the Kubernetes server to use, which is the default server.
  • sourceRepos: - https://github.com/my-org/my-repo.git: This specifies the Git repository where the project's configuration is stored. In this case, it is stored in the https://github.com/my-org/my-repo.git repository.
  • clusterResourceWhitelist: - group: apps/v1 kind: Deployment - group: v1 kind: Service: This specifies the list of resources that the project is allowed to manage. In this case, it is allowed to manage Deployments and Services.
  • roles: - name: my-role policies: - policy: default role: admin: This specifies the role-based access control (RBAC) settings for the project. In this case, it defines a role called my-role with the admin role and the default policy.

By defining a manifest file like this, you can easily create and manage Argo CD projects using configuration as code. You can then use tools like GitOps to version control and manage your project configurations.

Deploy a Sample App

By default, your ArgoCD instance will have no applications deployed. After logging in, the Applications dashboard will be empty. The first step is to connect a new git repository with your ArgoCD instance, so you can create an application using the repository. In this blog, we are going to use the public repository with sample application that ArgoCD project provides: https://github.com/rYz-DevOps/rYz-DevOps.git

Add A New Git Repository

Using the left navigation bar, click on the ‘Settings’ icon. This will direct you to the Settings page, where you can add or remove Git repositories.

On the Settings dashboard, click the first option called “_Repositories_”. This opens the Repository management page.

To attach a new Git Repository, click the “_Connect repo using HTTPS_” button at the top of the screen.

Within the slide out form, enter the following information to attach the ArgoCD Example App repository:

Then, click ‘Connect’ in the slide out form header. The sample apps repository is now connected to your ArgoCD instance, and you are ready to deploy your first sample application.

Deploy sample nginx-app

*Using UI

In this blog, we will deploy the sample nginx-app from the repository. To deploy the app, use the left-hand menu and click on the “_Applications_” menu option.

Next, on the Application dashboard, click the ‘New App’ button in the header.

The slide out form has three major sections, General (Application setup), Source (Application Repository) and Destination (the target Cluster). Fill out the form with the following information:

General

  • Application Name: nginx-app
  • Project: default
  • Sync Policy: Select “Automatic” for sync policy. Then enable “Prune Resources” and “Self Heal” by clicking on the checkboxes.

Source

  • Repository URL: Click and select the repository added above
  • Revision: argocd
  • Path: argocd/deployments/nginx

Destination

First, select “_Cluster Name_” instead of “_Cluster URL_” as the destination by clicking on the dropdown list at then end of the Cluster URL input field.

Then, specify the following inputs:

  • Cluster URL: Specify the Kubernetes cluster svc url eg : https://kubernetes.default.svc that you’d like to deploy the nginx-app on.
  • Namespace: Default (or select any target namespace on the Kubernetes cluster where you wish to deploy the app)

Deploy the App

To deploy the app, click ‘Create’ in the slide out form header.

View Application Deployment

The application deployment will be visible immediately on the Application dashboard. To view the details of the application deployment, click on the application card.

That’s it! Your first sample application is deployed using ArgoCD, and ArgoCD is now managing this application.

Using kubectl

We Can also Deploy the sample nginx-app in the argocd using the following command:

kubectl apply -f https://raw.githubusercontent.com/rYz-DevOps/rYz-DevOps/argocd/argocd/child-app/nginx-app.yaml

This command will create nginx namespace & its resources, including a deployment and service.

here’s an example of a manifest file for an Argo CD App:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: nginx-app
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: default
  source:
    repoURL: https://github.com/rYz-DevOps/rYz-DevOps.git
    targetRevision: argocd
    directory:
      recurse: true
    path: argocd/deployments/nginx/
  destination:
    server: https://kubernetes.default.svc
    namespace: nginx
  syncPolicy:
    automated:
      selfHeal: true
      prune: true
    syncOptions:
    - Validate=true
    - CreateNamespace=true
  • apiVersion: The version of the Argo CD API that this manifest uses.
  • kind: The Kubernetes kind of the resource, which in this case is an Application.
  • metadata: Contains metadata for the Application resource, including its name, namespace, and finalizers.
  • name: The name of the Application resource.
  • namespace: The namespace in which the Application resource will be created.
  • finalizers: Specifies one or more finalizers that are run when the resource is deleted, in order to clean up any resources associated with it.
  • spec: Specifies the configuration for the Application resource.
  • project: The name of the Argo CD project that this Application belongs to. In this case, it is set to the default project.
  • source: Specifies the source of the application, which is a Git repository.
  • repoURL: The URL of the Git repository where the application source code is stored.
  • targetRevision: The Git branch, tag, or commit hash to deploy.
  • directory: The directory path within the Git repository where the application manifests are located.
  • recurse: Specifies whether to include all subdirectories within the specified directory path.
  • path: The path within the Git repository to the folder containing the application manifests to be deployed.
  • destination: Specifies the destination of the deployment.
  • server: The URL of the Kubernetes API server to deploy to.
  • namespace: The Kubernetes namespace to deploy the application to.
  • syncPolicy: Specifies the synchronization policy for the Application resource.
  • automated: Specifies that synchronization should be automated.
  • selfHeal: If true, Argo CD will attempt to self-heal resources to match their desired state.
  • prune: If true, Argo CD will delete any resources that are not defined in the Git repository.
  • syncOptions: Additional options to pass to kubectl apply during synchronization.
  • Validate=true: Performs validation on the manifests before applying them to the Kubernetes cluster.
  • CreateNamespace=true: Creates the namespace if it does not already exist.

SyncWaves and Hooks

Syncwaves are used in Argo CD to order how manifests are applied to the cluster.

On the other hand resource hooks breaks up the delivery of these manifests in different phases.

Using a combination of syncwaves and resource hooks, you can control how your application rolls out.

This example will take you through the following steps:

  • Using Syncwaves to order deployment
  • Exploring Resource Hooks
  • Using Syncwaves and Hooks together

Using Sync Waves

A Syncwave is a way to order how Argo CD applies the manifests that are stored in git. All manifests have a wave of zero by default, but you can set these by using the argocd.argoproj.io/sync-wave annotation.

When you deploy an application, Argo CD synchronizes all the Kubernetes resources defined in the application YAML files to the target cluster. By default, Argo CD synchronizes all the resources in parallel. However, in some cases, you may want to synchronize resources in a specific order, to ensure that dependencies are met before the next resource is synchronized.

The syncWave field allows you to define a set of rules for how resources are synchronized. The count field specifies the number of waves to use, and the max field specifies the maximum percentage of resources that can be synchronized in each wave. The wait field specifies the time to wait between each wave.

For example, suppose you have a set of resources that include a database deployment and a web application deployment. The web application deployment depends on the database deployment, so you need to ensure that the database deployment is synchronized to the cluster before the web application deployment. You can define a syncWave with a count of 2, a max of 30%, and a wait of 2 seconds, like this:

Example:

metadata:
  annotations:
    argocd.argoproj.io/sync-wave: "2"

The wave can also be negative as well.

metadata:
  annotations:
    argocd.argoproj.io/sync-wave: "-5"

When Argo CD starts a sync action, the manifest get placed in the following order:

  • The wave the resource is annotated in (starting from the lowest value to the highest)
  • By kind (Namespaces first, then services, then deployments, etc …​)
  • By name (ascending order)

Read more about syncwaves on the official documentation site.

Exploring the Manifests

wordpress-deployment.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: wordpress
  annotations:
    argocd.argoproj.io/sync-wave: "-1"
---
apiVersion: v1
kind: Service
metadata:
  name: wordpress
  annotations:
    argocd.argoproj.io/sync-wave: "1"
  labels:
    app: wordpress
spec:
  ports:
  - port: 80
    targetPort: 80
  selector:
    app: wordpress
  type: LoadBalancer
---
apiVersion: v1
kind: Service
metadata:
  name: mysql
  annotations:
    argocd.argoproj.io/sync-wave: "0"
  labels:
    app: mysql
spec:
  ports:
  - port: 3306
  selector:
    app: mysql
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: wordpress
  annotations:
    argocd.argoproj.io/sync-wave: "1"
spec:
  replicas: 1
  selector:
    matchLabels:
      app: wordpress
  template:
    metadata:
      labels:
        app: wordpress
    spec:
      containers:
      - name: wordpress
        image: wordpress:latest
        ports:
        - containerPort: 80
        env:
        - name: WORDPRESS_DB_HOST
          value: mysql
        - name: WORDPRESS_DB_USER
          value: root
        - name: WORDPRESS_DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql
              key: password
        - name: WORDPRESS_DB_NAME
          value: wordpress
      imagePullSecrets:
        - name: mysql
         
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql
  annotations:
    argocd.argoproj.io/sync-wave: "0"
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: arm64v8/mysql:latest
        env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql
              key: password
        - name: MYSQL_DATABASE
          value: wordpress
        ports:
        - containerPort: 3306
        volumeMounts:
        - name: mysql-persistent-storage
          mountPath: /var/lib/mysql
      volumes:
      - name: mysql-persistent-storage
        persistentVolumeClaim:
          claimName: mysql-pv-claim
      imagePullSecrets:
        - name: mysql
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pv-claim
  annotations:
    argocd.argoproj.io/sync-wave: "0"
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

Don’t forget to create a Secret for this Wordpress application

apiVersion: v1
kind: Secret
metadata:
  name: mysql
  namespace: 
type: Opaque
data:
  password: cGFzc3dvcmQ=

We Can Deploy the sample wordpress-app in the argocd using the following command:

kubectl apply -f https://raw.githubusercontent.com/rYz-DevOps/rYz-DevOps/argocd/argocd/syncWave/wordpress-app.yaml

This command will create a WordPress namespace and its associated resources, followed by its syncwave weightage. So you can watch it!!!!!

New wordpress app will created

Click on it !!!

Argo CD will apply the Namespace first (since it’s the lowest value), and make sure it returns a “healthy” status before moving on.

Next, the mysql Deployment will be applied. After that reports healthy will continue with the rest of resources.

Argo CD won’t apply the next manifest until the previous reports “healthy”.

Check your cluster!!!

kubectl get all -n wordress

Exploring Resource Hooks

Now that you’re familiar with syncwaves, we can begin exploring applying manifests in phases using resource hooks.

Controlling your sync operation can be further redefined by using hooks. These hooks can run before, during, and after a sync operation. These hooks are:

  • PreSync — Runs before the sync operation. This can be something like a database backup before a schema change
  • Sync — Runs after PreSync has successfully ran. This will run alongside your normal manifests.
  • PostSync — Runs after Sync has ran successfully. This can be something like a Slack message or an email notification.
  • SyncFail — Runs if the Sync operation as failed. This is also used to send notifications or do other evasive actions.

To enable a sync, annotate the specific object manifest with argocd.argoproj.io/hook with the type of sync you want to use for that resource. For example, if I wanted to use the PreSync hook:

metadata:
  annotations:
    argocd.argoproj.io/hook: PreSync

You can also have the hooks be deleted after a successful/unsuccessful run.

  • HookSucceeded — The resource will be deleted after it has succeeded.
  • HookFailed — The resource will be deleted if it has failed.
  • BeforeHookCreation — The resource will be deleted before a new one is created (when a new sync is triggered).

You can apply these with the argocd.argoproj.io/hook-delete-policy annotation. For example

metadata:
  annotations:
    argocd.argoproj.io/hook: PostSync
    argocd.argoproj.io/hook-delete-policy: HookSucceeded

Since a sync can fail in any phase, you can come to a situation where the application never reports healthy!

Although hooks can be any resource, they are usually Pods and/or Jobs.

To read more about resource hooks, consult the official documentation

Exploring Manifests

apiVersion: batch/v1
kind: Job
metadata:
  name: one-time-job
  annotations:
    argocd.argoproj.io/hook: PostSync 
    argocd.argoproj.io/hook-delete-policy: HookSucceeded
spec:
  template:
    spec:
      containers:
        - name: my-container
          image: busybox
          command: ["echo", "Hello, world!"]
      restartPolicy: Never

This means that this Job will run in the PostSync phase, after the application of the manifests in the Sync phase.

This job will deleted after completion.

Create Single Master Application To Manage Multiple Applications In Argo CD

Since Argo CD’s job is to listen to a repo and apply the Manifest files it finds to the cluster, you can use this approach to configure Argo CD internals as well. In my previous example, I used the GUI to create a sample Nginx application. This time, I use the same approach as before, but I create an application from the GUI to deploy two separate applications nginx-app and and guestbook-app.

Configuring our child application

First, start by creating the Manifest files for your two applications. In my rYz-DevOps repository, I have created two applications underargocd/deployments/.

Create a YAML files to define the first child deployment and save it as argocd/deployments/guestbook/guestbook-ui.yamletc..

apiVersion: apps/v1
kind: Deployment
metadata:
  name: guestbook-ui
spec:
  replicas: 1
  revisionHistoryLimit: 3
  selector:
    matchLabels:
      app: guestbook-ui
  template:
    metadata:
      labels:
        app: guestbook-ui
    spec:
      containers:
      - image: gcr.io/heptio-images/ks-guestbook-demo:0.2
        name: guestbook-ui
        ports:
        - containerPort: 80
apiVersion: v1
kind: Service
metadata:
  name: guestbook-ui
spec:
  ports:
  - port: 80
    targetPort: 80
  selector:
    app: guestbook-ui
apiVersion: v1
kind: Namespace
metadata:
  name: guestbook
  annotations:
    argocd.argoproj.io/sync-wave: "-1"

Create another one for your second deployment and save it as argocd/deployments/nginx/nginx-deployment.yaml:etc…

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: test-app
  name: test-deployment
  namespace: 
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: test-app
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: test-app
    spec:
      containers:
      - image: nginx:latest
        imagePullPolicy: Always
        name: test-app
        ports:
        - containerPort: 80
          protocol: TCP
        resources: {}
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
---
apiVersion: v1
kind: Namespace
metadata:
  name: nginx
  annotations:
    argocd.argoproj.io/sync-wave: "-1"
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  type: ClusterIP
  selector:
    app: test-app
  ports:
    - name: http
      port: 80
      targetPort: 80

Now that your Manifest files are ready. You must create Argo CD Applications pointing to those Manifests.

Argo CD can be configured in three different ways: using the GUI, using the CLI, or using Kubernetes Manifest files. In this blog, I use the third method.

Create the following Manifest files in a new folder argocd/child-app/. This is argocd-apps/nginx-app.yml:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: nginx-app
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: default
  source:
    repoURL: https://github.com/rYz-DevOps/rYz-DevOps.git
    targetRevision: argocd
    directory:
      recurse: true
    path: argocd/deployments/nginx/
  destination:
    server: https://kubernetes.default.svc
    namespace: nginx
  syncPolicy:
    automated:
      selfHeal: true
      prune: true
    syncOptions:
    - Validate=true
    - CreateNamespace=true

This is child-app/guestbook-app.yaml:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook-app
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: test-dev
  source:
    repoURL: https://github.com/rYz-DevOps/rYz-DevOps.git
    targetRevision: argocd
    directory:
      recurse: true
    path: argocd/deployments/guestbook/
  destination:
    server: https://kubernetes.default.svc
    namespace: guestbook
  syncPolicy:
    automated:
      selfHeal: true
      prune: true
    syncOptions:
    - Validate=true

As you can see, you are creating a Kubernetes object called Application in the argocd namespace. This object contains the source Git repository and destination server details. Your Applications are pointing to the deployment manifest files you created earlier.

Configuring our master application

Now you need some way to tell Argo CD how to find your Nginx and guestbook applications. Do this by creating yet another Application. This pattern is called the App of Apps pattern, where one Application contains the instructions to deploy multiple child Applications.

Create a new Master Application from the GUI called master-app with the following configuration:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: master-app
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: default
  source:
    repoURL: https://github.com/rYz-DevOps/rYz-DevOps.git
    targetRevision: argocd
    directory:
      recurse: true
    path: argocd/child-app/
  destination:
    server: https://kubernetes.default.svc
    namespace: argocd
  syncPolicy:
    automated:
      selfHeal: true
      prune: true
    syncOptions:
    - Validate=true

Once it has been created, master-app begins syncing in the GUI:

After the sync is complete, your three Nginx and guestbook applications appear in the GUI as well:

You can also use this kubectl command for deploy Apps of Apps setup without help of GUI

kubectl apply -f https://raw.githubusercontent.com/rYz-DevOps/rYz-DevOps/argocd/argocd/master-app/master-app.yaml

Mastering the App of Apps pattern in ArgoCD is a game-changer for businesses looking to automate their deployment processes and manage applications more effectively. This pattern involves creating a central repository of applications and a set of automated deployment workflows that can be used to deploy applications across different environments.

In conclusion, ArgoCD is a powerful tool that can help businesses streamline their deployment processes and manage their applications more effectively. With its advanced features and capabilities, ArgoCD enables teams to automate their workflows, reduce the risk of errors, and achieve faster and more reliable deployments.One of the most significant benefits of ArgoCD is its ability to automate deployment workflows through the use of GitOps. This approach allows teams to define their desired application state in Git, which ArgoCD then uses to automatically configure the target environment. This reduces the need for manual intervention and ensures that the desired state is always maintained, even as the application evolves over time.

ArgoCD also provides a range of features that make it easy to manage and deploy applications across different environments. This includes support for multiple deployment strategies, rollback capabilities, and automated health checks, among other things. These features enable teams to deploy their applications with confidence and ensure that they are always running smoothly and reliably.Furthermore, ArgoCD is an open-source tool with a vibrant community of contributors and users. This means that businesses can benefit from a wide range of resources and support, including documentation, tutorials, and forums.

Overall, ArgoCD is a versatile and powerful tool that can help businesses achieve faster and more reliable deployments while reducing the risk of errors. With its advanced features, support for GitOps, and active community, ArgoCD is an excellent choice for businesses looking to take their deployment processes to the next level…

Argo Cd
Kubernetes
DevOps
Gitops

--

--

Riyaz S

Written by Riyaz S

2 Followers

DevOps Engineer

Help

Status

About

Careers

Press

Blog

Privacy

Terms

Text to speech

Teams