1부: 웹/안드로이드

주의: 이 기사는 원본 기사를 러시아어로 번역한 것입니다. “DevOps 도구는 DevOps만을 위한 것이 아닙니다. "처음부터 테스트 자동화 인프라 구축." 그러나 러시아어로 번역할 때 의미가 왜곡되는 것을 방지하기 위해 모든 그림, 링크, 인용문 및 용어는 원래 언어로 보존됩니다. 즐겁게 공부하시길 바랍니다!

현재 DevOps 전문 분야는 IT 업계에서 가장 수요가 많은 분야 중 하나입니다. 인기 구직 사이트를 열고 연봉으로 필터링해 보면 DevOps 관련 채용 정보가 목록 상단에 있는 것을 볼 수 있습니다. 그러나 이는 주로 '상위' 직위를 의미하며, 이는 후보자가 높은 수준의 기술, 기술 및 도구에 대한 지식을 보유하고 있음을 의미한다는 점을 이해하는 것이 중요합니다. 이는 또한 중단 없는 생산 운영과 관련된 높은 수준의 책임을 수반합니다. 그러나 우리는 DevOps가 무엇인지 잊어버리기 시작했습니다. 처음에는 특정 인물이나 부서가 아니었습니다. 이 용어의 정의를 찾아보면 방법론, 관행, 문화철학, 개념군 등과 같은 아름답고 올바른 명사를 많이 찾을 수 있습니다.

제 전문 분야는 테스트 자동화 엔지니어(QA 자동화 엔지니어)이지만, 이것이 자동 테스트 작성이나 테스트 프레임워크 아키텍처 개발에만 연관되어서는 안 된다고 생각합니다. 2020년에는 자동화 인프라에 대한 지식도 필수다. 이를 통해 테스트 실행부터 목표에 따라 모든 이해관계자에게 결과 제공까지 자동화 프로세스를 직접 구성할 수 있습니다. 결과적으로 DevOps 기술은 작업을 완료하는 데 필수입니다. 이 모든 것이 좋지만 불행히도 문제가 있습니다 (스포일러: 이 기사는 이 문제를 단순화하려고 시도합니다.). 요점은 DevOps가 어렵다는 것입니다. 그리고 이는 기업이 하기 쉬운 일에 많은 비용을 지불하지 않기 때문에 분명합니다. DevOps 세계에는 숙달해야 할 도구, 용어 및 관행이 많이 있습니다. 이는 경력 초기에 특히 어렵고 축적된 기술 경험에 따라 달라집니다.

출처 : http://maximelanciauxbi.blogspot.com/2017/04/devops-tools.html

여기서 우리는 아마도 서문 부분을 끝내고 이 기사의 목적에 초점을 맞출 것입니다. 

이 기사는 무엇에 관한 것입니까?

이 글에서는 테스트 자동화 인프라를 구축한 경험을 공유하려고 합니다. 인터넷에는 다양한 도구와 사용 방법에 대한 많은 정보 소스가 있지만 순전히 자동화의 맥락에서 살펴보고 싶습니다. 나는 많은 자동화 엔지니어들이 개발된 테스트를 실행하거나 유지 관리하는 데 관심을 두는 사람이 없는 상황을 잘 알고 있다고 생각합니다. 결과적으로 테스트는 시대에 뒤떨어져 업데이트하는 데 시간을 소비해야 합니다. 다시 한번 말씀드리지만, 경력 초기에는 상당히 어려운 작업이 될 수 있습니다. 주어진 문제를 해결하는 데 도움이 되는 도구가 무엇인지, 도구를 선택, 구성 및 유지 관리하는 방법을 현명하게 결정하는 것입니다. 일부 테스터는 DevOps(사람)에게 도움을 요청하며, 솔직하게 말하면 이 접근 방식이 효과가 있습니다. 대부분의 경우 모든 종속성에 대한 가시성이 없기 때문에 이것이 유일한 옵션일 수 있습니다. 하지만 우리가 알고 있듯이 DevOps는 조직/팀에 따라 회사 전체의 인프라, 배포, 모니터링, 마이크로서비스 및 기타 유사한 작업을 생각해야 하기 때문에 매우 바쁜 사람입니다. 일반적으로 그렇듯이 자동화는 우선순위가 아닙니다. 그러한 경우, 우리는 처음부터 끝까지 가능한 모든 노력을 다해야 합니다. 이를 통해 의존성이 줄어들고 작업 흐름 속도가 빨라지며 기술이 향상되고 무슨 일이 일어나고 있는지 더 큰 그림을 볼 수 있게 됩니다.

이 기사에서는 가장 인기 있고 널리 사용되는 도구를 소개하고 이를 사용하여 자동화 인프라를 단계별로 구축하는 방법을 보여줍니다. 각 그룹은 개인적인 경험을 통해 테스트된 도구로 대표됩니다. 하지만 그렇다고 해서 같은 것을 사용해야 한다는 의미는 아닙니다. 도구 자체는 중요하지 않으며 나타나고 쓸모 없게 됩니다. 우리의 엔지니어링 임무는 기본 원칙, 즉 이 도구 그룹이 필요한 이유와 이 도구의 도움으로 해결할 수 있는 작업 문제를 이해하는 것입니다. 그렇기 때문에 각 섹션의 끝에 귀하의 조직에서 사용할 수 있는 유사한 도구에 대한 링크를 남겨 두었습니다.

이 글에 없는 내용

이 기사는 특정 도구에 관한 것이 아니므로 문서 및 특정 명령에 대한 설명에서 코드를 삽입하지 않을 것임을 다시 한 번 반복합니다. 그러나 각 섹션의 끝 부분에는 자세한 연구를 위한 링크를 남겨 둡니다.

이는 다음과 같은 이유로 수행됩니다. 

• 이 자료는 다양한 소스(문서, 책, 비디오 강좌)에서 매우 쉽게 찾을 수 있습니다.
• 더 깊이 들어가려면 이 기사의 10, 20, 30개 부분을 작성해야 합니다(계획은 2-3개입니다).
• 동일한 목표를 달성하기 위해 다른 도구를 사용하고 싶을 수도 있으므로 시간을 낭비하고 싶지 않습니다.

연습

저는 이 자료가 단순히 읽고 잊혀지는 것이 아니라 모든 독자에게 유용하길 바랍니다. 어떤 연구에서든 연습은 매우 중요한 요소입니다. 이를 위해 내가 준비한 것은 모든 작업을 처음부터 수행하는 방법에 대한 단계별 지침이 포함된 GitHub 저장소. 실행 중인 명령의 행을 무심코 복사하지 않도록 하기 위한 숙제도 있습니다.

계획

단계
Technology
도구

1
로컬 실행(웹/안드로이드 데모 테스트 준비 및 로컬 실행) 
Node.js, 셀레늄, Appium

2
버전 관리 시스템 
힘내

3
컨테이너화
Docker, Selenium 그리드, Selenoid(웹, Android)

4
CI/CD
깃랩 CI

5
클라우드 플랫폼
Google Cloud Platform

6
오케스트레이션
Kubernetes

7
코드형 인프라(IaC)
테라폼, 앤서블

각 섹션의 구조

내러티브를 명확하게 유지하기 위해 각 섹션은 다음 개요에 따라 설명됩니다.

• 기술에 대한 간략한 설명,
• 자동화 인프라의 가치,
• 인프라의 현재 상태를 보여주는 그림,
• 공부 링크,
• 비슷한 도구.

