cloud

Git Smart with CodeCommit!

AWS recently announced that CodeCommit repositories can now be created via CloudFormation, which spurred me finally to take the opportunity to create my own home lab git repo. While I do have public GitHub repos, I have wanted a private repo for my experimental coding and other bits that aren’t ready or destined for public release. I could build my own VM at home to host a git repo (I recently tinkered with GitLab Community Edition), but then I have to worry about backups, accessibility from remote locations, etc.  As it turns out, you can build and use a CodeCommit repo for free in your AWS account, which made it even more compelling. So, I decided to give CodeCommit a try.

CodeCommit is a fully managed Git-based source control hosting service in AWS. Being fully managed, you can focus on using the repo rather than installing one, then maintaining, securing, backing it up, etc. And, it’s accessible from anywhere just like your other AWS services. The first 5 active users are free, which includes unlimited repo creation, 50 GB of storage, and  10,000 Git requests per month. Other benefits include integration paths with CodeDeploy and CodePipeline for a full CD/CI configuration. For a developer looking for a quick and easy way to manage non-public code, AWS offers a very attractive proposition to build your Git repo in CodeCommit.

QuickStart: Deploying Your Own CodeCommit Repo

  1. Download my CodeCommit CloudFormation template (json|yaml) and use to create your new repo.
  2. Add your SSH public key to your IAM user account and configure your SSH config to add a CodeCommit profile.
  3. Clone your new repo down to your workstation/laptop (be sure to use the correct AWS::Region and repository name): 
    git clone ssh://git-codecommit.us-east-1.amazonaws.com/v1/repos/yournewrepo

DeeperDive: Deploying Your Own CodeCommit Repo

Step 1: Building the CodeCommit Repository

I’ve created a CloudFormation template that creates a stack for deploying a CodeCommit repository. There are two versions, one in JSON and one in YAML, which is now supported for CF templating. Take your pick and deploy using either the console or via the AWS CLI.

You need to specify four stack parameters:

  • Environment (not used, but could be used in Ref’s for tagging)
  • RepoName (100-character string limit)
  • RepoDescription (1000-character string limit)
  • Email (for SNS notifications on repo events)

Here are the awscli commands required with sample parameters:

# modify the template if needed for your account particulars then validate:
$ aws cloudformation validate-template --template-body file:///path/to/template/aws-deploy-codecommit-repo.yml

$ aws cloudformation create-stack --stack-name CodeCommitRepo --template-body file:///path/to/template/aws-deploy-codecommit-repo.yml  --parameters ParameterKey=Environment,ParameterValue=Dev ParameterKey=RepoName,ParameterValue=myrepo ParameterKey=RepoDescription,ParameterValue='My code' ParameterKey=Email,ParameterValue=youremail@someplace.com

In a few minutes, you should have a brand new CloudFormation stack along with your own CodeCommit repository. You will receive a SNS notification email if you use my stock template, so be sure to confirm your topic subscription to receive updates when the repository event trigger runs (e.g., after commits to the master branch).

Step 2: Configure Your IAM Account With a SSH Key

Assuming that you, like myself, prefer to use SSH for git transactions, you will need to add your public SSH key to your IAM user in your AWS account. This is pretty straightforward and the steps are spelled out in the CodeCommit documentation.

Step 3: Clone Your New Repo

Once you’ve configured your SSH key in your IAM account profile, you can verify CodeCommit access like so:

ssh git-codecommit.us-east-1.amazonaws.com

Once you are able to talk to CodeCommit via git over SSH, you should be able to clone down your new repo:

git clone ssh://git-codecommit.us-east-1.amazonaws.com/v1/repos/yournewrepo

You will want to specify a repo-specific git config if you don’t use the global settings for your other repos:

git config user.name "Your Name"
git config user.email youremail@someplace.com

Now you are ready to add files to your new CodeCommit repository. Wasn’t that simple?

Externalizing domains in AWS Route53

I use AWS Route53 for registering domains that I use both personally and in my devops R&D lab work. It’s relatively inexpensive as registrars go (most of the ones I’ve registered are $12/yr) and domains integrate by default into Route53, which is very helpful for whatever hosting you perform via AWS.

However, sometimes I use domains in Route53 for external hosting applications, like blogs which hosted by WordPress.com. In order to use a custom domain with WordPress.com, you need to do two things when using R53 DNS:

  • change the NS records for the domain, and
  • change the DNS server list for zone delegation

Both of these are easily performed in the R53 administrative console, but in different places.

Updating the NS records for the domain

Changing the NS records is as simple as loading the hosted zone set and selecting the NS record entry and editing it to replace the AWS DNS servers that originally were placed in the record:

blog-cucurb-fig1-route53hostedzonensnew

After the NS record changes propagate, I check the delegation paths for the domain since I haven’t changed that yet and notice that the TLD .org servers still look to AWS DNS servers:

blog-cucurb-fig3-route53predelegationchange

So, let’s change the delegation on our zone so that the TLD DNS servers look to the right place.

Updating the DNS server list for zone delegation

On the R53 console, navigate to Domains, Registered Domains, then select the domain you want to change. You should see a screen that lists some expiration, renewal, authorization, and tag parameters along with a list of name servers on the right side. That list needs to be edited in order to fix the delegation pathing for the new NS record entries.

Original, with AWS DNS servers listed:

blog-regdomains-fig2-nameservers

Edited to use new DNS servers for external site:

blog-cucurb-fig4-route53hostedzonensupdated

It takes a while for these changes to go into effect, AWS will send you an email once the changes have been completed. At that point, you can check the delegation path again:

blog-cucurb-fig5-route53postdelegationchange

At this point, the delegation path between the new WordPress.com DNS servers and the TLD .org DNS servers is established and your application/blog should now be working.