We can install awscli command line tool using pip. We get a permission denied error. Let's use sudo to install it. We can see it is installed. We have to configure the awscli tool before we can use it. You need to provide your AWS access key id and AWS secret access key. Now we can use awscli to configure our domains. The aws command takes the aws service as the first argument, then the command we want to run.
In this case, we want to create a hosted zone for www.clickplan.net. We need to provide a unique caller reference that includes timestamp to recognize this particular command. The output JSON shows the name servers that is assigned to our domain. You can see the caller reference that we provided as the command line argument. We had to create the hosted zone for this domain. Because, clickplan.net domain was registered at namecheap. If you had registered the domain at Amazon, they will automatically create the hosted zone records. We need to copy the hosted zone id under the id: hosted zone entry. We can now list all the resource record sets for this particular hosted zone id. The output shows four resource records for name servers, the domain name and the time to live value. We also see one SOA entry record for this particular domain.
We can also list all the hosted zones in our account by using this command. You can see that there are two domains, clickplan.biz and clickplan.net. We see the caller reference we provided here.
You can login to the AWS console to see the results of running the command. You can see there are two domains, same as the command line output we just saw. We can see the details of the hosted zones such as name servers also here.
Deploying the Rails app to elastic beanstalk is covered in another episode. Let's use AWS CLI to point www.clickplan.net to the Elastic beanstalk URL. Therefore, instead of hitting the URL production.xyz.region.elasticbeanstalk.com in the browser to access the Rails 5.1 backend app, we can use www.clickplan.net.
The documentation is confusing because things are spread across different guides such as Route53, Beanstalks etc. It is also confusing due to two different hosted zone ids. The hosted zone id for www.clickplan.net is different from hosted zone id for the AliasTarget. The AliasTarget hosted zone id value is the same as the region where you deployed your domain. In my case us-east-1 is the region where I deployed clickplan.net using Beanstalk.
We create a JSON file that provides the values for the action, domain name, the type of record, and the hosted zone id of the region where beanstalk instance is deployed. We also need to provide the beanstalk instance URL in the dns name.
Let's create A record for the clickplan.net backend Rails API only app. We can run this command and provide the path to the JSON file. The status is pending. You can check the status by running this command. We provide the change id we got from the output of the previous command. The output shows that the status is INSYNC, which means Route53 has completed it's job. It will take some time to propagate the changes. Wait for a few hours for the DNS resolvers and servers to pick up this change.
You can use the dig command to check if the changes has propagated to all the DNS servers. You can see the question section for clickplan.net A record. The answer section shows two entries in the A record. Each entry has an IP address, these IP addresses might change because they correspond to the IP address of the elastic beanstalk instance.
We can run the eb open command to open the URL. Now we can use our domain name to access the health check endpoint. Let's make the home page display the health check. We need to add the change to git and deploy the latest code. The upload is complete. Let's check the status. It is in pending state. We need to wait from some time. The status is now ready and green. Let's go to the root url. It does not display the health status. If we open the console, we see everything seems to be ok. Let's run the app locally. It works locally. Reloading the browser does not solve the problem. We see that the old URL still works. Let's use curl to avoid any browser caching issues. It is not a browser caching issue.
I forgot to checkin the changes to the routes.rb. We can now deploy the changes. We can check the status. It is updating. We need to wait for a few minutes. The status is now ready and green. We can now see the health check JSON in the home page. It works!