1. 로컬에서 테스트 실행

기술에 대한 간략한 설명

이는 로컬에서 데모 테스트를 실행하고 테스트가 통과하는지 확인하기 위한 준비 단계일 뿐입니다. 실무적인 부분에서는 Node.js를 사용하지만 프로그래밍 언어나 플랫폼도 중요하지 않으며 회사에서 사용하는 것을 사용하면 됩니다. 

그러나 자동화 도구로는 웹 플랫폼용 Selenium WebDriver와 Android 플랫폼용 Appium을 각각 사용하는 것이 좋습니다. 다음 단계에서는 이러한 도구와 특별히 작동하도록 맞춤화된 Docker 이미지를 사용할 것이기 때문입니다. 또한 작업 요구 사항을 참조하면 이러한 도구는 시장에서 가장 수요가 많습니다.

아시다시피 우리는 웹 및 Android 테스트만 고려합니다. 불행하게도 iOS는 완전히 다른 이야기입니다(Apple에게 감사드립니다). 앞으로는 IOS 관련 솔루션과 사례를 선보일 계획입니다.

자동화 인프라의 가치

인프라 관점에서 로컬로 실행하는 것은 어떤 가치도 제공하지 않습니다. 로컬 브라우저와 시뮬레이터를 사용하여 로컬 컴퓨터에서 테스트가 실행되는지만 확인합니다. 그러나 어쨌든 이것은 필요한 출발점이다.

인프라 현황 예시

탐색할 링크

• 셀레니움
• 아 피움
• Android 에뮬레이터
• Selenium JS GitHub 예제
• Appium JS GitHub 예제

유사한 도구

• Selenium/Appium 테스트와 함께 원하는 프로그래밍 언어;
• 모든 테스트;
• 모든 테스트 러너.

2. 버전 관리 시스템(Git)

기술에 대한 간략한 설명

버전 제어가 팀에서나 개인 모두에서 개발에 있어 매우 중요한 부분이라고 말한다면 누구에게도 큰 폭로가 아닐 것입니다. 다양한 소스에 따르면 Git이 가장 인기 있는 대표작이라고 해도 과언이 아닙니다. 버전 관리 시스템은 코드 공유, 버전 저장, 이전 브랜치로 복원, 프로젝트 기록 모니터링, 백업 등 많은 이점을 제공합니다. 각 사항에 대해 자세히 논의하지는 않겠습니다. 여러분이 해당 내용에 매우 익숙하고 일상 업무에 활용하고 계시리라 믿습니다. 하지만 갑자기 그렇지 않다면 이 기사 읽기를 잠시 멈추고 가능한 한 빨리 이 공백을 메우는 것이 좋습니다.

자동화 인프라의 가치

그리고 여기에서 합리적인 질문을 할 수 있습니다. “왜 그가 우리에게 Git에 대해 이야기하는 걸까요? 모두가 이것을 알고 개발 코드와 자동 테스트 코드 모두에 사용합니다.” 전적으로 옳으실 것입니다. 하지만 이 기사에서는 인프라에 대해 이야기하고 있으며 이 섹션은 섹션 7: "IaC(코드형 인프라)"의 미리보기 역할을 합니다. 우리에게 이는 테스트를 포함한 전체 인프라가 코드 형식으로 설명되므로 여기에 버전 관리 시스템을 적용하고 개발 및 자동화 코드와 유사한 이점을 얻을 수도 있음을 의미합니다.

IaC에 대해서는 7단계에서 더 자세히 살펴보겠지만 지금도 로컬 저장소를 생성하여 로컬에서 Git 사용을 시작할 수 있습니다. 인프라에 원격 저장소를 추가하면 큰 그림이 확장됩니다.

인프라 현황 예시

탐색할 링크

• 버전 관리란 무엇입니까?
• 힘내
• 시작하기 - 버전 관리 정보

유사한 도구

• SVN
• 수은제 
• Microsoft TFS(현재 Azure DevOps Services의 일부임)

3. 컨테이너화(Docker)

기술에 대한 간략한 설명

컨테이너화가 게임의 규칙을 어떻게 변화시켰는지 보여주기 위해 수십 년 전으로 돌아가 보겠습니다. 그 당시 사람들은 애플리케이션을 실행하기 위해 서버 시스템을 구입하고 사용했습니다. 하지만 대부분의 경우 필요한 스타트업 자원이 사전에 알려지지 않았습니다. 결과적으로 기업에서는 값비싸고 강력한 서버를 구입하는 데 비용을 지출했지만 이 용량 중 일부는 완전히 활용되지 않았습니다.

진화의 다음 단계는 사용하지 않는 리소스에 대한 비용 낭비 문제를 해결한 가상 머신(VM)이었습니다. 이 기술을 통해 동일한 서버 내에서 애플리케이션을 서로 독립적으로 실행할 수 있어 완전히 격리된 공간을 할당할 수 있게 되었습니다. 그러나 불행히도 모든 기술에는 단점이 있습니다. VM을 실행하려면 CPU, RAM, 스토리지를 소비하는 전체 운영 체제가 필요하며 OS에 따라 라이선스 비용을 고려해야 합니다. 이러한 요소는 로딩 속도에 영향을 미치고 휴대성을 어렵게 만듭니다.

이제 컨테이너화에 이르렀습니다. 다시 한번, 이 기술은 컨테이너가 전체 OS를 사용하지 않기 때문에 이전 문제를 해결하여 많은 양의 리소스를 확보하고 이식성을 위한 빠르고 유연한 솔루션을 제공합니다.

물론 컨테이너화 기술은 새로운 것이 아니며 70년대 후반에 처음 소개되었습니다. 그 당시에는 많은 연구와 개발, 시도가 이루어졌습니다. 하지만 이 기술을 채택하여 대중이 쉽게 접근할 수 있게 만든 것은 Docker였습니다. 요즘 컨테이너에 관해 이야기할 때 대부분의 경우 Docker를 의미합니다. Docker 컨테이너는 Linux 컨테이너를 의미합니다. Windows 및 macOS 시스템을 사용하여 컨테이너를 실행할 수 있지만 이 경우 추가 레이어가 나타난다는 점을 이해하는 것이 중요합니다. 예를 들어 Mac의 Docker는 경량 Linux VM 내에서 컨테이너를 자동으로 실행합니다. 컨테이너 내에서 Android 에뮬레이터 실행을 논의할 때 이 주제로 돌아갈 것이므로 여기에는 더 자세히 논의해야 할 매우 중요한 뉘앙스가 있습니다.

자동화 인프라의 가치

우리는 컨테이너화와 Docker가 훌륭하다는 것을 알았습니다. 모든 도구나 기술은 문제를 해결해야 하기 때문에 이를 자동화의 맥락에서 살펴보겠습니다. UI 테스트의 맥락에서 테스트 자동화의 명백한 문제를 간략하게 설명하겠습니다.

• Selenium, 특히 Appium을 설치할 때 수많은 종속성이 발생합니다.
• 브라우저, 시뮬레이터 및 드라이버 버전 간의 호환성 문제
• 브라우저/시뮬레이터를 위한 격리된 공간이 부족하며 이는 병렬 실행에 특히 중요합니다.
• 10개, 50개, 100개 또는 심지어 1000개의 브라우저를 동시에 실행해야 하는 경우 관리 및 유지 관리가 어렵습니다.

