1-888-317-7920 info@2ndwatch.com

Migrating Terraform Remote State to a “Backend” in Terraform v.0.9+

(AKA: Where the heck did ‘terraform remote config’ go?!!!)

If you are working with cloud-based architectures or working in a DevOps shop, you’ve no doubt been managing your infrastructure as code. It’s also likely that you are familiar with tools like Amazon CloudFormation and Terraform for defining and building your cloud architecture and infrastructure. For a good comparison on Amazon CloudFormation and Terraform check out Coin Graham’s blog on the matter: AWS CFT vs. Terraform: Advantages and Disadvantages.

If you are already familiar with Terraform, then you may have encountered a recent change to the way remote state is handled, starting with Terraform v0.9. Continue reading to find out more about migrating Terraform Remote State to a “Backend” in Terraform v.0.9+.

First off… if you are unfamiliar with what remote state is check out this page.

Remote state is a big ol’ blob of JSON that stores the configuration details and state of your Terraform configuration and infrastructure that has actually been deployed. This is pretty dang important if you ever plan on changing your environment (which is “likely”, to put it lightly) and especially important if you want to have more than one person managing/editing/maintaining the infrastructure, or if you have even the most basic rationale as it pertains to backup and recovery.

Terraform supports almost a dozen backend types (as of this writing) including:

  • Artifactory
  • Azure
  • Consul
  • Etcd
  • Gcs
  • Http
  • Manta
  • S3
  • Swift
  • Terraform Enterprise (AKA: Atlas)

 

Why not just keep the Terraform state in the same git repo I keep the Terraform code in?

You also don’t want to store the state file in a code repository because it may contain sensitive information like DB passwords, or simply because the state is prone to frequent changes and it might be easy to forget to push those changes to your git repo any time you run Terraform.

So, what happened to terraform remote anyway?

If you’re like me, you probably run the la version of HashiCorp’s Terraform tool as soon as it is available (we actually have a hook in our team Slack channel that notifies us when a new version is released). With the release of Terraform v.0.9 last month, we were endowed with the usual heaping helping of excellent new features and bug-fixes we’ve come to expect from the folks at HashiCorp, but were also met with an unexpected change in the way remote state is handled.

Unless you are religious about reading the release notes, you may have missed an important change in v.0.9 around the remote state. While the release notes don’t specifically call out the removal (not even deprecation, but FULL removal) of the prior method (e.g. with Terraform remote config, the Upgrade Guide specifically calls out the process in migrating from the legacy method to the new method of managing remote state). More specifically, they provide a link to a guide for migrating from the legacy remote state config to the new backend system. The steps are pretty straightforward and the new approach is much improved over the prior method for managing remote state. So, while the change is good, a deprecation warning in v.0.8 would have been much appreciated. At least it is still backwards compatible with the legacy remote state files (up to version 0.10), making the migration process much less painful.

Prior to v.0.9, you may have been managing your Terraform remote state in an S3 bucket utilizing the Terraform remote config command. You could provide arguments like: backend and backend-config to configure things like the S3 region, bucket, and key where you wanted to store your remote state. Most often, this looked like a shell script in the root directory of your Terraform directory that you ran whenever you wanted to initialize or configure your backend for that project.

Something like…

Terraform Legacy Remote S3 Backend Configuration Example
#!/bin/sh
export AWS_PROFILE=myprofile
terraform remote config \
--backend=s3 \
--backend-config="bucket=my-tfstates" \
--backend-config="key=projectX.tfstate" \
--backend-config="region=us-west-2"

This was a bit clunky but functional. Regardless, it was rather annoying having some configuration elements outside of the normal terraform config (*.tf) files.

Along came Terraform v.0.9

The introduction of Terraform v.0.9 with its new fangled “Backends” makes things much more seamless and transparent.  Now we can replicate that same remote state backend configuration with a Backend Resource in a Terraform configuration like so:

Terraform S3 Backend Configuration Example
terraform {
  backend "s3" {
    bucket = "my-tfstates"
    key    = "projectX.tfstate"
    region = "us-west-2"
  }
}
A Migration Example

So, using our examples above let’s walk through the process of migrating from a legacy “remote config” to a “backend”.  Detailed instructions for the following can be found here.

1. (Prior to upgrading to Terraform v.0.9+) Pull remote config with pre v.0.9 Terraform

