Prior to the switch over for the new site, the old was hosted through ImpDesigns which is a full-service graphic and web design shop in Raleigh, NC. It was my first job out of college and they were gracious enough to let me host my creations on their server for free. It was my first jump into utilizing ExpressionEngine and managing my own host including it running a MySQL database.
Over the years, through the different startups I worked for, I learned other technology of the industry and found tools that did a lot of the heavy lifting for me. I found that I did not want to be a server admin, as I used to host and manage other websites I created for people. This time around I wanted to keep hosting simple and of course at a minimum cost.
GitLab
Starting off, I knew I wanted to do a static website where I generated the code locally and pushed up to the server. Github had always offered their own version of simple hosted pages of static HTML, but in order for a private repository, I would have to shell out money every month. Luckily, GitLab offers the same service, but with free private repositories and much more — I haven’t quite figured out what the exact limitations of all the free aspects of the service.
Not only do I get a CI/CD runner, but I can also use my personal domain in conjunction with the GitLab.io domain. All of this requires just a little bit of setup, and here is how to do it.
You get a continuous build system, for FREE
One thing that blew my mind with GitLab is that they offer a CI/CD service out of the box for completely nothing. This means that you create a simple config file based on their requirements, merge your code into master and each build runs the script to deploy or do whatever you need the CI to do.
I use the CI system to build my Hexo blog and subsequently deploy it to the GitLab Pages setup. The script is very straight forward. By creating a .gitlab-ci.yml file, the simplest of setups includes:
1 | image: node:7.2.1 |
2 | pages: |
3 | cache: |
4 | paths: |
5 | - node_modules/ |
6 | script: |
7 | - npm install hexo-cli -g |
8 | - npm install |
9 | - hexo deploy |
10 | artifacts: |
11 | paths: |
12 | - public |
13 | only: |
14 | - master |
Node image
Make sure to use the most recent NodeJS image or at least the same one you use on your local build. Doing this, allows you to not run into any deployment issues you don’t encounter locally when building. When I first found the setup script, they suggested to use Node v 4.2.0. Unfortunately, I have been utilizing ES6 in my Hexo blog for some of the layout items and data querying. ES6 support was not introduced until Node v 6. Needless to say, when I first deployed to GitLab, I would get errors and build failures due to this.
Pages runner
The pages runner section is what does all the heavy lifting allowing the code to be deployed on a master branch merge. After the script section runs, the cache is important to keep the build time down. The first run gathers all the required node packages and then ultimately caches them for subsequent runs. All files generated by the Hexo deploy line are ultimately uploaded to the public directory for the GitLab Pages.
Setup the Page
The GitLab page gives you a GitLab.io namespace based on your GitLab username to point your projects: USERNAME.gitlab.io/PROJECT. I did not have any other projects and also wanted to use my personal domain I already owned. This required a little more setup on my end to get it working correctly.
In order to get the root domain of USERNAME.gitlab.io to point directly to my blog, I had to create a GitLab group with the same name as the url of my page and add my repository, which I also named the same, to it. For example, @sloan.gitlab.io would be the group name and then selected the repository sloan.gitlab.io to be attached to the group. Now, when going to https://sloan.gitlab.io, it points directly to my blog.
Adding my personal domain to point to the GitLab page was the next step. Adding the domain in the settings/pages page is very straight forward. The only thing extra to do was to make an SSL certificate.
Adding the SSL Cert
To keep in line with my personal blog being as low cost as possible, but yet also play nicely with modern browsers and the security settings they have, I needed an SSL certificate. I decided to go with Let’s Encrypt which is a free SSL cert tool, the only downside is it expires every three months.
Luckily, there is a GitLab NPM package that makes generating the keys super easy. gitlab-letsencrypt makes generating the key very straight forward. All you need to do is make sure you have a GitLab personal access token prior to use.
1 | gitlab-le \ |
2 | --email me@email.com \ |
3 | --domain mydomain.com \ |
4 | --repository PROFILE/PROFILE.gitlab.io \ |
5 | --token ACCESS_TOKEN |
After running that, it will upload a key for it to access and check to make sure you have access to the repository, then spit out the SSL certificate keys for adding to the domain.
Finally, the DNS
If you have control of your domain through a name host, then adding the DNS records will be your next step so that it points to the GitLab servers. The following is all you should need to hook it up properly to the IP address of GitLab 52.167.214.135.
1 | A Record | @ | 52.167.214.135 |
2 | A Record | www | 52.167.214.135 |
3 | URL Redirect | mydomain.com | https://mydomain.com |
4 | URL Redirect | www.mydomain.com | https://mydomain.com |
After the newly updated DNS propagates, you should be able to visit your personal domain and see your newly minted GitLab page!