Today, they delve deep into the world of application deployment with our special guest, Josef Stribny, a freelance software engineer and author of "Deployment from Scratch" and "Kamal Handbook". Joined by the insightful panelists, Valentino and Ayush, they explore the intricacies of deploying applications using Kamal, a minimalistic deployment tool inspired by Ruby on Rails creator David Heinemeier Hansson.

In this episode, Josef shares his expertise on Kamal’s deployment process, Docker registries, managing database backups, and the use of accessories like Sidekick for background processing. They discuss the differences between Kamal and tools like Capistrano and Kubernetes, highlighting Kamal's unique approach to simplifying deployment. Along the way, the panelists dive into related discussions, from personal tech recommendations to favorite TV shows and movies, making for a rich and engaging conversation.

Tune in as they uncover the secrets to efficient deployment, the advantages and trade-offs of using Docker, and the cutting-edge features of Kamal, ensuring you are equipped with the knowledge to optimize your development workflow. 

Valentino Stoll [00:00:04]:
Hey, everybody. Welcome to another episode of the Ruby Rogues podcast. I am your host today, Valentino Sol, and I'm joined by our co host, Ayush.

Ayush Nwatiya [00:00:13]:
Hello. Hello.

Valentino Stoll [00:00:15]:
And we have a very special guest today, Joseph. Do you want to, introduce yourself and tell everybody why you're Ruby famous here?

Josef Stribny [00:00:24]:
Yes. Hello, everyone. So I'm Yozef. I am, a freelance software engineer. And, apparently now also a book author. I wrote 2 books. The first one was called Deployment from Scratch and the second one, is called Kamal Handbook. And that's probably why we are here today.

Josef Stribny [00:00:48]:
I see.

Valentino Stoll [00:00:51]:
Yeah. You know, the Kamal is like the one of the latest crazes with all the new rails announcements so it's kind of exciting to have an expert here or at least somebody who has, dove into the trenches and put together all the details for us to, you know, expose the the secrets of how how minimalistic it is. I I hope. I I honestly haven't had a chance to, play with Kamal, so I'm looking forward to hearing your take on, how it all comes together.

Josef Stribny [00:01:24]:
Yeah. I did a deploy or 2 before the show just so I know.

Valentino Stoll [00:01:32]:
So I I guess we can start maybe at a high level, like, you know, what what is the deploy process, like, look like, you know, maybe before Kamal and why Kamal is even here?

Josef Stribny [00:01:50]:
Yeah. So, maybe it would be interesting to see it from the point of 47 signals because they are the company behind Kamal. Right? Kamal was actually started by David Helmer Hansen, so Ultra of Rails also started CAML. And, they were doing the deployment, with, Capistrano, which is a simple Ruby deploy tool. You basically have all your little, tasks predefined in Ruby, and then you simply run them. They run on the server and, something happens. You know? CapEx channel, at the time, didn't do much assumptions about, what will be on the server or so on. You could define your own tasks, so you can drive the deployment the way you want it.

Josef Stribny [00:02:41]:
It was simply a tool given to you. And then they jump as everybody else on this Kubernetes train. Right? Like, big deployment, that have infinite scale. And to me, at the time, I was I remember it. I I was a little bit sad because I was like, they were the heroes of, kind of marketing the simple way of deploys. Right? So not everybody has to be on Kubernetes. And then it was announced that they are making, the leaf from cloud. Right? The big saving journey of leaving the cloud.

Josef Stribny [00:03:30]:
And I know they wanted to make Kubernetes work. They went to some vendors, you know, from SUSE and so on. And, David was talking, writing about that. But then he was probably thinking, okay. Maybe we can do something on our own, which is not really so unusual for David, I would say. And so they kind of went back to Capistrano roots, but for the new container era. So Kamal is designed, around Docker from the ground up. You know? And because of that, it also made some assumptions to make, some things a little bit easier.

Josef Stribny [00:04:13]:
So what state is the SSH kit, which is like Ruby library that simply connects over SSH to your server. But instead of running, some just pure bash code, You still run, you still run tasks, but they are usually around running Docker commands. So come on. Can install Docker and then simply run various, Docker commands tasks. The simplest way how you can think about it at the simplest level is simply that Gong will connect and run Docker run name of your application. You know? And, it doesn't even have a a specific Docker pool task, for example, because that's already something that Docker does itself. So command really tries to be as minimalistic as possible and as simple as possible. There are some limitations to that, of course, and I would say the simplicity maybe confuse people sometimes.

Josef Stribny [00:05:26]:
Because as you said, so what is the deploy process? Right? And usually, I would say before the deploy itself, you prepare the server beforehand, which we can call provisioning. You know? Part of that step can be even spinning up the virtual machines, for example, is what most people would probably do unless you have physical servers, and then installing some software firewalls and so on. It's just that with Camel, we don't need anything else for the Camel to work than Docker. And even Docker can be installed by Camel. So it simplifies it a lot, but it's still like one piece of a puzzle. Maybe you need other tools. You want to install some monitoring or recap scripts or whatever. So just one part of the wall of the wall process.

Ayush Nwatiya [00:06:16]:
Nice. So, noob question straight off the bat. Like, I I I assume this will also be, maybe a source of confusion for someone who doesn't know a whole lot about Docker or just, like, the modern deployment complexity and stuff. But can you, explain what the difference between Kubernetes and Kamal is for people who don't understand either of them?

