Unsucking Create-React-App Deployments

So you want to deploy a create-react-app? Cool throw it in an S3 bucket. But wait, you want to put it behind a domain name? Okay well set up Route53 and then mount the bucket. Hold on, what about SSL certs? And auto-invalidations on deployment? And setting up QA environments for your testers?

30 hours later…

Every time I deploy a CRA app, I end up using the same deployment scripts and npm script hacks. They’ve become so universally used on my teams that every stack starts with copying and pasting those command and scripts into a folder. So I thought… why not share it with the world!

ENTER…. stackpack

Stackpack is dev-dependency (or global) that you can throw into your CRA or serverless express.js lambda (soon) or express.js Beanstalk (soon) and it will create an opinionated DevOps setup for you in minutes.

Yeah. Prototype to multi-env setup in minutes.

How does it work?

Stackpack abstracts out lots of the AWS cli commands and provides you with basic templates that connect Cloudfront, S3, Route53, etc. All you have to do is run npm run deploy:develop and it will build and deploy your changes to S3 and invalidate your cache. If you use Gitlab’s runners, you can also just hit npm run git:develop or git:qaand it will commit your changes, merge up a branch in GitFlow, and tag the right version number on master.

But this seems very opinionated… why?

Because most frontend developers trying to do DevOps on their own don’t actually care. They want it to work in production, and they want it to work today. That’s why my teams have used it, and that’s why we liked it. Quick, easy, replicable deployment. All of our environments follow the same basic gitflow and deployment principles:

1. Git commits must go from Feature>Develop>QA>Staging/Demo>Production
2. All apps are rebuilt entirely in uniform docker containers during deployment. This applies from CRA to Lambda to backend to Python scripts, etc. We trust NO local environments.
3. We use the same tools for almost everything (node, React, Redux, AWS etc.). Common stack means no DevOps headaches every time a new stack gets added.

So that’s the “why.” Let’s get into the what…

The Tutorial

First setup a create-react-app

npx create-react-app awesome-app
cd awesome-ap
touch .env
npm start

Now let’s install the stackpack library

npm install --save-dev stackpack

Let’s use the default S3 Cloudfront SSL based template…

stackpack init s3-cf-https

# if you are using gitlab runners: 
stackpack init s3-cf-https-gitlab 

…and make sure we have the right git branches set up to use our version of git-flow.

git init; git branch develop; git branch qa; git branch staging;
stackpack init gitflow;

Now open up package.json to make just couple config edits.

FIRST: Setup the domain name you want to use for this app in route53 and add it to "domain":"www.example.com" . In this example, I’ve used www.awesomeapp.com. Subsequent environments will be referenced as develop-www.awesomeapp.com or qa-www.awesomeapp.com. These are the domains that you are allowed to point to from Route53 to the respective CloudFront domain endpoint.

SECOND: If you have an SSL certificate in AWS, replace the default in the stackpack settings like"ssl":"arn:aws:acm:us-east-1LXXXXXXXXXX". Otherwise, just delete the ssl property.

THIRD: If you want to use a different AWS IAM user to deploy that isn’t just your default, then replace "profile":"default" with the right profile name. This is helpful for using Gitlab runners with a separate AWS profile. For security, we set up a restricted runner profile for every stack with limited permissions.

FOURTH: If you don’t want to use CloudFront on every environment, you should remove those environment names from the cf_envs array. This array must be a subset of the environments array. These endpoints will be exposed without https and may have some hiccups, just FYI.

Next, we’re going to initiate some templated CloudFront configs. HINT: You can update these in the .stackpack/ to customize them, then run stackpack cf update to push the changes to AWS.

stackpack cf setup

Which should run and then show you…

Refreshing local Cloudfront configs…
   refreshing… develop
   refreshing… qa
   refreshing… staging
   refreshing… prod
   Refreshing and Creation is complete.

Now you are ready to deploy!

Really. I swear.

There are npm scripts that have been added that you can use to do these things together. But we’re going to take it one step at a time.

stackpack build --env develop;
stackpack deploy --env develop;
stackpack cf invalidate --env develop;

