Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Continuous Deployment of DNS Records with DNSimple

DZone's Guide to

Continuous Deployment of DNS Records with DNSimple

· DevOps Zone
Free Resource

Learn more about how CareerBuilder was able to resolve customer issues 5x faster by using Scalyr, the fastest log management tool on the market. 

At Codeship we always look into new ways how we can leverage Codeship to automate our workflows. A while ago we started Continuous Deployment of our DNS records.

How we managed our DNS records in the past.

Like everybody else – we used a web interface from our DNS provider. It’s basically a huge text area containing your zonefile. I always felt uncomfortable managing my DNS records this way. It’s too easy to delete a record by accident and nothing is preventing you from doing so.

What is missing in the old approach?

  • History
  • Reviews
  • My environment

History
First and foremost, you don’t have a history of your zone. You can see and edit only the latest state of your zone. There is no way to see, why a record was added or deleted in your zone.

Reviews
At Codeship we do code reviews for all our changes which go into our master branch. We all know a second pair of eyes is always better. Why not review changes which go into your DNS zone? I broke our DNS in the past, because of some stupid typo, which could have been prevented.

My environment
Another reason which, in my opinion is the most underrated one, is that us developers live in our code. Moving out of my editor is a huge step, I don’t want to be forced to use something else than my trusted editor for coding.


How did we solve this?

History first. We are using Git (and GitHub) for all of our software projects and Git has proven that it can track changes very well. Using Git to track the history of our DNS zone feels natural.

How should we do reviews for our DNS zone? The same way we do reviews for our code. We are using the Pull-Request workflow already (read about it here). We love that workflow and we want to use it whenever possible.

You need a DNS provider who offers you an API to change your DNS records. We are using DNSimple (https://dnsimple.com/) as our DNS provider, because they offer a great API and 2-Factor-Authentication for your account.

It’s time to glue everything together. Git, Pull-Request and our DNS provider. We open sourced our solution. Feel free to use it! You can find it here: https://github.com/codeship/dns_deploy

Using Dnsdeploy with Codeship

We prepared an example repository to show how you can use dnsdeploy with Codeship. You can use this as a template for your DNS repository.

You can find the example repository over at GitHub: https://github.com/codeship/dns-example

Codeship Setup Commands:

> rvm use $(cat .ruby-version) --install
> bundle install

Codeship Test Commands:

> bundle exec ruby validate.rb

Codeship Deploy Commands:

> bash deploy.sh

You need to export your DNSimple credentials as

DNSIMPLE_USERNAME

and

DNSIMPLE_API_TOKEN

Conclusion

It’s amazing to review your DNS changes and track the history of your DNS zone with the tools you are familiar with.

Now I can simply open a Pull-Request on our DNS repository to propose changes. After somebody else in the team reviewed my changes they get merged into the master branch and, thanks to Codeship, immediately deployed.

The new workflow makes changes to our DNS zone transparent and comprehensible for everybody in the team. Who changed our SPF records lately? Now it’s simple to answer that question.

How do you manage your DNS records? I would love to learn about it in the comments.

Further Information

Find out more about how Scalyr built a proprietary database that does not use text indexing for their log management tool.

Topics:

Published at DZone with permission of Moritz Plassnig, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}