[DevOps/02]Terraform Use cases 테라폼을 사용하는 이유

테라폼을 사용하는 이유

 

1. Heroku App Setup

- codify the setup required for a Heroku application, ensuring that all the required add-ons

- configuring DNSimple to set a CNAME, or setting up Cloudflare as a CDN for the app

- do all of this in under 30 seconds without using a web interface

 

2. Multi-Tier Applications

A very common pattern is the N-tier architecture. The most common 2-tier architecture is a pool of web servers that use a database tier. Additional tiers get added for API servers, caching servers, routing meshes, etc. This pattern is used because the tiers can be scaled independently and provide a separation of concerns. Terraform is an ideal tool for building and managing these infrastructures. Each tier can be described as a collection of resources, and the dependencies between each tier are handled automatically; Terraform will ensure the database tier is available before the web servers are started and that the load balancers are aware of the web nodes. Each tier can then be scaled easily using Terraform by modifying a single count configuration value. Because the creation and provisioning of a resource is codified and automated, elastically scaling with load becomes trivial.

- N-tier 아키텍처 패턴은 계층이 독립적으로 확장되고 문제를 분리 할 수 ​​있기 때문에 사용됨

- ensure the database tier is available before the web servers are started and that the load balancers are aware of the web node

- 테라폼을 사용하면 각 계층을 쉽게 확장 할 수 있음

- 리소스 생성 및 프로비저닝이 체계화되고 자동화되어 있기 때문에 부하에 따른 탄력적인 확장이 간단해짐

3. Self-Service Clusters

At a certain organizational size, it becomes very challenging for a centralized operations team to manage a large and growing infrastructure. Instead it becomes more attractive to make "self-serve" infrastructure, allowing product teams to manage their own infrastructure using tooling provided by the central operations team.

- 특정 조직 규모에서는 중앙 집중식 운영 팀이 크고 성장하는 인프라를 관리하는 것이 매우 어려움

- 대신 "셀프 서비스"인프라를 만드는 것이 더 매력적

- 제품 팀product team이 중앙 운영 팀central operations team에서 제공하는 도구를 사용하여 자체 인프라를 관리 할 수 ​​있음

Using Terraform, the knowledge of how to build and scale a service can be codified in a configuration. Terraform configurations can be shared within an organization enabling customer teams to use the configuration as a black box and use Terraform as a tool to manage their services.

- 테라폼을 사용하면 서비스를 빌드하고 확장하는 방법에 대한 지식을 구성에 코드화 할 수 있음

- 테라폼 구성은 조직 내에서 공유 할 수 있으므로 고객 팀customer team은 구성을 블랙 박스처럼 사용하고 테라폼을 서비스 관리 도구로 사용할 수 있음

 

4. Software Demos

Modern software is increasingly networked and distributed. Although tools like Vagrant exist to build virtualized environments for demos, it is still very challenging to demo software on real infrastructure which more closely matches production environments.

- Vagrant 와 같은 도구는 데모용 가상화 환경을 구축하기 위해 존재 하지만 프로덕션 환경과 더 밀접하게 일치하는 실제 인프라에서 소프트웨어를 데모하는 것은 여전히 ​​매우 어려움

Software writers can provide a Terraform configuration to create, provision and bootstrap a demo on cloud providers like AWS. This allows end users to easily demo the software on their own infrastructure, and even enables tweaking parameters like cluster size to more rigorously test tools at any scale.

- 소프트웨어 작성자는 Terraform 구성을 제공하여 AWS와 같은 클라우드 제공 업체에서 데모를 생성, 프로비저닝 및 부트 스트랩 할 수 있음

- 이를 통해 최종 사용자는 자체 인프라에서 소프트웨어를 쉽게 데모 할 수 있으며 클러스터 크기와 같은 매개 변수를 조정하여 어떤 규모에서든 도구를 보다 엄격하게 테스트 할 수 있음

 

5. Disposable Environments

It is common practice to have both a production and staging or QA environment. These environments are smaller clones of their production counterpart, but are used to test new applications before releasing in production. As the production environment grows larger and more complex, it becomes increasingly onerous to maintain an up-to-date staging environment.

