Overview
In this blog, we will explore how to create an Application in IBM DevOps Deploy that will interact with an Argo CD project to help you deploy updates in a controlled manner with all the proper governance controls and team-based security that you leverage today in IBM DevOps Deploy.
This blog assumes that you have an Argo CD Server setup in a Kubernetes cluster. It also assumes that you have a Argo CD project that references a source GitHub (or git) repository as well as the destination Kubernetes or OpenShift cluster where you want to deploy your Kubernetes resources. For this blog, we recommend that you set the ‘Sync Policy’ of the Argo CD application to manual.
Further, this blog assumes that you have setup all the perquisites required that are documented in part 1 of this blog series. Please refer to this before continuing to the steps outlined below.
In this blog post, we will take the following steps in IBM DevOps Deploy:
- Create a DevOps Deploy Component based on Argo CD Component Template
- Create a DevOps Deploy Application and add your new Argo-based Component to it.
- Create the Application Process for your new Argo-based DevOps Deploy Application
- Create your Target Environment and Resource Tree
- Create a DevOps Deploy Deployment Trigger
This post does share some additional configuration options that are specific to GitHub, however, IBM DevOps Deploy is easily configured to integrate with other systems as well including GitLab, Bitbucket, and more.
Let’s get started!
Create a Component based on the Argo CD Component Template
First, you will create a new DevOps Deploy component using the Argo CD Component Template. In your browser, connect to your IBM DevOps Deploy web console and click on the ‘Components’ tab at the top of the screen. Then click on the ‘Create Component’ button as shown below:
A ‘Create Component’ dialog will appear. From the Component Template pulldown, select the ‘ArgoCD Template’ and provide a name (in our case, Kubetoy) as shown below:
Scroll down and fill in the required component properties, including:
- argocd.server
- argocd.user
- argocd.password
- argocd.application.name
- argocd.global.flags
- argocd.cmd.path
Specify any required Argo CD CLI global flags in the argocd.global.flags field. The value must include the -config argument in the value field. Use this as your default value:
'--config=../argocd.config'
With this configuration setup, the DevOps Deploy plugin will go up one directory from the Agent working directory and create the argocd.config file there. This is important as multiple Argo CD plugin steps will need to access this file which holds the required authentication information. Alternatively, you could specify a fully qualified path to a folder that the DevOps Deploy Agent has permission to write to. If you have other flags to specify, be sure to specify each global flag on a line of its own if you add other flags.
If the Argo CD CLI is not installed in a directory that is included in the PATH of the DevOps Deploy Agent, specify its location in the argocd.cmd.path property.
Here is an example:
Click Save to complete the step of creating your new component.
Create a DevOps Deploy Application and Add Component
We can now create a DevOps Deploy Application that will be used to deploy your Kubernetes resources via the Argo CD integration. In your DevOps Deploy web console, click on Applications at the top of the page and then click the ‘Create Application’ button. Click the ‘New Application’ menu item that appears as shown below:
A dialog will appear. Provide a name for your application and click ‘Save’ as shown below:
For your new application, add your Argo CD component to the application by clicking on the Component sub-tab and then click the ‘Add Component’ button as shown below:
Select your Argo-based component from the list and click OK. Your application will now include your component. In our case, it is Kubetoy as shown below:
Create a DevOps Deploy Application Process
You will now create an application process for your new DevOps Deploy application. This process will be used to send an application sync request to the Argo CD server when you are ready to perform the deployment in a controlled manner.
For your application, click on the Processes sub-tab and click the ‘Create Process’ button:
A ‘Create Process’ dialog will appear. Provide a name like ‘Deploy Kubetoy’ as shown below:
Click Save to add the new process. The visual process designer will appear. In the Process Design step palette in the left-hand pane, drag the ‘Install Component’ step onto the process pane on the right as shown below:
Once the step is added to the visual design, click on the pencil icon to edit this step.
In the Edit Properties dialog that appears, type ‘Sync and Run Tests’ in the Name field. For the Component pulldown, select your Argo CD component and then select the Component Process. In my case, I selected the Component Process called 'Sync and Run Tests (Template)' as shown below:
Scroll down and click OK. Your application process should now look like this:
Click the ‘Save’ button to save your updates to the application process.
The ‘Sync and Run Tests’ Component Process Explained
Here is an explanation of the process that you just configured. The component process named ‘Sync and Run Tests’ you reference above is included in the Argo CD component template that comes with the plugin. The following screen shot shows the process design:
This component process leverages Argo CD plugin steps found in the step palette in the left-hand pane as shown above.
After authenticating with the Argo CD system, this process will run a ‘App Sync’ step which will invoke the Argo CD CLI to synchronize your Argo CD project. Further, there is a Shell step in the process named ‘Run Tests’ which you can modify to run any test that you would like to use to validate that your Kubernetes application has been deployed successfully.
If the status of the ‘Run Tests’ step is Success, then the ‘Sync and Run Tests’ process will exit with a successful status. If the status of the ‘Run Tests’ step is a Failure, then the ‘App Rollback’ plugin step is called to roll back to the previous application state.
Create the Target Environment and Resource Tree
With the process in place, we now need a target environment to run the process against. In your new application in DevOps Deploy, return to the ‘Environments’ sub-tab and click the ‘Create Environment’ button to create your first target environment:
In this example, we create a target environment named ‘Test’ which where the deployments will be triggered as shown below:
Click the Save button to finish this setup. Your new environment will appear as shown below:
The environment you created will refer to a location that you setup in the global resource tree view. Click on the Resources tab at the top of the page. Configure your resource tree using the highlighted steps below:
Notice that we created a folder called Test and then we add the DevOps Deploy Agent that has access to the Argo CD CLI as a child under the 'Test' folder. Finally, our Argo-based component that we created is then placed under the Agent to finish the resource tree setup.
In the DevOps Deploy web console, return to your new application. Click on the ‘Test’ environment and then click ‘Add Base Resources’ as shown below.
In the dialog that appears, select your resources in the global resource tree. When finished, your environment should be mapped to the resources in the resource tree as shown above.
Create a DevOps Deploy Deployment Trigger
With our application in place, we can now create a new Deployment Trigger that will be invoked whenever a new component version is created for the Argo-based component you just added to the application.
For your target environment in DevOps Deploy (in our example, Test), click on the Configuration sub-tab as shown below:
Select Deployment Triggers in the left-hand pane as shown above as step 2.
Click the ‘Create Deployment Trigger’ button (see below).
In the 'Create Deployment Trigger' dialog that appears, select the DevOps Deploy component and application process that we created earlier as well as the DevOps Deploy user that the process will execute as shown above.
Click Save to complete the setup of the deployment trigger.
Configure GitHub Actions workflow in GitHub Repository
You can create a new GitHub Actions workflow in your GitHub repository that will be triggered when changes are pushed to the main branch of your repository. When triggered, this workflow will cause a new DevOps Deploy component version to be created. When the new component version is added, this in turn will trigger the application process that will perform the deployment. As mentioned earlier, this deployment will invoke an ‘app-sync’ call to the Argo CD CLI which will result in the deployment of the Kubernetes resources defined in your GitHub repository.
To do this, create a new file named .github/workflows/CreateDevOpsDeployCompVersion.yml in your GitHub repository. The content should come from the Example Usage section found in https://github.com/HCL-TECH-SOFTWARE/devops-deploy-createcomponentversion-action.
Update the following input properties from the example with values specific to your DevOps Deploy instance. This includes:
- component – the name or ID of the component in DevOps Deploy
- hostname – the hostname or IP address of the DevOps Deploy Server
- port – the port number for your DevOps Deploy server. The default is 8443.
- authToken – the token value used to authenticate with the DevOps Deploy server. The example uses a secret named DEVOPS_DEPLOY_AUTHTOKEN which is defined in the GitHub repository at Settings->Secrets and variables->Actions.
Here is an example workflow that is fired when changes are pushed to the master branch. You will need to modify that value if your GitHub repository uses a different branch.
Deployment: Update GitHub Repository and DevOps Deploy Triggers Deployment
Everything is now configured so that whenever a change is pushed to the specified branch in your GitHub repository, DevOps Deploy will initiate an application sync request to Argo CD. Behind the scenes, Argo CD will check what changes have been made and then apply them to the destination Kubernetes/OpenShift cluster.
For this example deployment, we will change the replica count of a deployment or statefulset resource file and push the changes to our git repository. When this commit happens, the GitHub workflow is automatically run to create a new DevOps Deploy component version. Verify that the new component version is created as shown below:
Next, verify that the DevOps Deploy application process that invokes the Argo CD application sync request was executed as a result of the deployment trigger you setup for the Test environment. In your application, click on the History sub-tab as shown below:
You should see that a deployment was automatically run. You can view the results of the deployment by clicking the layer cake (the three dots to the right) and then click the ‘View Request’ menu item as shown below:
This will allow you to see all the details of the deployment as shown below:
Finally, you can check your application in the Argo CD UI to verify that the Kubernetes resources were updated to match the change you made in the GitHub repository. For this deployment, you will see that there are now two KubeToy pods displayed in the lower right-hand section of the image below:
Summary
IBM DevOps Deploy is a proven solution that many organization leverage today to ensure their application deployments are scalable, reliable, and with proper governance for a wide range of application types including mainframe applications, traditional applications or new container-based applications.
For existing IBM DevOps Deploy clients that are exploring the use of gitops with Argo CD, there are some business challenges they face. First, proper governance controls such as approvals and proper trail of audit can be a challenge without the use of DevOps Deploy. Second, trying to link automated testing and container scanning into Argo CD on its own is not trivial.
This is where DevOps Deploy and our new Argo CD plugin shine. The integration with DevOps Deploy provides our clients with the ability to control the sync of container updates in a controlled manner and you can easily wire in integrations with testing tools and container scanning with the excellent governance capabilities that you leverage today with IBM DevOps Deploy. In the end, it is a winning combination for our clients.
#IBMDevOpsAutomation
#DevOpsAutomation
#DevOps