Speaker 1: Welcome to the deep dive. We're your shortcut to getting
Speaker 1: genuinely well informed fast without drowning you in details.
Speaker 2: Yeah, we focus on those core insights, those aha moments exactly.
Speaker 1: And today we are taking a really fascinating deep dive
Speaker 1: into the world of Argo CD and git ops. We're
Speaker 1: using Argo CD up and running a hands on guide
Speaker 1: to get ups and Kubernetes by Andrew Block and Christian
Speaker 1: Hernandez as our guide. It's a pretty comprehensive.
Speaker 2: Definitely, and our mission today really is to unpack what
Speaker 2: gid ops actually is, how Argo CD brings it to life,
Speaker 2: and why it's becoming such a standard for cloud native apps.
Speaker 1: Right. So, whether you're prepping for that big meeting or
Speaker 1: just trying to stay current, or maybe you're just you know, curious.
Speaker 2: We'll give you the essential nuggets you walk away understanding
Speaker 2: this whole paradigm.
Speaker 1: Okay, let's start unpacking getups. We hear this term everywhere,
Speaker 1: so at its very core, what is it?
Speaker 2: Well, the book defines it pretty simply. It's basically a
Speaker 2: method for managing your infrastructure, your applications. Yeah, by describing
Speaker 2: the state you want them to be in declaratively in
Speaker 2: get and using git as that single source of truth.
Speaker 1: That sounds simple, but I guess the revolutionary part is
Speaker 1: the shift right from telling systems how to do things
Speaker 1: exactly imperative commands to just defining what you want in
Speaker 1: a way that's like auditible and trappable because it's.
Speaker 2: In geit precisely. Yeah, that's the real aha moment there.
Speaker 2: And you know the origin story is pretty interesting too.
Speaker 1: Oh yeah, tell me about that.
Speaker 2: It goes back to twenty seventeen with leave Works. They
Speaker 2: apparently had this incident where someone fat finger to config.
Speaker 1: Change oops we've all been there, took.
Speaker 2: Down their whole platform. Yeah, but the way they recovered
Speaker 2: by rolling back using git it sort of revealed this
Speaker 2: new better way of working.
Speaker 1: Ah. So necessity is the mother of invention.
Speaker 2: Kind of Yeah. And their CEO, Alexis Richardson, he's the
Speaker 2: one who coined the term git ops. It came out
Speaker 2: of a real mess basically.
Speaker 1: Okay, that makes sense, and it's important to note right
Speaker 1: this isn't some completely separate thing from.
Speaker 2: No, not at all. The book is really clear on this.
Speaker 2: It says get ops is DevOps. Get ops is the
Speaker 2: natural progression of DevOps.
Speaker 1: So it's like formalizing the good stuff people were already
Speaker 1: trying to do version control automation exactly.
Speaker 2: It takes those DevOps best practices and puts them into
Speaker 2: a really solid, audible automated workflow, like putting guardrails on things.
Speaker 1: Gotcha. So if it's a progression, what specifically defines it?
Speaker 1: Are their rules?
Speaker 2: Yeah? There are the open getops principles, which came out
Speaker 2: in twenty twenty one, lay out four key tenets. First,
Speaker 2: it has to be declarative.
Speaker 1: Declarative, meaning you describe the what, not the how, like
Speaker 1: a Kubernetes manifest.
Speaker 2: Precisely your entire system, state, apps, infra networks, whatever is
Speaker 2: described declaratively, you say what the end state should look like. Okay.
Speaker 1: Principle one declarative what's suck.
Speaker 2: Second, versioned and immutable. The desired state lives entirely in.
Speaker 1: Geit ah the source of truth part exactly.
Speaker 2: And because it's GIT, you get a complete, unchangeable history
Speaker 2: of every single change, auditing rollbacks, it's all built in.
Speaker 1: That's huge. Okay.
Speaker 2: Third, Third, and this is a really key difference from
Speaker 2: a lot of traditional CICD. Changes are pulled.
Speaker 1: Automatically, hold, not push right.
Speaker 2: Instead of a CI server pushing updates, you have get
Speaker 2: ups agents or controllers inside your environment, actively pulling the
Speaker 2: definitions from Git. They run this reconciliation loop.
Speaker 1: A reconciliation loop like a little robot constantly checking.
Speaker 2: Yeah, constantly checking does the live system match the blueprint
Speaker 2: in Git. It makes it more secure, more robust than
Speaker 2: just reacting to webbooks.
Speaker 1: Interesting, okay, And the fourth principle follows from that.
Speaker 2: It does it's continuously reconciled. Those agents are always observing
Speaker 2: the live state and working to make it match the
Speaker 2: desired state from GIT. It's like Kubernetes controllers, but for
Speaker 2: your whole application stack, always self healing, always striving for
Speaker 2: that get state.
Speaker 1: Okay. That makes get ups much clearer. So where does
Speaker 1: argo CD fit in this landscape?
Speaker 2: Rgo CD is a really prominent tool in this space.
Speaker 2: It's part of the wider Argo project and those built
Speaker 2: specifically for getups. Developer experience was a big focus too.
Speaker 1: And its main job is its core purpose.
Speaker 2: Is delivering changes to Kubernetes clusters, potentially at massive scale,
Speaker 2: following those getups principles we just talked about, and.
Speaker 1: The big value proposition seems to be around configuration drift.
Speaker 2: Absolutely, that's where it really shines. It actively detects and
Speaker 2: prevents configuration drift. You know, when your live cluster gets
Speaker 2: out of sync with Git because someone made a manual
Speaker 2: change or something.
Speaker 1: Broke, rgo CD sees the mismatch and flags it or
Speaker 1: fixes it both.
Speaker 2: Potentially. It constantly compares the YAMEL and Git to the
Speaker 2: live state. If they diverge, it lets you know, and
Speaker 2: you can configure it to automatically sink things back to
Speaker 2: the desired state.
Speaker 1: Okay, and you mentioned it brought structure to Kubernetes management.
Speaker 2: Yeah, Before tools like rgo CD, managing all the differ
Speaker 2: Kubernetes pieces to deployment services can fig maps could be
Speaker 2: a bit.
Speaker 1: Loose, right, just a bunch of Yamo files.
Speaker 2: Rgo CD introduced the concept of an ARGOCD application. Think
Speaker 2: of it as an atomic unit of work. It bundles
Speaker 2: everything related to your app, the deployment, the service, ingress,
Speaker 2: everything into one manageable thing.
Speaker 1: So deployments become more coherent, audible, automated exactly.
Speaker 2: You're dealing with the whole application picture at once.
Speaker 1: And it's flexible too, right, not just for strict geit ops.
Speaker 2: That's true. The book points out it can function as
Speaker 2: a general purpose deployment tool even if you're not doing
Speaker 2: full git ops yet, and it integrates nicely with tools
Speaker 2: people already use like Helm and customize. We'll get into
Speaker 2: those more cool.
Speaker 1: So it's adaptable. Let's maybe peel back the layers a bit.
Speaker 1: What's the architecture look like under the hood.
Speaker 2: Sure, so RGOCD itself follows on Microservice's architecture. Is made
Speaker 2: up of several smaller independent components working together.
Speaker 1: Okay, typical cloud native design, right.
Speaker 2: And it leans heavily on Kubernetes primitives. It uses Kubernetes
Speaker 2: concepts effectively. What's really fundamental is how it implements the
Speaker 2: Kubernetes controller pattern.
Speaker 1: Ah, the reconciliation loop idea again exactly.
Speaker 2: Just like built in Kubernetes controllers watch resources, rg CD
Speaker 2: watches two things, the desired state and get and the
Speaker 2: actual spate in your clusters.
Speaker 1: If there's a difference, it steps in and enforces the
Speaker 1: get state prevents that.
Speaker 2: Drift precisely, it's constantly reconciling.
Speaker 1: So what are the main components doing this work?
Speaker 2: Okay, First, you have the repository server. Its job is
Speaker 2: to maintain a local cache of your Git repos or
Speaker 2: Helm chart sources casing for speed yep, and then it
Speaker 2: generates the final Kubernetes manifests from whatever source you're using,
Speaker 2: Helm customized plane YAML.
Speaker 1: It preps the manifests, got it manifest prep station what else?
Speaker 2: Then there's the API server. This is the main hub.
Speaker 2: It uses gRPC and rest pretty standard stuff for communication,
Speaker 2: and this manages everything really application status, triggering, sinks, handling, RBAC,
Speaker 2: role based access control, you know who can do what,
Speaker 2: and it also serves the web UI.
Speaker 1: The user interface runs off This API server.
Speaker 2: Makes sense, but for cashing it uses rehttis.
Speaker 1: Reddus okay, fast in memory database.
Speaker 2: Right is it for local caching to speed things up,
Speaker 2: reduce calls to get and store some temporary state. Important
Speaker 2: note though this redd as cache isn't persistent. If rgo
Speaker 2: CV restarts, it rebuilds the cash.
Speaker 1: From get good to know not a permanent data store.
Speaker 2: And finally, finally, a really key part its own custom
Speaker 2: resources or crds. These extend Kubernetes itself. Rgo CD adds
Speaker 2: things like application at project and application set.
Speaker 1: So you manage rgo CD deployments using these Kubernetes native
Speaker 1: objects exactly.
Speaker 2: These crds become your main way of interacting with rgo
Speaker 2: CD and defining your gitups deployments within Kubernetes itself.
Speaker 1: Very cool. Okay, so how do you actually get this
Speaker 1: thing running and start using it?
Speaker 2: Installation is pretty standard Kupernettes stuff. You can use the
Speaker 2: raw yamal manifests they provide our helm or yeah, more
Speaker 2: commonly these days helm charts. The book guides you through
Speaker 2: setting it up into local kind cluster Kubernettes in Docker,
Speaker 2: which is great for just playing around.
Speaker 1: And learning and interacting with it. I hear the UI
Speaker 1: is quite good, it really is.
Speaker 2: The user interface gives you a great visual overview. You
Speaker 2: can see what apps are doing, theirs, SINC, datas, health,
Speaker 2: managed settings. It's very user friendly.
Speaker 1: How do you access it? Initially?
Speaker 2: You can start with cubictol PORTFOD, just a tunnel into
Speaker 2: it quickly, but for anything more permanent, you'd set up
Speaker 2: a proper Kubernetes ingress to give it a real host
Speaker 2: name like rgo CD dot, your domain, dot.
Speaker 1: Local or something right, make it accessible like a normal
Speaker 1: web app. What about the command line.
Speaker 2: Yep, there's the rg CDCLI tool. It actually offers more
Speaker 2: functionality than the UI, sometimes hitting the same back end API.
Speaker 2: It's where you do more advanced things like adding remote
Speaker 2: clusters declaratively.
Speaker 1: UI for visuals, CLI for power users, and automation. But
Speaker 1: here's the really neat getops part I read about. You
Speaker 1: manage rgo CD itself declaratively.
Speaker 2: Yes, this is super elegant. Rgo CD's own configuration like
Speaker 2: connection details for get, rebos, security settings, UI tweaks is
Speaker 2: stored in standard Kubernetes confct maps and secrets.
Speaker 1: So you can put rgo CD can fig in get
Speaker 1: and have ARGOCD apply its own can fig using.
Speaker 2: GetUp exactly, it manages itself. You define its configuration, declaratively
Speaker 2: commit it, and rgo CD picks it up and reconfigures itself.
Speaker 2: It's get oops all the way down.
Speaker 1: That is elegant. Okay, let's get to the heart of it,
Speaker 1: managing and synchronizing actual applications. This application CRD seems key.
Speaker 2: It is an rgo CD application is basically a pointer.
Speaker 2: It tells ARGOCD about a set of Kubernetes resources that
Speaker 2: belong together. It primarily defines two things.
Speaker 1: What are those?
Speaker 2: First? The dot sbec dot source. This is where the
Speaker 2: manifests live, usually a get repo URL, maybe a specific
Speaker 2: branch or tag and a path within that repo.
Speaker 1: Okay, where the blueprint is right.
Speaker 2: And interestingly, newer versions like V two point six onwards
Speaker 2: support multisource applications.
Speaker 1: Oh what does that mean?
Speaker 2: It means you can pull manifests from multiple sources like
Speaker 2: maybe your main app deployment from one get repo, but
Speaker 2: it's database configuration from another, and combine them into a
Speaker 2: single rgo CD application. Really powerful for complex setups.
Speaker 1: Okay, that's the source.
Speaker 2: What's the second part, the dot spec dot destination. This
Speaker 2: just tells our docd where to deploy those manifests, which
Speaker 2: Kubernetes cluster and which namespace within that cluster could be.
Speaker 1: The same cluster rgo CD is running on or different one.
Speaker 2: Yep, you can specify in cluster for the local cluster
Speaker 2: or provide the API server address for a remote cluster.
Speaker 1: And to manage the actual YAML complexity you mentioned, helm.
Speaker 2: And customize absolutely. You rarely want to be just copying
Speaker 2: and pasting raw YAML everywhere. RGOCD has first class support
Speaker 2: for Helm, which is kind of the standard package manager
Speaker 2: for Kubernetes.
Speaker 1: Now right for templating and managing dependencies, and.
Speaker 2: Also Customize, which is great for applying environment specific patches
Speaker 2: or variations to base manifests without actually changing the original files.
Speaker 1: You use bases and overlays, so RGOCD works with these
Speaker 1: tools to render the final manifests before applying them exactly.
Speaker 2: It uses the repository server component we talked about to
Speaker 2: run Helm or customize base on your applications tech.
Speaker 1: Okay, now the magic part synchronization. You said by default
Speaker 1: nothing happens when you create an application.
Speaker 2: Correct, and this is surprising but also really important. By default,
Speaker 2: creating an application resource just registers it with rgo CD.
Speaker 2: It doesn't actually apply anything to your cluster yet it
Speaker 2: gives you a chance to review. You can look in
Speaker 2: the UI see what argocd would deploy and make sure
Speaker 2: it looks right before you manually click sink or enable automation.
Speaker 2: It's a safety net.
Speaker 1: Ah okay, a deliberate pause, but you can automate it. Oh.
Speaker 2: Yes, you define a SINK policy in the application manifest.
Speaker 2: This lets you turn on automated.
Speaker 1: SINC And what options do you have there.
Speaker 2: Key ones are pune true, which tells RGOCD to automatically
Speaker 2: delete resources from the cluster if they're removed from get
Speaker 2: garbage collection.
Speaker 1: Essentially important for keeping things clean, and.
Speaker 2: Self heal true this tells RGCD to automatically fix any
Speaker 2: drifted to texts. If someone manually changes something in the cluster,
Speaker 2: self heal will revert it back.
Speaker 1: To the gets stay so truly, enforcing that get source of.
Speaker 2: Truth exactly the thing. Policy also lets you set up
Speaker 2: retry strategies. If a sinc fails with backoffs and.
Speaker 1: Limits, what about controlling things at a finer grain than
Speaker 1: the whole application you.
Speaker 2: Can You can use Kubernetes annotations directly on individual resource
Speaker 2: manifests in get what. For instance, you might annotate a
Speaker 2: persistent volume claim with rgocd dot rgoprojei dot iosinc options
Speaker 2: prune false to prevent argo CD from ever deleting it
Speaker 2: even if it's removed.
Speaker 1: From gitt ah protecting stateful things right.
Speaker 2: Or there's skip dry run and missing resource true, which
Speaker 2: can be useful if your application installs its own crds
Speaker 2: or operators. Sometimes the dry run fails initially because the
Speaker 2: CRD isn't there yet, So this lets you bypass that
Speaker 2: check for specific resources.
Speaker 1: Okay, annotations for fine tuning. What about running tasks during
Speaker 1: SINC like database migrations.
Speaker 2: That's where hooks come in. RGOCD lets you define Kubernetes
Speaker 2: jobs or pods as hooks that run its specif points
Speaker 2: in the sync life cycle.
Speaker 1: When would you use those?
Speaker 2: You have precinc hooks that run before anything else sincoks
Speaker 2: during the main sync, post sync, after a successful sink,
Speaker 2: sink fail if it bombs out, and even post.
Speaker 1: Delete, so post sync would be perfect for database migrations,
Speaker 1: apply the new app code, then run the migration job exactly.
Speaker 2: Or precinc could be used to say take a database
Speaker 2: backup before and upgrade. Very powerful automation.
Speaker 1: And for really complex apps with lots of dependencies, how
Speaker 1: do you manage the order?
Speaker 2: That's where sink waves are incredibly useful. Sometimes you need
Speaker 2: resource a like a database, to be fully up and
Speaker 2: running before resource b your application starts.
Speaker 1: Right dependencies, sink waves.
Speaker 2: Let you assign numerical waves to your resources using annotations.
Speaker 2: RGCD applies resources in wave order, waiting for resources in
Speaker 2: one wave to become healthy before starting the next wave zero,
Speaker 2: then wave one, wave two, and so on.
Speaker 1: Ah, so you can orchestrate complex rollouts precisely.
Speaker 2: Precisely. It prevents things from failing just because of dependency
Speaker 2: wasn't ready yet.
Speaker 1: One more sinc thing. Ignoring differences Sometimes the live state
Speaker 1: should be different, right, like with autoscaling.
Speaker 2: Good point. Yes, rgo CD lets you configure it to
Speaker 2: ignore specific differences. Maybe you have a horizontal pod autoscaler
Speaker 2: managing the replica's count of a deployment. You don't want
Speaker 2: rgo CD fighting with the HPA, so.
Speaker 1: You tell RGOCD, hey ignore changes to spec Dot replicas
Speaker 1: for this deployment exactly.
Speaker 2: You can configure these ignores at the application level or
Speaker 2: even globally for certain resource types or specific JSON paths
Speaker 2: across your whole RGOCD instance. Very flexible.
Speaker 1: Okay, makes sense. Now what about application health? How does
Speaker 1: rgo CD know if a deployment actually worked?
Speaker 2: It relies heavily on kubernators built in health checks. This
Speaker 2: means defining proper readiness and liveness probes in your deployments
Speaker 2: in state ful sets is absolutely critical.
Speaker 1: Because RGOCD uses those probe statuses to decide if a
Speaker 1: resource and therefore the whole application is healthy exactly if
Speaker 1: your probes aren't set up correctly, rgo CD might think
Speaker 1: app is healthy when it's not, or vice versa.
Speaker 2: Good probes are fundamental to reliable get ops.
Speaker 1: Does argo CD add its own health checks too?
Speaker 2: It does for many standard Kubernetes resource types. It has
Speaker 2: built in logic to understand the health of deployments, services,
Speaker 2: stateful sets, etc. However, there's a catch. Oh a surprising fact, Yeah,
Speaker 2: surprising faction. In the book, the built in health check
Speaker 2: for rgo CD's own application CRD was actually removed by
Speaker 2: default back in argo CD version one point eight.
Speaker 1: Wait, why would they do that and why does it matter?
Speaker 2: It matters if you're doing complex orchestrations where one rgo
Speaker 2: CD application needs to know if another argo CD application
Speaker 2: is healthy before it proceeds, like in the app of
Speaker 2: apps pattern we might discuss.
Speaker 1: Ah, So if you need applications to depend on each
Speaker 1: other's health, you need.
Speaker 2: To explicitly re enable that application health check in the
Speaker 2: main argo CD configment rgo CD cny it's off by default,
Speaker 2: which can trip people up when building those advanced workflows.
Speaker 1: Good tip. Okay, let's shift gears to more advanced topics
Speaker 1: operationalizing this stuff. Authentication and authorization seem crucial.
Speaker 2: Absolutely out of the box, RGCD gives you a single
Speaker 2: admin user. The initial password is in a Kubernet.
Speaker 1: Seekert change it immediately, yes, please?
Speaker 2: Then you can define additional local users. But more realistically,
Speaker 2: in an enterprise setup, you'll integrate with single sign on sso.
Speaker 1: Like using Octa or Google Workspace or something exactly.
Speaker 2: Rgo CD supports standard protocols like openetd Connect, ODC, or
Speaker 2: you can use an identity broker like decks, which can
Speaker 2: then connect to LDFP, SAML, get up whatever your company uses.
Speaker 2: The book uses key cloak as an example of you decks.
Speaker 1: Okay, so users log in with their normal company credentials.
Speaker 1: What about what they can do once logged in.
Speaker 2: That's where rg CDs built in RBAC comes in. Role
Speaker 2: based access control. It governs permissions.
Speaker 1: Does it have default roles?
Speaker 2: Yes? It starts with a powerful role Dot admin and
Speaker 2: a useful role dot readily, but you can define your
Speaker 2: own custom roles using simple CSD policies stored in configmap.
Speaker 1: So you can get really granular, like this team can
Speaker 1: only deploy to the devname space.
Speaker 2: Precisely, and that leads into projects or app project resources.
Speaker 2: These are fundamental for multi tenancy or just organizing things.
Speaker 1: Let do projects control.
Speaker 2: They act as logical groupings for applications. Crucially, they let
Speaker 2: administrators restrict things within that.
Speaker 1: Group, like what kind of restrictions you can.
Speaker 2: Restrict which get repositories applications in that project are like
Speaker 2: to pull.
Speaker 1: From AH security boundaries.
Speaker 2: Exactly which destination clusters or name spaces they can deploy to.
Speaker 2: You can even blacklist or whitelist specific kinds of Kubernetes resources,
Speaker 2: maybe disallow creating cluster rolls from a certain project.
Speaker 1: Wow. Okay, So projects are like security and policy sandboxes
Speaker 1: for groups of applications.
Speaker 2: Yep, and you assign permissions which users or sso groups
Speaker 2: can access the project and what roles they have at
Speaker 2: the project level too.
Speaker 1: There's also something called applications sinc impersonation that sounds important
Speaker 1: for security.
Speaker 2: It is, and it's relatively new from v two point
Speaker 2: one four onwards. It lets you specify a different Kumbinaties
Speaker 2: service account for RGOCD to use what it actually applies
Speaker 2: manifest to a cluster for a specific application.
Speaker 1: Why is that better than ARGOCD just using its own
Speaker 1: default service account.
Speaker 2: Principle of least privilege, the default argo CD service account
Speaker 2: often needs fairly broad permissions to manage crds and things.
Speaker 2: By using impersonation, you can create a dedicated service account
Speaker 2: for an application that only has permissions to manage deployments
Speaker 2: and services in the specific name space. For example.
Speaker 1: Ah so, even if the main RGO CD controller was
Speaker 1: somehow compromised, the blast radius for what it could do
Speaker 1: during a sink is much smaller.
Speaker 2: Exactly, it decouples the control planes permissions from the sink
Speaker 2: execution permissions. Big security win makes sense.
Speaker 1: Okay, what about managing multiple clusters? How does that work?
Speaker 2: RGOCD uses a hub and spoke model. Your main RGO
Speaker 2: CD installation is the hub. It then manages deployments out
Speaker 2: to potentially many spoke clusters.
Speaker 1: The control plane is centralized generally.
Speaker 2: Yes, the hub pushes or more accurately applies the configurations
Speaker 2: defined in get out to the managed clusters.
Speaker 1: How do you add those remote clusters?
Speaker 2: You can use the rgo CLI. There's a command like
Speaker 2: rgo sed cluster ad or more get up style. You
Speaker 2: can define the cluster connection details. API server endpoint credentials
Speaker 2: within a kubernating secret and apply that secret to the
Speaker 2: rgo CD control plane cluster.
Speaker 1: So the cluster definitions themselves live in geit.
Speaker 2: Yep RGOCD watches for secrets labeled correctly and automatically adds
Speaker 2: them as managed clusters.
Speaker 1: Okay, so you have multiple clusters defined. How do you
Speaker 1: deploy the same app to multiple clusters? And application CRD
Speaker 1: only points to one destination?
Speaker 2: Right, correct? A single application resource maps one source to
Speaker 2: one destination, but there are patterns for deploying to many.
Speaker 2: First is the app of apps pattern.
Speaker 1: App of apps? What's that?
Speaker 2: It's basically an rgo CD application whose source git rebo
Speaker 2: contains manifests for other rgo CD applicants meta.
Speaker 1: So one application deploys more application Exactly.
Speaker 2: You might have a staging apps application that deploys the
Speaker 2: specific application resources for your AP service, staging front and staging,
Speaker 2: et cetera. It's great for boost wrapping environments or managing
Speaker 2: application stacks together.
Speaker 1: Clever, what's the other way?
Speaker 2: Application sets? These are designed specifically for this multi deployment scenario.
Speaker 2: Think of an application set as an application factory. A
Speaker 2: factory you define an application set with a template for
Speaker 2: an rgo CD application, but you leave parts like the
Speaker 2: destination cluster or namespace dynamic. Then you use a generator
Speaker 2: generators like what for several A list generator lets you
Speaker 2: just provide a static list of clusters or parameters. A
Speaker 2: cluster generator automatically finds all the clusters registered with rgocd
Speaker 2: and creates an application for each. There's even an sem
Speaker 2: provider generator that can look at your Git hosting like
Speaker 2: GitHub git lab and create applications based on folders or branches.
Speaker 1: It finds wow, so application sets automate creating many so
Speaker 1: smilar applications targeted at different places. Very useful for platform teams.
Speaker 2: Hugely useful, reduces boilerplate can figure dramatically.
Speaker 1: Let's stock more security TLS certificates, connecting to private Git
Speaker 1: repos critical stuff.
Speaker 2: Rgocd obviously supports configuring TLS for its own EPI server
Speaker 2: and UI. You can bring your own CERTs or generate
Speaker 2: self signed ones. It also handles connecting securely to get repositories.
Speaker 2: How for HTTPS repos you can store credentials like username, password,
Speaker 2: or access tokens in Kubernetes. Secrets that rg CD is
Speaker 2: configured to use for SSH. You sort the private key
Speaker 2: in a secret and configure the known host entries again,
Speaker 2: usually via rgo CD's configureent secrets managed.
Speaker 1: Via git ops Okay, standard secure connection methods. What about
Speaker 1: verifying the commits themselves?
Speaker 2: Yes, for extra assurance, you can enable get commit signature
Speaker 2: verification using GTG gpgkeys, so.
Speaker 1: Argo City checks if the commit was signed by a
Speaker 1: trusted developer key before sinking.
Speaker 2: Exactly, you can figure rgo CD with the public keys
Speaker 2: of your trusted committers. If a commit in the tracked
Speaker 2: branch isn't signed or is signed by an unknown key,
Speaker 2: rgo CD can refuse to sink it. It ensures code.
Speaker 1: Provenance, important for regulated environments or just high trust. Okay,
Speaker 1: scaling this up monitoring essential.
Speaker 2: You absolutely should integrate rgo CD with Prometheus for metrics
Speaker 2: collection and Grafana for visualization.
Speaker 1: What kind of metrics do you get?
Speaker 2: You get metrics about argocd itself, CPU memory, usage of
Speaker 2: its components, API requests, latency, number of applications being managed,
Speaker 2: but also crucial metrics about SINC operations, how many sinks
Speaker 2: are happening, how long they take, success failure rates, it
Speaker 2: gives you operational visibility beyond just your own app metrics.
Speaker 1: And getting alerted when things go wrong.
Speaker 2: That's where RGCD notifications comes in. It's an optional but
Speaker 2: highly recommended component. It watches rgo CD.
Speaker 1: Events like sync failed or an app became unhealthy.
Speaker 2: Sync success failure, health degradation, sink starting, lots of triggers.
Speaker 2: Can then send nicely formatted notifications to slack matter, most
Speaker 2: email page, your duty teams, you name. It keeps everyone
Speaker 2: in the loop automatically. Very handy.
Speaker 1: What about keeping rgo CD itself reliable? High availability definitely
Speaker 1: needed for production.
Speaker 2: Rgocd's components, the API server, reposerver, application controller are designed
Speaker 2: to run with multiple replicas for high availability BJA. If
Speaker 2: one pod dies, another takes over. You typically manage this
Speaker 2: with standard Kubernetes deployments and potentially horizontal pod autoscalers.
Speaker 1: And if you have thousands of applications, can one controller
Speaker 1: handle all that reconciliation It.
Speaker 2: Can become a bottleneck for really large scale RGOCD supports
Speaker 2: charding the application.
Speaker 1: Controller starting splitting the work exactly.
Speaker 2: You can run multiple replicas of the controller and rgo
Speaker 2: CD will automatically distribute the applications across them. Based on
Speaker 2: a hashing algorithm, each controller instance only manages a subset
Speaker 2: of the total applications. This prevents one controller from becoming
Speaker 2: a hotspot and improves overall sync throughput okay.
Speaker 1: Jay and scharding for scale. Can you extend rgo CD's
Speaker 1: functionality if it doesn't support your specific tools out of
Speaker 1: the box.
Speaker 2: Yes, through config management plugins CMPs. Let's say you have
Speaker 2: some customs scripting process to generate your Yamel or maybe
Speaker 2: you use a less common tool.
Speaker 1: You can teach rgo CD how to use.
Speaker 2: It pretty much. If you package your tool or script
Speaker 2: into a container image to find how RGOCD should call
Speaker 2: it in the RGCD s endemioconfigmap and rgo CD's repository
Speaker 2: server will run your plug in in a sidecar container
Speaker 2: to generate the manifests. It's very flexible.
Speaker 1: Nice. What about customizing the look and feel of the UI.
Speaker 2: You can do that too. You could apply custom CSS
Speaker 2: style sheets to change colors, fonts, layout, maybe make the
Speaker 2: top bar red in your production. Rgo CD instances as
Speaker 2: a visual cue.
Speaker 1: Simple but effective. Can you add new UI elements?
Speaker 2: Yes? Through UI extensions. These are more involved. You basically
Speaker 2: build custom react components that get loaded into the RGO CDUI.
Speaker 2: You could use this to add buttons that trigger external
Speaker 2: actions or display information from other systems right within the
Speaker 2: RGO CD interface.
Speaker 1: Cool. Last major area integration with CI. How does rgocd
Speaker 1: fit into the broader CICD pipeline.
Speaker 2: Good question. We mentioned The reconciliation loop runs periodically, maybe
Speaker 2: every three minutes by default, but often you want changes
Speaker 2: deployed faster.
Speaker 1: Right as soon as they merge to maine.
Speaker 2: That's where web hooks come in. You can figure get GitHub,
Speaker 2: get lab, et cetera to send a webook notification to
Speaker 2: argocd whenever there's a push to the track branch. Rgo
Speaker 2: CD can then immediately trigger a refresh and sink if needed.
Speaker 2: It provides that on demand synchronization, so.
Speaker 1: You get the continuous reconciliation and fast updates via web hooks.
Speaker 2: Best of both worlds. And you can integrate this further,
Speaker 2: maybe your CI process using something like Tecton pipelines.
Speaker 1: Tecton the Kubernetes native CICD tool.
Speaker 2: Right your Tecton pipeline could run tests, lynch your manifests,
Speaker 2: maybe build an image and then as a final step.
Speaker 2: After everything passes, it merges the change, which then triggers
Speaker 2: the RGO CD web hoook.
Speaker 1: So CI handles the validation before getaps takes over for
Speaker 1: deployment exactly.
Speaker 2: You can even have tech ton directly interact with the
Speaker 2: RGO CD API if needed. Technon triggers can listen forget
Speaker 2: events to start these pipelines automatically. It creates a really robust,
Speaker 2: fully automated flow from code commit to running.
Speaker 1: In the cluster that paints a really comprehensive picture looking ahead.
Speaker 1: What are some ongoing discussions or future considerations in the
Speaker 1: getop space.
Speaker 2: One big one, especially for organizations starting out, is getops
Speaker 2: directory structures. How should you actually organize your repositories?
Speaker 1: Is there one right answer?
Speaker 2: Not really? The book mentions it often comes down to
Speaker 2: Conway's law. Your org structure influences your system design. Some
Speaker 2: for poly repos maybe one repo for the cluster platform
Speaker 2: stuff and separate reapers for each application. Others go for
Speaker 2: large monerapos containing everything.
Speaker 1: Pros and cons to both.
Speaker 2: I imagine definitely CALLI repos give teams more autonomy, but
Speaker 2: can be harder to coordinate. LONO repos make cross cutting
Speaker 2: changes easier, but require more tooling and discipline.
Speaker 1: What about storing rendered manifests you mentioned that earlier, Yes.
Speaker 2: The rendered manifest pattern. Instead of rgo CD pulling helm
Speaker 2: charts or customized bases and rendering them.
Speaker 1: On the fly, you pre render them in your CI
Speaker 1: pipeline and commit the final YAML to get exactly.
Speaker 2: The benefit is absolute clarity. What's in GET is exactly
Speaker 2: what rgo CD will apply. No surprises from template rendering
Speaker 2: logic changing between environments. It makes auditing and diffing much simpler.
Speaker 1: Interesting trade off, more CI work, but simpler.
Speaker 2: Geit ops state right and related to get structure is
Speaker 2: the recommended GitOps workflow. The book strangly advocates for trunk
Speaker 2: based development as.
Speaker 1: Opposed to something like gitflow with long lived develop staging
Speaker 1: main branches.
Speaker 2: Yes, the problem with long lived environment branches in a
Speaker 2: geitops world is that environment specific configuration like replica accounts
Speaker 2: or URLs tends to diverge. Merging between these branches becomes
Speaker 2: a nightmare, ah.
Speaker 1: Because you don't want stagings can fig merged into production exactly.
Speaker 1: Trunk based development where changes flow quickly to the main
Speaker 1: branch and configuration differences are handled by tools like Customize
Speaker 1: or helm values outside of Git. Branching generally works much
Speaker 1: better with the gt ops model.
Speaker 2: Good practical advice Where can people go to learn more
Speaker 2: or get involved?
Speaker 1: The community is really active. The CNCF slack has hashtag
Speaker 1: giittops and hashtag rgo CD channels, which are great places
Speaker 1: to ask questions.
Speaker 2: Okay, CNCs slack.
Speaker 1: Attending the public Argo project community meetings online is also
Speaker 1: a good way to see what's happening and check out
Speaker 1: projects incubating in Argo project labs. Likewise, there's the rgo
Speaker 1: CD image updater, which helps automate updating container image tags
Speaker 1: and get and a newer, more holistic project called cargo
Speaker 1: is emerging focused on orchestrating promotions and progressive delivery across
Speaker 1: different stages in a geit ops environment. It looks very promising.
Speaker 2: Lot's happening. Okay, let's try to wrap this up. We've
Speaker 2: really unpacked rgo CD and get ops today from weave workes,
Speaker 2: fat finger origin story, the core git ups principles.
Speaker 1: Declarative version pulled reconciled to rg CD's architecture, the controller pattern,
Speaker 1: how you interact via UI and CLI managing applications with sources, destinations,
Speaker 1: sink policies, hooks, waves.
Speaker 2: All the way to advance topics like security, multi cluster
Speaker 2: with apsets, ha charding extensibility.
Speaker 1: Right, you should now have a really solid foundation. This
Speaker 1: deep dive gives you that understanding of how it all
Speaker 1: clicks together.
Speaker 2: You've definitely got more than just the buzzwords, now practical insights,
Speaker 2: some of those surprising details like the application health check
Speaker 2: default hopefully helping you navigate get ups with more confidence.
Speaker 1: So here's a final thought to leave you with. If
Speaker 1: GIT truly becomes the single source of truth for our
Speaker 1: system's desired state, how might that change the way we
Speaker 1: think about all kinds of operational changes in our organizations
Speaker 1: beyond just application deployments. What else could we managed declaratively
Speaker 1: via get It's.
Speaker 2: A powerful shift in thinking, moving from imperative actions to
Speaker 2: declare of state management. Definitely something to moll over. And
Speaker 2: of course check out the book rg CD up and
Speaker 2: Running for even more detail and engage with that vibrant
Speaker 2: GitOps community.
Speaker 1: Absolutely, there's always more to explore. Thanks for joining us
Speaker 1: on the deep dive.