Forem: Douglas Rogers

Heroku vs DigitalOcean: Deploying to Heroku

Douglas Rogers — Wed, 20 May 2020 10:30:00 +0000

FINALLY deployed to Heroku!!!

The Experiment’s Table of Contents

Part 1: An Experiment in the Making

Part 2: Getting Started with DigitalOcean

Part 3: Handling Redirects with DigitalOcean

Part 4: The Experiment Continues

Part 5: Deploying to Heroku

I’ve gotten a few requests to hurry up with this experiment. It’s been a while…I know. But finally…I’ve done it: I’ve deployed my personal portfolio to Heroku successfully!

If you don’t already know, Heroku is an ephemeral PaaS. Again, I’m a front-end guy so that statement is foreign language to me. Ultimately, it means that while it allows you to deploy a website onto the platform, it does not give you full hosting like say DigitalOcean or MediaTemple. You have to figure out database and image management yourself. They do have a ton of add-ons (which we will get into later) that can aid in this process. However, if you are not careful the cost for these addons can pile up quickly. Heroku offers a free tier so that you can test. You get 1,000 dyno hours per month. Be careful because that is a 1,000 dyno hours a month for ALL free applications under your account…not 1,000 per application.

Considering this is a portfolio site and I’m not famous (…yet) traffic to my portfolio is abysmal. Keeping my portfolio on Heroku’s free tier doesn’t seem like a huge issue to me. I have the ability to add a custom domain to the site. The only challenge is that free dynos do not stay woke. Meaning after 30 minutes of inactivity, it goes to sleep and has to be re-awaken. That re-awaken period can take a second for visitors. There are methods to make sure your dyno remains on but…that’s for another post. Also, going to a paid tier allows me to add a SSL certificate to the domain.

Going back to my list, my next steps were as follows: — Find a cloud database solution — Install Perch’s Cloudinary Template filter onto the site — Connect Github and Heroku — Deploy site to Heroku

First things first, I had to create a Heroku app. There are a few ways to make that happen. You can do this the Matrix Way (aka command line) or the WYSIWYG Way (aka Heroku’s dashboard). I wanted to feel like a super backend developer so I opted the Matrix Way. I followed the instructions for the PHP setup since the site is ran on PHP but built using NodeJS.

Note: When running a site on Heroku with PHP, you have to have a composer.json file. My file is completely empty considering I don’t have any PHP dependencies on the site. The file still is needed as it indicates that you have PHP site that needs to be built. This is Heroku’s attempt at a zero configuration set up.

By the end of the instructions, you’ve got your site up and running…but I still needed to add NodeJS to my build since I don’t ship any destination files via Git. I won’t lie: THIS PART KICKED MY BUTT. After a lot of testing and experimenting, I finally wrapped my head around adding a new Buildpack and was able to get my site built and deployed properly to Heroku.

Next, it was time to get a database together. Remember those addons I spoke of? Well, Heroku has a bunch of them to help you out in this department. I ended up using ClearDB for the database. I opted to leave my WordPress instance out of the Heroku part of the experiment. We’ll talk more to that in the final post.

Next, was the images that get uploaded to Perch. All of my portfolio screenshots are uploaded via the backend of Perch. So what I needed as a way to easily host these images. Heroku does have addons like Cloudcube and HDrive but I wanted something a little more easy and cheaper. I landed on Cloudinary as my cloud asset host. You can see more about my decision in my previous post. I did chose to scrap Perch’s Cloudinary Template filter. I found one but decided against using it and just simply used the Autoupload method of getting images into Cloudinary.

The last part to figure out was how to get environment variables to point to the database. On DigitalOcean, I could simply upload a config.local.php file to my site that was not kept inside of Git. Heroku doesn't have an FTP option so I was left with their config variables in the app settings. This feature was pretty nifty since now all my private data is left outside of Git and still accessible to the app.

