Original subtitles

This episode is sponsored by Honey Badger.

In this episode, we're going to have a look at MERSC, which is a new deployment tool created by 37Signals.

NDHH did create a video about it, giving a quick overview, but there were a lot of questions that it raised.

And so, in this episode, I want to go through and have a look at the MERSC library and how we can deploy a simple Rails application to DigitalOcean.

And the infrastructure will look something like this, where we have a single load balancer and that is pointing to two different droplets.

So this is our entry point, and then we'll use MERSC to deploy to two different droplets, and we'll have a separate database.

And that's one of the things that was a bit confusing when looking at the video. It looked like MERSC was also deploying a SQL Server and provisioning that on a VM.

And I don't recommend that because there's a lot of benefits that we get with a managed database.

And a lot of those are things that I just don't want to have to deal with on a day-to-day basis.

That could be automated snapshots before we do a deployment, backups, and that kind of stuff.

So that's not something that I want to have to worry about. I would much rather use a managed database.

And so we're going to have a look at basically creating two new virtual machines, as well as our database cluster and the load balancer.

And we will have to do a bit of configuration for the load balancer and the database cluster.

However, we are going to be able to use MERSC to completely provision and deploy our application to these two virtual machines.

We're not going to have to shell into these at all to do any of the initial configuration.

MERSC will handle doing the initial Docker installation as well as the deployments.

And the way that MERSC works is that it has a traffic load balancer.

And that load balancer will respond on port 80 as we'll see.

So if we edit the settings of our load balancer here, you'll see that we are just forwarding all of our SSL traffic over to port 80 to the two different virtual machines.

And if we go in and have a look at the virtual machines, I could do a Docker container LS to see what's running.

And on here, you'll see that we have the traffic server and that's listening on port 80.

And then we have our application and that's running on port 3000.

So traffic is taking all of the requests and it's forwarding it over to our Docker container running the Rails application.

And so what that means is we can spin up new applications on this particular virtual machine as we are doing a deployment.

So the old application will still be running in its own Docker container and then we would have a new one running.

And the way MERSC does this is that it'll first spin up a health check to make sure that the application is up and running and is able to run.

And it does that on port 3999.

If that is successful, then it'll bring down the old container and spin up the new one.

And it'll do that for however many services that you have.

And in our next episode, we're going to have a look picking up where this episode ends, where we are going to then introduce other services like site kick for handling background jobs, active storage for uploads and that kind of stuff as well.

But for this episode, getting all of this infrastructure set up and MERSC to deploy your application is going to be quite a bit of work in of itself.

So the first thing that I'm going to do here is I'm going to go through and I'm going to destroy everything just so we're going to start fresh.

I'll destroy all the virtual machines and then we'll also destroy the database cluster.

And so right now our project has nothing and I'm going to go ahead and set up this part just so we can be provisioning while we work on the Rails application side.

And so I'm going to go ahead and create a couple of droplets.

We'll select the New York region.

We do need to take note that this is in New York one and then I'm going to use an Ubuntu image.

I don't like using a non LTS version, so I am going to select Ubuntu 22.04.

And because this is just an example application, I'm going to choose a much smaller VM size.

You could probably get away with the 1 GB.

However, I'm going to select the 1 CPU and 2 GB.

I'll scroll down a bit.

I am going to use SSH authentication.

So I do have a public key already uploaded to this account.

And if we scroll down a bit, I'm going to create two separate droplets.

And so you can see that this total is going to be $28 a month.

But then we're also going to need a $12 a month load balancer.

And then we're also going to need a $15 a month SQL Server.

And so for just a basic application, this is going to run about $55 a month, which might seem like a lot.

But hopefully your application is generating more than that.

And that won't be an issue.

And so once these are being created, I'm going to go ahead and create a managed database.

I'm going to put in the same VPC, which is the New York one.

I'm going to be using Postgres SQL.

I'll select the starter plan, which keep in mind, it only has a 22 connection limit.

