Transcript
Hello, friends. Today we are going to talk about deploying a Rails Aid application to production on gender.com. Now, uh, super Rails itself, uh, has been running on gender since forever, since I launched Super Rails. It's always been on render. Let's first have a look at how Super Rails is set up to work on gender. So first of all, let's have a look at the project, and we have, uh, web service, the rails, uh, application, uh, voca and the database. So I'm not using Redis because I'm using the gem. Good job for, uh, active jobs for all my jobs. And, uh, it is Postgres based, so I don't have Redis as a dependency. Let's a look at the web application. The setup is, um, very simple. So going to the settings I have, uh, the build command. This is mostly all the default, but in the end I also run bundle execute trails, db, migrate. So on each push to production, I also run the migrations if there are any missing migrations. And then they have just bundle start rail server, uh, going to environment variables. Also, nothing specific, nothing important, just the database, URL and the Rails Master key. These are important, uh, the database, URL, you can get it from render. Again here, if I open my database, click on connect here, I will have a database, URL, I can copy it and paste it there and go to the worker. Again, it's the same web application deployed where I also add the database, URL, the real master key. But I have a different run command going to settings here. I start command to start. Good job. So when will execute, good job start. And that's basically it. That's my whole setup of, uh, heavy rails running on the production. Nothing sophisticated. And if I have a look at the billing, let's see here. So, uh, uh, you see I'm paying like $21 for running the, uh, web application, the VO and the database that is shared among those two. Now, how can we deploy a new Rails application, uh, rails eight application to, uh, production. Um, let's start from a new application here. I've just created a new Rails eight application. And let's look at our database setup and out our GEM file. So we have, uh, gem Escal, and we have, uh, uh, escal as a database for production and for development. First of all, I'm going to change the database from escal to, uh, Postgre Scale. So render, it runs with, uh, uh, Postgre Scale. You can create a new Postgres database and connect to it. And, uh, generally speaking, I don't, uh, feel confident yet in deploying my applications, uh, uh, with having Skel Light as a database. So, uh, first of all, I'm going to change the database to PostgreSQL. We can run this command reality system change to PostgreSQL, uh, allow, okay, it'll, uh, let's say the changes. So in the GEM file, we replaced, escalated with Postgres in doca file. It was also replaced, and we updated our database via. Now let's have a look here. So we are using Postgres. And, uh, here you see if a production, we would be creating four separate databases, one for the main application database, one for solid cache, solid queue, and solid cable solid tri factor. Okay, let's run bundle And let's say Rails db, uh, create. You see in development, we created just, uh, one, uh, database. Uh, but, uh, with the current setup on production would be creating four separate databases. Let's say Rose BIM Migrate. Okay, and let's save our changes. So, um, what was the command, uh, change to Postgre scale? Okay, now, uh, we don't want to pay for four separate databases, uh, then deploy into production. We want to, to maybe use a bunch of database for all these services. So we want to solid Q cable and cache to use the same main postgre scale database. Andrew, um, Atkinson, the Postgres guy, he wrote nice book about Postgres, uh, wrote about, uh, using the sold queue and sold cache with Postgres. I commend these, uh, articles. Good stuff. So, uh, let's try, uh, running sold queue, uh, the, uh, job adapter on development using our main, uh, database. So, uh, to do this, uh, we can go to the documentation of soq. And here we'll have something about, uh, single database configuration. This is what we need. We want to use not, uh, three databases for each of them bought just one. So copy the contents of DB Q schema, uh, into normal migration and delete this content. Uh, let's say rails generate migration. Uh, solid q it creates, uh, the sold queue migration. Let's, uh, copy all this, uh, stuff into the main migration. Okay? Delete the queue schema. And, uh, we can also do something similar with the, uh, cable and with the cache. So solid cable And solid cache. Let's try running all the three solid, uh, uh, gems in, uh, the same Postgres database. So, uh, solid cable and, uh, solid cache. Okay, delete these other schemas. So we don't need all these, uh, through additional schemas. Let's run the migrations rails DB migrate. Okay, uh, let's, uh, see our changes. So in the schema, we've added all the migrations for all the solid tools. Uh, looks good. Now let's update our database configuration. So going to database via ml, um, for production. Uh, we can remove all the settings for using a separate database and going to, uh, queue via ML here. We are going to, no, we actually don't need to say anything. Let's go to cable. And, uh, here we are going to say, uh, connects to database write. And, uh, it's not going to be write, it is going to be the, uh, main database. Let's see, it's going to be primary. Um, we have primary defined, uh, here in database v ml. So this is the primary database. And for cache in production, we're also going to use the primary database. Okay, going back to the solid, uh, seconds. Let's, uh, go to development, RB and, uh, active job. Uh, do we have a queue adapter set here? No, let's go to production. So here in production, the queue adapter is set to solid queue. Uh, we are not going to need this line for using a separate database anymore. We can just remove it from production. I think it's also set, uh, in the sold queue. Yeah, remove config, sold queue connect tool from production. So we're removing this line. And, uh, yeah, we want to run it sold queue also locally on our, uh, development database, not, uh, in line. So I will say config, active job queue adapter is sold queue because by default it's in line, uh, in development mode. So we're going to run, uh, sold queue in development. And, uh, let's, uh, now, uh, try to trigger a job. Let's, uh, save our changes. Um, so solid, uh, soldier effect with one database. Okay, now let's try to trigger a job. Uh, let's say rails generate job, uh, hello world. Let's open the, the job. Let's say put hello world and let's, uh, run this job rails, uh, console before. Hello, will job perform later. And let's, uh, maybe try in queue the job for, uh, running like one week, uh, from now So we can say hello. Will job, uh, set, uh, what's the syntax? Wait v perform later. Okay, now, how can we see if, uh, we have these jobs? Uh, n queued to check this, the best way is to install mission control, uh, GitHub Mission control. So, uh, it's uh, also a jump from Rails for, uh, having a dashboard of all your jobs. Let's, uh, add this, jump to our jam file next to other, other solid jumps. 'cause it's kind of related to sold queue. Okay, now we need to add the jobs to our roots. And, uh, is there anything else we need to do? Let's start the rail server and see if it works. Okay? We cannot start the server via not, um, address already in use. Okay? I might be already running a rail server, uh, elsewhere. So let's say port 3 0 0 3. Okay, let's go to slash jobs and, uh, it doesn't work because we need to, uh, yeah, maybe try disabling this H two B basic, uh, uh, authentication. Let's, uh, disabled in development. Just have the jobs dashboard available quickly. Okay, so here you see, I have one, uh, scheduled job that is scheduled to run, uh, in seven days. Let's try scheduling another job. So refreshing. You see, I have two schedule jobs and, uh, why are they not trying? I have the rail server running where the job's not trying because I need to start the solid queue. So, uh, there are a couple of ways of starting solid queue. Um, one way would be to, let's open our profile. Oh, I don't have a profile because, uh, I'm not running, uh, like Vin CSS, it wasn't generated, uh, automatically. So let's just start a new process. And, uh, uh, they're going to say Bin Rails. Solid queue start. Okay, so you see, uh, the one job has been processed. If I go back, uh, you see finished jobs, there is one, uh, let's, uh, again, try running one job now without setting wait time, perform later, and still have two jobs that have been performed. So we have sold Q running with re locally. Now if we go to Puma, do Aby, that's something really interesting. You see, we have this, uh, plug and sold queue. Uh, So if we have environment variable sold queue in Puma enabled, then we are going to be able to run sold queue in line without having a separate process. So I don't need to run this command sold queue start. Uh, I can just say something like, if Rails equals development, then we will also run it, uh, uh, in line. Let's, uh, now just at the rail server, I'm not starting the VOCA separately. And, uh, let's have a look at our jobs. So we have two jobs finished, perform later there, three jobs finished. So see, uh, this plugin sold Queue is working with Puma and Works. Fantastic. Okay, so, uh, let's see. We have, uh, mission control and we've got jobs, uh, running. So now we can be sure that, uh, sold Queue is working, uh, uh, locally with our Postgres database. Now, if you are thinking of, uh, improving solid cache, for example, uh, its performance with, uh, Postgres, then you should also read this article and it gives some guides on how, how to set up your Postgres properly. So let's save our changes. I think we have everything they need to go into production, uh, Uh, run jobs. Uh, okay, let's just, uh, create a basic migration of both into our application. Uh, let's, uh, go and say Rails generate, scuff post, uh, title Rails to be migrate, just so that we have some kind of data to play with. Let's set the route to post index, and let's go to local host. So we have posts, we can create posts, okay, so now we have a basic application that we can deploy to production and play with. Okay, we are ready to push to, uh, render. So, uh, where are we going to start? Let's go and add a new, we can start with a new web service, but I would suggest starting with a new, uh, database, it can take some time to generate the database and we'll need the database, uh, URL for our web service. So, uh, let's give it a name. I know, like, uh, uh, render, uh, PG one. Uh, we don't need to set anything here. Uh, latest version, obviously. Um, there's actually a free plan that you can also try running, and it was a nice surprise for me to learn. That Run has some free plans. So if you're just experimenting and starting out, then you can, uh, try with a free plan. Let's go with basic, let, So 15 gigs of storage by default. That's, uh, uh, fine. Again, uh, I can try like five gigs of whatever. You can see the price in here. Let's go with, uh, 15, create database. And here, if you go to Connect, you have this internal database, UL uh, so external. If you're going to, uh, let's say host your web application, one place and your database on render internal, if, uh, you have the web application and the database both on render. So I will copy this and you see the status of the database is creating it. It can take air vial. Let's go and create a new web, uh, service. And here I'm going to connect a web, uh, uh, a GitHub repository. Let's, uh, see, I have this GitHub repository. I will, um, copy the URL. Uh, yes, it's a public GitHub repository. Uh, let's see. Yeah, maybe I have just created this repository so it's not, uh, uh, found yet. Let's click connect again. Um, let's try given access. Okay, so I went to the settings, configuring GitHub, and here I authorized this render eight, uh, repository. Okay, let's take this repository. Oh, yeah, maybe because it was, uh, private, I didn't notice. Okay, so, uh, language here I need to select, uh, Ruby, uh, build command. I will also say, uh, rails. D my grade bundle exec rails, DB my grade. Uh, and start command, uh, can be, it can be this one, it can be bundle exec rails, Server. Uh, again, that's also a free version, uh, for the web application, but we are going to run on the start plan. Good to start. So here I need to add my rails, master key. Uh, do I have one generated? Let's see here. I have a master key. Let's see if, uh, it works. Um, editor VM rails credentials, edit. Yes. So I can access the credentials with this, uh, master key. And I will also need a database, URL. Now, if you go to database, v ML here says that, uh, uh, yes, you can manually say, say all this, but the database CRL is, uh, takes precedence over anything. So we're going to use database URL. And, uh, in the meantime, let's go and have a look at our Postgres and cope with the database URL once again. Okay, so here's the Postgres, URL, uh, advanced. So, uh, the health check part is slash up in New Rails applications. If you go to slash uh, up, you see there's a green screen. So it's an default health check pod that exists in Rails eight, uh, or to deploy. So whenever you have a new change pushed to the main branch in, uh, GitHub, it's going to automatically deploy the latest updates. Uh, and I think they're all good. We can go and deploy the web service. Yeah, one thing I forgot, just one thing. Uh, going back to our Puma settings here, you see we have the salt queue in Puma. So I'm also going to go to environment for arrivals, and I will set the cell queue in PTO through, okay, save, rebuild and deploy. And now let's wait for our application to build and see if it works. Okay, so took couple of minutes and you see going back to the list of services, I see that the, the web application has been deployed. Let's try open. So here is the, uh, generated URL, and you see it's running. Let's try creating the post. Uh, hello. And yeah, the post has been created. Let's try viewing our jobs. Um, so I cannot view the jobs because I, uh, disabled authentication on mission controlled jobs only in development. So I can also do it in production. Again, I don't recommend the disabling this, uh, uh, job authentication in production. It's just for, uh, us to quickly be able to view, uh, and maybe trigger jobs in production. So let's, uh, uh, push the changes. And you see, I just pushed the changes and, uh, we are automatically redeploying. Okay, so now I have redeployed. Let's have a look at our application. So you see the jobs dashboard works. Let's try, uh, extend the render console. So going to Shell. And here we can, uh, now when it loads, we can maybe run Rails Console. Okay, let's say Rails Console. No Rails Console. Let's see if it connects. Okay, let's see. Uh, post count. Uh, let's now trigger a job. Uh, what was the job's name? Hello, world and Job Perform Later. Let's look at our jobs and see. We have one job that has been, uh, performed. It has been performed because we have our jobs, uh, running in the same process as our, uh, web application. So that's amazing. And yes, that is basically it. I deployed a Rails eight application using so trifecta and Postgre scale to production. Now you see, I manually had to create the, the web application. The, uh, database and render has an actually better way to deploy applications via blueprints. So imagine as in like Kamal, Kamal, uh, file, um, deploy via ml. So here has the Deploy ML file for Kamal. And it list a list of things that, uh, you would need to fill to, uh, deploy application to production. And render has a similar file render by ML that you can fill in that would automatically set up the database, the s and everything for your application. So, uh, for example, on, um, Mon Gun, my, uh, boil plate application, I have this random ML file. Let's have a look at it. And, uh, I said that we create the A database in Frankfurt region. On this plan, or on this plan, I set the disc size to then gigabyte by default, I create one web service, uh, the build command, the start command. So you see everything that I manually selected in the web view can be set up in this, uh, render dot v ml file. And, uh, using this render via ML file, I can even, uh, have add one click, deploy, uh, button. So clicking on deploy to render will, uh, open my repository, the blueprint, and uh, I can give it a name. So let's name it Money Gun, uh, branch Main. And there is one key that is required. It is the Rails master key. So, uh, let's have a look. I will get my master key Config master key. I will paste it here, deploy Blueprint. And, uh, going back, let's look at our, a list of our projects. So here has, uh, the database that it's created outta the database. It is going to create the web service, and it's going to connect everything. And, uh, using blueprints, you can, uh, uh, set up everything in code, how you want your application to be running. Maybe you want to have readiness, maybe you want to have, uh, uh, aed, web, uh, service for, uh, good job or anything else. You can set it up all in Render yml. And you don't need to manually click through the, uh, web fuels of, uh, render. So I think this, uh, is a wonderful way to keep track of all the services you need to correctly deploy application to production. And if you're using render, I would actually recommend having this kind of random I ml file for your deploys and, uh, update it as your Apple has new environment variables as it, uh, has new services. And yeah, deploy via render I ml. So yes, that's basically it. This is how you can deploy Rails, modern rails applications with render to production. Now, another thing I usually add to my applications when deploy into production is Glock. So it helps to reduce the member usage of the application to add to render Avenue, to set this LD Preload environment arrival. So going into an environment and this environment for arrival. And I will set it to this. Thanks Mark for the prompt Save and redeploy. And I think, uh, now it's going to work. Now previously to add the Glock to an Rails app that I was using on ku, I would need to set the environment for Glock enabled to through, and I would need to add the add build back of, uh, G Lock like this. And, uh, yeah, nothing I kind of like about Trend is, for example, let me go and create a new, new web service and, uh, you can add add disk. So going into advanced, you can add the add disk, you know, with Heroku, like, uh, if you redeploy everything you've been doing that is not still in the database is, uh, lost. And here you can have some storage, uh, for your ongoing stuff. So that's, uh, nice. And yeah, there's kind of a bunch of, uh, uh, reasons to use Run Over Heroku. Like, uh, there's, uh, means for HDP requests versus 30 seconds on Heroku, uh, render is, uh, cheaper than Heroku, much cheaper than, uh, Heroku if you are scaling a lot. And finally, big shout out and thank you to render.com for sponsoring this video, for giving this motivation to find the best approach to deploy a Rails eight application to production and deliver it to you.
0