- 프로덕션 및 스테이징 또는 QA 환경을 모두 갖는 것이 일반적 

- 이러한 환경은 프로덕션 환경의 작은 복제본이지만 프로덕션으로 출시하기 전에 새 애플리케이션을 테스트하는 데 사용

- 프로덕션 환경이 점점 더 커지고 복잡 해짐에 따라 최신 스테이징 환경을 유지하는 것이 점점 더 번거로워짐

Using Terraform, the production environment can be codified and then shared with staging, QA or dev. These configurations can be used to rapidly spin up new environments to test in, and then be easily disposed of. Terraform can help tame the difficulty of maintaining parallel environments, and makes it practical to elastically create and destroy them.

- 테라폼을 사용하면 프로덕션 환경을 코드화 한 다음 스테이징, QA 또는 개발자와 공유 할 수 있음

- 이러한 구성을 사용하면 테스 트할 새로운 환경을 빠르게 가동한 다음 쉽게 폐기 할 수 있음

- Terraform은 병렬 환경 유지의 어려움을 완화하고이를 탄력적으로 만들고 파괴하는 것을 실용적으로 만듬

 

 

6. Software Defined Networking

Software Defined Networking (SDN) is becoming increasingly prevalent in the datacenter, as it provides more control to operators and developers and allows the network to better support the applications running on top. Most SDN implementations have a control layer and infrastructure layer. Terraform can be used to codify the configuration for software defined networks. This configuration can then be used by Terraform to automatically setup and modify settings by interfacing with the control layer. This allows configuration to be versioned and changes to be automated. As an example, AWS VPC is one of the most commonly used SDN implementations, and can be configured by Terraform.

- codify SDN configuration 

- automatically setup and modify settings by interfacing with the control layer

 

7. Resource Schedulers

In large-scale infrastructures, static assignment of applications to machines becomes increasingly challenging. To solve that problem, there are a number of schedulers like Borg, Mesos, YARN, and Kubernetes. These can be used to dynamically schedule Docker containers, Hadoop, Spark, and many other software tools.

- 대규모 인프라에서는 애플리케이션을 기계에 정적으로 할당하는 것이 점점 더 어려워지고 있음

- 이 문제를 해결하기 위해 Borg, Mesos, YARN 및 Kubernetes와 같은 여러 스케줄러가 있음

- 이것들은 Docker containers, Hadoop, Spark 및 기타 여러 소프트웨어 도구를 동적으로 스케줄하는 데 사용할 수 있다.

Terraform is not limited to physical providers like AWS. Resource schedulers can be treated as a provider, enabling Terraform to request resources from them. This allows Terraform to be used in layers: to setup the physical infrastructure running the
schedulers as well as provisioning onto the scheduled grid.

-  setup the physical infrastructure running the schedulers as well as provisioning onto the scheduled grid

- 테라폼은 스케줄러를 provider로 취급하여 리소스 요청 가능  

 

8. Multi-Cloud Deployment

It's often attractive to spread infrastructure across multiple clouds to increase fault-tolerance. By using only a single region or cloud provider, fault tolerance is limited by the availability of that provider. Having a multi-cloud deployment allows for more graceful recovery of the loss of a region or entire provider.

- 내결함성을 높이기 위해 인프라를 분산시켜 저장 → 멀티 클라우드의 장점

Realizing multi-cloud deployments can be very challenging as many existing tools for infrastructure management are cloud-specific. Terraform is cloud-agnostic and allows a single configuration to be used to manage multiple providers, and to even handle cross-cloud dependencies. This simplifies management and orchestration, helping operators build large-scale multi-cloud infrastructures.

- 많은 인프라 관리 도구가 특정 클라우드 전용 → 멀티 클라우드 배포가 매우 힘들 수 있음 

- 테라폼은 클라우드의 종류에 구애받지 않고, 단일 구성(single configuration)으로 다양한 provider와 클라우드 종속성을 다룰 수 있음

- 이는 관리 및 오케스트레이션을 단순화하여 운영자가 대규모 멀티 클라우드 인프라를 구축 할 수 있도록 도움

 

---

* Terraform Use cases(링크)

Use Cases - Terraform by HashiCorp