Technical Director, Asia Pacific Center of Excellence.
For the past 16 years, Ali has held technical presales, architect and industry
consulting roles in BEA Systems and Oracle across Asia Pacific, focusing on middleware
and application development. Although he pretends to be Thor, his real areas of
expertise are Application Development, Integration, SOA (Service Oriented Architecture)
and BPM (Business Process Management).
Argo CD is a declarative, GitOps
continuous delivery tool for Kubernetes. This says a lot without being too wordy. When you
look at the user guide and features, this brief description probably undersells Argo CD.
Since we didn’t add the certificate, we’ll be warned of potential security risks ahead. To
this, we can add a certificate using Again, we’re in a bit of a hurry, so we’ll just skip
and click ‘Accept the Risk and Continue’.
We’ll now be redirected to Argo CD login page. Let’s retrieve the generated password:
$kubectl get pods -n argocd -l app.kubernetes.io/name=argocd-server -o name | cut-d'/'-f 2
and login with username admin and the retrieved password.
Follow the rest of the instructions in creating
apps via UI. Once the application is created, click on ‘Sync’ and watch the
being deployed as Kubernetes works its way to creating the various resources (deployment,
service, ReplicaSet, pods, etc).
Once the application is deployed, take a moment to poke around the Argo UI and the Kubernetes
resources. Select the guestbook-ui service and click ‘Edit’. Change the service type from
ClusterIP to LoadBalancer and then save. Once the OCI Load Balancer is provisioned, its
IP address appears. Awesome stuff. I pinch myself and make a quick check on OCI Console to
verify the Load Balancer IP just to ensure I’m not imagining this. Nope, I’m not.
From here, you can experiment with other applications such as the sock-shop or using other
such as helm or kustomize.
You can find more examples in this example apps repo.
Argo Rollouts provides additional deployment strategies such as Blue-Green and Canary to
Kubernetes. Let’s dive right into it and follow Rollouts’ getting started
to do a blue-green deployment:
Change the apiVersion from apps/v1 to argoproj.io/v1alpha1
Change the kind from Deployment to Rollout
Add a deployment strategy to the Rollout object
Create a bluegreen.yaml file (copied from the Argo CD documentation and example) on the
apiVersion:argoproj.io/v1alpha1kind:Rolloutmetadata:name:rollout-bluegreenspec:replicas:2revisionHistoryLimit:2selector:matchLabels:app:rollout-bluegreentemplate:metadata:labels:app:rollout-bluegreenspec:containers:-name:rollouts-demoimage:argoproj/rollouts-demo:blueimagePullPolicy:Alwaysports:-containerPort:8080strategy:blueGreen:# activeService specifies the service to update with the new template hash at time of promotion.# This field is mandatory for the blueGreen update strategy.activeService:rollout-bluegreen-active# previewService specifies the service to update with the new template hash before promotion.# This allows the preview stack to be reachable without serving production traffic.# This field is optional.previewService:rollout-bluegreen-preview# autoPromotionEnabled disables automated promotion of the new stack by pausing the rollout# immediately before the promotion. If omitted, the default behavior is to promote the new# stack as soon as the ReplicaSet are completely ready/available.# Rollouts can be resumed using: `kubectl argo rollouts promote ROLLOUT`autoPromotionEnabled:false---kind:ServiceapiVersion:v1metadata:name:rollout-bluegreen-activespec:type:LoadBalancerselector:app:rollout-bluegreenports:-protocol:TCPport:80targetPort:8080---kind:ServiceapiVersion:v1metadata:name:rollout-bluegreen-previewspec:type:LoadBalancerselector:app:rollout-bluegreenports:-protocol:TCPport:80targetPort:8080
and let’s deploy it:
$kubectl apply -f bluegreen.yaml
Verify that we have 2 pods created:
kubectl get pods
Let’s list the ReplicaSet:
NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR
rollout-bluegreen-6565b74f44 1 1 1 83s rollouts-demo argoproj/rollouts-demo:blue app=rollout-bluegreen,rollouts-pod-template-hash=6565b74f44
We can see that the image deployed is of the blue variety. Similarly, if get Argo
Rollouts to print thing for us:
kubectl argo rollouts get rollout rollout-bluegreen -w
Status: ✔ Healthy
Images: argoproj/rollouts-demo:blue (stable, active)
NAME KIND STATUS AGE INFO
⟳ rollout-bluegreen Rollout ✔ Healthy 21m
└──⧉ rollout-bluegreen-6565b74f44 ReplicaSet ✔ Healthy 20m stable,active
├──□ rollout-bluegreen-6565b74f44-qps4m Pod ✔ Running 19m ready:1/1
└──□ rollout-bluegreen-6565b74f44-twx2x Pod ✔ Running 4m19s ready:1/1
We can also use the Argo Rollouts dashboard to visualize things. If you’re logged in the
host, exit and login again:
Then, run the following command to access the dashboard:
kubectl argo rollouts dashboard
And use the browser to access the Rollout dashboards
Finally, since we deployed both services as type=LoadBalancer, we will have 2
Balancers. You can look up their respective public IP addresses in the OCI console or use
kubectl to look them up in the EXTERNAL-IP column when you run:
And if we access the preview and active Load Balancers, we’ll see the preview is green and
is still blue.
Let’s give the rollout a promotion. We can use command line as thus:
$kubectl promote rollout-bluegreen
or if you have Argo Rollouts Dashboard still open, you can use that too.
If we now access both load balancers, they’ll both show up as green. You can keep switching
between them to simulate upgrading to newer versions of your application.
I’ll pause here and leave Argo Events for a future post. For now, I hope this shows you that
you were considering running the Argo project on your Kubernetes cluster, OKE will work
nicely with it.
N.B. This article was originally posted on
https://medium.com/oracledevs/deploying-the-argo-project-on-oke-ee96cabf8910. It has been
updated to focus on ArgoCD and Rollouts and also to reflect the changes in the