Josef Stribny [00:06:45]:
Yeah. So, basically, you can split this kind of deploy systems to 2 categories. 1 is doing, push to the server. So you are pushing your configuration to the server, your changes to the server. In terms of come out, that means from your local computer or the CI server, you will run come out deploy, and come out will issue the concrete commands that have to run on all those servers that you defined. And Kubernetes is the other category, which we call, like, a pool systems, where usually you have one host that runs the main, master agent and so sort of way. And the other servers run some lightweight, minion, agents. And so the central system is that one master host, and then all the systems around it can pull the information from it.

Josef Stribny [00:07:52]:
So they constantly, fix the new information, and if they see, okay, there is a new version, then they go and pull the information themselves.

Ayush Nwatiya [00:08:02]:
Cool. That that makes sense. So, like, why would so me as an indie developer who is building very small apps on very small scale, and I'm thinking, do I even need Docker? Like, do I even need Kamal? Like, what what's your opinion on that?

Josef Stribny [00:08:20]:
Yeah. In terms of what I was think what I was speaking about, the split between, like, Kubernetes and the this agent systems, that's what I think that you don't really need for small scale. Right? Because you don't need extra resources to run the agents. You don't need the extra master server that maybe also needs some kind of, backup to be high available and so on. But as you say, there's still this question about Docker itself. Like, isn't even Docker overhead? Right? I I I saw some people commenting on, Ruby subreddit, and they were, like, kind of criticizing camel for using Docker when DHH wants Rails to be no build, hashtag no build, right, on the front end, but then introducing build process on the on the on the server side. But Docker still has, several advantages. First of all, we really package prepackage the application in the container, So we can be sure of what's really inside, and that at this revision, the application was running, which is important when you will be doing a rollback, you know, when something wrong happened and you want to roll back.

Josef Stribny [00:09:46]:
Then you know that the previous, version was actually running fine. The problem with Capistrano way of doing that is that suddenly you are trying to switch back to, Ruby version that hopefully is there, but maybe if there was some system changes, you know, system updates, system utilities, and a lot of real application also shell out to call some system system tools. Right? So suddenly, you don't even know what will happen because it can go all wrong.

Valentino Stoll [00:10:20]:
Yeah. For those that aren't aware, Travis trial is all, like, local file system and just has, like, a, you know, symlink cutoff to switch whatever production version you're using right behind the scenes. It's got, like, TLDR of it. There's other stuff. Right?

Josef Stribny [00:10:39]:
Yeah. Exactly as you say. And, of course, yes, it's simply a trade off. You can't really say it's so much better or so much worse. I think, for modern deploys, it's it's preferable to do it, with something like Docker or different container technology. But I do, sympathize somehow to to the Docker criticism because you now need, a Docker registry to save, your images, which, by the way, David suggested that they will get rid of in some future versions of Camel. So, hopefully, that will go away. But, yeah, it's new thing to to learn, basically, so I understand, especially because when I was writing my first book, deployment from scratch, I also basically did something like CapEx channel, except I didn't even use Ruby.

Josef Stribny [00:11:36]:
I simply do it with Bash only. You know? So you don't have to learn any other tool, and you can still install and, and run. And the biggest advantage there is that the switch to update can be really fast. If you are not even installing a new version of Ruby Gem, for example, it's really it's seconds. You know? It's it's really super fast. But I think the other advantages of Docker deploy is really really are better for for most people, for majority of people. And when I saw Kamal as a tool, I was I told myself, okay. This is it.

Josef Stribny [00:12:23]:
Because since I had this bash script kind of deploy, you know, very, very straightforward, I was thinking myself of doing some kind of small tool, something like Kamau. At the time, I was thinking maybe using some components like Kedi, for web server, you know, or maybe Podman instead of Docker, because my background is in, like, federal and and stuff. But I know that my little tool again be just for me. You know? So I thought, like, tunnel is the closest to what I want. And so that's how I basically started to be interested and started to look more into it.

Valentino Stoll [00:13:08]:
You know, I I really liked Kamal's direction. That make it just easier to jump on Docker without having to, like, necessarily worry about, like, how you configure Docker and, like, connect all of the services and things like that out of the box anyway. Right? And then because it sets you up kind of like, okay. If you needed to scale, you could then move to some other, you know, provider like AWS or something that could scale the nodes for you pretty easily, and you can reuse all the configuration stuff. And so it's a and a little exciting in that way. And it makes me it makes me think, though, like, like so how does this compare to, like, something like, you know, tools like Chef or, you know, some other configuration management aspects of, like, you know, the system deployment process? Like, where where are some advantages that Kamal could lead us Where, you know, maybe I know chef is like a it takes some extreme getting used. There's onboarding, ramp, like, pretty steep, learning curve. But, like, where where do you see Kamal, like, kind of maybe simplifying that, or how does it compare? Or does it not? Like

Josef Stribny [00:14:19]:
Yeah. I think that there is this confusion among the the deploy systems because then you have exactly as you say, Chef or Ansible, and they they maybe started as more like configuration tools, but they also offer you a way to do a deploy. You know? So they are not completely obsolete. With Camel because you can still use them, provision the servers, and then use Camel for the deploy part. In my case, I find that I don't need that much of the configuration. I mean, Camel itself even builds itself as almost you don't need anything, but that's not really true, and then people are disappointed. But for me, I, for example, included a very small Ruby script, which is just wrapped a little bit wrapper around some shell commands to provision some very basic things, for the server, like firewalls, different SSH user for security reasons, and so on. And in this way, you might find out that you need so little that you don't really need a proper tool like Chef.