The build step runs react-scripts builds . The deploy step moves it to the S3 bucket. The invalidate step runs a generic /* invalidation on CloudFront.

Annnnnnnnd you’re done.

Feel free to comment, below! Next up in the stackpack lineup, I’m going to deploy a Razzle app serverside app via Lambda and some hidden serverless magic.

That’s it. Just one EASY function. And put it on Lambda, behind a gateway API call. But AWS-lambda has this nasty quirk that native code modules need to be compiled in the exact same environment. I was using Claudia.js (while I had many options) to automate the upload to AWS. Claudia is great because it also handles the API-gateway creation.

But, despite all the magic of Claudia.js, I kept getting the bug:

{
  "errorMessage": "/var/task/node_modules/webworker-threads/build/Release/WebWorkerThreads.node: invalid ELF header",
  "errorType": "Error",
  "stackTrace": [
    "Module.load (module.js:487:32)",
    "tryModuleLoad (module.js:446:12)",
    "Function.Module._load (module.js:438:3)",
    "Module.require (module.js:497:17)",
    "require (internal/module.js:20:19)",
    "bindings (/var/task/node_modules/bindings/bindings.js:76:44)",
    "Object.<anonymous> (/var/task/node_modules/webworker-threads/index.js:1:105)",
    "Module._compile (module.js:570:32)"
  ]
}

Even dropped it on stackoverflow: http://stackoverflow.com/questions/43690371/can-i-use-webworkers-in-aws-lambda-node-6-10

Which is where I learned of AWS’s issue with native compilation. If I compile a module locally (on OSX) and then use claudia or even manually load the package, the native modules (node-gyp in my case) will be compiled against OSX and included as a local package. Womp womp.

Solution? Create an exact(ish) match of the AWS-Lambda env locally and compile the code and THEN load it to AWS. Simple enough, right?

Wrong. Wrong wrong wrong wrong.

I’m still somewhat of a Docker noob, but the published containers out there were very unfriendly in their documentation even for a senior dev. A lot of trial and error was required. Many diet cokes died to bring you this solution.

I’m using my AWS-Lambda MultiEnvironment structure (see https://medium.com/@james_mtc/automating-lambda-across-multiple-environments-50f47fbf393d)

In my case, the “natural” module is the one that did me in because it uses node-gyp. First thing we’re gonna do is create a Dockerfile

This Dockerfile uses the LambCI lambda image, but with the node 6.10 build. Drop in your ENV AWS keys. Then it goes to root, runs npm install and then run claudia update. The command in package.json looks like:

claudia update --cache-api-config

And because I hate running the same commands over and over again as I test out the deployment, here’s my bash script to automate the process

Whatevs. Doesn’t matter. This tutorial will help you unsuck the Github Jenkins multiple private repository disaster.

Now I’ve done this now multiple times. But every single time I did it slightly differently and ended up breaking it. This last time, I wrote down instructions for myself. But they seem worth sharing.

Why?

Github does not allow the same deploy key to be used in multiple repositories. So if you want to deploy two or three apps or repositories to the same machine, you have to come up with some SSH / RSA trickery.

For more info, see:

• Error: Key already in use - User Documentation
• Using the same deploy key for multiple github projects

Assumptions:

• LAMP stack (for config)
• Config through .conf files
• Node.js service running on something other than port 80
• Github.com for private repositories
• Standard Jenkins install with a “jenkins” user
• SSH and root access to your deployed machine.
• Jenkins is running on the local deployed machine (obviously not true, but I’m gonna skip the scripted SSH crap)

You are adding an app to a subdomain to www.example.com.

1. SSH in to the target machine.
2. Make the directory

mkdir var/www/html/sub1.example.com

3. Go and edit the .conf file. Probably already have one as 000-default.conf. Copy that and save it as example.com.conf

vim etc/apache2/sites-enabled/example.com.conf

4. Add the following

<VirtualHost *:80>
  ServerName sub1.example.com
  ServerAdmin webmaster@localhost
  DocumentRoot /var/www/html/sub1.example.com/public_html/
  <Directory "/var/www/html">
     AllowOverride All
  </Directory>
  ErrorLog ${APACHE_LOG_DIR}/error.log
  CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

5. Restart and then sudo in as jenkins

sudo apache2 service restart
sudo su jenkins
cd ~/.ssh/

6. Should now be in: var/lib/jenkins/.ssh

7. Create the new key pair

ssh-keygen -t rsa

8. When prompted, name the key “sub1-rsa”

9. After completing the creation, copy the blob from sub1-rsa.pub

10. Copy the blob and paste it into the deploy keys set on github. For example, this would be at https://github.com/MYNAME/sub1.example.com/settings/keys

11. Edit the ssh config file under jenkins

vim ~/.ssh/config

12. Add the following to the config. This shortcuts any ssh command to use a particular key when going to the listed host. It “tricks” github into a separate key with a nonsense github subdomain.

Host sub1.github.com
    HostName       github.com
    User           git
    IdentityFile   ~/.ssh/sub1-rsa
    IdentitiesOnly yes

13. Now to test it. Run:

ssh -T sub1.github.com

This should use the “fake” host of sub1.github.com and then go to github.com and swap in the sub1-rsa key to make the call.

14. Nowcd /var/www/html/sub1.example.com

15. Git and pull the repository.

git clone git@sub1.github.com:MYNAME/sub1.example.com.git

16. Boom, now you have a git folder inside that can be run and SHOULD be run by the jenkins user.

17. Rename the folder to public_html

18. Inside jenkins, check the “github Project” box and put in the name of the repository https://github.com/MYNAME/sub1.example.com/

19. Under source code management, select git. Then add repository url: git@sub1.github.com:MYNAME/sub1.example.com.git

20. Select “Build when a change is pushed to GitHub”

21. Execute Shell script will look something like this

cd /var/www/html/sub1.example.com/public_html/
git pull