코드로서의 인프라스트럭처

Infrastructure as code

코드로서의 인프라스트럭처(IaC)는 물리 하드웨어 구성이나 인터랙티브 구성 [1]도구가 아닌 기계 판독 가능한 정의 파일을 사용하여 컴퓨터 데이터 센터를 관리하고 프로비저닝하는 프로세스입니다. 프로세스에 의해 관리되는 IT인프라스트럭처베어메탈 서버와 같은 물리 기기 및 가상 머신과 관련된 구성 리소스로 구성됩니다.정의는 버전 관리 시스템에 있을 수 있습니다.정의 파일의 코드는 수동 프로세스를 통해 코드를 유지하는 것이 아니라 스크립트 또는 선언적 정의 중 하나를 사용할 수 있지만 IaC는 선언적 접근 방식을 사용하는 경우가 많습니다.

개요

IaC는 유틸리티 컴퓨팅과 제2세대 웹 프레임워크에 의해 야기된 어려움에 대한 대응으로 성장했습니다.2006년 Amazon Web Services의 Elastic Compute Cloud와 불과 몇[2] 달 전 Ruby on Rails 1.0 버전이 출시되면서 이전에는 다국적 [3]대기업에서만 경험했던 광범위한 확장 문제가 기업 내에서 발생했습니다.계속 성장하는 이 분야에 대응할 수 있는 새로운 툴이 등장하면서 IaC의 아이디어가 탄생했습니다.코드로 인프라스트럭처를 모델링하고 알려진 소프트웨어 베스트 프랙티스를 사용하여 애플리케이션 인프라스트럭처를 설계, 구현 및 도입할 수 있다는 생각은 소프트웨어 개발자와 IT 인프라 관리자 모두의 관심을 끌었습니다.인프라스트럭처를 코드로 취급해, 다른 소프트웨어 프로젝트와 같은 툴을 사용할 수 있기 때문에,[4] 개발자는 애플리케이션을 신속히 도입할 수 있습니다.

이점

IaC의 가치는 비용, 속도 및 [citation needed]위험의 세 가지 측정 가능한 범주로 나눌 수 있습니다.비용 절감은 재무적인 측면뿐만 아니라 인력 및 노력 측면에서도 기업을 지원하는 것을 목표로 합니다. 즉, 수동 구성 요소를 제거함으로써 사람들은 다른 엔터프라이즈 [citation needed]작업에 노력을 집중할 수 있게 됩니다.인프라스트럭처 자동화를 통해 인프라스트럭처 구성 시 실행속도가 향상되고 전사적인 다른 팀이 신속하고 효율적으로 작업할 수 있도록 가시성을 제공할 수 있습니다.자동화는 수동 구성 오류와 같은 인적 오류와 관련된 위험을 제거합니다. 이를 제거하면 다운타임을 줄이고 신뢰성을 높일 수 있습니다.이러한 결과와 속성은 기업이 개발[5]운영의 결합 작업인 DevOps 문화를 구현하는 데 도움이 됩니다.

어프로치의 종류

IaC에는 일반적으로 선언적(기능적)과 필수적(절차적)의 두 가지 접근방식이 있습니다.선언적 접근법과 명령적 접근법의 차이는 본질적으로 '무엇' 대 '어떻게'이다.선언적 접근법은 최종 타깃 구성이 무엇인지에 중점을 두고 있으며,[6] 이를 충족하기 위해 인프라스트럭처를 변경하는 방법에 중점을 두고 있습니다.선언적 접근법은 원하는 상태를 정의하고 원하는 상태를 달성하기 위해 필요한 작업을 수행합니다.명령어는 원하는 결론으로 끝나기 위해 적절한 순서로 실행해야 하는 특정 명령을 정의합니다.[7]

방법들