Josef Stribny [00:15:37]:
But at the same time, I I wouldn't say that Camel makes it obsolete because they complement each other. I do wonder if if David, for example, still have in his mind to release something complementing Camel because Kamal is so simple, and it started as a multi server tool. But at the same time, it cannot deploy a local answer, like, in front of the servers. Right? You have a proxy that, does to get us the points on each of host, like each server, but you still need, like, 3rd party load balancer. So Kamal is, like, really, like, very specific tool, and I wonder if, simply Kamal will maybe get a little bit bigger and, better in this way to handle these things, or there will be something else, maybe.

Ayush Nwatiya [00:16:31]:
Would you use Kamal for your, like, own independent single server applications as well, or would you use your with bash script, whatever approach you thought in in your first book?

Josef Stribny [00:16:42]:
So I switched everything to Kamal for all my projects, and, also, I was working with some clients to switch them to come out. For me, the although I actually really used the best scripts from from the book, they were developed specifically to be educational. I didn't say don't use tools. Don't use Kubernetes. But I rewrite it to pure bash to simply show people that everything else is an abstract abstraction. Right? For For example, when you have Ansible, it's written in Python, it's sort of Python code that in the end prepares, a bash code bash script that it copies onto the remote server, and then it executes it there. Right? So I basically skipped the part where I have to teach someone about different tools because, to be honest, the tools come and go. So the idea for the first book was really not being about particular tool, but more like how this actually works.

Josef Stribny [00:17:51]:
But since we have come out, I think it's it's, for me, it's like a perfect tool. There's some alternative. You can look into DUKU or maybe even simple, DUKU Compose. But, personally, I think Camel has advantage to them because they are it it it's designed for multiserver use from the ground up. Basically, the single server use case was, like, added later. Right? We've come out too. And, compared to the cool, there's also a different philosophy. It's not like pass.

Josef Stribny [00:18:31]:
It's more like really just a deploy tool. But if I'm deploying my own application that I also develop, I think come out fits best to that to that use case. You know? Maybe if you want to deploy some public, application, maybe it's easier to install something like Coolify or some other tools that can one click install them. But I think if you are the developer of the application, it really fits the feels of it the the best. And for me, personally, I I I really switched, 100%.

Valentino Stoll [00:19:10]:
Yeah. To to add on, I'm seeing there's a there's a PR open right now to add a cloud native build packs to come all, which would be interesting, where you can basically, yeah, build the app based off of other ones, pretty easily.

Josef Stribny [00:19:24]:
Yeah. So, basically, that's that's the single, I would say, advantage of the today that it can be a little bit more magical. It somehow will build it for you, and you don't have to write Dockerfile. Right. But lucky for us, Rails actually comes with Dockerfile, so there is no extra work. It is not true for every every framework. But, of course, if you are adopting Docker, I still recommend looking into, how to build Docker file, how to optimize it. For example, before, I was trying to squeeze the Docker file for my Rails applications.

Josef Stribny [00:20:04]:
You know? I was removing all the all the files. I don't need them to to have small footprint since you have to do the image and pull, and push. So so yeah.

Valentino Stoll [00:20:20]:
So what is, like, kind of, like, the full process? Like, let's say we do, like, a Rails new app and we wanted to, like, deploy it with Kamal to, like, some Linode or something, right, or DigitalOcean droplet. Like, what what is the steps of the process there, like, to just, like, rails new? Yeah. I have, like, you know, c m

Josef Stribny [00:20:45]:
So let's say you do you did a rails new. You have your Dockerfile. So that's one that's one prerequisite you have to have. For the Dockerfile because maybe you are not on rails, so let's just mention that, you do need your server to run on port 80. You can change it, but it's like default if you want it to simply work. That's the that's the main thing for the Dockerfile. Then you will need a Docker registry. So make an account, a Docker hub, or maybe, your provider has its own registry that you can use.

Josef Stribny [00:21:29]:
And, you need to create, like, they call it come across it's still, like, registry password, but, you should create a token and note it down. And then you will need to create, some virtual machine. It can be Hetzner. It can be DigitalOcean. Any cloud provider like that would would work. And for that, you will need to create, SSH key pairs. So you will create key pair. That means you have 2 keys, 1 private and 1, 1 public.

Josef Stribny [00:22:11]:
Right? So the private, obviously, you have to protect, like the registry password. And, during the creation of the virtual machine, when you go, like, create, you choose some resources, you know, how big the VM should be and so on. And then it will ask you to copy your key there. So that's how they will provision, the the VM for you, and you should you you should disable the password, password login value are there just for security. And so that's the that's that's what you need to that's what you need to have, you know, at the at the minimum at at the minimum, like, the basic ones. Now maybe you also want to deploy to a domain name, so then, obviously, you have to purchase a domain name. And you will need a DSM record at the very least type type a to point your domain to the IP address to the public IP address you will get for the machine you just, provisioned. And if you have that, you can basically start with Camel.

Josef Stribny [00:23:29]:
With CAMAL in it, there is some basic basic configuration file. There are comments in line, so even when you never saw it, you can usually guess a little bit what you will have to, put there. So you will name your application. Carmel calls it service. Yeah. I would also say be careful of the name because when you are doing the Docker local private networking, it's also, like, kind of a name that you are using, so you cannot, like, put any characters you want there. You know? Just stick to normal letters and dashes, and then you are fine. So so so we are not surprised later that it doesn't that it doesn't work.