그러나 Selenium은 가장 널리 사용되는 자동화 도구이고 Docker는 가장 널리 사용되는 컨테이너화 도구이므로 위에서 언급한 문제를 해결하기 위한 강력한 도구를 만들기 위해 누군가 두 가지를 결합하려고 시도한 것은 놀라운 일이 아닙니다. 이러한 솔루션을 더 자세히 고려해 보겠습니다. 

도커의 셀레늄 그리드

이 도구는 여러 시스템에서 여러 브라우저를 실행하고 중앙 허브에서 관리하기 위해 Selenium 세계에서 가장 널리 사용됩니다. 시작하려면 최소한 2개의 부분(허브 및 노드)을 등록해야 합니다. 허브는 테스트에서 모든 요청을 수신하고 이를 적절한 노드에 배포하는 중앙 노드입니다. 각 노드에 대해 원하는 브라우저와 버전을 지정하는 등 특정 구성을 구성할 수 있습니다. 그러나 여전히 호환되는 브라우저 드라이버를 직접 관리하고 원하는 노드에 설치해야 합니다. 이러한 이유로 Selenium 그리드는 Linux OS에 설치할 수 없는 브라우저로 작업해야 하는 경우를 제외하고는 순수한 형태로 사용되지 않습니다. 다른 모든 경우의 경우 매우 유연하고 올바른 솔루션은 Docker 이미지를 사용하여 Selenium 그리드 허브 및 노드를 실행하는 것입니다. 이 접근 방식은 이미 설치된 브라우저 및 드라이버의 호환 가능한 버전을 사용하여 필요한 이미지를 선택할 수 있으므로 노드 관리를 크게 단순화합니다.

특히 다수의 노드를 병렬로 실행할 때 안정성에 대한 부정적인 평가에도 불구하고 Selenium 그리드는 여전히 Selenium 테스트를 병렬로 실행하는 데 가장 널리 사용되는 도구입니다. 다양한 병목 현상을 해결하기 위해 이 도구의 다양한 개선 및 수정이 오픈 소스에 지속적으로 나타나고 있다는 점에 유의하는 것이 중요합니다.

웹용 셀레노이드

이 도구는 즉시 사용 가능하며 많은 자동화 엔지니어의 삶을 훨씬 쉽게 만들어 주었기 때문에 Selenium 세계에서 획기적인 것입니다. 우선, 이것은 Selenium 그리드의 또 다른 수정이 아닙니다. 대신 개발자들은 Golang에서 완전히 새로운 버전의 Selenium Hub를 만들었습니다. 이 버전은 다양한 브라우저용 경량 Docker 이미지와 결합되어 테스트 자동화 개발에 박차를 가했습니다. 게다가 Selenium Grid의 경우 필요한 모든 브라우저와 해당 버전을 미리 결정해야 하는데 이는 하나의 브라우저로만 작업할 때 문제가 되지 않습니다. 그러나 지원되는 여러 브라우저의 경우 Selenoid는 '주문형 브라우저' 기능 덕분에 최고의 솔루션입니다. 우리에게 필요한 것은 브라우저를 사용하여 필요한 이미지를 미리 다운로드하고 Selenoid가 상호 작용하는 구성 파일을 업데이트하는 것입니다. Selenoid는 테스트에서 요청을 받은 후 원하는 브라우저를 사용하여 원하는 컨테이너를 자동으로 시작합니다. 테스트가 완료되면 Selenoid는 컨테이너를 폐기하여 향후 요청을 위한 리소스를 확보합니다. 이 접근 방식은 Selenium 그리드에서 자주 발생하는 '노드 성능 저하'라는 잘 알려진 문제를 완전히 제거합니다.

그러나 아쉽게도 셀레노이드는 아직 만능이 아닙니다. '주문형 브라우저' 기능이 있지만 '주문형 리소스' 기능은 아직 사용할 수 없습니다. Selenoid를 사용하려면 물리적 하드웨어나 VM에 배포해야 합니다. 즉, 얼마나 많은 리소스를 할당해야 하는지 미리 알아야 합니다. 나는 이것이 10개, 20개, 심지어 30개의 브라우저를 병렬로 실행하는 소규모 프로젝트에서는 문제가 되지 않는다고 생각합니다. 하지만 100, 500, 1000 등이 필요하다면 어떻게 될까요? 항상 그렇게 많은 리소스를 유지하고 비용을 지불하는 것은 의미가 없습니다. 이 기사의 섹션 5와 6에서는 확장을 통해 회사 비용을 크게 절감할 수 있는 솔루션에 대해 논의합니다.

안드로이드용 셀레노이드

웹 자동화 도구로서 Selenoid가 성공한 후 사람들은 Android에서도 비슷한 것을 원했습니다. 그리고 그것은 일어났습니다 - Selenoid는 Android 지원과 함께 출시되었습니다. 높은 수준의 사용자 관점에서 보면 작동 원리는 웹 자동화와 유사합니다. 유일한 차이점은 브라우저 컨테이너 대신 Selenoid가 Android 에뮬레이터 컨테이너를 실행한다는 것입니다. 내 생각에 이것은 현재 Android 테스트를 병렬로 실행하기 위한 가장 강력한 무료 도구입니다.

저는 이 도구를 정말 좋아하기 때문에 이 도구의 부정적인 측면에 대해 이야기하고 싶지 않습니다. 그러나 여전히 웹 자동화에 적용되고 확장과 관련된 동일한 단점이 있습니다. 이 외에도 처음으로 도구를 설정하는 경우 놀랄 수 있는 한 가지 제한 사항에 대해 더 이야기해야 합니다. Android 이미지를 실행하려면 중첩된 가상화를 지원하는 물리적 머신이나 VM이 필요합니다. 방법 가이드에서는 Linux VM에서 이를 활성화하는 방법을 보여줍니다. 그러나 macOS 사용자이고 Selenoid를 로컬로 배포하려는 경우 Android 테스트를 실행할 수 없습니다. 그러나 '중첩 가상화'가 구성된 상태에서 항상 Linux VM을 로컬로 실행하고 내부에 Selenoid를 배포할 수 있습니다.

인프라 현황 예시

이 기사의 맥락에서 인프라를 설명하기 위해 두 가지 도구를 추가할 것입니다. 이는 웹 테스트용 Selenium 그리드와 Android 테스트용 Selenoid입니다. GitHub 튜토리얼에서는 Selenoid를 사용하여 웹 테스트를 실행하는 방법도 보여 드리겠습니다. 

탐색할 링크

• Docker: 컨테이너가 무엇인가요?
• 도커: 시작하다
• Docker의 5가지 컨테이너 대안
• 셀레늄 그리드
• 셀레늄 도커
• 셀레노이드
• 셀레노이드 Github
• Android 에뮬레이터용 KVM 설정
• Docker 심층 분석 책

유사한 도구

• 다른 컨테이너화 도구도 있지만 Docker가 가장 많이 사용됩니다. 다른 것을 시도하고 싶다면 Selenium 테스트를 병렬로 실행하기 위해 다룬 도구가 기본적으로 작동하지 않는다는 점을 명심하세요.  
• 이미 말했듯이 Selenium 그리드에는 많은 수정 사항이 있습니다. 예를 들면 다음과 같습니다. 잘레늄.

4.CI/CD

기술에 대한 간략한 설명