Because I don't have too many virtual machines that are going to be connecting to this.

That's not going to be that big of a deal.

But do keep in mind that if you are going to be having a lot of virtual machines, so a lot of web servers,

and if you're also going to have some background servers as well, then depending on the number of workers you have running,

and the number of web services and their number of workers, you could easily exceed this limit.

So you do want to be careful.

And you may need to bump it up to a larger plan if you need more connection limits.

There is always the possibility of creating your own droplet that acts as a proxy.

So all the connections will go through the proxy.

And then you just have a couple of connections connecting to the actual database server.

And however, while that may be cheaper, then go into the next size,

you do then have something else to maintain as well as being a single point of failure.

So I'll scroll down a bit and then we'll create the database cluster.

We'll go through the initial setup.

So you want to make sure that you don't skip this step.

And the reason why I created my virtual machines first is that now I can add them as a trusted source.

So I've selected both of my virtual machines,

which means that this database will not be accessible from any other IP addresses,

just these two virtual machines.

We'll continue on.

And then I'll click on the VPC network because we're not making a public request.

It's just going to be on our local environment.

And I'll just copy these connection details and I'll store them for later

because we are going to need these to connect to our database.

And then we can continue on.

And then finally, we can say great, I'm done because we're not going to be importing in our database.

But if you are migrating, then they do have some instructions on how you can do that.

So we'll finish this up and you'll see it'll take a little bit to create.

We can check on our other ones.

Our virtual machines are up and running.

The database is still provisioning.

But let's go ahead and create our load balancer so we can select our load balancer.

I want to make sure that we also have it selected in the same VPC.

We'll scroll down.

We're just going to have one node and then we can connect our droplets.

So taking note of what the names were, I'm just going to select the Ubuntu droplets.

And then I'll scroll down.

And here's where things get a little bit confusing if you don't know a lot about networking.

So typically our load balancer is going to be the SSL termination point.

So we can have all of our requests coming over port 443, which is an HTTPS.

We do need to have some kind of SSL certificate.

I did upload a self-signed certificate for here because I'm going to use Cloudflare to be my actual termination.

So Cloudflare will then just have the DNS settings point to the IP address of this load balancer.

So we'll continue on.

You'll see that we have some health checks here.

And with Rails 7.1, when that's released, we're actually going to have a health check endpoint at the URI up.

And because Rails 7.1 hasn't been released yet, there are some modifications that we're going to have to do to our application to get things up and running.

And in fact, we're going to be creating a standard Rails 7.0.4 application.

We will add stuff like a basic device install.

And then we're going to upgrade the application to Rails 7.1.

And that's simply because we will get some benefits from Rails 7.1 with the assume SSL,

which will allow for situations where we are terminating our SSL certificate at a proxy or load balancer.

And then those requests are coming unencrypted to the actual web application services.

So then we can scroll down.

We can redirect HTTP to HTTPS if we want.

It really shouldn't matter because Cloudflare is going to be sending over all the requests as HTTPS.

We then scroll down and then we'll hit create the load balancer.

And this, again, will take a few moments to create.

But we can go back to our projects and then we'll see our four running services.

And we will take note of these IP addresses as well because we will need that for our Merse deployment.

And the IP address for the load balancer, we'll need that to update our DNS services to point to this endpoint.

And so within our terminal, just to make sure I'm on the Rails 7.0.4, I'll go ahead and create a new project.

I'll call it template.

And I'm also going to pass in the database.

And we will set this equal to Postgres SQL.

We'll go ahead and create this and let it run.

And for this application, it is setting up ESBuild and CSS bundling with Bootstrap.

But it is a very basic install.

We can go into this project and then I'll run a script which simply adds device as a very basic install.

So it adds the gem.

It then creates a device user and then the device views.

It doesn't really do anything else.

It's just a very simple install.

And so the first thing that I'm going to do is come under the gem file and you'll see that if we want to use the edge rails instead,

then we can reference the GitHub rails and the main branch.