Josef Stribny [00:24:24]:
Then you specify the image, which is your container registries, username, like slash the application name, basically. And then you can put the IP address among servers. When you do that, you're configuring your application server by by default the role called web, and we can return just after this one how how Kamal splits the application server roles and accessories. But for now, if you just put there the IP address, that's enough. And, then you will configure your proxy. You will say, okay. I want SSL, and you will put their host, which is your domain name, or it can be also subdomain. It can be even more hosts if you want.

Josef Stribny [00:25:21]:
So very, very flexible. This is very nice. Then you finish up with the registry, and then there's builder configuration. But by default, I think there's some, reasonable value. And and once you have all this, then you only need to provide the environment, which is the secrets we, we talk about, like, common registry password, but it can be, many more secrets that the application have, obviously. So, you you list them in 2 ways. Basically, some environment variables, you can list directly, But the secret ones, you actually just, just put under, like, nth secret in the YAML in the YAML file, and then you only list them, but they live somewhere else. When you did the Camel in it from before, Camel also created dot Camel slash secrets file.

Josef Stribny [00:26:24]:
That's where the secrets are. And, of course, then you can also call password managers and so on. But at the very basic one, you would just put the secrets there. You will not check it out check it in in the source control, and then your configuration is done. You're on Camel setup, and camel does everything for you. It will connect to the server. It will install Docker. It will, install the camel proxy, and then it will boot your application.

Josef Stribny [00:26:59]:
So that's the most minimalistic way of deploying with

Valentino Stoll [00:27:03]:
command. Gotcha. So I'm walking through the commands, like, as you were reading through that, and just so, like, we can for the most people know Heroku. Right? Like, Heroku knew and then deploy, you know, put get push Heroku. And it seems like there's really, like, the 3, you know, Kamal commands that really do run through that. Well, everything you just said, right, which is pretty wild. Or we have, like, Kamal init creates all the configuration files. Kamal config, like, you know, starts to create your initial configuration file to add all of the stuff to.

Valentino Stoll [00:27:45]:
And then you have command deploy that just, like, push that up and proxy to the new version, right, of the app.

Josef Stribny [00:27:53]:
Yeah. Yeah. Basically, as you say I mean, the command config is already created with command in it, and command config simply rechecks the the configuration. It's good. That's actually good good point to run before the deploy. Yeah.

Valentino Stoll [00:28:09]:
That's awesome. I mean, that's, that's where we wanna head. Right? Like, it's, like, it's pretty close. I mean, I guess, like, yeah, I mean, so many, like, so many hosting providers now have that, like, one click process to just get your VM up that, it almost doesn't even make sense to abstract away that process, right, to make it easier because they already provide that for the most part. But this is really cool. So I'm trying to think, like, we walked through a very simple, like, example. Right? And I imagine, like, with all of the push to solid q and solid x y z, like, this is all running on a single machine. How does all of that work? Like, is it by default running the database on the same web server?

Josef Stribny [00:29:11]:
Yeah. So that's a that's a good good question for for talking a little bit about how Camel actually splits your application and what what it actually does for you. Because this is a simple example. We have 1 VM, the one one container. Right? But, your application probably does a little bit more. It has, it has to run jobs or some kind of other scheduling, or maybe you are running an API server or some marketing website, and then all those needs databases. So at the high level, Camel splits this into servers and accessories. So servers are your application servers.

Josef Stribny [00:30:02]:
Those all, run your application image, so you cannot build, like, from multiple images. It has to be one image. There's just different command that is being drawn, but it comes from that application. Of course, you can package whatever you want in the container, and you, for example, can have application role that runs a Django application next to it, you know, but you have to put it to the image because that's kind of a constraint that put puts a new. And with this server roles, it's important to say that there's a primary role. By default, it's called web, but you can rename it. And the primary role, assumption is that this is your main application server. That's your rails s, basically, or your, like, your Puma starting up.

Josef Stribny [00:30:58]:
And, why is it important? Because it plays in a role how come out actually, does deploy, on multiple servers and also on each particular server. Because when it boots your application, it usually puts your accessories, which are the databases, all these, low running services that are not necessarily I mean, they're connected with your application, but it's but it's something else. You know, they're not part of the COML Deploy process. They should already be running, and you are simply taking, use of it. But the primary is important because, CAMAL changed a little bit, regarding health checks and how it ensures that actually the container is healthy and can serve traffic or can run. Before with, with traffic, we had something like cord file. I will not really go into it because it's already kind of obsolete, but I will I will say that the new way, there is something called web barrier. Maybe you won't find this name in the docs, but you might find it in the in the code or somewhere in the issues.

Josef Stribny [00:32:18]:
That's how common maintenance call it. And the means that common will wait first for your web container to boot up successfully, the new one, for example, for the new version. And once it's healthy, then it assumes it can boot everything else. So all other roles, whether it's jobs or marketing sites or whatever you put there, will also start start without any further health check because the only come out proxy checks is for this primary role. So that's very important to realize. For example, you might be deploying front end and back end, you know, split. And with come out, you can have front end application as one application and back end as one application. But if you are putting it together and you are simply, splitting into roles, then one of them has to be the primary that come out.

