You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+159-4
Original file line number
Diff line number
Diff line change
@@ -1,10 +1,10 @@
1
1
# sails-react-bootstrap-webpack
2
2
3
3
[](https://app.travis-ci.com/github/neonexus/sails-react-bootstrap-webpack)
NOTE: You will need access to a MySQL / MariaDB database for the setup. If you want to use a different datastore, you'll need to configure it manually.
20
20
21
+
[Aiven.io](https://aiven.io) has FREE (no CC required) secure MySQL (5 GB), and Redis (1 GB). Both require use of SSL, and can be restricted to specified IPs. (If you are having trouble finding the
22
+
FREE instances, you need to select Digital Ocean as the cloud provider.) Use my [referral link](https://console.aiven.io/signup?referral_code=mk36ekt3wo1dvij7joon) to signup, and you'll get $100
23
+
extra when you start a trial (trial is NOT needed for the free servers).
If you would like to use [`sails-hook-autoreload`](https://npmjs.com/package/sails-hook-autoreload), just install it: `npm i sails-hook-autoreload --save-dev`. The config
531
538
file [`config/autoreload.js`](config/autoreload.js) is already pre-configured for this repo.
532
539
540
+
## Getting setup remotely
541
+
542
+
There are a lot of ways to go about remote deployments; many automated, some not so much. For the sake of argument, let's say you want to set up a remote server by hand. It would be nice if said
543
+
server (or servers if behind a load-balancer), could do a `git pull`, `npm install`, and an asset build if need be `npm run build`. It would also be great if you could see the progress, or even
544
+
just the console of the Node server.
545
+
546
+
That's what the [`self-update.sh`](self-update.sh) and [`tmux.sh`](tmux.sh) shell scripts are for. Note, they are both defaulted to `bash`, but should work just fine in `zsh`.
547
+
548
+
### What is TMUX?
549
+
550
+
In simplest terms, TMUX is a "terminal multiplexer". It lets you switch between programs in one terminal, detach them (they keep running in the background) and reattach them to a different terminal.
551
+
552
+
In other words, it adds a lot of magic to the terminal. One of the most useful things, is being able to run programs in the background, but still being able to see the console output later (as
553
+
it is still running). It runs on most Linux-y distros, including macOS.
554
+
555
+
[Check out their "Getting Started" docs](https://github.com/tmux/tmux/wiki/Getting-Started) for more on what you can do.
556
+
557
+
To install (remember: on the remote machine, not your local machine), it's most likely `sudo INSTALLER install tmux`. Amazon Linux is `sudo yum install tmux`, Ubuntu is `sudo apt-get install tmux`.
558
+
559
+
### A simple walkthrough for a self-updating VM
560
+
561
+
For this guide, I'm going to be using Amazon Linux as the basis; it's a great default if using AWS. However, most of these steps can easily be adapted.
562
+
563
+
It should also be noted, this is by no means the only way to set up remote servers; nor is it a thorough guide. This is just a quick-n-dirty, get off the ground running without a lot of tooling, kind
564
+
of guide. There are PLENTY of automated deployment managers and documentation out there. This is fairly open-ended; it is assumed you know how to do a portion of basic remote server management.
565
+
566
+
#### Getting Started
567
+
568
+
Spin up a new instance at the smallest size possible (as of this writing, `t4g.nano` is the smallest) and SSH into it and follow along.
569
+
570
+
#### Lack of Memory
571
+
572
+
While the smallest instance size will certainly not have enough RAM to support an asset build, it is plenty for running our Node server.
573
+
574
+
To make it so the instance CAN handle an asset build (despite its lack of memory), you'll want to create a swapfile. I use 4 GB swapfiles, as that seems to be more than enough head-room for asset
575
+
building, however, you can most likely get away with just 2G.
576
+
577
+
First, create the file, and allocate the space:
578
+
```shell
579
+
sudo fallocate -l 4G /swapfile
580
+
```
581
+
582
+
Make it readable / writable only from ROOT:
583
+
```shell
584
+
sudo chmod 600 /swapfile
585
+
```
586
+
587
+
Make it a proper swapfile:
588
+
```shell
589
+
sudo mkswap /swapfile
590
+
```
591
+
592
+
Tell the OS to actually use the swapfile:
593
+
```shell
594
+
sudo swapon /swapfile
595
+
```
596
+
597
+
Edit the `fstab` table to make this swapfile permanent:
598
+
```shell
599
+
sudo nano /etc/fstab
600
+
```
601
+
602
+
Add this to the bottom of the `fstab` and save:
603
+
```shell
604
+
/swapfile swap swap defaults 0 0
605
+
```
606
+
607
+
#### Get the basics installed
608
+
609
+
Now that we have the lack of memory issue dealt with, let's get the 3 bits of software installed that we for sure need: `git`, `node` and `tmux`:
610
+
611
+
```shell
612
+
sudo yum install git nodejs tmux
613
+
```
614
+
615
+
#### Setup server to be authenticated for `git pull`
616
+
617
+
This is going to assume you have a repo setup with GitHub, but the keygen is pretty much universal.
Save it as a ["deploy key"](https://docs.github.com/v3/guides/managing-deploy-keys/#deploy-keys). (Or however you need to save it in your repo to allow `git pull` on the remote server).
630
+
631
+
#### Clone your repo
632
+
633
+
Now that you have the server's public key saved in your repo, you should be able to clone your repo on the remote server:
Now, you'll want to `cd myapp`, and `npm install`.
642
+
643
+
Now, before you can actually start the server for a dry-run, you need to decide how you are going to store the server's credentials (user/pass for datastores and the like). It is recommended you use
644
+
the [environment variables](#environment-variables), but it is also possible to run the [interactive setup](#interactive-setup), and generate a `local.js`.
645
+
646
+
#### Give it a spin
647
+
648
+
You should now be able to `sudo npm run lift:prod` (recommended for all remote environments, even DEV). `sudo` is needed on Amazon Linux, because it required ROOT permissions to open ports.
649
+
650
+
If everything is working as intended... congrats (or so you thought)! Now that you have everything working; it's time to get the server to update / rebuild / start itself.
651
+
652
+
#### Final stretch
653
+
654
+
Now you need to decide how you are going to have the `tmux.sh` script run on startup. The easiest way would be to just install `cronie`:
655
+
656
+
```shell
657
+
sudo yum install cronie
658
+
```
659
+
660
+
Enable the service:
661
+
```shell
662
+
sudo systemctl enable crond.service
663
+
```
664
+
665
+
Start said service:
666
+
```shell
667
+
sudo systemctl start crond.service
668
+
```
669
+
670
+
Now edit the `crontab` to run the script at `@reboot`:
671
+
672
+
```shell
673
+
@reboot cd myapp; ./tmux.sh
674
+
```
675
+
676
+
#### Have you tried turning it off and on again?
677
+
678
+
```shell
679
+
sudo reboot
680
+
```
681
+
682
+
Now re-login to the instance. You should be able to `tmux attach` and see the Sails console.
683
+
684
+
#### Now save that image!
685
+
686
+
Now you should create an AMI from that server. You should be able to terminate the running instance, and spin up a new one using your new custom AMI, and everything should just work.
687
+
533
688
## What about SEO?
534
689
535
690
I recommend looking at [prerender.io](https://prerender.io). They offer a service (free up to 250 pages) that caches the end result of a JavaScript-rendered view (React, Vue, Angular), allowing search
0 commit comments