And I'm doing this because under the config, environments, and production environment, we do have a force SSL option,

but that force SSL isn't exactly what we want.

Instead, in the rail 7.1 library, we are getting access to a sum SSL.

And again, that's going to be helpful in situations where we have our load balancer terminating the SSL certificate

and our application is receiving the request in plain text.

And because that's all happening on the local VPC network, that's not that big of a deal.

We don't need to carry that SSL certificate all the way down to the rails application,

terminating it on the same VPC as our load balancer should be OK.

And so in the terminal, we will need to run bundle update rails to get the latest rails install.

So you can see we now have the rail 710 alpha.

So again, it is an alpha, so I don't recommend doing this in production yet.

If you have some hobby applications, you want to go ahead and upgrade this, then that's fine.

But do know that it is an alpha version and it's not ready for a production release yet.

Personally, I would recommend waiting to use MERSC with rail 7.1.

Or if you're a bit more familiar with the networking side of things and fixing some of the SSL certificate issues that you could experience,

then you could go ahead and use rail 704, but you could run into some redirect loop errors that's all centered around the SSL.

And so now that we have that installed, I'm going to do a bundle add MRSK.

And that's going to add the gem to our gem file.

And then we can call MRSK and then in it that'll create a config deployment and a dot in file.

And this is another thing that I noticed on DHH's video that wasn't very clear.

And it sounded like he committed the environment file into his get repository.

And that's very dangerous.

You do not want to do that because that is storing it in plain text.

So I think in at least what I understood and that I wanted to provide a clarification on is that this dot in file,

you should go into your get ignore if you don't have it already and you should exclude it because you don't want this getting pushed up to your code repository.

But what you do need to do is you do need to commit your code so you can have anything uncommitted.

So if I do a get status, you'll see that I have some things that have not been tracked yet and changes not staged for the commit.

And the way that MRSK works, if we do a git log, it's going to take the commit hash and it's going to use that for the Docker image tag.

So if I were to do the MRSK deployment right now, that's not really going to do anything or at least it's not going to pick up my latest code.

It's only going to take all the code up to the point where I added device.

So I believe that is what he meant by committing the code right after he had created the environment file.

But we're not ready to do any of the deployment yet because we do so have one big problem on our application.

Because this application was created based off Rails 7.04, it probably is a good idea to come into the config and the application.

And if we scroll down a bit, I'm going to load the defaults for the Rails 7.1.

You can look up what all the load defaults does.

But typically, once you verify that your application is all working correctly, once you've done your upgrade,

then come in and change the load defaults to the newer version.

And then you'll want to test again to make sure the new defaults hasn't broken anything within your app.

So once we have that done, we still have one more big missing piece, and that is our Docker file.

The way that Merck works is that it'll provision our remote virtual machines, or they could be bare metal servers as well.

And Merck is going to install Docker. It's also going to build a Docker image for our entire application.

It's going to push that image up to a registry, which by default, if we don't specify, it'll use Docker Hub.

And then it'll deploy that image.

And so, because this application was created off of Rails 7.0.4, we don't have a Docker file.

If we look at the Docker file that's created in a Rails 7 application, I'm just going to copy it over to my project.

But in the show notes for this episode, I will put the entire Docker file in the show notes, just so you can copy it from there.

This is what we're going to use, and we're actually not going to need to change anything within here.

For my application, because I am using ESBuild and CSS Bundling, it's going to work without any problems.

However, the one thing here that we will also need to copy is this Docker entry point.

And in the Rails 7.1 application, that's under our bin folder, so I'm going to copy that as well.

And we'll drop it in here.

And you'll see that it is simply just doing a Rails DB prepare, and then it's executing the command in the Docker file, which is starting the Rails server.

And if we wanted to, we can run the Docker build, and we could just try building this locally to make sure we're not going to have any problems.

However, because I am on an Apple M1 machine, I don't have the architecture set in my gemfile.lock.