Josef Stribny [00:33:18]:
We'll wait on, and then, it will also boot, boot the others. So that's, like, one important one important thing. You can still have health check also for other containers, but then it's just the regular Docker health checks that you can add there, but nothing to do with the tamout proxy process of of booting.

Ayush Nwatiya [00:33:40]:
So, which, Docker registry would you personally recommend people use?

Josef Stribny [00:33:47]:
I think the, so I personally use Docker Hub, right now. I want to support them because I know they had hard time as a company to actually actually make money out of Docker. And it's great that Docker is free and everything, you know, but to to support them, I I use them currently. Maybe the smart answer is use the registry with your provider because it might be faster for you. You know? Might be even cheaper because I think they're increasing prices right now with Docker Hub. But, I like the idea of supporting them in some way. So right now, I'm using their registry.

Ayush Nwatiya [00:34:37]:
Cool. And, so the thing with, this is more of a broader question around, self hosting as opposed to, using a a pass. The 2 things that kinda scare me about self hosting, which is why I haven't actually, deployed an app by myself yet. I use render.com personally. The 2 things that kinda scare me, one is database backups, for, like, I use post cross personally, but I probably use SQLite for the next project, which would make life a bit easier in that regard. But database backups and OS upgrades. So, like, for someone who's only ever used, like, Heroku or Rendon, never had to worry about this kind of stuff, what would you tell them?

Josef Stribny [00:35:22]:
Well, so you mentioned backups first. Right? So and the a Docker way of of doing backups, is is likely to simply run a Docker container that does backups. Right? That's that's the correct way because you have to run everything in Docker. You can still do manual backups as before. I actually mentioned it in camel handbooks how to how to do it. So you can still do manual backup. You can call you know, the the the command is a bit larger because you have to use the it is actually a good point that camel to edit aliases so you can prepare these commands and then have, like, nice come out backup, and it will do backup. Right? So so in a way, it works the same as, as normal self hosting, but it's definitely more work than just using managed database.

Josef Stribny [00:36:20]:
And I would say it might be good for people to first just move with their, server load, like application servers, and wait with the database. Just use to manage the database. There's nothing wrong with that. In fact, I I think most people will run it like that, will take advantage of the managed database because it saves you a lot of hassle, which is true. But, yeah, if you want to do it yourself, you will turn the container there, then you can upload it, for example, every day to s 3 or something like that and also have a way to pull pull it back if something happens. I also recommend to always turn on the automatic VM, backups, which means, the whole VM is back up, like, every day on your, cloud hosting provider. This is especially cool for, like, this project that, for example, I deploy. You know? They are not big yet.

Josef Stribny [00:37:20]:
They are 1 per server. So I know I have snapshot every day, database, and but also everything else. So I can just with one click to re return there and and continue, which is really, really good. But, you know, as it is with backups, it's good to always have, like, 2 different backups, maybe, just to be sure. So I think that extra, extra assurance can be this, virtual machine backups as a as a whole. Yeah. And, actually, with the system updates, I I think it's kind of similar because if you have backup of the VM and you can return and, return to the, to the to the process later. And with Camel, if you have more hosts, you can simply, put put the host that you're upgrading, like, kind of offline, you know, upgrade the system there, and then you put it back to the pool of servers.

Josef Stribny [00:38:21]:
That's ideal. If you if you have more servers and you can do it, that's that's, like, safe way to to to run it.

Valentino Stoll [00:38:28]:
Does the does the current Kamal proxy handle, like, load balancing to do, like, slow rollouts of versions of the app? Or

Josef Stribny [00:38:38]:
Yeah. Yeah. It will it it you it does so called blue green deploy. So on every host, it will put a new application. You are running also the old one. Then after the health check, it it it's switched. But then also it, like, goes and runs it across all hosts. Right? So Yeah.

Josef Stribny [00:39:01]:
Yeah. There's some settings, some little settings, around that, and it will do the rollout for you. Yeah.

Valentino Stoll [00:39:13]:
That's really cool. So I'd I'd love to to shift gears a little bit into this whole, like, Kamal accessory, stuff. Because it this is something I I wasn't immediately obvious, like, how it all works and when's the best use case, right, where when it's not good thing to use as an accessory. Like, what is an accessory? Right? Do you wanna just give us, like, a high level, like, what the Kamala accessories are and, like, one example of, like, the most common one that you would add to a a in that new app?

Josef Stribny [00:39:48]:
Yeah. So, basically, accessories are come a way of running, like, some kind of permanent services, you know, that are not part of that deploy life cycle. They simply run, next to it, whether that's relational databases, key value stores, search engines, maybe headless browsers, you know, anything else that you just run as a service, basically. So what's the service? Your application is is using. Most people will simply, use a database as a as a accessory or first accessory, and then you can run accessories on the same host or different host. Basically, that's what I really like about. You simply put the IP there, IP address, and it will deploy on that host, you know, where where that does an application role or accessory. It just puts it there where you want it.

Josef Stribny [00:40:49]:
If you, if you want to collocate it with the roles, you can also just say, okay. Just put it where the role that is, and then it'll automatically put the application next to I mean, your database next to your application on that server, so you don't even have to specify the IP again, for example. But, in principle, you can really spin it up anywhere anywhere you want.

Valentino Stoll [00:41:15]:
That's neat. So, like, let's say a more maybe more advanced one would be something like Sidekick or, like, a background processor. Like, how do the deploys then work, like, as you deploy a new version and it needs to, like, do, like, a rolling restart to wait for, you know, whatever jobs to finish before it it cycles over to the new version, for new jobs? What's that kind of process?