> terraform remote pull
Local and remote state in sync

2. Backup your terraform.tfstate file

> cp .terraform/terraform.tfstate 
/path/to/backup

3. Upgrade Terraform to v.0.9+

4. Configure the new backend

terraform {
  backend "s3" {
    bucket = "my-tfstates"
    key    = "projectX.tfstate"
    region = "us-west-2"
  }
}

5. Run Terraform init

> terraform init
Downloading modules (if any)...
 
Initializing the backend...
New backend configuration detected with legacy remote state!
 
Terraform has detected that you're attempting to configure a new backend.
At the same time, legacy remote state configuration was found. Terraform will
first configure the new backend, and then ask if you'd like to migrate
your remote state to the new backend.
 
 
Do you want to copy the legacy remote state from "s3"?
  Terraform can copy the existing state in your legacy remote state
  backend to your newly configured backend. Please answer "yes" or "no".
 
  Enter a value: no
  
Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.
 
Terraform has been successfully initialized!
 
You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.
 
If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your environment. If you forget, other
commands will detect it and remind you to do so if necessary.

6. Verify the new state is copacetic

> terraform plan
 
...
 
No changes. Infrastructure is up-to-date.
 
This means that Terraform did not detect any differences between your
configuration and real physical resources that exist. As a result, Terraform
doesn't need to do anything.

7.  Commit and push

In closing…

Managing your infrastructure as code isn’t rocket science, but it also isn’t trivial.  Having a solid understanding of cloud architectures, the Well Architected Framework, and DevOps best practices can greatly impact the success you have.  A lot goes into architecting and engineering solutions in a way that maximizes your business value, application reliability, agility, velocity, and key differentiators.  This can be a daunting task, but it doesn’t have to be!  2nd Watch has the people, processes, and tools to make managing your cloud infrastructure as code a breeze! Contact us today to find out how.

 

— Ryan Kennedy, Principal Cloud Automation Architect, 2nd Watch

 

Facebooktwittergoogle_pluslinkedinmailrss

Decision Points: Moving Enterprise Workloads to the Cloud

When you’re ready to move to the cloud, it’s truly a transformational time.  Determining your cloud strategy before moving too quickly is paramount.  It is important to make the hard and big decisions first.  You will be in the cloud for many years to come.  This can be a time to also remove years of technical debt.  After all, you want to migrate your workloads and not lift and shift your technical debt along with it.  At the same time, you do not want to experience “analysis paralysis” with all the decisions to be made.  Ultimately, you can have the speed, agility and cross-organizational support while providing the proper governance and guardrails.

Determining your migration strategy ahead of time is important for security, change management, and cost containment.  The promise of the cloud is great.  You might want to allow people to build and development environments at will.  You have smart and capable people.  They need help to quickly deploy.  Shadow IT results when innovative people are constrained from experimenting.  And often, the intention is that it will be temporary.  However, temporary quickly becomes permanent and undocumented without compliance.  The decision points listed in this article are important.  This is by no means a compressive list, as other items will likely reveal themselves during the process.

Decisions for Enterprise Cloud Migration – the Business of the Cloud:

  • Discovery – Can you get an accurate list of the application inventory?  What operating systems are in use?  Are all the applications still relevant or can they be retired?  What are the applications that have dependencies on other applications?  It may be hard to get this list together.  Some of these applications are likely many years old.  This can be time consuming and will help identify the true scope and cost estimates of moving to the cloud.  In many cases, third party discovery tools can aid in the discovery.
  • Vision and Education – Are the teams infighting and holding territory?  This can be related to understanding the cloud as well as they can.  It can be scary as all transformations are.  Y2K, client/server and the Internet revolution were scary as well.  We survived.  Plans for education to create awareness and capabilities will help.  There are also many misconceptions about the cloud in top management that will probably need to be addressed.