지속적인 통합의 관행은 개발에서 매우 널리 사용되며 버전 제어 시스템과 동등합니다. 그럼에도 불구하고 용어에 혼란이 있는 것 같습니다. 이 단락에서는 내 관점에서 본 기술의 3가지 수정 사항을 설명하고 싶습니다. 인터넷에서는 해석이 다른 많은 기사를 찾을 수 있으며, 귀하의 의견이 다른 것은 절대적으로 정상입니다. 가장 중요한 것은 동료들과 같은 페이지에 있다는 것입니다.

따라서 CI(지속적 통합), CD(지속적 전달), CD(지속적 배포)라는 3가지 용어가 있습니다. (아래에서는 이 용어를 영어로 사용하겠습니다.). 각 수정은 개발 파이프라인에 몇 가지 추가 단계를 추가합니다. 그러나 그 말은 끊임없는 (계속)이 가장 중요합니다. 이 맥락에서 우리는 중단이나 수동 개입 없이 처음부터 끝까지 일어나는 일을 의미합니다. 이런 맥락에서 CI&CD와 CD를 살펴보자.

• 지속적인 통합 이것이 진화의 초기 단계이다. 새 코드를 서버에 제출한 후 변경 사항이 괜찮다는 빠른 피드백을 받을 것으로 기대합니다. 일반적으로 CI에는 정적 코드 분석 도구 및 단위/내부 API 테스트 실행이 포함되어 있으며 이를 통해 몇 초/분 내에 코드에 대한 정보를 얻을 수 있습니다.
• 연속 배달 통합/UI 테스트를 실행하는 고급 단계입니다. 그러나 이 단계에서는 CI만큼 빨리 결과를 얻을 수 없습니다. 첫째, 이러한 유형의 테스트는 완료하는 데 시간이 더 오래 걸립니다. 둘째, 출시하기 전에 변경 사항을 테스트/스테이징 환경에 배포해야 합니다. 또한 모바일 개발에 관해 이야기하는 경우 애플리케이션 빌드를 생성하는 추가 단계가 나타납니다.
• 지속적인 배포 이전 단계에서 모든 승인 테스트를 통과한 경우 변경 사항을 프로덕션에 자동으로 릴리스한다고 가정합니다. 이 외에도 릴리스 단계 이후에는 프로덕션에서 스모크 테스트를 실행하고 관심 지표를 수집하는 등 다양한 단계를 구성할 수 있습니다. 지속적인 배포는 자동화된 테스트를 통해 적용 범위가 양호한 경우에만 가능합니다. 테스트를 포함하여 수동 개입이 필요한 경우 더 이상 이 작업을 수행할 수 없습니다. 끊임없는 (마디 없는). 그러면 우리 파이프라인은 Continuous Delivery 관행만 준수한다고 말할 수 있습니다.

자동화 인프라의 가치

이 섹션에서는 엔드투엔드 UI 테스트에 관해 이야기할 때 변경 사항 및 관련 서비스를 테스트 환경에 배포해야 함을 의미한다는 점을 명확히 해야 합니다. 지속적인 통합 - 프로세스는 이 작업에 적용되지 않으며 최소한 지속적인 전달 방식을 구현해야 합니다. 지속적인 배포는 프로덕션에서 UI 테스트를 실행하려는 경우 UI 테스트의 맥락에서도 의미가 있습니다.

그리고 아키텍처 변경에 대한 그림을 보기 전에 GitLab CI에 대해 몇 마디 말씀드리고 싶습니다. 다른 CI/CD 도구와 달리 GitLab은 원격 저장소와 기타 여러 추가 기능을 제공합니다. 따라서 GitLab은 CI 그 이상입니다. 여기에는 소스 코드 관리, 민첩한 관리, CI/CD 파이프라인, 로깅 도구 및 즉시 사용 가능한 메트릭 수집이 포함됩니다. GitLab 아키텍처는 Gitlab CI/CD와 GitLab Runner로 구성됩니다. 공식 홈페이지에 있는 간단한 설명은 다음과 같습니다.

Gitlab CI/CD는 데이터베이스에 상태를 저장하고, 프로젝트/빌드를 관리하고, 사용자 인터페이스를 제공하는 API가 포함된 웹 애플리케이션입니다. GitLab Runner는 빌드를 처리하는 애플리케이션입니다. 별도로 배포할 수 있으며 API를 통해 GitLab CI/CD와 함께 작동합니다. 테스트를 실행하려면 Gitlab 인스턴스와 Runner가 모두 필요합니다.

인프라 현황 예시

탐색할 링크

• 마틴 파울러: 지속적인 통합
• GitLab CI / CD
• 지속적 통합 도서
• 지속적인 전달 책

유사한 도구

• 젠킨스
• TeamCity
• 트래비스 
• 그리고 많은 다른 사람들

5. 클라우드 플랫폼

기술에 대한 간략한 설명

이번 섹션에서는 '퍼블릭 클라우드'라는 대중적인 트렌드에 대해 이야기하겠습니다. 위에서 설명한 가상화 및 컨테이너화 기술이 제공하는 엄청난 이점에도 불구하고 여전히 컴퓨팅 리소스가 필요합니다. 회사는 값비싼 서버를 구입하거나 데이터 센터를 임대하지만, 이 경우 필요한 리소스의 양, 연중무휴 24시간 사용할지, 어떤 목적으로 사용할지 계산해야 합니다(때로는 비현실적임). 예를 들어 프로덕션에는 연중무휴 7시간 실행되는 서버가 필요하지만 근무 시간 외에 테스트하려면 유사한 리소스가 필요합니까? 또한 수행되는 테스트 유형에 따라 다릅니다. 다음 날 결과를 얻기 위해 업무 외 시간에 실행할 부하/스트레스 테스트를 예로 들 수 있습니다. 그러나 종단 간 자동화 테스트에는 확실히 XNUMX/XNUMX 서버 가용성이 필요하지 않으며 특히 수동 테스트 환경에는 필요하지 않습니다. 그러한 상황에서는 필요에 따라 필요한 만큼의 리소스를 확보하여 사용하고 더 이상 필요하지 않을 때 지불을 중단하는 것이 좋습니다. 게다가 마우스 클릭 몇 번이나 스크립트 몇 개만 실행하면 바로 받아볼 수 있다는 점도 좋을 것 같아요. 이것이 퍼블릭 클라우드가 사용되는 이유입니다. 정의를 살펴보겠습니다:

“퍼블릭 클라우드는 제XNUMX자 제공업체가 공용 인터넷을 통해 제공하는 컴퓨팅 서비스로 정의되며 이를 사용하거나 구매하려는 누구나 사용할 수 있습니다. 무료이거나 주문형으로 판매될 수 있으므로 고객은 소비하는 CPU 주기, 스토리지 또는 대역폭에 대한 사용량에 대해서만 비용을 지불할 수 있습니다."

퍼블릭 클라우드는 비싸다는 의견이 있다. 그러나 그들의 핵심 아이디어는 회사 비용을 줄이는 것입니다. 앞서 언급했듯이 퍼블릭 클라우드를 사용하면 필요에 따라 리소스를 확보하고 사용한 시간만큼만 비용을 지불할 수 있습니다. 또한 직원이 급여를 받고 전문가도 값 비싼 자원이라는 사실을 때때로 잊어 버립니다. 퍼블릭 클라우드는 인프라 지원을 훨씬 쉽게 만들어 엔지니어가 더 중요한 작업에 집중할 수 있다는 점을 고려해야 합니다. 

자동화 인프라의 가치