Josef Stribny [00:41:47]:
So with with Sidekick, it's, we are still talking about application role. We would call it, like, jobs, for example. Right? And as I said before, it's not a primary role. So the the health check there is not really done. It waits for the web container to to boot. And once at least one of them boots, so it doesn't it can be on different host. You know? Like, once it successfully boots, come also, okay. I know the application.

Josef Stribny [00:42:23]:
It's probably built well. That's the assumption. Then it will simply start the good process for also the the other roles. So for roles that are not web based, there's this assumption that you can simply decommission them and, you know, start them again. If you have more, web roles, you can you can also say that, okay, run the proxy, come up proxy with this role, and then the request will be, still drained. So, come up proxy will still bait for the request to finish before it will be switching. You know? But that's really just the roles that are, what we could call proxy roles, roles that use proxy. But the other ones, they are not really there's not really big assumption of, like, come out is a tool that doesn't know that you are deploying Sidekiq or that you are deploying SQL accessory.

Josef Stribny [00:43:29]:
It it doesn't know. You know? That's why there's also not, like, some kind of plug in to run SQL or MySQL. It's it's the configuration you have to do. That that's that's the simplicity, but maybe also annoyance for some people that use tamil just does what what you tell it to do.

Valentino Stoll [00:43:48]:
Gotcha. So you you it's just the interface. You have to, like, kinda figure out all the implementation details of it, of how you're using it.

Josef Stribny [00:43:57]:
Yeah. In the simplest way, it's really just trans docker containers with docker run, and sometimes there are, health check involved. You know? And it's important to learn how the life cycle goes like that. Oh, okay. Accessors are booked first, then then the servers are booted first, primary role, then the others. And then you realize that then you can think about how to how to write the configuration you you need.

Valentino Stoll [00:44:27]:
So what what what are the the latest releases in, version 2 that you that has gotten you pretty excited about?

Josef Stribny [00:44:36]:
Yeah. So I think, Camel 2, Camel 2 is now probably interesting even to people that weren't interested in Camel 1. You know? For 1, deploying to a single server is so much easier and straightforward. There were ways how to do it with camel 1, but you had to configure traffic, and it was a bit annoying. And now it's all seamless in the config, which is for our which holds SSL true, and, there you have it. It's like number 1, thing for camel 2 that it auto provisions your SSL certificate with lots and encrypt. Don't have to do anything. It's just, in the configuration.

Josef Stribny [00:45:24]:
But there is one caveat I would just say with that. It does not apply for multi host, deployment because, again, Camel is so simple. There is no centralized way of sharing the the issued certificates, for example. You know? The different host doesn't know about each other. So if you would be issuing certificates again on every host, then maybe you run out of the attempts that let's encrypt or something like that. But for single server, there's, like, big leap forward, I would say. But, in general, the depots get faster, you know, because of the process I I described. So there's maybe a little bit less health checks done because there's just, like, one for the primary roles, and then we are rolling.

Josef Stribny [00:46:14]:
We are going for it. But that makes it, really faster. Also, ditching traffic has one nice side effect that the server CPU utilization went down because that was one thing that was constantly pulling for, like, state of Docker containers. Right? Because the configuration doesn't live in on traffic side, but on the container side, so it's constantly pulling. So if you would look, you would have some CPU utilization all the time, and that that's not the case with the new new common proxy. You know? The proxy is pretty, like, simple. It doesn't do too much. It routes to host.

Josef Stribny [00:47:03]:
You can register a service. It takes care of joining the request when it's switching over. No. And there there are not many features of, like, what proxy could have, like, KEDI or NGINX. You know? It does some basic request response buffering or, handle, like, maximum request sizes, and proxy headers. But it doesn't even do anything with, let's say, your static assets. Right? For for that, we have Truster. So they didn't really copy, for example, this functionality to, to come out proxy.

Josef Stribny [00:47:44]:
It's, it's still simple. I think simple is good. Some people might find it limiting. Let's see, what we'll see in the future because I would say the development of Camel since I started to look into it. And then even since I started to write Camel handbook was really, really fast. Right? I I did already, like, 2 updates, like, basically, 2 additions. The first one with a big update for command 17. So, yeah, it's faster.

Josef Stribny [00:48:18]:
It's much easier to use, I would say, and things are things are going well.

Valentino Stoll [00:48:26]:
Yeah. You did you bring up, something that I I was trying to work through. How you were doing, Kamal? I guess, like, let's say, like, you know, you wanna, like, configure or tune some, like, NGINX caching or, proxy specific in NGINX or some other system level configuration. Is that all handled, like, in whatever, server that you would configure with Kamal? Like, it's it's a step away from that, aspect? And maybe how does it, like can it work with it, to to auto generate that kind of stuff?

Josef Stribny [00:49:07]:
So so, come out with some assumption. As I said, it doesn't provision load balancer in front of your servers. Right? And, similarly, it doesn't, really, handle some serving of static assets. The assumption is that you either use something like Shuster inside your image, for example, so you have one more little proxy there. You could also have, for example, your own, engine's load balancer that would also does this caching, but you will have to deploy it yourself. That's the thing.

Valentino Stoll [00:49:42]:
Yeah.