After figuring all the above out, I must say…Heroku is not that bad. Figuring all this stuff out is a pain in the butt. However, once you get it down, it makes for a great and cheap alternative to traditional hosting for sites that don’t receive a lot of traffic.

And that’s it folks. I’m going to sit on this site for a little bit. I would love fabricate some traffic to the site to see how it handles it. That way I can experiment with scaling the site up. Let me know in the comments if you guys would like to see a video version of this experiment that walks thru all the steps and my thought process.

Disclaimer: Some of the links provided in this article are referral links where I get bonus time on the services if you click and sign up.

Heroku vs DigitalOcean: Handling Redirects with DigitalOcean

Douglas Rogers — Tue, 17 Dec 2019 20:24:54 +0000

I asked for total control and I got total control. One of the first issues I came across was that my site was no longer reading my .htaccess file. I had all these lovely redirects for previous blogs, non-www traffic, etc. Welp…all gone. I was so used to MediaTemple handling that for me. Well, those days are gone now that I’m on DigitalOcean, or at least until the end of my 30 days are over.

I had to get my hands dirty if I wanted to get my redirects back in order. That meant turning to DigitalOcean’s documentation. Apache does not allow .htaccess files to override things out the box. Not sure why. I’m sure it’s a good reason but that reason is beyond me. Again…I’m not a DevOps guys. You can do this one of a few ways: via the command line or FTP into your Droplet and navigate to /etc/apache2/apache2.conf. I chose the latter. But also not that you STILL will need to access your Droplet via command line so that you can restart Apache and enable mod_rewrite.

Towards the bottom of apache2.conf you want to add the following:

<Directory /var/www/html/>
    AllowOverride All
</Directory>

Save this out, turn to the command line if you are not already there and SSH into your Droplet. You’re going to need mod_rewrite so that WordPress can use permalinks and various other reasons. To enable mod_rewrite insert the following after you’ve logged into your Droplet via SSH:

sudo a2enmod rewrite

You can run sudo apache2ctl configtest to ensure that you haven’t made any syntax errors. You should see Syntax OK. If you see the following, that’s fine:

AH00558: apache2: Could not reliably determine the server’s fully qualified domain name, using 127.0.1.1. Set the ‘ServerName’ directive globally to suppress this message

If you want to suppress this message, we will need to open the main configuration file:

sudo nano /etc/apache2/apache2.conf

At the bottom of this file you will need to add what’s called a ServerName directive pointing to your domain (or IP Address if you have not set up your domain yet).

ServerName replace_this_with_your_server_domain_or_IP_here

Save and close the file when you are finished. You can re-run sudo apache2ctl configtest and you should not get that long message above Syntax OK.

Last but not least, restart Apache.

sudo systemctl restart apache2

Pretty intense, right? Well, that was just the beginning. You still have to add rules to 000-default-le-ssl.conf if you installed a SSL Certificate! Like I said before: if you are scared of the command line or running things yourself, run away!!!

Navigate to /etc/apache2/sites-available/000-default-le-ssl.conf in you FTP client or open it up in the command line by typing sudo nano /etc/apache2/sites-available/000-default-le-ssl.conf. We want to add rewrite rules in here. You could enable .htaccess files and do it that way but since I have control over config files, I figured I’d do it this way.

RewriteEngine On
RewriteCond %{HTTP_HOST}   !^www\.example\.com [NC]
RewriteRule ^/(.*)         https://www.example.com/$1 [L,R]

Replace example.com with your own domain. If you are looking to use a non-www URL for your site, remove the www from the block above. Save the file and restart Apache.

sudo systemctl restart apache2

Again, not for the faint at heart. If you are having issues yourself, I suggest you refer to DigitalOcean’s amazing documentation for more help.

Where do devs go online to chat?

Douglas Rogers — Thu, 12 Dec 2019 18:08:32 +0000

Aside from Twitter and Reddit, where else do developers to go chat? I've realized that I've just been in my own bubble, pounding away at my keyboard and I have not made many developer friends/buddies/communities. I have a few developer coworkers that I chat with from time to time. But where else is there for us to go to connect with one another?

