Sunday, April 24, 2016

OWASP Training @ PluralSight

Sat through the OWASP Top 10 training this Thursday. What's sad is how little heart & soul today's devs put into their work. Simple, assumed items like security fail to make it in the appa they build simply b/c they are told to do it. 

When interviewing devs, understanding their development philosophies are critical to know the way they code. Without knowing their personal coding integrity, you're risking a lot.

Thank you Troy Hunt for bring more exposure to security and its importance.

Further use of Octopus Deploy

 Off-loading steps from TeamCity to Octopus... aka: right tool for the job.

After almost daily use of Octopus, I'm finding it to be indispencable (sp), but still nowhere near as mature as TCity. Paul and his team are very active on the project and I'm glad to have convinced our company to purchase the 60 nodes/$2k version of Octopus.

One disappointment is that a Slack step keeps failing to use Slack's API, failing the deployment... causing my team to look no so good, at a critical time in the formation of it. Now, I had to change all Slack notifications to be sent from TeamCity. Really nbd... but still a PITA.

Octopus is now executing PM2 Delete & Start on each deployment (vs. relying on the --watch switch)... this solves several problems for managing the app environment, but I still need to take it a step further by assuming nothing is installed on the Linux instance -- leads to SALT perhaps.

The above addition allows for changes to be made on an environment agnostic level... the Octopus changes also updated to allow for dynamic args to be sent to "start" per environment -- which is great for the devs and testing.

One note: When using bash scripts, Octopus has a difficult time deciphering encrypted Octopus variables... but no trouble when transforming files (during deployment).

Wednesday, January 27, 2016

PM2 - Setup

Recent changes to the project now have it completely running under Node/Express/PM2. Details of the change(s) should be posted on the project's WIKI, but I thought it important enough to share what I've learned. This link was very helpful to get started. When adding the application to PM2, the following line is used to register/start the application: (THIS ONLY NEEDS TO BE RUN ONCE. There is an entry in /etc/init.d that will run the PM2 Daemon on server startup) pm2 start server/app.js –u app-www --watch --name app -- --app http://################### Let's break it down (now):
  1. "pm2" : The name of the cool Node Management platform that "on-the-fly" devotes resources to the given apps.
  2. "start" : Creates a new application
  3. "server/app.js" : The location of the main application .js
  4. "-u app-www" : The user to run under. We don't want PM2 to run as ROOT for security purposes, especially on port 80 or 443.
  5. "--watch" : Vital and saves each deployment from having to restart the application on each deployment. This is newly in place and still being tested. I originally thought it best to send a command after deployment was complete (and still do) but this may be just as good, and baked into the functionality of PM2.
  6. "--name app" : Force the name of the application (there could be many, but not in this current case). It's possible to run multiple applications under the same PM2 umbrella.
  7. "--" : Tells PM2 that everything after is a parameter to be sent to the Node Application
  8. Everything else, see below.
app Node Options: -a, --app path to app [string] [required] -c, --crt path to crt* [string] -k, --key path to key* [string] -d, --debug enable debug [boolean] NOTE: When this is enabled, the site will run on Port 8080 -h, --help Show help [boolean] *Required to run site under SSL.