Josef Stribny [00:49:43]:
Somehow won't do it for you. Or there's this assumption that most people maybe will just proxy with Cloudflare and, do the caching there. You know? So there's some limitation to it. For most people, I think, there's they have to do it. It's just like it's not handled directly in come out right now.

Valentino Stoll [00:50:07]:
Gotcha. Yeah. That makes sense. I mean, still early days.

Josef Stribny [00:50:15]:
Yeah. Yeah. I think so.

Valentino Stoll [00:50:17]:
Well, cool. So is there any, like, dashboard or monitoring or something like that, that's available to, like, kind of see things? I see there's, like, a, you know, come all details where you can kinda peek at the apps and services running. Is there any, like, UX, stuff out there that people are using to to visualize or gather metrics or things like this?

Josef Stribny [00:50:42]:
Well, I I believe that for the Samsung, they use something like from Elastic's, such tag like Graphene or or something like that. For my this thing server depots, for example, I take advantage of digital ocean agent because you can just click you want it, and then you have very beautiful, dashboard that you get for free, basically. You can even set up alerts. So for very small hosting, for example, what I do, I think that works very nicely. I know that somebody is making something, but it was not announced. So maybe there will be some come out specific tooling. But right now, we don't have it. So you have to do the, usual way if you want host monitoring, install that data dot agents, you know, or link Grafana.

Josef Stribny [00:51:39]:
It's definitely something that's not really soft in the, I would say, easy way to just to just, like, enable and and run with. But I I think that would be that would be some nice, nice projects for somebody for sure.

Valentino Stoll [00:52:00]:
Hey. You definitely got me, wanting to deploy a couple of apps just for fun. So what are what are maybe some, some things that you're looking forward to, or or maybe hopeful that they get added? I mean, outside of, like, the two items that we just talked about, with the, you know, maybe making proxying a little easier or the metrics aspects. Like, is there anything missing from the process that you, like, hope gets added?

Josef Stribny [00:52:34]:
For me, I was kind of already happy with Camel one. I mean, now that I see Camel 2, I'm even more happy. But I kind of already made it work. You know? It it it it it did it did the job. And, for example, when you when we were comparing with Capistrano in the beginning, you know, it doesn't also, have some kind of dashboard for you, you know, because the tool is limited. And some in some way, it's I think it's good that it has some kind of limits or some kind of philosophy of what it wants to be, and then there can be a sister project that provides the extra, extra features. So I will talk about, of course, like, this kind of dashboard or maybe even nicer backups. All these things would be nice or maybe provisioning.

Josef Stribny [00:53:24]:
Actually, it was my idea that I could develop, this project, that it would be like 0 config provisioning for Camel. That would be the the headline. You know? I don't know if I will get to it, but that's idea I I have. So so, personally, I would say the sister projects. I also think that that David suggested that the account will probably stay focused, and I think I think it's a good thing. Because when I look at Docu, for example, it was like the single server pass, and it was very well for that. But now I I checked docs recently, and I see that there's also a way how to spin up a k three s scheduler. You know, and then you are, like, kind of deleting the tool to be everything for everybody.

Josef Stribny [00:54:15]:
And, that's also, in the end, a negative for me. So so I'm happy if it stays stays simple, you know, improves in little ways, and I'm happy, man. Yeah.

Valentino Stoll [00:54:31]:
Yeah. I hear you. It's gonna be hard to shake, like, the existing, like, larger infrastructure stuff, focusing on, like, the the very specific simple utility of Docker maintenance and services. Definitely is appealing. Like, going off of that then, is there anything, like, you would like to see removed from the overall, like, architecture process, that maybe is just causing more headache and confusion than is adding value?

Josef Stribny [00:55:02]:
Not really. I have to say that the change with secrets for me was a little bit, maybe a downside in in a my specific way. Because what I was doing, since I knew how come out really worked, I kept on CI maybe just, like, 2 amps, and I could, like, just do deploy it and not really put my secrets to to GitHub, you know, which I was very happy about. And now you either have to put it there or use a secret, manager, which, of course, if you're a company, you should be using the security management. But for me, I was like, I have this this little project, and I was happy that I could do it this way, and now I can't. But in a way, I still think it's probably better. It's just like in my specific case, I was happy to also deploy without the change to environment. Because before, it was 2 steps, come on v 5.

Josef Stribny [00:55:56]:
This is push the amps, and then come all deployed. But now it's all together. So you do need all amps because if you don't have them, then it will fail. So that's maybe, like, one thing in my specific case, but I I I think, generally, it's it's still a step forward for for Camel. And, you know, I I wish people would maybe replace some Kubernetes clusters. But to be honest, it's probably not what will necessarily happen. I think the the most value, from CAML can get people that are now deploying with just Docker Compose. Because Docker Compose is originally like dev tool.

Josef Stribny [00:56:41]:
You have to put all the containers down and up. And I know there are some third party proxies that tries to solve this step plus deploy. But Camel is so much nicer in in in my opinion. You know? And, whatever criticism you will have for Camel, it will probably apply there as well. So I think it's just like a plus. It's just a better tool. But, yeah, we'll we'll see.

Valentino Stoll [00:57:15]:
Yeah. I think we've we've covered quite a lot of topics here. We're kind of coming to, you know, time here, but, is there any other, things you wanted to cover before we move into our pick section of the show?

