Speaker 1: Hey, everybody, welcome to another episode of the Ruby Rogues podcast.
Speaker 1: I am your host today, Valentino Stul and I'm joined
Speaker 1: by our.
Speaker 2: Co host Ayush.
Speaker 3: Hello.
Speaker 2: Hello, and we have a very special guest today, Joseph.
Speaker 1: Do you want to introduce yourself and tell everybody why
Speaker 1: you're Ruby famous here?
Speaker 4: Yes? Hello everyone, So I'm Yoseph. I am a freelance
Speaker 4: software engineer and apparently now also a book author. I
Speaker 4: wrote two books. The first one was called Diploma from
Speaker 4: Scratch and the second one is called Kamal Handbook, and
Speaker 4: that's probably by VR here today.
Speaker 1: Yeah, you know that Kamala is like the one of
Speaker 1: the latest crazes with all the new reels announcements that
Speaker 1: came out of raals World. So it's kind of exciting
Speaker 1: to have an expert here, or at least somebody who
Speaker 1: has dove into the trenches and put together all the
Speaker 1: details for us to, you know, expose the secrets of
Speaker 1: how minimalistic it is.
Speaker 2: I hope.
Speaker 1: I honestly haven't had a chance to play with Kamal,
Speaker 1: so I'm looking forward to hearing your take on how
Speaker 1: it all comes together.
Speaker 4: Yeah. I did a deployer or two before the show just.
Speaker 2: So I know.
Speaker 1: So I guess we can start maybe at a high level,
Speaker 1: like you know, what does the deployed process like look like?
Speaker 2: You know, maybe before Kamal and why Kamal is even here.
Speaker 4: Yeah, so maybe it would be interesting to see it
Speaker 4: from the point of forty seven Signals, because they are
Speaker 4: the company behind Come right was actually started by David
Speaker 4: helmer Hanson, so o profrails. He also started coming up
Speaker 4: and they were doing the deployment with a capistannel, which
Speaker 4: is a simple Ruby deployed tool. You basically have all
Speaker 4: your little tasks are predefined in Ruby and then you
Speaker 4: simply run them they're under the server and something happens.
Speaker 4: You know. Capis Channel at the time didn't do much
Speaker 4: assumptions about what you'll be on the server or so on.
Speaker 4: You could define your own tasks so you could drive
Speaker 4: the deployment the way you wanted. It was simply a
Speaker 4: tool given to you and then the jumped as everybody
Speaker 4: else on this Kubernetes train, right like a big deployment
Speaker 4: that have infinite scale. And to me at the time,
Speaker 4: I was I remember I was a little bit sad
Speaker 4: because I was like they were the heroes of kind
Speaker 4: of marketing this simple way of deployees right, so not
Speaker 4: everybody has to be on Kuberneti's And then it was
Speaker 4: announced that they are making the leaf from cloud right
Speaker 4: the big saving journey of leaving the cloud, and I
Speaker 4: know they wanted to make Cournetti's work. They went to
Speaker 4: some vendors, you know, from Susan and so on, and
Speaker 4: David was talking writing about that. But then he was
Speaker 4: fairly thinking, okay, maybe we can do something on our own,
Speaker 4: which is not chilly, so unusual for David, I would say,
Speaker 4: And so they kind of went back to capistannel routes.
Speaker 4: But for the new container, Era is designed around Docker
Speaker 4: from the ground up, you know, and because of that,
Speaker 4: it also made some assumptions to make something a little
Speaker 4: bit easier. So what state is the ssh kit which
Speaker 4: is like Ruby library that simply connects over SSH to
Speaker 4: your server, but instead of running some just pure best code,
Speaker 4: you still run. You still run tasks, but they are
Speaker 4: usually around running Docker commands. So kamaka install Docker and
Speaker 4: then simply run various Docker commands tasks. The simplest way
Speaker 4: how you can think about it at the simplest level
Speaker 4: is simply that can will connect and run docor run
Speaker 4: name of your application, you know, and it doesn't even
Speaker 4: have a specific Docker pull task, for example, because that's
Speaker 4: already something that Docker does itself. So comma. Really it
Speaker 4: trives to be as minimalistic as possible and as simple
Speaker 4: as possible. There are some limitations to that, of course,
Speaker 4: and I would say the simplicity may be confused people
Speaker 4: sometimes because as you said, so what is the deploy process, right,
Speaker 4: And usually I would say before the deploy itself, you
Speaker 4: prepare the server beforehand, which we can call provisioning, you know.
Speaker 4: Part of that's that can be even spinning up the
Speaker 4: virtual machines, for example, is what most people would probably
Speaker 4: do unless you have physical servers, and then installing some software,
Speaker 4: firewalls and so on. It's just that it's come out.
Speaker 4: We don't need anything else for the come out to work.
Speaker 4: Then Docker and even Docker can be installed by so
Speaker 4: it simplifies it a lot, but it's still like one
Speaker 4: piece of a puzzle. Maybe you need other tools you
Speaker 4: want to install some monitoring or the cup skips or whatever.
Speaker 4: So just one part of the role of the wo process.
Speaker 3: Nice, So new questions straight after that, h like I
Speaker 3: assume this will all to be maybe a source of
Speaker 3: confusion for someone who doesn't know a whole lot about
Speaker 3: Docker or just like the modern deployment complexity and stuff.
Speaker 3: But can you explain what the difference between Kubernetes and
Speaker 3: camale is for people who don't understand either of them.
Speaker 4: Yeah, So basically you can split this kind of the
Speaker 4: point systems to two categories. One is doing push to
Speaker 4: the server, pushing your configuration to the server, your changes
Speaker 4: to the server. In terms of come out, that means
Speaker 4: from your local computer or the CI server, you will
Speaker 4: run came out, deploy, and come out will issue the
Speaker 4: concrete commands that have to run on all those servers
Speaker 4: that you defined and kuvernatives is the other category, which
Speaker 4: we call like a pull systems, where usually you have
Speaker 4: one host that runs the main master agent in sort
Speaker 4: of way, and the other servers run some lightweight minion
Speaker 4: agents and so the central system is that one master
Speaker 4: host and then all the systems around it can pull
Speaker 4: the information from it. So they constantly fax the new
Speaker 4: information and if they see okay, there is a new version,
Speaker 4: then they go and pull the information themselves.
Speaker 3: Cool. That that makes sense, So like why would say
Speaker 3: me as an indie developer who is building very small
Speaker 3: apps on very small scale, and I'm thinking do I
Speaker 3: even need docer, Like do I even need come out?
Speaker 3: Like what what's your opinion on that?
Speaker 4: Yeah, in terms of what I was thinking, what I
Speaker 4: was speaking about the split between like Kubernetes and the
Speaker 4: agent systems. Uh, that's what I think that you don't
Speaker 4: really need for small scale, right because you don't need
Speaker 4: x RA resources to run the agents. You don't need
Speaker 4: the x and master server that maybe also need some
Speaker 4: kind of back up to be high available and so on.
Speaker 4: But as you say, there's still the question about Docker itself,
Speaker 4: like isn't even Docker overhead, right? I saw some people
Speaker 4: commenting on Ruby subreddit and they were like kind of
Speaker 4: criticizing come out for using Docker when the church wants
Speaker 4: re else to be no built, as the no built
Speaker 4: right on the front end, but then introducing build process
Speaker 4: on the on the on the server side. But dooker
Speaker 4: still has several advantages. First of all, we really package
Speaker 4: prepackage the application in the container, so we can be
Speaker 4: sure of what's really inside and that at this revision
Speaker 4: the application was running, which is important when you will
Speaker 4: be doing a roll back. You know, when something wrong
Speaker 4: happened and you want to roll back, then you know
Speaker 4: that the previous version was actually running fine. The problem
Speaker 4: with Capistrano way of doing that is that suddenly you
Speaker 4: are trying to switch back to a Ruby version that
Speaker 4: hopefully is there, but maybe if there is some system changes,
Speaker 4: you know, system update, system utilities, and a lot of
Speaker 4: application also shell out to call some system system tools. Right,
Speaker 4: so suddenly you don't even know what will happen because
Speaker 4: it can go all wrong.
Speaker 1: Yeah, for those that aren't aware, Cavistrano is all like
Speaker 1: local file system and just has like a you know,
Speaker 1: simblink cut off to switch whatever production.
Speaker 2: Version you're using right behind the scenes teldr of it.
Speaker 2: There's other stuff, right.
Speaker 4: Yeah, exactly as you say. And of course yes it's
Speaker 4: simply a trade off. You can't really say it's so
Speaker 4: much better or so much worse. I think for more
Speaker 4: deploys it's preferable to do it with something like Docker
Speaker 4: or different continued technology. But I do sympathize somehow to
Speaker 4: the local criticism because you now need a doctor registry
Speaker 4: to save your images, which, by the way, David suggested
Speaker 4: that they will get rid off in some future versions
Speaker 4: of come out, so hopefully that will go away. But yeah,
Speaker 4: it's a new thing to learn basically, so I understand,
Speaker 4: especially because when I was writing my first book, Diploma
Speaker 4: from Scratch, I also basically it's something like a pistannel,
Speaker 4: except I didn't even use Ruby. I simply do it
Speaker 4: with Besh only, you know, so you don't have to
Speaker 4: learn any other tool, and you can still install and run.
Speaker 4: And the biggest advantage there is that the switch the
Speaker 4: update can be really fast if you are not even
Speaker 4: installing a new version of Ruby GM for example. It's
Speaker 4: really it's like and you know, it's it's really super fast.
Speaker 4: But I think the other advantages of doctor deployees really,
Speaker 4: oh really are better for most people, for majority of people.
Speaker 4: And when I saw Kamal as a tool, I was
Speaker 4: I told myself, okay, this is it. Because since I
Speaker 4: had this Besh script kind of deploy you know, very
Speaker 4: very straightforward, I was thinking myself of doing some kind
Speaker 4: of small tool, something like comal. At the time, I
Speaker 4: was thinking maybe using some components like Caddy for web server,
Speaker 4: you know, or maybe Potman instead of Docker. Because my
Speaker 4: background is in like federalit knuks and and stuff. But
Speaker 4: I know that my little tool again be just for me,
Speaker 4: you know, so I thought like Tamil is the closest
Speaker 4: to what I want, and so that's how I basically
Speaker 4: started to be interested and started to look more into it.
Speaker 1: You know, I really liked Kamal's direction to make it
Speaker 1: just easier to jump on Docker without having to like
Speaker 1: necessarily worry about like how you configure Docker and like
Speaker 1: connect all of the services and things like that out
Speaker 1: of the box anyway, right, and then because it sets
Speaker 1: you up kind of like Okay, if you needed to scale,
Speaker 1: you could then move to some other you know, provider
Speaker 1: like AWS or something that could scale the notes for
Speaker 1: you pretty easily, and you can reuse all the configuration stuff.
Speaker 1: So that's a little exciting in that way. Uh, and
Speaker 1: it makes it it makes me think though, like like
Speaker 1: so how does this compare to like something like you know,
Speaker 1: tools like chef or uh, you know, some other configuration
Speaker 1: management aspects of like you know, the system deployment process,
Speaker 1: Like where where are some advantages that Kamal could lead
Speaker 1: us where you you know, maybe I know Chef is
Speaker 1: like a it takes some extreme getting used there's onboarding
Speaker 1: ramp like pretty steep learning curve, but like where do
Speaker 1: you see CAMAL like kind of maybe simplifying that or
Speaker 1: how does it compare or does it not.
Speaker 4: Yeah, I think there's this confusion among the deploy systems
Speaker 4: because then you have exactly, as you say, CHEF or Unstable,
Speaker 4: and they may be started as more like configuration tools,
Speaker 4: but they also offer you a way to do a deploy,
Speaker 4: you know, so they're not completely obsolete. We've come out
Speaker 4: because you can still use them provision the servers, and
Speaker 4: then you come out for the deploy part. In my case,
Speaker 4: I find that I don't need that much of the
Speaker 4: configuration I mean come out itself, even builds itself as
Speaker 4: almost you don't need anything, but that's not really true,
Speaker 4: and then people are disappointed. But for me, I for example,
Speaker 4: included a very small Ruby script which is just wrapped
Speaker 4: a little bit rapper around some show commands to provision
Speaker 4: some very basic things for the server like firewalls, a
Speaker 4: different associate user for security reasons, and so on. And
Speaker 4: in this way you might find out that you need
Speaker 4: so little that you don't really need a proper tool
Speaker 4: like CHEF. But at the same time, I wouldn't say
Speaker 4: that Kama makes it obsolete because they compliment each other.
Speaker 4: I do wonder if David, for example, still have in
Speaker 4: his mind to release something complimenting Comal because Kama is
Speaker 4: so simple and it started as a multi server tool,
Speaker 4: but at the same time it cannot deploy a lot
Speaker 4: bal answer like in front of the servers, right, you
Speaker 4: have a proxy that does to get plus the poise
Speaker 4: on each of hosts, like each server, but you still
Speaker 4: need like third party load bal answer. So Kamala is
Speaker 4: like really like very specific tool, and I wonder if
Speaker 4: simply comeal will maybe get a little bit bigger and
Speaker 4: better in this way to handle these things, or there
Speaker 4: will be something else.
Speaker 3: Maybe would you use Kamal for your like on independent
Speaker 3: single sub applications as well, or would you use your
Speaker 3: vast script whatever approach you thought in your first book.
Speaker 4: So I switched everything to come out for all my projects,
Speaker 4: and also I was working with some clients to switch
Speaker 4: them to come out for me. The Although I actually
Speaker 4: really used the best scripts from the book, they were
Speaker 4: developed specifically to be educational. I didn't say don't use tools,
Speaker 4: don't use kuberneties, but I rewrited it to pure beash
Speaker 4: to simply show people that everything else is an a abstruction. Right.
Speaker 4: For example, when you have answerable, it's written in Python,
Speaker 4: it's a lot of Python code that in the end
Speaker 4: prepares a best code best script that it copies onto
Speaker 4: the remote server and then it executes it there. Right.
Speaker 4: So I basically skip the part where I have to
Speaker 4: teach someone about different tools, because, to be honest, the
Speaker 4: tools come and go. So the idea for the first
Speaker 4: book was really not being about particular tool, but more
Speaker 4: like how this actually works. But since we have come out,
Speaker 4: I think it's it's for me. It's like a perfect tool.
Speaker 4: There's some alternative you can look into Doku or maybe
Speaker 4: even simple docer composed, but personally I think come Out
Speaker 4: has advantage to them because they are it's designed for
Speaker 4: multi server use from the ground up. Basically the single
Speaker 4: server use case was like edit later. Right, we've come
Speaker 4: out too, and compared to docul there's also a different philosophy.
Speaker 4: It's not like PAS. It's more like really just the
Speaker 4: deploy tool. But if I'm deploying my own application that
Speaker 4: I also develop, I think come out it's best to
Speaker 4: that to that use case. You know, maybe if you
Speaker 4: want to deploy some public application, maybe it's easier to
Speaker 4: install something like qulify or some other tools that can
Speaker 4: one click install them. But I think if you are
Speaker 4: the developer of the application, that really feel fits the
Speaker 4: films of the best, and for me personally, I really switched.
Speaker 1: Yeah to add on and I'm saying there's a there's
Speaker 1: a pr open right now to add a cloud native
Speaker 1: build text to come on, which would be interesting where
Speaker 1: you can basically build the app based off of other
Speaker 1: ones pretty easily.
Speaker 4: Yeah, So basically that's that's the single I would say
Speaker 4: advantage of docu today that it can be a little
Speaker 4: bit more magical. Somehow will build it for you and
Speaker 4: you don't have to write docer file. But lucky for us,
Speaker 4: Rails actually counts of docer file, so there's no extra work.
Speaker 4: It's not true for every every framework, but of course,
Speaker 4: if you are adopting doctor, I still recommend looking into
Speaker 4: how to build doc per file, how to optimize it.
Speaker 4: For example, before I was trying to squeeze the Stoker
Speaker 4: file for my reels applications, you know, I was removing
Speaker 4: all the all the files I don't need them to
Speaker 4: to have small footprint since you have to do the
Speaker 4: image and pull and push.
Speaker 1: So so yeah, so what is like kind of like
Speaker 1: the full process, Like let's say we do like a
Speaker 1: real's new app and we wanted to like deploy it
Speaker 1: with comal to like some Lino or something right or
Speaker 1: digital droplet, Like what what is the steps of the
Speaker 1: process there, like.
Speaker 2: To just like reels new.
Speaker 4: Yeah, you know, so let's say you do you did
Speaker 4: reels new. You have your doctor file. So that's one
Speaker 4: that's one perrequisite you have to have for the dooker
Speaker 4: file because maybe you're not rails. So let's just mention
Speaker 4: that you do need your server to run on board eighty.
Speaker 4: You can change it, but it's like default. If you
Speaker 4: want to simply work, that's the that's the main thing
Speaker 4: for the doctor file. Then you will need a doctor registry,
Speaker 4: so make an account a doctor hub, or maybe your
Speaker 4: provider has its own register that you can use. And
Speaker 4: you need to create like they call it cose. It's
Speaker 4: still registered passport, but you should create a token and
Speaker 4: note it down. And then you will need to create
Speaker 4: some virtual machine. It can be hadsner, it can be
Speaker 4: Digital Ocean, any cloud provider like that would work, and
Speaker 4: for that you will need to create as a SAGE
Speaker 4: key pairs, so you will create three pair. That means
Speaker 4: you have two keys, one private and one one public.
Speaker 4: Right to the private obviously you have to protect like
Speaker 4: the regiously password. And during the creation of the virtual machine,
Speaker 4: when you go like create, you choose some resources you
Speaker 4: know how big the VM should be and so on,
Speaker 4: and then I will ask you to copy your key there.
Speaker 4: So that's how they will provision uh, the VM for
Speaker 4: you and you should you should disable the password password
Speaker 4: logging value are there just for security, and so that's
Speaker 4: the that's that's what you need to That's what you
Speaker 4: need to have, you know, at the at the minimum,
Speaker 4: at at dominimum like the basic ones. Now maybe you
Speaker 4: also want to deploy to a domain name, so then
Speaker 4: obviously you have to purchase a domain name and you
Speaker 4: will need a DSM record at the very least type
Speaker 4: A to point your domain to the IP address, to
Speaker 4: the public IP address you will get for the machine
Speaker 4: you just provisioned. And if you have that, you can
Speaker 4: basically start with come out. We've come out in it.
Speaker 4: There's some basic basic configuration file. There are comments in line,
Speaker 4: so even when you never saw it, you can usually
Speaker 4: I guess a little bit what you will have to
Speaker 4: put there, So you will name your application, come out
Speaker 4: close it service. Yeah, I would also say be careful
Speaker 4: of the name because when you are doing the dooker
Speaker 4: a local private networking, it's also like kind of a
Speaker 4: name that you are using, so you cannot like put
Speaker 4: any characters you want there, you know, just stick to
Speaker 4: normal letters and lashes, and then you are fine, so
Speaker 4: so you are not surprised later that it doesn't it
Speaker 4: doesn't work. Then you specify the image which is your container.
Speaker 4: Registries use their name like slash the application name basically,
Speaker 4: and then you can put the IP address among servers.
Speaker 4: When you do that, you're configuring your application server by
Speaker 4: default the role called web and you can return just
Speaker 4: after this one how how came I splits the application
Speaker 4: server roles and accessories. But for now, if you just
Speaker 4: put there the IP address, that's enough, and then you
Speaker 4: will configure proxy. You will say okay, I want as
Speaker 4: a cell and you will put their holds which is
Speaker 4: your domain name or it can be also some domain.
Speaker 4: It can be even more hosts if you want so,
Speaker 4: very very flexible. This is very nice. Then you finish
Speaker 4: up with the registry and then there's a build a
Speaker 4: configuration but by default I think there's some reasonable value
Speaker 4: and and once you have all this then you only
Speaker 4: need to provide the environment, which is the secret spee.
Speaker 4: We talk about like IMO registry Passford, but it can
Speaker 4: be many more secrets the application have obviously, so you
Speaker 4: you list them in two basically want some environment variables
Speaker 4: you can list directly, but the secret once you actually
Speaker 4: just just put under like nd secret in the AMMO
Speaker 4: in the m file and then you only list them,
Speaker 4: but they leave somewhere else when you did the come
Speaker 4: out in it from before, come also created dot come
Speaker 4: out slash secrets file. That's where the secrets are. And
Speaker 4: of course then you can also call passform managers and
Speaker 4: so on. But at the very basic one you would
Speaker 4: just put the secrets there. You will not check it out,
Speaker 4: check it in the source control and then your configuration
Speaker 4: is done. You run come out set up and come
Speaker 4: all does everything for you. It will connect to the server,
Speaker 4: it will install do occur, it will install the come
Speaker 4: out proxy, and then it will put your application. So
Speaker 4: that's the most minimalistic way off the playing with Comal.
Speaker 2: Gotcha.
Speaker 1: So I'm mugging through the commands like as you're reading
Speaker 1: through that. Ah, and just so like we can most
Speaker 1: people know Horoku right like Heroku new and then deploy
Speaker 1: uh you know yeah, get pushed for Roku.
Speaker 2: Uh.
Speaker 1: And it seems like there's really like the three uh
Speaker 1: you know kmal commands that really run through that well
Speaker 1: everything you just said right, which is pretty wild, or.
Speaker 2: We have like come all in.
Speaker 1: It creates all the configuration files.
Speaker 2: Uh, comeal can fig like uh you know, starts to create.
Speaker 1: Your initial configuration file to add all the stuff to uh,
Speaker 1: and then you have KMAL deployed that just like push
Speaker 1: that up and proxy to the new version right of
Speaker 1: the app.
Speaker 4: Yeah. Yeah, basically as you say, I mean, the comal
Speaker 4: confix is already created. If come out in it and
Speaker 4: come out CONFIXP rechecks the configuration, it's good. That's actually good.
Speaker 4: Good one to run before the deployee.
Speaker 2: Yeah, that's awesome.
Speaker 4: I mean.
Speaker 1: That's uh, that's where we want to head right, Like
Speaker 1: it's like it's pretty close. I mean I guess like
Speaker 1: uh yeah, I mean so many like so many hosting
Speaker 1: providers now have that like one clip process to just
Speaker 1: get your VM up that it almost doesn't even make
Speaker 1: sense to abstract away that process, right to make it
Speaker 1: easier because they already provide that for the most part.
Speaker 2: But this is really cool.
Speaker 1: So I'm trying to think, like, uh, we walked through
Speaker 1: a very simple like example, right, and I imagine like
Speaker 1: with all of the push to solid q and solid
Speaker 1: x y z, like this is all running on a
Speaker 1: single machine.
Speaker 2: H how does all of that work?
Speaker 1: Like is it by default running the database on the
Speaker 1: same web server.
Speaker 4: Yeah, so that's a that's a good good question for
Speaker 4: for talking a little bit about how Comma actually splits
Speaker 4: your application and what what it actually does for you.
Speaker 4: Because this is simple example. You have one VM, one
Speaker 4: one container, right, but your application probably does a little
Speaker 4: bit more. It has it has to run jobs or
Speaker 4: some kind of other scheduling, or maybe are running an
Speaker 4: API server or some marketing website, and then all those
Speaker 4: needs databases. So at the high level, comme al splits
Speaker 4: this into servers and accessories. So servers are your application servers.
Speaker 4: Those all run your application image, so you cannot build
Speaker 4: like from multiple images. It has to be one image.
Speaker 4: There's just different command that it's been drun, but it
Speaker 4: comes from the application. Of course, you can package whatever
Speaker 4: you want in the container and you for example, can
Speaker 4: have application role that runs a jungle application next to it,
Speaker 4: you know, but you have to put it to the
Speaker 4: image because that's kind of a constraint that came as
Speaker 4: puts a new.
Speaker 1: UH.
Speaker 4: And with these server roles, it's important to say that
Speaker 4: there's a primary role. By default it's called web, but
Speaker 4: you can name it. And the primary role assumption is
Speaker 4: that this is your main application server, that's your rails
Speaker 4: s basically, or you like your Puma starting up. And
Speaker 4: why is it important because it plays in a role
Speaker 4: how come out actually does deploy on multiple servers and
Speaker 4: also on each particular server because when it puts your application,
Speaker 4: it usually puts your accessories, which are the databases all
Speaker 4: these low running services that are not necessarily I mean,
Speaker 4: they're connected with your applications, but it's something else. You know,
Speaker 4: they're not part of the Camel deployed process. Person they
Speaker 4: should already be running and you are simply taking use
Speaker 4: of it. But the primary is important because come al
Speaker 4: change a little bit regarding health checks and how it
Speaker 4: ensures that actually the container is healthy, it can serve
Speaker 4: traffic or can run. Before with traffic, we had something
Speaker 4: like courtfile. I will not really go into it because
Speaker 4: it's already kind of obsolete, but will I will say
Speaker 4: that the new way, there's something called the barrier. Maybe
Speaker 4: you won't find this name in the dogs, but you
Speaker 4: might find it in the code or somewhere in the issues.
Speaker 4: That's how common maintenance call it. And the barrier means
Speaker 4: that TAMEL will wait first for your that container to
Speaker 4: boot up successfully, the new one, for example, for the
Speaker 4: new version, and once it's healthy, then it assumes it
Speaker 4: can boot everything else. So all other roles, whether it's
Speaker 4: jobs or marketing sites or whatever you put there, will
Speaker 4: also start start without any further health check because the
Speaker 4: only comal proxy checks is for this primary role. So
Speaker 4: that's very important to realize. For example, you might be
Speaker 4: deploying front and I can't you know, split and I've
Speaker 4: come out. You can have from an application as one
Speaker 4: application and back as one application, but if you are
Speaker 4: putting it together and you are simply splitting in two roles,
Speaker 4: then one of them has to be the primary that
Speaker 4: come out will wait on and then it will also
Speaker 4: with the others, So that's like one important, one important thing.
Speaker 4: You can still have health check also for other containers,
Speaker 4: but then it's just the regular doctor health checks that
Speaker 4: you can add there, but nothing to do with the
Speaker 4: come out proxy process of booting.
Speaker 3: Which doctor registry would you personally recommend people use?
Speaker 4: I think so I personally use the carer ub right now.
Speaker 4: I want to support them because I know they had
Speaker 4: hard time as a company to actually excelving money out
Speaker 4: of doccer, and it's great that docer is free and everything,
Speaker 4: you know, but to support them, I use them currently.
Speaker 4: Maybe the smart answer is use the registry with your
Speaker 4: provider because it might be faster for you, you know,
Speaker 4: might be even cheaper, because I think they're increasing crisis
Speaker 4: right now, the doer hub. But I like the idea
Speaker 4: of supporting them in some way, So right now I'm
Speaker 4: using the registry.
Speaker 3: Cool And so the thing with there's more of a
Speaker 3: broader question around self hosting as opposed to using a pass.
Speaker 3: But do things that kind of scare me about self hosting,
Speaker 3: which is why I haven't actually the planting app by
Speaker 3: myself yet. I use render dot com personally. The two
Speaker 3: things that kind of scare me one is data based backups.
Speaker 3: For like, I use postcrafts personally, but I probably use
Speaker 3: equel Light for the next project, which would make life
Speaker 3: a bit easier in that regard. But database backups and
Speaker 3: OS upgrades. So like for someone who's only ever used
Speaker 3: like Herokua and then never had to worry about this
Speaker 3: kind of stuff, what would you tell them?
Speaker 4: Well, so you mentioned backups first, right, So in the
Speaker 4: Doker wave of doing backups is likely to simply run
Speaker 4: a Docker container that does backups.
Speaker 2: Right.
Speaker 4: That's that's doc y because you have to run everything
Speaker 4: in You can still do manual backups as before. I
Speaker 4: actually mentioned it in Camal handbooks how to how to
Speaker 4: do it. So you can still do manual backup. You
Speaker 4: can call you know, the the command is a bit
Speaker 4: larger because you have to use the There's actually a
Speaker 4: good point that comes to edit aliases. So you can
Speaker 4: prepare these commands and then have like nice come all
Speaker 4: back up and it will do back up right. So
Speaker 4: in a way it works the same as normal celf hosting,
Speaker 4: but it's definitely more work than just using manage database.
Speaker 4: And I would say it might be good for people
Speaker 4: to first just move with their server load like application
Speaker 4: servers and weight with the database just used to manage
Speaker 4: the database. There's nothing wrong with that. In fact, I
Speaker 4: think most people will run it like that, will take
Speaker 4: advantage of the manage database because it's safety a lot
Speaker 4: of hustle, which is true, but yeah, if you want
Speaker 4: to do yourself, you would run a container there. Then
Speaker 4: you can upload it for example every day to as
Speaker 4: free or something like that, and also have a way
Speaker 4: to pull it back if something happens. I also recommend
Speaker 4: to always turn on the automatic VM backups, which means
Speaker 4: the world VM is back up like every day on
Speaker 4: your cludusting provider. This is especially cool for like this
Speaker 4: project for example I deploy. You know, they are not
Speaker 4: big yet, they are one perserver, so I know I
Speaker 4: have snapshots every day with database but also everything else
Speaker 4: so I can just with one click to return there
Speaker 4: and continue, which is really really good. But you know,
Speaker 4: as it is with backups, it's good to always have
Speaker 4: like two different the cups maybe just to be sure.
Speaker 4: So I think that extra extra assurance can be this
Speaker 4: virtual machine back cups as a whole. Yeah, and actually
Speaker 4: with the system updates, I think it's kind of similar
Speaker 4: because if you have backup of the VM and you
Speaker 4: can really turn and return to the to the to
Speaker 4: the process later and if we've come out, if you
Speaker 4: have more hosts, you can simply uh put put the
Speaker 4: host that you're upgrading like kind of offline, you know,
Speaker 4: upgrade the system there and then you put it back
Speaker 4: to the pool of servers. That's ideal if you if
Speaker 4: you have more service and you can do it. That's
Speaker 4: that's like safe way to to to run.
Speaker 1: It does the does the current come out proxy handle
Speaker 1: like load balancing to do like slow rollouts of versions
Speaker 1: of the app.
Speaker 4: Or yeah, yeah it will it you. It does so
Speaker 4: called blue green deploy, So on every host it will
Speaker 4: put the new application you're running also the old one.
Speaker 4: Then after the health check it's switch. But then also
Speaker 4: it like goes and runs it across all hosts. Right,
Speaker 4: so yeah, there's some sittings, some little settings around that.
Speaker 4: Oh and it'll do the role out for you.
Speaker 2: Yeah, that's really cool.
Speaker 1: So I I'd love to shift gears a little bit
Speaker 1: into this whole like camal accessory stuff, because this is
Speaker 1: just something I wasn't immediately obvious, like how it all
Speaker 1: works and when's the best use case, right, where when's
Speaker 1: not a good thing to use as an accessory? Like
Speaker 1: what is an accessory?
Speaker 3: Right?
Speaker 2: Uh?
Speaker 1: Do you want to just give us like a high
Speaker 1: level like what the Kamal accessories are and like one
Speaker 1: example of like the most common one that you would
Speaker 1: add to a new app.
Speaker 4: Yeah. So basically accessories are come all way of running
Speaker 4: like some kind of permanent services you know that are
Speaker 4: not part of that deployal life cycle is simply run
Speaker 4: next to it. Whether that's relational database is key value stores,
Speaker 4: search engines, maybe headless browsers, you know, anything else that
Speaker 4: you just run as a service, basically the service your
Speaker 4: application is using. Most people will simply use a database
Speaker 4: as accessory or first accessory, and then you can run
Speaker 4: accessories on the same host or different holes. Basically that's
Speaker 4: what I really like Comalt. You simply put the IP
Speaker 4: there IP address and it feel the point that host.
Speaker 4: You know, whether whether that does an application, role or accessory,
Speaker 4: it just puts it there where you want it if
Speaker 4: you if you want to collocate it with the roles,
Speaker 4: you can also just say okay, just put it where
Speaker 4: the role web is and then it will auto particularly
Speaker 4: put the application next to I mean your database next
Speaker 4: to your application on that server. So you don't even
Speaker 4: have to specify the IP again for example, but in
Speaker 4: principle you can really spin it up anywhere anywhere.
Speaker 2: You won't, that's neat.
Speaker 1: So like let's say a more maybe more advanced when
Speaker 1: would be something like sidekick or like a background processor,
Speaker 1: Like how do the deployees then work? Like as you
Speaker 1: deploy a new version and it needs to like do
Speaker 1: like a rolling restart to wait for you know whatever
Speaker 1: jobs to finish before it it cycles over to the
Speaker 1: new version for new jobs.
Speaker 2: What's that kind of process?
Speaker 4: So with Sidekick, it's we are still talking about application role.
Speaker 4: You would call it like jobs for example, right, and
Speaker 4: as I said before, or it's not a primary role.
Speaker 4: So the health check there is not really done. Waits
Speaker 4: for the web container to boot and once at least
Speaker 4: one of them boots, so it doesn't it can be
Speaker 4: on different hosts, you know, like once it's successfully boots,
Speaker 4: come al said, okay, I know the application it is
Speaker 4: probably built. Well, that's the assumption. Then it will simply
Speaker 4: start to boot process for also the other roles. So
Speaker 4: for roles that are not web based, there's this assumption
Speaker 4: that you can simply decommission them and you know, start
Speaker 4: them again. If you have more web roles, you can
Speaker 4: you can also say that, okay, run the proxy come
Speaker 4: out proxy with this role, and then the request will
Speaker 4: be still train, so come out will still wait for
Speaker 4: the rectuesce to finish before it will be switching, you know.
Speaker 4: But that's really just the roles that are what we
Speaker 4: could call proxy rolls, roles that use proxy, but the
Speaker 4: other ones they are not really there's not really big
Speaker 4: assumption of like come on is the tool that doesn't
Speaker 4: know that you are deploying sidekick or that you are
Speaker 4: deploying POSTGA sequel accessory. It doesn't know, you know. That's
Speaker 4: why there's also not like some kind of plugging to
Speaker 4: run post gasquel or my sequel. It's it's the configuration
Speaker 4: you have to do that. That's that's the simplicity, but
Speaker 4: maybe also annoyance for some people that come on just
Speaker 4: does what you tell you to do.
Speaker 1: Gotcha, So you it's just the interface you have to
Speaker 1: like kind of figure out all the implementation details of it.
Speaker 2: How are you using it?
Speaker 4: Yeah, in the simplest way, it's really just doctor containers
Speaker 4: with doctor run and sometimes they are health check involves,
Speaker 4: you know, and it's important to learn how the LEF
Speaker 4: cycle goes like that. Okay, accessories are boot first, then
Speaker 4: the servers are booted first, the primary role than the others.
Speaker 4: And then you realize that then you can think about
Speaker 4: how to how to write a configuration you need.
Speaker 1: So what what are the latest releases in a version
Speaker 1: two that that has gotten you pretty excited about?
Speaker 4: Yeah, so I think come out to come out to
Speaker 4: is now probably interesting even to people that very interesting
Speaker 4: in come on one. You know, for one, the pointing
Speaker 4: to a single server is so much easier and straightforward.
Speaker 4: There are ways how to do it if you come
Speaker 4: out one, but you have to configure traffic and it
Speaker 4: was a bit annoying. And now it's all seamless in
Speaker 4: the conflict were just right which hosts? So true? And
Speaker 4: there you have it. It's like number one thing for
Speaker 4: come out too that it out of provisions or ascial
Speaker 4: certificates with lets encrypt, you don't have to do anything.
Speaker 4: It's just in the configuration. But there is one pevid
Speaker 4: I would just say with that it does not apply
Speaker 4: for multi host deployment because again COMMA is so simple.
Speaker 4: There is no centralized really way of sharing the the
Speaker 4: issue certificates. For example, you know, the different hosts doesn't
Speaker 4: know about each other. So if you would be issuing
Speaker 4: certificates again on every host, then maybe you run out
Speaker 4: of the attempts. Lets encrypt or something like that. But
Speaker 4: for single service it's like big leap forward, I would say.
Speaker 4: But in general, the depots get faster, you know, because
Speaker 4: of the process I described. So there's maybe a little
Speaker 4: bit less health checks done because there's just like one
Speaker 4: for the primary roles and then they are rolling. You
Speaker 4: are going for it, but that makes it really faster. Also,
Speaker 4: ditching traffic has one nice side effect that the server
Speaker 4: CPU utilization went down because that was one thing that
Speaker 4: was constantly pulling for like state of docor containers right
Speaker 4: because the configuration doesn't live on the traffic side but
Speaker 4: on the container side, so it's constantly palling. So if
Speaker 4: you would look, you would have some CP utilization all
Speaker 4: the time, and that that's not the case with the
Speaker 4: new newcome of proxy. You know, the proxy is pretty
Speaker 4: like simple that don't do too much the road to host.
Speaker 4: You can register a service, it takes care of draining
Speaker 4: the request when it's switching over, you know, and there
Speaker 4: are there are not many features of like what proxy
Speaker 4: could have like heady or engine X. You know, either
Speaker 4: some basic breakfast response buffering or handles like maximum reakfast
Speaker 4: sizes and proxy headers. But it doesn't even do anything
Speaker 4: with let's say your static assets, right for that we
Speaker 4: have truster, so they didn't really copy for example, this
Speaker 4: functionality too to come out proxy. It's it's still simple.
Speaker 4: I think simple. It is good. Some people mind find
Speaker 4: it limiting. Let's see what we'll see in the future.
Speaker 4: Because I would say the development of commons since I
Speaker 4: started to look into it, and then even since I
Speaker 4: started to rank Kamel Handbook was really really fast, right,
Speaker 4: I did already like to update like basically two editions,
Speaker 4: the first one with a big update for Kamal one seven.
Speaker 4: So yeah, it's faster, it's much easier to use, I
Speaker 4: would say, and things are things are going well?
Speaker 2: Yeah, you did.
Speaker 1: You bring up at something that I was trying to
Speaker 1: work through how you were doing Kamal. I guess like
Speaker 1: let's say, like you know, you want to like configure
Speaker 1: tune some like engine X caching or proxy specific in
Speaker 1: Engine X or some other system level configuration.
Speaker 2: Is that all handled like in whatever.
Speaker 1: Server that you would configure with kamal Like it's it's
Speaker 1: a step away from that aspect, and maybe how does
Speaker 1: it like can it work with it to auto generate
Speaker 1: that kind of stuff?
Speaker 4: So come out work with some assumption. As I said,
Speaker 4: it doesn't provision load balancer in front of your service
Speaker 4: right and similarly it doesn't really handle some serving of
Speaker 4: static assets. The assumption is that you either use something
Speaker 4: like suster inside your image for example, so you have
Speaker 4: one more little proxy there. You could also have, for example,
Speaker 4: your own engines load balancer that also does this caching,
Speaker 4: but you will have to deploy yourself. That's the thing.
Speaker 4: Come Out won't do it for you, or there's this
Speaker 4: assumption that most people maybe it will just approximate caut
Speaker 4: flare and do the caching there, you know, so there's
Speaker 4: some limitation to it for most people. I think there's
Speaker 4: about how to do it. It's just like it's not handled
Speaker 4: directly and come out right now, gotcha?
Speaker 2: Yeah that makes sense? I mean still early days, Yeah yeah,
Speaker 2: I think so. Well cool, So is.
Speaker 1: There any like dashboard or monitoring or something like that
Speaker 1: that's available to like kind of see things. I see
Speaker 1: there's like a you know, come out details where you
Speaker 1: can kind of peek at the apps and services running.
Speaker 1: Is there any like ux stuff out there that people
Speaker 1: are using to visualize or gather metrics or things like that.
Speaker 4: Well, I believe that for the something that they use
Speaker 4: something like from elasticks such tackle like draft funnel or
Speaker 4: something like that. For my thing server, the post for example,
Speaker 4: I take advantage of digit ocean agent because you can
Speaker 4: just clearly want it and then you have a very
Speaker 4: beautiful dashboard do you get for free? Basically you can
Speaker 4: even set up alerts. So for very small hosting for example,
Speaker 4: what I do, I think that works very nicely. I
Speaker 4: know that somebody is making something but it was not announced,
Speaker 4: so maybe there will be some come out specific tooling.
Speaker 4: But right now if we don't have it, so you
Speaker 4: have to do the usual way if you want host monitoring,
Speaker 4: install the data agents you know, or doing grafana. It's
Speaker 4: definitely something that's not really solved in the I would
Speaker 4: say easy way to just to just like enable and
Speaker 4: run with. But I think that would be that would
Speaker 4: be some nice, nice project for somebody.
Speaker 1: For sure, Hey, you definitely got me wanted to deploy
Speaker 1: a couple of apps just for fun. So what are
Speaker 1: what are maybe some uh, some things that you're looking
Speaker 1: forward to, uh or or maybe hopeful that they get added? Uh,
Speaker 1: I mean outside of like the two items that we
Speaker 1: just talked about, uh with the uh you know, maybe
Speaker 1: making proxying a little easier or the metrics aspects, like
Speaker 1: is there anything missing from the process that you, like,
Speaker 1: hope kids added.
Speaker 4: For me, I was kind of already happy with come
Speaker 4: Out one. I mean, now that I see come Out too,
Speaker 4: I'm even more happy. But I kind of already made
Speaker 4: it work. You know, it did it did the job.
Speaker 4: And UH. For example, when you when we were comparing
Speaker 4: with Copristano in the beginning, you know, it doesn't also
Speaker 4: have some kind of tastboard for you, you know, because
Speaker 4: the tool is limited and some in some way it's
Speaker 4: I think it's good that it has some kind of
Speaker 4: limits or some kind of philosophy what it wants to be.
Speaker 4: And then there can be a sister project that provides
Speaker 4: the extra extra features. So I have to talk about
Speaker 4: of course, like this kind of tashboard or maybe even
Speaker 4: nicer backups. All these things would be nice or maybe provisioning. Actually,
Speaker 4: it was my idea that I could develop this project
Speaker 4: that it would be like zero continct provisioning for came out.
Speaker 4: That would be the the headline.
Speaker 3: You know.
Speaker 4: I don't know if I will get to it, but
Speaker 4: it's idea I have, so personally, I would see the
Speaker 4: sister projects. I also think that David suggested that, yeah, come,
Speaker 4: I will probably stay focused, and I think I think
Speaker 4: it's a good thing because when I look at DOCU,
Speaker 4: for example, it was like the single server pass it
Speaker 4: was very well for that. But now I checked the
Speaker 4: dogs recently and I see that there's also a way
Speaker 4: how to spin up a K three as scheduler, you know,
Speaker 4: and then you are like kind of diluting the tool
Speaker 4: to be everything for everybody, and that's also in the
Speaker 4: end a negative for me. So so I'm happy if
Speaker 4: it stays simple, you know, improves in little ways, and
Speaker 4: I'm happy.
Speaker 3: Man.
Speaker 2: Yeah, yeah, I hear.
Speaker 1: It's gonna be hard to shake like the existing like
Speaker 1: larger infrastructure stuff. Focusing on like the very specific simple
Speaker 1: utility of Docker maintenance and services definitely is appealing. Like
Speaker 1: going off of that, then, is there anything like you
Speaker 1: would like to see removed from the overall like architecture
Speaker 1: process that maybe is just causing more headache and confusion
Speaker 1: than is adding that.
Speaker 4: Not really, I have to say that the change with
Speaker 4: secrets for me was a little bit maybe a downside
Speaker 4: in my specific way, because what I was doing, since
Speaker 4: I knew how COMA really worked, I kept on ci
Speaker 4: maybe just like two ends and I could like just
Speaker 4: do deployed and not really put my secrets to get up,
Speaker 4: you know, which I was very happy about. And now
Speaker 4: you either have to put it there or use a
Speaker 4: secret manager, which of course if you're a company, you
Speaker 4: should be using the secretly management. But for me, I
Speaker 4: was like, I have these little projects and I was
Speaker 4: happy that I could do it this way, and now
Speaker 4: I can't. But in a way, I still think it's
Speaker 4: probably better. It's just like that in my specific case,
Speaker 4: I was happy to also deploy without the change to
Speaker 4: environment because before it was two steps come on, be
Speaker 4: five that push the ends and then come out deployed.
Speaker 4: But now it's all together, so you do need all
Speaker 4: ends because if you don't have them then it will fail.
Speaker 4: So that's maybe like one thing in my specific case,
Speaker 4: but I think generally it's it's still a step forward
Speaker 4: for come out, and you know, I wish people would
Speaker 4: maybe replace some Kuberneties clusters, but to be honest, it's
Speaker 4: probably not what will necessarily happen. I think the most
Speaker 4: value from come Out can get people that are now
Speaker 4: deploying with just local composed, because local composed it's originally
Speaker 4: the tool you have to put all the containers down
Speaker 4: and up. And I know there are some third party
Speaker 4: proxies that tries to solve this step plus deployed, but
Speaker 4: Kamla is so much nicer in my opinion, you know,
Speaker 4: and whatever criticism we would have for come Out, it
Speaker 4: would probably apply there as well. So I think it's
Speaker 4: just like plus, it's just a better tool. But yeah,
Speaker 4: we'll we'll see. Yeah, I think we've.
Speaker 1: We've covered quite a lot of topics here. Uh we're
Speaker 1: kind of coming to you know time here. But is
Speaker 1: there any other things you wanted to cover before we
Speaker 1: move into our pick section of the show?
Speaker 4: No, not to see the cover, but if I can,
Speaker 4: I would just like want to thank you David for
Speaker 4: even starting come Out and uh also thank Donald mcgreen
Speaker 4: who uh done a lot of work on come Out
Speaker 4: too and also wrote a forward, so thank you, I
Speaker 4: don't know. And also to Kevin McConnell because he was
Speaker 4: the main guy behind Come Up Proxy. She's very important
Speaker 4: aspect of Come Out too. And then also a final
Speaker 4: shout out to Rosa because she kind of sent doing
Speaker 4: all the information that I am writing the book and
Speaker 4: then he wrote me in the email and that's how
Speaker 4: it all happened. So yeah, thank you, Thank you guys
Speaker 4: and everybody else that you know works on Come Out.
Speaker 1: I would pay to think, Yeah, seriously, thank you. All
Speaker 1: this stuff is definitely going to make it easier to
Speaker 1: work with Doccer at least. Yeah, it should be should
Speaker 1: help with deployees in general. It's definitely helpful to have
Speaker 1: a definitive rails process for deployments, which was missing for.
Speaker 2: Quite a long time.
Speaker 1: So it's exciting to see, well, great, we're going to
Speaker 1: move into picks. It's a second of the show where
Speaker 1: we just find some things that we are excited about
Speaker 1: in life or code or whatever it may be that
Speaker 1: I pique your interest. Uh and uh I can I
Speaker 1: can kick us off? I have this particle, Uh, I
Speaker 1: guess infatuation. It's a little hardware devices, a little micro controllers,
Speaker 1: they have this little development board called the Moon that
Speaker 1: lets you uh do things with cellular and uh mesh
Speaker 1: it with like you know, Wi Fi Uh so you
Speaker 1: can get like kind of like a blended solution on
Speaker 1: a micro controller.
Speaker 2: Uh. It's a lot of fun. I'm messing with it,
Speaker 2: uh just for fun.
Speaker 1: And uh I've been playing with open ayes uh new
Speaker 1: pipeline for fine tuning stuff.
Speaker 2: They call it distillation.
Speaker 4: Uh.
Speaker 1: It's a lot of fun where you could just uh
Speaker 1: send all of your AI and responses to Opening Eye
Speaker 1: and they'll automatically like fine tune a new model for
Speaker 1: you based on the outputs and inputs that you give it, which.
Speaker 2: Is just wild. So I'm having a lot of fun
Speaker 2: just messing around and seeing what I can get it
Speaker 2: to do.
Speaker 3: Nice.
Speaker 4: Yeah, I definitely.
Speaker 3: Yes, I've gone ah.
Speaker 4: Yeah. I just wanted to say, like also like this
Speaker 4: just little improvements in life that you can do. For example,
Speaker 4: on my travels this year, I switched to finally using
Speaker 4: SIM so I didn't have to like, you know, buy
Speaker 4: physical same change on the airport when I was like
Speaker 4: sweaty and tired and everything, because I just like click
Speaker 4: in my phone and I had service and it's like
Speaker 4: these little things that like actually are really amazing that
Speaker 4: I love. But since my book is about also like
Speaker 4: kind of doing something independently, you know, like in the
Speaker 4: in the acting spirit, I want to do a recommendation
Speaker 4: for one show. It's called The Indie Life's by Dougobard.
Speaker 4: He was doing a startup, he kind of failed. He
Speaker 4: also got divorced, and now he's like starting this show
Speaker 4: Whey where he discusses with people also the not so
Speaker 4: glamorous side of this India acting entrepreneurship and stuff. It's
Speaker 4: a nice show. So I would recommend this to check
Speaker 4: out cool.
Speaker 3: Is there any ethan provider that that you recommend, because
Speaker 3: I'm traveling to New Zealand and a couple of three
Speaker 3: weeks and I was looking at ethents as well.
Speaker 4: It was just my first time. I picked one that
Speaker 4: something the countries. I go and that's it. But it's
Speaker 4: worth It's worth nice. It's probably a bit more expensive,
Speaker 4: but I mean I really appreciate the leveling up in
Speaker 4: the comfort of travel, So for.
Speaker 3: Me, yeah, sure, it's definitely worth the worth the price.
Speaker 3: Right my picks, I've got I've got a movie in
Speaker 3: a TV show, so I watched a movie last night
Speaker 3: called A Night on Earth by Jim Jarmusch. I think
Speaker 3: it's from ninety ninety one. Absolutely brilliant. If you like
Speaker 3: like character driven movies that don't have a lot of
Speaker 3: plot but a very colorful characters, this is the kind
Speaker 3: of movie for you. I think really enjoyed a guy
Speaker 3: I met at the hag Strub conference last week, I
Speaker 3: recommended this movie. That's why I watched it, And yeah,
Speaker 3: I'd recommend it to everyone else. And the season two
Speaker 3: of a show called Shrinking has just started on Apple TV.
Speaker 3: I love season one, and season two started off really
Speaker 3: strongly as well. I think four episodes are at It's
Speaker 3: starring Harrison Ford and Jason Siegel. From my is familiar
Speaker 3: with How I Met Your Mother, wo would know who
Speaker 3: he is and Dad Lasso fans will also be happy
Speaker 3: to hear that Brett Goldstein is now has joined the
Speaker 3: cast for season two. So if any of the names
Speaker 3: ring a bell might be sure what checking out? Because
Speaker 3: I'm a huge fan. Yeah, those those those are my
Speaker 3: two picks.
Speaker 1: A Yeah, I always love a good TV movie show Combo. Well, Joseph,
Speaker 1: it was it was really great having you on today.
Speaker 1: Thank you for sharing all of your you know, deep
Speaker 1: diving on Camal. And for those that haven't checked it
Speaker 1: out yet, check out all of Joseph's great books that
Speaker 1: he's putting together Kamal Handbook for sure.
Speaker 2: I'm gonna be diving into that myself.
Speaker 1: So I appreciate you taking the time today and honestly
Speaker 1: spending all that time putting putting this content together because
Speaker 1: it's it's much needed.
Speaker 4: Thank you, and thank you for having me on the
Speaker 4: on the show I enjoyed awesome.
Speaker 1: Well, we'll have to have you come on again when
Speaker 1: Comal three comes out and we can get you to
Speaker 1: tear apart all the all the.
Speaker 2: Great new features that are to come. I'm sure. Well
Speaker 2: that's it for day, folks. I'm Valentino. Thank you, Thank you, Joseph.
Speaker 2: Until next time,