Strategic Decisions for the Cloud:

  • Which cloud providers are you going to use?  Clearly, Amazon Web Services is the leading cloud service provider.  However, a multi-cloud strategy may be important to the company as well.  How are you going to interconnect the cloud providers?
  • What account strategy will you use?  Will applications get their own account?  Or will accounts be aligned by business unit?  There are many different approaches to account strategy.  It will be hard to undue, so it is important to weigh the pros and cons of each strategy to account for billing, security and isolation.
  • What will your networking strategy be for networking in the cloud?  Will you use non-overlapping subnets managed with your on premise IP management?  Will you isolate production and non-production environments to separated block ranges in VPCs?  Or will you allow your migrated applications to only be accessed over the public internet instead of VPN?  It could also be a combination of these strategies.  There are many variables that will need to be identified to determine the best strategy.
  • Will you integrate on premise Identity management systems with your cloud infrastructure?  Active directory is common technology in most enterprises.  Will you extend your current AD architecture?  What changes need to be made to make it optimal for the cloud?

Decisions for Cost, Security and Compliance:

  • How will you tag your cloud assets?  Will it account for billing, security, and compliance?  Getting this right early on will allow for automation to enforce compliance and monitor for violations.
  • How will you manage the cloud costs?  Will you allow developers to provision their own instances?  What will your Reserved Instance strategy be?  How often does it need to be reviewed?  Costs in the cloud can spin out of control if proper guardrails are not established.  Scheduled power on and power off of environments is also another important strategy to further reduce costs.
  • What technologies are approved for cloud deployments?  Will your organization create approved images?  How will they be managed and updated?  Maybe your organization has approved base software that must be installed.  How will you maintain this configuration?  Configuration management and image baking are important processes to identify and define.
  • How will the cloud assets be continuously monitored for compliance?  Once a violation is found, how will it be remediated, with automation or manually?  Between AWS Config, CloudTrail and Tagging strategies, much of this task can be accomplished with automation.  However, there still needs to be individuals that review and update the process.
  • How will you secure your cloud environments?  WAF, anti-virus, IDS/IPS, and firewalls are just part of the overall security solution.  How will you control egress traffic as well?  How will you isolate your applications from each other and control user access?  We all know security is hard and requires constant care.  Find the right balance between real threats while still providing agility are important.
  • Will you secure data at rest?  Will you use built in AWS services for encryption keys, KMS or CloudHSM?  Or will you bring your own keys?  How will you provide column or row based encryption of your databases?  Cloud solutions need to be analyzed against the company standards to determine if you can use built in cloud encryption or decide to roll your own.
  • How will you provision your certificates for data in transit?  AWS provides the Certificate Manager service to provision SSL certificates.  Or will you continue to use your existing provider?  How will you track expiring certificates and update them?  AWS has many features for SSL including integration with their Elastic Load Balancers.
  • How will you manage your big data?  Will you scale up or out?  Are the workloads transient?  There are many options for cost optimization.  Between Spot Instances and automation, incredibility elegant solutions can be created.
  • What are your Disaster Recovery policies?  Do they need to be adjusted for the cloud?  Most likely they do.  How will you deliver your DR solutions?  Again, there are many solutions for DR in the cloud from infrastructure as code and creating automation to critical data and servers between regions.
  • What are your data retention policies?  How will you implement them in the cloud?  How will you ensure that you have met your regulatory compliance?  There are built-in solutions for data life cycles in AWS, but in many cases, it is more complicated than what is available off the shelf.
  • How will you handle OS and application licensing?  Will you use on-demand or bring your own licenses?  There is no one right answer.  ROIs needs to be calculated in many cases.
  • What is your single-sign-on (SSO) solution?  How will it integrate into the cloud?  AWS does provide federated authentication all of its services.

This is a long list of questions.  It isn’t intended to scare you away from the cloud, but rather to embrace it correctly.  No two enterprises are identical, but most share many of the same challenges.  Starting with this list of questions may help you identify many of the successful approaches to a migration journey to the much-promised benefits of the cloud.

-Ian Willoughby, Principal Architect

Facebooktwittergoogle_pluslinkedinmailrss

Top Business Issues When Moving to the Cloud

Jeff Aden, EVP of Business Development and Marketing at 2nd Watch, recently contributed this article on top business issues when moving to the cloud to Data Center Knowledge Enjoy!

When planning a move to the cloud, CIOs often worry about if and how legacy applications will migrate successfully, what level of security and archiving they need, whether they have the right internal skills and which cloud providers and toolsets are the best match for business goals.