So I am going to add that because I do want to make sure that this is going to work before we proceed further.

So I've added it in, and then we'll run the Docker build again.

And so then we can come under our config, and then there is this new deployment gemfile that was given to us.

We can update some of our text within here for the application name.

And in our case, I'm just going to call the directory example because I am going to use Docker Hub.

I will give it my Docker Hub name and then the servers we need to paste in the servers from Digital Ocean.

So I'll come over to Digital Ocean and I'll grab these and I'll paste them in.

And then we need to set our registry user.

Again, that's going to be my username.

And the password is going to refer to the password that is in the.env file.

So we will need to update this with the appropriate password.

And we also need to set the Rails master key.

So I'm going to go ahead and grab the master key and I'll paste that into the.env.

And then I'll go ahead and change this as well.

And this key is going to be what you get from Docker Hub or whatever your Docker registry is.

And so for our particular use case, we're not going to need to change anything else within here.

But it is good to come in and read out just all the different things that it's going to be doing.

And we don't need to make too many more changes within here.

We do want to go ahead and inject our environment variable for the secret, which is our Rails master key.

But we don't need to make any other changes in here.

If we had a separate machine that we wanted to use as our builder, because I am on an M1,

emulating the x86 AMD64 architecture is very slow.

You can get significantly faster build times using an Intel or AMD machine.

But for this example, I'm just going to leave it alone.

And then we have the accessories part.

And this is something that I really didn't like because I really don't want to have to manage my own database.

I would much rather have a managed database that I can use that's going to be backed up properly.

And I just won't have to worry about rather than managing that myself.

Same for Redis and any other kind of accessories or dependencies that your application may have,

like elastic search or anything like that.

And then there's some things for traffic that you can configure.

And also some things for the health check.

And there's one more thing that we need to do on our application before we test this out.

If we go into our database YAML file, you'll see under the production, it has our database, username and password.

However, that's not what we have here.

So instead, I am going to update this and we're just going to use a URL.

And instead of an environment variable here, which we could use,

I'm just going to use the rails.application.credentials.

And then I'm just going to call this the database underscore URL.

And the format that it's going to need to be in is going to be like the example above where we have our username,

which our username is a DO admin.

The password, I didn't copy the show text.

So luckily I can come back in into the database cluster.

I can check the VPC and get that password.

We can then change the my pass and then we need to select the host.

Instead of local host, it is going to be this long URL.

And we also have a different port.

It's not the standard Postgres SQL database port.

So at the end of the domain name, before we have our database, we need to put in a colon indicating a port.

And we need to put in that 25060.

And then the database that I created by default, I'm just going to use.

But you could create your own database if you wanted to.

So I'll paste that in and place it in the some database.

So this entire string I'm going to cut because we are going to need to go into our rails credentials.

And then we'll edit them.

And remember, our key is the database underscore URL.

And then we'll just set it to this long string.

Again, it is the Postgres colon forward slash forward slash our user, our password, the ad symbol, followed by our domain name, colon, our port number, forward slash and the database name.

So I'll save this and close it.

And then coming back down, I'll go ahead and delete the notes that we had here.

And then it'll make the proper connection.

And so I think I'm ready to test this out now.

However, before we testing out, we do need to commit all of our code.

So we'll run get status.

We'll see all of the changes and verify that this is all what we wanted.

Well, then do it get add and then we'll do a get commit.

I'll just give it a first deploy message and we don't need to push it up to our code repository.

It just needs to be committed here.

So if we go into the get log, we'll see that we no longer have the add device as our top level.

But instead, our head is now the new commit.

And this is the hash that will be created for the Docker tag.

And so we'll clear out the screen and let's have a look at MRSK.

We just run this without any commands.

You'll see that we get a list of everything that we need to do.

So we already ran the MRSK in it.

And with each one of these commands, like the MRSK app, if we run this and if we just run help,

that will also give us a list of all the different commands that's specific to that app command.

Whether we want to boot up or do something with containers, if we wanted to get the logs,

