So, in the last post, we finished setting up the infrastructure for our blog. In this post, we’ll deploy our blog to our server and make our blog live!

The idea here would be to do all this within the User Data Script, which is executed when the EC2 instance is initializing. We’ll write a shell script with all the required commands and run it with the User data script. Here are the things that need to be done to make our blog live:

• Installing a webserver to recieve traffic from the load balancer and setting it up with required configuration.
• Installing git (although its likely be present in the distribution already).
• Installing Hugo all the required dependencies.
• Fetching our blog to our server and set it up.

Installing nginx and git is straighforward, but apt generally has older versions for hugo. So its better to get hugo source/binary from the releases on github. We will also need to add the theme(s) that we have used in our blog.

#installing required packages
apt update
apt install -y git nginx
wget https://github.com/gohugoio/hugo/releases/download/v0.68.3/hugo_0.68.3_Linux-64bit.deb
dpkg -i hugo_0.68.3_Linux-64bit.deb 

mkdir -p /var/www/devopsdiary/themes
cd /var/www/devopsdiary/

#clone your blog
git clone -o StrictHostKeyChecking=no git@github.com:krishh-konar/my-blog.git
git clone https://github.com/jpescador/hugo-future-imperfect.git themes/hugo-future-imperfect
git clone git@github.com:martignoni/hugo-notice.git themes/hugo-notice

#generate static content in the ./public folder
hugo 

Now, since my blog is a private repository, it cannot be directly cloned here. If your blog is public, you can ignore this step. All we need to do is add the public key of the key-pair we used to create our instance as a deploy key in our blog’s repository. This will allow us to clone the repo in our EC2 instance. Once done, we run hugo, which generates our generates our blog in the ./public folder. The final step to make our blog live is to add a server block in nginx to serve our blog.

server {
    server_name devopsdiary.tech www.devopsdiary.tech;
    root /var/www/devopsdiary/public/;

    listen 80;

    index index.html;
    error_page 404 /404.html;

    #redirect http to https
    proxy_set_header X-Forwarded-Proto $scheme;
    if ( $http_x_forwarded_proto != 'https' ) {
        return 301 https://$host$request_uri;
    }
}

#setting up nginx
cp /var/www/devopsdiary/nginx.conf /etc/nginx/sites-available/devopsdiary.conf
ln -s /etc/nginx/sites-available/devopsdiary.conf /etc/nginx/sites-enabled/
systemctl restart nginx

And with that, our blog is live! Now only one thing remains, that is updating your blog on the server automatically after you’ve pushed changes in the repo. Here’s where things get complicated. Ideally you might want an instant reload to reflect all the changes as soon as possible, and that would require some additional setup. I decided to take the easier option though, and that is using a cron that runs every 15 mins. A simple shell script for updating the blog is given below:

# update-blog.sh
# checking if the repo has been updated
cd /var/www/devopsdiary/
git checkout master && git fetch
if [[ $(git rev-parse HEAD) == $(git rev-parse @{u}) ]]
then
    git pull origin master
    hugo
    #optional notification to slack after update
    curl -X POST --data-urlencode "payload={\"channel\": \"#alerts\", \"username\": \"blogbot\", \"text\": \"Blog updated!.\"}" https://hooks.slack.com/services/<webhook-id>
fi

Now, finally adding the cronscript in the User data file

crontab -l > /tmp/cron.tmp
echo "*/15 * * * * /bin/bash /var/www/devopsdiary/update-blog.sh" >> /tmp/cron.tmp
crontab /tmp/cron.tmp
rm /tmp/cron.tmp

This concludes setting up our blog on an AWS EC2 instance.

A few final thoughts: There are much better ways to do this. Instead of a cron running, we can have another small webapp running which can listen for requests and reload our blog as soon as we push changes to out github repo with github webhooks. We can even go serverless and use s3 bucket to host our blog and update it using Jenkins/CircleCI or any other continuous integration tool. Maybe I’ll try some of these methods some other day… But this works for now.