엔드투엔드 UI 테스트에는 어떤 구체적인 리소스가 필요합니까? 기본적으로 이는 브라우저와 에뮬레이터를 실행하기 위한 가상 머신 또는 클러스터(다음 섹션에서 Kubernetes에 대해 설명하겠습니다)입니다. 동시에 실행하려는 브라우저와 에뮬레이터가 많을수록 더 많은 CPU와 메모리가 필요하고 그에 대해 지불해야 하는 비용도 더 많아집니다. 따라서 테스트 자동화 측면에서 퍼블릭 클라우드를 사용하면 필요에 따라 많은 수(100, 200, 1000...)의 브라우저/에뮬레이터를 실행하고, 테스트 결과를 최대한 빨리 얻을 수 있으며, 리소스 집약적인 이러한 비용을 지불하지 않아도 됩니다. 힘. 

가장 인기 있는 클라우드 제공업체는 Amazon Web Services(AWS), Microsoft Azure, Google Cloud Platform(GCP)입니다. 방법 가이드에서는 GCP 사용 방법에 대한 예를 제공하지만 일반적으로 자동화 작업에 무엇을 사용하는지는 중요하지 않습니다. 모두 거의 동일한 기능을 제공합니다. 일반적으로 공급자를 선택하기 위해 경영진은 회사의 전반적인 인프라와 비즈니스 요구 사항에 중점을 두는데, 이는 이 문서의 범위를 벗어납니다. 자동화 엔지니어의 경우 Sauce Labs, BrowserStack, BitBar 등과 같은 테스트 목적으로 특별히 클라우드 플랫폼을 사용하는 것과 클라우드 공급자의 사용을 비교하는 것이 더 흥미로울 것입니다. 그럼 우리도 해보자! 제 생각에는 Sauce Labs가 가장 유명한 클라우드 테스트 팜이기 때문에 비교를 위해 사용했습니다. 

자동화 목적을 위한 GCP와 Sauce Labs:

8개의 웹 테스트와 8개의 Android 테스트를 동시에 실행해야 한다고 가정해 보겠습니다. 이를 위해 GCP를 사용하고 Selenoid로 2개의 가상 머신을 실행하겠습니다. 첫 번째에서는 브라우저를 사용하여 8개의 컨테이너를 생성합니다. 두 번째에는 에뮬레이터가 포함된 8개의 컨테이너가 있습니다. 가격을 살펴 보겠습니다.  

Chrome으로 하나의 컨테이너를 실행하려면 다음이 필요합니다. n1-표준-1 자동차. 안드로이드의 경우에는 그렇겠지만 n1-표준-4 하나의 에뮬레이터에 대해. 사실 더 유연하고 저렴한 방법은 CPU/메모리에 대한 특정 사용자 값을 설정하는 것이지만 현재로서는 Sauce Labs와 비교할 때 이것이 중요하지 않습니다.

Sauce Labs 사용 요금은 다음과 같습니다.

나는 당신이 이미 그 차이를 알아차렸다고 생각합니다. 그러나 나는 여전히 우리 작업에 대한 계산이 포함된 표를 제공할 것입니다:

필수 리소스
몬트리
근로 시간(오전 8시 - 오후 8시)
근로 시간+선점형

웹용 GCP
n1-표준-1 x 8 = n1-표준-8
$194.18
23일 * 12시간 * 0.38 = $104.88 
23일 * 12시간 * 0.08 = $22.08

웹용 소스 연구소
가상 Cloud8 병렬 테스트
$1.559
-
-

안드로이드용 GCP
n1-표준-4 x 8: n1-표준-16
$776.72
23일 * 12시간 * 1.52 = $419.52 
23일 * 12시간 * 0.32 = $88.32

Android용 소스 연구소
Real Device Cloud 8 병렬 테스트
$1.999
-
-

보시다시피 비용 차이는 엄청납니다. 특히 XNUMX시간의 작업 기간 동안에만 테스트를 실행하는 경우 더욱 그렇습니다. 하지만 선점형 머신을 사용하면 비용을 더욱 절감할 수 있습니다. 그것은 무엇입니까?

선점형 VM은 일반 인스턴스보다 훨씬 저렴한 가격으로 생성하고 실행할 수 있는 인스턴스입니다. 그러나 Compute Engine은 다른 작업을 위해 해당 리소스에 액세스해야 하는 경우 이러한 인스턴스를 종료(선점)할 수 있습니다. 선점형 인스턴스는 Compute Engine 용량의 초과이므로 사용량에 따라 가용성이 달라집니다.

앱이 내결함성이 있고 가능한 인스턴스 선점을 견딜 수 있는 경우 선점형 인스턴스를 사용하면 Compute Engine 비용을 크게 줄일 수 있습니다. 예를 들어 일괄 처리 작업은 선점형 인스턴스에서 실행될 수 있습니다. 처리 중에 해당 인스턴스 중 일부가 종료되면 작업 속도가 느려지지만 완전히 중지되지는 않습니다. 선점형 인스턴스는 기존 인스턴스에 추가 워크로드를 배치하지 않고 추가 일반 인스턴스에 대해 전체 가격을 지불하지 않고도 일괄 처리 작업을 완료합니다.

그리고 아직 끝나지 않았습니다! 실제로 12시간 동안 쉬지 않고 테스트를 진행하는 사람은 없을 것이라고 생각합니다. 그렇다면 가상 머신이 필요하지 않을 때 자동으로 시작하고 중지할 수 있습니다. 실제 이용시간은 하루 6시간으로 단축될 수 있습니다. 그러면 우리 작업에 따른 지불금은 11개 브라우저에 대해 월 8달러로 줄어들 것입니다. 정말 멋지지 않나요? 그러나 선점형 머신의 경우, 이러한 상황이 소프트웨어에서 제공되고 처리될 수 있더라도 중단과 불안정성에 주의하고 대비해야 합니다. 그것은 가치!

하지만 결코 '클라우드 테스트 팜을 사용하지 마세요'라고 말하는 것은 아닙니다. 그들은 많은 장점을 가지고 있습니다. 우선, 이는 단순한 가상 머신이 아니라 원격 액세스, 로그, 스크린샷, 비디오 녹화, 다양한 브라우저 및 물리적 모바일 장치 등 기본 기능 세트를 갖춘 본격적인 테스트 자동화 솔루션입니다. 많은 상황에서 이는 필수적인 세련된 대안이 될 수 있습니다. 테스트 플랫폼은 퍼블릭 클라우드가 Linux/Windows 시스템만 제공할 수 있는 IOS 자동화에 특히 유용합니다. 하지만 다음 기사에서는 iOS에 대해 이야기하겠습니다. 항상 상황을 살펴보고 작업부터 시작하는 것이 좋습니다. 어떤 경우에는 퍼블릭 클라우드를 사용하는 것이 더 저렴하고 효율적이며, 다른 경우에는 테스트 플랫폼이 확실히 지출한 비용만큼 가치가 있습니다.

인프라 현황 예시

탐색할 링크

• GCP
• GCP: 선점형
• GCP: VM 가격 책정
• 소스랩스
• 클라우드 제공업체 비교

유사한 도구:

• AWS 
• 하늘빛

6. 오케스트레이션

기술에 대한 간략한 설명