IaC에는 푸시 및 풀의 두 가지 방법이 있습니다.주된 차이는, 서버의 설정 방법을 지시하는 방법입니다.풀 방식에서는 설정하는 서버가 제어 서버에서 설정을 풀합니다.본 발명의 푸시방법은 제어서버가 컨피규레이션을 수신처 [8]시스템에 푸시한다.

도구들

인프라 자동화 기능을 충족하고 IaC를 사용하는 툴이 많이 있습니다.대략적으로 말하면, 변경을 실행하거나 프로그램적 접근법에 따라 인프라스트럭처를 선언적 또는 필수적으로 구성하는 프레임워크 또는 툴은 IaC로 [9]간주할 수 있습니다.기존에는 IaC를 실현하기 위해 서버(라이프 사이클) 자동화 및 구성 관리 도구가 사용되었습니다.현재 기업들은 지속적인 구성 자동화 툴이나 마이크로소프트의 PowerShell[10] DSC 또는 AWS CloudFormation과 [11]같은 독립형 IaC 프레임워크도 사용하고 있습니다.

지속적인 구성 자동화

모든 Continuous Configuration Automation(CCA; 연속 구성 자동화) 도구는 기존 IaC 프레임워크의 확장으로 간주할 수 있습니다.IaC를 활용하여 인프라를 변경, 구성 및 자동화하고 인프라 [3]관리 방법에 대한 가시성, 효율성 및 유연성을 제공합니다.이러한 추가 속성은 엔터프라이즈 수준의 보안 및 컴플라이언스를 제공합니다.

커뮤니티 콘텐츠

CCA 툴을 검토할 때 중요한 점은 오픈소스인 경우 커뮤니티 콘텐츠입니다.Gartner가 밝힌 와 같이 CCA 툴의 가치는 "자동화 [3]툴의 상업적 성숙도와 성능에 따라 사용자 커뮤니티가 제공하는 콘텐츠 및 지원에 따라 달라집니다."Puppet이나 Chef와 같은 벤더는 오랜 기간 동안 독자적인 커뮤니티를 만들었습니다.셰프에게는 셰프 커뮤니티 저장소가 있고 Puppet Forge에는 Puppet [12]Forge가 있습니다.다른 벤더는 인접 커뮤니티에 의존하여 PowerShell [10]DSC와 같은 다른 IaC 프레임워크를 활용합니다.컨텐츠가 아닌, 컨텐츠 제공을 위한 제품의 인텔리전스를 갖춘 모델 중심의 새로운 벤더가 등장하고 있습니다.이러한 시각적 객체 지향 시스템은 개발자들에게는 잘 작동하지만, 컨텐츠에 대한 스크립팅보다 모델을 중시하는 운영 지향 DevOps 및 운영 구성 요소에는 특히 유용합니다.이 분야가 계속 발전하고 변화함에 따라 IaC 툴이 모델 지향적이고 객체 지향적이지 않는 한 커뮤니티 기반 콘텐츠는 더욱 중요해질 것입니다.

주요 CCA 도구는 다음과 같습니다.

