Would you like to inspect the original subtitles? These are the user uploaded subtitles that are being translated:
1
00:00:00,000 --> 00:00:03,000
This episode is sponsored by Honey Badger.
2
00:00:13,000 --> 00:00:19,000
In this episode, we're going to have a look at MERSC, which is a new deployment tool created by 37Signals.
3
00:00:19,000 --> 00:00:27,000
NDHH did create a video about it, giving a quick overview, but there were a lot of questions that it raised.
4
00:00:27,000 --> 00:00:36,000
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.
5
00:00:36,000 --> 00:00:43,000
And the infrastructure will look something like this, where we have a single load balancer and that is pointing to two different droplets.
6
00:00:43,000 --> 00:00:52,000
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.
7
00:00:52,000 --> 00:01:03,000
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.
8
00:01:03,000 --> 00:01:08,000
And I don't recommend that because there's a lot of benefits that we get with a managed database.
9
00:01:08,000 --> 00:01:13,000
And a lot of those are things that I just don't want to have to deal with on a day-to-day basis.
10
00:01:13,000 --> 00:01:19,000
That could be automated snapshots before we do a deployment, backups, and that kind of stuff.
11
00:01:19,000 --> 00:01:24,000
So that's not something that I want to have to worry about. I would much rather use a managed database.
12
00:01:24,000 --> 00:01:32,000
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.
13
00:01:32,000 --> 00:01:37,000
And we will have to do a bit of configuration for the load balancer and the database cluster.
14
00:01:37,000 --> 00:01:46,000
However, we are going to be able to use MERSC to completely provision and deploy our application to these two virtual machines.
15
00:01:46,000 --> 00:01:51,000
We're not going to have to shell into these at all to do any of the initial configuration.
16
00:01:51,000 --> 00:01:56,000
MERSC will handle doing the initial Docker installation as well as the deployments.
17
00:01:56,000 --> 00:02:01,000
And the way that MERSC works is that it has a traffic load balancer.
18
00:02:01,000 --> 00:02:05,000
And that load balancer will respond on port 80 as we'll see.
19
00:02:05,000 --> 00:02:15,000
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.
20
00:02:15,000 --> 00:02:22,000
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.
21
00:02:22,000 --> 00:02:28,000
And on here, you'll see that we have the traffic server and that's listening on port 80.
22
00:02:28,000 --> 00:02:32,000
And then we have our application and that's running on port 3000.
23
00:02:32,000 --> 00:02:40,000
So traffic is taking all of the requests and it's forwarding it over to our Docker container running the Rails application.
24
00:02:40,000 --> 00:02:49,000
And so what that means is we can spin up new applications on this particular virtual machine as we are doing a deployment.
25
00:02:49,000 --> 00:02:55,000
So the old application will still be running in its own Docker container and then we would have a new one running.
26
00:02:55,000 --> 00:03:04,000
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.
27
00:03:04,000 --> 00:03:07,000
And it does that on port 3999.
28
00:03:07,000 --> 00:03:13,000
If that is successful, then it'll bring down the old container and spin up the new one.
29
00:03:13,000 --> 00:03:17,000
And it'll do that for however many services that you have.
30
00:03:17,000 --> 00:03:32,000
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.
31
00:03:32,000 --> 00:03:41,000
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.
32
00:03:41,000 --> 00:03:49,000
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.
33
00:03:49,000 --> 00:03:55,000
I'll destroy all the virtual machines and then we'll also destroy the database cluster.
34
00:03:55,000 --> 00:04:05,000
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.
35
00:04:05,000 --> 00:04:09,000
And so I'm going to go ahead and create a couple of droplets.
36
00:04:09,000 --> 00:04:11,000
We'll select the New York region.
37
00:04:11,000 --> 00:04:16,000
We do need to take note that this is in New York one and then I'm going to use an Ubuntu image.
38
00:04:16,000 --> 00:04:22,000
I don't like using a non LTS version, so I am going to select Ubuntu 22.04.
39
00:04:22,000 --> 00:04:28,000
And because this is just an example application, I'm going to choose a much smaller VM size.
40
00:04:28,000 --> 00:04:30,000
You could probably get away with the 1 GB.
41
00:04:30,000 --> 00:04:34,000
However, I'm going to select the 1 CPU and 2 GB.
42
00:04:34,000 --> 00:04:35,000
I'll scroll down a bit.
43
00:04:35,000 --> 00:04:38,000
I am going to use SSH authentication.
44
00:04:38,000 --> 00:04:42,000
So I do have a public key already uploaded to this account.
45
00:04:42,000 --> 00:04:45,000
And if we scroll down a bit, I'm going to create two separate droplets.
46
00:04:45,000 --> 00:04:49,000
And so you can see that this total is going to be $28 a month.
47
00:04:49,000 --> 00:04:53,000
But then we're also going to need a $12 a month load balancer.
48
00:04:53,000 --> 00:04:58,000
And then we're also going to need a $15 a month SQL Server.
49
00:04:58,000 --> 00:05:05,000
And so for just a basic application, this is going to run about $55 a month, which might seem like a lot.
50
00:05:05,000 --> 00:05:08,000
But hopefully your application is generating more than that.
51
00:05:08,000 --> 00:05:10,000
And that won't be an issue.
52
00:05:10,000 --> 00:05:15,000
And so once these are being created, I'm going to go ahead and create a managed database.
53
00:05:15,000 --> 00:05:19,000
I'm going to put in the same VPC, which is the New York one.
54
00:05:19,000 --> 00:05:21,000
I'm going to be using Postgres SQL.
55
00:05:21,000 --> 00:05:27,000
I'll select the starter plan, which keep in mind, it only has a 22 connection limit.
56
00:05:27,000 --> 00:05:31,000
Because I don't have too many virtual machines that are going to be connecting to this.
57
00:05:31,000 --> 00:05:34,000
That's not going to be that big of a deal.
58
00:05:34,000 --> 00:05:40,000
But do keep in mind that if you are going to be having a lot of virtual machines, so a lot of web servers,
59
00:05:40,000 --> 00:05:47,000
and if you're also going to have some background servers as well, then depending on the number of workers you have running,
60
00:05:47,000 --> 00:05:52,000
and the number of web services and their number of workers, you could easily exceed this limit.
61
00:05:52,000 --> 00:05:54,000
So you do want to be careful.
62
00:05:54,000 --> 00:05:59,000
And you may need to bump it up to a larger plan if you need more connection limits.
63
00:05:59,000 --> 00:06:04,000
There is always the possibility of creating your own droplet that acts as a proxy.
64
00:06:04,000 --> 00:06:07,000
So all the connections will go through the proxy.
65
00:06:07,000 --> 00:06:12,000
And then you just have a couple of connections connecting to the actual database server.
66
00:06:12,000 --> 00:06:16,000
And however, while that may be cheaper, then go into the next size,
67
00:06:16,000 --> 00:06:21,000
you do then have something else to maintain as well as being a single point of failure.
68
00:06:21,000 --> 00:06:25,000
So I'll scroll down a bit and then we'll create the database cluster.
69
00:06:25,000 --> 00:06:28,000
We'll go through the initial setup.
70
00:06:28,000 --> 00:06:30,000
So you want to make sure that you don't skip this step.
71
00:06:30,000 --> 00:06:36,000
And the reason why I created my virtual machines first is that now I can add them as a trusted source.
72
00:06:36,000 --> 00:06:39,000
So I've selected both of my virtual machines,
73
00:06:39,000 --> 00:06:43,000
which means that this database will not be accessible from any other IP addresses,
74
00:06:43,000 --> 00:06:46,000
just these two virtual machines.
75
00:06:46,000 --> 00:06:47,000
We'll continue on.
76
00:06:47,000 --> 00:06:52,000
And then I'll click on the VPC network because we're not making a public request.
77
00:06:52,000 --> 00:06:55,000
It's just going to be on our local environment.
78
00:06:55,000 --> 00:06:59,000
And I'll just copy these connection details and I'll store them for later
79
00:06:59,000 --> 00:07:02,000
because we are going to need these to connect to our database.
80
00:07:02,000 --> 00:07:04,000
And then we can continue on.
81
00:07:04,000 --> 00:07:09,000
And then finally, we can say great, I'm done because we're not going to be importing in our database.
82
00:07:09,000 --> 00:07:14,000
But if you are migrating, then they do have some instructions on how you can do that.
83
00:07:14,000 --> 00:07:18,000
So we'll finish this up and you'll see it'll take a little bit to create.
84
00:07:18,000 --> 00:07:20,000
We can check on our other ones.
85
00:07:20,000 --> 00:07:22,000
Our virtual machines are up and running.
86
00:07:22,000 --> 00:07:24,000
The database is still provisioning.
87
00:07:24,000 --> 00:07:28,000
But let's go ahead and create our load balancer so we can select our load balancer.
88
00:07:28,000 --> 00:07:32,000
I want to make sure that we also have it selected in the same VPC.
89
00:07:32,000 --> 00:07:34,000
We'll scroll down.
90
00:07:34,000 --> 00:07:38,000
We're just going to have one node and then we can connect our droplets.
91
00:07:38,000 --> 00:07:43,000
So taking note of what the names were, I'm just going to select the Ubuntu droplets.
92
00:07:43,000 --> 00:07:45,000
And then I'll scroll down.
93
00:07:45,000 --> 00:07:50,000
And here's where things get a little bit confusing if you don't know a lot about networking.
94
00:07:50,000 --> 00:07:55,000
So typically our load balancer is going to be the SSL termination point.
95
00:07:55,000 --> 00:08:02,000
So we can have all of our requests coming over port 443, which is an HTTPS.
96
00:08:02,000 --> 00:08:05,000
We do need to have some kind of SSL certificate.
97
00:08:05,000 --> 00:08:12,000
I did upload a self-signed certificate for here because I'm going to use Cloudflare to be my actual termination.
98
00:08:12,000 --> 00:08:19,000
So Cloudflare will then just have the DNS settings point to the IP address of this load balancer.
99
00:08:19,000 --> 00:08:20,000
So we'll continue on.
100
00:08:20,000 --> 00:08:22,000
You'll see that we have some health checks here.
101
00:08:22,000 --> 00:08:31,000
And with Rails 7.1, when that's released, we're actually going to have a health check endpoint at the URI up.
102
00:08:31,000 --> 00:08:39,000
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.
103
00:08:39,000 --> 00:08:45,000
And in fact, we're going to be creating a standard Rails 7.0.4 application.
104
00:08:45,000 --> 00:08:49,000
We will add stuff like a basic device install.
105
00:08:49,000 --> 00:08:53,000
And then we're going to upgrade the application to Rails 7.1.
106
00:08:53,000 --> 00:08:59,000
And that's simply because we will get some benefits from Rails 7.1 with the assume SSL,
107
00:08:59,000 --> 00:09:07,000
which will allow for situations where we are terminating our SSL certificate at a proxy or load balancer.
108
00:09:07,000 --> 00:09:12,000
And then those requests are coming unencrypted to the actual web application services.
109
00:09:12,000 --> 00:09:14,000
So then we can scroll down.
110
00:09:14,000 --> 00:09:18,000
We can redirect HTTP to HTTPS if we want.
111
00:09:18,000 --> 00:09:24,000
It really shouldn't matter because Cloudflare is going to be sending over all the requests as HTTPS.
112
00:09:24,000 --> 00:09:28,000
We then scroll down and then we'll hit create the load balancer.
113
00:09:28,000 --> 00:09:31,000
And this, again, will take a few moments to create.
114
00:09:31,000 --> 00:09:36,000
But we can go back to our projects and then we'll see our four running services.
115
00:09:36,000 --> 00:09:41,000
And we will take note of these IP addresses as well because we will need that for our Merse deployment.
116
00:09:41,000 --> 00:09:49,000
And the IP address for the load balancer, we'll need that to update our DNS services to point to this endpoint.
117
00:09:49,000 --> 00:09:56,000
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.
118
00:09:56,000 --> 00:09:58,000
I'll call it template.
119
00:09:58,000 --> 00:10:01,000
And I'm also going to pass in the database.
120
00:10:01,000 --> 00:10:03,000
And we will set this equal to Postgres SQL.
121
00:10:03,000 --> 00:10:06,000
We'll go ahead and create this and let it run.
122
00:10:06,000 --> 00:10:12,000
And for this application, it is setting up ESBuild and CSS bundling with Bootstrap.
123
00:10:12,000 --> 00:10:15,000
But it is a very basic install.
124
00:10:15,000 --> 00:10:21,000
We can go into this project and then I'll run a script which simply adds device as a very basic install.
125
00:10:21,000 --> 00:10:23,000
So it adds the gem.
126
00:10:23,000 --> 00:10:27,000
It then creates a device user and then the device views.
127
00:10:27,000 --> 00:10:29,000
It doesn't really do anything else.
128
00:10:29,000 --> 00:10:31,000
It's just a very simple install.
129
00:10:31,000 --> 00:10:39,000
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,
130
00:10:39,000 --> 00:10:42,000
then we can reference the GitHub rails and the main branch.
131
00:10:42,000 --> 00:10:52,000
And I'm doing this because under the config, environments, and production environment, we do have a force SSL option,
132
00:10:52,000 --> 00:10:55,000
but that force SSL isn't exactly what we want.
133
00:10:55,000 --> 00:11:01,000
Instead, in the rail 7.1 library, we are getting access to a sum SSL.
134
00:11:01,000 --> 00:11:08,000
And again, that's going to be helpful in situations where we have our load balancer terminating the SSL certificate
135
00:11:08,000 --> 00:11:13,000
and our application is receiving the request in plain text.
136
00:11:13,000 --> 00:11:18,000
And because that's all happening on the local VPC network, that's not that big of a deal.
137
00:11:18,000 --> 00:11:23,000
We don't need to carry that SSL certificate all the way down to the rails application,
138
00:11:23,000 --> 00:11:29,000
terminating it on the same VPC as our load balancer should be OK.
139
00:11:29,000 --> 00:11:35,000
And so in the terminal, we will need to run bundle update rails to get the latest rails install.
140
00:11:35,000 --> 00:11:39,000
So you can see we now have the rail 710 alpha.
141
00:11:39,000 --> 00:11:43,000
So again, it is an alpha, so I don't recommend doing this in production yet.
142
00:11:43,000 --> 00:11:47,000
If you have some hobby applications, you want to go ahead and upgrade this, then that's fine.
143
00:11:47,000 --> 00:11:52,000
But do know that it is an alpha version and it's not ready for a production release yet.
144
00:11:52,000 --> 00:11:57,000
Personally, I would recommend waiting to use MERSC with rail 7.1.
145
00:11:57,000 --> 00:12:04,000
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,
146
00:12:04,000 --> 00:12:13,000
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.
147
00:12:13,000 --> 00:12:19,000
And so now that we have that installed, I'm going to do a bundle add MRSK.
148
00:12:19,000 --> 00:12:22,000
And that's going to add the gem to our gem file.
149
00:12:22,000 --> 00:12:29,000
And then we can call MRSK and then in it that'll create a config deployment and a dot in file.
150
00:12:29,000 --> 00:12:34,000
And this is another thing that I noticed on DHH's video that wasn't very clear.
151
00:12:34,000 --> 00:12:38,000
And it sounded like he committed the environment file into his get repository.
152
00:12:38,000 --> 00:12:40,000
And that's very dangerous.
153
00:12:40,000 --> 00:12:44,000
You do not want to do that because that is storing it in plain text.
154
00:12:44,000 --> 00:12:52,000
So I think in at least what I understood and that I wanted to provide a clarification on is that this dot in file,
155
00:12:52,000 --> 00:13:01,000
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.
156
00:13:01,000 --> 00:13:08,000
But what you do need to do is you do need to commit your code so you can have anything uncommitted.
157
00:13:08,000 --> 00:13:15,000
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.
158
00:13:15,000 --> 00:13:24,000
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.
159
00:13:24,000 --> 00:13:33,000
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.
160
00:13:33,000 --> 00:13:37,000
It's only going to take all the code up to the point where I added device.
161
00:13:37,000 --> 00:13:43,000
So I believe that is what he meant by committing the code right after he had created the environment file.
162
00:13:43,000 --> 00:13:50,000
But we're not ready to do any of the deployment yet because we do so have one big problem on our application.
163
00:13:50,000 --> 00:13:59,000
Because this application was created based off Rails 7.04, it probably is a good idea to come into the config and the application.
164
00:13:59,000 --> 00:14:05,000
And if we scroll down a bit, I'm going to load the defaults for the Rails 7.1.
165
00:14:05,000 --> 00:14:08,000
You can look up what all the load defaults does.
166
00:14:08,000 --> 00:14:14,000
But typically, once you verify that your application is all working correctly, once you've done your upgrade,
167
00:14:14,000 --> 00:14:18,000
then come in and change the load defaults to the newer version.
168
00:14:18,000 --> 00:14:24,000
And then you'll want to test again to make sure the new defaults hasn't broken anything within your app.
169
00:14:24,000 --> 00:14:30,000
So once we have that done, we still have one more big missing piece, and that is our Docker file.
170
00:14:30,000 --> 00:14:39,000
The way that Merck works is that it'll provision our remote virtual machines, or they could be bare metal servers as well.
171
00:14:39,000 --> 00:14:46,000
And Merck is going to install Docker. It's also going to build a Docker image for our entire application.
172
00:14:46,000 --> 00:14:53,000
It's going to push that image up to a registry, which by default, if we don't specify, it'll use Docker Hub.
173
00:14:53,000 --> 00:14:55,000
And then it'll deploy that image.
174
00:14:55,000 --> 00:15:01,000
And so, because this application was created off of Rails 7.0.4, we don't have a Docker file.
175
00:15:01,000 --> 00:15:07,000
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.
176
00:15:07,000 --> 00:15:15,000
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.
177
00:15:15,000 --> 00:15:20,000
This is what we're going to use, and we're actually not going to need to change anything within here.
178
00:15:20,000 --> 00:15:27,000
For my application, because I am using ESBuild and CSS Bundling, it's going to work without any problems.
179
00:15:27,000 --> 00:15:32,000
However, the one thing here that we will also need to copy is this Docker entry point.
180
00:15:32,000 --> 00:15:38,000
And in the Rails 7.1 application, that's under our bin folder, so I'm going to copy that as well.
181
00:15:38,000 --> 00:15:40,000
And we'll drop it in here.
182
00:15:40,000 --> 00:15:49,000
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.
183
00:15:49,000 --> 00:15:57,000
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.
184
00:15:57,000 --> 00:16:04,000
However, because I am on an Apple M1 machine, I don't have the architecture set in my gemfile.lock.
185
00:16:04,000 --> 00:16:10,000
So I am going to add that because I do want to make sure that this is going to work before we proceed further.
186
00:16:10,000 --> 00:16:14,000
So I've added it in, and then we'll run the Docker build again.
187
00:16:14,000 --> 00:16:21,000
And so then we can come under our config, and then there is this new deployment gemfile that was given to us.
188
00:16:21,000 --> 00:16:26,000
We can update some of our text within here for the application name.
189
00:16:26,000 --> 00:16:31,000
And in our case, I'm just going to call the directory example because I am going to use Docker Hub.
190
00:16:31,000 --> 00:16:38,000
I will give it my Docker Hub name and then the servers we need to paste in the servers from Digital Ocean.
191
00:16:38,000 --> 00:16:44,000
So I'll come over to Digital Ocean and I'll grab these and I'll paste them in.
192
00:16:44,000 --> 00:16:46,000
And then we need to set our registry user.
193
00:16:46,000 --> 00:16:49,000
Again, that's going to be my username.
194
00:16:49,000 --> 00:16:55,000
And the password is going to refer to the password that is in the.env file.
195
00:16:55,000 --> 00:16:59,000
So we will need to update this with the appropriate password.
196
00:16:59,000 --> 00:17:01,000
And we also need to set the Rails master key.
197
00:17:01,000 --> 00:17:06,000
So I'm going to go ahead and grab the master key and I'll paste that into the.env.
198
00:17:06,000 --> 00:17:09,000
And then I'll go ahead and change this as well.
199
00:17:09,000 --> 00:17:14,000
And this key is going to be what you get from Docker Hub or whatever your Docker registry is.
200
00:17:14,000 --> 00:17:20,000
And so for our particular use case, we're not going to need to change anything else within here.
201
00:17:20,000 --> 00:17:26,000
But it is good to come in and read out just all the different things that it's going to be doing.
202
00:17:26,000 --> 00:17:29,000
And we don't need to make too many more changes within here.
203
00:17:29,000 --> 00:17:35,000
We do want to go ahead and inject our environment variable for the secret, which is our Rails master key.
204
00:17:35,000 --> 00:17:38,000
But we don't need to make any other changes in here.
205
00:17:38,000 --> 00:17:44,000
If we had a separate machine that we wanted to use as our builder, because I am on an M1,
206
00:17:44,000 --> 00:17:50,000
emulating the x86 AMD64 architecture is very slow.
207
00:17:50,000 --> 00:17:55,000
You can get significantly faster build times using an Intel or AMD machine.
208
00:17:55,000 --> 00:17:58,000
But for this example, I'm just going to leave it alone.
209
00:17:58,000 --> 00:18:00,000
And then we have the accessories part.
210
00:18:00,000 --> 00:18:05,000
And this is something that I really didn't like because I really don't want to have to manage my own database.
211
00:18:05,000 --> 00:18:11,000
I would much rather have a managed database that I can use that's going to be backed up properly.
212
00:18:11,000 --> 00:18:15,000
And I just won't have to worry about rather than managing that myself.
213
00:18:15,000 --> 00:18:21,000
Same for Redis and any other kind of accessories or dependencies that your application may have,
214
00:18:21,000 --> 00:18:24,000
like elastic search or anything like that.
215
00:18:24,000 --> 00:18:27,000
And then there's some things for traffic that you can configure.
216
00:18:27,000 --> 00:18:30,000
And also some things for the health check.
217
00:18:30,000 --> 00:18:35,000
And there's one more thing that we need to do on our application before we test this out.
218
00:18:35,000 --> 00:18:42,000
If we go into our database YAML file, you'll see under the production, it has our database, username and password.
219
00:18:42,000 --> 00:18:45,000
However, that's not what we have here.
220
00:18:45,000 --> 00:18:49,000
So instead, I am going to update this and we're just going to use a URL.
221
00:18:49,000 --> 00:18:53,000
And instead of an environment variable here, which we could use,
222
00:18:53,000 --> 00:18:58,000
I'm just going to use the rails.application.credentials.
223
00:18:58,000 --> 00:19:02,000
And then I'm just going to call this the database underscore URL.
224
00:19:02,000 --> 00:19:10,000
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,
225
00:19:10,000 --> 00:19:13,000
which our username is a DO admin.
226
00:19:13,000 --> 00:19:16,000
The password, I didn't copy the show text.
227
00:19:16,000 --> 00:19:20,000
So luckily I can come back in into the database cluster.
228
00:19:20,000 --> 00:19:23,000
I can check the VPC and get that password.
229
00:19:23,000 --> 00:19:27,000
We can then change the my pass and then we need to select the host.
230
00:19:27,000 --> 00:19:31,000
Instead of local host, it is going to be this long URL.
231
00:19:31,000 --> 00:19:33,000
And we also have a different port.
232
00:19:33,000 --> 00:19:37,000
It's not the standard Postgres SQL database port.
233
00:19:37,000 --> 00:19:44,000
So at the end of the domain name, before we have our database, we need to put in a colon indicating a port.
234
00:19:44,000 --> 00:19:47,000
And we need to put in that 25060.
235
00:19:47,000 --> 00:19:51,000
And then the database that I created by default, I'm just going to use.
236
00:19:51,000 --> 00:19:54,000
But you could create your own database if you wanted to.
237
00:19:54,000 --> 00:19:58,000
So I'll paste that in and place it in the some database.
238
00:19:58,000 --> 00:20:04,000
So this entire string I'm going to cut because we are going to need to go into our rails credentials.
239
00:20:04,000 --> 00:20:06,000
And then we'll edit them.
240
00:20:06,000 --> 00:20:10,000
And remember, our key is the database underscore URL.
241
00:20:10,000 --> 00:20:13,000
And then we'll just set it to this long string.
242
00:20:13,000 --> 00:20:28,000
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.
243
00:20:28,000 --> 00:20:30,000
So I'll save this and close it.
244
00:20:30,000 --> 00:20:35,000
And then coming back down, I'll go ahead and delete the notes that we had here.
245
00:20:35,000 --> 00:20:37,000
And then it'll make the proper connection.
246
00:20:37,000 --> 00:20:40,000
And so I think I'm ready to test this out now.
247
00:20:40,000 --> 00:20:44,000
However, before we testing out, we do need to commit all of our code.
248
00:20:44,000 --> 00:20:45,000
So we'll run get status.
249
00:20:45,000 --> 00:20:49,000
We'll see all of the changes and verify that this is all what we wanted.
250
00:20:49,000 --> 00:20:53,000
Well, then do it get add and then we'll do a get commit.
251
00:20:53,000 --> 00:20:58,000
I'll just give it a first deploy message and we don't need to push it up to our code repository.
252
00:20:58,000 --> 00:21:00,000
It just needs to be committed here.
253
00:21:00,000 --> 00:21:07,000
So if we go into the get log, we'll see that we no longer have the add device as our top level.
254
00:21:07,000 --> 00:21:10,000
But instead, our head is now the new commit.
255
00:21:10,000 --> 00:21:15,000
And this is the hash that will be created for the Docker tag.
256
00:21:15,000 --> 00:21:19,000
And so we'll clear out the screen and let's have a look at MRSK.
257
00:21:19,000 --> 00:21:21,000
We just run this without any commands.
258
00:21:21,000 --> 00:21:24,000
You'll see that we get a list of everything that we need to do.
259
00:21:24,000 --> 00:21:26,000
So we already ran the MRSK in it.
260
00:21:26,000 --> 00:21:33,000
And with each one of these commands, like the MRSK app, if we run this and if we just run help,
261
00:21:33,000 --> 00:21:40,000
that will also give us a list of all the different commands that's specific to that app command.
262
00:21:40,000 --> 00:21:45,000
Whether we want to boot up or do something with containers, if we wanted to get the logs,
263
00:21:45,000 --> 00:21:49,000
if we wanted to start or stop the containers and so forth.
264
00:21:49,000 --> 00:21:55,000
Going back to the MRSK command, let's look to see what we need to do for our application.
265
00:21:55,000 --> 00:21:59,000
It looks like the MRS server is going to be our best option.
266
00:21:59,000 --> 00:22:04,000
So let's run that and then you'll see that there is a bootstrap command.
267
00:22:04,000 --> 00:22:10,000
So if we run the MRSK server bootstrap, it picked up both the IP addresses
268
00:22:10,000 --> 00:22:15,000
and that should get Docker up and running on those remote virtual machines.
269
00:22:15,000 --> 00:22:17,000
And so that was pretty uneventful.
270
00:22:17,000 --> 00:22:21,000
We do see the command that it ran on each one of the machines,
271
00:22:21,000 --> 00:22:23,000
but it really didn't do anything else.
272
00:22:23,000 --> 00:22:25,000
It just installed Docker.
273
00:22:25,000 --> 00:22:29,000
So let's go back to our MRSK command and now let's try doing the deploy.
274
00:22:29,000 --> 00:22:31,000
So we can try the MRSK deploy.
275
00:22:31,000 --> 00:22:35,000
We can run help to see if there's any other commands and there wasn't.
276
00:22:35,000 --> 00:22:37,000
We just have the MRSK deploy.
277
00:22:37,000 --> 00:22:39,000
So let's go ahead and do that.
278
00:22:39,000 --> 00:22:41,000
I'm going to clear out the terminal before we run it,
279
00:22:41,000 --> 00:22:45,000
just so we can easily scroll back up to see what was done.
280
00:22:45,000 --> 00:22:49,000
So you'll see first off, it's ensuring that Docker was initialized.
281
00:22:49,000 --> 00:22:54,000
It then logs into our registry to make sure that we have access to the registry.
282
00:22:54,000 --> 00:22:57,000
And then it's going to build and push our app image.
283
00:22:57,000 --> 00:23:00,000
So because I am on an Apple Silicon machine,
284
00:23:00,000 --> 00:23:05,000
we are using the Docker BuildX, pushing up to our registry,
285
00:23:05,000 --> 00:23:08,000
specifying the platform AMD64,
286
00:23:08,000 --> 00:23:11,000
and it's also building the Linux ARM64,
287
00:23:11,000 --> 00:23:16,000
which isn't really needed because we are only deploying to an AMD64.
288
00:23:16,000 --> 00:23:21,000
It is using the builder, MRS, DR example, multi-arch.
289
00:23:21,000 --> 00:23:25,000
But if we look a little bit further down, we did get an error that that wasn't found.
290
00:23:25,000 --> 00:23:27,000
So it's going to create it first,
291
00:23:27,000 --> 00:23:30,000
and then it's going to continue one and try to rebuild.
292
00:23:30,000 --> 00:23:35,000
It's tagging it with my username, the image name, and then our hash,
293
00:23:35,000 --> 00:23:37,000
which again is the commit.
294
00:23:37,000 --> 00:23:40,000
It's also tagging it as the latest,
295
00:23:40,000 --> 00:23:42,000
and then it's specifying the dot,
296
00:23:42,000 --> 00:23:45,000
which is going to look for the Docker file that we had copied over.
297
00:23:45,000 --> 00:23:48,000
So it's going to go through and do all of this building.
298
00:23:48,000 --> 00:23:50,000
And depending on the speed of your machine,
299
00:23:50,000 --> 00:23:52,000
this could take a while.
300
00:23:52,000 --> 00:23:54,000
So I'm going to just fast forward down through here,
301
00:23:54,000 --> 00:23:56,000
and you see we got a strange error.
302
00:23:56,000 --> 00:23:59,000
And that error was caused by the debug gem.
303
00:23:59,000 --> 00:24:04,000
And for now, I'm just going to remove that because I really don't need that for my deployment.
304
00:24:04,000 --> 00:24:09,000
But what I'll need to do is I'll need to get commit just so it'll pick up our new hash,
305
00:24:09,000 --> 00:24:11,000
and then I can run the MRS deploy again.
306
00:24:11,000 --> 00:24:14,000
And you'll see it's running all the steps that it did before,
307
00:24:14,000 --> 00:24:19,000
but it is going to run a bit faster because now it is caching each one that completed steps.
308
00:24:19,000 --> 00:24:23,000
If there was a change, like we had changed our gems,
309
00:24:23,000 --> 00:24:27,000
then that is going to then have to redo those steps in below.
310
00:24:27,000 --> 00:24:31,000
And so we'll let this run through, and then we'll look at the logs at the end.
311
00:24:31,000 --> 00:24:33,000
And if we kind of want it to be a surprise,
312
00:24:33,000 --> 00:24:37,000
we can go back to our droplets and we'll hop into the console.
313
00:24:37,000 --> 00:24:40,000
I can run a watch-in.
314
00:24:40,000 --> 00:24:46,000
We'll look at it every one second, and we can do a Docker container ls.
315
00:24:46,000 --> 00:24:49,000
And right now we don't see any containers.
316
00:24:49,000 --> 00:24:53,000
But as this goes through and it finishes the deployment,
317
00:24:53,000 --> 00:24:58,000
it pushes up the image, and then it pulls the image over on our Digital Ocean droplet,
318
00:24:58,000 --> 00:25:04,000
we should see the containers spin up, and we're expecting to see the traffic container.
319
00:25:04,000 --> 00:25:08,000
We're also expecting to see a health check one created temporarily,
320
00:25:08,000 --> 00:25:12,000
but then we're also expecting to see the health check pass the health checks,
321
00:25:12,000 --> 00:25:15,000
and then our final container deployed.
322
00:25:15,000 --> 00:25:17,000
And so again, depending on your CPU,
323
00:25:17,000 --> 00:25:23,000
and if you're having to emulate the AMD64 x86 architecture,
324
00:25:23,000 --> 00:25:26,000
this could take a few minutes, especially for your first deployment.
325
00:25:26,000 --> 00:25:31,000
And you'll see we got another error because we need to add the Bundle Lock AMD64,
326
00:25:31,000 --> 00:25:33,000
which I'll go ahead and run that.
327
00:25:33,000 --> 00:25:35,000
We'll then get commit again.
328
00:25:35,000 --> 00:25:38,000
And once we commit, we can then run the Merse Deploy.
329
00:25:38,000 --> 00:25:40,000
And again, it's going to have to go through those steps,
330
00:25:40,000 --> 00:25:43,000
but hopefully it made it a lot further down in the steps,
331
00:25:43,000 --> 00:25:46,000
and so it's going to have a lot of that cached.
332
00:25:46,000 --> 00:25:50,000
And I know that these logs that Merse is creating is a huge information dump,
333
00:25:50,000 --> 00:25:53,000
but if you're having trouble deploying your application,
334
00:25:53,000 --> 00:25:57,000
these logs will most likely tell you exactly what's going on,
335
00:25:57,000 --> 00:26:01,000
or at least give you some kind of hints for some path forward.
336
00:26:01,000 --> 00:26:05,000
So you do want to make sure that when you are asking for help with some of these issues,
337
00:26:05,000 --> 00:26:09,000
that you are providing as much relevant information as possible.
338
00:26:09,000 --> 00:26:13,000
And with that, if we look up at the top, notice that it is redacting
339
00:26:13,000 --> 00:26:17,000
some of the important or the private information.
340
00:26:17,000 --> 00:26:21,000
So sharing these log outputs shouldn't be too big of a deal.
341
00:26:21,000 --> 00:26:24,000
And I also wanted to make a note of something that I brushed over pretty quickly
342
00:26:24,000 --> 00:26:26,000
while it's still building all of this,
343
00:26:26,000 --> 00:26:33,000
and that is that I did upgrade this application from a RAIL-704 to a 7.1,
344
00:26:33,000 --> 00:26:36,000
which in the past could be a rather pain,
345
00:26:36,000 --> 00:26:40,000
but you can see that if you have a very simple Rails application
346
00:26:40,000 --> 00:26:44,000
or an application that's sticking very close to the Rails core,
347
00:26:44,000 --> 00:26:48,000
meaning that you're not bringing in a lot of your own kind of configurations
348
00:26:48,000 --> 00:26:51,000
or deviating from the Rails way,
349
00:26:51,000 --> 00:26:54,000
then upgrading your application should be fairly simple.
350
00:26:54,000 --> 00:26:58,000
And that's especially if you're not bringing in a lot of external gems as well.
351
00:26:58,000 --> 00:27:03,000
And you can see that it's finished building our application's container image.
352
00:27:03,000 --> 00:27:07,000
And if we look down, it tried removing an old image,
353
00:27:07,000 --> 00:27:09,000
which that image wouldn't have existed,
354
00:27:09,000 --> 00:27:12,000
but now you can see we have our traffic image that's built,
355
00:27:12,000 --> 00:27:15,000
and now we have our example app running.
356
00:27:15,000 --> 00:27:17,000
But before we go test it out,
357
00:27:17,000 --> 00:27:20,000
let's go ahead and have a look at the rest of these logs.
358
00:27:20,000 --> 00:27:25,000
So, Merseq pulled our image, then had Docker run traffic,
359
00:27:25,000 --> 00:27:31,000
and then ran our application under health check with a published port of 3999.
360
00:27:31,000 --> 00:27:33,000
It still points to our Rails application,
361
00:27:33,000 --> 00:27:36,000
and this is where it's doing that health check.
362
00:27:36,000 --> 00:27:39,000
So, it finished running that successfully,
363
00:27:39,000 --> 00:27:48,000
but then it ran curl, which tried to hit that HTTP localhost port 3999 forward slash up,
364
00:27:48,000 --> 00:27:49,000
and it failed.
365
00:27:49,000 --> 00:27:52,000
It tried again, and it failed again,
366
00:27:52,000 --> 00:27:54,000
it then tried, and then it succeeded.
367
00:27:54,000 --> 00:27:58,000
And so that was just the application taking a moment to boot up,
368
00:27:58,000 --> 00:28:00,000
and once it finally succeeded,
369
00:28:00,000 --> 00:28:03,000
and if you remember, it then deleted that container,
370
00:28:03,000 --> 00:28:05,000
and then it starts up our real one.
371
00:28:05,000 --> 00:28:08,000
And it did this for both of our servers,
372
00:28:08,000 --> 00:28:10,000
and then it finishes out.
373
00:28:10,000 --> 00:28:14,000
And so our application should now be up and running.
374
00:28:14,000 --> 00:28:18,000
So, I'm first going to just test the individual application,
375
00:28:18,000 --> 00:28:21,000
because I could test it at the load balancer,
376
00:28:21,000 --> 00:28:26,000
but before I go into that, I like testing it at the IP address level,
377
00:28:26,000 --> 00:28:29,000
just so we're not adding in more things into the mix.
378
00:28:29,000 --> 00:28:32,000
And if we look at our application, it's not very pleasing.
379
00:28:32,000 --> 00:28:34,000
We're missing all of our assets.
380
00:28:34,000 --> 00:28:37,000
And if we look at the console, we can verify that,
381
00:28:37,000 --> 00:28:40,000
that the assets return 404 and not found.
382
00:28:40,000 --> 00:28:42,000
And that could be really frustrating,
383
00:28:42,000 --> 00:28:45,000
because you saw that all the assets were precompiled.
384
00:28:45,000 --> 00:28:48,000
And in the past, what we normally did with our Rails application,
385
00:28:48,000 --> 00:28:52,000
is we deployed it behind an Nginx server.
386
00:28:52,000 --> 00:28:56,000
The Nginx would then proxy to our running Rails application,
387
00:28:56,000 --> 00:29:00,000
but it would also serve all the assets from Nginx.
388
00:29:00,000 --> 00:29:02,000
We don't have that in our case,
389
00:29:02,000 --> 00:29:04,000
so we need to come back into our application,
390
00:29:04,000 --> 00:29:08,000
in the environments, in the production environment file,
391
00:29:08,000 --> 00:29:11,000
and we need to look for something around the Nginx.
392
00:29:11,000 --> 00:29:15,000
So here you can see the config public file server enabled.
393
00:29:15,000 --> 00:29:18,000
It's set to an environment variable, which we have not set.
394
00:29:18,000 --> 00:29:22,000
Because we are now switching to this new deployment mechanism,
395
00:29:22,000 --> 00:29:24,000
I'm just going to hard code it to true.
396
00:29:24,000 --> 00:29:27,000
So again, we're going to have to come back in,
397
00:29:27,000 --> 00:29:30,000
we'll have to git commit, we'll give it a commit message,
398
00:29:30,000 --> 00:29:33,000
we can then run the MRS deploy again.
399
00:29:33,000 --> 00:29:35,000
And so this is going to go a lot faster,
400
00:29:35,000 --> 00:29:37,000
because we already have everything cached.
401
00:29:37,000 --> 00:29:41,000
But you can see it's already done building the image, it pushed it up.
402
00:29:41,000 --> 00:29:45,000
It's making sure that we have the fresh image on each one of the servers.
403
00:29:45,000 --> 00:29:48,000
And then it's going through doing the deployment.
404
00:29:48,000 --> 00:29:52,000
It again is doing the health checks, the health checks passed,
405
00:29:52,000 --> 00:29:55,000
and then our application has finished deploying.
406
00:29:55,000 --> 00:30:00,000
We can come back to our application, we can refresh the page, and it works.
407
00:30:00,000 --> 00:30:04,000
But the real test here is to make sure that we can then sign in.
408
00:30:04,000 --> 00:30:06,000
We'll sign up for an account.
409
00:30:06,000 --> 00:30:10,000
I'll just use johnsmith at example.com, and then we'll sign up.
410
00:30:10,000 --> 00:30:13,000
But you see, we did get an error here,
411
00:30:13,000 --> 00:30:17,000
and it can be very frustrating because it's not a very helpful error message.
412
00:30:17,000 --> 00:30:21,000
And so now because we have our application running in a Docker container,
413
00:30:21,000 --> 00:30:24,000
and that Docker container is running on a virtual machine,
414
00:30:24,000 --> 00:30:28,000
we can't just SSH into that virtual machine and look at the logs.
415
00:30:28,000 --> 00:30:31,000
But luckily, if we run MRS and then app,
416
00:30:31,000 --> 00:30:34,000
we can look at a lot of different commands that we can get.
417
00:30:34,000 --> 00:30:36,000
One of them is logs.
418
00:30:36,000 --> 00:30:41,000
If we run this, you'll see that it's going to shell into both of the servers,
419
00:30:41,000 --> 00:30:43,000
and then it's going to spit out the logs.
420
00:30:43,000 --> 00:30:45,000
But these are really useless.
421
00:30:45,000 --> 00:30:48,000
It's not showing us what the error is.
422
00:30:48,000 --> 00:30:51,000
So you could log in to the DigitalOcean interface.
423
00:30:51,000 --> 00:30:54,000
You can open up a console to the droplet.
424
00:30:54,000 --> 00:30:58,000
You can then go into that running container to see the logs,
425
00:30:58,000 --> 00:31:00,000
or we could just log to the standard out.
426
00:31:00,000 --> 00:31:04,000
So again, we need to come into our production.rb file.
427
00:31:04,000 --> 00:31:06,000
And again, you'll see that there's an environment variable,
428
00:31:06,000 --> 00:31:08,000
log to standard out.
429
00:31:08,000 --> 00:31:12,000
If we delete that, because now we do want to log to standard out,
430
00:31:12,000 --> 00:31:14,000
we can commit it again.
431
00:31:14,000 --> 00:31:16,000
We can then run the MRS deploy,
432
00:31:16,000 --> 00:31:20,000
and it'll have to go through all the building and deployment process again.
433
00:31:20,000 --> 00:31:22,000
However, once it's done building our images,
434
00:31:22,000 --> 00:31:26,000
it's then going to do the deployment process again with the health checks,
435
00:31:26,000 --> 00:31:29,000
and then our application should be up and running.
436
00:31:29,000 --> 00:31:32,000
And so with all that done, in just over a minute,
437
00:31:32,000 --> 00:31:34,000
we can come back to our application.
438
00:31:34,000 --> 00:31:36,000
We can try reposting.
439
00:31:36,000 --> 00:31:40,000
We're going to get that same error as before because we haven't resolved that yet.
440
00:31:40,000 --> 00:31:43,000
But now when we run the MRS app logs,
441
00:31:43,000 --> 00:31:46,000
we are now seeing a lot more in our logs.
442
00:31:46,000 --> 00:31:49,000
But unfortunately, we're not seeing the error.
443
00:31:49,000 --> 00:31:51,000
Oh, but we are now on one of them,
444
00:31:51,000 --> 00:31:54,000
but it wasn't enough to really pick up to see what's going on.
445
00:31:54,000 --> 00:31:58,000
So what we can do is we can run the MRS app logs,
446
00:31:58,000 --> 00:32:01,000
and then we can add the dash dash help.
447
00:32:01,000 --> 00:32:03,000
That's going to give us more options,
448
00:32:03,000 --> 00:32:07,000
and we see that there's a number of lines that we can go back on.
449
00:32:07,000 --> 00:32:11,000
So let's go ahead and just run back maybe 1,000 lines.
450
00:32:11,000 --> 00:32:13,000
And so here's the error.
451
00:32:13,000 --> 00:32:17,000
Our origin header, because we did come under the HTTP,
452
00:32:17,000 --> 00:32:23,000
we were assuming SSL, so it was expecting the HTTPS.
453
00:32:23,000 --> 00:32:28,000
And so what we need to do is not access it directly from the IP address,
454
00:32:28,000 --> 00:32:32,000
but instead we can access it from our load balancer.
455
00:32:32,000 --> 00:32:35,000
I refresh the page just to make sure that it was healthy.
456
00:32:35,000 --> 00:32:37,000
I can copy this IP address.
457
00:32:37,000 --> 00:32:41,000
Because I am using a self-signed certificate, we will get an error,
458
00:32:41,000 --> 00:32:42,000
but that's OK for now.
459
00:32:42,000 --> 00:32:46,000
We can just continue on to that IP address,
460
00:32:46,000 --> 00:32:48,000
and then we see our application running.
461
00:32:48,000 --> 00:32:51,000
And now this application is load balanced,
462
00:32:51,000 --> 00:32:54,000
so it is going to bounce between both of our servers.
463
00:32:54,000 --> 00:32:58,000
But we can go ahead and test this out again with signing up for a new user,
464
00:32:58,000 --> 00:33:00,000
and this time it works successfully.
465
00:33:00,000 --> 00:33:04,000
We can sign out, sign in again just to make sure that works,
466
00:33:04,000 --> 00:33:07,000
and we'll sign in, and we can sign in successfully.
467
00:33:07,000 --> 00:33:08,000
So that's great.
468
00:33:08,000 --> 00:33:12,000
So at this point, you would want to make sure that your application is all working
469
00:33:12,000 --> 00:33:17,000
as you would expect before you change over any kind of DNS servers.
470
00:33:17,000 --> 00:33:21,000
And once you change your DNS to point over to your load balancer,
471
00:33:21,000 --> 00:33:23,000
it can take a while for that to work.
472
00:33:23,000 --> 00:33:27,000
So be patient, and just know that if you can access your website
473
00:33:27,000 --> 00:33:31,000
via the load balancer's IP address using SSL,
474
00:33:31,000 --> 00:33:35,000
and if you have the appropriate settings in your DNS service,
475
00:33:35,000 --> 00:33:37,000
then it'll start to work eventually.
476
00:33:37,000 --> 00:33:40,000
It could just have a slow propagation.
477
00:33:40,000 --> 00:33:45,000
So I can test this out again, logging in as John Smith, and it works.
478
00:33:45,000 --> 00:33:51,000
So we've taken our application and upgraded it from Rails 7.04 to 7.1,
479
00:33:51,000 --> 00:33:57,000
and also the Dockerfile to get our application built within a Docker container image.
480
00:33:57,000 --> 00:34:02,000
And using Merck, we've deployed our application up to DigitalOcean,
481
00:34:02,000 --> 00:34:05,000
provisioning the individual droplets,
482
00:34:05,000 --> 00:34:10,000
and we've also set up all of that infrastructure in DigitalOcean all in this episode.
483
00:34:10,000 --> 00:34:16,000
So it was a lot to cover, and I think for some that once you become familiar with Merck
484
00:34:16,000 --> 00:34:20,000
and all that it can do, it can be a really great tool.
485
00:34:20,000 --> 00:34:24,000
But again, depending on your application and some of the specific needs that you have,
486
00:34:24,000 --> 00:34:29,000
you might find something like AppRunner from AWS, or Beanstalk,
487
00:34:29,000 --> 00:34:32,000
or a Kubernetes solution might be more feasible.
488
00:34:32,000 --> 00:34:37,000
Because again, remember, even though our container images are built,
489
00:34:37,000 --> 00:34:39,000
and we really don't have to maintain those,
490
00:34:39,000 --> 00:34:42,000
we do now have two droplets that we have to maintain.
491
00:34:42,000 --> 00:34:46,000
Just as an example, if we shell into one of the containers,
492
00:34:46,000 --> 00:34:50,000
you'll see that we are missing a lot of security updates.
493
00:34:50,000 --> 00:34:57,000
So we are having to take on this responsibility of having to manage these two virtual machines.
494
00:34:57,000 --> 00:35:01,000
And so we're having to do stuff like security updates on these machines,
495
00:35:01,000 --> 00:35:07,000
which you do want to be careful on because if there ever is any kind of new Docker instance that's deployed,
496
00:35:07,000 --> 00:35:12,000
or maybe there's something with DNS changes, then it could end up breaking your connection.
497
00:35:12,000 --> 00:35:17,000
But luckily, you could always create a new virtual machine, update its packages,
498
00:35:17,000 --> 00:35:21,000
and run Merce to deploy on those newly provisioned machines.
499
00:35:21,000 --> 00:35:28,000
Because not only with the updates, another thing that we're also having to take responsibility for is our disk space.
500
00:35:28,000 --> 00:35:32,000
So while we do have plenty of disk space on this particular machine,
501
00:35:32,000 --> 00:35:36,000
and Merce does do a good job of removing old images,
502
00:35:36,000 --> 00:35:40,000
as to not use up a bunch of disk space with old unused Docker images,
503
00:35:40,000 --> 00:35:42,000
so that is good and helpful.
504
00:35:42,000 --> 00:35:44,000
It's just something that you need to be aware of.
505
00:35:44,000 --> 00:35:49,000
And the overhead of traffic is very minimal, so I wouldn't worry about that.
506
00:35:49,000 --> 00:35:54,000
And we can see from our running instance, even though we only have one CPU,
507
00:35:54,000 --> 00:36:00,000
with no traffic, there's not really anything happening, and we have plenty of room to grow with the RAM.
508
00:36:00,000 --> 00:36:04,000
And so we probably could have deployed our application on the 1GB droplet as well.
509
00:36:04,000 --> 00:36:08,000
And be sure to come in and read the documentation for Merce,
510
00:36:08,000 --> 00:36:11,000
because there's a lot that we haven't covered in this episode.
511
00:36:11,000 --> 00:36:17,000
Merce does support rollbacks, and it also supports using a generated environment file.
512
00:36:17,000 --> 00:36:23,000
For example, if you are using something like 1Password, which does have a command line interface,
513
00:36:23,000 --> 00:36:31,000
then you can use it to inject in from a environment.erb file with the merce-invify,
514
00:36:31,000 --> 00:36:37,000
which will generate your environment file, and there's a few other options as well, such as bitwarden.
515
00:36:37,000 --> 00:36:44,000
Again, I was using the default Docker Hub, and depending on your virtual machine or the bare-metal machine,
516
00:36:44,000 --> 00:36:50,000
you may not have direct root access. Instead, you might need to use a different user.
517
00:36:50,000 --> 00:36:56,000
And there's a lot of good documentation on the multi-architecture builds or single architecture builds,
518
00:36:56,000 --> 00:37:03,000
as well as the accessories if you want to go down that route, or using CronJobs if you want to use those as well.
519
00:37:03,000 --> 00:37:08,000
Just keep in mind that if you are using CronJobs to run a periodic rate task,
520
00:37:08,000 --> 00:37:13,000
then that rate task is going to have to load up your Rails application in memory each time.
521
00:37:13,000 --> 00:37:20,000
So if you have that CronJob running every one minute, that could actually be a huge load on your application server.
522
00:37:20,000 --> 00:37:25,000
So you do want to be careful with that. And so do keep in mind that this is beta software,
523
00:37:25,000 --> 00:37:28,000
and it is being developed fairly rapidly.
524
00:37:28,000 --> 00:37:33,000
So if you're finding that some of the steps that we did in this episode aren't quite matching up,
525
00:37:33,000 --> 00:37:38,000
then definitely check out the documentation to see if there's been some recent updates or changes,
526
00:37:38,000 --> 00:37:59,000
which could affect that. Well, that's all for this episode. Thanks for watching.
54929
Can't find what you're looking for?
Get subtitles in any language from opensubtitles.com, and translate them here.