Table of contents

Hey there, my dear readers! Today I am going to tell you a story about how I prepare the production environment for a Meteor application in a very detailed manner. Anyway, we all should know how it is usually done by hands, when no Docker or any other special software involved, shouldn`t we? The main question we are going to answer here is: “Okay fine, how to make it work in the end?”

At this moment we have our well-mastered Meteor app at the local dev machine and the brand new, fresh VDS we just purchased, with Centos 7 onboard, which we are going to utilize.

“Why Centos 7?” — you might ask. No reason. I use Debian on my desktop and happy with that, but when it is about networking and stuff like that, RedHat-based distribution is my choice.

Right. So, grab some beer, coffee, tea, whatever and let`s start.

# Step 1. SSH access

The first thing we are going to need is the external IP address — the static IP address of our server. How to find out: go to the control panel of the server (whatever it is — it depends on your hoster) and look around — the address should be there, it goes along with the server. Write it down to your favorite notepad app, you are going to need it. In my case, it is 173.20.88.42

Under your usual normal user (which is not root I hope) on your dev machine, we generate the RSA key pair (if you have done it before, just skip this action):

After passing a little quiz by ssh-keygen, we can find the new file in our home directory: ~/.ssh/id_rsa.pub. Now we need to deploy the public key to our server. There are two ways possible:

1. Deploy the key via the control panel of your hoster, if available. This way is preferable because it guarantees your key will be transferred safely via the HTTPS connection and no root password is exposed during the transfer (THEY are watching!). How to do it exactly — depends on the hoster.
2. In case of the hoster does not provide this feature (baaaad boooy), we can do it by hands, but you are going to need the root ssh password. Where to find: in the hoster control panel — it should be there, 100% sure, as this is, like, the initial credentials which always present when you buy a VDS.

Assume we have picked the second option, then we upload the public key to the server with scp:

where 173.20.88.42 is the static IP address of the server (notepad, remember?). You will be asked for the root password of the server then. Do not screw up with this! Send only .pub key, because the other key is private. Never ever show your private key to anybody. Done? Good. Now we log-in the server under root:

Type the password again. Then, after you logged in, we set the key as an authorized one and exit the server:

Done, try to log-in again:

From this moment on, you wont be asked for the password anymore: this is the magic ofRSA` in action.

# Step 2: Regular remote user

We are not going to work under root, we need a special dedicated user to run our project under. I suggest making one user per project (in case if you run several projects on the same server). It brings order to chaos and makes us feel more secure. But first, (not coffee) we update everything:

I usually name the user in the same way I name the project. Let it be

We also set up the password (you will need it when doing su myapp) and disable log-in with password:

We make this user able to run commands with sudo

Yes, in Сentos wheel is the sudo group by default.

Now we give our user the same public SSH key we gave to root. No worries, without the private key our public one is just a piece of paper.

Since this moment, we can log-in under our myapp with SSH without specifying the password too.

In addition, you might want to add some splendid aliases and tune your shell a bit. Just put this listing inside /home/myapp/.bashrc and they will take effect on the next login:

You can add more aliases, different and beautiful, if want.

# Step 3. Improve SSH

It is time to make our SSH even more secure. Before we start, I would kindly ask you to launch two (better three) SSH root sessions in the separate terminals. We are going to tune SSH settings, and if you screw up with this, you will no longer able to regain the access to our server, so you will end up texting your hoster support. A quick reminder:

Firstly, we disable the firewall, in case we have any (if the server is not the cheapest one, the firewall could be there and could be active):

We ensure there are no rules left in iptables (that is the name of the Linux firewall):

You should see picture like this:

Thats it, you are now as vulnerable as a goat inside the lions cage. Except, you got nothing to steal from you. Yet.

Meanwhile, we could set the hostname, just to be able to find out quickly on which host we are at the moment:

I hope you know any console-based text editor because now we are going to use one. It will be vi. If you know nothing about vi, go study it on Wikipedia, it is time to grow up.

...Several hours later...

Open the SSHD (D — stands for “daemon”) config file like this:

Edit Port option to move SSH daemon from the standard 22 port. Unless you want to face some bruteforcers, but the bandwidth is money, you know. In my case, I have picked 44227, but you can choose one between 1025 and 65535. Specifying something out of this range could (and for sure will) make your server inaccessible over SSH, so be extra careful.

Next, allow only the second version of the protocol, as it is more secure:

Disable plain password authorization. Since that you will only be able to get authorized with your private SSH key, so look after it well, better even copy it to some USB stick.

And finally, disable root SSH login at all: with a password or with a key, does not matter. Dont worry, you still will be able to startrootsession viasu root`.

