🔴 - To support my channel, I’d like to offer Mentorship/On-the-Job Support/Consulting - me@antonputra.com 👉 How to Set Up ArgoCD for Production?: ua-cam.com/video/_G_RY5trQao/v-deo.html 👉 [Playlist] Argo CD Tutorials: ua-cam.com/play/PLiMWaCMwGJXkktZoHhmL6sbg7ELNjv9Xw.html
Most serious DevOps channel on youtube! Everytime i search about DevOps i land here and see that its explained in details with reasoning. Thank you very much!
Hi @AntonPutra , I really enjoy watching your videos. I was wondering if it would be possible for you to make a video that delves into the subject of secret management? this is an important topic that deals with the safekeeping of sensitive information such as passwords, API keys, and other types of credentials.
Thank you, Vinay. It can be installed using the same helm provider as I did with other components. You can find it with - helm repo add argo argoproj.github.io/argo-helm - "helm search repo argo-rollouts"
Great Video as always, please make a video regarding argocd canary deployment & adding multiple clusters like eks & gke in a single argocd for easier managements, thanks for an amazing high class production grade content 🥰
interesting and very meaningful video as usual. Before viewing this video, I was thinking about using events to have CD / CI but with ArgoCD Image Updater, it simplies the approach a lot. Many thanks for your video Anton :)
Hello, thanks for the work you put to do these videos. What happens if the writeback branch is protected? How safe is to allow image updater service user to write back to the main branch with force-push permissions? We have a setup where we want to use image updater for DEV to enable automatic deployment, with writeback to main, and then QA/Prod would be PR workflow using manual image tag update.
Hi Anton, what do you think of following strategy 1. CI pipeline builds new docker image in the app repo and push it to CR 2. CI(we are still in App build CI pipeline) knows image tag, it pull deployment repo, use kustomize to update image tag in deployment, update deployment repo, push it 3. ArgoCD watches for the deployment repo and notice the tag change 4. ArgoCD does the deployment In here we use a single CI pipeline to build docker image, push it to CR, update deployment repo(which is a separate one) and let argo do the rest
@@AntonPutra hi anton, i finshed the vid, i think main difference with your vid and my approach was, in your one ArgoCD writes to the git repo about the latest tag, in mine CI server does this when certain criterias are met for example after staging deployed, CI server will update the deployment repo with image tag into prod env, causing argo cd to deploy the app to prod this way, we control the entire flow from a CI script and we control how same image tag promoted different multiple environments. I prefer to use git SHA for image tag, so we can correlate image version with our code at any given time. this allow us to simply promote same image across multi environments keeping things more consistent let me know what you think
@@kasvith Most of the time, I prepare some simplified versions of the pipelines. Production pipelines can have a lot more steps and validation, so I'm not surprised.
Hi Anton! Your videos are great! Thanks a lot! I am curious, how do you version kustomize artifacts? Let's say I have development and production environments. I am going to migrate from regular Deployment with rolling update to flagger and I want to commit that to the repository but affect development environment only. If we use the same app-base folder - that is a bit problematic. Or let's say I want to rollback, do I have to git revert? If I use helm, I can version charts in chartmuseum or OCI repository and upgrade/rollback independently
Yes, it's a trade-off. You can't really version control Kustomize; you can only override some parameters in each environment. Usually, it's enough. If not, consider creating a new folder for Kustomize.
hi, Anton, thank you for the content. Very useful. I've adopted a lot of practices you outline in your tutorial. I noticed that when terraform creates argocd helm release, and if you delete an ingress manually(I am creating an internal one) terraform doesn't know about ingress being deleted. Is there any way to have a control over it? My thought is to create ingress as a kubernetes resource instead of a part of helm release.
Thanks! Why not configure ingress using a Helm chart? For example, you can make it internal from the get-go. Or, you can use 'helm template' to generate YAML, then add your custom ingress and change variables with Kustomize.
uff thank you, its content is incredible, good practices can be understood, I like it a lot, what do you think of staging or production-like test environments and how should databases be managed? I have seen environments that from staging select a branch and send it to be deployed to a cluster that sees a url, where I work they want to make it possible to have n self-assembling virtual environments, but in their experience from what you have seen, or What do you think would be a good practice?
@@AntonPutra Yes, and with respect to creating test environments in kubernetes? What is the most common, the correct, the best practice? What would the flow of the team or the developer be like?
Hi @AntonPutra Thank you so much for your content. I have a question regarding how do we manage github repository when you have multiple environments, like how will the folder structure look like, application.yaml file . with image updater being setup too.
@@AntonPutra Thank you so much for your response. Unfortunately it doesn't address my problem statement, I am looking for a solution when you have your microservices managed by helm and you need to deploy them to different environment, Secondly i need to setup application.yaml file to each environment since i have argocd setup on each environment. Looking forward to hear from you :)
@@ahmadhassan2321 check out argocd autopilot, they have very opinionated folder structure that may work for you - argocd-autopilot.readthedocs.io/en/stable/
To deploy regular application using Argocd we need to apply argocd custom resource with reference to kubernetes deployment manifests. if you need to deploy 10 apps you need to manually apply 10 argocd custom resources. App of apps is the same argocd custom resource that you use to apply a single resource but instead it has reference to all argocd custom resources. So it automates deployments of all apps from the git
I would love to hear your thoughts on the best way to allow argoCD to connect to a private AWS ECR, for pulling oci helm charts. The ecr token expires every 12 hours so some kind of corn job maybe?
Thanks for the video, Sorry I have a question again. Should we make our backend app into tf code? Because in this example, we only use kubectl apply to put the application into Argocd. But I am trying to use terragrunt with combine with ArgoCD. However I don't know should I transform my application into tf code. Because both kustomise and helm also in yaml format which can not be called by using terraform / terragrunt apply. So I am quite confuse when we should put the application into argoCD, or we just run kubectl apply -f application at the end of infrastructure deployment. Below are my developed steps of terragrunt plan Group 1 - infrastructure-live/dev/vpc Group 2 - infrastructure-live/dev/eks - infrastructure-live/dev/iam-admin Group 3 - infrastructure-live/dev/argocd (argocd+image-updater+chart_museum) - infrastructure-live/dev/kube-prometheus-stack Group 4 - infrastructure-live/dev/external-ingress-nginx - infrasturcture-live/dev/my-backend-app
The only appropriate option now is to create an IAM role and use IRSA for the K8s ArgoCD service account. By the way I'll create a video soon ArgoCD + EKS..
I use Helm to deploy ephemeral environments that are typically torn down after you run tests or are done with development. It's also used for some open-source applications. If you decide to use Helm to manage applications in your production environments, over time, you may get new requests to add more deployments, expose them using ingress, etc. Any kind of change in Helm must be associated with additional commits and the release of a new Helm version. If you have hundreds of apps, managing Helm can sometimes be very annoying. With Kustomize, it’s a bit easier to manage in the long term.
Not sure regarding ArgoCD and AWS; for the last 4 years, I've been running FluxCD. It supports all cloud providers 100%. I'll check in the future, looks like there isa workaround - github.com/argoproj-labs/argocd-image-updater/issues/112
@@rohmersicat3429 Argocd is more popular just because it has UI, I don’t use it anyway. I’ve been running Fluxcd in prod for I few years and only had issue due to my mistake and built-in garbage collection
wouldn't it be simpler to use say "github actions" to make the 2nd example, PR -> master -> action: (1) build app and push to docker hub (2) commit&push tag release it wont separate ci/cd but keep it simpler
🔴 - To support my channel, I’d like to offer Mentorship/On-the-Job Support/Consulting - me@antonputra.com
👉 How to Set Up ArgoCD for Production?: ua-cam.com/video/_G_RY5trQao/v-deo.html
👉 [Playlist] Argo CD Tutorials: ua-cam.com/play/PLiMWaCMwGJXkktZoHhmL6sbg7ELNjv9Xw.html
Most serious DevOps channel on youtube! Everytime i search about DevOps i land here and see that its explained in details with reasoning. Thank you very much!
😊
I love this: 08:47, most of the tutorials forget the typical scenarios.
Much better than paid courses. Thanks for your time.
Thank you!
Quality of you Videos is super awesome it is very easy to learn.
Thanks!
thank you bro, you do great for your channel.... it help me alot!!
Thank you, Tú Võ Xuân!
With pullSecrets, you can configure it on namespace level by associating it with default (or other) service account.
note, when adding a helm repo, you can update local index for that repo only (faster)
helm repo add XYZ url
helm repo update XYZ
thanks good to know
Спасибо! Thanks very much for the in-depth guide!
Thanks!
Hi @AntonPutra , I really enjoy watching your videos.
I was wondering if it would be possible for you to make a video that delves into the subject of secret management?
this is an important topic that deals with the safekeeping of sensitive information such as passwords, API keys, and other types of credentials.
Sure, thanks for the feedback
Thank you very much for this content, hope you can make more videos about Argocd, specifically AppProject and Applicationset 😍
Sure, thanks!
@@AntonPutra thanks a lot, please upload more videos on argocd.
Great content!!!! Thanks for sharing.
Can you please share terraform code to install Argo Rollout as well if available.
Thank you, Vinay. It can be installed using the same helm provider as I did with other components. You can find it with
- helm repo add argo argoproj.github.io/argo-helm
- "helm search repo argo-rollouts"
Great Video as always, please make a video regarding argocd canary deployment & adding multiple clusters like eks & gke in a single argocd for easier managements, thanks for an amazing high class production grade content 🥰
Thanks!
Much appreciated, great job man, thank you behalf of the community....
thank you!
interesting and very meaningful video as usual. Before viewing this video, I was thinking about using events to have CD / CI but with ArgoCD Image Updater, it simplies the approach a lot. Many thanks for your video Anton :)
Thank you, events?
@@AntonPutraYes, they have Argo Events, Workflows and Rollouts. CI part can be implemented with events and workflows
Hello, thanks for the work you put to do these videos. What happens if the writeback branch is protected? How safe is to allow image updater service user to write back to the main branch with force-push permissions? We have a setup where we want to use image updater for DEV to enable automatic deployment, with writeback to main, and then QA/Prod would be PR workflow using manual image tag update.
i think i answered your question under another video. yes image updater won't work with protected branches and app of apps, try flux v2
hi,thanks for videos, pls make video for secret management.
Okay sure
Best Teacher Ever
Hi Anton, what do you think of following strategy
1. CI pipeline builds new docker image in the app repo and push it to CR
2. CI(we are still in App build CI pipeline) knows image tag, it pull deployment repo, use kustomize to update image tag in deployment, update deployment repo, push it
3. ArgoCD watches for the deployment repo and notice the tag change
4. ArgoCD does the deployment
In here we use a single CI pipeline to build docker image, push it to CR, update deployment repo(which is a separate one) and let argo do the rest
I think I described exactly the same strategy in either in the first video or in this one😊
@@AntonPutra yeah just noticed it, keep up the good work
@@kasvith thanks will do :)
@@AntonPutra hi anton, i finshed the vid, i think main difference with your vid and my approach was, in your one ArgoCD writes to the git repo about the latest tag, in mine CI server does this when certain criterias are met
for example after staging deployed, CI server will update the deployment repo with image tag into prod env, causing argo cd to deploy the app to prod
this way, we control the entire flow from a CI script and we control how same image tag promoted different multiple environments.
I prefer to use git SHA for image tag, so we can correlate image version with our code at any given time. this allow us to simply promote same image across multi environments keeping things more consistent
let me know what you think
@@kasvith Most of the time, I prepare some simplified versions of the pipelines. Production pipelines can have a lot more steps and validation, so I'm not surprised.
Thank you so much for this thorough video. Curious if its possible to use something like key vault or aws kvm for secrets. Would be an awesome video.
Thanks, yes it's possible. I have one video regarding eks and aws secrets manager integration, but it's quite old i would need to update soon
Hi Anton!
Your videos are great! Thanks a lot!
I am curious, how do you version kustomize artifacts? Let's say I have development and production environments. I am going to migrate from regular Deployment with rolling update to flagger and I want to commit that to the repository but affect development environment only.
If we use the same app-base folder - that is a bit problematic. Or let's say I want to rollback, do I have to git revert?
If I use helm, I can version charts in chartmuseum or OCI repository and upgrade/rollback independently
Yes, it's a trade-off. You can't really version control Kustomize; you can only override some parameters in each environment. Usually, it's enough. If not, consider creating a new folder for Kustomize.
super useful for me
Glad to hear that
hi, Anton, thank you for the content. Very useful. I've adopted a lot of practices you outline in your tutorial. I noticed that when terraform creates argocd helm release, and if you delete an ingress manually(I am creating an internal one) terraform doesn't know about ingress being deleted. Is there any way to have a control over it? My thought is to create ingress as a kubernetes resource instead of a part of helm release.
Thanks! Why not configure ingress using a Helm chart? For example, you can make it internal from the get-go. Or, you can use 'helm template' to generate YAML, then add your custom ingress and change variables with Kustomize.
uff thank you, its content is incredible, good practices can be understood, I like it a lot, what do you think of staging or production-like test environments and how should databases be managed? I have seen environments that from staging select a branch and send it to be deployed to a cluster that sees a url, where I work they want to make it possible to have n self-assembling virtual environments, but in their experience from what you have seen, or What do you think would be a good practice?
I saw that some companies take a snapshot of production data and load it to "staging" environments for tests.
@@AntonPutra Yes, and with respect to creating test environments in kubernetes? What is the most common, the correct, the best practice? What would the flow of the team or the developer be like?
many thanks man!
Welcome Dmitriy
Hi @AntonPutra
Thank you so much for your content. I have a question regarding how do we manage github repository when you have multiple environments, like how will the folder structure look like, application.yaml file . with image updater being setup too.
Something like this - github.com/antonputra/tutorials/tree/main/lessons/158/lesson-158/environments/staging
@@AntonPutra Thank you so much for your response. Unfortunately it doesn't address my problem statement, I am looking for a solution when you have your microservices managed by helm and you need to deploy them to different environment, Secondly i need to setup application.yaml file to each environment since i have argocd setup on each environment.
Looking forward to hear from you :)
@@ahmadhassan2321 check out argocd autopilot, they have very opinionated folder structure that may work for you - argocd-autopilot.readthedocs.io/en/stable/
Hi, Anton
great video, Thanks a lot for sharing
I have a question
in this scenario what is exactly ArgoCD " app of apps " ???
To deploy regular application using Argocd we need to apply argocd custom resource with reference to kubernetes deployment manifests. if you need to deploy 10 apps you need to manually apply 10 argocd custom resources. App of apps is the same argocd custom resource that you use to apply a single resource but instead it has reference to all argocd custom resources. So it automates deployments of all apps from the git
I would love to hear your thoughts on the best way to allow argoCD to connect to a private AWS ECR, for pulling oci helm charts.
The ecr token expires every 12 hours so some kind of corn job maybe?
have you tied this?
github.com/karlderkaefer/argocd-ecr-updater
Thank you definitely helpful
Great content
thanks!
Thanks for the video,
Sorry I have a question again.
Should we make our backend app into tf code? Because in this example, we only use kubectl apply to put the application into Argocd.
But I am trying to use terragrunt with combine with ArgoCD. However I don't know should I transform my application into tf code. Because both kustomise and helm also in yaml format which can not be called by using terraform / terragrunt apply.
So I am quite confuse when we should put the application into argoCD, or we just run kubectl apply -f application at the end of infrastructure deployment.
Below are my developed steps of terragrunt plan
Group 1
- infrastructure-live/dev/vpc
Group 2
- infrastructure-live/dev/eks
- infrastructure-live/dev/iam-admin
Group 3
- infrastructure-live/dev/argocd (argocd+image-updater+chart_museum)
- infrastructure-live/dev/kube-prometheus-stack
Group 4
- infrastructure-live/dev/external-ingress-nginx
- infrasturcture-live/dev/my-backend-app
is it better to use application sets or application with kustomize? Im using app of app approach either way
the fewer framework-specific objects you use, the easier it will be to migrate to a different project later
Hi Anton, what method would you suggest for authorization for AWS ECR?
The only appropriate option now is to create an IAM role and use IRSA for the K8s ArgoCD service account. By the way I'll create a video soon ArgoCD + EKS..
What is your preference? Helm or kustomize? And why?
I use Helm to deploy ephemeral environments that are typically torn down after you run tests or are done with development. It's also used for some open-source applications.
If you decide to use Helm to manage applications in your production environments, over time, you may get new requests to add more deployments, expose them using ingress, etc. Any kind of change in Helm must be associated with additional commits and the release of a new Helm version. If you have hundreds of apps, managing Helm can sometimes be very annoying. With Kustomize, it’s a bit easier to manage in the long term.
Thanks for this video. Its explained everything iam wondoring. :)
Thanks for your videos!
Can you do a Flux V2 tutorial?
Sure
thanks man
welcome
Hi seems like aws ecr not supported on the updater config registry do you have any work around for aws ecr ?
Not sure regarding ArgoCD and AWS; for the last 4 years, I've been running FluxCD. It supports all cloud providers 100%. I'll check in the future, looks like there isa workaround - github.com/argoproj-labs/argocd-image-updater/issues/112
@@AntonPutra Thank you in your opinion what do you prefer for CD FluxCD or ArgoCD ? specially when it comes of complexity
@@rohmersicat3429 Argocd is more popular just because it has UI, I don’t use it anyway. I’ve been running Fluxcd in prod for I few years and only had issue due to my mistake and built-in garbage collection
@@AntonPutra Thank you master! been following you and watching your video always :)
wouldn't it be simpler to use say "github actions" to make the 2nd example, PR -> master -> action: (1) build app and push to docker hub (2) commit&push tag release
it wont separate ci/cd but keep it simpler
isn't ArgoCD a bloatware? FluxCD looks simpler
Agree, i use fuxcd in my environments. But looks like argocd is much more popular..
Couldn't you use renovate bot for this
i haven't used it before
Thanks!
Thank you, Stephan!
No, thank YOU! Your content is fantastic. Keep it up