Speaker 1: Welcome to the deep dive. Okay, so you've given us
Speaker 1: this really dense stack of sources. It looks like it
Speaker 1: takes us right from the basics the core of a
Speaker 1: Linux server all the way up to managing stuff across
Speaker 1: multiple clouds.
Speaker 2: Yeah, that's the idea.
Speaker 1: So our mission today it's pretty simple. We're giving you
Speaker 1: the shortcut. We're not going to wade through, you know,
Speaker 1: setting up servers by hand, definitely not. We're cutting straight
Speaker 1: to the strategic stuff, the why and the how of
Speaker 1: real DevOps automation exactly.
Speaker 2: This deep dive it really tracks a huge shift in
Speaker 2: it thinking. I mean, we're moving from system admins clicking
Speaker 2: through installs one by one the old way right towards
Speaker 2: a true DevOps model, and that's all about speed, being
Speaker 2: able to audit everything, and well collaboration. The main thing
Speaker 2: is breaking down those old walls using automation to get
Speaker 2: things delivered faster and crucially reliably.
Speaker 1: Okay, so we'll start with the basics, the foundation links, fundamentals,
Speaker 1: and then pretty quickly ramp up towards infrastructure as cotatchies, containers, Kubernetes,
Speaker 1: and and multi cloud strategies.
Speaker 2: Think of it as your quick start guide. We want
Speaker 2: you to get the whole picture, focusing on the insights
Speaker 2: you really need, not all the low level detail.
Speaker 1: Got it, Let's dive in app Okay, let's start right
Speaker 1: at the beginning. Then Linux it's open source, which means
Speaker 1: lots of different versions. Right, Distributions are distros.
Speaker 2: Yep created by different groups, companies, communities.
Speaker 1: So what's the like the strategic difference when you're choosing
Speaker 1: between the big ones.
Speaker 2: Well, it really boils down to risk versus reward, especially
Speaker 2: around support. So on one side, you've got Red Hat
Speaker 2: Enterprise Linux RHL, that's your corporate choice, the subscription model.
Speaker 1: You pay for it.
Speaker 2: You pay, but you get guaranteed support, stability that's certified,
Speaker 2: and this is important compatibility with their enterprise software like
Speaker 2: JBoss and stuff.
Speaker 1: Okay, stable, supported, predictable exactly.
Speaker 2: Then on the other side you have things like Debian
Speaker 2: and it's very popular derivative Ubuntu. These are fully community maintained,
Speaker 2: so free as in cost, yes, maximum freedom. But you know,
Speaker 2: if something breaks, you're leaning on the community forums, mailing lists.
Speaker 2: The fix isn't guaranteed on a deadline.
Speaker 1: It's that classic trade off then, paid certainty versus free
Speaker 1: community efforts precisely. Okay, So once you've picked your OS,
Speaker 1: we're talking about putting it on a server. And the
Speaker 1: sources remind us a server is really just a powerful
Speaker 1: computer doing a specific job, like hosting a website or
Speaker 1: running a database.
Speaker 2: That's all it is. And when you pick the software
Speaker 2: for that job, you're defining what we call a stack.
Speaker 1: A stack like a set of tools to solve a
Speaker 1: particular problem.
Speaker 2: Right, you define the solution by the tools you choose.
Speaker 2: Everyone knows the classic LMP stack, right, Linux, APATCHEQL, PHP.
Speaker 1: The original workhorse totally.
Speaker 2: But modern stacks are way more varied. The sources mentioned
Speaker 2: one NPM and Jinx as the web server, piping for
Speaker 2: the application itself, and Mango dB for the database, different
Speaker 2: tools for different needs.
Speaker 1: And the last bit of this foundation, where does the
Speaker 1: server actually live? We're shifting here too, aren't we, from
Speaker 1: on premise to cloud big shift on premise.
Speaker 2: That meant the servers were physically inside the company in
Speaker 2: their own data center, maybe even under someone's desk.
Speaker 1: Huh hopefully not, hopefully not.
Speaker 2: But they own the hardware, the cooling, everything. They manage
Speaker 2: their own virtual machines too, maybe using tools like open stack.
Speaker 1: Or overt right at the cloud.
Speaker 2: Cloud just means those virtual servers are running on someone
Speaker 2: else's hardware in a third party's huge data center think AWS, Azure, GCP.
Speaker 1: And the big advantage there.
Speaker 2: Elasticity and cost. Mostly you can spin up resources when
Speaker 2: you need them and crucially turn them off when you don't,
Speaker 2: like overnight or weekends. You only pay for the run
Speaker 2: time and storage you actually consume. That can be a
Speaker 2: massive cost saving for organization.
Speaker 1: Makes sense. Pay for what you use. Yeah, all right,
Speaker 1: so we have our servers maybe in the cloud, but
Speaker 1: once you get more than a handful, doing things manually
Speaker 1: just breaks down right immediately.
Speaker 2: It doesn't scale. That's where automation becomes absolutely essential. And
Speaker 2: the first tool pretty much everyone learns is Bash.
Speaker 1: Bash the command line.
Speaker 2: Yeah, the command line interpreter, but it's also a scripting language.
Speaker 2: It's the system admin's Swiss army knife, you know, great
Speaker 2: for automating simple repetitive things like whati oh, rotating log files,
Speaker 2: checking if disk space is low, restarting a service, quick,
Speaker 2: imperative commands.
Speaker 1: Imperative. That's the key word here, isn't it. Bash tells
Speaker 1: the system how to do something step by step.
Speaker 2: Exactly. Step one, do this, step two do that.
Speaker 1: But if you're trying to set up say fifty identical
Speaker 1: web servers, writing a Bash script for that gets complicated fast.
Speaker 1: You're downloading ISO images, figuring out disc allocation.
Speaker 2: Oh yeah, dynamic allocation for your test lab maybe, but
Speaker 2: fixed size for production so you don't accidentally fill up
Speaker 2: the whole storage system. It's slow, it's prone to errors.
Speaker 2: That whole pain point is really what led to infrastructure
Speaker 2: as card I see. Absolutely nobody wants to sit there
Speaker 2: manually prove visioning one hundred vms every day. IC is
Speaker 2: the answer for the provisioning part, setting up the infrastructure itself.
Speaker 2: It goes way beyond just simple task scripting.
Speaker 1: So tools like Vagrant come in here.
Speaker 2: Vagrant is often the first IC tool developers meet. Instead
Speaker 2: of you know, clicking through all the virtual box setup screens,
Speaker 2: defining memory disk size, enabling virtualization in the bios. Yes,
Speaker 2: you just write a simple configuration file code. Vagrant reads
Speaker 2: that code, talks to virtual box, and automatically builds the
Speaker 2: VM for you. It usually uses pre built OS images
Speaker 2: they call them boxes from places like Vagrant Cloud gets
Speaker 2: the BASEOS installed instantly.
Speaker 1: Okay, so that's a huge leap. We've gone from telling
Speaker 1: the computer how to run each step with Bash to
Speaker 1: just declaring what we want the end result to look
Speaker 1: like with Vagrant and IIC.
Speaker 2: That's the core philosophical shift. It makes the whole process repeatable, consistent,
Speaker 2: and auditible. If your code says you need three gigs
Speaker 2: of RAM, you get three gigs of RAM every single
Speaker 2: time nopes I click the wrong button.
Speaker 1: Automation is getting serious now, but we can accelerate even more. Right.
Speaker 1: Moving beyond full virtual machines to containers, let's talk Docker.
Speaker 1: People often call it lightweight virtualization. What's actually happening under
Speaker 1: the hood in Linux?
Speaker 2: Yeah, lightweight's a good description. Fundamentally, a container is about
Speaker 2: isolating processes and their filesystems. Think of it like an
Speaker 2: advanced version of an old Linux command crut. It creates
Speaker 2: a sort of walled off directory that acts like its
Speaker 2: own little OS.
Speaker 1: Install walled off.
Speaker 2: Yeah. It uses Linux kernel features control groups name spaces
Speaker 2: to keep the container's resources. It's network traffic, it's view
Speaker 2: of the filesystem separate from the host and other containers.
Speaker 2: That's what makes it so portable. Everything the app needs
Speaker 2: is bundled inside Okay, so let's.
Speaker 1: Walk through an example. Say we're developing a simple web
Speaker 1: app and Python using the Flask framework. How does the
Speaker 1: whole container ecosystem build up around that to make it
Speaker 1: ready for production?
Speaker 2: Right, So you start coding with Flask, but flask itself
Speaker 2: it even warns you it's built in server is just
Speaker 2: for development. It's not tough enough for real traffic.
Speaker 1: Okay, so step one need a better.
Speaker 2: Server exactly for production. You need a proper WSGI server
Speaker 2: that stands for a Web Server Gateway interface. It's a
Speaker 2: standard way for Python web apps to talk to web servers.
Speaker 2: Guncorn is a really popular one.
Speaker 1: Gunnacorn handles the Python part robustly, but you still need
Speaker 1: something to face the public internet right to handle all
Speaker 1: the incoming connections.
Speaker 2: You got it. You need a traffic cop out front
Speaker 2: reverse proxy precisely. Typically you'd use something like in jincs.
Speaker 2: Jinx is fantastic at handling tons and tons of simultaneous connections.
Speaker 2: It does a few key things. It can load balance
Speaker 2: traffic if you have multiple guncorn.
Speaker 1: Workers, spreads the load yep.
Speaker 2: It can also cash static files your images, CSS, JavaScript.
Speaker 2: That stuff doesn't need to hit the Python app every time,
Speaker 2: and jinc serves it directly, which is super.
Speaker 1: Fast, takes load off the application server exactly.
Speaker 2: It only forwards the request that actually need dynamic processing,
Speaker 2: like fetching data from a database back to Gunnicorn. This
Speaker 2: massively reduces the CPU load on your application servers and
Speaker 2: makes everything much faster and more responsive.
Speaker 1: Okay, so now we have this perfectly packaged production ready
Speaker 1: container with then Jenks and Gunnicorn and our app. But
Speaker 1: one container isn't usually enough, is it? What happens when
Speaker 1: we need hundreds running across lots of physical machines, Doctor
Speaker 1: swarm maybe isn't.
Speaker 2: Quite enough right at that scale, you need serious orchestration.
Speaker 2: You need Kubernetes K eight's the eight hundred pound Gorilla
Speaker 2: pretty much. It's the standard now originally based on Google's
Speaker 2: internal system called Borg. When you're managing hundreds, maybe thousands
Speaker 2: of containers, the real challenge is maintaining the state you want. Declaratively,
Speaker 2: you tell Kubernetes I want five copies of my web
Speaker 2: server running and it makes it happen.
Speaker 1: How does it manage that? What are the key concepts
Speaker 1: we need to grasp?
Speaker 2: Okay, three key objects to start with. First is the pod.
Speaker 2: That's the smallest thing you can employ in Kubernetes. It's
Speaker 2: basically one or moreiners that are always scheduled together, run
Speaker 2: on the same node, and share resources like networking and storage.
Speaker 1: So a pod might have my Jinx container and my
Speaker 1: Gunicorn container running.
Speaker 2: Side by side exactly. Then you have the deployment. Think
Speaker 2: of this as the rulebook for your application. It defines
Speaker 2: how many copies or replicas of a pod you want
Speaker 2: running at all times. If a pod crashes, the deployment
Speaker 2: controller notices and starts a new one automatically to get
Speaker 2: back to the desired.
Speaker 1: Number self healing. Nice. Okay, pods are the runners, deployments
Speaker 1: are the rules. What's the third piece? How do users
Speaker 1: actually reach these pods? If they can come and go?
Speaker 2: Ah, that's the service. Pods are ephemeral, right, They can
Speaker 2: be destroyed and recreated, and they'll get new internal IP addresses.
Speaker 2: You can't rely on those ips. A service provides a stable,
Speaker 2: single point of contact. It maps a fixed IP address
Speaker 2: maybe an internal cluster IP or an external load balancer IP,
Speaker 2: to the group of pods managed by a deployment.
Speaker 1: So the service acts like a permanent front door even
Speaker 1: if the rooms behind it keep changing.
Speaker 2: Perfect analogy. It ensures traffic gets to healthy pods, enabling
Speaker 2: real scaling and resilience without users noticing pods restarting.
Speaker 1: Okay, it makes sense, But now we have potentially thousands
Speaker 1: of these pods spitting out logs across maybe hundreds of servers.
Speaker 1: Checking logs manually is.
Speaker 2: Impossible, utterly impossible. Forget tailing log files at this scale.
Speaker 2: You need centralized logging instantly, and.
Speaker 1: That's where the efkstack comes in.
Speaker 2: Yeah, EFK, elastic Search, Fluent, and Cubana. It's pretty standard
Speaker 2: practice in Cubernetes environments. Flunid is the log collector and shipper.
Speaker 2: It usually runs as a small agent on every single
Speaker 2: node in your cluster, grabs all the container log streams
Speaker 2: and sends them off, sends them where to elastic search.
Speaker 2: That's the powerhouse. It receives all these logs, parses them,
Speaker 2: indexes them so they're searchable, and stores them. It's built
Speaker 2: for handling huge volumes of text data.
Speaker 1: Okay, logs collected, indexed, how do we actually use them?
Speaker 2: That's Cubana. Cubana is the web interface on top of
Speaker 2: elastic Search. It lets you search across all your logs
Speaker 2: from all your containers in near real time. You can
Speaker 2: search for specific errors, filter by application, timeframe, whatever you need.
Speaker 2: Plus you can create dashboards visualized trends like graphing the
Speaker 2: number of four hundred and four or five hundred errors
Speaker 2: over time, invaluable for troubleshooting and monitoring.
Speaker 1: Right, so, we've built the infrastructure, we've containerized and scaled
Speaker 1: the application. We're logging everything centrally. But there's another big
Speaker 1: challenge organizations face today dealing with multiple cloud providers, the
Speaker 1: rise of multi cloud. We've got the big three AWS, GCP, Azure.
Speaker 2: Yep, the titans AWS is you know, the original Giant
Speaker 2: still the main player, has an absolutely massive range of
Speaker 2: services for almost anything, would be full choice for many
Speaker 2: often Yeah, then you've got GCP, Google Cloud a bit newer,
Speaker 2: often seen as being strong in data analytics and machine learning,
Speaker 2: things like big Query for huge data sets, specialized hardware
Speaker 2: for tensoflow, and sometimes it's cheaper, especially for raw compute power.
Speaker 1: Interesting and Azure.
Speaker 2: Azure is Microsoft's cloud, so its big strength is integration
Speaker 2: with the Microsoft ecosystem. If your company relies heavily on
Speaker 2: Windows Server Active Directory SQL server. Azure often makes the
Speaker 2: most sense, is generally seen as very reliable, very enterprise focus,
Speaker 2: but often the most expensive of the three.
Speaker 1: Okay, so they each have their niches. But the problem
Speaker 1: comes when a company wants to use services from more
Speaker 1: than one. Right, maybe they need Azure Active Directory for identity,
Speaker 1: by the one GCP's Big Query for analytics, and perhaps
Speaker 1: they run some Core apps on AWS using Dynamo dB.
Speaker 2: Exactly that's becoming super common. But managing that Each cloud
Speaker 2: has its own way of doing things, its own dashboard,
Speaker 2: and crucially, its own command line interface the awscli, Google's
Speaker 2: u cloud Cli, azures as cli. They all work differently,
Speaker 2: different commands, different syntax.
Speaker 1: It's chaos trying to automate across them.
Speaker 2: Total chaos, inconsistent, complex, aero prone. And that specific problem
Speaker 2: managing infrastructure consistently across multiple providers is exactly what Hashi
Speaker 2: Core's Terraform was built to solve.
Speaker 1: Caere Form the big name in IAC.
Speaker 2: It's become the de facto standard for multi cloud infrastructure
Speaker 2: s code. Its brilliance is that it lets you define
Speaker 2: your infrastructure, servers, databases, networks, load balancers, everything using one
Speaker 2: single universal syntax. In its configuration.
Speaker 1: Files one syntax for all clouds.
Speaker 2: One syntax. You write your Terraform code describing what you want,
Speaker 2: and Terraform itself figures out how to talk to the
Speaker 2: specific APIs of AWS or GCP or Azure or dozens
Speaker 2: of other providers to make it happen.
Speaker 1: So if Vagrant brought iac to managing single vms easily,
Speaker 1: Terraform brings that same declarative power to managing your entire
Speaker 1: complex multi cloud setup.
Speaker 2: That's a great way to put it. It manages the
Speaker 2: state of your whole infrastructure, and probably its most critical
Speaker 2: feature isn't even the apply part. It's the safety that
Speaker 2: it provides before you apply changes.
Speaker 1: You mean, the planning step.
Speaker 2: Absolutely, the Terraform plan command before you actually change anything.
Speaker 2: You run plan Terraform reads your code, checks the current
Speaker 2: state of your actual live infrastructure. It keeps track of
Speaker 2: this in a state file and tells you precisely what
Speaker 2: it intends to do.
Speaker 1: What it will add, change or dot delete exactly.
Speaker 2: It shows you this resource will be created, plus this
Speaker 2: one will be modified, and the really scary one, this
Speaker 2: resource will be destroyed. That preview, that ability to see
Speaker 2: the potential impact and catch mistakes before you accidentally delete
Speaker 2: your production database. It's an absolutely essential guardrail for managing
Speaker 2: complex infrastructure safely.
Speaker 1: Okay, we've used Terraform to build it. We use Docker
Speaker 1: and Kubernators to deploy and scale the app. Yeah, what's
Speaker 1: the final piece tying all this automation together, Getting code
Speaker 1: from a developer's laptop into production reliably. The CICD pipeline right.
Speaker 2: CICD often orchestrated by tools like Jenkins get lab, CI
Speaker 2: GitHub actions. There are many CI stands for continuous integration.
Speaker 1: Checking the code quality automatically.
Speaker 2: Pretty much every time a developer commits code, the CI
Speaker 2: server automatically pulls it, builds it, and runs a series
Speaker 2: of checks unit tests, integration tests, maybe static code analysis
Speaker 2: tools like linters. The goal is to catch bugs early
Speaker 2: and often makes sense fail fast exactly. Then if all
Speaker 2: those cichecks pass, you move to CD. That can mean
Speaker 2: continuous delivery or continuous deployment. Continuous delivery means the code
Speaker 2: is proven ready to deploy, maybe with one final manual
Speaker 2: approval click. Continuous deployment means it goes all the way
Speaker 2: out to.
Speaker 1: Production automatically, now fully automated.
Speaker 2: The goal is to be able to reliably push new
Speaker 2: versions frequently. And this whole complex workflow, build, test, deploy
Speaker 2: is itself defined as code, pipeline as code they call it.
Speaker 2: So the delivery process itself is versioned, repeatable and auditible,
Speaker 2: just like the infrastructure.
Speaker 1: Okay, wow, we have really covered a lot of ground.
Speaker 1: We went from the Linux foundation, the.
Speaker 2: Different district RHL versus w Nbuntu, through Bash scripting, the
Speaker 2: limitations there, and then the big philosophical leap to infrastructure
Speaker 2: as code with tools like Vagrant and crucially paraform for
Speaker 2: managing multi.
Speaker 1: Cloud Declarative configuration became key.
Speaker 2: Then we got into modern application delivery Docker cant the
Speaker 2: jin scuncorn pattern and scaling it all with Kubernetes, understanding pods,
Speaker 2: deployments and especially services to connect the moving parts and
Speaker 2: not forgetting centralized logging with EFK for managing that scale.
Speaker 1: Right, The whole journey shows this relentless drive towards automation.
Speaker 2: Doesn't it the overarching theme? It isn't just knowing the
Speaker 2: individual tools, is it. It's understanding that automation has to
Speaker 2: deliver resilience, consistency and auditibility. That's the goal.
Speaker 1: So let's leave you with a final thought to chew on.
Speaker 1: If the ultimate goal for a professional DevOps engineer is
Speaker 1: to build infrastructure that's so well defined by code that
Speaker 1: you could literally destroy it and recreate it perfectly identically
Speaker 1: in moments, what people often call immutable infrastructure the dream state.
Speaker 1: Can you realistically achieve that by clicking around in cloud
Speaker 1: provider dashboards or by relying on a patchwork of custom
Speaker 1: Bash scripts? Or is the unified declarative plan and apply
Speaker 1: approach of something like terraform the only truly sustainable way
Speaker 1: to manage the sheer, complexity and scale of modern, often
Speaker 1: multi cloud reality.
Speaker 2: How you answer that probably defines your approach as a
Speaker 2: modern engineer, something.
Speaker 1: They think about. That's all the time we have for
Speaker 1: this deep dive. Thanks for joining us, See you next time.