if we wanted to start or stop the containers and so forth.

Going back to the MRSK command, let's look to see what we need to do for our application.

It looks like the MRS server is going to be our best option.

So let's run that and then you'll see that there is a bootstrap command.

So if we run the MRSK server bootstrap, it picked up both the IP addresses

and that should get Docker up and running on those remote virtual machines.

And so that was pretty uneventful.

We do see the command that it ran on each one of the machines,

but it really didn't do anything else.

It just installed Docker.

So let's go back to our MRSK command and now let's try doing the deploy.

So we can try the MRSK deploy.

We can run help to see if there's any other commands and there wasn't.

We just have the MRSK deploy.

So let's go ahead and do that.

I'm going to clear out the terminal before we run it,

just so we can easily scroll back up to see what was done.

So you'll see first off, it's ensuring that Docker was initialized.

It then logs into our registry to make sure that we have access to the registry.

And then it's going to build and push our app image.

So because I am on an Apple Silicon machine,

we are using the Docker BuildX, pushing up to our registry,

specifying the platform AMD64,

and it's also building the Linux ARM64,

which isn't really needed because we are only deploying to an AMD64.

It is using the builder, MRS, DR example, multi-arch.

But if we look a little bit further down, we did get an error that that wasn't found.

So it's going to create it first,

and then it's going to continue one and try to rebuild.

It's tagging it with my username, the image name, and then our hash,

which again is the commit.

It's also tagging it as the latest,

and then it's specifying the dot,

which is going to look for the Docker file that we had copied over.

So it's going to go through and do all of this building.

And depending on the speed of your machine,

this could take a while.

So I'm going to just fast forward down through here,

and you see we got a strange error.

And that error was caused by the debug gem.

And for now, I'm just going to remove that because I really don't need that for my deployment.

But what I'll need to do is I'll need to get commit just so it'll pick up our new hash,

and then I can run the MRS deploy again.

And you'll see it's running all the steps that it did before,

but it is going to run a bit faster because now it is caching each one that completed steps.

If there was a change, like we had changed our gems,

then that is going to then have to redo those steps in below.

And so we'll let this run through, and then we'll look at the logs at the end.

And if we kind of want it to be a surprise,

we can go back to our droplets and we'll hop into the console.

I can run a watch-in.

We'll look at it every one second, and we can do a Docker container ls.

And right now we don't see any containers.

But as this goes through and it finishes the deployment,

it pushes up the image, and then it pulls the image over on our Digital Ocean droplet,

we should see the containers spin up, and we're expecting to see the traffic container.

We're also expecting to see a health check one created temporarily,

but then we're also expecting to see the health check pass the health checks,

and then our final container deployed.

And so again, depending on your CPU,

and if you're having to emulate the AMD64 x86 architecture,

this could take a few minutes, especially for your first deployment.

And you'll see we got another error because we need to add the Bundle Lock AMD64,

which I'll go ahead and run that.

We'll then get commit again.

And once we commit, we can then run the Merse Deploy.

And again, it's going to have to go through those steps,

but hopefully it made it a lot further down in the steps,

and so it's going to have a lot of that cached.

And I know that these logs that Merse is creating is a huge information dump,

but if you're having trouble deploying your application,

these logs will most likely tell you exactly what's going on,

or at least give you some kind of hints for some path forward.

So you do want to make sure that when you are asking for help with some of these issues,

that you are providing as much relevant information as possible.

And with that, if we look up at the top, notice that it is redacting

some of the important or the private information.

So sharing these log outputs shouldn't be too big of a deal.

And I also wanted to make a note of something that I brushed over pretty quickly

while it's still building all of this,

and that is that I did upgrade this application from a RAIL-704 to a 7.1,

which in the past could be a rather pain,

but you can see that if you have a very simple Rails application

or an application that's sticking very close to the Rails core,

meaning that you're not bringing in a lot of your own kind of configurations

or deviating from the Rails way,

