Welcome to my journey where I’ll share my experiences and thought process as I work towards deploying this blog to production.
Initial Plan #
When I started this project, I had a clear path in mind, even though I anticipated encountering some gaps along the way. Here’s what I initially planned:
- Find resources to guide me on deploying my blog online.
- Decide on the domain name for my blog.
- Choose the cloud provider for hosting.
- Prepare everything required for deployment, including static content, setting up a Github repository, and tying up loose ends.
- Define success as making the content publicly available.
Getting to Work #
I first thought about researching how I could deploy a statically generated site and making it publically available, but realized I was missing a step. I needed to first select my cloud provider and determine my domain name.
I made the decision to use Amazon Web Services (AWS) because I was familiar with a few of their core offerings, and there was a lot of other services that sounded like they could be useful.
For naming my domain, I knew I wanted to include my handle, but had not figured out what I wanted to use as the Top Level Domain. I narrowed down a list that sounded pretty tech focused after looking for some inspriration online.
Since I needed to purchase a new domain, I thought about doing so from AWS’ Route53. It took me a bit, but I eventually found a list of TLDs that could be used for domain names and were available for purchase. There was only one problem: the TLDs I had wanted to use were unavailable to be purchased from AWS. I didn’t think it should pose too much of an issue as I should just have to find the correct domain seller and import the domain to be provided by AWS instead. At least, was my understanding as I read some docs from Route53 about transferring domains into the service.
Little did I know that this was not going to be the case, and that it was going to be the tip of the iceberg for this project.
Browsing around the internet, I found the TLDs I was interested in from SquareSpace. I created an account and purchased my domain easily. I quickly accepted terms and conditions, validations, and verifications from different emails, and shortly after, I had received the notification that my domain was officially ready for use. Time for me to figure out how to import a domain into Route 53 like I had read about.
I logged into AWS Console and went into Route53. I found they included a wizard that could assist me with importing my newly purchased domain. I typed in my domain in to check if it was available for import, and received an error: The TLD specified is not supported. Not supported?
In my confusion, I decided to look closer at some of the other docs. Surely I couldn’t have made a mistake in my understanding of them?
Oh, but I did.
In another part of the documentation, I missed a section mentioning to ensure the TLD being imported was compatible with Route53’s approved list. Since the TLD I was attemping to use was not supported by AWS, I could not complete the transfer. Effectively, the domain I purchased was useless. Luckily, I was able to refund my purchase without issue.
So I looked at my list of desired domains once more and realized none of them were available in Route53. I pulled back up the list of approved Route53 TLDs, and decided that .codes is the closest thing to what I wanted. I then proceeded to step through the new domain purchasing wizard from AWS, and was well on my way.
Next I needed to figure out how to deploy the supporting infrastructure for my application. One of the resources I found previously said that I could use Cloudformation and that AWS had some docs to use that service to deploy a static site, so I decided to give it a go.
Inside the docs, there was a section that mentioned that you can use a prebuilt template to deploy some basic infrastructure for this usecase. It included a couple of S3 buckets, Cloudfront to act as a Content Delivery Network (CDN), a certificate to be able to serve your traffic over HTTPS, and a few other pieces. This all sounded good to me, so I ran the provided template.
The S3 buckets, Certificate Manager, IAM role, and a couple other pieces were Created and Running without issue, but I was still missing a few other components per the deployment. After several minutes had passed, I saw that the certificate request was still CREATING. Maybe I was getting a bit impatient after what happened earlier over the domain name combined with my excitement to get things going. 10 minutes go by with no changes. 15 minutes. 20 minutes…
My certificate was still stuck pending CREATING. I looked at the event logs and tried to reference other insights into the object creation that I could. But I couldn’t see anything and later discovered that the template did not enable logging and debugging capabilities.
So I tore down that deployment, and attempted it again since I read somewhere that it takes some time for some of the intermediate services to register your domain as being successfully validated. However, I was met with the same results as before. The process was still stuck on creating my certificate.
I was now at the next hurdle to decide how I wanted to proceed. I had one thing clear in my mind at this point: I wanted to get away from automating and managing as much of the underlying infrastructure as possible. This led me to discover an AWS service I had not heard of before: Amplify. Amplify even had a section on how to deploy a Single Page App (SPA) and static websites using it. I decided to try it out.
Getting Amplify setup and interfacing with my private Github repo was straightforward, but when I got to the build process section, I wasn’t sure how to proceed as I was using Hugo to statically generate my blog. A quick Google search showed me I needed to make a few alterations to the starting build template to use Hugo instead.
After making the changes, I kicked off a build. One of the first steps the taken was to generate the SSL/TLS certificate like earlier. I admit I got a bit nervous, but when I saw the process succeed, I felt confident that things were going to work out this time. I honestly have no clue what was different regarding the process used in Amplify versus Cloudformation, but hey. I’ll take a success at this point.
Next, it triggered a compilation of my content using Hugo. The build failed. The Hugo template I have chosen, Blowfish, was not supported with the version of Hugo built into Amplify’s service by default. I wondered how I could configure the version of Hugo being used.
Back to the internet I went searching for a solution. I eventually came across this Github Issue that described the issues I was facing. Luckily all I had to do was do a package version override for Hugo.
A quick change of the config and my website successfully built from start to finish, and was ready for serving. Although I had reached my point of success for this effort and couldn’t be happier, I wanted to make sure I captured some items to take into my future work.
My Key Takeaways #
- I need to approach unfamiliar problems more methodically.
- Reading documentation carefully is essential and can save a lot of time in a lot of instances.
- Expanding my understanding of networks beyond my developer perspective is crucial for future projects.
So I leave you all with this in mind:
Remember, in the ever-evolving world of technology, the journey never truly ends. Stay curious, stay humble and keep coding on.