좋은 소식이 있습니다. 기사가 거의 끝났습니다! 현재 우리의 자동화 인프라는 Docker 지원 도구인 Selenium 그리드 및 Selenoid를 사용하여 GitLab CI를 통해 병렬로 실행하는 웹 및 Android 테스트로 구성되어 있습니다. 또한 GCP를 통해 생성된 가상 머신을 사용하여 브라우저와 에뮬레이터가 포함된 컨테이너를 호스팅합니다. 비용을 절감하기 위해 이러한 가상 머신은 요청 시에만 시작하고 테스트가 수행되지 않을 때는 중지합니다. 인프라를 개선할 수 있는 다른 것이 있습니까? 대답은 그렇습니다! 쿠버네티스(K8s)를 만나보세요!

먼저 오케스트레이션, 클러스터, 쿠버네티스라는 단어가 어떻게 연관되어 있는지 살펴보겠습니다. 높은 수준에서 오케스트레이션은 애플리케이션을 배포하고 관리하는 시스템입니다. 테스트 자동화를 위한 컨테이너화된 애플리케이션은 Selenium 그리드와 Selenoid입니다. Docker와 K8은 서로를 보완합니다. 첫 번째는 애플리케이션 배포에 사용되고 두 번째는 오케스트레이션에 사용됩니다. K8s는 클러스터입니다. 클러스터의 임무는 VM을 노드로 사용하는 것입니다. 이를 통해 하나의 서버(클러스터) 내에 다양한 기능, 프로그램 및 서비스를 설치할 수 있습니다. 노드 중 하나라도 실패하면 다른 노드가 이를 선택하여 애플리케이션의 중단 없는 작동을 보장합니다. 이 외에도 K8s에는 확장과 관련된 중요한 기능이 있으므로 로드 및 설정된 제한에 따라 최적의 리소스 양을 자동으로 얻습니다.

실제로 Kubernetes를 처음부터 수동으로 배포하는 것은 결코 쉬운 작업이 아닙니다. 유명한 How-To 가이드인 "Kubernetes The Hard Way" 링크를 남겨드릴테니 관심 있으신 분들은 실습해 보시면 됩니다. 그러나 다행히도 대체 방법과 도구가 있습니다. 가장 쉬운 방법은 GCP에서 Google Kubernetes Engine(GKE)을 사용하는 것입니다. 이를 통해 몇 번의 클릭만으로 미리 만들어진 클러스터를 얻을 수 있습니다. 학습을 시작할 때 이 접근 방식을 사용하는 것이 좋습니다. 내부 구성 요소를 함께 통합하는 방법을 배우는 대신 작업에 K8을 사용하는 방법을 배우는 데 집중할 수 있기 때문입니다. 

자동화 인프라의 가치

K8s가 제공하는 몇 가지 중요한 기능을 살펴보겠습니다.

• 애플리케이션 배포: VM 대신 다중 노드 클러스터 사용
• 동적 확장: 요청 시에만 사용되는 리소스 비용을 줄입니다.
• 자가 치유: 포드 자동 복구(그 결과 컨테이너도 복원됨)
• 다운타임 없이 업데이트 롤아웃 및 변경 사항 롤백: 도구, 브라우저 및 에뮬레이터를 업데이트해도 현재 사용자의 작업이 중단되지 않습니다.

하지만 K8s는 아직 만능은 아니다. 우리가 고려하고 있는 도구(Selenium 그리드, Selenoid)의 맥락에서 모든 장점과 한계를 이해하기 위해 K8s의 구조에 대해 간략하게 논의하겠습니다. 클러스터에는 마스터 노드와 작업자 노드라는 두 가지 유형의 노드가 포함되어 있습니다. 마스터 노드는 관리, 배포 및 일정 결정을 담당합니다. 작업자 노드는 애플리케이션이 실행되는 곳입니다. 노드에는 컨테이너 런타임 환경도 포함되어 있습니다. 우리의 경우 컨테이너 관련 작업을 담당하는 Docker입니다. 그러나 다음과 같은 대체 솔루션도 있습니다. 컨테이너. 크기 조정이나 자가 복구는 컨테이너에 직접 적용되지 않는다는 점을 이해하는 것이 중요합니다. 이는 컨테이너를 포함하는 포드 수를 추가/감소하여 구현됩니다(일반적으로 포드당 하나의 컨테이너이지만 작업에 따라 더 많을 수 있음). 상위 계층 구조는 작업자 노드로 구성되며, 그 내부에는 포드가 있고 내부에는 컨테이너가 올라갑니다.

확장 기능은 핵심이며 클러스터 노드 풀 내의 노드와 노드 내의 포드 모두에 적용될 수 있습니다. 노드와 Pod 모두에 적용되는 크기 조정에는 두 가지 유형이 있습니다. 첫 번째 유형은 수평입니다. 노드/포드 수를 늘려 크기 조정이 발생합니다. 이 유형이 더 바람직합니다. 따라서 두 번째 유형은 수직입니다. 크기 조정은 개수가 아닌 노드/포드의 크기를 늘려 수행됩니다.

이제 위의 용어와 관련하여 도구를 살펴보겠습니다.

셀레늄 그리드

앞서 언급했듯이 Selenium 그리드는 매우 인기 있는 도구이며 컨테이너화되었다는 것은 놀라운 일이 아닙니다. 따라서 K8에 셀레늄 그리드를 배치할 수 있다는 것은 놀라운 일이 아닙니다. 이를 수행하는 방법의 예는 공식 K8s 저장소에서 찾을 수 있습니다. 늘 그렇듯이 섹션 끝에 링크를 첨부합니다. 또한 방법 가이드에서는 Terraform에서 이 작업을 수행하는 방법을 보여줍니다. 브라우저 컨테이너가 포함된 포드 수를 확장하는 방법에 대한 지침도 있습니다. 그러나 K8s의 자동 스케일링 기능은 아직 완전히 명확한 작업은 아닙니다. 공부를 시작했을 때 실용적인 지침이나 권장 사항을 찾지 못했습니다. DevOps 팀의 지원을 받아 여러 연구와 실험을 거친 후, 우리는 하나의 작업자 노드 내에 있는 하나의 포드 내에서 필요한 브라우저로 컨테이너를 키우는 접근 방식을 선택했습니다. 이 방법을 사용하면 노드 수를 늘려 노드의 수평 확장 전략을 적용할 수 있습니다. 나는 이것이 미래에 변하기를 바라며, 특히 내부 아키텍처가 변경된 Selenium Grid 4가 출시된 이후에 더 나은 접근 방식과 기성 솔루션에 대한 더 많은 설명을 보게 될 것입니다.

셀레노이드:

K8s의 셀레노이드 배치는 현재 가장 큰 실망입니다. 호환되지 않습니다. 이론적으로는 Pod 내부에 Selenoid 컨테이너를 생성할 수 있지만 Selenoid가 브라우저를 사용하여 컨테이너를 시작하면 여전히 동일한 Pod 내에 있게 됩니다. 이로 인해 확장이 불가능해지며 결과적으로 클러스터 내부의 Selenoid 작업은 가상 머신 내부 작업과 다르지 않습니다. 이야기의 끝.

달:

개발자들은 Selenoid로 작업할 때 이러한 병목 현상을 알고 Moon이라는 더욱 강력한 도구를 출시했습니다. 이 도구는 원래 Kubernetes와 함께 작동하도록 설계되었으므로 자동 크기 조정 기능을 사용할 수 있고 사용해야 합니다. 게다가 지금은 그렇다고 말하고 싶다. 단 하나의 기본 K8s 클러스터를 즉시 지원하는 Selenium 세계의 도구(더 이상 사용할 수 없습니다. 다음 도구를 참조하세요. ). 이러한 지원을 제공하는 Moon의 주요 기능은 다음과 같습니다. 

