Johnathan.org

Showing only: vps

An Auto-deploying Static Site with Backend

I have some nostalgia for static sites. I first learned to write any kind of code with HTML on a Packard Bell 486. I was hooked.

Fast forward a couple years and I was creating HTML sites in Allaire HomeSite (which became Adobe HomeSite and eventually Dreamweaver… R.I.P. HomeSite). It wasn’t long before I discovered CMSes–PostNuke, PHPNuke, TextPattern, MovableType, WordPress–I loved them all. Over the last half-decade though, WordPress was where I settled. The thought of going back to a static site was intriguing and I even tried it once, but I just couldn’t get it to stick.

Fast forward to now, where I’ve thrown WordPress to the side for a static option. I wrote this post to discuss my motivations behind it, especially after talking about–at length–why I left Ghost.org for WordPress.

Moving Parts

Beyond all else my primary motivator was complexity. As much as I’d like to think this would change, I don’t blog often, nor do I have a highly complex blog that requires a lot of input by multiple people. Naturally, one might think about going to a hosted solution like WordPress.com or Squarespace. Both were options I toyed with in the past and turned down as serious options.

WordPress.com costs more money than I think it’s worth and Squarespace isn’t blog-centric. It’s a great product and you can build awesome sites that have blogs as a component, but it just doesn’t have that “this is your place to share your thoughts” vibe I’m looking for. Beyond that, I have almost 300 posts (it used to be closed to 340, but I purged a bunch that were so out-dated and broken it wasn’t worth saving them) and I didn’t feel like that much imported content is something SquareSpace could handle well.

This led me to self-host WordPress. I enjoy setting up and maintaining servers as much as the next person, but my bill was higher than it was worth. I had deployed two DigitalOcean droplets, one for the database and one for the web server. At $20 each, (4GB ram, 80GB SSD) it was getting pretty pricey. I could have scaled down and even put both functions into one server, but even then I wouldn’t have felt comfortable spending any less than $20.

I would vouch for Digital Ocean all day long, though. They’re great people to work with–I know at least one of them personally–and their UI is prefect for my needs.

I had to really think about my plan. If I was going to go back to static, I needed to pick a tool that I wouldn’t end up hating six months from now. My answer was actually several tools.

The Toolkit

I came up with three pieces to complete my static site solution:

  • Jekyll: it’s Well-known and something I’m very familiar with.
  • Circle CI: making sure what I’m pushing is legit and let me auto-deploy… no more git hooks)
  • Forestry.io: I like using editors as much as the next guy but if I have something I want to write about, taking the extra steps to push it up to GitHub isn’t going to cut it for me.

Jekyll

Jekyll seemed like a no-brainer. Hugo was out of the question because I didn’t want to learn something new and others just weren’t full-featured enough. With my passable ruby and liquid knowledge, I could manipulate Jekyll to do what I want and not want to give up and throw it all away.

Circle CI

Circle CI came late in the game. I was originally going to use Netlify to deploy and host my site but I didn’t like how little control I had. Yes, it’s free as in beer, but I didn’t have any kind of insight as to the performance or overall control. Beyond that, deployment took longer than I wanted, primarily because it spends time at the final stages checking the HTML for forms it needs to process and understand. Given that I have over 300 pages–probably more than 400, actually–that was a non-starter. I’d probably use Netlify at work, but not for this project.

By having an CI tool at the ready, I could have it build the Jekyll-based site for me, check the HTML for obvious problems, then push it to my server (in fact that’s what it does–minus the HTML checking part, that’s not ready).

Forestry.io

Forestry.io is a tool I never heard of until a few weeks ago. It syncs with the GitHub repo that stores my site and allows me to create posts and pages, manipulate front matter templates, and do some basic media uploading. It’s not perfect, and on rare occasions it trips GitHub’s API rate limiting, but it’s been pretty solid overall. Support is good, and the free tier does exactly what I need it to, nothing more.

Performance

With these three tools in play, I have what amounts to a static site-CMS hybrid. When I click Publish on this post, Forestry will push it into my GitHub repo. From there, Circle CI will trigger when it sees a change and run my build script. The last step of that script is to rsync the built HTML site over to my server.

On my server, I have Nginx serving the pages with some effective caching and it’s smooth. By extracting WordPress and it’s PHP+MySQL clusterfest, I’ve also been able to improve load times both in the context of first-byte and the entire page.

