 Είδαμε σε άλλη αποδραμή της ArgoCon, όπως να προσπαθήσουμε και να δώσουμε τις ευρωπαϊκές ευρωπαϊκές ευρωπαϊκές ευρωπαϊκές. Η μία name είναι Kostis Cappellonis, δεχνήθα για τον Codfress ως ένας ευρωπαϊκό επικέτημα. Είμαι ένα ευρωπαϊκό ευρωπαϊκό κομπιτήρ, και είμαι κομπιτής της δοκιμινέας, το blog post και τίποτα like αυτή. Αν desired να ευlementsομαινετε τουHayekο σางmonary, ήηντε assumptions σωστifice σ 就και τρεπω My mankind, θα Θεσμεσατε βοησαν 내려γα και στον Ευρωπαϊκό Κομπιτήρ, perfect���εμο είτε πρόεδρομαι η ευρωπαϊκή ευρωπαϊκή ευρωπαϊκή ευρωπαϊκή ευρωπαϊκή ευρωπαϊκή προσπαθήρ, επίσης προσευχ daunting turning back to the TruePal website. Αυσαιτήαμε και βρήήμε τegt τείποτα που θα φυσικά點 unrestщее λόγες με το meine, και στους τεπλικούς θα έρθουν από πιπ 20. Είναι καλύτερο, έπρεπε, έπρεπε. Δεν υπάρχει τίποτα. Το πρόβλημα είναι ότι πολλοί οι κομπανές έχουν πραγματική αρχαία από δυσκές βαλύσεις. Αυτό είναι ένα παράδειγμα με δυσκές, έχεις ένα βαλύσιο, και then δυσκές βαλύσεις για δυσκές δυσκές, και κάθε βαλύσιο έχει τις δυσκές, και μπορείς να κάνεις το ίδιο με χαίλμ. Μπορείς να έχεις χαίλμ βαλύσεις και σε εμπραγματικά δυσκές δυσκές. Δεν είναι αυτό που θέλεις, ευγύρωσης θέλεις να δεις το whole context of the pull request, like the whole thing, not just the lines that changed. In most cases, what you want to see is a final rendered manifest. You don't really care about the customized line or the hill value that changed. You want to see the final manifest, and especially if you are using hill, and you have lots of templates, at least for me, να γινήσω μία καταγράφηση στην κορυπή μου, δεν είναι καλό πολύ όλα να κάνω. Ξέριας να παράξω σκόλου, πρέπει να νομίζω τι μία καταγράφηση θα κάνω και να προσπαθώ να ανοίξω, να δεύει τη δύο ή εσένα. Αυτό είναι κάτι που δεν θέλω να κάνω. Για εχθήρους της κορυπής, αυτό το πρόβλημα είναι ακριβώς μεγάλιο, προσπαθώ να ανοίξω τι είναι το δεύτερο. Αυτό είναι το προς που θα μιλώσουμε σχέσης για μένα, Και θα δούμε 4 φορές, τα 3 που δεν είναι καλύτερος και το καλύτερο που θέλω να συγχωθεί. Οπότε το πρώτο και το πιο δύσκολο είναι ότι ξέρω ότι αργο-CD έχει ένα βιλτινό δημιουργείο inside the UI. Οπότε όταν κάτι αλλάξει στο μανιφέσ ή στο κλάσταρ, αργο-CD θα σας πει ότι κάτι αλλάξει. Μετά μπορείτε να κλείτε στο UI και να δείξετε την αξιότητα. Όπως όλα τα μανιφέσ θα είναι ρέντε, θα δείξετε το βιλτινό. Από την τελευταία, ξέρετε τι θα αλλάξει και αυτό βγράφει. Είναι καλύτερο, μπορείτε να κάνετε. Αλλά έχει δεύτερες δημιουργές. Πρώτας, όλα σημαίνει ότι έχετε δημιουργείοδο αυτοσύνκ. Ενώ αν μπορείτε να αντιμετωπίσω αυτοσύνκ, αυτό δεν θα μπορείτε να μην είναι βυσικο. Από έναν χρόνο και εγώ σιχαίνω να αντιμετωπίσω αυτοσύνκ. Επειδή αυτό είναι πώς παίρνεις γητοπίσ. Είχα always the guarantee that what is in the cluster. Είναι μεταρράχωνα, εσύρα είμαι αγγελ pursed in the cluster. Στα ευλογή, όταν βλέπω την ευρώσταση να τάξω τον επόμενο. 不是 a lot of options, I wouldn't suggest to use it as a regular utility. My recommendation is if you're doing this, maybe it's in a production environment... και βέβαια είναι για σκέψη, σκέψη, ότι ναι, αυτή είναι η θέση που θέλω. Αλλά για νομιπροδοκτικές εμπειρήσεις, νομίζω ότι αυτή δεν είναι μια καλή ιδιότητα. Λοιπόν, αυτή ήταν one option. Η άλλη option είναι να χρησιμοποιήσει τη CLI χρησιμοποιή. Και πραγματικά έχω ένα καλύτερο παιδί για εσένας, πώς πολλοί γνωρίζουν την αργο-CDCLI DEAF κομμάντ, πώς πολλοί γνωρίζουν την αργο-CDCLI DEAF κομμάντ. Λοιπόν, αν θέλεις να μου πεις αυτό, αυτό είναι ένα από τα φεύγραφα που δεν έχει καλύτερο παιδί, υπάρχει η δικαλία παιδί που λάξει να δεις, την ίδια παιδί της CLI, αλλά η πιο εξεγραφή είναι το αργο-CDCLI DEAF κομμάντ, που λάξει να εξεγραφήσει τι είναι σε την κλαστά την εξεγραφή, όχι σε ένα γητροποζητή, αλλά σε μία που έχεις εσένας στο λόγω. Παρακολουθούντας κάτι, μπορείς να δημιουργήσεις πριν ένα μανιφέστο στο μόνο σας και να δείξεις τι είναι οι χένες. Αυτό είναι το πρόβλημα. Υπάρχει και δείξεις τι είναι δύσκολο και πρέπει να δημιουργήσεις πολλές φιλές και να δείξεις πραγματική σύμφωνα για να δημιουργήσεις πραγματική ή τίποτα που χρησιμοποιείς. Λοιπόν, αν έχεις αυτό το σύμφωνο σύμφωνο, then the obvious thing is to do the same thing that if you have seen Terraform and Atlantis do you essentially integrate this thing into a pull request. Λοιπόν, έχεις το σύμφωνο σύμφωνο και ρίξεις βλέπεις το αρχισιμοποιούς αυτο-ίδηγου, αιτή vest. Και μετά μπορείς να δημιουργήσεις το συνδήμα στο σύμφωνο σύμφωνο που χρησιμοποιής. Π κάνεις τη φορά που χρή siitä επίσης, έχεις also a comment on the DIFF. Και αυτό δείχνει, αυτό είναι το τι η Atlantis είναι ακούσε, αλλά δεν είναι μια πολύ καλή ιδία, γιατί μόνο χρησιμοποιούς σύμφωνος σύμφωνος. like argocd cli, needs access to the cluster in order to create a diff. So this implies that your CI system has access to the argocd cluster, which is possible, but sometimes you don't want to do this. One of the advantages of argocd is that you can set up argocd on its own, on its cluster, and then its pooling changes from git, without you having access there. So with this way, you need to give access to the argocd server. And also maybe you have a strange topology where, let's say your deployment servers are in China, You might have problems with network there so it works, but it's not the perfect solution. I think it's great while you are developing so as you are creating manifest and if you want to test something yourself, you can quickly run it and see what I'm creating is also what I need. So great, you know, for local testing but I wouldn't recommend it for cleaners as well but it's a very good option. So great for local testing but I wouldn't recommend it for any production use. So another popular choice is to pre-render the manifests and get a final view of what they do so essentially how this works is usually you have your own Git repository that has the source information, so your Helm charts or your customized overlays and then you have a different second Git repository which might be a completely separate Git repository or maybe or maybe a folder or maybe a branch is not really important, where you have your final manifest. And then you need to set up an automated process. So whenever somebody changes something in the private git repo, in the first git repo that has the source, you generate the manifest and commit them. And Argos, it is looking at the second git repository, not the first one. So this is how it works. I'm a developer. I change my customize overlay or my Helm values. I commit the first git repo and then I wait. There is an automated process that copies and renders the manifest, commits them to the second repo, and then Argos is looking at the second repo. So if I do this, now I have the information on the diff on the second repo so I can look at how the diff is presented on the final rendered manifest. And you might think that this copy process is simple and you can do it with a CI system, but you also need to take into account your workflow. So let's say I open a pull request to the first repo. If I want to see a diff, like a diff on a pull request, I also need the pull request on the second repo. So do I open it myself? No, you should also automate this. And whenever I approve this pull request, I want to approve it on the first repo and I want also to approve the pull request on the second repo as well. So things are a bit more complex than what they seem. But the end result is great because you use your native git provider, what they are offering. So this is the same example as before the Helm chart. And right now I see the final manifest. It's not a Helm template. I see the final manifest and I can say, yes, this change is good. I approve it, let's go. And I don't need to render anything manually in my head. So this works. And actually there are some companies that are using it. I think Intuit is one of them. You can do it, that's fine. I mean, you solve the initial problem that you present a nice diff to the user. But I don't personally recommend it because it's super complex to set up. You have more moving parts in your deployment process. You introduce your CI process that does this copying and rendering of manifest. So if your CI system is down, now you cannot deploy anymore. And also if you're in a big company, you need to put some guard rails in place because you need to prevent people from committing to their own repository. Because remember one of the good algo practices is you have one GitHub repository for source code and one GitHub repository for manifest. And now you're introducing a third GitHub repository with final render manifest. So if I want to do a change, I need to be certain that I'm doing it on the source Git repo and not the target Git repo. And also it completely bypasses the support that Argo CD has for Customize and Helm. Because you're passing plain manifest, you are not using that support. So I think it's not the perfect way to do it. So you can use it. If you're using it already, that's fine. I'm not against it, but you need a well-disciplined team in order to explain to people how the workflow works, how to onboard new people that they can understand how it works and also how to prevent wrong commits in wrong repos. And the way, the reason I don't recommend it is because there is an even better option which is the one I personally recommend which is you render the manifests on the fly. So how does this work? If you remember the problem we had with the Argo CD-CLI is that it needs access to the cluster in order to create a diff. But if you're following GitOps, you already have the guarantee that what is in the cluster is in the Git repo. So if you want to compare the current state of the cluster, it makes sense to look at what the Git repo is having because that's the whole reason that you're using GitOps in the first place. So if you want to make a diff on what is coming as a new change and what is already there, you can simply do a Git diff on the pull request that is coming versus the current state in the Git repo without any access to the Argo CD cluster. So this is how it works. There is a single GitOps repository that you have as always. You do your change in your manifest, in your Helm chart or customize overlay and then there is an automated process that just does the diff between the pull request and what you already have in Git. And you attach the result as a comment in the pull request. So, an Argo CD is looking at the same repo. So you are using again the CI system to do something, but it's not a point of failure. Like if your CI system is down, you can still deploy and you don't get this nice diff compared to the previous solution. And it's all Git based. So there is no access needed to the cluster. And then at the end, as a user, I just go to my normal pull request in Git and I have, let's say, the dump Git diff information that only Git knows in my smart diff that I have created as a comment in my CI system. And as a human, I look at the second one, the smart one. So this is how it looks. This is an example. I'm looking at the pull request and you can see I have a comment and this comment has different sections for the environments that I'm about to deploy and I can see that in this environment, this is a full manifest that will go in that environment and this is the actual change that will happen with Argos idea. I don't need again to bother myself with Helm templates or customize overlays. So is it perfect? Of course not, it's not perfect. The main problem is that you still need to set up this something, this CI process that dips the manifest. Also specifically with Helm, there are some corner cases that I'm not going to go into where the diff you get is not the exact same thing that you would get with Helm. So you might miss something. But everything else is at an advantage. It only works for Git. You don't need to do any special networking with Argos CD. There is only one Git repository, the one that both humans use and Argos CD is using and where is the Flux guy? This is not Argos CD specific. It's for any GitOps tool. So even if you're using Flux, you can do the exact same thing. So you can switch from company to company regardless of the tool that they are using. So that's my personal recommendation. It's simple. It's robust and you should use it. It works with any CI system and with any topology. But there's a final closing point and I think this is pretty important. So far we have been talking about looking at the different understanding what has changed. But it's also important to know sometimes what has not changed and maybe even more important. So in the previous ArgoCon, I had a presentation about a very popular blog post which is how you organize your GitOps environments and how you promote changes from environment to environment. I'm not going to go into this topic right now. There is a YouTube recording. Go and watch it in a blog post. But essentially there the answer was that you should use folders for your environments and you should have a folder for QA, a folder for production, a folder for staging and then you copy stuff between them. And there was a specific scenario which I'm showing in the screen. The orange boxes are folders and the blue boxes are overlays or maybe helm values, whatever you prefer. So there is a change that is coming in and they say to you, this change should go only to staging. So you make the change in the customize overlay only for staging or helm values, you apply it, it works, everything's perfect. Then one week later they tell you, oh, this change should now go to production. So you go to the production overlay, you do the same change, you approve it, you merge it and it works. And then you realize that you have the exact same change into overlays and the obvious thing to think is, okay, why have this duplication? Let's move this change into the parent overlay or to the parent helm value. And a lot of people said that this is a very dangerous operation because you will change many overlays and you don't know exactly what was changed and they are not going to do it and it's a risk and this is why they don't agree with how you should organize your environments and you should not use folders. So I didn't know the answer back then but I know the answer now. These people were afraid because this is what the default diff gives you. Like the default diff. You see some changes. There is a line that is being removed from two overlays and there is a line that is added in the base overlay. And this is a change. Like you see this and say, oh, things are changing. What should I do? I don't know exactly what happens. But if you remember, this is the naive diff. The diff that your provider is giving you by default. If you follow my approach and you have the smart diff that I explained, here I have pre-rendered the manifests and nothing has changed. The end result is exactly the same. So I did some refactorings in my manifest and I know that what Argos CD will say is absolutely nothing. I know that after I commit this change and merge it, Argos CD will do absolutely nothing. So I can merge this commit with 100% safety and no risk at all. And I did this because I looked at the smart diff and not the native diff that my provider is giving me. So for me, this is even more important not only to know what has changed but also to know what hasn't changed. This is the same thing. This is a comment attached on the pull request. I have the URL there. Everything I've showed is not theoretical. You can find a code that does this. This was a very popular question. How do you do this? You can go and look at it. So these are the solutions that we have seen. The native git diff is very naive. It's very simple. It doesn't give you enough context on what has changed. Don't use it. Argos CD UI diff, yes, it's fine but it's very late in the process and you lose the auto sync behavior if you do this. The CLI, the minus minus local argument is okay for local experimentation but I wouldn't use it for production. If you want to pre-render manifest on a second git repo, yes, you can do it, companies do it but I think it's super complex and it adds many moving parts and my favorite way you render manifest on the fly and you attach them as a comment on the pull request. It's simple to set up. It works for Argos CD and Flux. There is only one git repo and it only, and not only tells you what has changed but also what has not changed. So these are some resources. The first one is a blog post that has what I explained with many more details. I'm including Atlantis there. It was mentioned in the previous presentation as well which if you are familiar with Terraform, it's doing a similar thing. It has pull request and then it attaches comment on the pull request about the Terraform plan. So what we saw here is essentially an improvement on what Atlantis does because Atlantis has the same issues. It needs access to your Terraform state, to your Terraform CLI, to your Terraform everything. It has the keys to your kingdom and we don't want to repeat the same mistake with Argos CD. And then the last one is the link to the Argos CD certification. It has lots of things also, it includes the promotion to environments. And that's it. We have a few minutes for questions or arguments. Kostas loves arguments. If you want to raise your hand, you want to argue. Yeah, if you have arguments, don't start them here. Maybe you can find the afterwards and tell me, no, you are wrong. I love that way in that way. Hi, thanks for the presentation. It was really good. I have a question. Can you please give more details about how you actually make the diff between the Argo, what is running actually now in the cluster and what is in the git? If you go to this URL, there is actually a GitHub workflow that I use as an example and it's the full code. It's not something that is, let's say, super usable. I did it for fun. Essentially, there is a checkout step from the pull request that takes the code of the pull request. Then it runs customize because the example I'm using is running customize and it does customize build my QA, customize build my production, customize build my something. It saves the result because it's the final rendered manifest. And then it does the exact same thing from the main branch. Because remember, because of GitOps, we know that what is in the main branch is also in the cluster. And there is a final diff between those and then there is an attachment to the PR. But instead of me explaining its open source, you can just click on it and look at the code and see exactly what it does. And GitHub actually is just an example. You can do it with CircleCI, CodeFresh, Jenkins, GitHub, whatever. Other questions? One of the slides mentioned like one of the outside use cases. So we use Flux and Argo CD in my group. How about, how about for post renders? Does it show that as well? I would guess so. Yeah, I don't see any reason why. It's completely- Post renders after, you know, for let's say like not modifying our Helm chance afterwards. Let's say like it doesn't show up in the manifest file but we modify the templates. Yeah, as long as you're doing the full process. Like I think at the end of the day you're doing a Helm template or you're doing a Customize. So as long as you're applying those post processors on it then it would work exactly the same. Yeah, Customize and Helm are again are just examples. You can have your own favorite templating tool that just takes something and prepares a manifest. Same thing. Yeah. Good question. Questions? We have probably time for one more. What else will they learn in the certification courses? Promotion between environments I think is the big thing. And then Argo rollouts. If you're already using Argo CD and you want to know about Argo rollouts there are examples there as well. Thank you, Kostas.