완전히 무국적자입니다. Selenoid는 현재 실행 중인 브라우저 세션에 대한 정보를 메모리에 저장합니다. 어떤 이유로 프로세스가 충돌하면 실행 중인 모든 세션이 손실됩니다. 반대로 Moon에는 내부 상태가 없으며 데이터 센터 전체에 복제될 수 있습니다. 하나 이상의 복제본이 다운되더라도 브라우저 세션은 계속 유지됩니다.

따라서 Moon은 훌륭한 솔루션이지만 한 가지 문제가 있습니다. 무료가 아닙니다. 가격은 세션 수에 따라 다릅니다. 무료로 0~4개의 세션만 실행할 수 있는데 이는 특별히 유용하지 않습니다. 하지만 5번째 세션부터는 각 세션당 500달러를 지불해야 합니다. 회사마다 상황이 다를 수 있지만 우리의 경우 Moon을 사용하는 것은 의미가 없습니다. 위에서 설명한 대로 필요에 따라 Selenium Grid를 사용하여 VM을 실행하거나 클러스터의 노드 수를 늘릴 수 있습니다. 약 500개의 파이프라인에 대해 5개의 브라우저를 시작하고 테스트가 완료된 후 모든 리소스를 중지합니다. Moon을 사용했다면 테스트를 아무리 자주 실행하더라도 월 2500 x XNUMX = $XNUMX를 추가로 지불해야 합니다. 다시 말하지만, Moon을 사용하지 말라는 뜻은 아닙니다. 예를 들어, 조직에 많은 프로젝트/팀이 있고 모든 사람을 위한 거대한 공통 클러스터가 필요한 경우 작업에 있어서 이는 필수적인 솔루션이 될 수 있습니다. 항상 그렇듯이 마지막에 링크를 남겨두고 작업 맥락에서 필요한 모든 계산을 수행하는 것이 좋습니다.

칼리스토: (주목! 이 내용은 원본 기사에는 없으며 러시아어 번역본에만 포함되어 있습니다.)

제가 말했듯이 Selenium은 매우 인기 있는 도구이며 IT 분야는 매우 빠르게 발전하고 있습니다. 번역 작업을 하는 동안 Callisto라는 새로운 유망 도구가 웹에 나타났습니다(안녕하세요 Cypress 및 기타 Selenium 킬러들). K8s와 기본적으로 작동하며 노드 전체에 분산된 Pod에서 Selenoid 컨테이너를 실행할 수 있습니다. 자동 크기 조정을 포함하여 모든 것이 즉시 작동합니다. 환상적이지만 테스트가 필요합니다. 저는 이미 이 도구를 배포하고 여러 가지 실험을 실행했습니다. 하지만 결론을 내리기에는 너무 이르며, 장거리 결과를 받은 후 향후 기사에서 검토할 것입니다. 지금은 독립적인 연구를 위한 링크만 남겨 두겠습니다.  

인프라 현황 예시

탐색할 링크

• 쿠버네티스: 설정
• 쿠버네티스: 어려운 길
• 쿠버네티스: 셀레늄
• GCP: 쿠버네티스 엔진
• 달
• 쿠버네티스 책
• Kubernetes를 사용한 분산 자동화
• 셀레늄 그리드 4
• 칼리스토 GitHub
• Wrike TechClub (칼리스토)

유사한 도구

• 도커 떼 
• 마라톤 

7. 코드형 인프라(IaC)

기술에 대한 간략한 설명

이제 마지막 섹션에 이르렀습니다. 일반적으로 이 기술 및 관련 작업은 자동화 엔지니어의 책임이 아닙니다. 그리고 여기에는 이유가 있습니다. 첫째, 많은 조직에서 인프라 문제는 DevOps 부서의 통제하에 있으며 개발 팀은 파이프라인이 작동하게 만드는 요소와 파이프라인과 연결된 모든 것이 어떻게 지원되어야 하는지에 대해 실제로 관심을 두지 않습니다. 둘째, 솔직히 말해서 IaC(Infrastructure as Code) 실행은 아직 많은 기업에서 채택되지 않았습니다. 그러나 이는 확실히 대중적인 트렌드가 되었으며 이와 관련된 프로세스, 접근 방식 및 도구에 참여하는 것이 중요합니다. 아니면 최소한 최신 정보를 유지하세요.

이 접근 방식을 사용하게 된 동기부터 시작해 보겠습니다. GitlabCI에서 테스트를 실행하려면 최소한 Gitlab Runner를 실행하는 데 필요한 리소스가 필요하다는 점을 이미 논의했습니다. 그리고 브라우저/에뮬레이터로 컨테이너를 실행하려면 VM 또는 클러스터를 예약해야 합니다. 리소스 테스트 외에도 데이터베이스, 자동 일정, 네트워크 구성, 로드 밸런서, 사용자 권한 등을 포함하는 개발, 준비, 프로덕션 환경을 지원하려면 상당한 용량이 필요합니다. 중요한 문제는 이를 모두 지원하는 데 필요한 노력입니다. 변경하고 업데이트를 출시할 수 있는 방법에는 여러 가지가 있습니다. 예를 들어 GCP 컨텍스트에서는 브라우저의 UI 콘솔을 사용하고 버튼을 클릭하여 모든 작업을 수행할 수 있습니다. 대안은 API 호출을 사용하여 클라우드 항목과 상호작용하거나 gcloud 명령줄 유틸리티를 사용하여 원하는 조작을 수행하는 것입니다. 그러나 매우 많은 수의 다양한 엔터티와 인프라 요소로 인해 모든 작업을 수동으로 수행하는 것이 어렵거나 심지어 불가능해집니다. 게다가 이러한 모든 수동 작업은 제어할 수 없습니다. 실행 전에 검토를 위해 제출할 수 없으며, 버전 관리 시스템을 사용하고, 사고로 이어진 변경 사항을 신속하게 롤백할 수 없습니다. 이러한 문제를 해결하기 위해 엔지니어들은 자동 bash/shell 스크립트를 생성하고 생성했는데, 이는 절차적 스타일에서 빠르게 읽고, 이해하고, 유지 관리하고 수정하기가 쉽지 않기 때문에 이전 방법보다 크게 나아지지 않았습니다.

이 기사와 How-to 가이드에서는 IaC 실습과 관련된 두 가지 도구를 사용합니다. Terraform과 Ansible이 그것이다. 어떤 사람들은 기능이 비슷하고 상호 교환이 가능하기 때문에 동시에 사용하는 것이 의미가 없다고 생각합니다. 그러나 사실 처음에는 완전히 다른 작업이 주어졌습니다. 그리고 이러한 도구가 서로를 보완해야 한다는 사실은 HashiCorp와 RedHat을 대표하는 개발자의 공동 프레젠테이션에서 확인되었습니다. 개념적 차이점은 Terraform이 서버 자체를 관리하기 위한 프로비저닝 도구라는 것입니다. Ansible은 이러한 서버에 소프트웨어를 설치, 구성 및 관리하는 작업을 수행하는 구성 관리 도구입니다.