There are also a number of business issues to consider, such as the changing nature of contracts and new considerations for budgeting and financial planning. For instance, transitioning from large upfront capital purchases, such as data center investments and software agreements to monthly service fees can help lower costs related to the management and maintenance of technology, much of which is underutilized. There’s also no need to deploy capital on unutilized resources — all positive changes. Yet pay-as-you-go pricing also brings a change in how IT is purchased: the CFO will need processes for monitoring usage and spending, to prevent so-called cloud sprawl.  Here’s our take on the top considerations beyond technology planning for making a smooth move to the cloud.

  1. Working with existing IT outsourcers. A recent survey by Gartner noted that approximately 70% of CIOs surveyed will be changing IT vendor and sourcing relationships over the next two years. The primary reason for this shift is that most traditional IT service providers aren’t delivering public cloud-related services or products that are suited for the transition to a digital business. Dissolving or changing relationships with longtime IT partners will take some thought around how to structure the right business terms. For instance, when renewing contracts with current vendors, companies may seek to add a clause allowing them to bifurcate between current services (hardware/colocation) and emerging services such as cloud. This will allow the right provider with the right skill sets to manage the cloud workloads. If your company is within an existing contract that’s not up for renewal soon, look for another legal out, such as “default” or “negligent” clauses in the contract, which would also allow you to hire a reputable cloud IaaS firm because your current provider does not have the skill set, process for expertise in a new technology. Reputable vendors shouldn’t lock their customers into purchasing services which aren’t competitive in the marketplace. Yet, the contract rules everything, so do whatever you can to ensure flexibility to work with cloud vendors when renewing IT contracts.
  1. Limits of liability. This contractual requirement gives assurances to the customer that the vendor will protect your company, if something goes wrong. Limits of liability are typically calculated on the number of staff people assigned to an account and/or technology investments. For instance, when a company would purchase a data center or enter into a colocation agreement, it required a large CAPEX investment and a large ongoing OPEX cost. For these reasons, the limits of liability would be a factor above this investment and the ongoing maintenance costs. With the cloud, you only pay for what you use which is significantly less but grows overtime. Companies can manage this risk by ensuring escalating limits of liability which are pegged to the level of usage. As your cloud usage grows, so does your protection.
  1. Financial oversight. As mentioned earlier, one advantage of on-premise infrastructure is that the costs are largely stable and predictable. The cloud, which gives companies far more agility to provision IT resources in minutes with a credit card, can run up the bill quickly without somebody keeping a close watch of all the self-service users in your organization. It’s more difficult to predict costs and usage in the cloud, given frequent changes in pricing along with shifts in business strategy that depend upon easy access to cloud infrastructure. Monitoring systems that track activity and usage in real time, across cloud and internal or hosted environments are critical in this regard. As well, finance tools that allow IT and finance to map cloud spending to business units and projects will help analyze spend, measure business return and assist with budget planning for the next quarter or year. Cloud expense management tools should integrate with other IT cost management and asset management tools to deliver a quick view of IT investments at any moment. Another way to control spend is to work with a reseller. An authorized reseller will be able to eliminate credit card usage, providing your company with invoicing and billing services, the ability to track spend and flexible payment terms. This approach can save companies time and money when moving to the cloud.
  1. Service catalogue: A way to manage control while remaining agile is to implement a service catalogue, allowing a company’s security and network teams to sign off on a design that can be leveraged across the organization multiple times with the same consistency every time. Service catalogues control which users have access to which applications or services to enable compliance with business policies while giving employees an easy way to browse available resources. For instance, IT can create a SAP Reference Implementation for a environment.  Once this is created, signed off by all groups, and stored in your service catalogue it can be leveraged the same way, every time and by all approved users.  This provides financial control and governance over how the cloud is being deployed in your organization. It can also move your timelines up considerably, saving you weeks and months from ideation to deployment.
  1. Staffing/organizational changes: With any shift in technology, there is a required shift in staffing and organizational changes. With the cloud, this involves both skills and perspective.  Current technologists whom are subject matter experts, such as SAN engineers, will need to understand business drivers, adopt strategic thinking and have a focus on business-centered innovation.  The cloud brings tools and services that change the paradigm on where and how time is being spent.  Instead of spending 40% of your time planning the next rack of hardware to install, IT professional should focus their energies responding to business needs and providing valuable solutions that were previously cost prohibitive, such as spinning up a data warehouse for less than a $1,000 per year.

To set up a private appointment with a 2nd Watch migration expert, Contact Us.

