Workshop Production - Pushing to Production

Firstly, ensure that you’re currently using the vote-app-ci-%USERID% project. This is where our pipeline manifests have been created and where we’ll run the Pipeline from.

Within the Pipelines dashboard, we can select the promote-to-prod pipeline to see the details of the Pipeline.

Here, you can review the pipeline steps and see what each step is doing. You can also see the pipeline resources that are being used. In addition, you can see the pipeline parameters that are being used. These parameters are used to pass in the name of the image that will be built and the name of the image that will be pushed to the registry. For reference, here are the pipeline steps:

Now, let’s go ahead and start the Pipeline. Click on the top-right Actions and then the Start button to start the Pipeline. The steps are the same as the previous pipelines so we won’t go through them again.

You will be prompted to enter the values for the pipeline parameters. However, the default values are already set for you. At the bottom of the menu, we can specify an Empty Directory for the app-source parameter. This is because we’re not building the application from the source; we’re using the image that was built in the dev project. Click on the Start button to start the Pipeline.

Now that the promote-to-prod PipelineRun has been started, let’s go ahead and check the status of the Pipeline.

Once the Pipeline has been completed, you’ll notice that the vote-app-gitops repo has been updated with a new hash of an image. This is the image that was built in the dev project, pushed to the prod project, and referenced in the environments/prod/kustomization.yaml file that can be found here.

Let’s head to the Argo CD dashboard, and click on the + New App button to begin creating our production application.

Fill in the following information, many of which may auto-fill when selected:

When finished, click the CREATE button in the top left-hand corner to create the application. You will be taken to the application details page. Here, you can see the application’s health, sync status, and associated resources. Currently, the application is syncing, so the status is OutOfSync. Once the application is synced, the status will change to a green Synced.

Argo CD has a feature called Syncwaves, which allows you to deploy applications in a staggered fashion. This is useful when you have multiple applications that are dependent on each other and you want to deploy them in a specific order. For example, you may have a database application you want to deploy first, then your application depends on the database. SyncWaves can deploy the database application first, then the application that depends on the database.

In our case, we see SyncWaves in action, as we need the vote-api to be deployed before vote-ui. Let’s visit the vote-app-gitops production kustomization.yaml file here.

With our configuration currently, SyncWaves allow for a controlled rollout of resources by setting a sequence in which they should be deployed. In this case, we have multiple resources, vote-api and vote-ui. The vote-api resources have syncwaves of 0 and 1, whereas the vote-ui resources have a syncwave of 2, 3, and 4. This means that the vote-api resource will be deployed first, then the vote-ui resource will be deployed second.

Now that the application has been deployed to production let’s go ahead and view the application in the OpenShift console. Click on the Developer perspective, then select the Topology view. Ensure you’re in the vote-app-prod-%USERID% project, and you should see the application deployed.

Click on the vote-ui deployment, and click Details to see the deployment details. Here, you see how Argo CD will auto-detect drift in the application. Let’s go ahead and change the number of replicas to 2 and see how Argo CD detects the drift and auto-heals.

Almost immediately after scaling up the replicas for the vote-ui deployment, Argo CD notices this drift and auto-corrects us back to 1 replicas. Pretty neat!

Now, let’s go ahead and make a change to the application. We’ll change the number of replicas to 2 and see how Argo CD detects the drift and auto-heals. To do this, let’s go ahead and modify the environments/prod/kustomization.yaml file in the vote-app-gitops repository here. Now, within the Code tab, click on the Edit button to edit within the web page.

Change the number of replicas on line 4 to 2, then navigate to the Commit changes section at the bottom of the page. Here, we can select Create a new branch for this commit and start a pull request. We will create a new branch, %USERID%-feature-ha and start a pull request to merge the changes into the main branch. This can be helpful if we want to easily roll back changes to our cluster using GitOps. Click on the Propose file change button to create the pull request.

You will be taken to the New Pull Request page. Here, you can see the changes that were made to the file, just changing the replicas of the vote-ui deployment. Click on the New Pull Request button to create the pull request.

Here, you can see the pull request details; to save time, we can skip adding details to this PR. Select the Create Pull Request button to create the pull request.

With the new pull request created, let’s go ahead and merge the pull request into the main branch, where Argo CD is currently tracking our repository. Click the Create merge commit button to merge the pull request.

Now, let’s go ahead and check the application status in the OpenShift Web Console. Select the Developer perspective, then click on the Topology view. Ensure you’re in the vote-app-prod-%USERID% application, and you should see the vote-ui deployed, now with 2 replicas.

Click on the vote-ui deployment, and click Details to see the deployment details. Here, you see how Argo CD will auto-detect drift in the application. Let’s go ahead and change the number of replicas to 1 and see how Argo CD detects the drift and auto-heals.

Automatically, the application will sync, and we cannot keep the vote-ui pod replicas at 1. Argo CD uses the manifests in the vote-app-gitops repository and Git as the single source of truth, detecting these application drifts and keeping our resource at 2 replicas. We can also see this in Argo CD, where auto sync is enabled.

In this section, we learned how to use OpenShift GitOps to deploy an application from a development to a production environment and how to use Argo CD to detect drift in the application and ensure high availability.