Josef Stribny [00:57:33]:
Not not not really cover, but, if I can, I would just, like, want to thank you, David, for even starting Camel? And, also thank Donald and Ben who, done a lot of work on Camel 2 and also wrote a forward so so thank you, Donald. And also to Kevin McConnell because he was the main guy behind Camel proxy. He's very important aspect of camel too. And then also a final shout out to Rosa, because, she kind of sent done all the information that I am writing the book, and then he wrote me an email, and that's that's how it all happened. So yeah. Thank you. Thank you, guys. And everybody else that, you know, works on camel, I would like to think.

Valentino Stoll [00:58:28]:
Yeah. Seriously. Thank you. All this stuff is definitely gonna make it easier to work with Docker at least. Yeah. But it should be it should help with deploys in general. It's it's definitely helpful to have a definitive, Rails process for deployments, which was missing for quite a long time. So it's exciting to see.

Valentino Stoll [00:58:50]:
Well, great. We're gonna move into picks. It's a segment of our show where we just find some things that we are excited about in life or code or, whatever it may be that pique your interest. And, I can, I could kick us off? I have this particle, I guess, infatuation. It's a little hardware devices, little microcontrollers. They have this little development board called the the muon that lets you do things, with cellular and, mesh it, with, like, you know, Wi Fi, so you can get it, like, kind of, like, a blended solution on a microcontroller. It's it's a lot of fun. I'm messing with it, just for fun.

Valentino Stoll [00:59:44]:
And, I've been playing with OpenAI's new pipeline for fine tuning stuff. They call it distillation. It's a lot of fun where you could just send all of your, AI prompts and responses, to OpenAI, and they'll automatically, like, fine tune a new model for you based on the outputs and inputs that you give it, which is just wild. So I was I'm I'm having a lot of fun just messing around and seeing, what I can get it to do.

Ayush Nwatiya [01:00:20]:
Nice.

Josef Stribny [01:00:21]:
Yeah. I just searched it.

Ayush Nwatiya [01:00:25]:
I've gone. Yes. I've gone.

Josef Stribny [01:00:28]:
Yeah. I just wanted to say, like, also like this, just little improvements in in life that you can do. For example, on my travels this year, I switched to finally using eSIM so I didn't have to, like, you know, buy a physical SIM change, on the airport when I was, like, sweaty and tired and everything. Because I just, like, clicked in my phone and I had service. And it's like these little things that, like, actually are really amazing that that that that I love. But, since, my book is about also, like, kind of doing something independently, you know, like, in the in the hacking spirit, I I want to do a recommendation for one show. It's called the indie life. It's by.

Josef Stribny [01:01:20]:
He was doing a start up. He kind of failed. He also got divorced, and now he's, like, starting this show where where he discusses with people. Also, the not so glamorous side of this India King entrepreneurship and stuff. It's a nice show, so I would recommend this to check out.

Ayush Nwatiya [01:01:45]:
Cool. Is there any eSIM provider that, that you recommend? Because I'm traveling to New Zealand in a couple of in a part 3 weeks, and I was looking at eSIMs as well.

Josef Stribny [01:01:56]:
It was just my first time. I picked one that, sounded it covered the countries. I go and that's it. But it worked it worked nice. It's probably a bit more expensive, but, I mean, I I really appreciate the the, the leveling up in the comfort of of travel. So for me

Ayush Nwatiya [01:02:17]:
Yeah. Yeah. Sure. It's definitely worth the worth the price. Yeah. Right. My picks. I've got I've got a movie and a TV show.

Ayush Nwatiya [01:02:25]:
So I watched a movie last night called, A Night on Earth by Jim Jarmusch. I think it's from 1991. Absolutely brilliant. If you like, like, character driven movies that don't have a lot of plot but a very colorful characters. This is the kind of movie for you, I think. Really enjoyed it. A guy I met I met at, at the Haggis Ruby Conference last week. I recommended this movie that's why I watched it.

Ayush Nwatiya [01:02:54]:
And, yeah, I'd recommend it to everyone else. And, season 2 of a show called shrinking has just started on Apple TV. I love season 1, and season 2 started off really strongly as well. I think 4 episodes are at. It's, starring Harrison Ford and, Jason Segal from, any of my who's familiar with How I Met Your Mother, would would know who he is. And Ted Lasso fans would also be happy to hear that Brett Goldstein has now has joined the cast for season 2. So if any of the names ring a bell, might be sure we're checking out because because I'm a huge fan. Yeah.

Ayush Nwatiya [01:03:37]:
Those those those are my 2 picks.

Valentino Stoll [01:03:40]:
Awesome. Yeah. I I always love a good, TV movie show combo. Well, Josef, it was it was really great having you on today. Thank you for sharing all of your, you know, deep diving on Kamal. And, for those that haven't checked it out yet, check out all of, Joseph's great books that he's putting together. The Kamal Handbook for sure. I'm gonna be diving into that myself.

Valentino Stoll [01:04:11]:
So appreciate you taking the time today and, honestly, spending all that time putting putting this content together because it's, it's much needed.

Josef Stribny [01:04:21]:
Thank you. And, thank you for having me on the on the show. I enjoyed a lot.

Valentino Stoll [01:04:27]:
Awesome. Well, we'll have to have you, come on again when, Kamal 3 comes out, and we can Sure. Get you to tear apart all the all the great new features, that are to come, I'm sure. Perfect. Well, that's it for Dave Folkes. I'm Valentino. Thank you, Ayush. Thank you, Yosef.

Valentino Stoll [01:04:46]:
Till next time.