도구. 발매자 방법 접근 기입처 평.
셰프 셰프(2009) 당기다. 선언적 및 명령적 루비 -
수달 이네도 밀다 선언적 및 명령적 - 윈도 지향의
꼭두각시 Puppet (2005) 당기다. 선언적 및 명령적 C++ & Clojure 4.0 이후, 루비 -
솔트스택 SaltStack (2011) 밀고 당기다 선언적 및 명령적 파이썬 -
CFEngine Northern.tech(북방.tech 당기다. 선언적 C -
테라폼 하시코프 (2014) 밀다 선언적 가세요 -
앤서블 / 앤서블 타워 레드햇 (2012) 밀다 선언적 및 명령적 파이썬 -

기타 툴로는 AWS CloudFormation, cdist, StackStorm, Juju 등이 있습니다.

DevOps와의 관계

IaC는 DevOps에서 베스트 프랙티스를 실현하기 위한 중요한 속성이 될 수 있습니다.개발자는 설정의 정의에, 운용팀은 개발 [13]프로세스의 초기에 관여합니다.IaC를 이용하는 툴은 서버 상태와 구성을 가시화하고 궁극적으로 기업 내 사용자에게 가시성을 제공하여 [14]팀 간의 협력을 극대화하는 것을 목표로 합니다.일반적으로 자동화는 수동 프로세스의 혼란과 오류 발생 가능성이 높은 측면을 고려하여 프로세스의 효율성과 생산성을 높이는 것을 목표로 합니다.유연성과 다운타임을 줄이고 전체적인 비용 효율이 뛰어난 방법으로 더 나은 소프트웨어와 애플리케이션을 만들 수 있습니다.IaC는 수동 구성의 효율성을 떨어뜨리는 복잡성을 줄이는 것을 목적으로 합니다.자동화 및 협업은 DevOps의 중심 포인트로 간주되며, 인프라 자동화 툴은 DevOps 툴 [15]체인의 구성 요소로 포함되는 경우가 많습니다.

보안과의 관계

Unit 42(사이버 보안 제공업체 Palo Alto Networks의 위협 인텔리전스 유닛)가 발표한 2020 클라우드 위협 보고서는 [16]코드 템플릿으로 인프라의 약 200,000개의 잠재적 취약성을 확인했습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Wittig, Andreas; Wittig, Michael (2016). Amazon Web Services in Action. Manning Press. p. 93. ISBN 978-1-61729-288-0.
  2. ^ Bower, Joseph L.; Christensen, Clayton M. "Disruptive Technologies: Catching the Wave". Harvard Business Review.
  3. ^ a b c Fletcher, Colin; Cosgrove, Terrence (26 August 2015). Innovation Insight for Continuous Configuration Automation Tools. Gartner (Report).[데드링크]
  4. ^ Riley, Chris (12 November 2015). "Version Your Infrastructure". DevOps.com.
  5. ^ Phillips, Andrew (14 May 2015). "Moving from Infrastructure Automation to True DevOps". DevOps.com.
  6. ^ "Declarative v. Imperative Models for Configuration Management: Which Is Really Better?". Scriptrock.com. Retrieved 14 December 2015.
  7. ^ Loschwitz, Martin (14 November 2014). "Choosing between the leading open source configuration managers". Admin Network & Security. Lawrence, KS USA: Linux New Media USA LLC.
  8. ^ Venezia, Paul (21 November 2013). "Puppet vs. Chef vs. Ansible vs. Salt". networkworld.com. Network World. Retrieved 14 December 2015.
  9. ^ Garner Market Trends: DevOps – Not a Market, but Tool-Centric Philosophy That supports a Continuous Delivery Value Chain (Report). Gartner. 18 February 2015.
  10. ^ a b Chaganti, Ravikanth (5 January 2016). "DevOps, Infrastructure as Code, and PowerShell DSC: The Introduction". PowerShell Magazine. PowerShell Magazine. Retrieved 11 January 2016.
  11. ^ "Introducing AWS CloudFormation".
  12. ^ Sturgeon, Phil (28 October 2012). "Puppet or Chef?".
  13. ^ Ramos, Martin (4 November 2015). "Continuous Integration: Infrastructure as Code in DevOps". easydynamics.com. Archived from the original on 6 February 2016. Retrieved 29 January 2016.
  14. ^ Infrastructure As Code: Fueling the Fire for Faster Application Delivery (Report). Forrester. March 2015.
  15. ^ Wurster, Laurie F.; Colville, Ronni J.; Height, Cameron; Tripathi, Somendra; Rastogi, Aditi. Emerging Technology Analysis: DevOps a Culture Shift, Not a Technology (Report). Gartner.
  16. ^ "Cloud Threat Report Shows Need for Consistent DevSecOps". InformationWeek. 13 February 2020. Retrieved 24 February 2020.