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