My PageSpeed and YSlow scores are better than they used to be when running WordPress. There’s room for improvement but overall, it’s turning out pretty well when I consider the fact that I haven’t gone out of my way to make them great.

One thing I really need to work on, though, is my Lighthouse performance. This is what I would say is going to be the successor to PageSpeed. It’s really tough on sites and my performance as it’s measuring is dismal. Some of that might be the extensions Chrome is running and removing them speeds things up a bit, but I definitely have some front-loading I need to do of critical CSS and moving the rest to the back.

Overall, though, I’m happy with how things are operating. Forestry is fast, the whole thing can be done for $5, and I can feel good knowing that my site can’t be taken over thanks to a vulnerability in WordPress.

Linode vs Digital Ocean: A Three-Round VPS Benchmark Showdown

A few days ago, Digital Ocean announced new pricing tiers for their VPSes (affectionately called Droplets). I’ve been a fan of Digital Ocean’s offerings for a long time. Compared to other popular VPS provider Linode, there seemed like there was only one choice as Digital Ocean’s pricing ran 2x for almost everything.

Now that they’re the same price, I think it’s about time they faceoff in a set of sysbench benchmark tests.

(more…)

My Overloaded Server Story

So as you probably know by now, I converted my blog to Jekyll, yesterday, and it’s been a huge success, in my opinion. I’m motivated more than ever to start blogging more because I have the added tinker factor and using Git and GitHub to keep everything organized rocks.

But that isn’t what this story is about. Tonight’s story is about a server. A lowly VPS floating somewhere in the SFO DigitalOcean…. ocean. I’ve had this server running for many months–probably over a year now and I just don’t know it–and it’s hosted just about anything and everything I’ve tinkered with including many a failed idea.

I use this server a lot and for the most part it always responds well and isn’t sluggish. It’s hosted my former WordPress blog since January and hasn’t made but a peep about it so I’ve spent quite a bit of time thinking nothing’s amiss. I felt, though, that Jekyll shouldn’t be taking as long as it was to build my site but I couldn’t convince myself the server was overloaded.

As it Turns OutTM, I was wrong.

My baby of a server has, for the last five or so months, been filling Newrelic graphs with stuff like this:

CPU

loaded_server_before_cpu

Memory

loaded_server_before_mem

Disk

loaded_server_before_disk

Load

loaded_server_before_load

So I’m just going to go ahead and say that’s not good. The only graph above that’s even remote decent is the Disk graph, but it’s washed over by the CPU > 80% indication so it’s also pretty much hosed.

At this point I’m honestly surprised. I’m a terrible pseudo-sysadmin and I should be fired but there’s no one to fire me and I’m the boss so whatever. If I can fix all this, I’m giving myself a raise.

I started digging. I wanted to see what’s running and who’s sucking up all the juices. I fired up top and waited a few seconds. A few things popped up: a couple instances of node and an instance of ruby.

Hmm. That doesn’t make any sense… I’m not running any node apps and jekyll is the only ruby thing I use right now… oh wait.

See, I tinkered with NodeJS apps late last spring. Ghost was a blogging tool I was considering for a while. I also tinkered with Discourse to see what it was all about. Turns OutTM, neither are suited for my needs.

I don’t really know what happened but I can only assume I forgot about them and they’ve been running all this time. I had a total of five Node instances running and Docker was running Discourse so between the two of them, I was on swap 24/7. So dirty.

This story isn’t super climactic in any way and the fix was easy: kill all the things. I also found this to be a good time to remove Node and Docker since I need neither.

I still couldn’t figure out why my disk usage was so high, though. Leave it to me to forget about a 4GB .iso I left in a folder and leave it to Discourse to fail at sending 5GB of emails through postfix over the last five months and clog up my /var/mail folder. Needless to say, after the almost-winter cleaning, I gained quite a bit of ground:

CPU

loaded_server_after_cpu

Memory

loaded_server_after_mem

Disk

loaded_server_after_disk

Load

loaded_server_after_load

Sorry this story wasn’t more interesting. If you’re curious, my Jekyll build time was cut in half.

That’s about it. Orphaned tools and processes makes my server a dull VPS.

Johnathan Lyman
Kenmore, WA,
United States
 
blogging, design, technology, software, development, gaming, photography