Facebooktwittergoogle_pluslinkedinmailrss

Digital Business: Speeding Transition to the Cloud

Gartner defines Digital Business as the creation of new business designs by blurring the digital and physical worlds. What does this mean? It means that business demand is out pacing the ability physical IT data centers have to accommodate. Companies are being challenged by competitors using newer technology or startups reinventing how business problems are solved.

Digital Business has changed how business executives think about IT and technology. The ability to innovate quickly and at very low cost is key to being competitive in today’s digital economy – no matter what business, from retail to manufacturing to financial to gaming. Great examples are companies like NetFlix and Instagram, which have changed our culture with their ability to innovate.

I mention these companies specifically because they use the public cloud to create innovation. In the past, companies required huge investment and time to build out data centers for a global presence. Now, with the public cloud like AWS, companies can go from concept to global roll out in months with very little upfront costs.

Digital Business is changing the way companies think about IT. Much of the excitement of public cloud has been focused on small companies that innovate and grow large. But in the past year or so, large enterprise companies have become serious about adopting this same type of innovation. For those of us old enough to know – Enterprise IT hasn’t seen this dramatic of a change since the personal computer changed the mainframe industry.

So why does the public cloud make sense for Digital Business? As you know from our previous post, the cloud enables innovation. First, public cloud is elastic and pay-as-you-use, which enables IT organizations to innovate with very small upfront costs and with the ability to scale globally. Next, public cloud provides a robust platform of services besides just computing, which enables software development teams to focus on business differentiation and to do so much quicker than with traditional IT. Instead of spending time figuring out how to setup a message queue system, developers can use something like the AWS service SQS. Again this speeds up innovation.

In future articles – we will describe in more detail why public cloud is an ideal platform for the new world of Digital Business.

-Joel Rosenberger, EVP Software, Executive

Facebooktwittergoogle_pluslinkedinmailrss

The Public Cloud – Planning for 2015

With every new year comes a new beginning. The holidays give us a chance to reflect on our achievements from the previous year, as well as give us a benchmark for what we 2015want to accomplish in the following year. For most individuals, weight loss, quitting a bad habit, or even saving money top the list for resolutions. For companies, the goals are a little bit more straight forward and quantitative. Revenue goals are set, quotas are established, and business objectives are defined. The success of a company is entrenched in these goals and will determine; positively or negatively, how a company should be valued.

Today’s businesses are becoming even more complex than ever, and we can thank new technologies, emerging markets, and the ease of globalization for helping drive these new trends. One of the most impactful and fast adopting technologies that is helping businesses in 2015 is the public cloud.

What’s amazing, though, is that how businesses are planning for the adoption of public cloud is still unknown to most. Common questions such as “Is my team staffed accordingly to handle this technology change?” or “How do I know if I’m architecting correctly for my business?” are coming up often. These questions are extremely common with new technologies, but it doesn’t have to be difficult if you take these simple steps.

  • Plan Ahead: Guide your leadership to see that now is the time to review the current technology inventory being utilized by the company and strategically outline what it will take to help the company become more agile, cost effective, and leverage the most robust technologies in the New Year.
  • Over communicate: By talking with all the necessary parties, you will turn an unknown topic into water cooler conversation. Involve as many people as possible and ask for feedback constantly. This way, if there is anyone that is not on-board with this technology shift, you will have advocates across the organization helping your cause.
  • Track your progress: Keep an active log of your adoption process, pitfalls, to-dos, and active contributors. Establish a weekly cadence to review past success and upcoming agendas. Focus on small wins, and after a while you will see amazing results for your achievements.
  • Handle problems with positivity: Technology changes are never easy for an organization, but take each problem as an opportunity to learn. If something isn’t working, it’s probably for good reason. Review what went wrong, learn from the mistakes, and make sure they don’t repeat themselves. Each problem should be welcomed, addressed and reviewed accordingly.
  • Stay diligent: Rome wasn’t built in a day, and neither will your new public-cloud datacenter be. Review your plan, do constant check points against your cloud strategy, follow your roadmap and address problems as soon as they come up. By staying focused and tenacious you will be successful in your endeavors.

Happy 2015, and let’s make it a great year.

-Blake Diers, Alliance Manager

Facebooktwittergoogle_pluslinkedinmailrss