Talks

Summarized using AI

Kamal 2.0: Deploy Web Apps Anywhere

Donal McBreen • September 26, 2024 • Toronto, Canada

In the video titled "Kamal 2.0: Deploy Web Apps Anywhere," Donal McBreen, a programmer from 37signals, discusses the features and functionalities of Kamal 2.0, an imperative deployment tool built for running applications with Docker. This presentation was given during the Rails World 2024 event, where McBreen outlines the evolution and improvements from the previous version, Kamal 1.0.

Key Points Discussed:
- Background of Kamal: 37signals transitioned from using AWS's managed Kubernetes service (EKS) to deploying applications on their own hardware. They realized Kubernetes added unnecessary complexity, while Docker offered a more straightforward option for container management.
- Kamal's Purpose: Kamal aims to be a “Capistrano for containers,” allowing developers to seamlessly deploy web applications using Docker. With Kamal, the deployments can be automated and made repeatable, thus simplifying the deployment process.
- Core Features of Kamal 2.0:

- Zero Downtime: Designed to ensure that deployment happens without service interruptions by managing container versions effectively.
- Imperative Tool: Unlike declarative tools, Kamal executes commands and waits for their completion, ensuring deployments are controlled and predictable.
- Requirements for Kamal: Users need an application configured to run with Docker, access to a Docker registry, and SSH access to deployment servers.
- Deployment Process Overview:

- Users set up Kamal, install the necessary configurations, build Docker images, and push them to the designated application host before launching the application containers.
- The deployment phase entails booting a proxy for traffic management, allowing for controlled routing to the new version of the application.
- Asset Bridging: A notable feature of Kamal 2.0 where it manages asset transitions between different application versions, ensuring that assets are accessible and avoiding 404 errors during deployment.
- Transition from Kamal 1.0 to 2.0: The presentation outlines upgrades such as a shift from using the traffic proxy to a custom-built proxy designed specifically for Kamal, which addresses issues inherent to the previous iteration regarding traffic management and deployment clarity.
- User Experience Improvements: Several refinements were made, including a more straightforward command structure for handling secrets and simplified configurations for deploying applications with SSL support.

Conclusions:
Kamal 2.0 significantly enhances the deployment experience for Ruby on Rails applications, streamlining the process from development to production. It intends to provide a seamless and efficient deployment workflow for developers looking to utilize Docker without the overhead of complex configurations. The tool is expected to promote rapid deployment of applications on various hosting environments.

Kamal 2.0: Deploy Web Apps Anywhere
Donal McBreen • September 26, 2024 • Toronto, Canada

Kamal is an imperative deployment tool from 37signals for running your apps with Docker. Donal McBreen, from the Security, Infrastructure and Performance team at 37signals will run through how it works, what they've learned from v1.0 and the changes they've made for v2.0 at his talk at #RailsWorld.

#Kamal2 #rails #rubyonrails #deployment #Rails8

Thank you Shopify for sponsoring the editing and post-production of these videos. Check out insights from the Engineering team at: https://shopify.engineering/

Stay tuned: all 2024 Rails World videos will be subtitled in Japanese and Brazilian Portuguese soon thanks to our sponsor Happy Scribe, a transcription service built on Rails. https://www.happyscribe.com/

Rails World 2024