Done editing the file: exit the editor and reload the sshd:

And now exit the session:

Now try to login with our myapp user:

Worked? It should have. But in case you cant login, go to the terminal with our “backup” root session and re-check the config file.

As a bonus, you may add some handy aliases to .bashrc file on your dev machine:

This is for “fast” login and for file transfers over scp.

# Step 4: Firewall

Remember we have switched off the firewall? Right. It is time to turn it on back. There is a frontend to iptables, called firewalld. We are not going to use it. Instead, we will look under the hood an see how iptables actually works.

Next thing we are going to need is server WAN interface and its IP address — the network interface which server uses to connect to the outer world and its IP address. How to find out:

The output would be like this:

On a simple VDS you will see only two records. This first is your loopback interface which is always present, and the second one is for sure our WAN interface. If you have more than two interfaces in the list, please, consider asking your hoster support about which one to use. In my case, it is eth0, with the IP address 173.20.88.42. Please also keep in mind, that WAN IP and external IP are not always the same!

So, let`s check again the situation with firewall by typing

It still should display the empty list of rules, where the “accept” policy is turned on by default. Now, we are going actually to add some rules. Here is the listing, read the explanation inside:

Place this listing in the file called /root/iptables.sh (by using vi or scp), make it executable:

And, eventually, execute the file:

Are you still with me? Do you have your SSH connection safe and sound? If not, you screwed up with the file. No worries, just go to the control panel and restart the server. After server restarts, all rules should become empty again. Then you fix the file and re-try.

You can check if all the rules are there, by running one more time:

As soon as you are happy, we need to make these rules permanent. Do:

This tool will allow us to controll iptables in a service manner. Then write the current rule table into the config file:

And finally, start the iptables service:

This will make sure your firewall is up and running, with everything applied as requested.

At this point, we exit root session and log-in under our myapp user. It is time.

# Step 5: NodeJS and NPM

There are options… We can install nodejs + npm globally, so, for the entire server we will have the same nodejs version. In general, this is not quite a brilliant solution, as soon as you want to run several nodejs applications. Another option could be to install nodejs locally for each user (one user — one application, remember?) We will consider both ways.

First, we need to pick the right version of our nodejs. It is very tempting to deploy the latest, fancy, bleeding-edge version available. But this is not going to work in the real life. In the real life, we face a lot of outdated, yet useful packages and frameworks, which are mandatory in the everyday life, but refuse to work on newer versions of nodejs. As an example, the recommended version of nodejs for Meteor 1.5 is… 4.8.6 or around that version. Having in mind the current stable version is 9. Life is hard.

Also, we can install nodejs in several different ways: install with yum, install some pre-built executable and even build it from source. We are going to use the second option. We go to https://nodejs.org and pick the right binary for our architecture.

Now, to install globally:

Or, to install nodejs locally for myapp user:

Now to check the executable, re-login and test:

Worked? Good. We are half-way there.

# Step 6. MongoDB

Now it is time to set-up our MongoDB server. Nowadays, everywhere we hear the modern “microservices” and “PAAS” terms, so, for MongoDB, there are also options. We could use any MongoDB PAAS, which offers really fancy infrastructure, backups, scaling, sharding, monitoring and profiling out-of-the-box, but, unfortunately, not for free. For an established project this option is preferable, but at the beginning, you are probably not even close to 10% sure the project you have built will gain some profit. So I hope you are as greedy as I am because now we are going to install MongoDB locally.

As a good start, I offer you to look at the documentation on the official website: https://docs.mongodb.com/manual/tutorial/install-mongodb-on-red-hat/ It is short, easy and sound.

As soon as you are ready, start the server:

But not so fast, always mind the security, mister. First of all, lets set up the database password. Start the mongo shell, let`s create some user credentials.

First, create the administrator:

Then, create a regular user to manage our project database. Let's name the database after the project — myapp:

Of course, use your own, randomly-generated and long passwords here.

Now exit shell:

Now edit mongod config file here: /etc/mongod.conf

Modify the block of settings in the following way to enable security:

Reload the mongod service:

By the way, the database connection string in your application will look like this:

The last thing we for sure will do —we open the database to the outer world. It could be useful when you need to make a quick look at the production database with your desktop client, but we need to make some precautions.

There are two ways of acheive this:

1. Expose the database to the WAN directly, or…
2. Make a SSH tunnel.