이러한 도구의 또 다른 주요 특징은 코딩 스타일입니다. Bash 및 Ansible과 달리 Terraform은 실행 결과로 달성할 원하는 최종 상태에 대한 설명을 기반으로 하는 선언적 스타일을 사용합니다. 예를 들어 10개의 VM을 만들고 Terraform을 통해 변경 사항을 적용하려는 경우 10개의 VM을 얻게 됩니다. 스크립트를 다시 실행하면 이미 10개의 VM이 있으므로 아무 일도 일어나지 않으며 Terraform은 인프라의 현재 상태를 상태 파일에 저장하기 때문에 이에 대해 알고 있습니다. 그러나 Ansible은 절차적 접근 방식을 사용하므로 10개의 VM을 생성하도록 요청하면 처음 시작할 때 Terraform과 유사한 10개의 VM을 얻게 됩니다. 그러나 다시 시작한 후에는 이미 20개의 VM이 있게 됩니다. 이것이 중요한 차이점입니다. 절차적 스타일에서는 현재 상태를 저장하지 않고 단순히 수행해야 하는 일련의 단계를 설명합니다. 물론 다양한 상황을 처리하고 리소스 존재 여부와 현재 상태에 대한 여러 검사를 추가할 수 있지만 이러한 논리를 제어하는 ​​데 시간을 낭비하고 노력하는 것은 의미가 없습니다. 게다가 실수할 위험도 높아집니다. 

위의 모든 내용을 요약하면 Terraform과 선언적 표기법이 서버 프로비저닝에 더 적합한 도구라는 결론을 내릴 수 있습니다. 하지만 구성 관리 작업을 Ansible에 위임하는 것이 더 좋습니다. 이쯤에서 자동화의 맥락에서 사용 사례를 살펴보겠습니다.

자동화 인프라의 가치

여기서 이해해야 할 유일한 중요한 점은 테스트 자동화 인프라가 전체 회사 인프라의 일부로 간주되어야 한다는 것입니다. 이는 모든 IaC 관행이 전체 조직의 리소스에 전역적으로 적용되어야 함을 의미합니다. 이에 대한 책임은 귀하의 프로세스에 따라 다릅니다. DevOps 팀은 이러한 문제에 대해 더 많은 경험을 갖고 있으며, 무슨 일이 일어나고 있는지에 대한 전체 그림을 봅니다. 그러나 QA 엔지니어는 빌딩 자동화 프로세스와 파이프라인 구조에 더 많이 관여하므로 필요한 모든 변경 사항과 개선 기회를 더 잘 확인할 수 있습니다. 가장 좋은 방법은 함께 일하고 지식과 아이디어를 교환하여 예상되는 결과를 얻는 것입니다. 

다음은 이전에 논의한 테스트 자동화 및 도구의 맥락에서 Terraform 및 Ansible을 사용하는 몇 가지 예입니다.

1. Terraform을 사용하여 VM 및 클러스터에 필요한 특성과 매개변수를 설명합니다.

2. Ansible을 사용하여 테스트에 필요한 도구(docker, Selenoid, Selenium Grid)를 설치하고 필요한 브라우저/에뮬레이터 버전을 다운로드합니다.

3. Terraform을 사용하여 GitLab Runner가 실행될 VM의 특성을 설명합니다.

4. Ansible을 사용하여 GitLab Runner 및 필요한 관련 도구를 설치하고 설정 및 구성을 지정합니다.

인프라 현황 예시

탐색할 링크:

• 테라 폼
• 책임감있는
• Ansible과 Terraform을 함께 사용하면 더 좋습니다
• Terraform 종합 가이드
• Chef, Puppet, Ansible, SaltStack 또는 CloudFormation이 아닌 Terraform을 사용하는 이유
• GCP: IaC

유사한 도구

• 요리사
• 인형
• SaltStack
• 방랑자

요약해보자!

단계
Technology
도구
자동화 인프라의 가치

1
로컬 러닝
Node.js, 셀레늄, Appium

• 웹과 모바일에서 가장 널리 사용되는 도구
• 다양한 언어 및 플랫폼 지원(Node.js 포함)

2
버전 관리 시스템 
힘내

• 개발 코드와 유사한 이점

3
컨테이너화
Docker, Selenium 그리드, Selenoid(웹, Android)

• 병렬로 테스트 실행
• 격리된 환경
• 간단하고 유연한 버전 업그레이드
• 사용하지 않는 리소스를 동적으로 중지
• 간편한 설정

4
CI/CD
깃랩 CI

• 파이프라인의 일부를 테스트합니다.
• 빠른 피드백
• 회사/팀 전체에 대한 가시성

5
클라우드 플랫폼
Google Cloud Platform

• 주문형 리소스(필요할 때만 비용 지불)
• 관리 및 업데이트가 용이함
• 모든 리소스에 대한 가시성 및 제어

6
오케스트레이션
Kubernetes
포드 내부에 브라우저/에뮬레이터가 있는 컨테이너의 맥락에서:

• 스케일링/자동 스케일링
• 자가 치유
• 중단 없는 업데이트 및 롤백

7
코드형 인프라(IaC)
테라폼, 앤서블

• 개발 인프라와 유사한 이점
• 코드 버전 관리의 모든 이점
• 변경 및 유지 관리가 용이함
• 완전 자동화

마인드맵 다이어그램: 인프라의 진화

1단계: 로컬

2단계: VCS

3단계: 컨테이너화 

4단계: CI/CD 

5단계: 클라우드 플랫폼

6단계:오케스트레이션

7단계: IaC

다음은 뭐지?

그래서, 이것으로 기사가 끝납니다. 하지만 결론적으로 나는 당신과 몇 가지 합의를 하고 싶습니다.

귀하의 측면에서
서두에서 말했듯이, 이 글이 실무에 활용되고, 얻은 지식을 실제 업무에 적용하는 데 도움이 되기를 바랍니다. 다시 추가해요 실무 가이드 링크.

하지만 그 후에도 멈추지 말고 연습하고 관련 링크와 책을 공부하고 회사에서 어떻게 작동하는지 알아보고 개선할 수 있는 곳을 찾아 참여하세요. 행운을 빌어요!

내 쪽에서

제목을 보면 이것이 첫 번째 부분에 불과하다는 것을 알 수 있습니다. 꽤 큰 것으로 판명되었음에도 불구하고 여기서는 여전히 중요한 주제를 다루지 않습니다. 두 번째 부분에서는 IOS의 맥락에서 자동화 인프라를 살펴볼 계획입니다. macOS 시스템에서만 iOS 시뮬레이터를 실행하는 것에 대한 Apple의 제한으로 인해 당사의 솔루션 범위가 좁아졌습니다. 예를 들어 Docker를 사용하여 시뮬레이터를 실행하거나 퍼블릭 클라우드를 사용하여 가상 머신을 실행할 수 없습니다. 그러나 이것이 다른 대안이 없다는 것을 의미하지는 않습니다. 고급 솔루션과 최신 도구를 통해 최신 정보를 제공하도록 노력하겠습니다!

그리고 모니터링과 관련된 꽤 큰 주제에 대해서는 언급하지 않았습니다. 3부에서는 가장 널리 사용되는 인프라 모니터링 도구와 고려해야 할 데이터 및 지표를 살펴보겠습니다.

그리고 마지막으로. 앞으로는 테스트 인프라 구축과 인기 도구에 대한 동영상 강좌를 공개할 계획입니다. 현재 인터넷에는 DevOps에 대한 강좌와 강의가 꽤 많이 있지만, 모든 자료는 테스트 자동화가 아닌 개발 맥락에서 제시됩니다. 이 문제에 관해서는 그러한 과정이 테스터 및 자동화 엔지니어 커뮤니티에 흥미롭고 가치가 있는지에 대한 피드백이 정말로 필요합니다. 미리 감사드립니다!

출처 : habr.com