00:00:10.000 okay hi everyone let's see there we go
00:00:14.480 okay um yes so uh let's go back one
00:00:18.720 right that's me Don MCB I'm a programmer
00:00:21.000 at uh 37 signals and so uh yeah Kamal 2
00:00:25.000 is the tool we're currently using to
00:00:27.080 deploy hay so I'm going to talk uh a
00:00:29.279 little bit just about Cal in general how
00:00:31.039 it works and then more specifically
00:00:33.399 about what we've added for Cal 2 so we
00:00:36.800 sort of had the history already so we'll
00:00:38.320 go through this I won't take too long
00:00:40.520 but where we were at the start was we
00:00:42.600 were running a bunch of applications in
00:00:44.640 AWS uh on their managed kubernetes
00:00:47.480 service eks and we wanted to bring them
00:00:49.960 inhouse and run them on our own Hardware
00:00:52.120 so we needed a way to run them so one
00:00:54.480 option would be to uh start using
00:00:56.399 kubernetes locally but we looked at that
00:00:59.320 and we didn't really fancy it we were
00:01:02.840 like that looks quite uh you know tricky
00:01:06.159 um we were looking at we already had
00:01:09.439 base camp our uh biggest application had
00:01:12.640 always run on our own hardware and we
00:01:15.119 were just using Capistrano to deploy it
00:01:17.720 and when we looked at what we were doing
00:01:19.360 in AWS it was like well we don't really
00:01:21.880 like this kubernetes part that looks a
00:01:23.560 bit tricky and we don't really need it
00:01:25.360 but this doer bit looks great because we
00:01:27.479 won't need to like artisanally manage
00:01:29.280 our servers anymore to make sure we can
00:01:31.720 you know compile the latest Ruby and
00:01:34.119 make sure all the gems install correctly
00:01:36.119 so we're like well we do like the uh
00:01:37.880 Docker part so uh what we decided we
00:01:41.159 needed was Capistrano for containers um
00:01:45.320 so if you H don't know what Capistrano
00:01:48.680 is so in the days before Capistrano uh
00:01:51.680 you would you know deploy your
00:01:53.399 applications by running some scripts
00:01:55.399 You' made up or sshing into a server and
00:01:57.560 just typing some random commands and
00:01:59.119 hope that it worked
00:02:00.560 and Capistrano which was uh originally
00:02:04.200 built by jamus bu who's actually talking
00:02:06.600 right now in the other room um was a way
00:02:10.119 to make this simpler so the idea was you
00:02:13.560 would SSH you'd have capistran would SSH
00:02:16.319 to your servers for you and have a bunch
00:02:18.480 of recipes that it would run that would
00:02:20.080 deploy your app and you'd have
00:02:21.160 repeatable buildt and that was what we
00:02:24.440 decided we needed so kamal's kind of a
00:02:26.000 modern take on Capistrano but decided to
00:02:28.280 run with Docker and it's a ruby gem
00:02:30.920 built on top of SSH kit so SSH kit is a
00:02:34.280 library extracted from Capistrano and
00:02:36.720 that helps you you know run uh commands
00:02:39.760 over SSH concurrently and wait for them
00:02:41.599 all to return and just makes that really
00:02:43.480 easy to do uh and then the idea is
00:02:46.000 you've just got some Linux servers
00:02:47.800 running Docker or about to run Docker
00:02:50.159 that you want to deploy
00:02:52.360 to okay so these were the three um kind
00:02:56.800 of big goals we had first was that it
00:02:58.760 would be Zero D time so if you do very
00:03:01.319 naive version of just running Docker
00:03:03.400 you're going to have your application
00:03:04.840 you'll Boot It Up sort of sit there on
00:03:06.959 Port 80 and then you've got a new
00:03:08.360 version of the application and what you
00:03:09.959 need to do so that it can sit on Port J
00:03:12.080 is take the first one down and bring the
00:03:13.400 other one up and you've got a big gap
00:03:14.799 there where you're going to be serving
00:03:16.319 error pages so we wanted to avoid that
00:03:19.920 the second thing was that it would be an
00:03:22.799 imperative tool and what this means is
00:03:26.200 that we're going to run a command and
00:03:28.799 then we're going to wait and when the
00:03:30.080 command is finished we're done there's
00:03:31.480 nothing else going on so something like
00:03:33.720 uh kubernetes is more declarative and I
00:03:35.760 think the difference between the two is
00:03:37.360 imperative means I insist and
00:03:39.840 declarative means I suggest so with this
00:03:43.280 we're saying I insist you deploy and you
00:03:46.040 tell me whether you've deployed or not
00:03:47.560 and once the command's over we're
00:03:49.480 done and then if we're going to wait for
00:03:51.959 you well to complete we need to be as
00:03:55.280 fast as possible so um we're going to be
00:03:58.519 deploying docker images so you know
00:04:01.040 you've got to build them and move them
00:04:02.599 around so if that takes a long time well
00:04:04.079 that's going to take a long time but we
00:04:05.319 wanted Cal to be as fast as possible and
00:04:08.560 avoid adding any extra overhead if
00:04:12.799 possible okay so um the prerequisites if
00:04:17.120 you want to run Cal on an app so you
00:04:19.359 need you'll need an app with a Docker
00:04:20.639 file so you can build your Docker image
00:04:22.479 now it doesn't have to be rails it can
00:04:23.680 be any kind of web app that uh you can
00:04:26.479 package up as a Docker image and uh as
00:04:30.800 David said earlier you do need a Docker
00:04:32.639 registry right now and we have some
00:04:34.080 ideas on how to get rid of that part
00:04:35.560 because it's really really annoying but
00:04:37.440 you have toiv that for now and finally
00:04:40.759 you need a bunch of servers that you
00:04:42.199 have SSH access
00:04:44.320 to okay so and then if we want to
00:04:47.240 install well with rails 8 it will come
00:04:49.720 installed already unless you add the
00:04:51.560 skip Comm command uh option to the
00:04:55.360 command uh otherwise if you want to try
00:04:57.600 and try it out on an existing
00:04:59.280 application you can install the gem or
00:05:01.320 you put it in your bundle uh so you do
00:05:04.199 that and then run Cala nit which will
00:05:07.039 create a bunch of files um so uh the
00:05:11.280 main one here being config deployed. AML
00:05:13.479 so uh we
00:05:14.720 saw that earlier but this is kind of the
00:05:18.360 minimal version you need so servers
00:05:20.440 you're deploying to details on your
00:05:22.319 registry and what architecture you want
00:05:24.840 to build
00:05:25.960 for okay so here's our really simple
00:05:29.720 looking infrastructure we've got a host
00:05:31.160 we're deploying from that could be your
00:05:32.639 laptop could be you know a special host
00:05:35.520 to use somewhere for deploying from and
00:05:37.800 a host we want to deploy to and we're
00:05:39.240 going to talk over SSH you might have
00:05:41.840 multiple hosts that's fine um it'll do
00:05:45.199 all that all the work to deploy in
00:05:46.960 parallel if that's the
00:05:48.440 case though H you will need your own
00:05:51.039 load balancer somewhere to uh balance
00:05:54.280 things out over those
00:05:56.680 hosts and we'll go through we'll just
00:05:59.880 use one host here so we've got our
00:06:01.360 deployment host we've got our
00:06:02.520 application
00:06:03.639 host and we've got our Docker registry
00:06:06.000 for now
00:06:07.319 anyway and what we do is we run Cal
00:06:10.800 setup and when you run this you're going
00:06:12.919 to it's going to spit out this kind of
00:06:14.680 output which is uh kind of the standard
00:06:17.479 SS SSH kit output and it's quite handy
00:06:21.120 because you can do a deployment and then
00:06:22.840 just inspect that and it will just tell
00:06:24.240 you here are the commands the Cal does
00:06:26.240 so if you're like what is it doing you
00:06:27.759 just run a deployment and then just go
00:06:29.639 and start digging those logs and you can
00:06:31.759 see exactly what's there it's just the
00:06:34.280 Heritage from Capistrano which is really
00:06:37.560 handy uh okay so when we run Cal setup
00:06:43.120 the first thing it's going to do is it's
00:06:44.520 going to check on the application host
00:06:46.880 as to whether docker's install if it's
00:06:48.400 not it'll try and install it if it can't
00:06:50.840 well you'll have to sort that out
00:06:51.960 yourself manually but otherwise we'll
00:06:54.840 get Docker installed on
00:06:57.120 there uh and then we'll do a Docker
00:06:59.199 build on our deployment host and that's
00:07:01.319 going to build uh our application image
00:07:04.000 on our host and we'll push it so do a
00:07:06.960 Docker
00:07:08.199 push and then we will SSH over to our
00:07:12.680 application host and do a Docker pull so
00:07:15.919 now we have our container sitting on our
00:07:18.840 application
00:07:20.120 host okay so the next part is the
00:07:22.280 deployment phase and we'll zoom into the
00:07:24.360 application host for that bit so we've
00:07:27.280 got our commands coming in over SSH from
00:07:30.360 our deployment
00:07:32.000 host and uh we've got Docker installed
00:07:34.800 here we've just copied our image on the
00:07:36.960 first thing we're going to do is boot a
00:07:38.280 proxy so this is in Cal 2 is going to be
00:07:41.879 an instance of Cal proxy which is the
00:07:44.599 new a proxy we built and my colleague
00:07:46.720 Kevin is giving a talk on that uh after
00:07:49.120 this so if you're interested in knowing
00:07:50.479 more uh come along to
00:07:52.680 that but how we use it is we then boot
00:07:55.919 up our uh application container and then
00:08:00.159 we tell the proxy send the traffic
00:08:01.960 through to that container so now we're
00:08:04.240 done we're Ser requests are coming in uh
00:08:07.520 the proxy forwarding them to our
00:08:10.960 application okay so the next phase is I
00:08:14.000 want to deploy a second version of
00:08:16.000 applications you've made your changes
00:08:17.599 you've committed them and you want to do
00:08:19.840 that so you're going to run Cal deploy
00:08:21.639 So Cal setup is kind of just the initial
00:08:24.759 setup and then a deployment and then
00:08:26.479 this one is just that sort of second
00:08:28.000 phase to the kind of deployment part
00:08:30.479 so to start with it's going to um do
00:08:35.399 that kind of dance of building the image
00:08:38.399 and pushing it and then pulling it so
00:08:40.479 we've now got uh the second version of
00:08:43.640 our application sitting on our
00:08:45.680 application host um and this is where
00:08:48.720 where we left things off after our last
00:08:50.519 deployment so we'll just uh boost up a
00:08:53.360 container running the second version of
00:08:55.640 the
00:08:56.640 application and then we'll tell Cal
00:08:58.920 proxy please send the traffic over there
00:09:02.120 and we're done so that's uh a very sort
00:09:06.040 of the the simple version of how it
00:09:08.880 works now there's more to the things
00:09:10.399 like um you know if you want to have if
00:09:12.880 you've got job servers where you don't
00:09:14.120 need a proxy it'll handle those and you
00:09:16.240 can configure all that
00:09:19.399 separately okay oh yeah and then we we
00:09:22.040 can now turn off the old container
00:09:24.399 because we're
00:09:26.279 done so one interesting part in this
00:09:30.279 that uh I thought it would be worth
00:09:32.160 discussing is uh what we call Asset
00:09:34.720 bridging so if you have the n n version
00:09:38.120 of the deployment kind of as I described
00:09:40.040 there you have a problem as the new
00:09:42.600 version is going out especially if
00:09:44.240 you're running on multiple application
00:09:45.600 hosts and they're all deploying at a
00:09:47.240 slightly different rate you've got your
00:09:48.839 new containers floating around you've
00:09:50.360 got your old containers floating around
00:09:52.800 um and you have uh yeah so say you've
00:09:56.720 got a build and you've
00:09:59.480 changed your CSS so now the fingerprint
00:10:01.480 on the file has changed and you've got
00:10:03.560 this new
00:10:04.760 asset that you want that sits on your
00:10:07.640 new containers and this old asset
00:10:09.240 sitting on your old containers but you
00:10:10.959 have no guarantee about which container
00:10:12.680 the requests are going to come to so
00:10:14.480 what are you going to get as you deploy
00:10:16.000 you're going to get four or fours you're
00:10:17.200 going to get a few random unstyled pages
00:10:19.959 and if people are watching carefully
00:10:21.200 they can tell when you're deploying
00:10:22.880 which is not what we want we want that
00:10:24.640 to be zero time downtime and
00:10:27.200 invisible Okay so
00:10:30.000 this is a common problem and like loads
00:10:32.360 of rails apps have this step beforehand
00:10:34.560 where you'll like take your assets and
00:10:36.600 copy them up to an S3 bucket or
00:10:38.240 something and like have some separate
00:10:40.120 asset host to make sure that they're
00:10:41.600 there but we wanted to make it so if
00:10:43.200 you're using Cal you just don't have to
00:10:44.680 worry about this so um if you go and uh
00:10:50.079 create a new rails H app and look in the
00:10:53.279 config there you'll find this line asset
00:10:55.279 path rails public assets so we're
00:10:57.880 telling Cal where in our Docker image it
00:11:00.920 can find the
00:11:02.639 assets and what we'll do with that
00:11:04.760 information is that we will um boot up
00:11:09.160 our application image but we're going to
00:11:11.720 change the entry point and just set it
00:11:13.079 to sleep so it just boots up and does
00:11:14.680 nothing and just sits there hanging
00:11:16.560 around waiting and then we copy the
00:11:18.360 assets out into a folder on the
00:11:20.760 application host so outside Docker in a
00:11:22.720 separate folder and now we've got those
00:11:24.560 assets we can stop uh stop our
00:11:28.000 container so got those assets and what
00:11:30.959 we're going to do is well the last time
00:11:33.360 we deployed we did the same thing so we
00:11:35.200 have the assets from the last deployer
00:11:36.519 lying around as well so we'll take the
00:11:39.320 new assets and the old assets copy them
00:11:41.800 into a combined asset folder and then
00:11:44.079 we've got a folder containing all the
00:11:46.120 assets um and uh when came up with this
00:11:51.040 idea I got this far and I was like now I
00:11:53.120 don't know what to do with them and
00:11:54.320 luckily uh Lu my colleague Jeremy had
00:11:57.600 the very what now seems very obvious
00:11:59.800 point of what you should do with them
00:12:01.519 which is just map that folder back over
00:12:03.800 rail's public assets when you actually
00:12:05.360 boot your container so when you boot up
00:12:07.760 the new um applica the new version of
00:12:11.160 your application rails public assets
00:12:13.360 contains the old assets and the new
00:12:15.079 assets so you don't care which container
00:12:17.160 it hits and you've got you've still got
00:12:18.880 the problem with your old containers but
00:12:22.560 you can fix that because you already had
00:12:24.079 a uh folder mapped in for those so
00:12:26.880 before you boot up this new one you copy
00:12:28.560 those new assets back into that folder
00:12:30.440 and is can also serve both versions of
00:12:32.480 your
00:12:34.480 assets so you get no 404s you don't need
00:12:38.240 to mess around with like trying to CD
00:12:40.120 see the CDN or hoping that like you'll
00:12:42.720 just get hits from your CDN uh I'm not
00:12:46.120 saying you don't need a CDN you might
00:12:47.399 need a CDN but you don't need it for
00:12:48.959 this uh and you don't need to like set
00:12:51.079 up these special asset hosts to deal
00:12:53.440 with this so H yeah that's us a
00:12:57.040 bridging okay so now uh just to go to
00:13:01.839 just to say yes it is releasing today no
00:13:04.880 it has not released yet not as Brave as
00:13:07.399 Rosa releasing the thing and then doing
00:13:09.360 a talk I decided it would be better to
00:13:10.920 do it the other way around so um the
00:13:14.600 main thing that means is the
00:13:15.519 documentation is not up to date so if
00:13:16.920 you've gone to look at the documentation
00:13:18.560 it's not got the information for the new
00:13:20.639 version but it will be there later today
00:13:22.920 okay so what's new well the biggest
00:13:25.920 thing is that we're changing the proxy
00:13:27.920 we're using so so we used in Cal 1 we
00:13:30.519 used to use uh traffic as this proxy
00:13:32.760 that we use to uh
00:13:35.040 switch uh between
00:13:37.600 containers um and so traffic is it's an
00:13:41.000 open source application proxy um and
00:13:44.760 it's designed to kind of configure
00:13:46.920 itself automatically and dynamically and
00:13:49.639 so what how we would use it is we would
00:13:53.160 uh it has a Docker provider and when you
00:13:56.639 boot up your container if you put some
00:13:59.120 labels on us it will notice those labels
00:14:00.880 and start sending traffic through to
00:14:02.360 your container based on the labels um so
00:14:05.320 that's what we were using
00:14:07.600 um but there was kind of problems with
00:14:11.600 this that it just became obvious more we
00:14:13.360 were trying to make all the like you
00:14:15.199 know get rid of all the little ede cases
00:14:17.199 and make sure that things deployment
00:14:18.600 went smoothly without dropping anything
00:14:20.519 and the main one is this there's this
00:14:21.759 kind of declarative imper of mismatch
00:14:24.040 with with Kamal we're you know we're
00:14:26.720 saying I want to call this command I
00:14:29.240 want this thing to happen we're you know
00:14:31.639 we're we're insisting we're not
00:14:33.199 suggesting but traffic only takes
00:14:35.160 suggestions so you have to like boot up
00:14:38.440 the container with the labels and then
00:14:40.959 you have to start polling and waiting
00:14:42.360 for it to notice the labels and then
00:14:43.800 suddenly it looks like okay it's picked
00:14:45.160 it up and actually I think we just had a
00:14:47.040 bit where we go and now we'll wait three
00:14:48.560 seconds and assume it's got R to it um
00:14:51.120 and that's just not great it's not not a
00:14:52.720 great match and the biggest problem we
00:14:54.639 found was it was really difficult to
00:14:56.040 drain requests because container lay
00:14:59.040 labels are immutable so you can boot up
00:15:00.920 your container and say send traffic to
00:15:02.959 this container but you can't get rid of
00:15:04.800 those labels it's just going to keep
00:15:06.199 sending the requests to the container
00:15:08.199 until the container goes away so you get
00:15:10.160 this problem as you're trying to stop it
00:15:12.440 before you stop it you want to say don't
00:15:14.399 send any more requests let's finish up
00:15:16.199 the requests that are there and then
00:15:17.560 we'll stop we couldn't do that with
00:15:19.120 traffic really we had to resort to like
00:15:21.759 really horrible hacks where we started
00:15:23.440 messing with um the health check and
00:15:27.600 deleting files so the health Che would
00:15:29.360 fail and traffic would go oh better not
00:15:31.040 send any traffic any requests to this
00:15:33.120 container so wasn't great and the third
00:15:36.160 thing is like it was hard to understand
00:15:38.800 what was going on when things went wrong
00:15:40.240 and this isn't traffic's fault this is
00:15:42.199 just you're getting errors in traffic's
00:15:45.000 language and traffic is a general
00:15:46.920 purpose proxy and it's got It's kind of
00:15:49.399 all these kind of quite um you know it's
00:15:53.560 got these different concepts that allow
00:15:55.480 you to do all kinds of things but we
00:15:57.120 just wanted it to do one thing so you
00:15:58.639 get these errors about entry points and
00:16:00.839 rouers and services and it's just like
00:16:02.959 well how does that connect to what I was
00:16:04.360 trying to do so we figured yes this is
00:16:07.600 not really working and what we decided
00:16:11.079 was we would build a our own proxy to
00:16:14.720 replace traffic and this proxy was built
00:16:17.399 with Cal exactly in mind so it's zero is
00:16:21.040 config basically what we're saying there
00:16:23.199 is one one of the things we want to do
00:16:25.240 is be able to run multiple applications
00:16:27.160 so if you have boot time configuration
00:16:30.240 then you can't vary it between the
00:16:31.839 applications so we have as little config
00:16:34.920 as possible when you boot the proxy and
00:16:38.120 there's this kind of onetoone command
00:16:39.920 mapping so when we want to deploy you
00:16:43.959 you type command deploy Cal deploy goes
00:16:46.279 to the proxy says deploy the proxy
00:16:48.040 deploys says I've done it we say yes
00:16:49.920 we've done it and everything is just
00:16:51.199 nice and streamlined everything Maps up
00:16:54.120 it's quick because you're not polling
00:16:55.759 and waiting and waiting um and that's
00:16:58.480 yeah that's kind of one of the reasons
00:17:00.160 we built it and as I said Kevin's going
00:17:02.000 to talk a lot more and there's some
00:17:03.560 really cool features that we're planning
00:17:05.760 to introduce into Kamal he's going to
00:17:07.120 show later
00:17:09.280 on okay so one of the things we wanted
00:17:11.959 to uh be able to do this so when we
00:17:14.160 built the first version of Cal it was
00:17:17.120 really designed specifically for our use
00:17:19.319 case in mind which was you've got you've
00:17:21.240 got an application you've already got a
00:17:23.199 load balancer you've got lots and lots
00:17:25.319 of um hosts that you're deploying to for
00:17:28.240 this one application
00:17:29.559 but a lot of people who are using Cal
00:17:31.200 had a different kind of setup where they
00:17:33.080 you know you've just got your sort of
00:17:34.679 brand new app you just want to run it on
00:17:36.400 a single server uh or you don't even
00:17:39.559 want to you know you've got six
00:17:41.039 different apps and you don't want six
00:17:42.160 different you don't need six different
00:17:43.240 servers or you don't mess around and
00:17:44.480 creating lots of EMS you just like to
00:17:45.960 run them all on that one single host so
00:17:48.919 we built in support for these we kind of
00:17:51.000 saw this earlier H in um David's keynote
00:17:56.080 but you just configure the host and say
00:17:58.280 SSL through and that should uh it'll go
00:18:01.799 and do the let's encryption dance so
00:18:03.679 what you need here for this to work is
00:18:05.640 that fu. example.com points directly to
00:18:08.400 this server and the port 443 is open on
00:18:12.159 that server and then the proxy will just
00:18:14.640 automatically do all the rest for you
00:18:16.520 you just deploy it should just
00:18:19.080 work and then multiple apps board we saw
00:18:21.600 this again you can just set the two
00:18:24.120 proxies in each app's configuration they
00:18:27.120 can deploy to the same server
00:18:29.360 and you will end up with a uh situation
00:18:32.640 that looks um a bit like this so we've
00:18:36.000 got a proxy here and we've got two
00:18:37.400 separate applications and it's using
00:18:39.080 host Bas routing to send the correct
00:18:42.080 requests to each container and now we
00:18:44.360 can go and do our deployments that we
00:18:46.080 saw earlier and deploy each container uh
00:18:49.080 independently at the same time it'll do
00:18:51.080 that dance of switching one version and
00:18:52.919 the other version out first um and yeah
00:18:56.360 it should just work um the thing was
00:18:59.480 that uh you know traffic one of the
00:19:01.880 things about traffic was that it was
00:19:03.200 very very flexible and we allowed you to
00:19:04.880 add all kinds of any labels you wanted
00:19:06.640 to so people have worked out how to do
00:19:09.039 these things in traffic one but it was
00:19:11.840 not it was like that was just people's
00:19:13.320 engineuity we had not designed it to do
00:19:14.960 that and there were certain things that
00:19:16.000 just didn't map well so we've kind of
00:19:17.760 gone back and tried to make sure that
00:19:19.000 it's specifically designed so that these
00:19:21.760 things just should
00:19:24.600 work um okay so next
00:19:30.039 right so if you haven't used Cal at all
00:19:32.799 this will be meaningless if you have
00:19:34.679 you've probably struggled with these
00:19:36.240 commands wondering when am I supposed to
00:19:37.799 run these what do they do like and
00:19:39.640 what's going on so the these were
00:19:41.520 commands we used for handling secrets so
00:19:44.520 we would um store secrets in uh in
00:19:49.440 theend file in the root of your
00:19:51.600 application and use the Cal N5 as a
00:19:54.919 command to build that from a template
00:19:56.880 and then push would then push them to
00:19:59.400 the servers and they had uh a different
00:20:02.520 life cycle to the rest of the commands
00:20:04.720 and you had to remember which things you
00:20:06.400 were supposed to run when and it was all
00:20:07.720 very complicated and we find it very
00:20:10.240 confusing so if you find it very
00:20:12.720 confusing you were not alone um so what
00:20:16.520 we wanted to do was yeah just simplify
00:20:19.400 this so we're using the rubyn gem so
00:20:23.520 that's do EnV and it has support built
00:20:26.840 in for variable command substitution so
00:20:30.120 we thought we'll just lean on that so
00:20:32.640 now here's what our secrets will look
00:20:34.880 like and this is what you should get in
00:20:36.120 the default rails at app uh we've moved
00:20:39.240 them they used to be in the end file but
00:20:41.240 that was like you know it clashed with
00:20:44.159 things like Forman so we' moved them
00:20:46.120 into a separate file and we're using the
00:20:48.960 interpolation to load these at kind of
00:20:51.480 run time so when you run your command we
00:20:53.280 will pull these in at that point so we
00:20:54.760 don't need templates that build other
00:20:57.640 files we don't need to store your
00:20:59.360 secrets on disk anywhere we can just uh
00:21:02.240 run it like this so what's happening in
00:21:03.640 that first line is it's just reading the
00:21:06.440 registry password in from uh the
00:21:09.240 environment which does mean you have to
00:21:11.080 set it up in your environment which is
00:21:12.360 annoying but we're hoping to get rid of
00:21:13.559 the registry all together so if we do
00:21:15.400 that then that problem goes away and
00:21:17.760 then the second command is using the
00:21:19.960 second line we're using H command
00:21:22.640 substitution so we're going to read the
00:21:25.200 configuration file uh directly from
00:21:28.159 config master key and that will just go
00:21:30.960 into uh reals master key again at
00:21:36.320 runtime okay so that sort of uh made
00:21:39.960 life a bit easier we don't need to store
00:21:41.640 the secrets as I said uh on the file
00:21:44.600 system you can commit this file into
00:21:47.080 your Source control um you can just put
00:21:49.720 your passwords directly in here if you
00:21:51.480 do take it out of source control um but
00:21:54.919 yeah it should just work but um there
00:21:58.840 there's one flaw here in what I'm saying
00:22:00.640 which is uh I'm saying they're not on
00:22:02.520 disk but actually if you look yes they
00:22:04.080 are on disk they're just in a different
00:22:05.880 file so uh what we what you know if you
00:22:09.559 start a new rails app and you have your
00:22:11.159 master key sitting in config master. key
00:22:14.279 you should probably put it somewhere a
00:22:15.520 bit safer as soon as possible so uh
00:22:19.360 We've also added some secret helpers to
00:22:21.400 kind of Aid doing this so um this is
00:22:25.799 kind of looks uh more like the version
00:22:28.200 we have running in Hay so what we've
00:22:30.200 done is we've added a couple of commands
00:22:32.480 into Cal and this first one Cal Secrets
00:22:35.640 fetch H we've got a bunch of different
00:22:37.960 adapters so there's one for one password
00:22:41.240 last pass and bit Warden at the moment
00:22:43.640 but we can we can add more as they go we
00:22:46.799 use one password so probably that one is
00:22:50.600 H the other ones may have uh
00:22:53.320 slightly uh rougher edges but we we'll
00:22:56.480 get there with those um and we call this
00:22:59.840 Cal Secrets fetch command and that is
00:23:01.919 going to go and manage getting the
00:23:05.000 secrets from our password manager for us
00:23:06.880 so it's going to check are you logged in
00:23:08.440 and if you're not logged in it's going
00:23:09.799 to ask you for your password or let you
00:23:11.919 you know put your fingerprint in and
00:23:14.520 authenticate with your password manager
00:23:16.559 and then as efficiently as possible it's
00:23:18.679 going to extract your passwords from
00:23:20.919 your password manager so in the case of
00:23:22.360 one password this means instead of
00:23:24.640 having to run separate commands for
00:23:26.159 every password if you store them all in
00:23:27.880 one item you can grab them all in one go
00:23:30.000 which can be much more efficient so
00:23:32.039 that's the first part and because we've
00:23:34.360 got them all in one go we've kind of we
00:23:36.919 then need a way to separate them out
00:23:38.919 into the different variables so we're
00:23:40.679 going to store them under secrets and
00:23:42.960 then we'll run uh Cal Secrets extract
00:23:46.000 which honestly is just a glorified
00:23:48.320 version of JQ but you're definitely
00:23:50.640 going to have Cal installed because
00:23:52.000 you're using Cal and you may not have or
00:23:53.880 want to make sure that you've got JQ Q
00:23:56.200 installed so that will then pull CL out
00:23:58.919 and store them in there so those
00:24:02.039 uh yeah those are the secret
00:24:05.279 outl uh okay so uh
00:24:11.159 next we've got uh so this uh David kind
00:24:15.080 of showed this uh a bit earlier but this
00:24:17.679 is the command you can run to open a
00:24:19.720 rails console and you can do this right
00:24:21.240 now in Camal one so app exac is a CALA
00:24:26.919 command that will
00:24:29.080 uh either boot up a new container
00:24:32.399 running your latest application image or
00:24:34.559 EXA into an existing container and run
00:24:37.240 the command ju Supply so you can just
00:24:39.039 pass rails console and there you go
00:24:41.120 you've got a running rails console in
00:24:43.919 production but the problem is that it
00:24:47.600 might be uh you know this is a bit of a
00:24:49.760 mouthful there also like you might have
00:24:52.000 very specific requirements you might
00:24:53.559 want the people always open the console
00:24:56.360 on a specific host so you can a host
00:24:59.080 parameter here you could pass minus H
00:25:00.760 the host you want people to open the
00:25:02.440 console but you want everyone to get the
00:25:04.760 same thing so that's where aliases come
00:25:06.960 in which you shown uh saw earlier but
00:25:09.559 here's how they look in uh the config so
00:25:12.760 you can just set an
00:25:14.159 alias um and you can say right who's
00:25:17.799 console and when you typ console it
00:25:20.240 means this command here and rails I
00:25:23.000 think will ship with console for opening
00:25:25.520 a console shell for opening a b shell
00:25:27.640 and logs for um just tailing logs on one
00:25:31.840 one of your
00:25:33.039 servers so yeah so that's the aliases
00:25:36.640 and that's how it works then you can
00:25:38.080 just run Cal console so if you've
00:25:39.760 deployed with Cal that should be enough
00:25:41.520 out of the box at rails eight to get
00:25:43.760 yourself a console uh that's up and
00:25:48.760 running okay so um yeah just to say in
00:25:53.840 conclusion uh So Cal one that was really
00:25:57.159 we built that with our speci ofic use
00:25:58.880 case in mine but with Cal 2 what we were
00:26:01.159 really looking at was say you know
00:26:04.399 you're you're just typing rails new you
00:26:07.080 using rails eight with Cal 2 say you've
00:26:10.760 just bought a domain and you've got like
00:26:12.200 a $6 a month uh like digital Ocean
00:26:14.919 droplet or something and you just want
00:26:16.159 to go as quickly as possible from rails
00:26:18.240 new to it just running on HPS we saw
00:26:21.080 from David's demo that you can do that
00:26:22.880 really really quickly so that's kind of
00:26:24.440 all the steps we've been uh doing here
00:26:27.080 to try and make that uh process as uh
00:26:30.880 smooth as possible so uh one other thing
00:26:34.080 I'll just say about Cal 2 is yes it's
00:26:36.799 not been released yet as I said before
00:26:39.640 it will be released later today uh Kevin
00:26:42.240 is going to help me uh with that because
00:26:44.360 he's dealing with Kamal proxy so we'll
00:26:46.080 wait till after he's talked as well and
00:26:48.440 then we should be uh ready to go and uh
00:26:51.720 yeah there'll be some up up uh updates
00:26:54.600 to the documentation at that point um
00:26:58.000 and yeah really good to know what you
00:27:02.240 think okay uh and I'll just leave you
00:27:05.640 with some links here that is the
00:27:07.679 currently Cal 1 documentation site soon
00:27:09.960 to be Cal 2 uh these are the repos for
00:27:13.320 Cal itself the gem and then for Cal
00:27:15.760 proxy the go uh proxy and that's me
00:27:21.159 thank you very much
Explore all talks recorded at Rails World 2024
+17