Charles Max_Wood:
Hey everybody and welcome back to another episode of the Ruby Rogues Podcast. This week on our panel we have Valentino Stoll. I'm Charles Maxwood
Valentino_Stoll:
And now...
Charles Max_Wood:
from Top End Devs. Quick reminder about Rails Remote Conf coming up at the end of September. We have a special guest this week, and that's Cameron Dutrote. Cameron, do you wanna just remind people who you are?
Cameron_Dutro:
Sure, yeah, I'm Cameron Dutro. I work at GitHub and I am here to talk about a deployment solution that I wrote called Kubi.
Charles Max_Wood:
Very cool. Now, Kube, you know, just doing a little bit of homework here. It does Docker Kubernetes magic. And yeah, you know, my DevOps skills used to be current and then they invented all this container stuff. So, yeah,
Cameron_Dutro:
Right.
Charles Max_Wood:
I'm kind of liking the idea of a Kube, right? Do you want to give people kind of the elevator pitch, you know, what it is, what it's for, for people to use stuff like that.
Cameron_Dutro:
Yeah, for sure. And yeah, first of all, thanks for having me on. Kubi and deployment and something and stuff like that is really near and dear to my heart. And the actual story behind Kubi actually starts with an episode of the RubyRogues podcast.
Charles Max_Wood:
Woo!
Cameron_Dutro:
I know, it's kind of come in full circle. So let's see, I think it's, I'm going to have to look this up, but it's episode 300 something of the podcast. and talked about why, or sort of one of the problems or the holes that he sees in Rails, which is that there's no active deployment for Rails apps. And so what he meant by that was, we have all these other great frameworks in Rails for interacting with the database. We have active record for that and active storage for storing files in the cloud,
Charles Max_Wood:
Uh huh.
Cameron_Dutro:
action text, all these other cool frameworks, but we don't have anything for deployment. And that's kind of funny, like things that you want to do with your app. Once you're finished building it, you want to put it online somewhere and there's not really a set solution out of the box that Rails has for that. And so on the podcast, Stefan was saying like, I don't really know if that needs to be a tool or if it just needs to be an official Rails guide or what, but it would be nice to have some official guidance in that regard. So I heard that episode and thought that he was totally right and I didn't really understand you know, sort of a blessed path for that, for Rails. And so fast forward a couple years, didn't think that it was going to be me that was going to work on that because, like
Charles Max_Wood:
Mm-hmm.
Cameron_Dutro:
you mentioned, Chuck, my DevOps skills were not fantastic. And it wasn't something that I really had specialized in my career. So I was like, well, maybe one day, maybe Stefan himself will do this. Maybe somebody else will step up and build a deployment solution for Rails that is
Charles Max_Wood:
Right.
Cameron_Dutro:
kind of the de facto. But in the intervening years, nobody really did that. You know, kept that in the back of my mind. And then a couple of years later, the company I worked for at the time, Lumos Labs, started to use and adopt Kubernetes to deploy Lumasi.com, the big monolith that we had for Lumasi.com.
Charles Max_Wood:
Mm-hmm.
Cameron_Dutro:
And we used, initially we used Docker and ECS for that, the Elastic Container Service, which is like Amazon's
Charles Max_Wood:
Right.
Cameron_Dutro:
sort of precursor to Kubernetes. And ECS is fine, it's kind of bare bones. You know, everything runs in containers, but it's not particularly easy to use their interface. And, you know, it really just runs containers. It doesn't do anything else besides that. So no databases, you know, no Redis, for example, you'd have to set all that stuff up yourself manually. So we used that for a long time. And then hired somebody who actually had much more experience with Kubernetes. And he started to convert all of us over Kubernetes and also, you know, the we also adopted a deployment web app called Samson by Zendesk and started to sort of deploy everything with that setup. And, you know, there's a moment for me where I just I remember sort of watching over his shoulder and we were deploying the Masi.com for kind of the first time and I
Charles Max_Wood:
Thanks for watching!
Cameron_Dutro:
was watching the the output scroll by and watching the output from things stood up automatically. And it was just, it was one of those moments that you have sometimes in tech where you're just like super blown away by how just magical the tool is. I'll never forget how amazed I was that it was doing all these things automatically when you just would configure what you wanted the tool to do and then it would go do it and make sure your app was running and all the other important parts to make sure your app stays up. I mentioned that we had background jobs, I think, or most apps do. And so it would start up the background job processor and connect to a Redis. And all that stuff just kind of happened automatically. There was no intervention necessary. And so that was a real light bulb moment. And so when that happened, I thought, why don't we do this? Why doesn't Rails have something like this that runs on Kubernetes that anybody could take advantage of? And so that's how Kuby was born. You had asked what Kubi is, I just gave sorts of background. Kubi is
Charles Max_Wood:
Mm-hmm.
Cameron_Dutro:
a deployment tool. I want it to be active deployment for Rails. It's written to be very simple, minimal configuration. I think the tagline for a long time was, deploy your app with almost, use Kubernetes with almost no configuration because Kubernetes is kind of known for being very config heavy
Charles Max_Wood:
Mm-hmm.
Cameron_Dutro:
and Kubi is very config light. It makes a lot of intelligent default choices feel like you might expect as a Rails Dev. you can put your config in there and all your config really is is just a couple of credentials so you know I want to deploy to DigitalOcean or Linode or EKS, Azure's Kubernetes offering any of those we have plug-in providers for those things. You configure those, you tell it where you want to push your Docker image and then you run a few commands and next thing you know your app is online and being served and conserved traffic. So yeah that's that's kube in a nutshell.
Charles Max_Wood:
Nice, yeah, I mean, this is the thing that's kind of hung me up is that, so I like running my app in a Docker container locally. I mean, it's really convenient because I don't have to go and like sandbox crap or use a gem set for our VM or anything like that, right? I just, hey, install the stuff I need. Okay, done, right? Oh, I need a different version of Ruby now, okay. It's really
Cameron_Dutro:
Mm-hmm.
Charles Max_Wood:
convenient locally. But then I started looking at Kubernetes, right? Because I've been hosting on DigitalOcean forever.
Cameron_Dutro:
Yeah.
Charles Max_Wood:
And I was thinking, okay, well, now I've got top end devs. I'm also incidentally using the same code base for a podcast playbook. And so it's got an admin system that I've put on a separate server from the main site that hosts all the courses and stuff for people. stuff going on with like Redis and PostgreSQL and things like that. And, uh, you know, I'm, I'm using kind of their cloud database hosting for that. But, you know, eventually I'm going to have to scale it, or at least I'm hoping eventually I'll have to scale it. Right. And so then I'm
Cameron_Dutro:
Right.
Charles Max_Wood:
going to need a load balancer and I'm going to need, you know, more than one server running this stuff. And so, um, I was thinking, oh, cool. I'll just, you know, I'll figure out Kubernetes and try and, and use it. was so overwhelming that I was just like, you know, maybe I'll just stick this on VPSs for right now.
Cameron_Dutro:
Yeah.
Charles Max_Wood:
And then hopefully when I have that problem, I'll also have budget to hire somebody who really can do this for me. And so
Cameron_Dutro:
Yeah.
Charles Max_Wood:
that's where this appeals to me, right? Is it's like, okay, well, now I can put this on Docker containers, I can use some kind of Docker or container registry, and then hopefully I can, I can do this on my own and be my own IT guy for a little longer before I have to hire somebody to manage all this stuff. And I'm assuming too at some scale, you're gonna want somebody that just does all the monitoring and management stuff. But for now, it's just me.
Cameron_Dutro:
Yeah. Yeah, right. Well, no, I mean, that's really, I think, an important like point to make that, you know, web development and building websites, putting them online can be a very specialized job. Right. Like you talk about hiring an Ops person. That's really how a lot of companies are organized. There's the devs who work on the actual features. And then there are Ops people who make sure that the website's up and job title that's kind of common these days is site reliability engineer. So they're responsible for
Charles Max_Wood:
Yeah.
Cameron_Dutro:
making sure the site's up all the time. And, you know, there can sometimes be, you know, maybe a contentious relationship between the devs and the ops people. And that's, I think, really why DevOps became a thing, right? So now we've got people who do both dev and ops or do dev as part of ops. And so there's
Charles Max_Wood:
Mm-hmm.
Cameron_Dutro:
a lot more crossover there. But I want to also call out how learning curve of a lot of these ops tools, like not even just Kubernetes, but a lot of ops tools are really complicated.
Charles Max_Wood:
Oh yeah.
Cameron_Dutro:
They're geared much more toward, you know, someone who does it full time, someone who used to be a network or sysadmin, you know, who is like very familiar with firewall rules. And I mean, you know, networking in general, and that's really, in my experience, not the average Rails dev. Most average Rails devs are slinging code in Ruby and writing features and, you know, doing that stuff when it comes to the ops side, there's a lot less confidence they have there that what they're doing is the right thing and a lot of times, you know, they open up security holes. They don't mean to because they don't understand the tooling. And so, you know, when I started to realize is that most devs would rather not have to care about ops at all. They
Charles Max_Wood:
Mm-hmm.
Cameron_Dutro:
want to care about it exactly 0% of the time. And there are great tools out there. I mean, you have the opportunity as a dev to use, a bunch of different deployment solutions. It's not like the Rails world or even the web development world is really lacking tools in this regard. Like you can really get as deep or as shallow as you want. You could use Heroku, which is a phenomenal hosting platform.
Charles Max_Wood:
Yeah.
Cameron_Dutro:
Maybe not in the recent couple of years, but a recent couple of months, but certainly one of the most popular ones for Rails devs, it's so easy just get push and next thing you know, your apps online, all of the networking and database management for you. Phenomenal, absolutely phenomenal. And you can use elastic Beanstalk, you could use render. There's
Charles Max_Wood:
Mm-hmm.
Cameron_Dutro:
so many options. And, but I think that there's also a lot to be said for managing some of this on your own. Because I come from the world of Capistrano and copying PHP files up to an FTP server. And there's nothing simpler maybe than Git push, but there's also maybe the one step slightly less complicated even than that, is just copying some files up to a server, right? And that's essentially what Capistrano is doing. It just takes some files, it copies them up, maybe it clones your repository, and
Charles Max_Wood:
Yeah.
Cameron_Dutro:
then runs your app using system control or whatever. And there's a lot to be said for having sort of that level of simplicity or that level of control over your environment. You know, Capistrano, it's just a Ruby script and you have a bare metal server up somewhere or any VPS you can put stuff onto. as a developer, I kind of miss that. Like I don't want to have to depend on render or depend on ECS or any of these platforms. I want to be able to have this awesome experience and control that I get with Capistrano, but still have the power of something like Kubernetes or Docker Swarm or any of these orchestration tools. So, and in my opinion too, like most of these orchestration tools Docker Swarm like Kubernetes are much too complicated for the average person. And like I said, most devs don't want to think about those things. They want to think a layer up from the stack, but maybe not as high as Render or Heroku, right? So what I really want out of Kube is to be as flexible and as developer-friendly as Capstrono, but there's no vendor lock-in with it. It's just a tool that you run on your machine. It's not anything more than that. There's no hosted option. There's no vendor lock-in. and usable as just an average
Charles Max_Wood:
Mm-hmm.
Cameron_Dutro:
dev.
Charles Max_Wood:
So I want to speak to some of this because, so I was using DigitalOcean's app platform for a while
Cameron_Dutro:
Mm-hmm.
Charles Max_Wood:
to host top end devs. And I started hearing from people that it would inexplicably go out, like
Cameron_Dutro:
Mm.
Charles Max_Wood:
my website would. And so I'd go look and I'd get this weird error from DigitalOcean. And I kept sending them support requests and they're good about answering them, would just randomly not
Cameron_Dutro:
Hmm.
Charles Max_Wood:
work. And it wasn't an error from my side, it was an error on their system. And so I moved everything over to Capistrano and a server on one of their droplets. If you're not familiar with droplets, that's DigitalOcean's VPS
Cameron_Dutro:
Right.
Charles Max_Wood:
option. So I set everything just like I expected to because I've used it for years. The problem I had was figuring out, okay, I've got this server that I need to run Puma, and I want to use Puma, Proxy behind Nginx, and blah, blah, blah. It works terrific
Cameron_Dutro:
Hmm.
Charles Max_Wood:
on my local machine, but I had to figure out how to make it a system and there wasn't good documentation out there for how to put that configuration file onto the server
Cameron_Dutro:
Hmm.
Charles Max_Wood:
so that Puma would actually just start up on its own. And then when I wanted to restart it, I could just tell the system control system to restart the Puma service. And
Cameron_Dutro:
Mm-hmm.
Charles Max_Wood:
I think I still have a bruise on my head from like three or four or five weeks ago when I did this, because I banged my head against the wall for like three days straight trying to get it up. And then, you know, once I had it up, It was like, well, flip, I'm copying this file over to any other server I have to set up for podcast playbook. And then the other issue I ran into was that I had to do the same thing for Sidekick. And it wasn't identical, right? It wasn't identical to setting up the Puma service. And so I had to go in there and fiddle with it until I set it up. And even now, I still don't know if it's running optimally. I just
Cameron_Dutro:
Mm-hmm.
Charles Max_Wood:
know that it works. And so, you know, being kind of a level simpler, or a level more complicated than a git push. And that's true after you have the server set up. And
Cameron_Dutro:
Yeah.
Charles Max_Wood:
all of the, okay, and I also needed to do all of the Rails stuff. And so I need all the dependencies there. And okay, I added a new dependency. And so now I have to go onto the server and install the C library that it relies on. And so I had to jump through all those hoops. Yeah, now when I need to deploy, just cap production deploy, right? And it just
Cameron_Dutro:
Yeah.
Charles Max_Wood:
goes. And even if I add a new gem, 99% of the gems I'm using are straight up Ruby. And so there's no dependency that I'm missing. But yeah, it was a giant hassle to set it up. And so that's the other thing is, is if there was some kind of, I mean, cause the containers just work. I just pulled down a Ruby container that's designed to run Rails and I'm basically done. And so that, that's the appeal that it has is, you know, yeah, I like the containers. I like the simplicity, but it's a headache. And I'd like to be
Cameron_Dutro:
Yeah.
Charles Max_Wood:
able to set up triggers so that, yeah, when I do a get push, it goes, oh, do you want to deploy this? And I say, yes, and then it just deploys it. Or I don't push to the production branch until I'm ready to deploy or something like that. Because the DigitalOcean app platform actually worked that way. I'd pushed
Cameron_Dutro:
Mm.
Charles Max_Wood:
the production branch automatically pull it down and deploy it.
Cameron_Dutro:
Absolutely. Yeah, I think a lot of what you're describing is the pain that I also have gone through with with Capistrano. Like specifically the problem where so I gave a RailsConf talk about about Kubi and I mentioned and like something made it online to YouTube. A couple weeks ago, and one of the comments under the video was somebody saying yeah Capistrano is great, but it will fail. The first 19 times you try to run it.
Charles Max_Wood:
Mm-hmm.
Cameron_Dutro:
Because you haven't gotten everything you know figured out yet
Charles Max_Wood:
Yeah.
Cameron_Dutro:
and that's absolutely right like there's It's great. It's smooth sailing. It works really well. But you know, getting to that point and I feel like I had to do that every single time I made a new app, I had to go to play somewhere and like some weird thing was wrong. You know, like
Charles Max_Wood:
Yep.
Cameron_Dutro:
the version of CentOS or whatever that I was using, you know, didn't support installing the GCC compiler version that I needed. In fact, that's actually something that happened to us at Lumos. We had this old Cron server that used to, it was all provisioned with Chef, I think. And there were some scripts on there that were supposed to run every day that like our billing reconciliation and
Charles Max_Wood:
I
Cameron_Dutro:
would...
Charles Max_Wood:
loved Chef until I didn't anymore.
Cameron_Dutro:
Yeah, well, and Chef is great. It's just like, you know, Chef suffers from the same problems that
Charles Max_Wood:
It
Cameron_Dutro:
you
Charles Max_Wood:
does.
Cameron_Dutro:
would suffer from with Capistrano, right? Like it needs to go into a server and install things, but if the environment isn't exactly what it expects, it'll just blow up,
Charles Max_Wood:
Yep.
Cameron_Dutro:
right? So what happened to us, we had this old app, Cron server, that nobody wanted to move or migrate or touch because it handled all our billing reconciliation. And so one day, one of our, we had this bug, and that server, the billing stuff started to fail. And we were like, that's weird, what happened? It turns out that one of our engineers had upgraded the Rails app to Ruby 2.6, which introduced the new safe navigation operator. And so that code is the same code that was used on the AppCron servers. So everything worked fine in production because we upgraded the production servers to 2.6, but nobody thought to upgrade the AppCron server to 2.6. And so when the billing reconciliation code ran, there was a safe navigation in that code was literally a syntax error on Ruby 2.5, which is what this old server was running. And
Charles Max_Wood:
Mm-hmm.
Cameron_Dutro:
so we were like, oh, dang it. Okay, I guess we got to go in and upgrade this server. So we wanted to upgrade the server, but we couldn't install 2.6 because it depended, like the GCC that was on that system was too old. And so we were like, okay, let's upgrade GCC. There was no package available for that CentOS version. So we're like, okay, well, let's install it manually. And that also failed for some reason. So we're stuck with this yak shave where we, you know, like
Charles Max_Wood:
Yeah.
Cameron_Dutro:
we couldn't upgrade CentOS would mean that we'd have to go and reposition the AMI or the Amazon, you know, instance for this, which is the whole point of we didn't want to do that in the first place because it was
Charles Max_Wood:
This
Cameron_Dutro:
going
Charles Max_Wood:
is
Cameron_Dutro:
to be
Charles Max_Wood:
why
Cameron_Dutro:
super
Charles Max_Wood:
I
Cameron_Dutro:
painful
Charles Max_Wood:
don't
Cameron_Dutro:
to
Charles Max_Wood:
use
Cameron_Dutro:
migrate
Charles Max_Wood:
passenger
Cameron_Dutro:
everything
Charles Max_Wood:
anymore.
Cameron_Dutro:
over, right?
Charles Max_Wood:
Because the same thing, you have to go deploy engine X by hand to make passenger happy.
Cameron_Dutro:
Yep. Right, you just get stuck in this totally hellish cycle of like
Charles Max_Wood:
Yeah.
Cameron_Dutro:
not being able to do anything because you want to upgrade all of these things that depend on each
Charles Max_Wood:
Yep.
Cameron_Dutro:
other, right? So that's a lot of the pain that Docker solved, right? It was like, you
Charles Max_Wood:
Oh,
Cameron_Dutro:
know,
Charles Max_Wood:
100%.
Cameron_Dutro:
you don't need to worry about what the operating system has installed. You just put everything you need into this image and then that can be, you know, run anywhere.
Charles Max_Wood:
Well, the other thing is, is that the build artifact that you create with Docker, like I, you know, I have Docker installed on my Mac,
Cameron_Dutro:
Thanks for watching!
Charles Max_Wood:
but if anybody else has Docker, right, with anywhere close to the same capabilities, and I tend to keep mine updated, so it'll run on the latest version of Docker, Docker
Cameron_Dutro:
Mm-hmm.
Charles Max_Wood:
desktop. They have a working artifact, right? I don't
Cameron_Dutro:
Yep.
Charles Max_Wood:
have to go tell them, go install all this crap on your computer, you
Cameron_Dutro:
Exactly,
Charles Max_Wood:
know.
Cameron_Dutro:
exactly. Right, like whenever I get a new Mac and I'm trying to install like NocoGiri, I always have to go through the hell of trying to
Charles Max_Wood:
Mm-hmm.
Cameron_Dutro:
figure out LibX, SLT, and this other,
Charles Max_Wood:
Yeah.
Cameron_Dutro:
and fortunately it's just a lot of brew installs.
Charles Max_Wood:
What are those flags? Yeah.
Cameron_Dutro:
Right, what are the flag? Exactly, like what are the flags? Like SQLite
Charles Max_Wood:
Yeah.
Cameron_Dutro:
sometimes has problems, but if you just use that pre-built, like Rails,
Charles Max_Wood:
Mm-hmm.
Cameron_Dutro:
or I think it's a Ruby Docker image,
Charles Max_Wood:
Yeah.
Cameron_Dutro:
it has all of that stuff installed. So literally like gem install NocoGiri just works. Like you don't
Charles Max_Wood:
Yep.
Cameron_Dutro:
have to ever like mess around stuff anymore. So
Charles Max_Wood:
Yep.
Cameron_Dutro:
yeah, that's definitely the
Charles Max_Wood:
The
Cameron_Dutro:
power
Charles Max_Wood:
other
Cameron_Dutro:
of Docker.
Charles Max_Wood:
one that gets me is the Postgres app.
Cameron_Dutro:
This
Charles Max_Wood:
And
Cameron_Dutro:
is.
Charles Max_Wood:
then it's, Oh, what's the magic path to,
Cameron_Dutro:
Yeah.
Charles Max_Wood:
you know, to get the PG
Cameron_Dutro:
Yeah.
Charles Max_Wood:
gem to play nicely with it anyway.
Cameron_Dutro:
Yeah, exactly. Right. So, yeah, I'm going to go ahead and do that. I'm going to
Charles Max_Wood:
And
Cameron_Dutro:
go
Charles Max_Wood:
then
Cameron_Dutro:
ahead and
Charles Max_Wood:
I
Cameron_Dutro:
do
Charles Max_Wood:
don't
Cameron_Dutro:
that.
Charles Max_Wood:
have
Cameron_Dutro:
I'm going
Charles Max_Wood:
the right
Cameron_Dutro:
to go
Charles Max_Wood:
version of Postgres installed in it. So now I've got it.
Cameron_Dutro:
Yeah, it's such a massive pain. And that's like a lot of the, I don't know, a lot of the friction that I used to encounter
Charles Max_Wood:
Yeah.
Cameron_Dutro:
with Rails development. Even trying to get a new junior person set up with a Rails app. I mean, I worked at Twitter back when Twitter was still using Ruby. And every time somebody would come onto the team, we'd have to spend like three hours getting their laptop
Charles Max_Wood:
Mm-hmm.
Cameron_Dutro:
set up because there was so many obnoxious
Charles Max_Wood:
Yep.
Cameron_Dutro:
compile errors and whatnot, you know? So yeah, I'm glad that a lot of the problems that used to happen, that have been solved by Docker.
Charles Max_Wood:
Yeah, one question that I have. I'm sorry, Valentino, I feel like I'm just hogging the mic.
Valentino_Stoll:
I'll get to it. I have lists going here.
Charles Max_Wood:
Okay. So one thing that I'm curious about though is like I'm using Docker Compose on my machine
Cameron_Dutro:
and I'll see you next time. Bye.
Charles Max_Wood:
and I know that there are sort of client side versions of Kubernetes that you can run on your
Cameron_Dutro:
Mm.
Charles Max_Wood:
Mac or whatever. So would this work there too so I can test out the whole ball of wax or?
Cameron_Dutro:
Yeah, for sure. So let me step back real fast and just make sure that I've said this so that it's sort of loaded into our brains here. Kubernetes works with Docker images, not necessarily Docker images, but images built with Docker or a Docker adjacent tool. There's lots of
Charles Max_Wood:
Okay.
Cameron_Dutro:
other tools that also build images. And so that's what Kubernetes does. It takes an image and then we'll run it for you and make sure the networking is connected. Like, you know, if you want to connect to a MySQL, running in the same cluster, because the network is all set up for you. So that's what those two tools are doing. And that's what also a Kube does. It'll build an image out of your Rails app and install all the right packages and whatnot. And then we'll push that to a registry. So Docker registry, you push all of your images and then it'll run, you know, when you start your app and deploy it, the Kubernetes cluster will pull down those images and run them. So, okay, so I think we're on the same page there. Oh, and I've totally forgotten your question now. I'm sorry, what was your question?
Charles Max_Wood:
So can I run this locally?
Cameron_Dutro:
Oh, right, yes, okay, so all of that stuff can run locally because the registry and Kubernetes, all of that is runnable anywhere really, so a server or your laptop. Kube has a series of plugins called providers that will let you deploy to DigitalOcean or Linode. And there's also one that deploys to, uses this tool called Kind. And Kind is like a cluster that can run So you would just use the kind provider and then deploy to, you know, to kind essentially, and then that would just run on your machine. You could look, you know, hit the website, localhost 3000, like you would normally do. Thanks for watching!
Charles Max_Wood:
I mean it all sounds great to me.
Cameron_Dutro:
I'm glad to hear that.
Valentino_Stoll:
I mean,
Cameron_Dutro:
Yeah.
Valentino_Stoll:
I got to jump in here. I mean, I'm torn. And from a certain point in a Ruby app or Rails app, I could totally see the allure of Kubernetes and Docker
Cameron_Dutro:
Yeah.
Valentino_Stoll:
and all that. My problem is more of like the low to middle tier apps, right? Like that need to change and
Cameron_Dutro:
Easy.
Valentino_Stoll:
don't need structure
Charles Max_Wood:
Hmm,
Valentino_Stoll:
overhead
Charles Max_Wood:
yeah.
Valentino_Stoll:
for the most part. I know that probably isn't the most use case because of the bohemists that are out there now. But I feel like there's still a huge number of people where maybe Kubernetes, maybe Overkill, and maybe Kube solves that, mitigating some of that overhead. I was playing with Kube, the Daku, which
Cameron_Dutro:
Mm.
Valentino_Stoll:
you can run the same Roku. And it's still hard to beat that
Cameron_Dutro:
Mm-hmm.
Valentino_Stoll:
be able to just
Cameron_Dutro:
Yeah.
Valentino_Stoll:
get push dacu the same way you would. But having run a dacu server before this morning and it worked really well, I was able to deploy
Cameron_Dutro:
Totally.
Valentino_Stoll:
to Linode,
Cameron_Dutro:
Yeah.
Valentino_Stoll:
it was great.
Charles Max_Wood:
Yeah.
Cameron_Dutro:
Yeah, totally.
Valentino_Stoll:
But it's still, like you mentioned, Heroku, get push Heroku, there's an open source version of that, like
Cameron_Dutro:
Mm-hmm.
Valentino_Stoll:
upgrading is
Cameron_Dutro:
Sure.
Valentino_Stoll:
terribly painful. So I definitely see the alert of having something more manageable in Kubernetes make that transition easier, right? Like how does the upgrade process work for Kubernetes?
Cameron_Dutro:
So you have actually hit on like the most difficult part of Kubernetes. I wish that... So yes, so Kubernetes, unfortunately, is very difficult to upgrade, mostly because the APIs and whatnot will change. And when I say APIs, I mean, you'll apply these resources to the cluster. It's all YAML config, right? that from you. You don't have to actually mess with that YAML config. But what it's doing behind the scenes is building up this large amount of YAML and then shoving it into the cluster and saying, you know, do what I want you to do with this YAML. You know, set up my networking and whatnot. What usually happens with a cluster, though, is that it gets into a particular state and that state can be... state that you created, you know, that could be created, or a state that an operator creates, an operator being... a special program running inside your cluster that will respond to requests to, for example, create a database, in our case, a Cockroach database or Postgres. And so there's some implicit state there too. And when it comes to upgrading the cluster, sometimes those upgrades work flawlessly because they try not to break anything between from the previous minor version to the next one. However, in my experience, rough upgrades. So 119 to 120 was pretty rough because they they move the ingress controller or the ingress API to a different namespace. And so Linode, for example, will automatically upgrade. Like if they'll give you an email they'll say hey we are no longer we're gonna deprecate support for this previous version that you're currently using. You need to go in and upgrade and if you don't we'll like force upgrade your cluster at this particular date, which is I think they have to do that because if they don't, they'll end up supporting these super old versions of all this stuff. But those upgrades, I mean, this just happened to my dad's construction company website. They forced her upgraded his to the latest version and it just, the whole thing went down. You know, like it was just not, I got this email from the uptime robot and it was like, your site's down because they forced upgraded you. So that story in Kubernetes is not very good right now. And correspondingly, that story is totally non-existent in Kube. And that's one of the things that I really would like to have a better answer for, and we don't currently have a good answer for it. What most people do in the Kubernetes world, even without Kube, is they'll create a new cluster, migrate
Charles Max_Wood:
Thanks for watching!
Cameron_Dutro:
everything to it sort of manually, and then deploy to that from then on. And they'll just go delete the old cluster. You know, like that's really not viable most of the time. So, you know, like, you know, and Kubernetes is pretty mature, but it's also, you know, there are some aspects of it like this that are pretty amateur, not amateur, that's the word, pretty immature, I suppose. So yeah, that's why it's so funny you asked that as the first question, because it's like, that's not a great, not a great experience on a great story right now. And I would love it to be better. I hope that we'll be able to come up with something.
Valentino_Stoll:
Yeah, I guess what I was getting at,
Cameron_Dutro:
No, it's totally fine.
Valentino_Stoll:
I didn't mean to like, surface
Cameron_Dutro:
Yeah,
Valentino_Stoll:
the biggest
Cameron_Dutro:
yeah.
Valentino_Stoll:
pain point.
Charles Max_Wood:
Hold still, I'm gonna poke you
Valentino_Stoll:
But
Charles Max_Wood:
in the eye!
Valentino_Stoll:
what I
Charles Max_Wood:
Ha
Valentino_Stoll:
was getting
Charles Max_Wood:
ha
Valentino_Stoll:
at...
Charles Max_Wood:
ha!
Cameron_Dutro:
Yeah.
Valentino_Stoll:
I'm going to get sold. I mean, more of what I was getting at is, uh, yeah, I'm trying on the Kubernetes as a,
Cameron_Dutro:
Mm,
Valentino_Stoll:
the defacto
Cameron_Dutro:
sure.
Valentino_Stoll:
deployment service, right? If we want to make like active deployment, right? Like should it be on
Cameron_Dutro:
Yeah,
Valentino_Stoll:
Kubernetes
Cameron_Dutro:
right.
Valentino_Stoll:
and
Charles Max_Wood:
That's
Valentino_Stoll:
why?
Charles Max_Wood:
an interesting question though.
Cameron_Dutro:
It is.
Charles Max_Wood:
Cause I feel like if we have active deployment, you know, just like we have, uh, what active storage and you can choose cloud storage or local storage. You've got the active job and you can pick like sidekick or rescue or delay job or any of those. Yeah. It seems like we had active deployment. You, it would make sense to say, you know, Kubernetes or a VPS or.
Cameron_Dutro:
Right. I
Charles Max_Wood:
Right.
Cameron_Dutro:
see what you're saying.
Charles Max_Wood:
Or, or, or, I like that as an option. Right.
Cameron_Dutro:
Mm-hmm.
Charles Max_Wood:
could adapt onto a Kube or adapt onto something a little less painful setup than Kubernetes. I don't know.
Cameron_Dutro:
for sure. I think that's also a really good question or a really good point to make. Like why Kubernetes? You know, why? Like, because I personally think that Kubernetes is the right target for something like active deployment. And the reason I say that is because, you know, your app is never just your app. Your app is
Charles Max_Wood:
Mm-hmm.
Cameron_Dutro:
obviously your app and your code that you know, you have in your app, but there's also a bunch of external stuff. So I mentioned before, Sidekick Workers, database, Redis, Elasticsearch, whatever. there's always a bunch of sort of peripheral stuff on the outside of your app. If all you needed to do was put your code on a server and say Puma run or, you know, bundled exec
Charles Max_Wood:
Thanks for watching!
Cameron_Dutro:
rail server, then, you know, this would be a totally, Kubernetes would be a terrible choice because it's way more complex than you need for something like that. But because there's all these external peripheral services that you need to access or not even, I wanna say services, processes that you need to also run and manage, doing all of that with CopAstronos doing all that with any other platforms, absolutely doable. But Kubernetes makes that just a lot more, a lot easier. And the way I talked about this in the RailsConf talk was if you are using Capistrano, then the primitive that you're working with is just a server somewhere. Capistrano uses SSH to connect to your server. All that it has to work with is what you've given it on that server. So that server may or may not have system control. That server may or may not be running AMD processors or you know x86 processors versus M1 processors, right? So there's it may not even have an internet connection. We don't it's it's just you know, you're you're you're given this Platform to run on but all it is is a server that has some software running on you don't even know or control what that is so From a tooling perspective like as a developer, you know a lot more about the server than campus rondo does You know that it's running this version of a little too You know, it's got these tools installed the campus runner doesn't know that stuff You have to basically tell it what what to do And it can kind of rely on certain tools existing, like there has to be an SSH daemon running, of course,
Charles Max_Wood:
Mm-hmm.
Cameron_Dutro:
but that's about all that it knows about your server. So from a Capistrano author's perspective, all that they can really do is let you run commands and you have to sort of specify what those commands are to a large degree. When it comes to Kubernetes, however, you have a much larger, much richer API that you can write code against. You can, for example, You can be totally confident that your server or that your platform can run Docker images. You can be totally confident that the networking between pods and pods by the way are just running containers. You can be sure that that's something that will just work, right? You don't have to go and configure that stuff. Well, you have to configure, but you can guarantee that it's there and that you can use it. So you have a much larger surface area of APIs to contact and to access and to do stuff with. Obviously, there are other tools that will do this, that will do this as well. But most of them are proprietary, right? So you could use render, but render's proprietary system, you know, would mean that you'd have to code specifically to render's APIs. Kubernetes is running, you know, is an open source project. A lot of these providers, these hosting providers like DigitalOcean will let you stand a Kubernetes cluster up. And that cluster is going to look exactly like a cluster that Lino would give you. So it makes it a much better target than just a bare metal server. of the richness and because it's going to be the same pretty much everywhere, that something like Active Deployment could target. Because it's so rich, that means that Kube can, for example, stand up a database for you. It can stand up a series of, it can set up a Redis for you, and it can use a plugin to stand up another set of pods that will be your sidekick workers. So
Charles Max_Wood:
Thanks for watching!
Cameron_Dutro:
without having to do really much of anything besides, like as a person who has a lot of is going to be using Kuby, go to a provider like there's lotion and say, get me a cluster, get that clusters ID, paste it into your config, and then you're off to the races. Like there's no additional messing around that you have to do. Right. And we are able to do that because it's targeting Kubernetes and because Kubernetes is such a rich platform and rich API. you
Valentino_Stoll:
So let's say that, you know, QB starts to become the de facto standard, right? And people are like building on top of this. Like, do you foresee like, you know, kind of rails triggers into that process where say like, you know, the typical sidekick installation is, you know, gem install sidekick and then have some configuration somewhere that says where Redis
Cameron_Dutro:
Right.
Valentino_Stoll:
is. to be able to like just say, okay, I want sidekick and it will automatically do that for your Rails app or where does that divide lay
Cameron_Dutro:
Yeah,
Valentino_Stoll:
now?
Cameron_Dutro:
that's a great question. So Kube supports a plugin architecture. So that's how the providers work, like DigitalOcean, Linode, they're just gems that you would add to your gem file and then you require those at the top of your Kube config. And then in your config, you can say provider, DigitalOcean, provider Linode. By the same token, you can also install like the Kube sidekick gem, require that, and then add plugin sidekick.
Charles Max_Wood:
Thanks for watching!
Cameron_Dutro:
And there's some config that you need to add, but that's documented in the gem, the gems readme. So your config initializers, psychic.rb, there's basically a block of code that you can just copy paste from the documentation. And that will then, when your app starts and starts to shove jobs into your queue, it'll just communicate directly with Redis automatically. And there's no additional configuration besides that that you need to do. So yes, there is, to answer your question, yes, there is a paved path for sidekick and there could be, I mean, you can imagine how much, how far you could take that, right? You could have a paved path for elastic search and for everything else that you wanted to also.
Valentino_Stoll:
Yeah, that's cool. I mean, one of my. One of my biggest gripes currently is, you know. I experiment
Cameron_Dutro:
Mm.
Valentino_Stoll:
a ton, and I imagine like lots of people that, you know, are working with rails are experimenting a ton because there's so much new that changes and so much new to explore as you like start
Cameron_Dutro:
Hmm.
Valentino_Stoll:
diving in more. You know, how easy is it to say, like, let's say I have like a Linode machine or just as many apps
Cameron_Dutro:
Yeah.
Valentino_Stoll:
as I want to it. Is
Cameron_Dutro:
Hmm.
Valentino_Stoll:
it more geared toward a multi-node setup?
Cameron_Dutro:
Hmm. Yeah, interesting. So I think there might be two questions there. So like if you have a bare metal server there that like
Valentino_Stoll:
Yeah,
Cameron_Dutro:
what you
Valentino_Stoll:
that's
Cameron_Dutro:
would normally
Valentino_Stoll:
the idea.
Cameron_Dutro:
deploy with Capistrano to, is that the idea? Yeah, right. So because Kube requires you to have a Kubernetes cluster, you would need to be running a cluster on that node, but there are like kind or KubeADM, there are ways to do that on a bare metal server. There would have to be, to get that to work. But it's definitely possible. And then the other thing too that Kubernetes offers is namespacing. So when you deploy an app using Kube, it will create a namespace for it and all of the pods, so the app and the psychic workers and all that are deployed into that namespace. And you could then deploy another app into that same cluster, which would just choose a different namespace. And so they'd be isolated from each other in that regard. So yeah, you could
Charles Max_Wood:
I was going to ask about that.
Cameron_Dutro:
wanted you to do it. Yeah.
Charles Max_Wood:
Because what I'm looking at, and so this is interesting, I mentioned that I'm running the same code base for both Top End Devs and Podcast Playbook.
Cameron_Dutro:
Mm-hmm.
Charles Max_Wood:
And so when I deploy, I do cap production deploy, and it deploys it to Top End Devs. It does not deploy it to Podcast Playbook. And the
Cameron_Dutro:
Right.
Charles Max_Wood:
reason is because Top End Devs is getting more usage, before I push it to the other system. And so I'm imagining, yeah, that I might, or the other thing is, it's a platform that I also imagine other people may want to use at some point. And so
Cameron_Dutro:
Right.
Charles Max_Wood:
I'm liking the idea that, hey, you know, when I'm ready to have it deploy globally, right, it just deploys to all of the namespaces. But at the same
Cameron_Dutro:
Right,
Charles Max_Wood:
time,
Cameron_Dutro:
absolutely.
Charles Max_Wood:
if I wanted to go to just one app as kind of the testbed, then I can do that. it's simple enough to do instead of having to have
Cameron_Dutro:
Right.
Charles Max_Wood:
a podcast playbook environment config for the deploy and a
Cameron_Dutro:
Mm-hmm.
Charles Max_Wood:
production deploy file for the config, right?
Cameron_Dutro:
Yeah, for sure. So yeah, I mean, you could always do like the multi tenant concept, I guess. But the other solution, like you mentioned, is just a deploy to like different clusters. And
Charles Max_Wood:
Multitenant
Cameron_Dutro:
you can absolutely
Charles Max_Wood:
is such a mess. I've never
Cameron_Dutro:
I know.
Charles Max_Wood:
seen it done where people don't spend years trying to fix it.
Cameron_Dutro:
Yeah, for sure. It's nice. And especially if you wanna truly isolate the data from
Charles Max_Wood:
Yeah.
Cameron_Dutro:
between customers, then having another instance
Charles Max_Wood:
Which I definitely
Cameron_Dutro:
is the
Charles Max_Wood:
do,
Cameron_Dutro:
way to go.
Charles Max_Wood:
yeah.
Cameron_Dutro:
Yeah, for sure. Yeah, so Kubi actually supports different environments. And so what you could do is potentially have a bunch of environments configured that you could deploy
Valentino_Stoll:
you
Cameron_Dutro:
to individually.
Charles Max_Wood:
Is there a way of sharing sort of global config or global information? This goes back to
Cameron_Dutro:
Mm-hmm.
Charles Max_Wood:
Valentino mentioning, like you have to tell it where the Redis server is. You have to tell it where the Postgres
Cameron_Dutro:
Right.
Charles Max_Wood:
server is and stuff like that, right? So I stick that
Cameron_Dutro:
Right.
Charles Max_Wood:
in environment variables, but then I send the same environment variable to all of the things, right? So they can
Cameron_Dutro:
Right.
Charles Max_Wood:
all talk to the things. So
Cameron_Dutro:
Yes.
Charles Max_Wood:
is there some kind of secrets management that goes into Kubernetes like that?
Cameron_Dutro:
There's, well, so first of all, you can specify that like shared configuration. So if you have a bunch of environments in your Kuby config, you can have a shared, like it's just a Lambda, essentially like it's instance
Charles Max_Wood:
Right.
Cameron_Dutro:
exact into each environment because
Charles Max_Wood:
Okay.
Cameron_Dutro:
it's a DSL. So you can have shared config. In terms of secrets, yeah, Kubernetes does have like probably the worst secret management. And this, I say this with, you know, with potentially love in my voice here, like there's a specific like object type in the the K8s API called secret. But all that it does is take your secrets and like base64 encode them. So like they're not
Charles Max_Wood:
Oh, I feel
Cameron_Dutro:
really
Charles Max_Wood:
better
Cameron_Dutro:
encrypted
Charles Max_Wood:
now.
Cameron_Dutro:
at all, right? I know. So, you know, the only, like if you have access to the cluster, then all you need to do is copy that string and like run base64 decode and you can see the secret.
Charles Max_Wood:
Right.
Cameron_Dutro:
There are certain providers will like hook into that.
Charles Max_Wood:
Yeah.
Cameron_Dutro:
So like AWS, for example, has their KMS service, their key management service, and you can tell it to automatically encrypt your secrets. Like when they go into the Kubernetes API, it'll just automatically go and encrypt those for you. And the same thing is true, I'm sure of other platforms. Kuby itself, like doesn't do any additional encryption. I guess we could
Charles Max_Wood:
Okay.
Cameron_Dutro:
add that feature, but it doesn't do any additional encryption currently. It will, one thing that is kind of nice though, as opposed to like it won't like Kubernetes will, or Kube rather will not turn your credentials into the secrets. It keeps your credential, like you know your credential, your encrypted credential store in Rails. It uses that, like it encourages you to store all your credentials in there and those are encrypted,
Charles Max_Wood:
Right.
Cameron_Dutro:
you know, using a much better algorithm than Base64. And so as opposed to like turning that into a secret, which would then get Base64 encoded, it instead just, you know, you copy that file up with your app, like you would normally do with
Charles Max_Wood:
Right.
Cameron_Dutro:
Capistrano or anything else. And then you just provide that Rails master key.
Charles Max_Wood:
Yep.
Cameron_Dutro:
And as long as the Rails master keys provided the Rails, we'll just look at that file and open it like it would normally do in development. So it doesn't try to do any secrets decoding and stuffing into a secret. It just copies that file up and then you provide the master key and it uses the key to unlock it.
Charles Max_Wood:
Yeah. The reason I asked is because that's the other issue I've had with running the same code base in multiple places is yeah, the database strings and stuff like that. They
Cameron_Dutro:
Right.
Charles Max_Wood:
all have to be managed differently and putting that all into that in a secrets encrypt file in rails.
Cameron_Dutro:
This is it.
Charles Max_Wood:
It, it started to get to be kind of a headache.
Cameron_Dutro:
Right.
Charles Max_Wood:
And then I was using the same master key everywhere and I'm like, yeah, this
Cameron_Dutro:
Yeah.
Charles Max_Wood:
is not ideal. So
Cameron_Dutro:
Yeah,
Charles Max_Wood:
yeah.
Cameron_Dutro:
for sure.
Charles Max_Wood:
Anyway.
Cameron_Dutro:
One thing I will say actually about database, like passwords and usernames and stuff, I mean, specifically passwords, those are the secrets, the secret part of connect to a database.
Charles Max_Wood:
Mm-hmm.
Cameron_Dutro:
Kube actually, because it's using, I mean, Postgres can do this too, but we actually, I might say we, the project, I wrote the project to modify it so that it uses CockroachDB now, which is like a lot more
Charles Max_Wood:
Mm-hmm.
Cameron_Dutro:
cloud native. And what I mean by that is it's sort of more designed to run in an environment like Kubernetes, as opposed to Postgres, which you're gonna have to massage And because Cockroach has like wire compatibility with Postgres, for the most part, it's a drop in replacement for Postgres. There are some slight changes, but both of those databases support connecting over SSL or over TLS. And so you can use a password if you want to, but what Kubi will do by default is generate a series of certificates for you. And then when you connect to the database, it's all over SSL and there is no password.
Charles Max_Wood:
Oh right.
Cameron_Dutro:
Yeah, so you don't even have to worry about having a password. If you're, if, if Kubi manages your database, it just automatically will connect and work via SSL or via TLS certificates.
Charles Max_Wood:
That makes sense. So you just tell Cockroach, Hey, these certificates are okay.
Cameron_Dutro:
Right, exactly. Yeah, like the Cockroach server has the private key, but
Charles Max_Wood:
Mm-hmm.
Cameron_Dutro:
the Rails app only has the public key, for example, and it will encrypt that, send it to the server, and the server decrypts it, and runs the query and returns it.
Valentino_Stoll:
I've got a couple of follow
Charles Max_Wood:
Cool.
Valentino_Stoll:
up questions here.
Cameron_Dutro:
Yeah.
Charles Max_Wood:
Oh, I was gonna say, I was gonna let
Cameron_Dutro:
Yeah, sure.
Charles Max_Wood:
Valentino get a few more
Valentino_Stoll:
So
Charles Max_Wood:
in
Valentino_Stoll:
two
Charles Max_Wood:
here.
Valentino_Stoll:
other things just kind of looking at like, okay, putting Kubi in use, right? Like, I guess I have like kind of a three part question is like, what are some of the things that you've seen Kubi kind of solve for you?
Cameron_Dutro:
Okay.
Valentino_Stoll:
Right? That maybe doing it a
Cameron_Dutro:
Mm-hmm.
Valentino_Stoll:
Another is kind of building on that is like, how does, like, let's say you have a completely separate team devoted to DevOps, whatever you want to call it, you know, does the Kube configuration kind of conflict
Cameron_Dutro:
Yeah.
Valentino_Stoll:
with people running manual commands in Kube control or something like that? How is that managed? And
Cameron_Dutro:
Mmm. Mm-hmm.
Valentino_Stoll:
I guess the last one is related to your plugins, which are really cool. third party plugins, how does that kind of system work? And do you have plans to like open that up to more like, you know, QB.install kind of setup.
Cameron_Dutro:
Yeah, yeah, super good questions. So yeah, what does it solve is a good way to, I guess, I wrote them all down here, so I'll start with that one. For me, so like, as far as I know, there's only two apps that are currently using Kube right now. One is my dad's construction website. Shout out to masterbuilderconstruction.com. Yeah, right. And that actually started life as a PHP app and I converted to Rails It really exists only because I needed a test bed to run Quby stuff with. The other one is the storybook. So I work on the design infrastructure team, or design engineering team at GitHub. And we work on Primer, this design system, and Primer view components, specifically. And those view components, there's a storybook, which is this cool design tool that you can use to
Charles Max_Wood:
Mm-hmm.
Cameron_Dutro:
preview your components and whatnot. So it uses a Rails app to render the components. And so that's also deployed with Kube into Azure Kubernetes service. So there's two apps that use it. And for me, what it really solves is just like I just went, I spent so long, like I've stood up numerous Rails apps in my career, either professionally or just on the side. And like every time I do that, I had to reach for something like Capistrano or I had to use Heroku. And there's just limitations to each of those approaches. Like I thought we talked about Capistrano
Charles Max_Wood:
Yep.
Cameron_Dutro:
at length. And Heroku is phenomenal, to I think 10 individual web apps on their free tier. So if you wanted to go and launch that 11th app, you'd have to kick one out before you could do that. Otherwise you'll end up spending money and I didn't want to spend money on it. Which is funny because like with Kubernetes, like, you know, there's no way to not spend money on that. So what I was looking for was a way to deploy something that I had more control over, but that I wouldn't break the bank to stand up, you know? Like Heroku can get really expensive if,
Charles Max_Wood:
Oh yeah.
Cameron_Dutro:
even if you just do a couple of really basic, like even if you want just a few more database I think it limits you to 100,000 rows or something. Even if you want 100,001 rows, you still have to pay. It's a pretty steep, it goes up really quickly.
Charles Max_Wood:
Mm-hmm.
Cameron_Dutro:
And I found that I could actually get basically more freedom by spending the same amount of money. So you can run, I think on Line node right now, my dad's website is hosted for about $25 a month. And it's just one node and there's a load balancer and it all works really well with Kubi. And there's no sort of, I don't have to worry about the additional overhead of paying. I'm never going to have 100,000 rows in that database, but if I do, I don't have to go and worry about increasing my account limits or whatever. I can just increase the size of the disk that it's on and be done.
Charles Max_Wood:
Yeah.
Cameron_Dutro:
It solves those problems. What I'm hoping is that it will eventually become, because I think that my real goal behind this is not so much to stand up my dad's database or whatever, my dad's website. My real goal is to prevent people from getting that point in their Rails journey and realizing that they either have to spend money or have to struggle setting up Capistrano or whatever, you know, or have to bump another app off their, you know, free tier in Heroku. I want these developers that are coming up in Rails and coming up in Ruby to not get stuck at that step where they have no chance and no options to deploy something or that Rails doesn't provide for them, right? So that's what I want Kube to be is this plugin system and this thing that you can just plug into your app and suddenly you're like off to the races, right? So yeah, that's the major goal is to make sure we don't lose companies and juniors and stuff at the step where they like make their app and then they can't deploy it. Okay, and then your next question was, does Kubi's config like supersede kube control commands? Like what if you run a command with kube control and then that like somehow, you know, conflicts with your kube config? That's a good question. I mean, you can definitely do that, right? You go and, for example, mess with the config. is that there's not, like you can go and mess with that config manually. You can go and apply, for example, a different YAML file or editor resource directly in your editor that you could, that your kube control command could start up for you and save it back and then mess things up. Totally true. One thing that's nice about Kubernetes though, is that it's sort of, if you wanted to go and sort of fix that, or if you wanted to, like you made a mistake, you could simply deploy with kube again, that you just edited with the one that could be generated. And so that would hopefully fix any of the problems that you introduced by manually editing things. So that's kind of a double-edged sword, though, right? Because it's really just clobbering all the config that you already entered. If you wanted to persist that, if you wanted to make a change that would persist on multiple deploys, you would need to make that change in the Kuby config.
Charles Max_Wood:
Right.
Cameron_Dutro:
And Kuby uses this other project called kubesl to generate Kubernetes resources. There's really no part of that deploy process that you can't monkey with if you want to I had to do a lot of that actually for the for the the primer storybook So yeah, so I would recommend that you not run, you know random kube control commands that are making changes to your resources And instead go in and modify your kube config to tweak whatever you want so that it's a persistent change
Charles Max_Wood:
Yeah, but that was the
Cameron_Dutro:
Um,
Charles Max_Wood:
same story
Cameron_Dutro:
yeah.
Charles Max_Wood:
with things like Chef and crap like that too, is, you know,
Cameron_Dutro:
Yes.
Charles Max_Wood:
it would generate your config files and then basically just stick them on the server and it wouldn't even check to see if something was there before.
Cameron_Dutro:
Exactly, that's totally right. So, and it could really devastate things if you're not, like it was making changes that, you know, you weren't expecting or that weren't codified somewhere, you could really get
Charles Max_Wood:
Yeah.
Cameron_Dutro:
into big trouble. Yeah, that's true. Okay, and then to answer your last question, third-party plugins. So right now there's one third-party plugin. So anybody can write a plugin. I have documentation for that on the getcubi.io. You can make your own plugins. There's one that I know that, so all of the plugins except one have been written by me. get Kubi organization. Yeah, but there was a great article published by the Evil Martians, Vladimir Demetyev, where he talked about deploying an app with Kubi, and he made some really interesting suggestions as part of that article. And so I think the Evil Martians are the guys behind AnyCable, and they wanted to get AnyCable working with Kubi, so they wrote a plug-in for it that you can, I think it's just EvilMartians slash Kubi-A-AnyCable, and if you add that to and it will automatically stand up like the AnyCable Go service and
Valentino_Stoll:
Oh, that's
Cameron_Dutro:
just
Valentino_Stoll:
cool.
Cameron_Dutro:
wires everything up for you. So it's a really good example of being able to take something that would normally have taken a lot of effort to get running,
Valentino_Stoll:
I'm gonna have to.
Cameron_Dutro:
and you
Valentino_Stoll:
That's
Cameron_Dutro:
can just
Valentino_Stoll:
great.
Cameron_Dutro:
drop a plugin in and it just works.
Valentino_Stoll:
I'm gonna have to play with that.
Cameron_Dutro:
Yeah, it was fun to see that happen.
Charles Max_Wood:
Yeah.
Cameron_Dutro:
Yeah, for sure. I mean, it's again, that's really because of the power of the Kubernetes platform. Like, imagine trying to do something like that, you know, in Capistrano or, you know, even in Heroku, I guess it's
Valentino_Stoll:
I'm
Cameron_Dutro:
all
Valentino_Stoll:
get-
Cameron_Dutro:
possible, of course, but it would be I think it's much easier to do that in those other platforms.
Valentino_Stoll:
I don't, you know, part of me is, I don't know if I'm like, it's the longevity of, of me being, you know, a seasoned developer that I'm just used to the, you know, uh, orchestration at this point,
Cameron_Dutro:
Mm.
Valentino_Stoll:
or some of the, some of these skills that maybe if I was just starting now, I would just overlook
Cameron_Dutro:
Mm-hmm.
Valentino_Stoll:
because other people do that or there's other tools, right? Uh, so it's kind of hard to tell where it's
Charles Max_Wood:
Mm-hmm.
Cameron_Dutro:
is
Valentino_Stoll:
going
Cameron_Dutro:
in.
Valentino_Stoll:
to go. It's what I'm saying. Uh, but it definitely, I, interface
Cameron_Dutro:
Yeah, for sure,
Valentino_Stoll:
of
Cameron_Dutro:
for
Valentino_Stoll:
Kubi.
Cameron_Dutro:
sure.
Valentino_Stoll:
As a configuration, it did make it feel easier to deploy, I will say. Because I similarly have been down that Capistor on
Cameron_Dutro:
Mm-hmm.
Valentino_Stoll:
a path where I have a bare metal server and I want to push it and something isn't there, right? That it's expecting and you have to figure out what it is. That pain just
Cameron_Dutro:
Yeah.
Valentino_Stoll:
sucks
Charles Max_Wood:
Mm-hmm.
Valentino_Stoll:
so much time away that, you know,
Cameron_Dutro:
For sure, for sure. Yeah.
Valentino_Stoll:
which even though that's probably not the best thing, uh, you still would save me time, you know.
Cameron_Dutro:
Yeah. Right, right. Yeah, no, totally. Yeah, you know, that's actually a really good point that like I think a lot of the DevOps kind of revolution that we went through was realizing. Well, I don't want to say revolution. There's been there have been several stages of DevOps, I think that we've all sort of experienced. And the first one was like, oh, I can I can code up a like I could write a script, but it's it could be a chef script or it could be a bash script. that will provision my server for me. And then I can run that on the server every time I create a new server.
Charles Max_Wood:
Thanks for watching!
Cameron_Dutro:
Oh, that's gonna save me so much time. And maybe on the first one it does, but then the second one it's gonna blow up and something's not quite the same as you remember from before. So that was sort of the first wave. Like we can codify these rules into a script or a chef cookbook or whatever and apply them everywhere. And that was pretty great actually for a long time. What we I think discovered though after that was that it's often a lot better to just have everything be ephemeral. You don't want to lose your data. But like you talk about deleting a kates cluster and bringing another one back up, that often is just a much easier
Valentino_Stoll:
you
Cameron_Dutro:
solution than like trying to debug the existing one. And because
Valentino_Stoll:
And, you
Cameron_Dutro:
it's
Valentino_Stoll:
know,
Cameron_Dutro:
so ephemeral,
Valentino_Stoll:
I even
Cameron_Dutro:
I could
Valentino_Stoll:
think
Cameron_Dutro:
just
Valentino_Stoll:
of
Cameron_Dutro:
delete
Valentino_Stoll:
it
Cameron_Dutro:
it
Valentino_Stoll:
too,
Cameron_Dutro:
and make a new
Valentino_Stoll:
like
Cameron_Dutro:
one and move on with my life.
Valentino_Stoll:
stuff
Charles Max_Wood:
Mm-hmm.
Valentino_Stoll:
that you come back to after years, right? Like I have all these old apps that I have up that, you know, I don't want to upgrade or anything because they're just, you know, they're so ancient. And I was like curious, you know, about something that I had worked
Cameron_Dutro:
Right.
Valentino_Stoll:
on and I wanted to try and get it up again, just see what was working. I couldn't. I was like, well, I just said, I'm not going to do this.
Cameron_Dutro:
Yeah. Yep. All
Valentino_Stoll:
pretty easily,
Cameron_Dutro:
right.
Valentino_Stoll:
you know, I feel like that could take out a barrier. It's definitely a pain point
Cameron_Dutro:
Yeah,
Valentino_Stoll:
of mine that
Cameron_Dutro:
totally.
Valentino_Stoll:
I still have.
Cameron_Dutro:
Yeah, really good point. Like the bit rot that often like sets in on on these older applications. Yeah, absolutely. And like Docker is the thing that really, I think makes that easier. Kubernetes doesn't really help you in that. I mean, it would because you could still launch it or deploy it or whatever,
Valentino_Stoll:
Yeah,
Cameron_Dutro:
but
Valentino_Stoll:
but then
Cameron_Dutro:
the
Valentino_Stoll:
I'd
Cameron_Dutro:
Docker
Valentino_Stoll:
have to make
Cameron_Dutro:
image
Valentino_Stoll:
a Docker
Cameron_Dutro:
is really what
Valentino_Stoll:
image
Cameron_Dutro:
like
Valentino_Stoll:
for
Cameron_Dutro:
would
Valentino_Stoll:
those
Cameron_Dutro:
save you.
Valentino_Stoll:
old apps.
Charles Max_Wood:
Yeah.
Cameron_Dutro:
Right. Totally. Yeah.
Charles Max_Wood:
Good luck.
Cameron_Dutro:
Yeah, man.
Charles Max_Wood:
Cool.
Cameron_Dutro:
There's actually, I mean, Ruby, so the Ruby official Ruby Docker image has, I think versions going all the way back to like 2.2, I want to say, maybe even 2.0. So you can go back pretty far in time with those images.
Charles Max_Wood:
Yep. All right, well, let's do some picks. I think we've pretty well covered the topic.
Cameron_Dutro:
Yeah.
Valentino_Stoll:
Sure.
Charles Max_Wood:
Valentino, do you want to start us
Valentino_Stoll:
I
Charles Max_Wood:
off
Valentino_Stoll:
just
Charles Max_Wood:
with
Valentino_Stoll:
came
Charles Max_Wood:
picks?
Valentino_Stoll:
across this article from the guy that's been working on all the improvements to IRB. Was it Stan Lowe? He has this article on from Bye Bye, Bye Bug to Ruby debug. It's really cool. It outlines kind of all the pain points from Bye Bug and kind of what's new really cool to see all the new features that are coming out of there. And my other pick is Keychron. I have this new keyboard. It's wireless. And I haven't had any issues with it. It's mechanical. And I don't get keyboards that often. So this was a huge, huge win for me.
Charles Max_Wood:
Nice. All right, I'm gonna jump in. I usually do a game board pick or game board pick. I must be tired. A board game pick. The one I'm gonna pick this time, it's card game, it's called Quiddler. This one's been around for a long, long time. So a lot of people may have played it. Effectively, what you do is you have a hand of cards, you try and make words out of it. When you've put down all the cards in your hand, kind of gets a shot to put down what they've got and then you tally up the points you get bonus points for having the longest word or the most words right so you can put down two words anyway Yeah, but that's pretty much the game. It ranks on board game geek at a 1.43, which means it's on the simpler side. I mean, I basically told you how to play it. So, you know, and you just play a number of hands starting at three cards and going up to however many cards. I like board games because I tend to win them. But yeah, it's a good family game. And so yeah, I'm gonna pick Quiddler. trying to think what else I've got here for picks. I'm ramping things up on the Meetup side. So keep an eye out if you go to topendevs.com slash Meetups or if you scroll down, it should show you all of the events we have coming up. But yeah, definitely check that out. I'm also thinking about adding a function. We're using Riverside to... to kind of do the show live or to do the show among us. And I haven't been posting the videos, but it does have a feature where people can join as audience. And so you could kind of see us talking, you could see my messy office. And so I'm thinking about putting all of the shows, live recordings on there, so if people wanna come in and participate in the chat that they can. But yeah, I'm really looking at that Rails Remote Conf is coming up, CFP still open. I'm trying to think of what else I'm gonna pick. My wife and I started watching a new show, and so I'll pick that, and that'll be my last pick. It's called The Lost Symbol. It's based on Dan Brown's book. It's on Peacock. I remember back in the day you'd say, it's on channel five at six p. Not anymore, it's on this streaming service, it's on Peacock. I think my wife picked up the Peacock Plus subscription when she wanted to watch Olympics. Then we held on to it because I wanted to watch Yellowstone. Now we're watching Lost Symbol. They've got a ton of stuff on there just like all the rest of them. But yeah, this one's pretty good. It's based on the book. I haven't read the book in so long. I can't tell you how closely it's sticking to the story. But it's got, what's his name? Robert Langdon? And, you know, I think the characters all have the same names at the very least. So anyway, it's been decent. It's not riveting to me like Yellowstone was. Like Yellowstone, I couldn't quit watching it. But it's nice to just sit down and, you know, watch a show with the wife. And this has been a good show. So yeah, so I'll pick the lost symbol as a pick. All right, Cameron. Thanks.
Cameron_Dutro:
Well definitely plus one to Quiddler. That's one I played before. It was pretty fun. Lost Symbols is interesting because I feel like that wasn't... Did they make that into a movie at some point like a couple years ago? I want
Charles Max_Wood:
I don't
Cameron_Dutro:
to say
Charles Max_Wood:
think so.
Cameron_Dutro:
I got...
Charles Max_Wood:
They did Angels and Demons and they did the Da Vinci Code.
Cameron_Dutro:
Oh, DaVinci cut, right, but they haven't done Lost Symbol. Okay,
Charles Max_Wood:
I don't think they did
Cameron_Dutro:
cool.
Charles Max_Wood:
the Lost Symbol. The Lost Symbol, the book, wasn't as good as either the other ones. He's done
Cameron_Dutro:
Yeah.
Charles Max_Wood:
four or five books that
Cameron_Dutro:
Right.
Charles Max_Wood:
I've read, and Angels and Demons and The Da Vinci Code are definitely the better books.
Cameron_Dutro:
Yeah, I've read all of them as well. It's like one of the only authors that I read anymore. But, you know, I've been told that I have poor taste in literature, but I think they're really good. So I was hoping that maybe the Lost Symbol book was, or series is good too. Um, so.
Charles Max_Wood:
So far, we've watched like three or four episodes.
Cameron_Dutro:
Okay, okay, cool. I might have to check it out. So yeah, my picks are gonna be, I just have two picks. One is view component. So I work on the design engineering team, as I mentioned at GitHub. And one of the projects that we work on is the view component framework. And view component's a really, I would say, awesome way to clean up your views, especially if you have logic in those views.
Charles Max_Wood:
Mm-hmm.
Cameron_Dutro:
I know that Joel Huxley, the creator of View Component, has been on this podcast before So at this point,
Charles Max_Wood:
I am
Cameron_Dutro:
I
Charles Max_Wood:
addicted
Cameron_Dutro:
think probably most
Charles Max_Wood:
to
Cameron_Dutro:
people.
Charles Max_Wood:
them.
Cameron_Dutro:
Oh, nice. That's good to hear.
Charles Max_Wood:
I use them
Cameron_Dutro:
Yeah,
Charles Max_Wood:
all the time.
Cameron_Dutro:
that's awesome. Yeah, we really there's lots of adoption and I just, you know, wanted to pick it because it's like, I think maybe one of the best things to happen to the Rails View layer like maybe ever. And then my last pick is going to be for Apple AirPods. I'm just a huge fan of AirPods. They work
Charles Max_Wood:
Mm-hmm.
Cameron_Dutro:
super well. I've dropped them like a billion times and they still work. And they're a little expensive, but they're absolutely worth it. Pro AirPods. So, you know, if you're looking for a pair of really, I would say, pretty good quality, durable, works automatically with everything I have that's Apple based. You know, if you want something like that, then definitely get the AirPods to try.
Charles Max_Wood:
Yeah, I haven't tried the AirPod Pro. I've always just gotten the older AirPods. In fact, mine died and I recently got new ones and I went and got, specifically got the old version of them just because I like them
Cameron_Dutro:
Okay,
Charles Max_Wood:
so much.
Cameron_Dutro:
sure.
Charles Max_Wood:
But they, yeah, they stand up well, they
Cameron_Dutro:
Yeah.
Charles Max_Wood:
pair with everything. And it seems like I have to replace them every like three or four years. And so, I mean, they hold up really, really, really well.
Cameron_Dutro:
Yeah, three or four years for headphones is pretty good, I think.
Charles Max_Wood:
Yeah.
Cameron_Dutro:
For like in-ear headphones, yeah.
Charles Max_Wood:
Yeah.
Cameron_Dutro:
Cool. Well, thanks guys. It's been a real pleasure.
Charles Max_Wood:
All right. Yeah, well, we'll wrap it up here. Till next time, folks. Max out.