then upgrading your application should be fairly simple.

And that's especially if you're not bringing in a lot of external gems as well.

And you can see that it's finished building our application's container image.

And if we look down, it tried removing an old image,

which that image wouldn't have existed,

but now you can see we have our traffic image that's built,

and now we have our example app running.

But before we go test it out,

let's go ahead and have a look at the rest of these logs.

So, Merseq pulled our image, then had Docker run traffic,

and then ran our application under health check with a published port of 3999.

It still points to our Rails application,

and this is where it's doing that health check.

So, it finished running that successfully,

but then it ran curl, which tried to hit that HTTP localhost port 3999 forward slash up,

and it failed.

It tried again, and it failed again,

it then tried, and then it succeeded.

And so that was just the application taking a moment to boot up,

and once it finally succeeded,

and if you remember, it then deleted that container,

and then it starts up our real one.

And it did this for both of our servers,

and then it finishes out.

And so our application should now be up and running.

So, I'm first going to just test the individual application,

because I could test it at the load balancer,

but before I go into that, I like testing it at the IP address level,

just so we're not adding in more things into the mix.

And if we look at our application, it's not very pleasing.

We're missing all of our assets.

And if we look at the console, we can verify that,

that the assets return 404 and not found.

And that could be really frustrating,

because you saw that all the assets were precompiled.

And in the past, what we normally did with our Rails application,

is we deployed it behind an Nginx server.

The Nginx would then proxy to our running Rails application,

but it would also serve all the assets from Nginx.

We don't have that in our case,

so we need to come back into our application,

in the environments, in the production environment file,

and we need to look for something around the Nginx.

So here you can see the config public file server enabled.

It's set to an environment variable, which we have not set.

Because we are now switching to this new deployment mechanism,

I'm just going to hard code it to true.

So again, we're going to have to come back in,

we'll have to git commit, we'll give it a commit message,

we can then run the MRS deploy again.

And so this is going to go a lot faster,

because we already have everything cached.

But you can see it's already done building the image, it pushed it up.

It's making sure that we have the fresh image on each one of the servers.

And then it's going through doing the deployment.

It again is doing the health checks, the health checks passed,

and then our application has finished deploying.

We can come back to our application, we can refresh the page, and it works.

But the real test here is to make sure that we can then sign in.

We'll sign up for an account.

I'll just use johnsmith at example.com, and then we'll sign up.

But you see, we did get an error here,

and it can be very frustrating because it's not a very helpful error message.

And so now because we have our application running in a Docker container,

and that Docker container is running on a virtual machine,

we can't just SSH into that virtual machine and look at the logs.

But luckily, if we run MRS and then app,

we can look at a lot of different commands that we can get.

One of them is logs.

If we run this, you'll see that it's going to shell into both of the servers,

and then it's going to spit out the logs.

But these are really useless.

It's not showing us what the error is.

So you could log in to the DigitalOcean interface.

You can open up a console to the droplet.

You can then go into that running container to see the logs,

or we could just log to the standard out.

So again, we need to come into our production.rb file.

And again, you'll see that there's an environment variable,

log to standard out.

If we delete that, because now we do want to log to standard out,

we can commit it again.

We can then run the MRS deploy,

and it'll have to go through all the building and deployment process again.

However, once it's done building our images,

it's then going to do the deployment process again with the health checks,

and then our application should be up and running.

And so with all that done, in just over a minute,

we can come back to our application.

We can try reposting.

We're going to get that same error as before because we haven't resolved that yet.

But now when we run the MRS app logs,

we are now seeing a lot more in our logs.

But unfortunately, we're not seeing the error.

Oh, but we are now on one of them,

but it wasn't enough to really pick up to see what's going on.

So what we can do is we can run the MRS app logs,

and then we can add the dash dash help.

That's going to give us more options,

and we see that there's a number of lines that we can go back on.

So let's go ahead and just run back maybe 1,000 lines.

And so here's the error.

