Over the past month, I started rebuilding the Raspberry Pi Dramble project using Kubernetes instead of installing and configuring the LEMP stack directly on nodes via Ansible (track GitHub issues here). Along the way, I've hit tons of minor issues with the installation, and I wanted to document some of the things I think turn people away from Kubernetes early in the learning process. Kubernetes is definitely not the answer to all application hosting problems, but it is a great fit for some, and it would be a shame for someone who could really benefit from Kubernetes to be stumped and turn to some other solution that costs more in time, money, or maintenance!
I run dozens of websites, and help build and maintain many others. Almost every one of these sites is served on a server in one of the giant regional data centers in New York, Atlanta, Seattle, LA, Dallas, Chicago, and other major cities in the US and around the world.
These data centers all share some very important traits that are key to hosting high-performing, highly-available websites:
- Power redundancy (multiple power feeds, multiple backup power sources)
- 1 Gbps+ upload/download bandwidth (usually with many redundant connections)
- 24x7 physical security, environmental controls, hardware monitoring etc.
When I choose to host the Raspberry Pi Dramble website in my basement, I get almost none of these things. Instead:
The Raspberry Pi Dramble (which powers www.pidramble.com, run from my basement!) has been featured in a number of videos lately:
- Ansible 101 - on a Cluster of Raspberry Pi 2s
- Nginx Load Balancer Visualization on a Raspberry Pi Cluster
- Ansible + Drupal: A Fortuitous DevOps Match
- Ansible Serial/Forks Demo on a Raspberry Pi Cluster
The Dramble was even featured on PCWorld's 2015 list of Insanely Innovative and Incredibly Cool Raspberry Pi projects!
As most web developers have over their careers, I've often spent time researching different low-priced web hosting companies in search of a better plan than the one(s) I'm currently using.
Every year or two, I like to get a good overview of different hosting providers' VPS performance, and from time to time, I move certain websites and services to a new host based on my results.
In the past, I've stuck with Linode for many services (their end-to-end UX, and raw server performance is great!) that weren't intense on disk operations, and Hot Drupal for some sites that required high-performance IO (since Hot Drupal's VPSes use SSDs and are very fast). This year, though, after Digital Ocean jumped into the VPS hosting scene, I decided to give them a look.
Before going further, I thought I'd give a few quick benchmarks from each of the providers; these are all on middle-range plans (1 or 2GB RAM), and with the exception of Linode, the disks are all SSD, so should be super fast:
I've seen a ton of iptables configurations on the Internet, and none of them really got to the heart of what I need to do for the majority of my LAMP-based web servers (hosted on Linode, HostGator, Hot Drupal, and elsewhere). For these servers, I just need a really simple set of rules that restricts all incoming traffic except for web (port 80/443 for http/https traffic), ssh (usually port 22), smtp (port 25), and icmp ping requests.
The script below (save it as 'firewall.bash',
chmod u+x it to make it executable, and run it with
$ sudo /path/to/firewall.bash, then test your server (access websites, log on to it from another Terminal session, ping it, etc., and make sure that's all working)):
I got an email from HostGator yesterday alerting me to some really awesome deals for their web hosting services; for Cyber Monday, they're giving half off pretty much all their hosting plans:
- Shared hosting: As low as $4.95 Now only: $2.48
- Reseller Hosting: As low as $24.95 Now Only: $12.48
- VPS Hosting: As low as $19.95 Now Only: $9.98
- Dedicated Servers: As low as $174 Now Only $87
I've been using HostGator for a few of my less-trafficed websites for over three years now, and have had less than 10 minutes of measured downtime. I also use a cheap shared hosting plan to simply store backups of my other sites (they give you limited SSH access to cheap plans—which is awesome!).
I highly recommend HostGator; unlike most other low-cost hosts, their support team is top-notch, their plans are priced perfectly, and their servers (even for cheap shared hosting) are super-fast, compared to other hosts I've used (1&1, GoDaddy, Dreamhost, etc.).
For some of my Drupal sites and PHP scripts (and shell scripts) that I run on a VPS I manage, I need to simply be able to send outgoing emails from arbitrary email addresses. I could go into all the details of DNS SPF records and MX records here, but that's something you'll need to research on your own. This post simply shows how to install and configure sendmail on a CentOS box to just allow outgoing mail from php's mail() function, the mail command line utility, etc., and only from localhost (127.0.0.1):
First, install sendmail with
$ sudo yum install sendmail sendmail-cf.
Then, configure sendmail by editing the file
/etc/mail/sendmail.mc (don't edit the sendmail.cf file - we'll auto-generate that after setting things correctly in sendmail.mc).
I've spent a lot of time working on making sure my smaller Drupal sites (mostly run on shared hosts or very small VPSes) run lean and mean. This helps the pages load faster, users are happier, and my hosting providers don't have to shut down any of my sites, even when they're under pretty heavy load.
Here are my three recommendations for making your Drupal 7 website run great on a shared (or low-end VPS) host:
Initially, when thinking about finally taking the plunge and purchasing a slice or two from Slicehost, I thought, "wow, this is going to be incredibly fast and awesome, compared to my Host Gator account!"
But, after setting everything up and putting Open Source Catholic live on the fresh slice, running
free -m, and looking at the results, reality set in: 256 MB of RAM is not much to work with if you're running a Drupal site on a LAMP stack! Drupal usually consumes 15-40 MB of RAM per page view for a logged-in user, and if you have a site with 10 or so logged in users at any moment... well, bad things can happen.
For anonymous users, using Boost will help your site fly no matter the amount of RAM you have. But even so, a bunch of requests to uncached pages will cause your site to load a heck of a lot slower, and will fill up your RAM faster than a fire hose fills up an 8 oz. glass!
Using default Apache, MySQL and PHP settings, free -m showed a full 250 MB of RAM used, along with 400-500 swap space used (swap should be kept to a minimum—if you have a lot of swap usage, that means the hard drive is being used instead of RAM, and the hard drive is inherently many times slower!). After performing a few quick modifications to Apache and MySQL, I was able to get this number down to 140 MB RAM / 40-60 MB swap, on average.