Twitter contains so much noise that it's difficult to facilitate a conversation. Places like Reddit and Hacker News, to me, foster a bunch of bullies waiting to tell you that your post sucks or for moderates to delete your post because you said "I" too many times.

Are there Discord channels? Slack channels? IRC Chatrooms? (FYI: I've NEVER got a chance to learn IRC)

Lets discuss.

Heroku vs DigitalOcean: Getting Started with DigitalOcean

Douglas Rogers — Fri, 22 Nov 2019 14:41:35 +0000

The Experiment’s Table of Contents
Part 1: An Experiment in the Making
Part 2: Getting Started with DigitalOcean

The reason I'm getting started with this project is because I ran across this Chrome extension that does a variety of audits on your websites including SEO, security and performance. I got a 35% in the security department. While trying to figure out ways to increase that score, I realized how little I was able to do that with my MediaTemple GridContainer. I contacted MediaTemple to ask how I could alter the httpd.conf file and they told me I didn't have access to the root because I was on shared hosting. Unacceptable.

Between DigitalOcean (I will refer to DigitalOcean as DO from here on) and Heroku, DO is definitely the platform that gives me the most control over my server. As I mentioned in the previous post, DigitalOcean is an IaaS, so they give us a server and leaves it up to me to decide upon and make use of other software to setup, interact, maintain and deploy code to the server. If I want a LAMP stack, then I must decide what version of Ubuntu to use, install Apache, setup a firewall, install MySQL, install PHP and its various components and PHPMyAdmin.

Luckily, DO provides great documentation to help you get off the ground with all of this. I had no problems following the steps and had my server up and running with in x. If working in the command line gives you the heebie jeebies, then first off you may not want to explore this project. You will be all up and through the command line working with DO so just stay away. Secondly, DO makes it easy for you by providing one-click apps that have a variety of pre-configured applications for you to use, including LEAN stack, WordPress, MongoDB and PHPMyAdmin. The command line makes me feel like I'm in the Matrix so I'm starting from the bottom floor of it all and installing every single thing by myself.

DO has superb documentation on how to do everything from creating your first Droplet to installing Linux, Apache, MySQL and PHP on on Ubuntu. I decided to run with Ubuntu 16.04.3. DO has version 17.10 available but after some research, there wasn't much of a difference and the documentation uses 16.04.3 so I kept it that way for consistency. I'm not going to get into too much details of my set up because it was pretty basic for setting up this experiment. I figured that I'd start low and scale up if I need to, which DO makes possible.

The one challenging part that I came across was installing PHP packages. I had to do a little digging on what packages would be necessary for WordPress as a base to start off with. My logic was if I start there I would have a solid foundation. But if anything breaks…meh, it's my site. For those looking for this answer, these are the PHP packages I ended up installing:

php7.0-cgi
php7.0-cli
php-dev
php-all-dev
php7.0-mysql
php7.0-xmlrpc
php7.0-curl
php7.0-gd
php-apcu
php-pear
php7.0-pspell

Make sure that you are using PHP7 or else you'll need a different set of packages.

Once I was done with installing all those packages, I moved on to database management. I was going to use PHPMyAdmin but figured I could rely on good ole' Sequel Pro. That would be one less thing I have to install and secure. Just note the MySQL Host and SSH Host are your Droplet's IP Address and Sequel Pro automatically checks for the usual location ~/.ssh for SSH Keys. If you have it in a custom location, you'll need to point Sequel Pro there.

From Sequel Pro, I created a database user and created a database for WordPress and Perch. Note: if you want to connect to Sequel Pro with that new database user, the Username and Password is the new database user's name and it's password while the SSH Host and SSH User is still the root server user. In the tutorial, it recommends you create a different server user than root and I recommend you use that server user. I know…that's a tad confusing but it will make sense once you go thru all the documentations. I may just create a separate post.

After the database was all ready, I uploaded my portfolio. I was met with this initially:

At this moment I'm thinking "OMG!!! What is happening?!?!"
It took me a minute to discover the "How To Install WordPress with LAMP on Ubuntu 16.04" for some reason (read: I discovered it a while ago but did not follow the instructions) and that left me in the dark about enabling .htaccess, mod_rewrite, and disabling indexes. I figured it out eventually (again…followed the instructions properly) but it was painful before discovering that tutorial.

After pulling my hair out and downing a bottle of whiskey, I finally had my portfolio up and running. Then I turned my attention to the WordPress blog. Let me say this: No one probably visits my WordPress blog. It is the first version of Standing Dreams and was like a music/lifestyle blog and my portfolio. BUT, for the purposes of this blog series, I wanted to maintain it and see what it takes to move from one service to the next.

I got my portfolio up. I got my blog up. Now it's time to move on to the big move. I had to wait a few days because my domain was with Media Temple and I wanted to move it to Google Domains. After getting all that situated, it was a pretty easy move. I was able to install my Let's Encrypt SSL Certificate relatively easy as well. With Media Temple, I had to go thru a crazy process to install a SSL Certificate from Let's Encrypt. They also would not allow me to auto renew this SSL Certificate so every 90 days I was renewing my SSL Certificate.

So far, so good. I definitely have full control over my server. I will keep you guys updated with challenges I face over the next few weeks.

Heroku vs DigitalOcean: An Experiment in the Making

Douglas Rogers — Fri, 15 Nov 2019 03:36:24 +0000

The Experiment's Table of Contents
Part 1: An Experiment in the Making
Part 2: Getting Started with DigitalOcean

I have been a loyal customer of MediaTemple for years. They made my hosting needs extremely easy. I loved the customer service. I hosted sites for friends and family with ease. I just loved it.

However, as I got further into my development career and wanted more, I felt my tier was very lacking. I was paying $20 a month for a GridContainer. While it served my basic needs, it left me with no access to the root where all the fun happens. Being a true tinker, this was unacceptable. At the company I worked at, we use Heroku and DigitalOcean on a few sites. I loved features that came with Heroku but I loved the control that came with DigitalOcean.

Like any great developer, I turned to Google for some good comparisons between DigitalOcean and Heroku. I found a few blog posts and Quora posts but nothing answered my questions exactly. I wanted someone to spell it out for me. You know…make my life easier. Isn't that what Google is for?? Since I couldn't find the answers, I figured I'd do a little experiment to answer my own question. Plus it gave me a chance to play with new stuff. (TOYS!!!)

Heroku is a PaaS - i.e. Platform as a service, letting you run apps on their platform their way. DigitalOcean is an IaaS, or Infrastructure as a Service, which gives you raw servers to compose as you want to run your app. The differences are mainly around pricing and control vs effort.
An answer on Quora by Russell Smith

For starters, I am not a DevOps guy. I'm a front-end developer with some backend chops. I have worked in both, DigitalOcean and Heroku, before but it was like someone's grandmother poking around an iPhone: slow and cautious with lots of questions and fear I would burn the internet down with every click. I do know that Heroku is a PaaS (Platform as a Service) and DigitalOcean is a IaaS (Infrastructure as a Service). The comparison between the two only comes up because people rely on both in some capacity for hosting for some sort of site, web app or API. However, because they are basically different, there are less solid answers as to which you should turn to when you're looking for a new hosting solution.

SO here we are! My goal is to take my portfolio that is ran off of Perch CMS and a legacy WordPress blog, host them on both services for one month each and record my findings. AGAIN…I am by no means a DevOps guy. I will be depending the services' documentation, customer service reps, StackOverflow and Google for all of my needs. Since I have credits with DigitalOcean (and because my coworker called heads for DigitalOcean on a coin toss), DigitalOcean will be first up.

I'll simply post findings, frustrations, tip and tricks, rants and raves about my experience for the next person that is looking at Heroku and DigitalOcean for their hosting needs.

Wish me luck. 👍🏾