Our origin header, because we did come under the HTTP,

we were assuming SSL, so it was expecting the HTTPS.

And so what we need to do is not access it directly from the IP address,

but instead we can access it from our load balancer.

I refresh the page just to make sure that it was healthy.

I can copy this IP address.

Because I am using a self-signed certificate, we will get an error,

but that's OK for now.

We can just continue on to that IP address,

and then we see our application running.

And now this application is load balanced,

so it is going to bounce between both of our servers.

But we can go ahead and test this out again with signing up for a new user,

and this time it works successfully.

We can sign out, sign in again just to make sure that works,

and we'll sign in, and we can sign in successfully.

So that's great.

So at this point, you would want to make sure that your application is all working

as you would expect before you change over any kind of DNS servers.

And once you change your DNS to point over to your load balancer,

it can take a while for that to work.

So be patient, and just know that if you can access your website

via the load balancer's IP address using SSL,

and if you have the appropriate settings in your DNS service,

then it'll start to work eventually.

It could just have a slow propagation.

So I can test this out again, logging in as John Smith, and it works.

So we've taken our application and upgraded it from Rails 7.04 to 7.1,

and also the Dockerfile to get our application built within a Docker container image.

And using Merck, we've deployed our application up to DigitalOcean,

provisioning the individual droplets,

and we've also set up all of that infrastructure in DigitalOcean all in this episode.

So it was a lot to cover, and I think for some that once you become familiar with Merck

and all that it can do, it can be a really great tool.

But again, depending on your application and some of the specific needs that you have,

you might find something like AppRunner from AWS, or Beanstalk,

or a Kubernetes solution might be more feasible.

Because again, remember, even though our container images are built,

and we really don't have to maintain those,

we do now have two droplets that we have to maintain.

Just as an example, if we shell into one of the containers,

you'll see that we are missing a lot of security updates.

So we are having to take on this responsibility of having to manage these two virtual machines.

And so we're having to do stuff like security updates on these machines,

which you do want to be careful on because if there ever is any kind of new Docker instance that's deployed,

or maybe there's something with DNS changes, then it could end up breaking your connection.

But luckily, you could always create a new virtual machine, update its packages,

and run Merce to deploy on those newly provisioned machines.

Because not only with the updates, another thing that we're also having to take responsibility for is our disk space.

So while we do have plenty of disk space on this particular machine,

and Merce does do a good job of removing old images,

as to not use up a bunch of disk space with old unused Docker images,

so that is good and helpful.

It's just something that you need to be aware of.

And the overhead of traffic is very minimal, so I wouldn't worry about that.

And we can see from our running instance, even though we only have one CPU,

with no traffic, there's not really anything happening, and we have plenty of room to grow with the RAM.

And so we probably could have deployed our application on the 1GB droplet as well.

And be sure to come in and read the documentation for Merce,

because there's a lot that we haven't covered in this episode.

Merce does support rollbacks, and it also supports using a generated environment file.

For example, if you are using something like 1Password, which does have a command line interface,

then you can use it to inject in from a environment.erb file with the merce-invify,

which will generate your environment file, and there's a few other options as well, such as bitwarden.

Again, I was using the default Docker Hub, and depending on your virtual machine or the bare-metal machine,

you may not have direct root access. Instead, you might need to use a different user.

And there's a lot of good documentation on the multi-architecture builds or single architecture builds,

as well as the accessories if you want to go down that route, or using CronJobs if you want to use those as well.

Just keep in mind that if you are using CronJobs to run a periodic rate task,

then that rate task is going to have to load up your Rails application in memory each time.

So if you have that CronJob running every one minute, that could actually be a huge load on your application server.

So you do want to be careful with that. And so do keep in mind that this is beta software,

and it is being developed fairly rapidly.

So if you're finding that some of the steps that we did in this episode aren't quite matching up,

then definitely check out the documentation to see if there's been some recent updates or changes,

which could affect that. Well, that's all for this episode. Thanks for watching.