Around 25:00, when using Helm, you should use a checksum annotation of the config map in the deployment. Google "helm tricks automatically roll deployments", it'll be the first result from the Helm docs. Great video, cheers!
😍The Video. Clear concise explanations. I knew Kustomize before and I always wondered why config generator. Now I get the reason. Thanks for your explanations.
Regarding the destination cluster URL - if there were more than one, what would they look like? How do we define them so we know which one is which? I am guessing that one shows as default because it was not configured with a different name?
Thanks for the video, but apparently the most important piece is missing. When the actual application code changes, how do you build a new image (with a new tag other than "latest"? and how do you update the helm and kustomize configurations with that new image name:tag, and how do you trigger anrgo CD that application code has been changed, new image has been created and it (argo cd) should kick off and deploy the newest version? In your video you only showed what happens when the configuration part changes. So it is incomplete IMHO.
Thanks for the comment. I briefly mention this at 1:35. You would have two repositories, one for the image and one for the configuration. The CI/CD for the first repository would work like any other container pipeline, but at the end it would submit a PR to your config repository to update it with the new image tag. I didn't work it into the practical portion of the video because I didn't want to overcomplicate things I just wanted to show the basics of ArgoCD. Most people when getting started with ArgoCD update the configuration repository manually with the new image tag. I hope that makes sense. Thanks again for your feedback - I was thinking of doing a video of a complete Gitops flow that does exactly what you mentioned and your comment has inspired me to do that, so check back in a month or so :)
@DevOpsJourney Why wouldn't you just use a `checksum` annotation inside of your Helm deployment that digests the contents of the ConfigMap? When the contents of the ConfigMap changes, it changes the Deployment triggering a rolling update of the pods? Does ArgoCD do something different than stock Helm + K8s?
Hi, at 10:37, you are saying one argocd installation can manage multiple kubernates cluster, but i don't understand how? because argocd is going to be installed in a specific cluster, so is there not one-to-one relationship between argocd and K8S cluster, if not how you can manage multiple K8S cluster?
There is a clusters tab. You can add other clusters into ArgoCD there. ArgoCD will just need credentials and a URI for connecting/managing other clusters
very nice. Im from Belgium, i speak french, but i have all understand ;-) I'm interested in a video showing ArgoCD - GitLab not deploying a web app, but an Apache Camel-K integration. Would it be possible for you to make one? I think you will have the right reflexes directly on ArgoCD. The Kustomize version is really interesting, especially when you don't want to create the entire helm ecosystem. THANKS
1. Create a kubeconfig file containing the cluster's credentials. 2. Login to ArgoCD and navigate to the Clusters page. 3. Select the “Create Cluster” button at the top right. 4. Select the type of cluster you want to add and provide the necessary credentials. 5. When prompted, select the kubeconfig file you created in step 1. Click Create CLI commands: argocd cluster add dev-cluster1 --name dev-cluster1 argocd cluster list
hi, i tried the lab for kustom-webapp, i got this error: Unable to create application: application spec for kustom-webapp-dev is invalid: InvalidSpecError: Unable to generate manifests in kustom-webapp/overlays/dev: rpc error: code = Unknown desc = Manifest generation error (cached): `kustomize build /kustom-webapp/overlays/dev` failed exit status 1: Error: invalid Kustomization: json: cannot unmarshal string into Go struct field Kustomization.patches of type types.Patch. Please how can that be resolved?
I'm trying to deploy this on an M series mac, how can I specify the architecture of the nodes? I'm looking at the values.yaml file but I'm not sure how I can edit the files so it deploys as arm64
If running on a M series Mac the architecture of minikube will be arm64. The key is to make sure our images are ARM64 compatible. The deployment is using the image devopsjourney1/mywebapp:latest - which does support ARM64. I only recently shipped the ARM64-compatible image, so you may have an older one cached. try removing and re-pulling devopsjourney1/mywebapp:latest. If that doesn't work then I will try creating a new image for you that is only ARM64. I think the issue might be that minikube doesn't always understand how to use multi-arch images properly
when I click "Create"for the helm-webapp-dev I get "Unable to create application: application spec for helm-web app-dev is invalid: InvalidSpecError: Unable to generate manifests in helm-webapp: rpc error: code = Unknown desc = `helm template . --name-template helm-web app-dev --namespace dev --kube-version 1.30 --values /helm-webapp/values-dev.yaml --include-crds` failed exit status 1: Error: release name "helm-web app-dev": invalid release name, must match regex ^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$ and the length must not be longer than 53" Any idea?