We are going to discuss both.

# Exposing mongodb to WAN (option one)

We are going to need to know the IP address of your computer. Sounds a bit scary, doesn't it? How to find out (in case you don't know): google the phrase “my ip address” and enter the first website, for example, http://www.myipaddress.com/show-my-ip-address/. Let's assume your address is 213.71.25.78

Next, add the following rules to the iptables:

Reload iptables when done. Make sure the rules took effect.

After that, let's edit mongod config file here: /etc/mongod.conf

Modify the block of settings in the following way:

Where 173.20.88.42 is, as you remember, your WAN IP address. What is going on here? The bind_ip option contains the list of IP addresses our mongod binds at. Currently, both loopback and wan interfaces are allowed.

Reload the mongod service:

Please note though, your IP address is not static. It will alter every time you move from one wifi spot to another, when you restart your router, laptop and so on. So actually you may consider this only as a temporal measure. The more advanced option could be is to establish a SSH tunnel to your server.

Never ever leave your mongodb exposed to the outer world and unprotected with a password! One day some other guy will for sure get that IP address you allowed, and then… probably nothing will happen until your project is enough popular. But you got the idea, right?

# SSH tunnel (option two, better)

The disadvantages of the previous method are obvious: it has weak security level, you need to update the firewall configuration to update the IP address frequently and so on. So, let me show you how we can make use of SSH in order to make a safe connection to our database. I assume now you got rid of all the changes made during the discussion of the first option, and reloaded the server. Now, let`s execute the following command:

What does it do?

First, it connects to our server by SSH with our private key. Then it makes a tunnel to our mongod server running on the remote localhost at 27017 port, establishes a local server (on the dev machine) and keeps running in the background. Now we can connect to our database as if it is running on our local machine, by typing:

Note, that now the port is not 27017, but 27018. Everything you send to this server, automatically goes to the tunnel and then to the mongod server running on the production, safely and secure! Magic.

I also offer you to make use of some cool GUI tool to manage your databases, instead of typing mongodb commands in the terminal. Such software usually supports a lot of handy features, including SSH tunneling in particular.

# Step 7. Domain name

Let me provide you with a brief instruction about how to buy a domain name for your application, and set it up. Four simple steps:

1. Go to your favorite domain name registrar and buy the domain you liked. In our case, I assume, the domain will be myapp.com.
2. Now you need to “place” this domain on a DNS server, which will be responsible for the domain in future. It is called “to delegate the domain”. Usually, it can be done through registrar's interface on their website.
3. You need to set up a so-called A record, which allows to map your domain name to the IP address of our server. In our case, to 173.20.88.42.
4. Wait till your update is spread across the whole DNS system. It can take up to 72 hours, but it never took more than a day in my case.

As always, there could be complications. By default, the domain will be delegated to the registrar's server. But some services do not provide the ability to set up A record for the domain for free. Instead of paying money to them, you could try and delegate the domain to the DNS server of your hoster, and probably there you can do it with no extra charges (you already paid them for VDS, what else do they need, huh?).

If you feel confident and brave enough, you can even set up your own DNS server, make it responsible for a zone of your domain and delegate the domain. But, as you understand, it will require extra work and involves higher responsibility…

# Step 8. Nginx

Let's install Nginx. That one is easy.

Now we are going to customize it`s config file a bit. Actually, we will replace it completely.

Here is the contents of the config file:

We will manage virtual hosts in the Apache way: we create a separate file for each new application, having it inside /etc/nginx/sites-available/, then creating the symbolic link to /etc/nginx/sites-enabled/. Cool, huh? Let`s do it.

Now we create the file inside /etc/nginx/sites-available/ called myapp.conf:

With the following content:

What is important here for us? As you can see, we declared actually two servers. The first one accepts connections with the insecure HTTP to the domain itself or to its ugly dwarf twins and redirects everything to the canonical https://myapp.com domain. The second server describes so-called reversed-proxy pass which basically dumps all the incoming traffic to our Meteor application, which, in order, hangs on the loopback interface, being inaccessible externally. This approach is called “to use Nginx as a frontend”.

In this case, Nginx also takes care about TLS, so you don't need to set up any certificates on the level of Meteor application itself. Also, note the port number in http://localhost:11001 — you are going to make use of it later.

So, at this moment we create a self-signed TLS certificate. No worries, it is just for testing.

Then we activate our virtual host:

And reload Nginx:

Hopefully, you will not see any errors.

Checking! In your favorite browser, type http://myapp.com If you got redirected to https://myapp.com, you see Nginx Bad Gateway 502 error and the browser started to complain about the invalid certificate — you are on the right way. Great. Now we get a valid certificate.

# Step 9. TLS

Instead of buying an expensive commercial certificate, we are going to satisfy our needs with the free one, put in use the famous letsencrypt.com service. So, first, install the software:

Then we create folders which will help us to pass the challenge and save the princess. “What challenge, dude? What princess?” — I see your question. Well, you need to prove that you own the domain you are going to protect with a certificate, that is why certbot places a special file, which should be correctly served by Nginx so it becomes accessible from outside.

Now try to obtan the certificate:

If it says the dry run was successful, repeat the same command without the dry-run option. Hopefully, you will find your certificate at /etc/letsencrypt/live/myapp.com/. In case of any problems, don't force the certbot to execute the command multiple times: if you fail 20 attempts in a row, you will end up banned for 1 hour.

The last thing: go to the Nginx virtual host config file

Remove lines for the self-signed certificate, and un-comment lines for the real one. Reload Nginx:

Go to https://myapp.com. Hopefully, you can see the browser now treats your certificate as valid, green and happy.

You think we are done? Not so fa-ast! The certificate issued by Letsencrypt stays valid only for 3 months (or so), that is why we need to make it auto-renewable. Remember we installed cronie before? Right. Start the root session (you are going to need your root password here):

Now edit root's crontab:

And place the following there:

This will run the renewal request every day at 5 am and, 3 minutes later, reload Nginx.

Now it is done.

# Step 10. PM2 and Deployment

Guys, we are almost there! Now it is time to find out, how we are going to deploy the application itself!

First step: on the server we install pm2 — the advanced process manager for launching nodejs applications. It provides a lot of features, you are going to like it.

Now go to your local machine, and install there pm2-meteor — a version of pm2 made specially for Meteor.

Open the folder with your app, for example:

We are going to create the deployment settings folder there:

Just like npm or gulp or other similar software, pm2-meteor uses special .json file to keep the configuration. We either generate this file with

Or we can write it manually. Here is the example:

Let's discuss important parts here:

1. env.ROOT_URL — this is our domain with https attached.
2. env.PORT — the application TCP port to bind at. Remember the config file of our nginx proxy-pass? Yes, the same number here.
3. env.MONGO_URL — the connection string to our local MongoDB server
4. server.host — WAN IP address of our VDS
5. server.port — SSH port
6. sever.username — the application user
7. server.deploymentDir — our project root folder on the server
8. server.pem — the path to your private (not public) SSH key on your local machine (this one is used to make a connection when deploying)

In addition, if your server has several cores (a good server should have more than one), we can set server.exec_mode to “cluster_mode” and specify the number of cores with server.instances. It will allow us to run several instances of the application an balance between them.

Now the deployment is simple like never. At the same folder just type

At the end of the process, go to the server and type

You will see your instances up and running. Finally access your application at https://myapp.com. It`s alive… ALIVE!!!

You can view the console output of your application by typing

# Step 11. Autorun

Last step, guys! We need to make sure our application starts automatically after the server gets restarted. Forget about forever and stuff like that, with pm2 it is very easy to achieve:

PM2 is smart enough to detect we are using Centos and that SystemD is available. SystemD is a special mechanism that helps to control applications. After this is done, open the file:

And remove the following line:

It should not be there, this is a bug in PM2 service file generator.

Guys, an important remark, while you are still here. If due to some reason you decided not to use PM2 for the deployment process, and instead decided to deploy by hands (still possible yet more complicated): do not forget to set NODE_ENV to “production”. By not doing so, when typing ‘npm install’ you will add a lot of packages which are meant to be used only in the development environment. For example, babel, mocha, gulp and other packages could be installed. Moreover, in the ‘development’ mode some packages can have severe security and performance issues, so be careful.

The easiest way to set the variable is to execute the following command, being logged in under myapp user:

and then relogin\restart the server. In case of using PM2, it will set up NODE_ENV automatically inside the SystemD service file.

# Conclusion

Well, that is basically all. Pheeew… That was a long one. We have gone from the top to the bottom, reviewed the entire process. Now you know how to make use of the Meteor application you wrote. Further improvements could involve, for instance:

1. Make use of Docker
2. Implement continuous integration with Travis or Jenkins
3. Set-up the production of daily backups
4. Configure integration with services like Prerender, to make your app crawlable

Thanks for reading, guys, have fun!