Translated 2022 day56-76 to korean
This commit is contained in:
Me1e
parent
524d8ee942
commit
ef5e237798
133
2022/ko/Days/day56.md
Normal file
133
2022/ko/Days/day56.md
Normal file
@ -0,0 +1,133 @@
|
|||||||
|
---
|
||||||
|
title: '#90DaysOfDevOps - The Big Picture: IaC - Day 56'
|
||||||
|
published: false
|
||||||
|
description: 90DaysOfDevOps - The Big Picture IaC
|
||||||
|
tags: 'devops, 90daysofdevops, learning'
|
||||||
|
cover_image: null
|
||||||
|
canonical_url: null
|
||||||
|
id: 1048709
|
||||||
|
---
|
||||||
|
|
||||||
|
## 큰 그림: IaC
|
||||||
|
|
||||||
|
인간은 실수를 합니다! 자동화를 도입해야 합니다!
|
||||||
|
|
||||||
|
현재 시스템을 어떻게 구축하고 계신가요?
|
||||||
|
|
||||||
|
오늘 물리 머신, 가상 머신, 클라우드 VM, 클라우드 PaaS 등 모든 것을 잃게 된다면 어떤 계획을 세우시겠습니까?
|
||||||
|
|
||||||
|
모든 것을 교체하는 데 얼마나 걸리나요?
|
||||||
|
|
||||||
|
IaC는 이를 테스트할 수 있는 동시에 이를 수행할 수 있는 솔루션을 제공하며, 이를 백업 및 복구와 혼동해서는 안 되지만 인프라와 환경, 플랫폼 측면에서 이를 스핀업하여 가축과 반려동물로 취급할 수 있어야 합니다.
|
||||||
|
|
||||||
|
결론은 코드를 사용하여 전체 환경을 재구축할 수 있다는 것입니다.
|
||||||
|
|
||||||
|
처음부터 데브옵스에 대해 일반적으로 장벽을 허물어 시스템을 안전하고 신속하게 프로덕션에 배포하는 방법이라고 말씀드린 것을 기억하세요.
|
||||||
|
|
||||||
|
IaC는 시스템을 제공하는 데 도움이 되며, 우리는 많은 프로세스와 도구에 대해 이야기했습니다. IaC는 프로세스의 이 부분을 구현하기 위해 익숙한 더 많은 도구를 제공합니다.
|
||||||
|
|
||||||
|
이 섹션에서는 IaC에 대해 집중적으로 살펴보겠습니다. 이를 코드의 인프라 또는 코드로서의 구성이라고도 합니다. 가장 잘 알려진 용어는 아마도 IaC가 아닐까 생각합니다.
|
||||||
|
|
||||||
|
### 반려동물 대 가축
|
||||||
|
|
||||||
|
데브옵스 이전을 살펴보면, 새로운 애플리케이션을 빌드해야 하는 경우 대부분의 경우 서버를 수동으로 준비해야 합니다.
|
||||||
|
|
||||||
|
- 가상 머신 배포 | 물리적 서버 및 운영 체제 설치
|
||||||
|
- 네트워킹 구성
|
||||||
|
- 라우팅 테이블 생성
|
||||||
|
- 소프트웨어 및 업데이트 설치
|
||||||
|
- 소프트웨어 구성
|
||||||
|
- 데이터베이스 설치
|
||||||
|
|
||||||
|
이는 시스템 관리자가 수동으로 수행하는 프로세스입니다. 애플리케이션의 규모가 클수록 더 많은 리소스와 서버가 필요하며, 이러한 시스템을 가동하는 데 더 많은 수작업이 필요합니다. 이 작업에는 엄청난 인력과 시간이 소요될 뿐만 아니라 기업 입장에서도 이러한 환경을 구축하기 위해 리소스에 대한 비용을 지불해야 합니다. "인간은 실수를 합니다! 자동화를 도입해야 합니다!"로 섹션을 시작한 이유입니다.
|
||||||
|
|
||||||
|
위의 초기 설정 단계에 이어서 이러한 서버를 유지 관리해야 합니다.
|
||||||
|
|
||||||
|
- 버전 업데이트
|
||||||
|
- 새 릴리스 배포
|
||||||
|
- 데이터 관리
|
||||||
|
- 애플리케이션 복구
|
||||||
|
- 서버 추가, 제거 및 확장
|
||||||
|
- 네트워크 구성
|
||||||
|
|
||||||
|
여러 테스트 및 개발 환경의 복잡성을 추가하세요.
|
||||||
|
|
||||||
|
위에서 언급한 서버를 마치 반려동물처럼 돌보던 시절에는 서버에 애칭을 붙이거나 적어도 한동안 '가족'의 일원이 되기를 바라며 이름을 지어주기도 했습니다.
|
||||||
|
|
||||||
|
IaC를 사용하면 이러한 모든 작업을 처음부터 끝까지 자동화할 수 있습니다. IaC는 인프라를 자동으로 프로비저닝하는 개념으로, 일부 툴은 서버에 문제가 발생하면 서버를 폐기하고 새 서버를 스핀업하는 작업을 수행합니다. 이 프로세스는 자동화되어 있으며 서버는 코드에 정의된 대로 정확하게 작동합니다. 이 시점에서는 장애가 발생하거나 애플리케이션의 일부 또는 전부를 업데이트하여 더 이상 현장에 존재하지 않고 이를 대체할 다른 서버가 있을 때까지는 서버의 명칭이 무엇이든 상관없습니다.
|
||||||
|
|
||||||
|
이는 거의 모든 플랫폼, 가상화, 클라우드 기반 워크로드, 그리고 Kubernetes 및 컨테이너와 같은 클라우드 네이티브 인프라에서 사용할 수 있습니다.
|
||||||
|
|
||||||
|
### 인프라 프로비저닝
|
||||||
|
|
||||||
|
이 섹션에서 사용할 도구는 아래의 처음 두 가지 영역만 다루고 있습니다. Terraform은 우리가 다룰 도구이며, 이를 통해 무에서 시작하여 인프라의 모양을 코드로 정의한 다음 배포할 수 있으며, 인프라를 관리하고 애플리케이션을 처음 배포할 수도 있지만 그 시점에서는 애플리케이션을 추적할 수 없게 되므로 다음 섹션에서 구성 관리 도구로서 Ansible과 같은 것이 이 부분에서 더 잘 작동할 수 있습니다.
|
||||||
|
|
||||||
|
너무 앞서 나가지 않고 초기 애플리케이션 설정을 처리한 다음 해당 애플리케이션과 그 구성을 관리하는 데는 chef, puppet 및 ansible과 같은 도구가 가장 적합합니다.
|
||||||
|
|
||||||
|
소프트웨어의 초기 설치 및 구성
|
||||||
|
|
||||||
|
- 새 서버 스핀업
|
||||||
|
- 네트워크 구성
|
||||||
|
- 로드 밸런서 생성
|
||||||
|
- 인프라 수준에서 구성
|
||||||
|
|
||||||
|
### 프로비저닝된 인프라 구성
|
||||||
|
|
||||||
|
- 서버에 애플리케이션 설치
|
||||||
|
- 애플리케이션을 배포할 서버를 준비합니다.
|
||||||
|
|
||||||
|
### 애플리케이션 배포
|
||||||
|
|
||||||
|
- 애플리케이션 배포 및 관리
|
||||||
|
- 유지 관리 단계
|
||||||
|
- 소프트웨어 업데이트
|
||||||
|
- 재구성
|
||||||
|
|
||||||
|
### IaC 도구의 차이점
|
||||||
|
|
||||||
|
선언적 방식과 절차적 방식
|
||||||
|
|
||||||
|
절차적
|
||||||
|
|
||||||
|
- 단계별 지침
|
||||||
|
- 서버 생성 > 서버 추가 > 이 변경하기
|
||||||
|
|
||||||
|
선언적
|
||||||
|
|
||||||
|
- 결과 선언
|
||||||
|
- 서버 2개
|
||||||
|
|
||||||
|
변경 가능(반려동물) vs 변경 불가(가축)
|
||||||
|
|
||||||
|
변경 가능
|
||||||
|
|
||||||
|
- 대체 대신 변경
|
||||||
|
- 일반적으로 수명이 길다
|
||||||
|
|
||||||
|
변경 불가
|
||||||
|
|
||||||
|
- 변경 대신 교체
|
||||||
|
- 수명이 짧을 수 있음
|
||||||
|
|
||||||
|
이것이 바로 IaC를 위한 다양한 옵션이 있는 이유입니다. 모든 것을 지배하는 하나의 도구가 없기 때문입니다.
|
||||||
|
|
||||||
|
저희는 주로 Terraform을 사용하며 직접 실습해볼 예정인데, 이것이 IaC가 실제로 작동할 때 그 이점을 확인할 수 있는 가장 좋은 방법이기 때문입니다. 실습은 코드 작성에 필요한 기술을 익힐 수 있는 가장 좋은 방법이기도 합니다.
|
||||||
|
|
||||||
|
다음에는 직접 사용해 보기 전에 101을 통해 Terraform에 대해 살펴보겠습니다.
|
||||||
|
|
||||||
|
## 자료
|
||||||
|
|
||||||
|
아래에 많은 리소스를 나열했으며 이 주제는 이미 여러 번 다루어졌다고 생각합니다. 추가 리소스가 있는 경우 리소스와 함께 PR을 올리면 기꺼이 검토하여 목록에 추가해 드리겠습니다.
|
||||||
|
|
||||||
|
- [What is Infrastructure as Code? Difference of Infrastructure as Code Tools](https://www.youtube.com/watch?v=POPP2WTJ8es)
|
||||||
|
- [Terraform Tutorial | Terraform Course Overview 2021](https://www.youtube.com/watch?v=m3cKkYXl-8o)
|
||||||
|
- [Terraform explained in 15 mins | Terraform Tutorial for Beginners](https://www.youtube.com/watch?v=l5k1ai_GBDE)
|
||||||
|
- [Terraform Course - From BEGINNER to PRO!](https://www.youtube.com/watch?v=7xngnjfIlK4&list=WL&index=141&t=16s)
|
||||||
|
- [HashiCorp Terraform Associate Certification Course](https://www.youtube.com/watch?v=V4waklkBC38&list=WL&index=55&t=111s)
|
||||||
|
- [Terraform Full Course for Beginners](https://www.youtube.com/watch?v=EJ3N-hhiWv0&list=WL&index=39&t=27s)
|
||||||
|
- [KodeKloud - Terraform for DevOps Beginners + Labs: Complete Step by Step Guide!](https://www.youtube.com/watch?v=YcJ9IeukJL8&list=WL&index=16&t=11s)
|
||||||
|
- [Terraform Simple Projects](https://terraform.joshuajebaraj.com/)
|
||||||
|
- [Terraform Tutorial - The Best Project Ideas](https://www.youtube.com/watch?v=oA-pPa0vfks)
|
||||||
|
- [Awesome Terraform](https://github.com/shuaibiyy/awesome-terraform)
|
||||||
|
|
||||||
|
[Day 57](day57.md)에서 봐요!
|
||||||
98
2022/ko/Days/day57.md
Normal file
98
2022/ko/Days/day57.md
Normal file
@ -0,0 +1,98 @@
|
|||||||
|
---
|
||||||
|
title: '#90DaysOfDevOps - An intro to Terraform - Day 57'
|
||||||
|
published: false
|
||||||
|
description: 90DaysOfDevOps - An intro to Terraform
|
||||||
|
tags: 'devops, 90daysofdevops, learning'
|
||||||
|
cover_image: null
|
||||||
|
canonical_url: null
|
||||||
|
id: 1048710
|
||||||
|
---
|
||||||
|
|
||||||
|
## Terraform 소개
|
||||||
|
|
||||||
|
"Terraform은 인프라를 안전하고 효율적으로 구축, 변경, 버전 관리할 수 있는 도구입니다."
|
||||||
|
|
||||||
|
위의 인용문은 Terraform의 개발사인 HashiCorp에서 인용한 것입니다.
|
||||||
|
|
||||||
|
"Terraform은 수백 개의 클라우드 서비스를 관리하기 위한 일관된 CLI workflow를 제공하는 코드 소프트웨어 도구로서 오픈 소스 인프라입니다. Terraform은 클라우드 API를 선언적 구성 파일로 코드화합니다."
|
||||||
|
|
||||||
|
해시코프는 [HashiCorp 배우기](https://learn.hashicorp.com/terraform?utm_source=terraform_io&utm_content=terraform_io_hero)에서 모든 제품을 다루는 훌륭한 리소스를 제공하고 있으며, IaC로 무언가를 달성하려고 할 때 유용한 데모를 제공합니다.
|
||||||
|
|
||||||
|
모든 클라우드 제공업체와 온프레미스 플랫폼은 일반적으로 UI를 통해 리소스를 생성할 수 있는 관리 콘솔에 대한 액세스를 제공하며, 일반적으로 이러한 플랫폼은 동일한 리소스를 생성할 수 있는 CLI 또는 API 액세스도 제공하지만, API를 사용하면 빠르게 프로비저닝할 수 있습니다.형
|
||||||
|
|
||||||
|
IaC를 사용하면 이러한 API에 연결하여 원하는 상태로 리소스를 배포할 수 있습니다.
|
||||||
|
|
||||||
|
아래에 배타적이거나 완전한 도구가 아닌 다른 도구가 있습니다. 다른 도구가 있다면 PR을 통해 공유해 주세요.
|
||||||
|
|
||||||
|
| Cloud Specific | Cloud Agnostic |
|
||||||
|
| ------------------------------- | -------------- |
|
||||||
|
| AWS CloudFormation | Terraform |
|
||||||
|
| Azure Resource Manager | Pulumi |
|
||||||
|
| Google Cloud Deployment Manager | |
|
||||||
|
|
||||||
|
데모뿐만 아니라 일반적으로 사용하고자 하는 클라우드와 플랫폼에 구애받지 않으려는 것이 바로 우리가 Terraform을 사용하는 또 다른 이유입니다.
|
||||||
|
|
||||||
|
## Terraform 개요
|
||||||
|
|
||||||
|
Terraform은 프로비저닝에 중점을 둔 도구로, 복잡한 인프라 환경을 프로비저닝할 수 있는 기능을 제공하는 CLI입니다. 로컬 또는 원격(클라우드)에 존재하는 복잡한 인프라 요구 사항을 정의할 수 있습니다. Terraform을 사용하면 처음에 구축할 수 있을 뿐만 아니라 해당 리소스의 수명 기간 동안 유지 관리 및 업데이트할 수 있습니다.
|
||||||
|
|
||||||
|
여기서는 개략적인 내용만 다루겠지만, 더 자세한 내용과 다양한 리소스를 보려면 [terraform.io](https://www.terraform.io/)를 방문하세요.
|
||||||
|
|
||||||
|
### 쓰기
|
||||||
|
|
||||||
|
Terraform을 사용하면 환경을 구축할 선언적 구성 파일을 만들 수 있습니다. 이 파일은 블록, 인수, 표현식을 사용하여 리소스를 간결하게 설명할 수 있는 해시코프 구성 언어(HCL)를 사용하여 작성됩니다. 물론 가상 머신, 컨테이너를 배포할 때와 쿠버네티스 내에서 이를 자세히 살펴볼 것입니다.
|
||||||
|
|
||||||
|
### 계획
|
||||||
|
|
||||||
|
위의 구성 파일들이 우리가 보고자 하는 것을 배포할 것인지 확인하기 위해 Terraform cli의 특정 기능을 사용하여 배포하거나 변경하기 전에 해당 계획을 테스트할 수 있는 기능입니다. Terraform은 인프라를 위한 지속적인 도구이므로 인프라의 측면을 변경하려면 코드에서 모두 캡처되도록 Terraform을 통해 변경해야 한다는 점을 기억하세요.
|
||||||
|
|
||||||
|
### 적용
|
||||||
|
|
||||||
|
만족스러우면 계속해서 이 구성을 Terraform 내에서 사용할 수 있는 많은 제공업체에 적용할 수 있습니다. [여기](https://registry.terraform.io/browse/providers)에서 사용 가능한 수많은 제공자를 확인할 수 있습니다.
|
||||||
|
|
||||||
|
또 한 가지 언급할 것은 사용 가능한 모듈도 있다는 것인데, 이러한 모듈은 공개적으로 생성 및 공유되어 있으므로 특정 인프라 리소스를 모든 곳에 동일한 방식으로 배포하는 모범 사례를 반복해서 생성할 필요가 없다는 점에서 컨테이너 이미지와 유사합니다. 사용 가능한 모듈은 [여기](https://registry.terraform.io/browse/modules)에서 찾을 수 있습니다.
|
||||||
|
|
||||||
|
Terraform workflow는 다음과 같습니다. (_Terraform 사이트에서 가져옴_)
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
### Terraform vs Vagrant
|
||||||
|
|
||||||
|
이번 챌린지에서는 개발 환경에 집중하는 또 다른 해시코프 오픈소스 도구인 Vagrant를 사용했습니다.
|
||||||
|
|
||||||
|
- Vagrant는 개발 환경 관리에 중점을 둔 도구입니다.
|
||||||
|
|
||||||
|
- Terraform은 인프라 구축을 위한 도구입니다.
|
||||||
|
|
||||||
|
두 도구에 대한 자세한 비교는 공식 [HashiCorp 사이트](https://www.vagrantup.com/intro/vs/terraform)에서 확인할 수 있습니다.
|
||||||
|
|
||||||
|
## Terraform 설치
|
||||||
|
|
||||||
|
Terraform을 설치하는 데에는 많은 것이 필요하지 않습니다.
|
||||||
|
|
||||||
|
Terraform은 크로스 플랫폼이며, 제 리눅스 머신에서 아래에서 CLI를 다운로드하고 설치하는 몇 가지 옵션을 볼 수 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
`arkade`를 사용하여 Terraform을 설치하면, 아케이드는 필요한 도구, 앱, 클리스를 시스템에 설치할 수 있는 편리한 작은 도구입니다. 간단한 `arkade get terraform`으로 Terraform을 업데이트할 수 있으며, Terraform이 있다면 같은 명령으로 Terraform CLI도 설치할 수 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
앞으로 HCL에 대해 좀 더 자세히 살펴본 다음 다양한 플랫폼에서 인프라 리소스를 생성하는 데 Terraform을 사용해 보도록 하겠습니다.
|
||||||
|
|
||||||
|
## 자료
|
||||||
|
|
||||||
|
아래에 많은 리소스를 나열했으며 이 주제는 이미 여러 번 다루어졌다고 생각합니다. 추가 리소스가 있는 경우 리소스와 함께 PR을 올리면 기꺼이 검토하여 목록에 추가해 드리겠습니다.
|
||||||
|
|
||||||
|
- [What is Infrastructure as Code? Difference of Infrastructure as Code Tools](https://www.youtube.com/watch?v=POPP2WTJ8es)
|
||||||
|
- [Terraform Tutorial | Terraform Course Overview 2021](https://www.youtube.com/watch?v=m3cKkYXl-8o)
|
||||||
|
- [Terraform explained in 15 mins | Terraform Tutorial for Beginners](https://www.youtube.com/watch?v=l5k1ai_GBDE)
|
||||||
|
- [Terraform Course - From BEGINNER to PRO!](https://www.youtube.com/watch?v=7xngnjfIlK4&list=WL&index=141&t=16s)
|
||||||
|
- [HashiCorp Terraform Associate Certification Course](https://www.youtube.com/watch?v=V4waklkBC38&list=WL&index=55&t=111s)
|
||||||
|
- [Terraform Full Course for Beginners](https://www.youtube.com/watch?v=EJ3N-hhiWv0&list=WL&index=39&t=27s)
|
||||||
|
- [KodeKloud - Terraform for DevOps Beginners + Labs: Complete Step by Step Guide!](https://www.youtube.com/watch?v=YcJ9IeukJL8&list=WL&index=16&t=11s)
|
||||||
|
- [Terraform Simple Projects](https://terraform.joshuajebaraj.com/)
|
||||||
|
- [Terraform Tutorial - The Best Project Ideas](https://www.youtube.com/watch?v=oA-pPa0vfks)
|
||||||
|
- [Awesome Terraform](https://github.com/shuaibiyy/awesome-terraform)
|
||||||
|
|
||||||
|
[Day 58](day58.md)에서 봐요!
|
||||||
234
2022/ko/Days/day58.md
Normal file
234
2022/ko/Days/day58.md
Normal file
@ -0,0 +1,234 @@
|
|||||||
|
---
|
||||||
|
title: '#90DaysOfDevOps - HashiCorp Configuration Language (HCL) - Day 58'
|
||||||
|
published: false
|
||||||
|
description: 90DaysOfDevOps - HashiCorp Configuration Language (HCL)
|
||||||
|
tags: 'devops, 90daysofdevops, learning'
|
||||||
|
cover_image: null
|
||||||
|
canonical_url: null
|
||||||
|
id: 1048741
|
||||||
|
---
|
||||||
|
|
||||||
|
## HashiCorp 구성 언어(HCL)
|
||||||
|
|
||||||
|
Terraform으로 무언가를 만들기 시작하기 전에 HashiCorp 구성 언어(HCL)에 대해 조금 알아볼 필요가 있습니다. 지금까지 챌린지를 진행하면서 몇 가지 다른 스크립팅 및 프로그래밍 언어를 살펴봤는데, 여기에 또 다른 언어가 있습니다. [Go 프로그래밍 언어](day07.md)에 이어 [bash 스크립트](day19.md)를 다루었고, [네트워크 자동화](day27.md)와 관련해서는 파이썬도 조금 다뤄봤습니다.
|
||||||
|
|
||||||
|
이제 HashiCorp 구성 언어(HCL)를 다뤄야 하는데, 이 언어를 처음 접하는 분들에게는 다소 어렵게 느껴질 수 있지만 매우 간단하고 강력한 언어입니다.
|
||||||
|
|
||||||
|
이 섹션을 진행하면서 어떤 OS를 사용하든 시스템에서 로컬로 실행할 수 있는 예제를 사용할 것이며, 일반적으로 Terraform에서 사용하는 인프라 플랫폼은 아니지만 VirtualBox를 사용할 것입니다. 그러나 로컬에서 실행하는 것은 무료이며 이 게시물에서 원하는 것을 달성할 수 있습니다. 이 포스팅의 개념을 도커나 쿠버네티스로 확장할 수도 있습니다.
|
||||||
|
|
||||||
|
하지만 일반적으로는 퍼블릭 클라우드(AWS, Google, Microsoft Azure)뿐만 아니라 가상화 환경(VMware, Microsoft Hyper-V, Nutanix AHV)에도 인프라를 배포하는 데 Terraform을 사용하거나 사용해야 합니다. 퍼블릭 클라우드에서 Terraform을 사용하면 가상 머신 자동 배포뿐 아니라 PaaS 워크로드와 같은 모든 필수 인프라와 VPC 및 보안 그룹과 같은 모든 네트워킹 필수 자산을 생성할 수 있습니다.
|
||||||
|
|
||||||
|
Terraform에는 두 가지 중요한 측면이 있는데, 이 포스팅에서 다룰 code와 state입니다. 이 두 가지를 함께 Terraform의 핵심이라고 부를 수 있습니다. 그런 다음 우리가 대화하고 배포하고자 하는 환경이 있는데, 이는 지난 세션에서 간략히 언급했지만, AWS 공급자, Azure 공급자 등을 사용하여 실행되는 Terraform 공급자를 사용하여 실행됩니다. 수백 개가 있습니다.
|
||||||
|
|
||||||
|
### 기본 Terraform 사용법
|
||||||
|
|
||||||
|
Terraform `.tf` 파일이 어떻게 구성되는지 살펴보겠습니다. 첫 번째로 살펴볼 예제는 AWS에 리소스를 배포하는 코드이며, 이를 위해서는 시스템에 AWS CLI를 설치하고 계정에 맞게 구성해야 합니다.
|
||||||
|
|
||||||
|
### 공급자
|
||||||
|
|
||||||
|
더 복잡하게 만들 때까지는 일반적으로 `main.tf`라고 부르는 `.tf` 파일 구조의 맨 위에 있습니다. 여기서는 앞서 언급했던 공급자를 정의합니다. 보시다시피 AWS 공급자의 소스는 `hashicorp/aws`이며, 이는 공급자가 HashiCorp에서 직접 유지 관리하거나 게시했음을 의미합니다. 기본적으로 [Terraform 레지스트리](https://registry.terraform.io/)에서 사용할 수 있는 제공자를 참조하게 되며, 제공자를 작성하여 로컬에서 사용하거나 Terraform 레지스트리에 자체 게시할 수도 있습니다.
|
||||||
|
|
||||||
|
```
|
||||||
|
terraform {
|
||||||
|
required_providers {
|
||||||
|
aws = {
|
||||||
|
source = "hashicorp/aws"
|
||||||
|
version = "~> 3.0"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
프로비저닝할 AWS 리전을 결정하기 위해 여기에 리전을 추가할 수도 있는데, 이를 위해 다음을 추가할 수 있습니다:
|
||||||
|
|
||||||
|
```
|
||||||
|
provider "aws" {
|
||||||
|
region = "ap-southeast-1" //리소스를 배포해야 하는 지역
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
### Terraform 리소스
|
||||||
|
|
||||||
|
- EC2, 로드 밸런서, VPC 등과 같은 하나 이상의 인프라 개체를 설명하는 Terraform 구성 파일의 또 다른 중요한 구성 요소입니다.
|
||||||
|
|
||||||
|
- 리소스 블록은 지정된 유형("aws_instance")의 리소스를 지정된 로컬 이름("90daysofdevops")으로 선언합니다.
|
||||||
|
|
||||||
|
- 리소스 유형과 이름은 함께 지정된 리소스의 식별자 역할을 합니다.
|
||||||
|
|
||||||
|
```
|
||||||
|
resource "aws_instance" "90daysofdevops" {
|
||||||
|
ami = data.aws_ami.instance_id.id
|
||||||
|
instance_type = "t2.micro"
|
||||||
|
availability_zone = "us-west-2a"
|
||||||
|
security_groups = [aws_security_group.allow_web.name]
|
||||||
|
user_data = <<-EOF
|
||||||
|
#! /bin/bash
|
||||||
|
sudo yum update
|
||||||
|
sudo yum install -y httpd
|
||||||
|
sudo systemctl start httpd
|
||||||
|
sudo systemctl enable httpd
|
||||||
|
echo "
|
||||||
|
<h1>Deployed via Terraform</h1>
|
||||||
|
|
||||||
|
" | sudo tee /var/www/html/index.html
|
||||||
|
EOF
|
||||||
|
tags = {
|
||||||
|
Name = "Created by Terraform"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
위에서 `yum` 업데이트를 실행하고 ec2 인스턴스에 `httpd`를 설치하는 것을 볼 수 있습니다.
|
||||||
|
|
||||||
|
이제 전체 main.tf 파일을 보면 다음과 같이 보일 수 있습니다.
|
||||||
|
|
||||||
|
```
|
||||||
|
terraform {
|
||||||
|
required_providers {
|
||||||
|
aws = {
|
||||||
|
source = "hashicorp/aws"
|
||||||
|
version = "~> 3.27"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
required_version = ">= 0.14.9"
|
||||||
|
}
|
||||||
|
|
||||||
|
provider "aws" {
|
||||||
|
profile = "default"
|
||||||
|
region = "us-west-2"
|
||||||
|
}
|
||||||
|
|
||||||
|
resource "aws_instance" "90daysofdevops" {
|
||||||
|
ami = "ami-830c94e3"
|
||||||
|
instance_type = "t2.micro"
|
||||||
|
availability_zone = "us-west-2a"
|
||||||
|
user_data = <<-EOF
|
||||||
|
#! /bin/bash
|
||||||
|
sudo yum update
|
||||||
|
sudo yum install -y httpd
|
||||||
|
sudo systemctl start httpd
|
||||||
|
sudo systemctl enable httpd
|
||||||
|
echo "
|
||||||
|
<h1>Deployed via Terraform</h1>
|
||||||
|
|
||||||
|
" | sudo tee /var/www/html/index.html
|
||||||
|
EOF
|
||||||
|
tags = {
|
||||||
|
Name = "Created by Terraform"
|
||||||
|
|
||||||
|
tags = {
|
||||||
|
Name = "ExampleAppServerInstance"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
위의 코드는 AWS에서 매우 간단한 웹 서버를 ec2 인스턴스로 배포합니다. 이 코드와 이와 같은 다른 구성의 가장 큰 장점은 이 작업을 반복할 수 있고 매번 동일한 출력을 얻을 수 있다는 것입니다. 제가 코드를 엉망으로 만들었을 가능성을 제외하고는 위와 같이 사람이 개입할 여지가 없습니다.
|
||||||
|
|
||||||
|
한 번도 사용하지 않을 것 같은 아주 간단한 예제를 살펴볼 수 있지만, 어쨌든 유머러스하게 만들어 보겠습니다. 모든 훌륭한 스크립팅 및 프로그래밍 언어가 그렇듯, Hello World부터 시작해야 합니다.
|
||||||
|
|
||||||
|
```
|
||||||
|
terraform {
|
||||||
|
# 이 모듈은 현재 Terraform 0.13.x에서만 테스트 중입니다. 그러나 더 쉽게 업그레이드할 수 있도록 다음과 같이 설정하고 있습니다.
|
||||||
|
# 0.12.26을 최소 버전으로 설정했는데, 이 버전은 소스 URL이 있는 required_providers에 대한 지원이 추가되었기 때문입니다.
|
||||||
|
# 0.13.x 코드와 호환됩니다.
|
||||||
|
required_version = ">= 0.12.26"
|
||||||
|
}
|
||||||
|
|
||||||
|
# website::tag::1:: 가장 간단한 Terraform 모듈: "Hello, World!"를 출력하기만 하면 됩니다.
|
||||||
|
output "hello_world" {
|
||||||
|
value = "Hello, 90DaysOfDevOps from Terraform"
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
이 파일은 IaC 폴더 안의 Hello-world 폴더에서 찾을 수 있지만, Terraform 코드를 사용하기 위해 실행해야 하는 몇 가지 명령이 있기 때문에 바로 작동하지는 않습니다.
|
||||||
|
|
||||||
|
터미널에서 main.tf가 생성된 폴더로 이동합니다. 이 저장소에서 가져올 수도 있고 위의 코드를 사용하여 새 저장소를 생성할 수도 있습니다.
|
||||||
|
|
||||||
|
해당 폴더에서 `terraform init`을 실행합니다.
|
||||||
|
|
||||||
|
Terraform 코드가 있는 모든 디렉토리에서 또는 Terraform 코드를 실행하기 전에 이 작업을 수행해야 합니다. 구성 디렉터리를 초기화하면 구성에 정의된 공급자를 다운로드하여 설치합니다. 이 경우에는 공급자가 없지만 위의 예제에서는 이 구성에 대한 AWS 공급자를 다운로드합니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
다음 명령은 `terraform plan`입니다.
|
||||||
|
|
||||||
|
`terraform plan` 명령은 실행 계획을 생성하여 Terraform이 인프라에 적용하려는 변경 사항을 미리 볼 수 있게 해줍니다.
|
||||||
|
|
||||||
|
hello-world 예제를 통해 아래에서 간단히 볼 수 있듯이, 이것이 AWS ec2 인스턴스였다면 생성할 모든 단계가 출력되는 것을 볼 수 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이 시점에서 리포지토리를 초기화했고 필요한 경우 제공자를 다운로드했으며, 테스트 워크스루를 실행하여 원하는 대로 표시되는지 확인했으므로 이제 코드를 실행하고 배포할 수 있습니다.
|
||||||
|
|
||||||
|
`terraform apply`를 사용하면 이 작업을 수행할 수 있으며, 이 명령에는 안전 조치가 내장되어 있어 앞으로 일어날 일에 대한 계획 보기가 다시 제공되므로 계속할 것인지에 대한 응답을 보장합니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
값을 입력하기 위해 yes를 입력하면 코드가 배포됩니다. 그다지 흥미롭지는 않지만, 코드에서 정의한 출력이 나오는 것을 볼 수 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이제 우리는 아무것도 배포하지 않았고, 아무것도 추가, 변경 또는 삭제하지 않았지만, 만약 배포했다면 위와 같이 표시된 것을 볼 수 있을 것입니다. 그러나 무언가를 배포한 후 배포한 모든 것을 제거하려면 `terraform destroy` 명령을 사용할 수 있습니다. 이 경우에도 `apply` 및 `delete` 명령 끝에 `--auto-approve`을 사용하여 수동 개입을 우회할 수 있지만 예라고 입력해야 하는 안전성이 있습니다. 하지만 이 단축키는 학습 및 테스트 시에만 사용하는 것이 좋으며, 때로는 모든 것이 빌드된 것보다 빨리 사라질 수 있습니다.
|
||||||
|
|
||||||
|
지금까지 Terraform CLI에서 다룬 명령어는 총 4가지입니다.
|
||||||
|
|
||||||
|
- `terraform init` = 프로바이더로 프로젝트 폴더 준비하기
|
||||||
|
- `terraform plan` = 코드를 기반으로 다음 명령 중에 생성 및 변경될 내용을 표시합니다.
|
||||||
|
- `terraform apply`= 코드에 정의된 리소스를 배포합니다.
|
||||||
|
- `terraform destroy` = 프로젝트에서 생성한 리소스를 파괴합니다.
|
||||||
|
|
||||||
|
코드 파일에서 두 가지 중요한 측면도 다루었습니다.
|
||||||
|
|
||||||
|
- providers = API를 통해 Terraform이 최종 플랫폼과 대화하는 방법
|
||||||
|
- resources = 우리가 코드로 배포하고자 하는 것
|
||||||
|
|
||||||
|
또 한 가지 주의해야 할 점은 `terraform init`을 실행할 때 폴더의 트리를 전후로 살펴보고 어떤 일이 발생하고 제공자와 모듈을 어디에 저장하는지 확인하는 것입니다.
|
||||||
|
|
||||||
|
### Terraform state
|
||||||
|
|
||||||
|
또한 디렉터리 내부에 생성되는 state 파일도 알아야 하는데, 이 hello-world 예제에서 state 파일은 간단합니다. 이것은 Terraform에 따라 세계를 표현하는 JSON 파일입니다. 상태는 민감한 데이터를 기꺼이 보여줄 수 있으므로 주의해야 하며, 모범 사례로 GitHub에 업로드하기 전에 `.tfstate` 파일을 `.gitignore` 폴더에 넣는 것이 좋습니다.
|
||||||
|
|
||||||
|
기본적으로 상태 파일은 프로젝트 코드와 같은 디렉터리에 있지만 옵션으로 원격으로 저장할 수도 있습니다. 프로덕션 환경에서는 S3 버킷과 같은 공유 위치가 될 가능성이 높습니다.
|
||||||
|
|
||||||
|
또 다른 옵션으로는 유료 관리형 서비스인 Terraform Cloud가 있습니다. (최대 5명의 사용자까지 무료)
|
||||||
|
|
||||||
|
원격 위치에 상태를 저장할 때 얻을 수 있는 장점은 다음과 같습니다:
|
||||||
|
|
||||||
|
- 민감한 데이터 암호화
|
||||||
|
- 협업
|
||||||
|
- 자동화
|
||||||
|
- 그러나 복잡성이 증가할 수 있습니다.
|
||||||
|
|
||||||
|
```JSON
|
||||||
|
{
|
||||||
|
"version": 4,
|
||||||
|
"terraform_version": "1.1.6",
|
||||||
|
"serial": 1,
|
||||||
|
"lineage": "a74296e7-670d-0cbb-a048-f332696ca850",
|
||||||
|
"outputs": {
|
||||||
|
"hello_world": {
|
||||||
|
"value": "Hello, 90DaysOfDevOps from Terraform",
|
||||||
|
"type": "string"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
"resources": []
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
## 자료
|
||||||
|
|
||||||
|
아래에 많은 리소스를 나열했으며 이 주제는 이미 여러 번 다루어졌다고 생각합니다. 추가 리소스가 있는 경우 리소스와 함께 PR을 올리면 기꺼이 검토하여 목록에 추가해 드리겠습니다.
|
||||||
|
|
||||||
|
- [What is Infrastructure as Code? Difference of Infrastructure as Code Tools](https://www.youtube.com/watch?v=POPP2WTJ8es)
|
||||||
|
- [Terraform Tutorial | Terraform Course Overview 2021](https://www.youtube.com/watch?v=m3cKkYXl-8o)
|
||||||
|
- [Terraform explained in 15 mins | Terraform Tutorial for Beginners](https://www.youtube.com/watch?v=l5k1ai_GBDE)
|
||||||
|
- [Terraform Course - From BEGINNER to PRO!](https://www.youtube.com/watch?v=7xngnjfIlK4&list=WL&index=141&t=16s)
|
||||||
|
- [HashiCorp Terraform Associate Certification Course](https://www.youtube.com/watch?v=V4waklkBC38&list=WL&index=55&t=111s)
|
||||||
|
- [Terraform Full Course for Beginners](https://www.youtube.com/watch?v=EJ3N-hhiWv0&list=WL&index=39&t=27s)
|
||||||
|
- [KodeKloud - Terraform for DevOps Beginners + Labs: Complete Step by Step Guide!](https://www.youtube.com/watch?v=YcJ9IeukJL8&list=WL&index=16&t=11s)
|
||||||
|
- [Terraform Simple Projects](https://terraform.joshuajebaraj.com/)
|
||||||
|
- [Terraform Tutorial - The Best Project Ideas](https://www.youtube.com/watch?v=oA-pPa0vfks)
|
||||||
|
- [Awesome Terraform](https://github.com/shuaibiyy/awesome-terraform)
|
||||||
|
|
||||||
|
[Day 59](day59.md)에서 봐요!
|
||||||
130
2022/ko/Days/day59.md
Normal file
130
2022/ko/Days/day59.md
Normal file
@ -0,0 +1,130 @@
|
|||||||
|
---
|
||||||
|
title: '#90DaysOfDevOps - Create a VM with Terraform & Variables - Day 59'
|
||||||
|
published: false
|
||||||
|
description: 90DaysOfDevOps - Create a VM with Terraform & Variables
|
||||||
|
tags: 'devops, 90daysofdevops, learning'
|
||||||
|
cover_image: null
|
||||||
|
canonical_url: null
|
||||||
|
id: 1049051
|
||||||
|
---
|
||||||
|
|
||||||
|
## Terraform 및 변수를 사용하여 VM 생성하기
|
||||||
|
|
||||||
|
이 세션에서는 VirtualBox 내에서 Terraform을 사용하여 VM을 한두 개 생성해 보겠습니다. VirtualBox는 워크스테이션 가상화 옵션이므로 Terraform의 사용 사례는 아니지만, 저는 현재 36,000피트 상공에 있으며 이 정도 높이의 클라우드에 퍼블릭 클라우드 리소스를 배포한 만큼 노트북에서 로컬로 이 작업을 수행하는 것이 훨씬 더 빠릅니다.
|
||||||
|
|
||||||
|
순전히 데모 목적이지만 개념은 동일합니다. 원하는 상태 구성 코드를 만든 다음 VirtualBox 공급자에 대해 실행할 것입니다. 과거에는 여기서는 vagrant를 사용했으며 이 섹션의 시작 부분에서 vagrant와 Terraform의 차이점에 대해 다루었습니다.
|
||||||
|
|
||||||
|
### VirtualBox에서 가상 머신 생성하기
|
||||||
|
|
||||||
|
가장 먼저 할 일은 VirtualBox라는 새 폴더를 생성한 다음 VirtualBox.tf 파일을 생성하고 여기에서 리소스를 정의하는 것입니다. VirtualBox 폴더에서 VirtualBox.tf로 찾을 수 있는 아래 코드는 Virtualbox에 2개의 VM을 생성합니다.
|
||||||
|
|
||||||
|
커뮤니티 VirtualBox 제공업체에 대한 자세한 내용은 [여기](https://registry.terraform.io/providers/terra-farm/virtualbox/latest/docs/resources/vm)에서 확인할 수 있습니다.
|
||||||
|
|
||||||
|
```
|
||||||
|
terraform {
|
||||||
|
required_providers {
|
||||||
|
virtualbox = {
|
||||||
|
source = "terra-farm/virtualbox"
|
||||||
|
version = "0.2.2-alpha.1"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
# 현재 공급자 자체에 대한 구성 옵션이 없습니다.
|
||||||
|
|
||||||
|
resource "virtualbox_vm" "node" {
|
||||||
|
count = 2
|
||||||
|
name = format("node-%02d", count.index + 1)
|
||||||
|
image = "https://app.vagrantup.com/ubuntu/boxes/bionic64/versions/20180903.0.0/providers/virtualbox.box"
|
||||||
|
cpus = 2
|
||||||
|
memory = "512 mib"
|
||||||
|
|
||||||
|
network_adapter {
|
||||||
|
type = "hostonly"
|
||||||
|
host_interface = "vboxnet1"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
output "IPAddr" {
|
||||||
|
value = element(virtualbox_vm.node.*.network_adapter.0.ipv4_address, 1)
|
||||||
|
}
|
||||||
|
|
||||||
|
output "IPAddr_2" {
|
||||||
|
value = element(virtualbox_vm.node.*.network_adapter.0.ipv4_address, 2)
|
||||||
|
}
|
||||||
|
|
||||||
|
```
|
||||||
|
|
||||||
|
이제 코드가 정의되었으므로 이제 폴더에서 `terraform init`을 수행하여 Virtualbox용 공급자를 다운로드할 수 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
또한 시스템에도 VirtualBox가 설치되어 있어야 합니다. 그런 다음 `terraform plan`을 실행하여 코드가 무엇을 생성하는지 확인할 수 있습니다. 이어서 `terraform apply`를 실행하면 아래 이미지에 완성된 프로세스가 표시됩니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이제 Virtualbox에서 2개의 가상 머신을 볼 수 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
### 구성 변경
|
||||||
|
|
||||||
|
배포에 다른 노드를 추가해 보겠습니다. 카운트 라인을 변경하여 원하는 새로운 노드 수를 표시하면 됩니다. `terraform apply`를 실행하면 아래와 같이 표시됩니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
VirtualBox에서 완료되면 이제 3개의 노드가 실행되고 있는 것을 볼 수 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
완료되면 `terraform destroy`를 사용하여 이를 지우면 머신이 제거됩니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
### 변수 및 출력
|
||||||
|
|
||||||
|
지난 세션에서 hello-world 예제를 실행할 때 출력을 언급했습니다. 여기서 더 자세히 살펴볼 수 있습니다.
|
||||||
|
|
||||||
|
하지만 여기에도 사용할 수 있는 다른 많은 변수가 있으며, 변수를 정의하는 몇 가지 다른 방법도 있습니다.
|
||||||
|
|
||||||
|
- `terraform plan` 또는 `terraform apply` 명령을 사용하여 변수를 수동으로 입력할 수 있습니다.
|
||||||
|
|
||||||
|
- 블록 내의 .tf 파일에 변수를 정의할 수 있습니다.
|
||||||
|
|
||||||
|
- `TF_VAR_NAME` 형식을 사용하여 시스템 내에서 환경 변수를 사용할 수 있습니다.
|
||||||
|
|
||||||
|
- 저는 프로젝트 폴더에 terraform.tfvars 파일을 사용하는 것을 선호합니다.
|
||||||
|
|
||||||
|
- \*auto.tfvars 파일 옵션이 있습니다.
|
||||||
|
|
||||||
|
- 또는 `-var` 또는 `-var-file`을 사용하여 `terraform plan` 또는 `terraform apply`을 실행할 때를 정의할 수 있습니다.
|
||||||
|
|
||||||
|
아래에서 위로 올라가는 것이 변수를 정의하는 순서입니다.
|
||||||
|
|
||||||
|
또한 상태 파일에 민감한 정보가 포함될 것이라고 언급했습니다. 민감한 정보를 변수로 정의하고 이를 민감한 정보로 정의할 수 있습니다.
|
||||||
|
|
||||||
|
```
|
||||||
|
variable "some resource" {
|
||||||
|
description = "something important"
|
||||||
|
type= string
|
||||||
|
sensitive = true
|
||||||
|
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
## 자료
|
||||||
|
|
||||||
|
아래에 많은 리소스를 나열했으며 이 주제는 이미 여러 번 다루어졌다고 생각합니다. 추가 리소스가 있는 경우 리소스와 함께 PR을 올리면 기꺼이 검토하여 목록에 추가해 드리겠습니다.
|
||||||
|
|
||||||
|
- [What is Infrastructure as Code? Difference of Infrastructure as Code Tools](https://www.youtube.com/watch?v=POPP2WTJ8es)
|
||||||
|
- [Terraform Tutorial | Terraform Course Overview 2021](https://www.youtube.com/watch?v=m3cKkYXl-8o)
|
||||||
|
- [Terraform explained in 15 mins | Terraform Tutorial for Beginners](https://www.youtube.com/watch?v=l5k1ai_GBDE)
|
||||||
|
- [Terraform Course - From BEGINNER to PRO!](https://www.youtube.com/watch?v=7xngnjfIlK4&list=WL&index=141&t=16s)
|
||||||
|
- [HashiCorp Terraform Associate Certification Course](https://www.youtube.com/watch?v=V4waklkBC38&list=WL&index=55&t=111s)
|
||||||
|
- [Terraform Full Course for Beginners](https://www.youtube.com/watch?v=EJ3N-hhiWv0&list=WL&index=39&t=27s)
|
||||||
|
- [KodeKloud - Terraform for DevOps Beginners + Labs: Complete Step by Step Guide!](https://www.youtube.com/watch?v=YcJ9IeukJL8&list=WL&index=16&t=11s)
|
||||||
|
- [Terraform Simple Projects](https://terraform.joshuajebaraj.com/)
|
||||||
|
- [Terraform Tutorial - The Best Project Ideas](https://www.youtube.com/watch?v=oA-pPa0vfks)
|
||||||
|
- [Awesome Terraform](https://github.com/shuaibiyy/awesome-terraform)
|
||||||
|
|
||||||
|
[Day 60](day60.md)에서 봐요!
|
||||||
194
2022/ko/Days/day60.md
Normal file
194
2022/ko/Days/day60.md
Normal file
@ -0,0 +1,194 @@
|
|||||||
|
---
|
||||||
|
title: '#90DaysOfDevOps - Docker Containers, Provisioners & Modules - Day 60'
|
||||||
|
published: false
|
||||||
|
description: '90DaysOfDevOps - Docker Containers, Provisioners & Modules'
|
||||||
|
tags: 'devops, 90daysofdevops, learning'
|
||||||
|
cover_image: null
|
||||||
|
canonical_url: null
|
||||||
|
id: 1049052
|
||||||
|
---
|
||||||
|
|
||||||
|
## Docker 컨테이너, Provisioners 및 모듈
|
||||||
|
|
||||||
|
[Day 59](day59.md)에는 Terraform을 사용하여 로컬 무료 VirtualBox 환경에 가상 머신을 프로비저닝했습니다. 이 섹션에서는 몇 가지 구성이 포함된 Docker 컨테이너를 로컬 Docker 환경에 배포해 보겠습니다.
|
||||||
|
|
||||||
|
### Docker 데모
|
||||||
|
|
||||||
|
먼저 아래 코드 블록을 사용하여 간단한 웹 앱을 Docker에 배포하고 이를 게시하여 네트워크에서 사용할 수 있도록 하겠습니다. nginx를 사용할 것이며 로컬 호스트와 포트 8000을 통해 노트북에서 외부에서 사용할 수 있도록 할 것입니다. 커뮤니티에서 제공하는 Docker 공급자를 사용하고 있으며 구성에서도 사용 중인 Docker 이미지를 확인할 수 있습니다.
|
||||||
|
|
||||||
|
```
|
||||||
|
terraform {
|
||||||
|
required_providers {
|
||||||
|
docker = {
|
||||||
|
source = "kreuzwerker/docker"
|
||||||
|
version = "2.16.0"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
provider "docker" {}
|
||||||
|
|
||||||
|
resource "docker_image" "nginx" {
|
||||||
|
name = "nginx:latest"
|
||||||
|
keep_locally = false
|
||||||
|
}
|
||||||
|
|
||||||
|
resource "docker_container" "nginx" {
|
||||||
|
image = docker_image.nginx.latest
|
||||||
|
name = "tutorial"
|
||||||
|
ports {
|
||||||
|
internal = 80
|
||||||
|
external = 8000
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
첫 번째 작업은 `terraform init` 명령을 사용하여 로컬 머신에 프로바이더를 다운로드하는 것입니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
그런 다음 `terraform apply`를 실행한 다음 `docker ps`를 실행하면 컨테이너가 실행되는 것을 볼 수 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이제 브라우저를 열어 `http://localhost:8000/`으로 이동하면 NGINX 컨테이너에 액세스할 수 있는 것을 볼 수 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
자세한 내용은 [Docker Provider](https://registry.terraform.io/providers/kreuzwerker/docker/latest/docs/resources/container)에서 확인할 수 있습니다.
|
||||||
|
|
||||||
|
위는 Terraform과 Docker로 무엇을 할 수 있는지, 그리고 Terraform 상태에서 어떻게 관리할 수 있는지에 대한 아주 간단한 데모입니다. 컨테이너 섹션에서 docker-compose에 대해 다뤘고, 이것과 IaC, 그리고 Kubernetes 사이에는 약간의 교차점이 있습니다.
|
||||||
|
|
||||||
|
이를 보여드리고 Terraform이 어떻게 좀 더 복잡한 것을 처리할 수 있는지 보여드리기 위해, 우리가 docker-compose로 만든 워드프레스와 MySQL용 docker-compose 파일을 가져와서 이것을 Terraform에 넣도록 하겠습니다. [docker-wordpress.tf](2022/Days/IaC/Docker-WordPress/docker-WordPress.tf)를 찾을 수 있습니다.
|
||||||
|
|
||||||
|
```
|
||||||
|
terraform {
|
||||||
|
required_providers {
|
||||||
|
docker = {
|
||||||
|
source = "kreuzwerker/docker"
|
||||||
|
version = "2.16.0"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
provider "docker" {}
|
||||||
|
|
||||||
|
variable wordpress_port {
|
||||||
|
default = "8080"
|
||||||
|
}
|
||||||
|
|
||||||
|
resource "docker_volume" "db_data" {
|
||||||
|
name = "db_data"
|
||||||
|
}
|
||||||
|
|
||||||
|
resource "docker_network" "wordpress_net" {
|
||||||
|
name = "wordpress_net"
|
||||||
|
}
|
||||||
|
|
||||||
|
resource "docker_container" "db" {
|
||||||
|
name = "db"
|
||||||
|
image = "mysql:5.7"
|
||||||
|
restart = "always"
|
||||||
|
network_mode = "wordpress_net"
|
||||||
|
env = [
|
||||||
|
"MYSQL_ROOT_PASSWORD=wordpress",
|
||||||
|
"MYSQL_PASSWORD=wordpress",
|
||||||
|
"MYSQL_USER=wordpress",
|
||||||
|
"MYSQL_DATABASE=wordpress"
|
||||||
|
]
|
||||||
|
mounts {
|
||||||
|
type = "volume"
|
||||||
|
target = "/var/lib/mysql"
|
||||||
|
source = "db_data"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
resource "docker_container" "wordpress" {
|
||||||
|
name = "wordpress"
|
||||||
|
image = "wordpress:latest"
|
||||||
|
restart = "always"
|
||||||
|
network_mode = "wordpress_net"
|
||||||
|
env = [
|
||||||
|
"WORDPRESS_DB_HOST=db:3306",
|
||||||
|
"WORDPRESS_DB_USER=wordpress",
|
||||||
|
"WORDPRESS_DB_NAME=wordpress",
|
||||||
|
"WORDPRESS_DB_PASSWORD=wordpress"
|
||||||
|
]
|
||||||
|
ports {
|
||||||
|
internal = "80"
|
||||||
|
external = "${var.wordpress_port}"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
이 파일을 다시 새 폴더에 넣은 다음 `terraform init` 명령을 실행하여 필요한 Provisioners를 내려놓습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
그런 다음 `terraform apply` 명령을 실행한 다음 `docker ps` 출력을 살펴보면 새로 생성된 컨테이너를 볼 수 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이제 WordPress 프론트엔드로 이동할 수도 있습니다. 컨테이너 섹션에서 docker-compose로 이 과정을 거쳤을 때와 마찬가지로 이제 설정을 실행할 수 있으며 WordPress 게시물이 MySQL 데이터베이스에 저장됩니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이제 컨테이너와 Kubernetes에 대해 자세히 살펴봤는데요, 테스트용으로는 괜찮지만, 실제 웹사이트를 운영할 계획이라면 컨테이너만으로는 이 작업을 수행하지 않고 Kubernetes를 사용하여 이를 달성할 것입니다. 다음에는 Terraform과 Kubernetes를 사용하여 살펴보도록 하겠습니다.
|
||||||
|
|
||||||
|
### Provisioners
|
||||||
|
|
||||||
|
Provisioners는 어떤 것이 선언적일 수 없는 경우 이를 배포에 파싱할 수 있는 방법을 제공하기 위해 존재합니다.
|
||||||
|
|
||||||
|
다른 대안이 없고 코드에 이러한 복잡성을 추가해야 하는 경우 다음 코드 블록과 유사한 것을 실행하여 이를 수행할 수 있습니다.
|
||||||
|
|
||||||
|
```
|
||||||
|
resource "docker_container" "db" {
|
||||||
|
# ...
|
||||||
|
|
||||||
|
provisioner "local-exec" {
|
||||||
|
command = "echo The server's IP address is ${self.private_ip}"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
```
|
||||||
|
|
||||||
|
원격 실행 Provisioners는 원격 리소스가 생성된 후 원격 리소스에서 스크립트를 호출합니다. 이 스크립트는 OS에 따라 다르거나 구성 관리 도구에서 래핑하는 데 사용될 수 있습니다. 이 중 일부는 Provisioners에서 다루고 있습니다.
|
||||||
|
|
||||||
|
[Provisioners에 대한 자세한 내용](https://www.terraform.io/language/resources/provisioners/syntax)
|
||||||
|
|
||||||
|
- file
|
||||||
|
- local-exec
|
||||||
|
- remote-exec
|
||||||
|
- vendor
|
||||||
|
- ansible
|
||||||
|
- chef
|
||||||
|
- puppet
|
||||||
|
|
||||||
|
### 모듈
|
||||||
|
|
||||||
|
모듈은 함께 사용되는 여러 리소스를 위한 컨테이너입니다. 모듈은 동일한 디렉터리에 있는 .tf 파일 모음으로 구성됩니다.
|
||||||
|
|
||||||
|
모듈은 인프라 리소스를 분리할 수 있는 좋은 방법일 뿐만 아니라 이미 만들어진 타사 모듈을 가져올 수 있으므로 처음부터 다시 만들 필요가 없습니다.
|
||||||
|
|
||||||
|
예를 들어, 동일한 프로젝트를 사용하여 일부 VM, VPC, 보안 그룹을 구축한 다음 Kubernetes 클러스터도 구축하려는 경우 리소스를 모듈로 분할하여 리소스와 그룹화 위치를 더 잘 정의하고 싶을 것입니다.
|
||||||
|
|
||||||
|
모듈의 또 다른 장점은 이러한 모듈을 가져와 다른 프로젝트에 사용하거나 커뮤니티를 돕기 위해 공개적으로 공유할 수 있다는 것입니다.
|
||||||
|
|
||||||
|
저희는 인프라를 구성 요소로 나누고 있으며, 여기서 구성 요소는 모듈로 알려져 있습니다.
|
||||||
|
|
||||||
|
## 자료
|
||||||
|
|
||||||
|
아래에 많은 리소스를 나열했으며 이 주제는 이미 여러 번 다루어졌다고 생각합니다. 추가 리소스가 있는 경우 리소스와 함께 PR을 올리면 기꺼이 검토하여 목록에 추가해 드리겠습니다.
|
||||||
|
|
||||||
|
- [What is Infrastructure as Code? Difference of Infrastructure as Code Tools](https://www.youtube.com/watch?v=POPP2WTJ8es)
|
||||||
|
- [Terraform Tutorial | Terraform Course Overview 2021](https://www.youtube.com/watch?v=m3cKkYXl-8o)
|
||||||
|
- [Terraform explained in 15 mins | Terraform Tutorial for Beginners](https://www.youtube.com/watch?v=l5k1ai_GBDE)
|
||||||
|
- [Terraform Course - From BEGINNER to PRO!](https://www.youtube.com/watch?v=7xngnjfIlK4&list=WL&index=141&t=16s)
|
||||||
|
- [HashiCorp Terraform Associate Certification Course](https://www.youtube.com/watch?v=V4waklkBC38&list=WL&index=55&t=111s)
|
||||||
|
- [Terraform Full Course for Beginners](https://www.youtube.com/watch?v=EJ3N-hhiWv0&list=WL&index=39&t=27s)
|
||||||
|
- [KodeKloud - Terraform for DevOps Beginners + Labs: Complete Step by Step Guide!](https://www.youtube.com/watch?v=YcJ9IeukJL8&list=WL&index=16&t=11s)
|
||||||
|
- [Terraform Simple Projects](https://terraform.joshuajebaraj.com/)
|
||||||
|
- [Terraform Tutorial - The Best Project Ideas](https://www.youtube.com/watch?v=oA-pPa0vfks)
|
||||||
|
- [Awesome Terraform](https://github.com/shuaibiyy/awesome-terraform)
|
||||||
|
|
||||||
|
[Day 61](day61.md)에서 봐요!
|
||||||
172
2022/ko/Days/day61.md
Normal file
172
2022/ko/Days/day61.md
Normal file
@ -0,0 +1,172 @@
|
|||||||
|
---
|
||||||
|
title: '#90DaysOfDevOps - Kubernetes & Multiple Environments - Day 61'
|
||||||
|
published: false
|
||||||
|
description: 90DaysOfDevOps - Kubernetes & Multiple Environments
|
||||||
|
tags: 'devops, 90daysofdevops, learning'
|
||||||
|
cover_image: null
|
||||||
|
canonical_url: null
|
||||||
|
id: 1048743
|
||||||
|
---
|
||||||
|
|
||||||
|
## Kubernetes 및 다중 환경
|
||||||
|
|
||||||
|
지금까지 IaC에 대한 이 섹션에서는 가상 머신을 배포하는 방법을 살펴보았지만, 가상 머신의 모양을 코드에서 정의한 다음 배포한다는 전제는 실제로 동일합니다. Docker 컨테이너도 마찬가지이며, 이 세션에서는 Terraform을 사용하여 Kubernetes에서 지원하는 리소스와 상호 작용하는 방법을 살펴보겠습니다.
|
||||||
|
|
||||||
|
저는 데모 목적으로 3개의 주요 클라우드 제공업체에 Terraform을 사용하여 Kubernetes 클러스터를 배포해 왔으며, 리포지토리 [tf_k8deploy](https://github.com/MichaelCade/tf_k8deploy)를 찾을 수 있습니다.
|
||||||
|
|
||||||
|
그러나 Terraform을 사용하여 Kubernetes 클러스터 내의 객체와 상호 작용할 수도 있는데, 이는 [Kubernetes 공급자](https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs)를 사용하거나 [Helm 공급자](https://registry.terraform.io/providers/hashicorp/helm/latest)를 사용하여 차트 배포를 관리할 수 있습니다.
|
||||||
|
|
||||||
|
이제 이전 섹션에서 살펴본 것처럼 `kubectl`을 사용할 수 있습니다. 하지만 Kubernetes 환경에서 Terraform을 사용하면 몇 가지 이점이 있습니다.
|
||||||
|
|
||||||
|
- 통합 workflow - 클러스터 배포에 Terraform을 사용했다면, 동일한 workflow와 도구를 사용하여 Kubernetes 클러스터 내에 배포할 수 있습니다.
|
||||||
|
|
||||||
|
- 라이프사이클 관리 - Terraform은 단순한 프로비저닝 도구가 아니라 변경, 업데이트, 삭제를 가능하게 합니다.
|
||||||
|
|
||||||
|
### 간단한 Kubernetes 데모
|
||||||
|
|
||||||
|
지난 세션에서 만든 데모와 마찬가지로 이제 Kubernetes 클러스터에 nginx를 배포할 수 있습니다. 여기서는 데모 목적으로 Minikube를 다시 사용하겠습니다. Kubernetes.tf 파일을 생성하고 [여기](2022/Days/IaC/Kubernetes/Kubernetes.tf)에서 이 파일을 찾을 수 있습니다.
|
||||||
|
|
||||||
|
이 파일에서 Kubernetes 공급자를 정의하고, kubeconfig 파일을 가리키고, nginx라는 네임스페이스를 생성한 다음, 2개의 복제본과 마지막으로 서비스를 포함하는 배포를 생성하겠습니다.
|
||||||
|
|
||||||
|
```
|
||||||
|
terraform {
|
||||||
|
required_providers {
|
||||||
|
kubernetes = {
|
||||||
|
source = "hashicorp/kubernetes"
|
||||||
|
version = ">= 2.0.0"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
provider "kubernetes" {
|
||||||
|
config_path = "~/.kube/config"
|
||||||
|
}
|
||||||
|
resource "kubernetes_namespace" "test" {
|
||||||
|
metadata {
|
||||||
|
name = "nginx"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
resource "kubernetes_deployment" "test" {
|
||||||
|
metadata {
|
||||||
|
name = "nginx"
|
||||||
|
namespace = kubernetes_namespace.test.metadata.0.name
|
||||||
|
}
|
||||||
|
spec {
|
||||||
|
replicas = 2
|
||||||
|
selector {
|
||||||
|
match_labels = {
|
||||||
|
app = "MyTestApp"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
template {
|
||||||
|
metadata {
|
||||||
|
labels = {
|
||||||
|
app = "MyTestApp"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
spec {
|
||||||
|
container {
|
||||||
|
image = "nginx"
|
||||||
|
name = "nginx-container"
|
||||||
|
port {
|
||||||
|
container_port = 80
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
resource "kubernetes_service" "test" {
|
||||||
|
metadata {
|
||||||
|
name = "nginx"
|
||||||
|
namespace = kubernetes_namespace.test.metadata.0.name
|
||||||
|
}
|
||||||
|
spec {
|
||||||
|
selector = {
|
||||||
|
app = kubernetes_deployment.test.spec.0.template.0.metadata.0.labels.app
|
||||||
|
}
|
||||||
|
type = "NodePort"
|
||||||
|
port {
|
||||||
|
node_port = 30201
|
||||||
|
port = 80
|
||||||
|
target_port = 80
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
새 프로젝트 폴더에서 가장 먼저 해야 할 일은 `terraform init` 명령을 실행하는 것입니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
그리고 `terraform apply` 명령을 실행하기 전에 네임스페이스가 없다는 것을 보여드리겠습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
apply 명령을 실행하면 Kubernetes 클러스터 내에 3개의 새로운 리소스, 네임스페이스, 배포 및 서비스가 생성됩니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이제 클러스터 내에 배포된 리소스를 살펴볼 수 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이전 섹션에서 보셨듯이 Minikube를 사용하고 있기 때문에 도커 네트워킹으로 인그레스를 시도할 때 한계가 있습니다. 하지만 `kubectl port-forward -n nginx svc/nginx 30201:80` 명령을 실행하고 `http://localhost:30201/`으로 브라우저를 열면 NGINX 페이지를 볼 수 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Terraform과 Kubernetes에 대해 더 자세한 데모를 해보고 싶으시다면 [HashiCorp 학습 사이트](https://learn.hashicorp.com/tutorials/terraform/kubernetes-provider)를 방문해 보시기 바랍니다.
|
||||||
|
|
||||||
|
### 여러 환경
|
||||||
|
|
||||||
|
우리가 실행한 데모를 이제 특정 프로덕션, 스테이징 및 개발 환경이 동일하게 보이고 이 코드를 활용하기를 원한다면 Terraform을 사용하여 이를 달성하는 두 가지 접근 방식이 있습니다.
|
||||||
|
|
||||||
|
- `terraform workspaces` - 단일 백엔드 내의 여러 개의 명명된 섹션
|
||||||
|
|
||||||
|
- 파일 구조 - 디렉토리 레이아웃은 분리를 제공하고, 모듈은 재사용을 제공합니다.
|
||||||
|
|
||||||
|
하지만 위의 각 방법에는 장단점이 있습니다.
|
||||||
|
|
||||||
|
### Terraform workspaces
|
||||||
|
|
||||||
|
장점
|
||||||
|
|
||||||
|
- 쉬운 시작
|
||||||
|
- 편리한 terraform.workspace 표현식
|
||||||
|
- 코드 중복 최소화
|
||||||
|
|
||||||
|
단점
|
||||||
|
|
||||||
|
- 인적 오류가 발생하기 쉬움(TF를 사용하여 이를 제거하려고 노력 중임)
|
||||||
|
- 동일한 백엔드 내에 저장된 상태
|
||||||
|
- 코드베이스가 배포 구성을 명확하게 보여주지 않음.
|
||||||
|
|
||||||
|
### 파일 구조
|
||||||
|
|
||||||
|
장점
|
||||||
|
|
||||||
|
- 백엔드 격리
|
||||||
|
- 보안 향상
|
||||||
|
- 인적 오류 가능성 감소
|
||||||
|
- 배포된 상태를 완벽하게 나타내는 코드베이스
|
||||||
|
|
||||||
|
단점
|
||||||
|
|
||||||
|
- 프로비저닝 환경에 여러 Terraform 적용 필요
|
||||||
|
- 코드 중복이 더 많지만, 모듈을 사용하여 최소화할 수 있습니다.
|
||||||
|
|
||||||
|
## 자료
|
||||||
|
|
||||||
|
아래에 많은 리소스를 나열했으며 이 주제는 이미 여러 번 다루어졌다고 생각합니다. 추가 리소스가 있는 경우 리소스와 함께 PR을 올리면 기꺼이 검토하여 목록에 추가해 드리겠습니다.
|
||||||
|
|
||||||
|
- [What is Infrastructure as Code? Difference of Infrastructure as Code Tools](https://www.youtube.com/watch?v=POPP2WTJ8es)
|
||||||
|
- [Terraform Tutorial | Terraform Course Overview 2021](https://www.youtube.com/watch?v=m3cKkYXl-8o)
|
||||||
|
- [Terraform explained in 15 mins | Terraform Tutorial for Beginners](https://www.youtube.com/watch?v=l5k1ai_GBDE)
|
||||||
|
- [Terraform Course - From BEGINNER to PRO!](https://www.youtube.com/watch?v=7xngnjfIlK4&list=WL&index=141&t=16s)
|
||||||
|
- [HashiCorp Terraform Associate Certification Course](https://www.youtube.com/watch?v=V4waklkBC38&list=WL&index=55&t=111s)
|
||||||
|
- [Terraform Full Course for Beginners](https://www.youtube.com/watch?v=EJ3N-hhiWv0&list=WL&index=39&t=27s)
|
||||||
|
- [KodeKloud - Terraform for DevOps Beginners + Labs: Complete Step by Step Guide!](https://www.youtube.com/watch?v=YcJ9IeukJL8&list=WL&index=16&t=11s)
|
||||||
|
- [Terraform Simple Projects](https://terraform.joshuajebaraj.com/)
|
||||||
|
- [Terraform Tutorial - The Best Project Ideas](https://www.youtube.com/watch?v=oA-pPa0vfks)
|
||||||
|
- [Awesome Terraform](https://github.com/shuaibiyy/awesome-terraform)
|
||||||
|
|
||||||
|
[Day 62](day62.md)에서 봐요!
|
||||||
135
2022/ko/Days/day62.md
Normal file
135
2022/ko/Days/day62.md
Normal file
@ -0,0 +1,135 @@
|
|||||||
|
---
|
||||||
|
title: '#90DaysOfDevOps - Testing, Tools & Alternatives - Day 62'
|
||||||
|
published: false
|
||||||
|
description: '90DaysOfDevOps - Testing, Tools & Alternatives'
|
||||||
|
tags: 'devops, 90daysofdevops, learning'
|
||||||
|
cover_image: null
|
||||||
|
canonical_url: null
|
||||||
|
id: 1049053
|
||||||
|
---
|
||||||
|
|
||||||
|
## 테스트, 도구 및 대안
|
||||||
|
|
||||||
|
IaC에 대한 이 섹션을 마무리하면서 코드 테스트, 사용 가능한 다양한 도구, 그리고 이를 달성하기 위한 Terraform의 몇 가지 대안에 대해 언급하지 않을 수 없습니다. 이 섹션의 시작 부분에서 말씀드렸듯이 제가 Terraform에 초점을 맞춘 이유는 첫째로 무료이며 오픈 소스이고 둘째로 크로스 플랫폼이며 환경에 구애받지 않기 때문입니다. 하지만 고려해야 할 다른 대안도 있지만, 전반적인 목표는 이것이 인프라를 배포하는 방법이라는 것을 사람들에게 알리는 것입니다.
|
||||||
|
|
||||||
|
### Code Rot
|
||||||
|
|
||||||
|
이 세션에서 다루고자 하는 첫 번째 영역은 Code Rot으로, 애플리케이션 코드와 달리 코드로서의 인프라는 한 번 사용되었다가 오랫동안 사용하지 않을 수도 있습니다. Terraform을 사용하여 AWS에 VM 환경을 배포하려고 하는데, 처음에 완벽하게 작동하고 환경이 갖춰졌지만, 이 환경이 자주 변경되지 않아 코드가 중앙 위치에 저장되기를 바라지만 코드가 변경되지 않는 상태를 그대로 유지한다고 가정해 보겠습니다.
|
||||||
|
|
||||||
|
인프라에 변화가 생기면 어떻게 될까요? 하지만 대역 외에서 수행되거나 다른 환경이 변경되는 경우가 있습니다.
|
||||||
|
|
||||||
|
- 대역 외 변경 사항
|
||||||
|
- 고정되지 않은 버전
|
||||||
|
- 더 이상 사용되지 않는 종속성
|
||||||
|
- 적용되지 않은 변경 사항
|
||||||
|
|
||||||
|
### 테스트
|
||||||
|
|
||||||
|
코드 썩음과 일반적으로 뒤따르는 또 다른 큰 영역은 IaC를 테스트하고 모든 영역이 정상적으로 작동하는지 확인하는 기능입니다.
|
||||||
|
|
||||||
|
먼저 살펴볼 수 있는 몇 가지 기본 제공 테스트 명령어가 있습니다:
|
||||||
|
|
||||||
|
| Command | Description |
|
||||||
|
| -------------------- | ------------------------------------------------------------------------ |
|
||||||
|
| `terraform fmt` | Terraform 구성 파일을 표준 형식과 스타일로 다시 작성합니다. |
|
||||||
|
| `terraform validate` | 디렉터리에 있는 구성 파일의 유효성을 검사하여 구성만 참조합니다. |
|
||||||
|
| `terraform plan` | 실행 계획을 생성하여 Terraform이 계획한 변경 사항을 미리 볼 수 있습니다. |
|
||||||
|
| Custom validation | 입력 변수가 예상과 일치하는지 확인하기 위한 입력 변수 유효성 검사 |
|
||||||
|
|
||||||
|
Terraform 외부에서 사용할 수 있는 몇 가지 테스트 도구도 있습니다:
|
||||||
|
|
||||||
|
- [tflint](https://github.com/terraform-linters/tflint)
|
||||||
|
|
||||||
|
- 가능한 오류를 찾습니다.
|
||||||
|
- 더 이상 사용되지 않는 구문과 사용되지 않는 선언에 대해 경고합니다.
|
||||||
|
- 모범 사례와 명명 규칙을 적용합니다.
|
||||||
|
|
||||||
|
검사 도구
|
||||||
|
|
||||||
|
- [checkov](https://www.checkov.io/) - 클라우드 인프라 구성을 스캔하여 배포하기 전에 잘못된 구성을 찾습니다.
|
||||||
|
- [tfsec](https://aquasecurity.github.io/tfsec/v1.4.2/) - Terraform 코드에 대한 정적 분석 보안 스캐너입니다.
|
||||||
|
- [terrascan](https://github.com/accurics/terrascan) - IaC를 위한 정적 코드 분석기입니다.
|
||||||
|
- [terraform-compliance](https://terraform-compliance.com/) - IaC에 대한 네거티브 테스트 기능을 지원하는 Terraform에 대한 경량의 보안 및 규정 준수 중심 테스트 프레임워크입니다.
|
||||||
|
- [snyk](https://docs.snyk.io/products/snyk-infrastructure-as-code/scan-terraform-files/scan-and-fix-security-issues-in-terraform-files) - Terraform 코드에서 잘못된 구성과 보안 문제를 스캔합니다.
|
||||||
|
|
||||||
|
관리형 클라우드 제품
|
||||||
|
|
||||||
|
- [Terraform Sentinel](https://www.terraform.io/cloud-docs/sentinel) - HashCorp 엔터프라이즈 제품과 통합된 임베디드 정책 기반 프레임워크로 세분화된 로직 기반 정책 결정을 가능하게 하며, 외부 소스의 정보를 사용하도록 확장할 수 있습니다.
|
||||||
|
|
||||||
|
### 자동화된 테스트
|
||||||
|
|
||||||
|
- [Terratest](https://terratest.gruntwork.io/) - Terratest는 인프라 테스트를 위한 패턴과 도우미 함수를 제공하는 Go 라이브러리입니다.
|
||||||
|
- Terratest는 인프라 코드에 대한 자동화된 테스트 작성을 용이하게 합니다. 일반적인 인프라 테스트를 위한 다양한 도우미 함수와 패턴을 제공합니다.
|
||||||
|
- 코드는 2022/Days/IaC/Terratest에서 찾을 수 있습니다.
|
||||||
|
- 이 애플리케이션을 실행하려면
|
||||||
|
- git clone #repo_url# <br />
|
||||||
|
- cd test <br />
|
||||||
|
- go mod init "<MODULE_NAME>" <br />
|
||||||
|
**MODULE_NAME은 github.com/<YOUR_USERNAME>/<YOUR_REPO_NAME>이 됩니다.** <br />
|
||||||
|
- go mod init github.com/<FOLDER-PATH> <br/>
|
||||||
|
- go run
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
go mod init "<MODULE_NAME>"은 테스트 폴더에 go.mod 파일을 생성합니다. <br />
|
||||||
|
|
||||||
|
- go.mod 파일은 GoLang에서 의존성 관리의 기초입니다.
|
||||||
|
- 프로젝트에서 필요하거나 사용할 모든 모듈이 go.mod 파일에 유지됩니다.
|
||||||
|
- 프로젝트에서 사용하거나 가져올 모든 패키지의 항목을 생성합니다.
|
||||||
|
- 수동으로 각 종속성을 가져오는 노력을 줄입니다.
|
||||||
|
|
||||||
|
처음 **go test**를 실행하면 go.sum 파일이 생성됩니다. <br />
|
||||||
|
|
||||||
|
- **go test** 또는 **go build**가 처음 실행될 때 go.sum 파일이 생성됩니다.
|
||||||
|
- 특정 버전(최신)으로 모든 패키지를 설치합니다.
|
||||||
|
- 우린 파일을 편집하거나 수정할 필요가 없습니다.
|
||||||
|
|
||||||
|
추가로 언급할 만한 것들
|
||||||
|
|
||||||
|
- [Terraform 클라우드](https://cloud.hashicorp.com/products/terraform) - Terraform 클라우드는 HashCorp의 관리형 서비스 제품입니다. 실무자, 팀 및 조직이 프로덕션에서 Terraform을 사용하기 위해 불필요한 도구와 문서가 필요하지 않습니다.
|
||||||
|
|
||||||
|
- [Terragrunt](https://terragrunt.gruntwork.io/) - Terragrunt는 구성을 건조하게 유지하고, 여러 Terraform 모듈로 작업하고, 원격 상태를 관리하기 위한 추가 도구를 제공하는 얇은 래퍼입니다.
|
||||||
|
|
||||||
|
- [Atlantis](https://www.runatlantis.io/) - Terraform 풀 리퀘스트 자동화
|
||||||
|
|
||||||
|
### 대안
|
||||||
|
|
||||||
|
이 섹션을 시작할 때 57일째에 몇 가지 대안이 있다고 언급했으며, 이번 챌린지에서도 이에 대해 계속 살펴볼 계획입니다.
|
||||||
|
|
||||||
|
| Cloud Specific | Cloud Agnostic |
|
||||||
|
| ------------------------------- | -------------- |
|
||||||
|
| AWS CloudFormation | Terraform |
|
||||||
|
| Azure Resource Manager | Pulumi |
|
||||||
|
| Google Cloud Deployment Manager | |
|
||||||
|
|
||||||
|
저는 위의 목록 중 AWS CloudFormation을 가장 많이 사용했으며 AWS에서 기본으로 제공하지만, Terraform 이외의 다른 제품은 사용해 본 적이 없습니다. 클라우드별 버전은 특정 클라우드에서는 매우 훌륭하지만, 여러 클라우드 환경이 있는 경우 이러한 구성을 마이그레이션하는 데 어려움을 겪거나 IaC 작업을 위해 여러 관리 플레인을 사용해야 할 것입니다.
|
||||||
|
|
||||||
|
흥미로운 다음 단계는 시간을 내서 [Pulumi](https://www.pulumi.com/)에 대해 자세히 알아보는 것입니다.
|
||||||
|
|
||||||
|
Pulumi 사이트의 비교 부분에서
|
||||||
|
|
||||||
|
> "Terraform과 Pulumi 모두 코드가 원하는 인프라 상태를 나타내는 코드 모델로 원하는 상태 인프라를 제공하며, 배포 엔진은 이 원하는 상태를 스택의 현재 상태와 비교하여 어떤 리소스를 생성, 업데이트 또는 삭제해야 하는지를 결정합니다."
|
||||||
|
|
||||||
|
제가 볼 수 있는 가장 큰 차이점은 HCL(HashCorp 구성 언어)과 달리 Pulumi는 Python, TypeScript, JavaScript, Go, .NET과 같은 범용 언어를 허용한다는 점입니다.
|
||||||
|
|
||||||
|
간략한 개요 [Pulumi 소개: 코드형 최신 인프라](https://www.youtube.com/watch?v=QfJTJs24-JM) 저는 선택의 폭이 넓다는 점이 마음에 들어서 좀 더 자세히 알아보고 싶었습니다.
|
||||||
|
|
||||||
|
이것으로 IaC 섹션을 마무리하고, 다음에는 구성 관리와 약간 겹치는 부분, 특히 일부 작업 및 데모에 Ansible을 사용할 구성 관리의 큰 그림을 살펴볼 것입니다.
|
||||||
|
|
||||||
|
## 리소스
|
||||||
|
|
||||||
|
아래에 많은 리소스를 나열했으며 이 주제는 이미 여러 번 다루어졌다고 생각합니다. 추가 리소스가 있는 경우 리소스와 함께 PR을 올리면 기꺼이 검토하여 목록에 추가해 드리겠습니다.
|
||||||
|
|
||||||
|
- [What is Infrastructure as Code? Difference of Infrastructure as Code Tools](https://www.youtube.com/watch?v=POPP2WTJ8es)
|
||||||
|
- [Terraform Tutorial | Terraform Course Overview 2021](https://www.youtube.com/watch?v=m3cKkYXl-8o)
|
||||||
|
- [Terraform explained in 15 mins | Terraform Tutorial for Beginners](https://www.youtube.com/watch?v=l5k1ai_GBDE)
|
||||||
|
- [Terraform Course - From BEGINNER to PRO!](https://www.youtube.com/watch?v=7xngnjfIlK4&list=WL&index=141&t=16s)
|
||||||
|
- [HashiCorp Terraform Associate Certification Course](https://www.youtube.com/watch?v=V4waklkBC38&list=WL&index=55&t=111s)
|
||||||
|
- [Terraform Full Course for Beginners](https://www.youtube.com/watch?v=EJ3N-hhiWv0&list=WL&index=39&t=27s)
|
||||||
|
- [KodeKloud - Terraform for DevOps Beginners + Labs: Complete Step by Step Guide!](https://www.youtube.com/watch?v=YcJ9IeukJL8&list=WL&index=16&t=11s)
|
||||||
|
- [Terraform Simple Projects](https://terraform.joshuajebaraj.com/)
|
||||||
|
- [Terraform Tutorial - The Best Project Ideas](https://www.youtube.com/watch?v=oA-pPa0vfks)
|
||||||
|
- [Awesome Terraform](https://github.com/shuaibiyy/awesome-terraform)
|
||||||
|
- [Pulumi - IaC in your favorite programming language!](https://www.youtube.com/watch?v=vIjeiDcsR3Q&t=51s)
|
||||||
|
|
||||||
|
[Day 63](day63.md)에서 봐요!
|
||||||
101
2022/ko/Days/day63.md
Normal file
101
2022/ko/Days/day63.md
Normal file
@ -0,0 +1,101 @@
|
|||||||
|
---
|
||||||
|
title: '#90DaysOfDevOps - The Big Picture: Configuration Management - Day 63'
|
||||||
|
published: false
|
||||||
|
description: 90DaysOfDevOps - The Big Picture Configuration Management
|
||||||
|
tags: 'devops, 90daysofdevops, learning'
|
||||||
|
cover_image: null
|
||||||
|
canonical_url: null
|
||||||
|
id: 1048711
|
||||||
|
---
|
||||||
|
|
||||||
|
## 큰 그림: 구성 관리
|
||||||
|
|
||||||
|
IaC를 다루는 섹션의 뒷부분에서 바로 이어서 구성 관리 또는 애플리케이션 구성 관리에 대해 이야기할 때 약간의 교차점이 있을 것입니다.
|
||||||
|
|
||||||
|
구성 관리는 애플리케이션, 시스템, 서버를 원하는 상태로 유지하는 프로세스입니다. 인프라스트럭처와 겹치는 부분은 IaC가 인프라가 원하는 상태에 있는지 확인하지만, 그 이후에는 특히 Terraform이 OS 설정이나 애플리케이션의 원하는 상태를 관리하지 않기 때문에 구성 관리 도구가 필요하다는 점입니다. Deane에서 변경 사항이 발생할 때 시스템과 애플리케이션이 예상대로 작동하는지 확인합니다.
|
||||||
|
|
||||||
|
구성 관리는 문서화되지 않은 크고 작은 변경을 방지합니다.
|
||||||
|
|
||||||
|
### 시나리오: 구성 관리를 사용하려는 이유
|
||||||
|
|
||||||
|
구성 관리를 사용하고자 하는 시나리오나 이유를 알기 위해 철수를 만나보세요. 철수는 우리의 시스템 관리자이며, 환경 내의 모든 시스템에서 열심히 일하며 만족하는 사람입니다.
|
||||||
|
|
||||||
|
시스템에 장애가 발생하거나 화재가 발생하거나 서버가 다운되면 어떻게 될까요? 철수는 화재가 발생하면 어떻게 해야 하는지 정확히 알고 있기 때문에 쉽게 해결할 수 있지만, 특히 대규모로 확장하는 환경에서 여러 서버가 장애를 일으키기 시작하면 철수에게 구성 관리 도구가 필요한 이유가 바로 여기에 있습니다. 구성 관리 도구는 철수가 각 서버를 빠르고 효과적으로 대규모로 설정하는 방법에 대한 지침을 푸시할 수 있는 올바른 코드를 구성하기만 하면 되는 록스타처럼 보이도록 도와줄 수 있습니다.
|
||||||
|
|
||||||
|
### 구성 관리 도구
|
||||||
|
|
||||||
|
다양한 구성 관리 도구를 사용할 수 있으며, 각 도구에는 특정 상황에 더 적합한 특정 기능이 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이 단계에서는 위 그림의 옵션을 간략히 살펴본 후 어떤 도구를 사용할지, 왜 사용할지 결정하겠습니다.
|
||||||
|
|
||||||
|
- **Chef**
|
||||||
|
- Chef는 인프라 자동화를 통해 모든 환경, 모든 규모에서 구성이 일관되게 적용되도록 보장합니다.
|
||||||
|
- Chef는 Ruby와 Erlang으로 작성된 OpsCode에서 개발한 오픈 소스 도구입니다.
|
||||||
|
- Chef는 이기종 인프라를 보유하고 있으며 성숙한 솔루션을 찾고 있는 조직에 가장 적합합니다.
|
||||||
|
- Recipes와 Cookbooks은 시스템의 구성 코드를 결정합니다.
|
||||||
|
- 프로 - 방대한 Recipes 컬렉션을 사용할 수 있습니다.
|
||||||
|
- 장점 - 강력한 버전 제어를 제공하는 Git과 잘 통합됩니다.
|
||||||
|
- 단점 - 학습 곡선이 가파르며 상당한 시간이 필요합니다
|
||||||
|
- 단점 - 메인 서버에서 제어할 수 있는 권한이 많지 않습니다.
|
||||||
|
- 아키텍처 - 서버/클라이언트
|
||||||
|
- 설정 용이성 - 보통
|
||||||
|
- 언어 - 절차적 - 작업 수행 방법 지정
|
||||||
|
- **Puppet**
|
||||||
|
- Puppet은 자동 배포를 지원하는 구성 관리 도구입니다.
|
||||||
|
- Puppet은 Ruby로 빌드되며 매니페스트 작성에 DSL을 사용합니다.
|
||||||
|
- Puppet은 확장성에 중점을 둔 이기종 인프라에서도 잘 작동합니다.
|
||||||
|
- 장점 - 지원을 위한 대규모 커뮤니티가 있습니다.
|
||||||
|
- 장점 - 잘 발달된 보고 메커니즘입니다.
|
||||||
|
- 단점 - 고급 작업을 수행하려면 Ruby 언어에 대한 지식이 필요합니다.
|
||||||
|
- 단점 - 메인 서버에 대한 제어 권한이 많지 않습니다.
|
||||||
|
- 아키텍처 - 서버/클라이언트
|
||||||
|
- 설정 용이성 - 보통
|
||||||
|
- 언어 - 선언적 - 수행할 작업만 지정 가능
|
||||||
|
- **Ansible**
|
||||||
|
- Ansible은 구성 관리, 클라우드 프로비저닝, 배포 및 오케스트레이션을 자동화하는 IT 자동화 도구입니다.
|
||||||
|
- Ansible Playbook의 핵심은 YAML로 작성되어 있습니다. (몇 번 본 적이 있으므로 YAML에 대한 섹션을 만들어야 합니다.)
|
||||||
|
- Ansible은 빠르게 시작하고 실행하는 데 중점을 두는 환경이 있을 때 잘 작동합니다.
|
||||||
|
- 서버에 지침을 제공하는 Playbook에서 작동합니다.
|
||||||
|
- 장점 - 원격 노드에 에이전트가 필요하지 않습니다.
|
||||||
|
- 장점 - YAML은 배우기 쉽습니다.
|
||||||
|
- 단점 - 성능 속도가 다른 도구보다 느린 경우가 많습니다.(철수가 직접 수동으로 수행하는 것보다 빠름)
|
||||||
|
- 단점 - YAML은 Ruby만큼 강력하지는 않지만 학습 곡선이 적습니다.
|
||||||
|
- 아키텍처 - 클라이언트 전용
|
||||||
|
- 설정 용이성 - 매우 쉬움
|
||||||
|
- 언어 - 절차적 - 작업 수행 방법 지정
|
||||||
|
- **SaltStack**
|
||||||
|
- SaltStack은 구성 관리와 원격 실행을 자동화하는 CLI 기반 도구입니다.
|
||||||
|
- SaltStack은 Python 기반이며, 명령어는 YAML 또는 해당 DSL로 작성됩니다.
|
||||||
|
- 확장성과 복원력을 최우선으로 고려하는 환경에 적합합니다.
|
||||||
|
- 장점 - 가동 및 실행 시 사용이 간편합니다.
|
||||||
|
- 장점 - 우수한 보고 메커니즘입니다.
|
||||||
|
- 단점 - 설정 단계가 까다롭습니다.
|
||||||
|
- 단점 - 다른 서비스보다 훨씬 덜 개발된 새로운 웹 UI가 있습니다.
|
||||||
|
- 아키텍처 - 서버/클라이언트
|
||||||
|
- 설정 용이성 - 보통
|
||||||
|
- 언어 - 선언적 - 수행할 작업만 지정함
|
||||||
|
|
||||||
|
### Ansible과 Terraform 비교
|
||||||
|
|
||||||
|
이 섹션에서 사용할 도구는 Ansible입니다. (사용하기 쉽고 언어에 지식이 약간만 필요합니다.)
|
||||||
|
|
||||||
|
도구를 좀 더 자세히 살펴보기 전에 Ansible과 Terraform의 몇 가지 차이점을 살펴보는 것이 중요하다고 생각합니다.
|
||||||
|
|
||||||
|
| | Ansible | Terraform |
|
||||||
|
| ----------------- | --------------------------------------------------------------------------------------- | ------------------------------------------------------------------- |
|
||||||
|
| 유형 | Ansible은 구성 관리 도구입니다. | Terraform은 오케스트레이션 도구입니다. |
|
||||||
|
| 인프라 | Ansible은 변경 가능한 인프라를 지원하며, Terraform은 변경 불가능한 인프라를 지원합니다. |
|
||||||
|
| 언어 | Ansible은 절차적 언어를 따르고, Terraform은 선언적 언어를 따릅니다. |
|
||||||
|
| 프로비저닝 | 부분 프로비저닝(VM, 네트워크, 스토리지) 제공합니다. | Terraform은 광범위한 프로비저닝(VM, 네트워크, 스토리지) 제공합니다. |
|
||||||
|
| 패키징 | 패키징 및 템플릿에 대한 완벽한 지원 제공합니다. | 패키징 및 템플릿에 대한 부분 지원 제공합니다. |
|
||||||
|
| 라이프사이클 관리 | Ansible에는 라이프사이클 관리 기능이 없습니다. | Terraform은 라이프사이클 및 상태 관리에 크게 의존합니다. |
|
||||||
|
|
||||||
|
## 자료
|
||||||
|
|
||||||
|
- [What is Ansible](https://www.youtube.com/watch?v=1id6ERvfozo)
|
||||||
|
- [Ansible 101 - Episode 1 - Introduction to Ansible](https://www.youtube.com/watch?v=goclfp6a2IQ)
|
||||||
|
- [NetworkChuck - You need to learn Ansible right now!](https://www.youtube.com/watch?v=5hycyr-8EKs&t=955s)
|
||||||
|
|
||||||
|
[Day 64](day64.md)에서 봐요!
|
||||||
87
2022/ko/Days/day64.md
Normal file
87
2022/ko/Days/day64.md
Normal file
@ -0,0 +1,87 @@
|
|||||||
|
---
|
||||||
|
title: '#90DaysOfDevOps - Ansible: Getting Started - Day 64'
|
||||||
|
published: false
|
||||||
|
description: '90DaysOfDevOps - Ansible: Getting Started'
|
||||||
|
tags: 'devops, 90daysofdevops, learning'
|
||||||
|
cover_image: null
|
||||||
|
canonical_url: null
|
||||||
|
id: 1048765
|
||||||
|
---
|
||||||
|
|
||||||
|
## Ansible: 시작하기
|
||||||
|
|
||||||
|
어제 [Day 63](day63.md)에서 Ansible이 무엇인지에 대해 조금 다루었지만 여기서는 이에 대해 조금 더 자세히 알아보겠습니다. 먼저 Ansible은 RedHat에서 제공합니다. 둘째, 에이전트가 없으며 SSH를 통해 연결하고 명령을 실행합니다. 셋째, 크로스 플랫폼(Linux 및 macOS, WSL2) 및 오픈 소스(엔터프라이즈용 유료 옵션도 있음)이며 다른 모델에 비해 Ansible은 구성을 push합니다.
|
||||||
|
|
||||||
|
### Ansible 설치
|
||||||
|
|
||||||
|
여러분이 상상할 수 있듯이, RedHat과 Ansible 팀은 Ansible을 문서화하는 데 환상적인 작업을 해왔습니다. 이는 일반적으로 [여기](https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html)에서 찾을 수 있는 설치 단계부터 시작됩니다. Ansible은 에이전트가 없는 자동화 도구이며, 이 도구는 "Control Node"라고 하는 시스템에 배포되고 이 Control Node에서 SSH를 통해 머신 및 기타 장치(네트워크일 수 있음)를 관리한다고 말씀드린 것을 기억하세요.
|
||||||
|
|
||||||
|
위에 링크된 문서에는 Windows OS를 Control Node로 사용할 수 없다고 명시되어 있습니다.
|
||||||
|
|
||||||
|
Control Node 및 적어도 이 데모에서는 [Linux 섹션](day20.md)에서 만든 Linux VM을 Control Node로 사용하겠습니다.
|
||||||
|
|
||||||
|
이 시스템은 우분투를 실행 중이며 설치 단계는 다음 명령만 있으면 됩니다.
|
||||||
|
|
||||||
|
```Shell
|
||||||
|
sudo apt update
|
||||||
|
sudo apt install software-properties-common
|
||||||
|
sudo add-apt-repository --yes --update ppa:ansible/ansible
|
||||||
|
sudo apt install ansible
|
||||||
|
```
|
||||||
|
|
||||||
|
이제 Control Node에 ansible이 설치되어 있어야 하며, `ansible --version`을 실행하여 확인할 수 있으며 아래와 비슷한 내용이 표시됩니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이제 환경의 다른 Node를 제어하는 방법을 살펴보기 전에 로컬 머신에 대해 `ansible localhost -m ping` 명령을 실행하여 ansible의 기능을 확인할 수도 있습니다. 이 명령은 [Ansible 모듈](https://docs.ansible.com/ansible/2.9/user_guide/modules_intro.html)을 사용하며, 여러 시스템에서 하나의 작업을 빠르게 수행할 수 있는 방법이기도 합니다. 로컬 호스트만으로는 그다지 재미있지 않지만, 무언가를 얻거나 모든 시스템이 가동 중이고 1000개 이상의 서버와 디바이스가 있다고 상상해 보세요.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
또는 실제 모듈의 실제 사용법은 `ansible webservers -m service -a "name=httpd state=started"`와 같이 모든 웹서버에 httpd 서비스가 실행 중인지 여부를 알려주는 것일 수 있습니다. 이 명령에 사용된 웹서버 용어에 대해 간략히 설명했습니다.
|
||||||
|
|
||||||
|
### 호스트
|
||||||
|
|
||||||
|
위에서 localhost를 사용하여 시스템에 대한 간단한 핑 모듈을 실행하는 방법으로는 네트워크에 다른 컴퓨터를 지정할 수 없습니다. 예를 들어 VirtualBox가 실행 중인 Windows 호스트에는 IP 10.0.0.1의 네트워크 어댑터가 있지만 아래에서 볼 수 있듯이 핑으로 연결할 수 있지만 ansible을 사용하여 해당 작업을 수행할 수 없습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이러한 작업으로 자동화할 호스트 또는 Node를 지정하려면 이를 정의해야 합니다. 시스템의 /etc/ansible 디렉토리로 이동하여 정의할 수 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
편집하려는 파일은 호스트 파일이며, 텍스트 편집기를 사용하여 호스트를 정의할 수 있습니다. 호스트 파일에는 파일을 사용하고 수정하는 방법에 대한 많은 훌륭한 지침이 포함되어 있습니다. 아래로 스크롤하여 [windows]라는 새 그룹을 만들고 해당 호스트에 대한 `10.0.0.1` IP 주소를 추가하겠습니다. 파일을 저장합니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
그러나 Ansible이 시스템에 연결하려면 SSH를 사용할 수 있어야 한다고 말씀드린 것을 기억하세요. 아래에서 볼 수 있듯이 `ansible windows -m ping`을 실행하면 SSH를 통한 연결에 실패하여 연결할 수 없다는 메시지가 표시됩니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이제 인벤토리에 호스트를 추가하기 시작했는데, 모든 장치를 정의하는 곳이기 때문에 이 파일의 다른 이름인 네트워크 장치, 스위치 및 라우터도 여기에 추가하고 그룹화할 수 있습니다. 하지만 호스트 파일에는 Linux 시스템 그룹에 액세스하기 위한 자격 증명도 추가했습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이제 `ansible Linux -m ping`을 실행하면 아래와 같이 성공합니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이제 구성을 자동화하려는 대상 시스템인 Node 요구 사항이 있습니다. 이 시스템에는 Ansible을 위한 어떤 것도 설치하지 않습니다(소프트웨어를 설치할 수는 있지만 필요한 Ansible의 클라이언트는 없습니다). Ansible은 SSH를 통해 연결하고 SFTP를 통해 모든 것을 전송합니다. (원하는 경우 SSH를 구성한 경우 SCP 대 SFTP를 사용할 수 있습니다.)
|
||||||
|
|
||||||
|
### Ansible 명령
|
||||||
|
|
||||||
|
리눅스 머신에 대해 `ansible Linux -m ping`을 실행하고 응답을 얻을 수 있는 것을 보셨겠지만, 기본적으로 Ansible을 사용하면 많은 adhoc 명령을 실행할 수 있습니다. 하지만 이 명령을 시스템 그룹에 대해 실행하여 해당 정보를 다시 가져올 수 있습니다. [adhoc 명령](https://docs.ansible.com/ansible/latest/user_guide/intro_adhoc.html)
|
||||||
|
|
||||||
|
명령을 반복하거나 이러한 명령을 실행하기 위해 개별 시스템에 로그인해야 하는 경우 Ansible이 도움이 될 수 있습니다. 예를 들어, 아래의 간단한 명령은 Linux 그룹에 추가하는 모든 시스템에 대한 모든 운영 체제 세부 정보를 출력합니다.
|
||||||
|
`ansible linux -a "cat /etc/os-release"`
|
||||||
|
|
||||||
|
다른 사용 사례로는 시스템 재부팅, 파일 복사, 패커 및 사용자 관리 등이 있습니다. adhoc 명령과 Ansible 모듈을 결합할 수도 있습니다.
|
||||||
|
|
||||||
|
adhoc 명령은 선언적 모델을 사용하여 지정된 최종 상태에 도달하는 데 필요한 작업을 계산하고 실행합니다. adhoc 명령은 시작하기 전에 현재 상태를 확인하고 현재 상태가 지정된 최종 상태와 다르지 않으면 아무 작업도 수행하지 않음으로써 일종의 무임승차를 하는 셈입니다.
|
||||||
|
|
||||||
|
## 자료
|
||||||
|
|
||||||
|
- [What is Ansible](https://www.youtube.com/watch?v=1id6ERvfozo)
|
||||||
|
- [Ansible 101 - Episode 1 - Introduction to Ansible](https://www.youtube.com/watch?v=goclfp6a2IQ)
|
||||||
|
- [NetworkChuck - You need to learn Ansible right now!](https://www.youtube.com/watch?v=5hycyr-8EKs&t=955s)
|
||||||
|
|
||||||
|
[Day 65](day65.md)에서 봐요!
|
||||||
278
2022/ko/Days/day65.md
Normal file
278
2022/ko/Days/day65.md
Normal file
@ -0,0 +1,278 @@
|
|||||||
|
---
|
||||||
|
title: '#90DaysOfDevOps - Ansible Playbooks - Day 65'
|
||||||
|
published: false
|
||||||
|
description: 90DaysOfDevOps - Ansible Playbooks
|
||||||
|
tags: 'devops, 90daysofdevops, learning'
|
||||||
|
cover_image: null
|
||||||
|
canonical_url: null
|
||||||
|
id: 1049054
|
||||||
|
---
|
||||||
|
|
||||||
|
### Ansible Playbook
|
||||||
|
|
||||||
|
이 섹션에서는 적어도 Ansible의 경우 하나의 명령으로 여러 서버를 실행하여 긴 서버 목록을 재부팅하는 것과 같은 간단한 명령을 수행하고 각 서버에 개별적으로 연결해야 하는 번거로움을 줄일 수 있다는 점이 가장 큰 장점이라고 할 수 있습니다.
|
||||||
|
|
||||||
|
하지만 실제로 베어 운영 체제를 가져와서 해당 시스템에서 실행할 소프트웨어와 서비스를 선언하고 모두 원하는 상태로 실행되도록 하는 것은 어떨까요?
|
||||||
|
|
||||||
|
이것이 바로 Ansible Playbook이 필요한 이유입니다. Playbook을 사용하면 서버 그룹을 가져와서 해당 그룹에 대해 구성 및 설치 작업을 수행할 수 있습니다.
|
||||||
|
|
||||||
|
### Playbook 형식
|
||||||
|
|
||||||
|
Playbook > Play > Task
|
||||||
|
|
||||||
|
스포츠에 관심이 있는 분이라면 Playbook이라는 용어를 들어보셨을 텐데요, Playbook은 다양한 Play와 Task로 구성된 Play 방법을 팀에게 알려주는 것으로, Play를 스포츠나 게임의 세트 피스라고 생각하면 각 Play에 Task가 연관되어 있고, Play를 구성하는 여러 Task가 있을 수 있으며, Playbook에는 여러 가지 다른 Play가 있을 수 있습니다.
|
||||||
|
|
||||||
|
이러한 Playbook은 YAML(YAML은 마크업 언어가 아님)로 작성되어 있으며, 지금까지 다룬 많은 섹션, 특히 컨테이너와 Kubernetes에서 YAML 형식의 구성 파일을 찾을 수 있습니다.
|
||||||
|
|
||||||
|
playbook.yml이라는 간단한 Playbook을 살펴보겠습니다.
|
||||||
|
|
||||||
|
```Yaml
|
||||||
|
- name: Simple Play
|
||||||
|
hosts: localhost
|
||||||
|
connection: local
|
||||||
|
tasks:
|
||||||
|
- name: Ping me
|
||||||
|
ping:
|
||||||
|
- name: print os
|
||||||
|
debug:
|
||||||
|
msg: "{{ ansible_os_family }}"
|
||||||
|
```
|
||||||
|
|
||||||
|
위의 파일 [simple_play](/2022/Days/Configmgmt/simple_play.yml)을 찾을 수 있습니다. 그런 다음 `ansible-playbook simple_play.yml` 명령을 사용하면 다음 단계를 수행합니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
'gathering facts'라는 첫 번째 Task가 발생한 것을 볼 수 있지만, 우리가 트리거하거나 요청하지 않았나요? 이 모듈은 원격 호스트에 대한 유용한 변수를 수집하기 위해 Playbook에서 자동으로 호출됩니다. [ansible.builtin.setup](https://docs.ansible.com/ansible/latest/collections/ansible/builtin/setup_module.html)
|
||||||
|
|
||||||
|
두 번째 Task는 Ping을 설정하는 것이었는데, 이것은 ICMP Ping이 아니라 원격 또는 로컬 호스트에 대한 연결 성공 시 `pong`을 반환하는 파이썬 스크립트입니다. [ansible.builtin.ping](https://docs.ansible.com/ansible/latest/collections/ansible/builtin/ping_module.html)
|
||||||
|
|
||||||
|
그런 다음 첫 번째 Task로 정의한 세 번째 또는 두 번째 Task는 OS를 알려주는 메시지 인쇄를 비활성화하지 않는 한 실행됩니다. 이 Task에서는 조건문을 사용하고 있으므로 모든 유형의 운영 체제에 대해 이 Playbook을 실행할 수 있으며, 그러면 OS 이름이 반환됩니다. 편의상 이 출력은 단순히 메시지를 출력하고 있지만 다음과 같이 말하는 Task를 추가할 수 있습니다:
|
||||||
|
|
||||||
|
```Yaml
|
||||||
|
tasks:
|
||||||
|
- name: "shut down Debian flavoured systems"
|
||||||
|
command: /sbin/shutdown -t now
|
||||||
|
when: ansible_os_family == "Debian"
|
||||||
|
```
|
||||||
|
|
||||||
|
### Vagrant로 환경 설정하기
|
||||||
|
|
||||||
|
Vagrant를 사용하여 Node 환경을 설정할 것입니다. 저는 이것을 합리적인 4 Node로 유지하려고 하지만 300 Node 또는 3000 Node가 될 수 있으며 이것이 서버를 구성할 수 있는 Ansible 및 기타 구성 관리 도구의 힘이라는 것을 알 수 있기를 바랍니다.
|
||||||
|
|
||||||
|
이 파일은 [여기](/2022/Days/Configmgmt/Vagrantfile)에서 찾을 수 있습니다.
|
||||||
|
|
||||||
|
```Vagrant
|
||||||
|
Vagrant.configure("2") do |config|
|
||||||
|
servers=[
|
||||||
|
{
|
||||||
|
:hostname => "db01",
|
||||||
|
:box => "bento/ubuntu-21.10",
|
||||||
|
:ip => "192.168.169.130",
|
||||||
|
:ssh_port => '2210'
|
||||||
|
},
|
||||||
|
{
|
||||||
|
:hostname => "web01",
|
||||||
|
:box => "bento/ubuntu-21.10",
|
||||||
|
:ip => "192.168.169.131",
|
||||||
|
:ssh_port => '2211'
|
||||||
|
},
|
||||||
|
{
|
||||||
|
:hostname => "web02",
|
||||||
|
:box => "bento/ubuntu-21.10",
|
||||||
|
:ip => "192.168.169.132",
|
||||||
|
:ssh_port => '2212'
|
||||||
|
},
|
||||||
|
{
|
||||||
|
:hostname => "loadbalancer",
|
||||||
|
:box => "bento/ubuntu-21.10",
|
||||||
|
:ip => "192.168.169.134",
|
||||||
|
:ssh_port => '2213'
|
||||||
|
}
|
||||||
|
|
||||||
|
]
|
||||||
|
|
||||||
|
config.vm.base_address = 600
|
||||||
|
|
||||||
|
servers.each do |machine|
|
||||||
|
|
||||||
|
config.vm.define machine[:hostname] do |node|
|
||||||
|
node.vm.box = machine[:box]
|
||||||
|
node.vm.hostname = machine[:hostname]
|
||||||
|
|
||||||
|
node.vm.network :public_network, bridge: "Intel(R) Ethernet Connection (7) I219-V", ip: machine[:ip]
|
||||||
|
node.vm.network "forwarded_port", guest: 22, host: machine[:ssh_port], id: "ssh"
|
||||||
|
|
||||||
|
node.vm.provider :virtualbox do |v|
|
||||||
|
v.customize ["modifyvm", :id, "--memory", 2048]
|
||||||
|
v.customize ["modifyvm", :id, "--name", machine[:hostname]]
|
||||||
|
end
|
||||||
|
end
|
||||||
|
end
|
||||||
|
|
||||||
|
end
|
||||||
|
```
|
||||||
|
|
||||||
|
`vagrant up` 명령을 사용하여 VirtualBox에서 이러한 머신을 스핀업하면 메모리를 더 추가할 수 있고 각 머신에 대해 다른 private_network 주소를 정의할 수도 있지만 제 환경에서는 이 방법이 작동합니다. 컨트롤 박스는 리눅스 섹션에서 배포한 우분투 데스크톱이라는 점을 기억하세요.
|
||||||
|
|
||||||
|
리소스가 제한되어 있는 경우 `vagrant up web01 web02`를 실행하여 여기서 사용 중인 웹서버만 불러올 수도 있습니다.
|
||||||
|
|
||||||
|
### Ansible 호스트 구성
|
||||||
|
|
||||||
|
이제 환경이 준비되었으므로 Ansible을 확인할 수 있으며, 이를 위해 우분투 데스크톱(이 데스크톱을 사용할 수도 있지만 아래 네트워크에 액세스하는 네트워크에 있는 모든 Linux 기반 머신을 동일하게 사용할 수 있음)을 컨트롤로 사용하고, ansible 호스트 파일에서 새 Node를 그룹에 추가해 보겠습니다, 이 파일을 인벤토리로 생각할 수 있으며, 이에 대한 대안으로 `-i filename`을 사용하여 ansible 명령의 일부로 호출되는 또 다른 인벤토리 파일을 사용할 수 있습니다. 이는 프로덕션, 테스트 및 스테이징 환경마다 다른 파일을 가질 수 있으므로 호스트 파일을 사용하는 것보다 유용할 수 있습니다. 기본 호스트 파일을 사용하고 있으므로 이 파일을 기본으로 사용하므로 지정할 필요가 없습니다.
|
||||||
|
|
||||||
|
기본 호스트 파일에 다음을 추가했습니다.
|
||||||
|
|
||||||
|
```Text
|
||||||
|
[control]
|
||||||
|
ansible-control
|
||||||
|
|
||||||
|
[proxy]
|
||||||
|
loadbalancer
|
||||||
|
|
||||||
|
[webservers]
|
||||||
|
web01
|
||||||
|
web02
|
||||||
|
|
||||||
|
[database]
|
||||||
|
db01
|
||||||
|
|
||||||
|
```
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
계속 진행하기 전에 Node에 대해 명령을 실행할 수 있는지 확인하기 위해 `ansible nodes -m command -a hostname`을 실행해 보겠습니다. 이 간단한 명령은 연결이 있는지 테스트하고 호스트 이름을 다시 보고합니다.
|
||||||
|
|
||||||
|
또한, 연결을 보장하기 위해 /etc/hosts 파일 내의 Ubuntu 제어 Node에 이러한 Node와 IP를 추가했습니다. 우분투 상자에서 각 Node에 대해 SSH 구성을 수행해야 할 수도 있습니다.
|
||||||
|
|
||||||
|
```Text
|
||||||
|
192.168.169.140 ansible-control
|
||||||
|
192.168.169.130 db01
|
||||||
|
192.168.169.131 web01
|
||||||
|
192.168.169.132 web02
|
||||||
|
192.168.169.133 loadbalancer
|
||||||
|
```
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이 단계에서는 제어 Node와 서버 Node 사이에 SSH 키를 설정하는 과정을 진행하겠습니다. 다음 단계에서는 호스트의 파일에 변수를 추가하여 사용자 이름과 비밀번호를 제공하는 방법을 사용할 수 있습니다. 이 방법은 결코 모범 사례가 될 수 없으므로 권장하지 않습니다.
|
||||||
|
|
||||||
|
SSH를 설정하고 Node 간에 공유하려면 아래 단계를 따르세요. 비밀번호(`vagrant`)를 묻는 메시지가 표시되면 `y`를 몇 번 눌러야 수락할 수 있습니다.
|
||||||
|
|
||||||
|
`ssh-keygen`
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
`ssh-copy-id localhost`
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이제 모든 VM이 켜져 있다면 `ssh-copy-id web01 && ssh-copy-id web02 && ssh-copy-id loadbalancer && ssh-copy-id db01`을 실행하면 비밀번호를 입력하라는 메시지가 표시됩니다(이 경우 비밀번호는 `vagrant`입니다).
|
||||||
|
|
||||||
|
모든 VM을 실행하지 않고 웹서버만 실행하고 있으므로 `ssh-copy-id web01 && ssh-copy-id web02`를 발급했습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Playbook을 실행하기 전에 그룹과 간단하게 연결되었는지 확인하고 싶어서 `ansible webservers -m ping`을 실행하여 연결을 테스트했습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
### 첫 번째 "진짜" Ansible Playbook
|
||||||
|
|
||||||
|
첫 번째 Ansible Playbook은 웹 서버를 구성하는 것으로, 호스트 파일에서 [webservers] 그룹 아래에 웹 서버를 그룹화했습니다.
|
||||||
|
|
||||||
|
Playbook을 실행하기 전에 web01과 web02에 apache가 설치되어 있지 않은 것을 확인할 수 있습니다. 아래 스크린샷 상단은 이 Playbook을 실행하기 위해 ansible 컨트롤 내에서 생성한 폴더 및 파일 레이아웃을 보여줍니다. `playbook1.yml`이 있고, template 폴더에는 `index.html.j2`와 `ports.conf.j2` 파일이 있습니다. 이 파일은 위에 나열된 리포지토리 폴더에서 찾을 수 있습니다.
|
||||||
|
|
||||||
|
그런 다음 web01에 SSH로 접속하여 apache가 설치되어 있는지 확인합니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
위에서 web01에 apache가 설치되어 있지 않다는 것을 알 수 있으므로 아래 Playbook을 실행하여 이 문제를 해결할 수 있습니다.
|
||||||
|
|
||||||
|
```Yaml
|
||||||
|
- hosts: webservers
|
||||||
|
become: yes
|
||||||
|
vars:
|
||||||
|
http_port: 8000
|
||||||
|
https_port: 4443
|
||||||
|
html_welcome_msg: "Hello 90DaysOfDevOps"
|
||||||
|
tasks:
|
||||||
|
- name: ensure apache is at the latest version
|
||||||
|
apt:
|
||||||
|
name: apache2
|
||||||
|
state: latest
|
||||||
|
|
||||||
|
- name: write the apache2 ports.conf config file
|
||||||
|
template:
|
||||||
|
src: templates/ports.conf.j2
|
||||||
|
dest: /etc/apache2/ports.conf
|
||||||
|
notify:
|
||||||
|
- restart apache
|
||||||
|
|
||||||
|
- name: write a basic index.html file
|
||||||
|
template:
|
||||||
|
src: templates/index.html.j2
|
||||||
|
dest: /var/www/html/index.html
|
||||||
|
notify:
|
||||||
|
- restart apache
|
||||||
|
|
||||||
|
- name: ensure apache is running
|
||||||
|
service:
|
||||||
|
name: apache2
|
||||||
|
state: started
|
||||||
|
|
||||||
|
handlers:
|
||||||
|
- name: restart apache
|
||||||
|
service:
|
||||||
|
name: apache2
|
||||||
|
state: restarted
|
||||||
|
```
|
||||||
|
|
||||||
|
위의 Playbook을 분석합니다:
|
||||||
|
|
||||||
|
- `host: webserver`는 이 Playbook을 실행할 그룹이 웹서버라는 그룹이라는 것을 의미합니다.
|
||||||
|
- `become: yes`는 Playbook을 실행하는 사용자가 원격 시스템에서 루트가 된다는 의미입니다. 루트 비밀번호를 입력하라는 메시지가 표시됩니다.
|
||||||
|
- 그런 다음 `vars`가 있는데, 이는 웹서버 전체에서 원하는 몇 가지 환경 변수를 정의합니다.
|
||||||
|
|
||||||
|
그런 다음 Task를 시작합니다,
|
||||||
|
|
||||||
|
- Task 1은 apache가 최신 버전을 실행 중인지 확인하는 것입니다.
|
||||||
|
- Task 2는 template 폴더에 있는 소스에서 ports.conf 파일을 작성하는 것입니다.
|
||||||
|
- Task 3은 기본 index.html 파일을 생성하는 것입니다.
|
||||||
|
- Task 4는 apache가 실행 중인지 확인하는 것입니다.
|
||||||
|
|
||||||
|
마지막으로 Handler 섹션인 [Handler: 변경에 대한 Task 실행](https://docs.ansible.com/ansible/latest/user_guide/playbooks_handlers.html)이 있습니다.
|
||||||
|
|
||||||
|
"때로는 컴퓨터에서 변경이 이루어질 때만 Task가 실행되기를 원할 때가 있습니다. 예를 들어, 태스크가 해당 서비스의 구성을 업데이트하지만, 구성이 변경되지 않은 경우 서비스를 다시 시작하고 싶을 수 있습니다. Ansible은 이 사용 사례를 해결하기 위해 Handler를 사용합니다. Handler는 알림을 받을 때만 실행되는 태스크입니다. 각 Handler는 전 세계적으로 고유한 이름을 가져야 합니다."
|
||||||
|
|
||||||
|
이 단계에서는 5개의 VM을 배포했다고 생각할 수 있습니다(Ansible 컨트롤 역할을 하는 Ubuntu 데스크톱 머신 포함). 다른 시스템은 이 섹션의 나머지 부분에서 다루게 될 것입니다.
|
||||||
|
|
||||||
|
### Playbook 실행
|
||||||
|
|
||||||
|
이제 Node에 대해 Playbook을 실행할 준비가 되었습니다. Playbook을 실행하려면 `ansible-playbook playbook1.yml`을 사용하면 됩니다. Playbook 내에서 Playbook이 실행될 호스트를 정의했으며, 정의한 Task를 안내합니다.
|
||||||
|
|
||||||
|
명령이 완료되면 Play와 Task를 보여주는 출력이 표시되며, 아래 이미지에서 원하는 상태를 설치하는 데 시간이 걸리는 것을 확인할 수 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
그런 다음 Node로 이동하여 Node에 소프트웨어가 설치되었는지 확인하여 이를 다시 확인할 수 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
위와 같이 두 개의 독립형 웹서버를 배포했으므로 이제 정의한 각각의 IP로 이동하여 새 웹 사이트를 가져올 수 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이 섹션의 나머지 부분을 진행하면서 이 Playbook을 기반으로 구축할 것입니다. 또한 Ubuntu 데스크톱을 가져와서 Ansible을 사용하여 애플리케이션과 구성을 부트스트랩할 수 있는지 살펴보고 싶어서 이 부분도 다뤄볼 수 있을 것 같습니다. 예를 들어 명령에서 로컬 호스트를 사용하여 로컬 호스트에 대해 Playbook을 실행할 수 있다는 것을 보셨습니다.
|
||||||
|
|
||||||
|
여기에 추가해야 할 또 다른 사항은 우리는 실제로 Ubuntu VM으로만 작업하고 있지만 Ansible은 대상 시스템에 구애받지 않는다는 것입니다. 시스템을 관리하기 위해 이전에 언급했던 대안은 서버별로 서버를 관리할 수 있습니다(서버 수가 많을 경우 확장성이 떨어지고 Node가 3개일 때도 문제가 있음) Linux 섹션에서 다시 다룬 셸 스크립팅을 사용할 수도 있지만 이러한 Node는 잠재적으로 다를 수 있으므로 가능하지만 누군가 스크립트를 유지 및 관리해야 합니다. Ansible은 무료이며 전문화된 스크립트가 필요 없는 대신 간편한 버튼을 누릅니다.
|
||||||
|
|
||||||
|
## 자료
|
||||||
|
|
||||||
|
- [What is Ansible](https://www.youtube.com/watch?v=1id6ERvfozo)
|
||||||
|
- [Ansible 101 - Episode 1 - Introduction to Ansible](https://www.youtube.com/watch?v=goclfp6a2IQ)
|
||||||
|
- [NetworkChuck - You need to learn Ansible right now!](https://www.youtube.com/watch?v=5hycyr-8EKs&t=955s)
|
||||||
|
- [Your complete guide to Ansible](https://www.youtube.com/playlist?list=PLnFWJCugpwfzTlIJ-JtuATD2MBBD7_m3u)
|
||||||
|
|
||||||
|
위에 나열된 마지막 재생 목록은 이 섹션의 많은 코드와 아이디어가 나온 곳이며, 동영상 형식의 훌륭한 리소스이자 워크스루입니다.
|
||||||
|
|
||||||
|
[Day 66](day66.md)에서 봐요!
|
||||||
130
2022/ko/Days/day66.md
Normal file
130
2022/ko/Days/day66.md
Normal file
@ -0,0 +1,130 @@
|
|||||||
|
---
|
||||||
|
title: '#90DaysOfDevOps - Ansible Playbooks Continued... - Day 66'
|
||||||
|
published: false
|
||||||
|
description: 90DaysOfDevOps - Ansible Playbooks Continued...
|
||||||
|
tags: 'devops, 90daysofdevops, learning'
|
||||||
|
cover_image: null
|
||||||
|
canonical_url: null
|
||||||
|
id: 1048712
|
||||||
|
---
|
||||||
|
|
||||||
|
## Ansible Playbook (계속)
|
||||||
|
|
||||||
|
지난 섹션에서는 vagrant 파일을 사용하여 4대의 머신을 배포하는 작은 실험실을 만드는 것으로 시작했고, 이 섹션에서 만든 Linux 머신을 Ansible 제어 시스템으로 사용했습니다.
|
||||||
|
|
||||||
|
또한 Playbook의 몇 가지 시나리오를 실행했고 마지막에는 web01과 web02를 개별 웹 서버로 만드는 Playbook을 만들었습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
### 깔끔하게 정리하기
|
||||||
|
|
||||||
|
추가 자동화 및 배포를 시작하기 전에 Playbook을 간결하고 깔끔하게 유지하는 기능과 작업과 Handler를 하위 폴더로 분리하는 방법에 대해 다뤄야 합니다.
|
||||||
|
|
||||||
|
작업을 폴더 내의 해당 파일에 복사하겠습니다.
|
||||||
|
|
||||||
|
```Yaml
|
||||||
|
- name: ensure apache is at the latest version
|
||||||
|
apt: name=apache2 state=latest
|
||||||
|
|
||||||
|
- name: write the apache2 ports.conf config file
|
||||||
|
template:
|
||||||
|
src=templates/ports.conf.j2
|
||||||
|
dest=/etc/apache2/ports.conf
|
||||||
|
notify: restart apache
|
||||||
|
|
||||||
|
- name: write a basic index.html file
|
||||||
|
template:
|
||||||
|
src: templates/index.html.j2
|
||||||
|
dest: /var/www/html/index.html
|
||||||
|
notify:
|
||||||
|
- restart apache
|
||||||
|
|
||||||
|
- name: ensure apache is running
|
||||||
|
service:
|
||||||
|
name: apache2
|
||||||
|
state: started
|
||||||
|
```
|
||||||
|
|
||||||
|
Handler도 마찬가지입니다.
|
||||||
|
|
||||||
|
```Yaml
|
||||||
|
- name: restart apache
|
||||||
|
service:
|
||||||
|
name: apache2
|
||||||
|
state: restarted
|
||||||
|
```
|
||||||
|
|
||||||
|
Playbook의 이름을 `playbook2.yml`로 지정한 다음, 이 파일을 가리킵니다. 이 모든 파일은 [ansible-scenario2](/2022/Days/Configmgmt/ansible-scenario2/)에서 찾을 수 있습니다.
|
||||||
|
|
||||||
|
제어 머신에서 테스트할 수 있습니다. 리포지토리에서 파일을 복사한 경우 "write a basic index.html file"에서 변경된 사항을 발견했을 것입니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
`curl web01:8000`을 사용하여 어떤 간단한 변경이 있었는지 알아봅시다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
방금 Playbook을 정리하고 규모에 따라 Playbook을 매우 압도적으로 만들 수 있는 영역을 분리하기 시작했습니다.
|
||||||
|
|
||||||
|
### Role과 Ansible Galaxy
|
||||||
|
|
||||||
|
현재 4개의 VM을 배포했으며 이 중 2개의 VM을 웹 서버로 구성했지만 데이터베이스 서버와 로드 밸런서 또는 프록시 등 좀 더 구체적인 기능이 있습니다. 이 작업을 수행하고 리포지토리를 정리하기 위해 Ansible 내에서 Role을 사용할 수 있습니다.
|
||||||
|
|
||||||
|
이를 위해 공유 리포지토리에서 Ansible Role을 관리하기 위해 존재하는 `ansible-galaxy` 명령을 사용합니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
우리는 `ansible-galaxy`를 사용하여 웹서버에 대한 세부 정보를 넣을 apache2의 Role을 생성할 것입니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
위의 명령 `ansible-galaxy init roles/apache2`는 위에 표시된 폴더 구조를 생성합니다. 다음 단계는 기존 작업과 template을 새 구조의 관련 폴더로 이동하는 것입니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
복사하여 붙여넣으면 파일을 쉽게 옮길 수 있지만, tasks/main.yml을 변경하여 이 파일이 apache2_install.yml을 가리키도록 해야 합니다.
|
||||||
|
|
||||||
|
또한 새로운 Role을 참조하도록 Playbook을 변경해야 합니다. playbook1.yml과 playbook2.yml에서 작업과 Handler를 두 버전 간에 변경하면서 다른 방식으로 결정합니다. 아래와 같이 이 Role을 사용하도록 Playbook을 변경해야 합니다:
|
||||||
|
|
||||||
|
```Yaml
|
||||||
|
- hosts: webservers
|
||||||
|
become: yes
|
||||||
|
vars:
|
||||||
|
http_port: 8000
|
||||||
|
https_port: 4443
|
||||||
|
html_welcome_msg: "Hello 90DaysOfDevOps - Welcome to Day 66!"
|
||||||
|
roles:
|
||||||
|
- apache2
|
||||||
|
```
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이제 새 Playbook 이름인 `ansible-playbook playbook3.yml`로 Playbook을 다시 실행하면 deprecated가 발생한 것을 확인할 수 있으며, 다음에 수정할 수 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Playbook이 실행되었지만, deprecated가 발생했으므로 이제 방법을 수정해야 합니다. 이를 위해 tasks/main.yml의 include 옵션을 아래와 같이 import_tasks로 변경했습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이 파일은 [ansible-scenario3](/2022/Days/Configmgmt/ansible-scenario3)에서 찾을 수 있습니다.
|
||||||
|
|
||||||
|
또한 우리가 만들 `ansible-galaxy`를 사용하면서 몇 가지 Role을 더 만들 것입니다:
|
||||||
|
|
||||||
|
- common = 모든 서버용(`ansible-galaxy init roles/common`)
|
||||||
|
- nginx = 로드밸런서용(`ansible-galaxy init roles/nginx`)
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
여기서는 여기까지만 하고 다음 세션에서는 배포했지만, 아직 아무것도 하지 않은 다른 Node에 대한 작업을 시작하겠습니다.
|
||||||
|
|
||||||
|
## 자료
|
||||||
|
|
||||||
|
- [What is Ansible](https://www.youtube.com/watch?v=1id6ERvfozo)
|
||||||
|
- [Ansible 101 - Episode 1 - Introduction to Ansible](https://www.youtube.com/watch?v=goclfp6a2IQ)
|
||||||
|
- [NetworkChuck - You need to learn Ansible right now!](https://www.youtube.com/watch?v=5hycyr-8EKs&t=955s)
|
||||||
|
- [Your complete guide to Ansible](https://www.youtube.com/playlist?list=PLnFWJCugpwfzTlIJ-JtuATD2MBBD7_m3u)
|
||||||
|
|
||||||
|
위에 나열된 마지막 재생 목록은 이 섹션의 많은 코드와 아이디어가 나온 곳이며, 동영상 형식의 훌륭한 리소스이자 워크스루입니다.
|
||||||
|
|
||||||
|
[Day 67](day67.md)에서 봐요!
|
||||||
122
2022/ko/Days/day67.md
Normal file
122
2022/ko/Days/day67.md
Normal file
@ -0,0 +1,122 @@
|
|||||||
|
---
|
||||||
|
title: '#90DaysOfDevOps - Using Roles & Deploying a Loadbalancer - Day 67'
|
||||||
|
published: false
|
||||||
|
description: '90DaysOfDevOps - Using Roles & Deploying a Loadbalancer'
|
||||||
|
tags: 'devops, 90daysofdevops, learning'
|
||||||
|
cover_image: null
|
||||||
|
canonical_url: null
|
||||||
|
id: 1048713
|
||||||
|
---
|
||||||
|
|
||||||
|
## Role 사용 및 로드밸런서 배포하기
|
||||||
|
|
||||||
|
지난 세션에서는 Role에 대해 다루고 `ansible-galaxy` 명령을 사용하여 앞으로 사용할 몇 가지 Role에 대한 폴더 구조를 만들었습니다. 모든 것이 Role 폴더에 숨겨져 있기 때문에 구성 코드의 작업 저장소가 훨씬 더 깔끔해졌습니다.
|
||||||
|
|
||||||
|
하지만 지금까지는 apache2 Role만 사용했고 웹서버를 처리하기 위해 작동하는 playbook3.yaml이 있습니다.
|
||||||
|
|
||||||
|
이 시점에서 `vagrant up web01 web02`만 사용했다면 이제 `vagrant up loadbalancer`를 실행하면 로드 밸런서/프록시로 사용할 다른 Ubuntu 시스템이 나타납니다.
|
||||||
|
|
||||||
|
호스트 파일에 이 새 시스템을 이미 정의했지만, 사용할 수 있을 때까지 ssh 키가 구성되지 않았으므로 시스템이 가동되고 준비되면 `ssh-copy-id loadbalancer`도 실행해야 합니다.
|
||||||
|
|
||||||
|
### Common Role
|
||||||
|
|
||||||
|
어제 세션 마지막에 `common` Role을 만들었는데, Common은 모든 서버에서 사용되는 반면 다른 Role은 사용 사례에 따라 다르지만 이제 설치하려는 애플리케이션은 가짜처럼 일반적이며 이것이 왜 그런지 많은 이유를 알 수는 없지만 그 목적을 보여줍니다. Common Role 폴더 구조에서 작업 폴더로 이동하면 main.yml이 있습니다. 이 YAML에서 이 파일을 install_tools.yml 파일로 가리켜야 하며, `- import_tasks: install_tools.yml` 줄을 추가하여 이를 수행합니다. 이전에는 `include`였으나 곧 사용되지 않을 예정이므로 import_tasks를 사용합니다.
|
||||||
|
|
||||||
|
```Yaml
|
||||||
|
- name: "Install Common packages"
|
||||||
|
apt: name={{ item }} state=latest
|
||||||
|
with_items:
|
||||||
|
- neofetch
|
||||||
|
- tree
|
||||||
|
- figlet
|
||||||
|
```
|
||||||
|
|
||||||
|
그런 다음 playbook에서 각 호스트 블록에 대한 Common Role을 추가합니다.
|
||||||
|
|
||||||
|
```Yaml
|
||||||
|
- hosts: webservers
|
||||||
|
become: yes
|
||||||
|
vars:
|
||||||
|
http_port: 8000
|
||||||
|
https_port: 4443
|
||||||
|
html_welcome_msg: "Hello 90DaysOfDevOps - Welcome to Day 66!"
|
||||||
|
roles:
|
||||||
|
- common
|
||||||
|
- apache2
|
||||||
|
```
|
||||||
|
|
||||||
|
### Nginx
|
||||||
|
|
||||||
|
다음 단계는 로드밸런서 VM에 nginx를 설치하고 구성하는 것입니다. 일반적인 폴더 구조와 마찬가지로, 마지막 세션을 기반으로 nginx를 구성합니다.
|
||||||
|
|
||||||
|
먼저 playbook에 호스트 블록을 추가하겠습니다. 이 블록에는 Common Role과 새로운 nginx Role이 포함됩니다.
|
||||||
|
|
||||||
|
playbook은 여기에서 찾을 수 있습니다. [playbook4.yml](/2022/Days/Configmgmt/ansible-scenario4/playbook4.yml)
|
||||||
|
|
||||||
|
```Yaml
|
||||||
|
- hosts: webservers
|
||||||
|
become: yes
|
||||||
|
vars:
|
||||||
|
http_port: 8000
|
||||||
|
https_port: 4443
|
||||||
|
html_welcome_msg: "Hello 90DaysOfDevOps - Welcome to Day 66!"
|
||||||
|
roles:
|
||||||
|
- common
|
||||||
|
- apache2
|
||||||
|
|
||||||
|
- hosts: proxy
|
||||||
|
become: yes
|
||||||
|
roles:
|
||||||
|
- common
|
||||||
|
- nginx
|
||||||
|
```
|
||||||
|
|
||||||
|
이것이 의미가 있으려면 실행할 작업을 정의해야 하며, 같은 방식으로 이번에는 설치용 파일과 구성용 파일 두 개를 가리키도록 작업의 main.yml을 수정하겠습니다.
|
||||||
|
|
||||||
|
원하는 결과에 따라 수정한 다른 파일이 몇 개 더 있는데, [ansible-scenario4](/2022/Days/Configmgmt/ansible-scenario4) 폴더에서 변경된 모든 파일을 살펴보세요. nginx 폴더의 작업, Handler 및 template 폴더를 확인하면 추가 변경 사항과 파일을 찾을 수 있습니다.
|
||||||
|
|
||||||
|
### 업데이트된 playbook 실행
|
||||||
|
|
||||||
|
어제부터 시스템에 일부 패키지를 설치하는 Common Role을 추가한 데 이어 설치 및 구성을 포함하는 nginx Role도 추가했습니다.
|
||||||
|
|
||||||
|
`anible-playbook playbook4.yml`을 사용하여 playbook4.yml을 실행해 보겠습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이제 웹 서버와 로드밸런서가 구성되었으므로 이제 로드밸런서의 IP 주소인 http://192.168.169.134/ 로 이동할 수 있어야 합니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이 과정을 따르고 있는데도 이 상태가 나타나지 않는다면 사용 중인 환경의 서버 IP 주소 때문일 수 있습니다. 이 파일은 `templates\mysite.j2`에서 찾을 수 있으며 아래와 유사하게 보입니다: 웹 서버 IP 주소로 업데이트해야 합니다.
|
||||||
|
|
||||||
|
```J2
|
||||||
|
upstream webservers {
|
||||||
|
server 192.168.169.131:8000;
|
||||||
|
server 192.168.169.132:8000;
|
||||||
|
}
|
||||||
|
|
||||||
|
server {
|
||||||
|
listen 80;
|
||||||
|
|
||||||
|
location / {
|
||||||
|
proxy_pass http://webservers;
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
우리가 설치한 것이 모두 정상이라고 확신하지만, ansible을 사용하여 임시 명령을 사용하여 이러한 일반적인 도구 설치를 확인해 보겠습니다.
|
||||||
|
|
||||||
|
`ansible loadbalancer -m command -a neofetch`
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## 자료
|
||||||
|
|
||||||
|
- [What is Ansible](https://www.youtube.com/watch?v=1id6ERvfozo)
|
||||||
|
- [Ansible 101 - Episode 1 - Introduction to Ansible](https://www.youtube.com/watch?v=goclfp6a2IQ)
|
||||||
|
- [NetworkChuck - You need to learn Ansible right now!](https://www.youtube.com/watch?v=5hycyr-8EKs&t=955s)
|
||||||
|
- [Your complete guide to Ansible](https://www.youtube.com/playlist?list=PLnFWJCugpwfzTlIJ-JtuATD2MBBD7_m3u)
|
||||||
|
|
||||||
|
위에 나열된 마지막 재생 목록은 이 섹션의 많은 코드와 아이디어가 나온 곳이며, 동영상 형식의 훌륭한 리소스이자 워크스루입니다.
|
||||||
|
|
||||||
|
[Day 68](day68.md)에서 봐요!
|
||||||
353
2022/ko/Days/day68.md
Normal file
353
2022/ko/Days/day68.md
Normal file
@ -0,0 +1,353 @@
|
|||||||
|
---
|
||||||
|
title: '#90DaysOfDevOps - Tags, Variables, Inventory & Database Server config - Day 68'
|
||||||
|
published: false
|
||||||
|
description: '90DaysOfDevOps - Tags, Variables, Inventory & Database Server config'
|
||||||
|
tags: 'devops, 90daysofdevops, learning'
|
||||||
|
cover_image: null
|
||||||
|
canonical_url: null
|
||||||
|
id: 1048780
|
||||||
|
---
|
||||||
|
|
||||||
|
## Tag, Variable, Inventory 및 Database 서버 구성
|
||||||
|
|
||||||
|
### Tag
|
||||||
|
|
||||||
|
어제 세션에 playbook을 남겨두었으므로 모든 작업을 실행하고 해당 playbook 내에서 play해야 합니다. 즉, 웹서버와 로드밸런서 play 및 작업을 모두 실행해야 완료할 수 있습니다.
|
||||||
|
|
||||||
|
하지만 Tag를 사용하면 원하는 경우 이러한 작업을 분리할 수 있습니다. 이는 환경에 매우 크고 긴 playbook이 있는 경우 효율적인 방법이 될 수 있습니다.
|
||||||
|
|
||||||
|
이 경우 playbook 파일에서는 [ansible-scenario5](/2022/Days/Configmgmt/ansible-scenario5/playbook5.yml)를 사용하고 있습니다.
|
||||||
|
|
||||||
|
```Yaml
|
||||||
|
- hosts: webservers
|
||||||
|
become: yes
|
||||||
|
vars:
|
||||||
|
http_port: 8000
|
||||||
|
https_port: 4443
|
||||||
|
html_welcome_msg: "Hello 90DaysOfDevOps - Welcome to Day 66!"
|
||||||
|
roles:
|
||||||
|
- common
|
||||||
|
- apache2
|
||||||
|
tags: web
|
||||||
|
|
||||||
|
- hosts: proxy
|
||||||
|
become: yes
|
||||||
|
roles:
|
||||||
|
- common
|
||||||
|
- nginx
|
||||||
|
tags: proxy
|
||||||
|
```
|
||||||
|
|
||||||
|
그런 다음 `ansible-playbook playbook5.yml --list-tags`를 사용하여 이를 확인할 수 있으며, list Tag는 우리가 playbook에서 정의한 Tag의 윤곽을 나타냅니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이제 프록시만 타깃팅하려면 `ansible-playbook playbook5.yml --tags proxy`를 실행하면 아래에서 볼 수 있듯이 프록시에 대해서만 playbook을 실행할 수 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Tag는 작업 수준에서도 추가할 수 있으므로 원하는 위치와 작업을 세분화할 수 있습니다. 예를 들어 애플리케이션 중심 Tag가 될 수도 있고, 작업을 살펴보고 설치, 구성 또는 제거에 따라 작업에 Tag를 지정할 수도 있습니다. 사용할 수 있는 또 다른 매우 유용한 Tag는 다음과 같습니다.
|
||||||
|
|
||||||
|
`tag: always` 이것은 명령에 어떤 --tags를 사용하든 상관없이 항상 값으로 Tag가 지정된 항목이 있으면 ansible-playbook 명령을 실행할 때 항상 실행되도록 보장합니다.
|
||||||
|
|
||||||
|
Tag를 사용하여 여러 Tag를 함께 묶을 수도 있으며, `ansible-playbook playbook5.yml --tags proxy,web`을 실행하도록 선택하면 해당 Tag가 있는 모든 항목이 실행됩니다. 물론 이 예제에서는 playbook을 실행하는 것과 같은 의미이지만, 다른 play가 여러 개 있는 경우에는 이 방법이 의미가 있을 것입니다.
|
||||||
|
|
||||||
|
둘 이상의 Tag를 정의할 수도 있습니다.
|
||||||
|
|
||||||
|
### Variable
|
||||||
|
|
||||||
|
Ansible에는 크게 두 가지 유형의 Variable이 있습니다.
|
||||||
|
|
||||||
|
- User created
|
||||||
|
- Ansible Facts
|
||||||
|
|
||||||
|
### Ansible Facts
|
||||||
|
|
||||||
|
playbook을 실행할 때마다 "Gathering facts"라는 정의되지 않은 작업이 있었는데, 이러한 Variable 또는 fact를 사용하여 자동화 작업을 수행할 수 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
다음 `ansible proxy -m setup` 명령을 실행하면 JSON 형식의 많은 출력을 볼 수 있습니다. 이를 사용하려면 터미널에 많은 정보가 있어야 하므로 `ansible proxy -m setup >> facts.json`을 사용하여 파일로 출력하고 싶습니다. [여기](/2022/Days/Configmgmt/ansible-scenario5/facts.json)에서 이 파일을 볼 수 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이 파일을 열면 명령에 대한 모든 종류의 정보를 볼 수 있습니다. IP 주소, 아키텍처, 바이오스 버전을 확인할 수 있습니다. 이 정보를 활용하여 playbook에 사용하려는 경우 유용한 정보가 많이 있습니다.
|
||||||
|
|
||||||
|
한 가지 아이디어는 웹서버의 IP 주소를 하드코딩한 nginx template mysite.j2 내에서 이러한 Variable 중 하나를 잠재적으로 사용하는 것입니다. mysite.j2에 for 루프를 생성하면 [webservers] 그룹을 순환하여 2개 이상의 웹서버를 자동으로 동적으로 생성하거나 이 로드 밸런서 구성에 추가할 수 있습니다.
|
||||||
|
|
||||||
|
```
|
||||||
|
#Dynamic Config for server {{ ansible_facts['nodename'] }}
|
||||||
|
upstream webservers {
|
||||||
|
{% for host in groups['webservers'] %}
|
||||||
|
server {{ hostvars[host]['ansible_facts']['nodename'] }}:8000;
|
||||||
|
{% endfor %}
|
||||||
|
}
|
||||||
|
|
||||||
|
server {
|
||||||
|
listen 80;
|
||||||
|
|
||||||
|
location / {
|
||||||
|
proxy_pass http://webservers;
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
위의 결과는 지금과 동일하게 보이지만 웹 서버를 더 추가하거나 제거하면 프록시 구성이 동적으로 변경됩니다. 이 기능을 사용하려면 이름 확인을 구성해야 합니다.
|
||||||
|
|
||||||
|
### User created
|
||||||
|
|
||||||
|
User created Variable은 우리가 직접 만든 Variable입니다. playbook을 살펴보면 `vars:`가 있고 거기에 3개의 Variable 목록이 있는 것을 볼 수 있습니다.
|
||||||
|
|
||||||
|
```Yaml
|
||||||
|
- hosts: webservers
|
||||||
|
become: yes
|
||||||
|
vars:
|
||||||
|
http_port: 8000
|
||||||
|
https_port: 4443
|
||||||
|
html_welcome_msg: "Hello 90DaysOfDevOps - Welcome to Day 68!"
|
||||||
|
roles:
|
||||||
|
- common
|
||||||
|
- apache2
|
||||||
|
tags: web
|
||||||
|
|
||||||
|
- hosts: proxy
|
||||||
|
become: yes
|
||||||
|
roles:
|
||||||
|
- common
|
||||||
|
- nginx
|
||||||
|
tags: proxy
|
||||||
|
```
|
||||||
|
|
||||||
|
그러나 Variable을 해당 파일로 이동하여 playbook에 Variable이 없도록 할 수 있습니다. 이 작업을 수행하되, [ansible-scenario6](/2022/Days/Configmgmt/ansible-scenario6) 폴더로 이동하겠습니다. 해당 폴더의 루트에 group_vars 폴더를 만들겠습니다. 그런 다음 all이라는 또 다른 폴더를 만듭니다(모든 그룹이 이 Variable을 가져옵니다). 이 폴더에 `common_variables.yml`이라는 파일을 만들고 playbook의 Variable을 이 파일에 복사합니다. Variable과 함께 playbook에서 Variable을 제거합니다.
|
||||||
|
|
||||||
|
```Yaml
|
||||||
|
http_port: 8000
|
||||||
|
https_port: 4443
|
||||||
|
html_welcome_msg: "Hello 90DaysOfDevOps - Welcome to Day 68!"
|
||||||
|
```
|
||||||
|
|
||||||
|
이 Variable을 전역 Variable로 연결하기 때문에 여기에 NTP 및 DNS 서버도 추가할 수 있습니다. Variable은 우리가 만든 폴더 구조에서 설정됩니다. 이제 playbook이 얼마나 깔끔해졌는지 아래에서 확인할 수 있습니다.
|
||||||
|
|
||||||
|
```Yaml
|
||||||
|
- hosts: webservers
|
||||||
|
become: yes
|
||||||
|
roles:
|
||||||
|
- common
|
||||||
|
- apache2
|
||||||
|
tags: web
|
||||||
|
|
||||||
|
- hosts: proxy
|
||||||
|
become: yes
|
||||||
|
roles:
|
||||||
|
- common
|
||||||
|
- nginx
|
||||||
|
tags: proxy
|
||||||
|
```
|
||||||
|
|
||||||
|
그 Variable 중 하나는 http_port로, 아래와 같이 mysite.j2 내의 for 루프에서 이 Variable을 다시 사용할 수 있습니다:
|
||||||
|
|
||||||
|
```J2
|
||||||
|
#Dynamic Config for server {{ ansible_facts['nodename'] }}
|
||||||
|
upstream webservers {
|
||||||
|
{% for host in groups['webservers'] %}
|
||||||
|
server {{ hostvars[host]['ansible_facts']['nodename'] }}:{{ http_port }};
|
||||||
|
{% endfor %}
|
||||||
|
}
|
||||||
|
|
||||||
|
server {
|
||||||
|
listen 80;
|
||||||
|
|
||||||
|
location / {
|
||||||
|
proxy_pass http://webservers;
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
또한, 어떤 웹서버를 사용하고 있는지 파악할 수 있도록 roles/apache2/templates/index.HTML.j2 파일에 분석 가능한 사실을 정의할 수도 있습니다.
|
||||||
|
|
||||||
|
```J2
|
||||||
|
<html>
|
||||||
|
|
||||||
|
<h1>{{ html_welcome_msg }}! I'm webserver {{ ansible_facts['nodename'] }} </h1>
|
||||||
|
|
||||||
|
</html>
|
||||||
|
```
|
||||||
|
|
||||||
|
Variable을 변경하여 `ansible-playbook playbook6.yml` 명령을 실행한 결과, 로드밸런서에 도달하면 그룹에 있는 웹서버 중 하나에 도달한 것을 볼 수 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
또한 host_vars라는 폴더를 추가하고 web01.yml을 생성하여 원하는 경우 특정 메시지를 표시하거나 호스트별로 표시되는 내용을 변경할 수 있습니다.
|
||||||
|
|
||||||
|
### Inventory 파일
|
||||||
|
|
||||||
|
지금까지 호스트를 결정하기 위해 /etc/ansible 폴더에 있는 기본 호스트 파일을 사용했습니다. 그러나 프로덕션 및 스테이징과 같이 환경마다 다른 파일을 사용할 수 있습니다. 더 많은 환경을 만들지는 않겠습니다. 하지만 호스트 파일은 만들 수 있습니다.
|
||||||
|
|
||||||
|
서버와 노드의 다양한 Inventory에 대해 여러 개의 파일을 만들 수 있습니다. 우리는 `ansible-playbook -i dev playbook.yml`을 사용하여 이를 호출합니다. 호스트 파일 내에 Variable을 정의한 다음 이를 출력하거나 playbook의 다른 곳에서 해당 Variable을 활용할 수도 있습니다. 예를 들어 아래 예제 및 교육 과정에서는 호스트 파일에서 생성된 환경 Variable을 로드밸런서 웹 페이지 template에 추가하여 웹 페이지 메시지의 일부로 환경을 표시했습니다.
|
||||||
|
|
||||||
|
### Database 서버 배포
|
||||||
|
|
||||||
|
아직 전원을 켜고 구성하지 않은 머신이 하나 더 있습니다. vagrant 파일이 있는 곳에서 `vagrant up db01`을 사용하여 이 작업을 수행할 수 있습니다. 전원이 켜지고 액세스할 수 있게 되면 `ssh-copy-id db01`을 사용하여 SSH 키를 복사하여 액세스할 수 있도록 해야 합니다.
|
||||||
|
|
||||||
|
여기서는 [ansible-scenario7](/2022/Days/Configmgmt/ansible-scenario7) 폴더에서 작업할 것입니다.
|
||||||
|
|
||||||
|
그런 다음 `ansible-galaxy init roles/mysql`을 사용하여 "MySQL"이라는 새 Role에 대한 새 폴더 구조를 만들어 보겠습니다.
|
||||||
|
|
||||||
|
playbook에서 Database 구성을 위한 새로운 play 블록을 추가하겠습니다. /etc/ansible/hosts 파일에 그룹 Database가 정의되어 있습니다. 그런 다음 Database 그룹에 공통 Role과 이전 단계에서 생성한 MySQL이라는 새 Role을 갖도록 지시합니다. 또한 Database 그룹에 Database Tag를 지정하고 있는데, 이는 앞서 설명한 것처럼 원하는 경우 이러한 Tag에 대해서만 실행하도록 선택할 수 있음을 의미합니다.
|
||||||
|
|
||||||
|
```Yaml
|
||||||
|
- hosts: webservers
|
||||||
|
become: yes
|
||||||
|
roles:
|
||||||
|
- common
|
||||||
|
- apache2
|
||||||
|
tags:
|
||||||
|
web
|
||||||
|
|
||||||
|
- hosts: proxy
|
||||||
|
become: yes
|
||||||
|
roles:
|
||||||
|
- common
|
||||||
|
- nginx
|
||||||
|
tags:
|
||||||
|
proxy
|
||||||
|
|
||||||
|
- hosts: database
|
||||||
|
become: yes
|
||||||
|
roles:
|
||||||
|
- common
|
||||||
|
- mysql
|
||||||
|
tags: database
|
||||||
|
```
|
||||||
|
|
||||||
|
이제 Role 폴더 구조 내에서 트리가 자동으로 생성되었으므로 다음을 채워야 합니다:
|
||||||
|
|
||||||
|
Handlers - main.yml
|
||||||
|
|
||||||
|
```Yaml
|
||||||
|
# handlers file for roles/mysql
|
||||||
|
- name: restart mysql
|
||||||
|
service:
|
||||||
|
name: mysql
|
||||||
|
state: restarted
|
||||||
|
```
|
||||||
|
|
||||||
|
Tasks - install_mysql.yml, main.yml & setup_mysql.yml
|
||||||
|
|
||||||
|
install_mysql.yml - 이 작업은 MySQL을 설치하고 서비스가 실행 중인지 확인하기 위해 수행됩니다.
|
||||||
|
|
||||||
|
```Yaml
|
||||||
|
- name: "Install Common packages"
|
||||||
|
apt: name={{ item }} state=latest
|
||||||
|
with_items:
|
||||||
|
- python3-pip
|
||||||
|
- mysql-client
|
||||||
|
- python3-mysqldb
|
||||||
|
- libmysqlclient-dev
|
||||||
|
|
||||||
|
- name: Ensure mysql-server is installed latest version
|
||||||
|
apt: name=mysql-server state=latest
|
||||||
|
|
||||||
|
- name: Installing python module MySQL-python
|
||||||
|
pip:
|
||||||
|
name: PyMySQL
|
||||||
|
|
||||||
|
- name: Ensure mysql-server is running
|
||||||
|
service:
|
||||||
|
name: mysql
|
||||||
|
state: started
|
||||||
|
```
|
||||||
|
|
||||||
|
main.yml은 이러한 파일에서 작업을 가져오도록 제안하는 포인터 파일입니다.
|
||||||
|
|
||||||
|
```Yaml
|
||||||
|
# tasks file for roles/mysql
|
||||||
|
- import_tasks: install_mysql.yml
|
||||||
|
- import_tasks: setup_mysql.yml
|
||||||
|
```
|
||||||
|
|
||||||
|
setup_mysql.yml - 이 작업은 Database와 Database 사용자를 생성합니다.
|
||||||
|
|
||||||
|
```Yaml
|
||||||
|
- name: Create my.cnf configuration file
|
||||||
|
template: src=templates/my.cnf.j2 dest=/etc/mysql/conf.d/mysql.cnf
|
||||||
|
notify: restart mysql
|
||||||
|
|
||||||
|
- name: Create database user with name 'devops' and password 'DevOps90' with all database privileges
|
||||||
|
community.mysql.mysql_user:
|
||||||
|
login_unix_socket: /var/run/mysqld/mysqld.sock
|
||||||
|
login_user: "{{ mysql_user_name }}"
|
||||||
|
login_password: "{{ mysql_user_password }}"
|
||||||
|
name: "{{db_user}}"
|
||||||
|
password: "{{db_pass}}"
|
||||||
|
priv: '*.*:ALL'
|
||||||
|
host: '%'
|
||||||
|
state: present
|
||||||
|
|
||||||
|
- name: Create a new database with name '90daysofdevops'
|
||||||
|
mysql_db:
|
||||||
|
login_user: "{{ mysql_user_name }}"
|
||||||
|
login_password: "{{ mysql_user_password }}"
|
||||||
|
name: "{{ db_name }}"
|
||||||
|
state: present
|
||||||
|
```
|
||||||
|
|
||||||
|
위에서 비밀번호, 사용자 이름 및 Database와 같은 일부 구성을 결정하기 위해 몇 가지 Variable을 사용하고 있음을 알 수 있으며, 이 Variable은 모두 group_vars/all/common_variables.yml 파일에 저장되어 있습니다.
|
||||||
|
|
||||||
|
```Yaml
|
||||||
|
http_port: 8000
|
||||||
|
https_port: 4443
|
||||||
|
html_welcome_msg: "Hello 90DaysOfDevOps - Welcome to Day 68!"
|
||||||
|
|
||||||
|
mysql_user_name: root
|
||||||
|
mysql_user_password: "vagrant"
|
||||||
|
db_user: devops
|
||||||
|
db_pass: DevOps90
|
||||||
|
db_name: 90DaysOfDevOps
|
||||||
|
```
|
||||||
|
|
||||||
|
또한 template 폴더에 아래와 같은 my.cnf.j2 파일이 있습니다:
|
||||||
|
|
||||||
|
```J2
|
||||||
|
[mysql]
|
||||||
|
bind-address = 0.0.0.0
|
||||||
|
```
|
||||||
|
|
||||||
|
### playbook 실행
|
||||||
|
|
||||||
|
이제 VM이 실행 중이고 구성 파일이 준비되었으므로 이제 playbook을 실행할 준비가 되었습니다. 다음 `ansible-playbook playbook7.yml`을 실행하면 이전에 수행한 모든 작업이 포함된 playbook을 실행할 수 있고, `ansible-playbook playbook7.yml --tags database` 명령으로 Database 그룹에 배포하여 새 구성 파일만 실행하도록 선택할 수도 있습니다.
|
||||||
|
|
||||||
|
Database Tag에 대해서만 실행했지만, 오류가 발생했습니다. 이 오류는 pip3(파이썬)가 설치되어 있지 않다는 것을 알려줍니다. 이 오류는 일반 작업에 추가하여 해결할 수 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
위의 문제를 수정하고 playbook을 다시 실행했더니 성공적으로 변경되었습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이제 새로 구성한 db01 서버에서 모든 것이 우리가 원하는 대로 작동하는지 확인해야 합니다. Control Node에서 `ssh db01` 명령을 사용하여 이 작업을 수행할 수 있습니다.
|
||||||
|
|
||||||
|
MySQL에 연결하기 위해 `sudo /usr/bin/mysql -u root -p`를 사용하고 프롬프트에서 root에 대한 vagrant 암호를 제공했습니다.
|
||||||
|
|
||||||
|
연결이 완료되면 먼저 DevOps라는 사용자가 생성되었는지 확인합니다. `select user, host from mysql.user;`
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이제 `SHOW DATABASES;` 명령을 실행하여 생성된 새 Database를 확인할 수 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
루트를 사용하여 연결했지만 이제 `sudo /usr/bin/MySQL -u devops -p`를 사용하여 동일한 방법으로 DevOps 계정으로 로그인할 수도 있지만 여기서 암호는 DevOps90입니다.
|
||||||
|
|
||||||
|
제가 발견한 한 가지는 `setup_mysql.yml`에 `login_unix_socket: /var/run/mysqld/mysqld.sock` 줄을 추가해야 db01 MySQL 인스턴스에 성공적으로 연결할 수 있었고 이제 이 작업을 실행할 때마다 사용자를 만들 때 변경 사항을 보고하므로 어떤 제안이라도 대단히 감사하겠습니다.
|
||||||
|
|
||||||
|
## 자료
|
||||||
|
|
||||||
|
- [What is Ansible](https://www.youtube.com/watch?v=1id6ERvfozo)
|
||||||
|
- [Ansible 101 - Episode 1 - Introduction to Ansible](https://www.youtube.com/watch?v=goclfp6a2IQ)
|
||||||
|
- [NetworkChuck - You need to learn Ansible right now!](https://www.youtube.com/watch?v=5hycyr-8EKs&t=955s)
|
||||||
|
- [Your complete guide to Ansible](https://www.youtube.com/playlist?list=PLnFWJCugpwfzTlIJ-JtuATD2MBBD7_m3u)
|
||||||
|
|
||||||
|
위에 나열된 마지막 재생 목록은 이 섹션의 많은 코드와 아이디어가 나온 곳이며, 동영상 형식의 훌륭한 리소스이자 워크스루입니다.
|
||||||
|
|
||||||
|
[Day 69](day69.md)에서 봐요!
|
||||||
143
2022/ko/Days/day69.md
Normal file
143
2022/ko/Days/day69.md
Normal file
@ -0,0 +1,143 @@
|
|||||||
|
---
|
||||||
|
title: '#90DaysOfDevOps - All other things Ansible - Automation Controller (Tower), AWX, Vault - Day 69'
|
||||||
|
published: false
|
||||||
|
description: '90DaysOfDevOps - All other things Ansible - Automation Controller (Tower), AWX, Vault'
|
||||||
|
tags: 'devops, 90daysofdevops, learning'
|
||||||
|
cover_image: null
|
||||||
|
canonical_url: null
|
||||||
|
id: 1048714
|
||||||
|
---
|
||||||
|
|
||||||
|
## 기타 모든 Ansible - 자동화 컨트롤러(타워), AWX, Vault
|
||||||
|
|
||||||
|
구성 관리에 대한 섹션을 마무리하면서 Ansible을 다룰 때 접할 수 있는 다른 영역에 대해 살펴보고 싶었습니다.
|
||||||
|
|
||||||
|
Ansible 자동화 플랫폼을 구성하는 많은 제품이 있습니다.
|
||||||
|
|
||||||
|
Red Hat Ansible Automation Platform은 조직 전반에서 자동화를 구축하고 운영하기 위한 기반입니다. 이 플랫폼에는 전사적인 자동화를 구현하는 데 필요한 모든 도구가 포함되어 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이 글에서는 이 중 일부를 다루려고 합니다. 하지만 더 자세한 내용은 공식 Red Hat Ansible 사이트에서 더 많은 정보를 확인할 수 있습니다. [Ansible.com](https://www.ansible.com/?hsLang=en-us)
|
||||||
|
|
||||||
|
### Ansible 자동화 컨트롤러 | AWX
|
||||||
|
|
||||||
|
자동화 컨트롤러와 AWX는 제공하는 기능이 매우 유사하기 때문에 이 두 가지를 함께 묶었습니다.
|
||||||
|
|
||||||
|
AWX 프로젝트 또는 줄여서 AWX는 Red Hat이 후원하는 오픈 소스 커뮤니티 프로젝트로, 사용자 환경 내에서 Ansible 프로젝트를 더 잘 제어할 수 있도록 지원합니다. AWX는 자동화 컨트롤러 구성 요소가 파생된 업스트림 프로젝트입니다.
|
||||||
|
|
||||||
|
엔터프라이즈 솔루션을 찾고 계신다면 자동화 컨트롤러를 찾으시거나 이전에 Ansible Tower라고 들어보셨을 것입니다. Ansible 자동화 컨트롤러는 Ansible 자동화 플랫폼의 컨트롤 플레인입니다.
|
||||||
|
|
||||||
|
AWX와 자동화 컨트롤러는 지금까지 이 섹션에서 다룬 다른 모든 기능 위에 다음과 같은 기능을 제공합니다.
|
||||||
|
|
||||||
|
- 사용자 인터페이스
|
||||||
|
- 역할 기반 액세스 제어
|
||||||
|
- workflow
|
||||||
|
- CI/CD 통합
|
||||||
|
|
||||||
|
자동화 컨트롤러는 지원 비용을 지불하는 엔터프라이즈 제품입니다.
|
||||||
|
|
||||||
|
Minikube kubernetes 환경 내에서 AWX를 배포하는 방법을 살펴보겠습니다.
|
||||||
|
|
||||||
|
### Ansible AWX 배포하기
|
||||||
|
|
||||||
|
AWX를 kubernetes 클러스터에 배포할 필요는 없으며, [github](https://github.com/ansible/awx)에서 AWX에 대한 자세한 내용을 확인할 수 있습니다. 그러나 버전 18.0부터는 AWX 오퍼레이터를 사용하여 AWX를 설치하는 것이 선호됩니다.
|
||||||
|
|
||||||
|
우선 Minikube 클러스터가 필요합니다. kubernetes 섹션에서 `minikube start --cpus=4 --memory=6g --addons=ingress` 명령으로 새 Minikube 클러스터를 생성하는 방법을 따라 했다면 이 작업을 수행할 수 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
공식 [Ansible AWX 오퍼레이터](https://github.com/ansible/awx-operator)는 여기에서 확인할 수 있습니다. 설치 지침에 명시된 대로 이 리포지토리를 복제한 다음 배포를 실행해야 합니다.
|
||||||
|
|
||||||
|
위의 리포지토리를 folk한 다음 `git clone https://github.com/MichaelCade/awx-operator.git`을 실행했는데, 여러분도 똑같이 하시고 제가 만든 리포지토리는 변경되거나 존재하지 않을 수 있으므로 사용하지 않는 것이 좋습니다.
|
||||||
|
|
||||||
|
복제된 리포지토리에서 아래와 같이 `NodePort`를 `ClusterIP`로 변경해야 하는 awx-demo.yml 파일을 찾을 수 있습니다:
|
||||||
|
|
||||||
|
```Yaml
|
||||||
|
---
|
||||||
|
apiVersion: awx.ansible.com/v1beta1
|
||||||
|
kind: AWX
|
||||||
|
metadata:
|
||||||
|
name: awx-demo
|
||||||
|
spec:
|
||||||
|
service_type: ClusterIP
|
||||||
|
```
|
||||||
|
|
||||||
|
다음 단계는 awx 연산자를 배포할 네임스페이스를 정의하는 것으로, `export NAMESPACE=awx` 명령을 사용한 다음 `make deploy`로 배포를 시작합니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
확인을 통해 새 네임스페이스가 있고 네임스페이스에서 awx-operator-controller pod가 실행되고 있음을 확인합니다. `kubectl get pods -n awx`
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
복제된 리포지토리 내에서 awx-demo.yml이라는 파일을 찾을 수 있으며, 이제 이 파일을 Kubernetes 클러스터와 awx 네임스페이스에 배포하려고 합니다. `kubectl create -f awx-demo.yml -n awx`
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
`kubectl get pods -n awx -w`로 진행 상황을 계속 주시할 수 있습니다.
|
||||||
|
|
||||||
|
모든 것이 실행되면 아래와 같은 이미지와 비슷한 것이 보일 것입니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이제 새 터미널에서 `minikube service awx-demo-service --url -n $NAMESPACE`를 실행하여 Minikube 인그레스를 통해 이를 노출한 후 awx 배포에 액세스할 수 있어야 합니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
그런 다음 해당 주소 []로 브라우저를 열면 사용자 이름과 비밀번호를 입력하라는 메시지가 표시되는 것을 볼 수 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
기본적으로 사용자 이름은 admin이며, 비밀번호를 얻으려면 다음 명령어를 실행하여 `kubectl get secret awx-demo-admin-password -o jsonpath="{.data.password}" -n awx| base64 --decode`를 얻을 수 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이렇게 하면 중앙 집중화된 위치에서 playbook 및 구성 관리 작업을 관리할 수 있는 UI가 제공되며, 지금까지 하나의 Ansible 제어 스테이션에서 실행하던 것과 달리 팀원들이 함께 작업할 수 있습니다.
|
||||||
|
|
||||||
|
이 영역은 이 도구의 기능을 살펴보는 데 더 많은 시간을 할애할 수 있는 또 다른 영역 중 하나입니다.
|
||||||
|
|
||||||
|
Ansible AWX 사용에 대해 더 자세히 설명하는 Jeff Geerling의 훌륭한 리소스를 소개해 드리겠습니다. [Ansible 101 - 에피소드 10 - Ansible 타워 및 AWX](https://www.youtube.com/watch?v=iKmY4jEiy_A&t=752s)
|
||||||
|
|
||||||
|
이 비디오에서 그는 자동화 컨트롤러(이전 Ansible Tower)와 Ansible AWX(무료 및 오픈 소스)의 차이점에 대해서도 자세히 설명합니다.
|
||||||
|
|
||||||
|
### Ansible Vault
|
||||||
|
|
||||||
|
`ansible-vault`를 사용하면 Ansible 데이터 파일을 암호화하고 해독할 수 있습니다. 이 섹션에서는 일부 민감한 정보를 건너뛰고 일반 텍스트로 표시했습니다.
|
||||||
|
|
||||||
|
Ansible 바이너리에는 이 민감한 정보를 마스킹할 수 있는 `ansible-vault`가 내장되어 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
비밀 관리는 점차 HashiCorp Vault나 AWS 키 관리 서비스와 같은 도구와 함께 더 많은 시간을 할애해야 하는 또 다른 영역이 되었습니다. 이 부분은 더 자세히 살펴볼 영역으로 표시하겠습니다.
|
||||||
|
|
||||||
|
Jeff Geerling의 훌륭한 리소스와 데모를 다시 한번 링크해드리겠습니다 [Ansible 101 - 에피소드 6 - Ansible Vault와 역할](https://www.youtube.com/watch?v=JFweg2dUvqM).
|
||||||
|
|
||||||
|
### Ansible Galaxy(문서)
|
||||||
|
|
||||||
|
이제 데모 프로젝트의 일부 역할과 파일 구조를 생성하기 위해 이미 `ansible-galaxy`를 사용했습니다. 하지만 [Ansible Galaxy 문서](https://galaxy.ansible.com/docs/)도 있습니다.
|
||||||
|
|
||||||
|
"Galaxy는 Ansible 콘텐츠를 찾고 공유하기 위한 허브입니다."
|
||||||
|
|
||||||
|
### Ansible 테스트
|
||||||
|
|
||||||
|
- [Ansible Molecule](https://molecule.readthedocs.io/en/latest/) - Molecule 프로젝트는 Ansible 역할의 개발 및 테스트를 지원하도록 설계되었습니다.
|
||||||
|
|
||||||
|
- [Ansible Lint](https://ansible-lint.readthedocs.io/en/latest/) - playbook, 역할 및 컬렉션을 Lint하기 위한 CLI 도구입니다.
|
||||||
|
|
||||||
|
### 기타 리소스
|
||||||
|
|
||||||
|
- [Ansible 문서](https://docs.ansible.com/ansible/latest/index.html)
|
||||||
|
|
||||||
|
## 자료
|
||||||
|
|
||||||
|
- [What is Ansible](https://www.youtube.com/watch?v=1id6ERvfozo)
|
||||||
|
- [Ansible 101 - Episode 1 - Introduction to Ansible](https://www.youtube.com/watch?v=goclfp6a2IQ)
|
||||||
|
- [NetworkChuck - You need to learn Ansible right now!](https://www.youtube.com/watch?v=5hycyr-8EKs&t=955s)
|
||||||
|
- [Your complete guide to Ansible](https://www.youtube.com/playlist?list=PLnFWJCugpwfzTlIJ-JtuATD2MBBD7_m3u)
|
||||||
|
|
||||||
|
위에 나열된 마지막 재생 목록은 이 섹션의 많은 코드와 아이디어가 나온 곳이며, 동영상 형식의 훌륭한 리소스이자 연습입니다.
|
||||||
|
|
||||||
|
이 포스팅에서는 구성 관리에 대해 살펴본 내용을 마무리하고, 다음에는 CI/CD 파이프라인과 애플리케이션 개발 및 릴리스에 이러한 workflow를 달성하기 위해 사용할 수 있는 몇 가지 도구 및 프로세스에 대해 살펴봅니다.
|
||||||
|
|
||||||
|
[Day 70](day70.md)에서 봐요!
|
||||||
123
2022/ko/Days/day70.md
Normal file
123
2022/ko/Days/day70.md
Normal file
@ -0,0 +1,123 @@
|
|||||||
|
---
|
||||||
|
title: '#90DaysOfDevOps - The Big Picture: CI/CD Pipelines - Day 70'
|
||||||
|
published: false
|
||||||
|
description: 90DaysOfDevOps - The Big Picture CI/CD Pipelines
|
||||||
|
tags: 'devops, 90daysofdevops, learning'
|
||||||
|
cover_image: null
|
||||||
|
canonical_url: null
|
||||||
|
id: 1048836
|
||||||
|
---
|
||||||
|
|
||||||
|
## 큰 그림: CI/CD 파이프라인
|
||||||
|
|
||||||
|
CI/CD(지속적 통합/지속적 배포) 파이프라인 구현은 최신 DevOps 환경의 중추입니다.
|
||||||
|
|
||||||
|
파이프라인은 애플리케이션의 빌드, 테스트 및 배포를 자동화하여 개발과 운영 간의 격차를 해소합니다.
|
||||||
|
|
||||||
|
챌린지의 첫 번째 섹션에서 이 중요한 요소에 대해 많이 다루었습니다. 하지만 다시 한번 말씀드리자면:
|
||||||
|
|
||||||
|
지속적 통합(CI)은 점진적인 코드 변경을 더 자주 그리고 안정적으로 수행하는 보다 현대적인 소프트웨어 개발 관행입니다. 지속적 통합에 의해 트리거되는 자동화된 빌드 및 테스트 Workflow Step은 리포지토리에 병합되는 코드 변경 사항을 신뢰할 수 있도록 보장합니다.
|
||||||
|
|
||||||
|
그런 다음 해당 코드/애플리케이션은 지속적 배포 프로세스의 일부로 신속하고 원활하게 제공됩니다.
|
||||||
|
|
||||||
|
### CI/CD의 중요성은?
|
||||||
|
|
||||||
|
- 소프트웨어를 빠르고 효율적으로 배포
|
||||||
|
- 애플리케이션을 최대한 빠르게 시장에 출시하기 위한 효과적인 프로세스를 촉진합니다.
|
||||||
|
- 버전 릴리스를 위해 몇 달 또는 몇 년을 기다릴 필요 없이 버그 수정 및 새로운 기능을 지속적으로 제공할 수 있습니다.
|
||||||
|
|
||||||
|
개발자가 영향력 있는 작은 변경을 정기적으로 수행할 수 있으므로 더 빠른 수정과 더 많은 기능을 더 빨리 얻을 수 있습니다.
|
||||||
|
|
||||||
|
### 자, 이게 무슨 뜻인가요?
|
||||||
|
|
||||||
|
[Day 5](day05.md)에서 데브옵스에 대한 많은 이론을 다뤘으며, 이미 여기에서 CI/CD 파이프라인이 최신 데브옵스 환경의 핵심이라고 언급했듯이, 이 파이프라인은 최신 데브옵스 환경의 기본입니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이제 데브옵스의 기본을 배우는 여정에 조금 더 들어섰으므로 위 이미지의 몇 가지 핵심 사항을 다시 한번 강조하고 싶습니다.
|
||||||
|
|
||||||
|
소프트웨어 개발 수명 주기(SDLC)를 언급하고 있습니다.
|
||||||
|
|
||||||
|
이 주기는 영원히 반복되는 주기이기 때문에 일반적으로 무한 루프 내에 단계가 기록됩니다.
|
||||||
|
|
||||||
|
개발자가 **코드**를 작성하면 **빌드**되거나 모두 컴파일되고, 버그가 있는지 **테스트**되고, 최종 사용자나 고객이 사용하는 프로덕션에 **배포**되고(**운영**), **모니터링** 및 피드백을 수집하고, 마지막으로 해당 피드백을 중심으로 개선 사항을 **계획**하고 반복하는 것이 이 주기의 단계입니다.
|
||||||
|
|
||||||
|
### CI/CD에 대해 좀 더 자세히 알아봅시다.
|
||||||
|
|
||||||
|
### CI
|
||||||
|
|
||||||
|
CI는 개발자가 하루에 여러 번 공유 리포지토리에 코드를 통합해야 하는 개발 관행입니다.
|
||||||
|
|
||||||
|
코드가 작성되어 Github 또는 GitLab과 같은 리포지토리에 push되면 마법이 시작됩니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
자동화된 빌드를 통해 코드가 검증되므로 팀이나 프로젝트 소유자가 문제를 조기에 발견할 수 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
여기에서 코드를 분석하고 일련의 자동화된 테스트를 수행하는데, 세 가지 예는 다음과 같습니다.
|
||||||
|
|
||||||
|
- 단위 테스트는 소스 코드의 개별 단위를 테스트합니다.
|
||||||
|
- 유효성 검사 테스트는 소프트웨어가 의도된 용도를 충족하거나 적합한지 확인합니다.
|
||||||
|
- 형식 테스트는 구문 및 기타 형식 지정 오류를 확인합니다.
|
||||||
|
|
||||||
|
이러한 테스트는 workflow로 생성된 다음 마스터 브랜치로 push할 때마다 실행되므로 거의 모든 주요 개발팀에는 일종의 CI/CD workflow가 있으며, 개발팀에서는 하루 종일 전 세계의 여러 팀에서 다양한 프로젝트를 진행하는 개발자로부터 새로운 코드가 들어올 수 있으므로 코드가 승인되기 전에 모든 사람이 같은 페이지에 있는지 확인하는 테스트의 자동화된 workflow를 구축하는 것이 더 효율적입니다. 사람이 매번 이 작업을 수행하려면 훨씬 더 오랜 시간이 걸립니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
테스트가 완료되고 성공하면 컴파일하여 리포지토리로 보낼 수 있습니다. 예를 들어, 저는 DockerHub를 사용하고 있지만 파이프라인의 CD 측면에 활용되는 모든 곳이 될 수 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
따라서 이 프로세스는 소프트웨어 개발 프로세스와 매우 유사하며, 애플리케이션을 만들고, 버그를 추가하고, 수정한 다음 소스 제어를 업데이트하고, 테스트하면서 버전도 관리합니다.
|
||||||
|
|
||||||
|
다음 단계로 넘어가면 CD 요소인데, 일반적으로 상용 소프트웨어에서 볼 수 있는 CD 요소는 점점 더 많아지고 있으며, 오라클이나 Microsoft와 같은 공급업체로부터 소프트웨어를 받으면 DockerHub 유형 리포지토리에서 이를 소비한 다음 CD 파이프라인을 사용하여 환경에 배포하는 추세를 보게 될 것이라고 주장하고 싶습니다.
|
||||||
|
|
||||||
|
### CD
|
||||||
|
|
||||||
|
이제 테스트된 버전의 코드를 배포할 준비가 되었습니다. 소프트웨어 공급업체가 이 단계를 진행하겠지만, 저는 이것이 앞으로 우리 모두가 필요한 상용 소프트웨어를 배포하는 방식이 될 것이라고 굳게 믿습니다.
|
||||||
|
|
||||||
|
이제 코드를 환경에 배포할 차례입니다. 여기에는 프로덕션 환경뿐만 아니라 스테이징과 같은 다른 환경도 포함될 것입니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
소프트웨어 배포 1일차에서 다음 단계는 올바른 코드 베이스를 올바른 환경으로 가져오고 있는지 확인하는 것입니다. 소프트웨어 리포지토리(DockerHub)에서 요소를 가져올 수도 있지만, 다른 코드 리포지토리에서 추가 구성, 예를 들어 애플리케이션에 대한 구성을 가져올 수도 있습니다. 아래 다이어그램에서는 DockerHub에서 소프트웨어의 최신 릴리스를 가져온 다음 이를 환경에 릴리스하는 동시에 Git 리포지토리에서 구성을 가져올 수 있습니다. CD 도구가 이 작업을 수행하여 모든 것을 환경에 push합니다.
|
||||||
|
|
||||||
|
이 작업은 동시에 수행되지 않을 가능성이 높습니다. 즉, 구성이 올바른지 확인하기 위해 스테이징 환경으로 이동하여 이 구성에 대해 실행한 후 테스트를 위한 수동 단계일 수도 있고, 이 코드를 프로덕션에 배포하기 전에 다시 자동화할 수도 있습니다(자동화로 가겠습니다).
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
그런 다음 애플리케이션의 v2가 나오면 이번에는 단계를 반복하여 애플리케이션 + 구성이 스테이징에 배포되어 모든 것이 정상인지 확인한 다음 프로덕션에 배포합니다.
|
||||||
|
|
||||||
|
### CI/CD를 사용하는 이유는 무엇인가요?
|
||||||
|
|
||||||
|
이미 여러 번 이점에 대해 설명했지만, 수동으로 수행해야 하는 작업을 자동화하여 작은 문제가 메인 코드 베이스에 들어가기 전에 발견하기 때문입니다. 고객에게 잘못된 코드를 push하면 큰 문제가 발생할 수 있다는 것을 상상할 수 있을 것입니다!
|
||||||
|
|
||||||
|
또한 메인 코드 리포지토리는 시간이 지남에 따라 지속적으로 구축되기 때문에 첫날에 수행한 지름길 수정이 몇 년 후 기하급수적으로 더 많은 비용이 드는 수정이 될 수 있다는 생각인 기술 부채를 방지하는 데 도움이 됩니다.
|
||||||
|
|
||||||
|
### 도구
|
||||||
|
|
||||||
|
다른 섹션과 마찬가지로 CI/CD 파이프라인 프로세스를 달성하는 몇 가지 도구에 대해 실습해 보겠습니다.
|
||||||
|
|
||||||
|
모든 도구가 CI와 CD를 모두 수행해야 하는 것은 아니며, 소프트웨어를 Kubernetes 클러스터에 배포하는 데 있어 CD 요소에 능숙한 ArgoCD를 살펴볼 것입니다. 하지만 Jenkins와 같은 것은 다양한 플랫폼에서 작동할 수도 있습니다.
|
||||||
|
|
||||||
|
저는 다음을 살펴볼 계획입니다:
|
||||||
|
|
||||||
|
- Jenkins
|
||||||
|
- ArgoCD
|
||||||
|
- GitHub Actions
|
||||||
|
|
||||||
|
## 자료
|
||||||
|
|
||||||
|
- [Jenkins is the way to build, test, deploy](https://youtu.be/_MXtbjwsz3A)
|
||||||
|
- [Introduction to Jenkins](https://www.edx.org/course/introduction-to-jenkins)
|
||||||
|
- [Jenkins.io](https://www.jenkins.io/)
|
||||||
|
- [ArgoCD](https://argo-cd.readthedocs.io/en/stable/)
|
||||||
|
- [ArgoCD Tutorial for Beginners](https://www.youtube.com/watch?v=MeU5_k9ssrs)
|
||||||
|
- [What is Jenkins?](https://www.youtube.com/watch?v=LFDrDnKPOTg)
|
||||||
|
- [Complete Jenkins Tutorial](https://www.youtube.com/watch?v=nCKxl7Q_20I&t=3s)
|
||||||
|
- [GitHub Actions](https://www.youtube.com/watch?v=R8_veQiYBjI)
|
||||||
|
- [GitHub Actions CI/CD](https://www.youtube.com/watch?v=mFFXuXjVgkU)
|
||||||
|
|
||||||
|
[Day 71](day71.md)에서 봐요!
|
||||||
105
2022/ko/Days/day71.md
Normal file
105
2022/ko/Days/day71.md
Normal file
@ -0,0 +1,105 @@
|
|||||||
|
---
|
||||||
|
title: '#90DaysOfDevOps - What is Jenkins? - Day 71'
|
||||||
|
published: false
|
||||||
|
description: 90DaysOfDevOps - What is Jenkins?
|
||||||
|
tags: 'DevOps, 90daysofdevops, learning'
|
||||||
|
cover_image: null
|
||||||
|
canonical_url: null
|
||||||
|
id: 1048745
|
||||||
|
---
|
||||||
|
|
||||||
|
## Jenkins란 무엇인가요?
|
||||||
|
|
||||||
|
Jenkins는 새로 만든 코드를 지속적으로 개발, 테스트 및 배포할 수 있는 지속적 통합 도구입니다.
|
||||||
|
|
||||||
|
야간 빌드 또는 지속적 개발을 통해 이를 달성할 수 있는 방법에는 두 가지가 있습니다. 첫 번째 옵션은 개발자가 하루 종일 작업을 개발하다가 정해진 하루가 끝나면 변경 사항을 소스 코드 저장소에 push하는 것입니다. 그런 다음 밤에는 단위 테스트를 실행하고 소프트웨어를 빌드합니다. 이것이 모든 코드를 통합하는 오래된 방식이라고 할 수 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
다른 옵션이자 선호되는 방식은 개발자가 소스 코드에 변경 사항을 커밋하고 해당 코드 커밋이 완료되면 빌드 프로세스가 지속적으로 시작되는 방식입니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
위의 방법을 사용하면 전 세계에 분산된 개발자가 있는 경우 매일 정해진 시간에 코드 변경 사항 커밋을 중단할 수 없습니다. 이러한 테스트와 빌드 프로세스를 제어하기 위해 CI 서버 역할을 하는 것이 바로 Jenkins입니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
여기서는 Jenkins에 대해 이야기하고 있지만 나중에 몇 가지를 더 추가하여 Jenkins가 전반적으로 가장 인기 있는 것으로 보이는 이유와 그 이유, 그리고 다른 도구가 Jenkins보다 무엇을 할 수 있는지에 대해 알아보고자 합니다.
|
||||||
|
|
||||||
|
- TravisCI - GitHub에서 호스팅되는 소프트웨어 프로젝트를 빌드하고 테스트하는 데 사용되는 호스팅된 분산형 지속적 통합 서비스입니다.
|
||||||
|
- Bamboo - 빠른 컴파일을 위해 여러 빌드를 병렬로 실행할 수 있으며, 리포지토리와 연결할 수 있는 기능이 내장되어 있고 Ant 및 Maven용 빌드 작업이 있습니다.
|
||||||
|
- Buildbot - 소프트웨어 빌드, 테스트 및 릴리스 프로세스를 자동화하기 위한 오픈 소스 프레임워크입니다. Python으로 작성되었으며 여러 플랫폼에서 작업의 분산 병렬 실행을 지원합니다.
|
||||||
|
- Apache Gump - 매일 밤 Java 프로젝트를 빌드하고 테스트하도록 설계된 Java 프로젝트 전용으로, 모든 프로젝트가 API 및 기능 수준 모두에서 호환되도록 보장합니다.
|
||||||
|
|
||||||
|
이제부터는 Jenkins에 초점을 맞추겠습니다. Jenkins는 위의 모든 도구와 마찬가지로 오픈 소스이며 Java로 작성된 자동화 서버입니다. 지속적인 통합을 통해 소프트웨어 개발 프로세스를 자동화하고 지속적인 배포를 용이하게 하는 데 사용됩니다.
|
||||||
|
|
||||||
|
### Jenkins의 특징
|
||||||
|
|
||||||
|
예상할 수 있듯이 Jenkins는 다양한 영역에 걸쳐 많은 기능을 가지고 있습니다.
|
||||||
|
|
||||||
|
**간편한 설치** - Jenkins는 Windows, macOS 및 Linux 운영 체제용 패키지와 함께 실행할 준비가 된 독립형 자바 기반 프로그램입니다.
|
||||||
|
|
||||||
|
**간편한 구성** - 오류 확인 및 기본 제공 도움말이 포함된 웹 인터페이스를 통해 쉽게 설정 및 구성할 수 있습니다.
|
||||||
|
|
||||||
|
**플러그인** - 업데이트 센터에서 다양한 플러그인을 사용할 수 있으며 CI/CD 툴체인의 여러 도구와 통합됩니다.
|
||||||
|
|
||||||
|
**확장 가능** - 사용 가능한 플러그인 외에도 플러그인 아키텍처를 통해 Jenkins를 확장할 수 있어 거의 무한한 용도로 사용할 수 있는 옵션을 제공합니다.
|
||||||
|
|
||||||
|
**분산** - Jenkins는 여러 머신에 작업을 쉽게 분산하여 여러 플랫폼에서 빌드, 테스트 및 배포 속도를 높일 수 있도록 지원합니다.
|
||||||
|
|
||||||
|
### Jenkins 파이프라인
|
||||||
|
|
||||||
|
이 파이프라인을 보셨겠지만, 훨씬 광범위하게 사용되며 특정 도구에 대해서는 언급하지 않았습니다.
|
||||||
|
|
||||||
|
Jenkins에 코드를 커밋하면 모든 자동화된 테스트를 통해 애플리케이션을 빌드한 다음 각 단계가 완료되면 해당 코드를 릴리스 및 배포합니다. 이 프로세스를 자동화할 수 있는 것이 바로 Jenkins입니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
### Jenkins 아키텍처
|
||||||
|
|
||||||
|
먼저, 바퀴를 재발명하고 싶지 않기 때문에 항상 [Jenkins 문서](https://www.jenkins.io/doc/developer/architecture/)에서 시작하는 것이 가장 좋지만, 여기에도 제가 메모하고 배운 내용을 적어 두려고 합니다.
|
||||||
|
|
||||||
|
Jenkins는 윈도우, 리눅스, 맥OS 등 다양한 운영체제에 설치할 수 있을 뿐만 아니라 Docker 컨테이너로 배포하거나 Kubernetes 내에서 배포할 수 있는 기능도 있습니다. [Jenkins 설치하기](https://www.jenkins.io/doc/book/installing/)
|
||||||
|
|
||||||
|
이번 글에서는 Minikube 클러스터 내에 Jenkins를 설치하여 Kubernetes에 배포하는 과정을 시뮬레이션해 보겠습니다. 하지만 이는 이 섹션의 나머지 부분에서 구성한 시나리오에 따라 달라집니다.
|
||||||
|
|
||||||
|
이제 아래 이미지를 분석해 보겠습니다.
|
||||||
|
|
||||||
|
1단계 - 개발자가 소스 코드 리포지토리에 변경 사항을 커밋합니다.
|
||||||
|
|
||||||
|
2단계 - Jenkins가 정기적으로 리포지토리를 확인하여 새 코드를 가져옵니다.
|
||||||
|
|
||||||
|
3단계 - 빌드 서버가 코드를 실행 파일로 빌드하며, 이 예에서는 잘 알려진 빌드 서버로 maven을 사용하고 있습니다. 다루어야 할 또 다른 영역입니다.
|
||||||
|
|
||||||
|
4단계 - 빌드에 실패하면 개발자에게 피드백이 다시 전송됩니다.
|
||||||
|
|
||||||
|
5단계 - 그런 다음 Jenkins는 빌드된 앱을 테스트 서버에 배포합니다. 이 예에서는 잘 알려진 테스트 서버로 selenium을 사용하고 있습니다. 또 다른 영역입니다.
|
||||||
|
|
||||||
|
6단계 - 테스트가 실패하면 개발자에게 피드백이 전달됩니다.
|
||||||
|
|
||||||
|
7단계 - 테스트가 성공하면 프로덕션에 릴리스할 수 있습니다.
|
||||||
|
|
||||||
|
이 주기는 연속적이기 때문에 애플리케이션을 몇 시간, 며칠, 몇 달, 몇 년이 아닌 몇 분 만에 업데이트할 수 있습니다!
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
필요한 경우 master가 slave Jenkins 환경에 작업을 배포할 수 있는 master-slave 기능이 있는 등 Jenkins의 아키텍처에는 훨씬 더 많은 기능이 있습니다.
|
||||||
|
|
||||||
|
참고로 Jenkins는 오픈 소스이므로 지원을 필요로 하는 많은 기업이 있을 것이며, CloudBees는 유료 엔터프라이즈 고객을 위한 지원 및 기타 기능을 제공하는 엔터프라이즈 버전의 Jenkins입니다.
|
||||||
|
|
||||||
|
고객 중 한 예로 Bosch를 들 수 있는데, Bosch 사례 연구는 [여기](https://assets.ctfassets.net/vtn4rfaw6n2j/case-study-boschpdf/40a0b23c61992ed3ee414ae0a55b6777/case-study-bosch.pdf)에서 확인할 수 있습니다.
|
||||||
|
|
||||||
|
내일은 애플리케이션의 단계별 예시를 통해 Jenkins를 사용하는 방법을 살펴본 다음 다른 도구와 함께 사용할 수 있도록 하겠습니다.
|
||||||
|
|
||||||
|
## 자료
|
||||||
|
|
||||||
|
- [Jenkins is the way to build, test, deploy](https://youtu.be/_MXtbjwsz3A)
|
||||||
|
- [Jenkins.io](https://www.jenkins.io/)
|
||||||
|
- [ArgoCD](https://argo-cd.readthedocs.io/en/stable/)
|
||||||
|
- [ArgoCD Tutorial for Beginners](https://www.youtube.com/watch?v=MeU5_k9ssrs)
|
||||||
|
- [What is Jenkins?](https://www.youtube.com/watch?v=LFDrDnKPOTg)
|
||||||
|
- [Complete Jenkins Tutorial](https://www.youtube.com/watch?v=nCKxl7Q_20I&t=3s)
|
||||||
|
- [GitHub Actions](https://www.youtube.com/watch?v=R8_veQiYBjI)
|
||||||
|
- [GitHub Actions CI/CD](https://www.youtube.com/watch?v=mFFXuXjVgkU)
|
||||||
|
|
||||||
|
[Day 72](day72.md)에서 봐요!킨
|
||||||
162
2022/ko/Days/day72.md
Normal file
162
2022/ko/Days/day72.md
Normal file
@ -0,0 +1,162 @@
|
|||||||
|
---
|
||||||
|
title: '#90DaysOfDevOps - Getting hands-on with Jenkins - Day 72'
|
||||||
|
published: false
|
||||||
|
description: 90DaysOfDevOps - Getting hands-on with Jenkins
|
||||||
|
tags: 'DevOps, 90daysofdevops, learning'
|
||||||
|
cover_image: null
|
||||||
|
canonical_url: null
|
||||||
|
id: 1048829
|
||||||
|
---
|
||||||
|
|
||||||
|
## Jenkins 실습하기
|
||||||
|
|
||||||
|
오늘 계획은 Jenkins를 직접 사용해 보고 CI 파이프라인의 일부로 사용할 수 있는 몇 가지 예제 코드 베이스를 살펴보면서 무언가를 만들어 보는 것입니다.
|
||||||
|
|
||||||
|
### 파이프라인이란 무엇인가요?
|
||||||
|
|
||||||
|
시작하기 전에 CI와 관련하여 파이프라인이 무엇인지 알아야 하는데, 어제 세션에서 이미 다음 이미지와 함께 이 내용을 다루었습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
위의 프로세스 또는 단계를 자동화하여 최종적으로 배포된 애플리케이션을 고객, 최종 사용자 등에게 제공할 수 있는 결과물을 얻고자 합니다.
|
||||||
|
|
||||||
|
이 자동화된 프로세스를 통해 사용자와 고객에 대한 버전 관리를 수행할 수 있습니다. 모든 변경 사항, 기능 향상, 버그 수정 등은 이 자동화된 프로세스를 거쳐 코드가 양호한지 확인하기 위해 많은 수동 개입 없이 모든 것이 정상인지 확인합니다.
|
||||||
|
|
||||||
|
이 프로세스에는 안정적이고 반복 가능한 방식으로 소프트웨어를 빌드하고, 여러 단계의 테스트 및 배포를 통해 빌드된 소프트웨어('build'라고 함)를 발전시키는 작업이 포함됩니다.
|
||||||
|
|
||||||
|
Jenkins 파이프라인은 Jenkins파일이라는 텍스트 파일로 작성됩니다. 이 파일은 소스 제어 리포지토리에 커밋되어야 합니다. 이를 코드형 파이프라인이라고도 하며, 몇 주 전에 다룬 IaC에 매우 유사하게 비유할 수도 있습니다.
|
||||||
|
|
||||||
|
[Jenkins 파이프라인 정의](https://www.jenkins.io/doc/book/pipeline/#ji-toolbar)
|
||||||
|
|
||||||
|
### Jenkins 배포하기
|
||||||
|
|
||||||
|
Jenkins 배포를 재미있게 해봤는데요, [문서](https://www.jenkins.io/doc/book/installing/)를 보면 Jenkins를 설치할 수 있는 위치에 대한 옵션이 많다는 것을 알 수 있습니다.
|
||||||
|
|
||||||
|
저는 Minikube를 가지고 있고 이를 여러 번 사용했기 때문에 이 작업에도 Minikube를 사용하고 싶었습니다. (또한 무료입니다!) [Kubernetes 설치](https://www.jenkins.io/doc/book/installing/kubernetes/)에 나와 있는 단계는 벽에 부딪혀서 실행하지 못했지만, 여기에 단계를 문서화하면 두 가지를 비교할 수 있습니다.
|
||||||
|
|
||||||
|
첫 번째 단계는 Minikube 클러스터를 시작하고 실행하는 것으로, `minikube start` 명령으로 간단히 할 수 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
여기에서 찾을 수 있는 모든 YAML 구성과 값이 있는 폴더를 [여기](/2022/Days/CICD/Jenkins) 추가했습니다.이제 클러스터가 생겼으므로 다음을 실행하여 jenkins 네임스페이스를 생성할 수 있습니다. `kubectl create -f jenkins-namespace.yml`
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
클러스터에 Jenkins를 배포하기 위해 Helm을 사용할 것이며, Helm은 Kubernetes 섹션에서 다루었습니다. 먼저 jenkinsci Helm 리포지토리 `helm repo add jenkinsci https://charts.jenkins.io`를 추가한 다음 `helm repo update` chart를 업데이트해야 합니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Jenkins의 기본 개념은 파이프라인의 상태를 저장하는 것으로, 위의 Helm 설치를 지속성 없이 실행할 수 있지만 해당 pod가 재부팅, 변경 또는 수정되면 생성한 파이프라인이나 구성이 손실됩니다. `kubectl apply -f jenkins-volume.yml` 명령으로 jenkins-volume.yml 파일을 사용하여 지속성을 위한 volume을 생성합니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
또한 이 YAML 파일과 명령어를 사용하여 생성할 수 있는 서비스 계정이 필요합니다. `kubectl apply -f jenkins-sa.yml`
|
||||||
|
|
||||||
|
|
||||||
|
이 단계에서는 Helm chart를 사용하여 배포하는 것이 좋으며, 먼저 `chart=jenkinsci/jenkins`를 사용하여 chart를 정의한 다음, 이 명령을 사용하여 배포할 것이며, 여기에는 이전에 클러스터에 배포한 지속성 및 서비스 계정이 포함된 jenkins-values.yml이 포함됩니다. `helm install jenkins -n jenkins -f jenkins-values.yml $chart`
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이 단계에서는 pod가 이미지를 가져올 것이지만 pod가 스토리지에 액세스할 수 없으므로 Jenkins를 시작하고 실행하기 위한 구성을 시작할 수 없습니다.
|
||||||
|
|
||||||
|
이 단계에서는 문서가 무슨 일이 일어나야 하는지 이해하는 데 큰 도움이 되지 않았습니다. 하지만 Jenkins 설치를 시작할 수 있는 권한이 없다는 것을 알 수 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
위의 문제를 수정하거나 해결하려면, 우리가 제안한 이 위치에 Jenkins pod가 쓸 수 있도록 액세스 권한 또는 올바른 권한을 제공해야 합니다. 이를 위해 `minikube ssh`를 사용하여 실행 중인 Minikube Docker 컨테이너에 들어간 다음 `sudo chown -R 1000:1000 /data/jenkins-volume`을 사용하여 데이터 volume에 대한 권한이 설정되어 있는지 확인할 수 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
위의 프로세스로 pod가 수정되어야 하지만, 그렇지 않은 경우 `kubectl delete pod jenkins-0 -n jenkins` 명령으로 pod를 강제로 새로 고칠 수 있다. 이 시점에서, 2/2의 실행 중인 pod인 jenkins-0이 있어야 한다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이제 관리자 비밀번호가 필요하며 다음 명령어를 사용하여 비밀번호를 입력할 수 있습니다. `kubectl exec --namespace jenkins -it svc/jenkins -c jenkins -- /bin/cat /run/secrets/chart-admin-password && echo`
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이제 워크스테이션에서 접근할 수 있도록 `port-forward` 명령을 사용할 것이므로 새 터미널을 엽니다. `kubectl --namespace jenkins port-forward svc/jenkins 8080:8080`
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이제 브라우저를 열고 `http://localhost:8080`에 로그인하여 이전 단계에서 수집한 username: admin과 password로 인증할 수 있어야 합니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
인증이 완료되면 Jenkins 시작 페이지는 다음과 같이 표시되어야 합니다:
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
여기에서 "Manage Jenkins"로 이동하면 사용 가능한 몇 가지 업데이트가 있는 "Manage Plugins"가 표시됩니다. 해당 플러그인을 모두 선택하고 "Download now and install after restart"를 선택합니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
더 나아가 shell 스크립트를 사용하여 Jenkins 배포를 자동화하고 싶다면 트위터에서 저와 공유한 이 훌륭한 리포지토리를 참고하세요 [mehyedes/nodejs-k8s](https://github.com/mehyedes/nodejs-k8s/blob/main/docs/automated-setup.md).
|
||||||
|
|
||||||
|
### Jenkinsfile
|
||||||
|
|
||||||
|
이제 Kubernetes 클러스터에 Jenkins가 배포되었으므로 이제 돌아가서 이 Jenkinsfile에 대해 생각해 볼 수 있습니다.
|
||||||
|
|
||||||
|
모든 Jenkinsfile은 이렇게 시작될 가능성이 높습니다. 먼저 파이프라인의 단계를 정의하는 곳이며, 이 경우에는 빌드 > 테스트 > 배포가 있습니다. 하지만 여기서는 특정 단계를 호출하기 위해 `echo` 명령을 사용하는 것 외에는 아무것도 하지 않습니다.
|
||||||
|
|
||||||
|
```
|
||||||
|
Jenkinsfile (Declarative Pipeline)
|
||||||
|
|
||||||
|
pipeline {
|
||||||
|
agent any
|
||||||
|
|
||||||
|
stages {
|
||||||
|
stage('Build') {
|
||||||
|
steps {
|
||||||
|
echo 'Building..'
|
||||||
|
}
|
||||||
|
}
|
||||||
|
stage('Test') {
|
||||||
|
steps {
|
||||||
|
echo 'Testing..'
|
||||||
|
}
|
||||||
|
}
|
||||||
|
stage('Deploy') {
|
||||||
|
steps {
|
||||||
|
echo 'Deploying....'
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
```
|
||||||
|
|
||||||
|
Jenkins 대시보드에서 "New Item"을 선택하고 항목에 이름을 지정합니다. 저는 "echo1"이라고 하고 이것이 파이프라인이라고 해보겠습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
확인을 누르면 파이프라인에만 관심이 있는 간단한 테스트를 위한 탭(일반, 빌드 트리거, 고급 프로젝트 옵션 및 파이프라인)이 표시됩니다. 파이프라인에서 스크립트를 추가할 수 있으며, 위의 스크립트를 복사하여 상자에 붙여 넣을 수 있습니다.
|
||||||
|
|
||||||
|
위에서 말했듯이 이것은 많은 작업을 수행하지는 않지만 빌드 > 테스트 > 배포의 단계를 보여줍니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
저장을 클릭하면 이제 아래에 강조 표시된 "build now"를 사용하여 빌드를 실행할 수 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
또한 터미널을 열고 `kubectl get pods -n jenkins`를 실행하여 어떤 일이 발생하는지 확인해야 합니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
자, 아주 간단하지만 이제 Jenkins 배포와 설치가 올바르게 작동하고 있으며 여기에서 CI 파이프라인의 구성 요소를 볼 수 있습니다.
|
||||||
|
|
||||||
|
다음 섹션에서는 Jenkins 파이프라인을 구축하겠습니다.
|
||||||
|
|
||||||
|
## 자료
|
||||||
|
|
||||||
|
- [Jenkins is the way to build, test, deploy](https://youtu.be/_MXtbjwsz3A)
|
||||||
|
- [Jenkins.io](https://www.jenkins.io/)
|
||||||
|
- [ArgoCD](https://argo-cd.readthedocs.io/en/stable/)
|
||||||
|
- [ArgoCD Tutorial for Beginners](https://www.youtube.com/watch?v=MeU5_k9ssrs)
|
||||||
|
- [What is Jenkins?](https://www.youtube.com/watch?v=LFDrDnKPOTg)
|
||||||
|
- [Complete Jenkins Tutorial](https://www.youtube.com/watch?v=nCKxl7Q_20I&t=3s)
|
||||||
|
- [GitHub Actions](https://www.youtube.com/watch?v=R8_veQiYBjI)
|
||||||
|
- [GitHub Actions CI/CD](https://www.youtube.com/watch?v=mFFXuXjVgkU)
|
||||||
|
|
||||||
|
[Day 73](day73.md)에서 봐요!
|
||||||
226
2022/ko/Days/day73.md
Normal file
226
2022/ko/Days/day73.md
Normal file
@ -0,0 +1,226 @@
|
|||||||
|
---
|
||||||
|
title: '#90DaysOfDevOps - Building a Jenkins Pipeline - Day 73'
|
||||||
|
published: false
|
||||||
|
description: 90DaysOfDevOps - Building a Jenkins Pipeline
|
||||||
|
tags: 'DevOps, 90daysofdevops, learning'
|
||||||
|
cover_image: null
|
||||||
|
canonical_url: null
|
||||||
|
id: 1048766
|
||||||
|
---
|
||||||
|
|
||||||
|
## Jenkins 파이프라인 구축하기
|
||||||
|
|
||||||
|
지난 섹션에서는 Minikube 클러스터에 Jenkins를 배포하고 파이프라인의 단계를 echo하는 것 외에는 별다른 기능을 하지 않는 매우 기본적인 Jenkins 파이프라인을 설정했습니다.
|
||||||
|
|
||||||
|
또한 Jenkins Pipeline 생성에서 실행할 수 있는 몇 가지 예제 스크립트가 있다는 것을 보셨을 것입니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
첫 번째 데모 스크립트는 "Declarative (Kubernetes)"이며 아래 단계를 볼 수 있습니다.
|
||||||
|
|
||||||
|
```Yaml
|
||||||
|
// Uses Declarative syntax to run commands inside a container.
|
||||||
|
pipeline {
|
||||||
|
agent {
|
||||||
|
kubernetes {
|
||||||
|
// Rather than inline YAML, in a multibranch Pipeline you could use: yamlFile 'jenkins-pod.yaml'
|
||||||
|
// Or, to avoid YAML:
|
||||||
|
// containerTemplate {
|
||||||
|
// name 'shell'
|
||||||
|
// image 'ubuntu'
|
||||||
|
// command 'sleep'
|
||||||
|
// args 'infinity'
|
||||||
|
// }
|
||||||
|
yaml '''
|
||||||
|
apiVersion: v1
|
||||||
|
kind: Pod
|
||||||
|
spec:
|
||||||
|
containers:
|
||||||
|
- name: shell
|
||||||
|
image: ubuntu
|
||||||
|
command:
|
||||||
|
- sleep
|
||||||
|
args:
|
||||||
|
- infinity
|
||||||
|
'''
|
||||||
|
// Can also wrap individual steps:
|
||||||
|
// container('shell') {
|
||||||
|
// sh 'hostname'
|
||||||
|
// }
|
||||||
|
defaultContainer 'shell'
|
||||||
|
}
|
||||||
|
}
|
||||||
|
stages {
|
||||||
|
stage('Main') {
|
||||||
|
steps {
|
||||||
|
sh 'hostname'
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
이 파이프라인을 실행하면 어떤 결과가 발생하는지 아래에서 확인할 수 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
### Job 만들기
|
||||||
|
|
||||||
|
#### 목표
|
||||||
|
|
||||||
|
- 간단한 앱을 만들어 GitHub 공용 리포지토리에 저장 [https://github.com/scriptcamp/kubernetes-kaniko.git](https://github.com/scriptcamp/kubernetes-kaniko.git)
|
||||||
|
|
||||||
|
- Jenkins를 사용하여 Docker 컨테이너 이미지를 빌드하고 DockerHub에 push합니다. (이를 위해 비공개 리포지토리를 사용합니다.)
|
||||||
|
|
||||||
|
Minikube에서 실행 중이거나 Minikube를 사용하는 Kubernetes 클러스터에서 이 작업을 수행하려면 [Kaniko](https://github.com/GoogleContainerTools/kaniko#running-kaniko-in-a-kubernetes-cluster)라는 것을 사용해야 하지만, 실제 Kubernetes 클러스터에서 Jenkins를 사용하거나 서버에서 실행하는 경우 에이전트를 지정하여 Docker 빌드 명령을 수행하고 이를 DockerHub에 업로드할 수 있는 기능을 제공하는 것이 일반적입니다.
|
||||||
|
|
||||||
|
위의 내용을 염두에 두고 GitHub credentials로 Kubernetes에 시크릿을 배포해 보겠습니다.
|
||||||
|
|
||||||
|
```Shell
|
||||||
|
kubectl create secret docker-registry dockercred \
|
||||||
|
--docker-server=https://index.docker.io/v1/ \
|
||||||
|
--docker-username=<dockerhub-username> \
|
||||||
|
--docker-password=<dockerhub-password>\
|
||||||
|
--docker-email=<dockerhub-email>
|
||||||
|
```
|
||||||
|
|
||||||
|
여기서 다룰 내용 대부분을 관통하는 [DevOpsCube.com](https://devopscube.com/build-docker-image-kubernetes-pod/)의 또 다른 훌륭한 리소스를 공유하고자 합니다.
|
||||||
|
|
||||||
|
### Jenkins에 credentials 추가하기
|
||||||
|
|
||||||
|
하지만 저희와 다른 Jenkins 시스템을 사용 중이라면 Jenkins 내에서 credentials를 정의한 다음 파이프라인 및 구성 내에서 여러 번 사용하고 싶을 것입니다. 생성 시 결정한 ID를 사용하여 파이프라인에서 이러한 credentials를 참조할 수 있습니다. 계속해서 단계를 진행하여 DockerHub 및 GitHub에 대한 사용자 항목을 만들었습니다.
|
||||||
|
|
||||||
|
먼저 "Manage Jenkins"를 선택한 다음 "Manage Credentials"를 선택합니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
페이지 중앙에 Jenkins로 범위가 설정된 Stores가 표시되면 여기에서 Jenkins를 클릭합니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이제 Global Credentials (Unrestricted)를 선택합니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
그런 다음 왼쪽 상단에 Add Credentials가 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
계정에 대한 세부 정보를 입력한 다음 확인을 선택하고, 이 credentials를 호출할 때 참조할 ID를 기억하세요. 여기서도 비밀번호 대신 특정 토큰 액세스를 사용하는 것이 좋습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
GitHub의 경우 [Personal Access Token](https://vzilla.co.uk/vzilla-blog/creating-updating-your-github-personal-access-token)을 사용해야 합니다.
|
||||||
|
|
||||||
|
저는 이 계정을 생성하는 과정이 직관적이지 않아서 사용하지는 않지만, UI에서 명확하지 않아서 그 과정을 공유하고 싶었습니다.
|
||||||
|
|
||||||
|
### 파이프라인 구축
|
||||||
|
|
||||||
|
Kubernetes 클러스터에 비밀로 배포된 DockerHub credentials를 가지고 있으며, 이 credentials를 파이프라인의 DockerHub 단계에 배포하기 위해 호출할 것입니다.
|
||||||
|
|
||||||
|
파이프라인 스크립트는 아래에서 볼 수 있는 것과 같으며, 파이프라인의 프로젝트 가져오기 단계에서도 볼 수 있는 GitHub 리포지토리에 있는 Jenkinsfile이 될 수 있습니다.
|
||||||
|
|
||||||
|
```Yaml
|
||||||
|
podTemplate(yaml: '''
|
||||||
|
apiVersion: v1
|
||||||
|
kind: Pod
|
||||||
|
spec:
|
||||||
|
containers:
|
||||||
|
- name: maven
|
||||||
|
image: maven
|
||||||
|
command:
|
||||||
|
- sleep
|
||||||
|
args:
|
||||||
|
- 99d
|
||||||
|
- name: kaniko
|
||||||
|
image: gcr.io/kaniko-project/executor:debug
|
||||||
|
command:
|
||||||
|
- sleep
|
||||||
|
args:
|
||||||
|
- 9999999
|
||||||
|
volumeMounts:
|
||||||
|
- name: kaniko-secret
|
||||||
|
mountPath: /kaniko/.docker
|
||||||
|
restartPolicy: Never
|
||||||
|
volumes:
|
||||||
|
- name: kaniko-secret
|
||||||
|
secret:
|
||||||
|
secretName: dockercred
|
||||||
|
items:
|
||||||
|
- key: .dockerconfigjson
|
||||||
|
path: config.json
|
||||||
|
''') {
|
||||||
|
node(POD_LABEL) {
|
||||||
|
stage('Get the project') {
|
||||||
|
git url: 'https://github.com/scriptcamp/kubernetes-kaniko.git', branch: 'main'
|
||||||
|
container('maven') {
|
||||||
|
stage('Test the project') {
|
||||||
|
sh '''
|
||||||
|
echo pwd
|
||||||
|
'''
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
stage('Build & Test the Docker Image') {
|
||||||
|
container('kaniko') {
|
||||||
|
stage('Deploy to DockerHub') {
|
||||||
|
sh '''
|
||||||
|
/kaniko/executor --context `pwd` --destination me1e/helloword
|
||||||
|
'''
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
Jenkins 대시보드에서 항목을 시작하려면 "New Item"을 선택해야 합니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
그런 다음 항목에 이름을 지정하고 파이프라인을 선택한 다음 확인을 누릅니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
일반 트리거나 빌드 트리거는 선택하지 않겠지만 흥미로운 일정과 기타 구성이 있을 수 있으므로 이 트리거를 사용해 보겠습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
마지막에 있는 Pipeline 탭에만 관심이 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
파이프라인 정의에서 위에 있는 파이프라인 스크립트를 스크립트 섹션에 복사하여 붙여 넣고 저장을 누릅니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
다음으로 페이지 왼쪽에서 "Build Now" 옵션을 선택합니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이제 1분 미만의 짧은 시간을 기다려야 합니다. Status 아래에 위에서 스크립트에서 정의한 단계가 표시됩니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
더 중요한 것은 이제 DockerHub로 이동하여 새 빌드가 있는지 확인하는 것입니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
전체적으로 파악하는 데 시간이 좀 걸렸지만, Minikube와 GitHub 및 DockerHub에 대한 액세스를 사용하여 누구나 실행할 수 있는 시나리오를 실습하고 작업하기 위해 계속 진행하려고 했습니다.
|
||||||
|
|
||||||
|
이 데모에 사용한 DockerHub 리포지토리는 비공개 리포지토리였습니다. 하지만 다음 섹션에서는 이러한 단계 중 일부를 발전시켜 단순히 `pwd`를 출력하고 몇 가지 테스트 및 빌드 단계를 실행하는 대신 무언가를 수행하도록 하고 싶습니다.
|
||||||
|
|
||||||
|
## 자료
|
||||||
|
|
||||||
|
- [Jenkins is the way to build, test, deploy](https://youtu.be/_MXtbjwsz3A)
|
||||||
|
- [Jenkins.io](https://www.jenkins.io/)
|
||||||
|
- [ArgoCD](https://argo-cd.readthedocs.io/en/stable/)
|
||||||
|
- [ArgoCD Tutorial for Beginners](https://www.youtube.com/watch?v=MeU5_k9ssrs)
|
||||||
|
- [What is Jenkins?](https://www.youtube.com/watch?v=LFDrDnKPOTg)
|
||||||
|
- [Complete Jenkins Tutorial](https://www.youtube.com/watch?v=nCKxl7Q_20I&t=3s)
|
||||||
|
- [GitHub Actions](https://www.youtube.com/watch?v=R8_veQiYBjI)
|
||||||
|
- [GitHub Actions CI/CD](https://www.youtube.com/watch?v=mFFXuXjVgkU)
|
||||||
|
|
||||||
|
[Day 74](day74.md)에서 봐요!
|
||||||
96
2022/ko/Days/day74.md
Normal file
96
2022/ko/Days/day74.md
Normal file
@ -0,0 +1,96 @@
|
|||||||
|
---
|
||||||
|
title: '#90DaysOfDevOps - Hello World - Jenkinsfile App Pipeline - Day 74'
|
||||||
|
published: false
|
||||||
|
description: 90DaysOfDevOps - Hello World - Jenkinsfile App Pipeline
|
||||||
|
tags: 'devops, 90daysofdevops, learning'
|
||||||
|
cover_image: null
|
||||||
|
canonical_url: null
|
||||||
|
id: 1048744
|
||||||
|
---
|
||||||
|
|
||||||
|
## Hello World - Jenkinsfile 앱 파이프라인
|
||||||
|
|
||||||
|
지난 섹션에서는 공개 GitHub 리포지토리에 있는 dockerfile에서 비공개 Dockerhub 리포지토리로 docker 이미지를 push하는 간단한 Jenkins 파이프라인을 구축했습니다.
|
||||||
|
|
||||||
|
이 섹션에서는 한 단계 더 나아가 간단한 애플리케이션을 통해 다음을 달성하고자 합니다.
|
||||||
|
|
||||||
|
### 목표
|
||||||
|
|
||||||
|
- Dockerfile (Hello World)
|
||||||
|
- Jenkinsfile
|
||||||
|
- GitHub 리포지토리가 업데이트될 때 트리거할 Jenkins 파이프라인
|
||||||
|
- GitHub 리포지토리를 소스로 사용
|
||||||
|
- Run - 리포지토리 복제/가져오기, 빌드, 테스트, 배포 단계
|
||||||
|
- 점진적인 버전 번호로 DockerHub에 배포
|
||||||
|
- Kubernetes 클러스터에 배포하는(여기에는 GitHub credentials를 사용하는 다른 job 및 매니페스트 리포지토리가 포함됨) Stretch Goal
|
||||||
|
|
||||||
|
### 1단계
|
||||||
|
|
||||||
|
[GitHub 리포지토리](https://github.com/MichaelCade/Jenkins-HelloWorld)가 있습니다. 여기에는 현재 Dockerfile과 index.html이 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
위에서 파이프라인에서 소스로 사용하던 것을 이제 해당 Jenkins 파이프라인 스크립트를 GitHub 리포지토리에도 추가하려고 합니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이제 Jenkins 대시보드로 돌아가서 새 파이프라인을 만들되, 스크립트를 붙여 넣는 대신 "Pipeline script from SCM"를 사용하고 아래의 구성 옵션을 사용하겠습니다.
|
||||||
|
|
||||||
|
참고로 리포지토리 URL은 `https://github.com/MichaelCade/Jenkins-HelloWorld.git`을 사용하겠습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이 시점에서 저장 및 적용을 누르면 수동으로 파이프라인을 실행하여 DockerHub 리포지토리에 업로드된 새 Docker 이미지를 빌드할 수 있습니다.
|
||||||
|
|
||||||
|
하지만 리포지토리 또는 소스 코드가 변경될 때마다 빌드를 트리거하도록 일정을 설정하고 싶습니다. webhooks를 사용하거나 예약 pull을 사용할 수 있습니다.
|
||||||
|
|
||||||
|
파이프라인을 유지하기 위해 값비싼 클라우드 리소스를 사용하고 있고 코드 저장소에 변경 사항이 많다면 많은 비용이 발생할 수 있으므로 이 점을 크게 고려해야 합니다. 이것이 데모 환경이라는 것을 알고 있기 때문에 "poll scm" 옵션을 사용하고 있습니다. (또한 Minikube를 사용하면 webhooks를 사용할 수 있는 기능이 부족하다고 생각합니다.)
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
어제 세션 이후 변경한 한 가지는 이제 이미지를 공개 저장소(이 경우 michaelcade1\90DaysOfDevOps)에 업로드하고 싶다는 것인데, 제 Jenkinsfile에는 이미 이 변경 사항이 있습니다. 그리고 이전 섹션에서 기존 데모 컨테이너 이미지를 모두 제거했습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
여기서 거꾸로 돌아가서 파이프라인을 생성한 다음 이전에 표시된 대로 구성을 추가했습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이 단계에서는 파이프라인이 실행되지 않았으며 스테이지 뷰는 다음과 같이 표시됩니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이제 "Build Now" 버튼을 트리거해 보겠습니다. 그러면 스테이지 뷰에 스테이지가 표시됩니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이제 DockerHub 리포지토리로 이동하면 2개의 새 Docker 이미지가 있어야 합니다. 빌드 ID는 1이고 최신 빌드가 있어야 하는데, 이는 "Upload to DockerHub"를 기반으로 생성하는 모든 빌드에 대해 Jenkins Build_ID 환경 변수를 사용하여 버전을 전송하고 최신 빌드도 발행하기 때문입니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이제 아래와 같이 깃허브 리포지토리에 index.html 파일을 업데이트해 보겠습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Jenkins로 돌아가서 "Build Now"를 다시 선택하면 됩니다. 2번 빌드가 성공했는지 확인해 보겠습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
그런 다음 DockerHub를 간단히 살펴보면 태그가 버전 2와 최신 태그가 있는 것을 볼 수 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
여기서 한 가지 주목할 점은, 제가 Kubernetes 클러스터에 액세스 및 인증을 통해 DockerHub로 도커 빌드를 push할 수 있는 시크릿을 추가했다는 것입니다. 이 과정을 따라하는 경우 계정에 대해 이 과정을 반복하고 내 리포지토리 및 계정과 연결된 Jenkins파일도 변경해야 합니다.
|
||||||
|
|
||||||
|
## 자료
|
||||||
|
|
||||||
|
- [Jenkins is the way to build, test, deploy](https://youtu.be/_MXtbjwsz3A)
|
||||||
|
- [Jenkins.io](https://www.jenkins.io/)
|
||||||
|
- [ArgoCD](https://argo-cd.readthedocs.io/en/stable/)
|
||||||
|
- [ArgoCD Tutorial for Beginners](https://www.youtube.com/watch?v=MeU5_k9ssrs)
|
||||||
|
- [What is Jenkins?](https://www.youtube.com/watch?v=LFDrDnKPOTg)
|
||||||
|
- [Complete Jenkins Tutorial](https://www.youtube.com/watch?v=nCKxl7Q_20I&t=3s)
|
||||||
|
- [GitHub Actions](https://www.youtube.com/watch?v=R8_veQiYBjI)
|
||||||
|
- [GitHub Actions CI/CD](https://www.youtube.com/watch?v=mFFXuXjVgkU)
|
||||||
|
|
||||||
|
[Day 75](day75.md)에서 봐요!
|
||||||
188
2022/ko/Days/day75.md
Normal file
188
2022/ko/Days/day75.md
Normal file
@ -0,0 +1,188 @@
|
|||||||
|
---
|
||||||
|
title: '#90DaysOfDevOps - GitHub Actions Overview - Day 75'
|
||||||
|
published: false
|
||||||
|
description: 90DaysOfDevOps - GitHub Actions Overview
|
||||||
|
tags: 'devops, 90daysofdevops, learning'
|
||||||
|
cover_image: null
|
||||||
|
canonical_url: null
|
||||||
|
id: 1049070
|
||||||
|
---
|
||||||
|
|
||||||
|
## GitHub Actions 개요
|
||||||
|
|
||||||
|
이 섹션에서는 방금 시간을 할애한 것과는 다른 접근 방식을 살펴보고자 합니다. 이 세션에서 집중적으로 다룰 내용은 GitHub Actions입니다.
|
||||||
|
|
||||||
|
GitHub Actions는 파이프라인의 다른 작업들 사이에서 빌드, 테스트 및 배포할 수 있는 CI/CD 플랫폼입니다. 이 플랫폼은 GitHub 리포지토리를 대상으로 빌드하고 테스트하는 Wolkflow의 개념을 가지고 있습니다. 또한 GitHub Actions를 사용하여 리포지토리 내에서 발생하는 Event를 기반으로 다른 Wolkflow를 구동할 수도 있습니다.
|
||||||
|
|
||||||
|
### Wolkflow
|
||||||
|
|
||||||
|
전반적으로 GitHub Actions에서는 작업을 **Wolkflow**라고 부릅니다.
|
||||||
|
|
||||||
|
- **Wolkflow**는 구성 가능한 자동화된 프로세스입니다.
|
||||||
|
- YAML 파일로 정의됩니다.
|
||||||
|
- 하나 이상의 **Job**을 포함하고 실행합니다.
|
||||||
|
- 리포지토리의 **Event**에 의해 트리거될 때 실행되거나 수동으로 실행할 수 있습니다.
|
||||||
|
- 리포지토리당 여러 Wolkflow를 사용할 수 있습니다.
|
||||||
|
- **Wolkflow**에는 **Job**과 해당 **Job**을 달성하기 위한 **Step**이 포함됩니다.
|
||||||
|
- **Wolkflow** 내에는 **Wolkflow**가 실행되는 **Runner**도 있습니다.
|
||||||
|
|
||||||
|
예를 들어 PR을 빌드하고 테스트하는 **Wolkflow**, 릴리스가 만들어질 때마다 애플리케이션을 배포하는 **Wolkflow**, 누군가 새 issue를 열 때마다 레이블을 추가하는 또 다른 **Wolkflow**가 있을 수 있습니다.
|
||||||
|
|
||||||
|
### Event
|
||||||
|
|
||||||
|
Event는 Wolkflow를 실행하도록 트리거하는 리포지토리의 특정 이벤트입니다.
|
||||||
|
|
||||||
|
### Job
|
||||||
|
|
||||||
|
Job은 Runner에서 실행되는 Wolkflow의 Step 집합입니다.
|
||||||
|
|
||||||
|
### Step
|
||||||
|
|
||||||
|
Job 내의 각 Ste은 실행되는 shell 스크립트 또는 Action이 될 수 있습니다. Step은 순서대로 실행되며 서로 종속됩니다.
|
||||||
|
|
||||||
|
### Action
|
||||||
|
|
||||||
|
자주 반복되는 작업에는 반복 가능한 사용자 지정 애플리케이션이 사용됩니다.
|
||||||
|
|
||||||
|
### Runner
|
||||||
|
|
||||||
|
Runner는 Wolkflow를 실행하는 서버로, 각 Runner는 한 번에 하나의 작업을 실행합니다. GitHub Actions는 Ubuntu Linux, Microsoft Windows 및 macOS Runner를 실행할 수 있는 기능을 제공합니다. 특정 OS 또는 하드웨어에서 직접 호스팅할 수도 있습니다.
|
||||||
|
|
||||||
|
아래에서 Wolkflow를 트리거하는 Event > Wolkflow가 두 개의 Job으로 구성 > 작업 내에 단계와 액션이 있는 모습을 볼 수 있습니다.
|
||||||
|
|
||||||
|
아래에서 Wolkflow를 트리거하는 Event가 있고 > Wolkflow가 두 개의 Job으로 구성되어 있으며 > Job 내에 Step가 있고 > Action이 있는 것을 볼 수 있습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
### YAML
|
||||||
|
|
||||||
|
실제 사용 사례를 살펴보기 전에 위의 이미지를 예제 YAML 파일 형태로 간단히 살펴봅시다.
|
||||||
|
|
||||||
|
주석을 추가하여 YAML Wolkflow의 구성 요소를 찾을 수 있도록 했습니다.
|
||||||
|
|
||||||
|
```Yaml
|
||||||
|
#Workflow
|
||||||
|
name: 90DaysOfDevOps
|
||||||
|
#Event
|
||||||
|
on: [push]
|
||||||
|
#Jobs
|
||||||
|
jobs:
|
||||||
|
check-bats-version:
|
||||||
|
#Runner
|
||||||
|
runs-on: ubuntu-latest
|
||||||
|
#Steps
|
||||||
|
steps:
|
||||||
|
#Actions
|
||||||
|
- uses: actions/checkout@v2
|
||||||
|
- uses: actions/setup-node@v2
|
||||||
|
with:
|
||||||
|
node-version: '14'
|
||||||
|
- run: npm install -g bats
|
||||||
|
- run: bats -v
|
||||||
|
```
|
||||||
|
|
||||||
|
### GitHub Actions 실습하기
|
||||||
|
|
||||||
|
코드 빌드, 테스트, 배포 및 그 이후의 지속적인 단계와 관련하여 CI/CD 요구 사항을 충족할 수 있는 GitHub Actions에는 많은 옵션이 있다고 생각합니다.
|
||||||
|
|
||||||
|
GitHub Actions를 사용할 수 있는 많은 옵션과 기타 자동화된 작업을 볼 수 있습니다.
|
||||||
|
|
||||||
|
### 코드 lint에 GitHub 액션 사용하기
|
||||||
|
|
||||||
|
한 가지 옵션은 리포지토리 내에서 코드를 깨끗하고 깔끔하게 정리하는 것입니다. 이것이 첫 번째 예제 데모가 될 것입니다.
|
||||||
|
|
||||||
|
이 섹션의 리소스 중 하나에 링크된 몇 가지 예제 코드를 사용하여 `GitHub/super-linter`를 사용하여 코드를 확인하겠습니다.
|
||||||
|
|
||||||
|
```Yaml
|
||||||
|
name: Super-Linter
|
||||||
|
|
||||||
|
on: push
|
||||||
|
|
||||||
|
jobs:
|
||||||
|
super-lint:
|
||||||
|
name: Lint code base
|
||||||
|
runs-on: ubuntu-latest
|
||||||
|
steps:
|
||||||
|
- name: Checkout code
|
||||||
|
uses: actions/checkout@v2
|
||||||
|
|
||||||
|
- name: Run Super-Linter
|
||||||
|
uses: github/super-linter@v3
|
||||||
|
env:
|
||||||
|
DEFAULT_BRANCH: main
|
||||||
|
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||||
|
```
|
||||||
|
|
||||||
|
**github/super-linter**
|
||||||
|
위에서 단계 중 하나에 GitHub/super-linter라는 Action이 있으며 이는 커뮤니티에서 이미 작성된 Step을 참조하고 있음을 알 수 있습니다. 이에 대한 자세한 내용은 [Super-Linter](https://github.com/github/super-linter)에서 확인할 수 있습니다.
|
||||||
|
|
||||||
|
"이 리포지토리는 super-linter를 실행하기 위한 Github Actions를 위한 저장소입니다. 소스 코드의 유효성을 검사하는 데 도움이 되도록 bash로 작성된 다양한 linter의 간단한 조합입니다."
|
||||||
|
|
||||||
|
또한 위의 코드 스니펫에 GITHUB_TOKEN이 언급되어 있어서 이것이 왜 필요한지, 어떤 용도로 사용되는지 궁금했습니다.
|
||||||
|
|
||||||
|
"참고: Wolkflow에서 환경 변수 `GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}`을 전달하면 GitHub Super-Linter가 PR의 Checks 섹션에 각 linter 실행 상태를 표시합니다. 이 기능이 없으면 전체 실행의 전체 상태만 볼 수 있습니다. **GitHub Secret은 GitHub에서 자동으로 설정하므로 설정할 필요가 없으며, Action으로 전달하기만 하면 됩니다.**"
|
||||||
|
|
||||||
|
굵은 텍스트는 이 단계에서 주목해야 할 중요한 부분입니다. 우리는 이 기능을 사용하지만, 리포지토리 내에서 환경 변수를 설정할 필요는 없습니다.
|
||||||
|
|
||||||
|
테스트할 리포지토리는 Jenkins 데모에서 사용한 리포지토리를 사용하겠습니다. [Jenkins-HelloWorld](https://github.com/MichaelCade/Jenkins-HelloWorld).
|
||||||
|
|
||||||
|
다음은 Jenkins 세션에 남겨둔 저장소입니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이 기능을 활용하려면 위의 Actions 탭을 사용하여 곧 다룰 마켓플레이스에서 선택하거나 위의 super-linter 코드를 사용하여 파일을 생성할 수 있는데, 직접 생성하려면 리포지토리에 이 위치에 새 파일을 만들어야 합니다. `.github/workflows/workflow_name`은 분명히 여러분이 알아볼 수 있는 유용한 이름이어야 하며, 여기에는 리포지토리에 대해 다양한 작업과 작업을 수행하는 다양한 Wolkflow가 있을 수 있습니다.
|
||||||
|
|
||||||
|
`.github/workflows/super-linter.yml`을 생성하겠습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이제 코드를 붙여 넣고 리포지토리에 코드를 커밋한 다음 Actions 탭으로 이동하면 아래와 같은 super-linter Wolkflow가 표시됩니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
코드에서 리포지토리에 무언가를 push할 때 이 Wolkflow가 실행되도록 정의했기 때문에, super-linter.yml을 리포지토리에 push할 때 Wolkflow가 트리거되었습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
위에서 보시다시피 해킹 능력과 코딩 능력에 따라 몇 가지 오류가 발생했습니다.
|
||||||
|
|
||||||
|
적어도 아직은 제 코드는 아니었지만, 이 코드를 실행하고 오류가 발생했을 때 이 [문제](https://github.com/github/super-linter/issues/2255)를 발견했습니다.
|
||||||
|
|
||||||
|
2번 super-linter의 버전을 버전 3에서 4로 변경하고 작업을 다시 실행했습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
예상대로 해커 코딩에서 몇 가지 문제가 발생했으며 여기 [Wolkflow](https://github.com/MichaelCade/Jenkins-HelloWorld/runs/5600278515?check_suite_focus=true)에서 확인할 수 있습니다.
|
||||||
|
|
||||||
|
Wolkflow 내에서 무언가가 실패하거나 오류를 보고했을 때 리포지토리에 표시되는 모습을 지금 보여주고 싶었습니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
이제 제 코드에서 문제를 해결하고 변경 사항을 적용하면 Wolkflow가 다시 실행됩니다(이미지에서 'bugs'를 해결하는 데 시간이 걸린 것을 볼 수 있습니다.) 파일을 삭제하는 것은 권장되지 않지만, 문제가 해결되었음을 보여주는 매우 빠른 방법입니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
위에 강조 표시된 new Wolkflow 버튼을 누르면 수많은 작업의 문이 열립니다. 이번 챌린지를 진행하면서 눈치채셨겠지만, 저희는 거인의 어깨 위에 서서 코드, 자동화 및 기술을 널리 공유하여 삶을 더 편하게 만들고자 하는 것이 아닙니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Wolkflow가 성공했을 때 리포지토리의 녹색 체크 표시를 보여드리지 못했네요.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
지금까지는 GitHub Actions의 기본적인 관점에 대해 설명했지만, 저와 같은 분이라면 GitHub Actions를 사용하여 많은 작업을 자동화할 수 있는 다른 방법을 알고 계실 것입니다.
|
||||||
|
|
||||||
|
다음에는 CD의 또 다른 영역인 애플리케이션을 환경에 배포하기 위해 ArgoCD를 살펴볼 것입니다.
|
||||||
|
|
||||||
|
## 자료
|
||||||
|
|
||||||
|
- [Jenkins is the way to build, test, deploy](https://youtu.be/_MXtbjwsz3A)
|
||||||
|
- [Jenkins.io](https://www.jenkins.io/)
|
||||||
|
- [ArgoCD](https://argo-cd.readthedocs.io/en/stable/)
|
||||||
|
- [ArgoCD Tutorial for Beginners](https://www.youtube.com/watch?v=MeU5_k9ssrs)
|
||||||
|
- [What is Jenkins?](https://www.youtube.com/watch?v=LFDrDnKPOTg)
|
||||||
|
- [Complete Jenkins Tutorial](https://www.youtube.com/watch?v=nCKxl7Q_20I&t=3s)
|
||||||
|
- [GitHub Actions](https://www.youtube.com/watch?v=R8_veQiYBjI)
|
||||||
|
- [GitHub Actions CI/CD](https://www.youtube.com/watch?v=mFFXuXjVgkU)
|
||||||
|
|
||||||
|
[Day 76](day76.md)에서 봐요!
|
||||||
83
2022/ko/Days/day76.md
Normal file
83
2022/ko/Days/day76.md
Normal file
@ -0,0 +1,83 @@
|
|||||||
|
---
|
||||||
|
title: '#90DaysOfDevOps - ArgoCD Overview - Day 76'
|
||||||
|
published: false
|
||||||
|
description: 90DaysOfDevOps - ArgoCD Overview
|
||||||
|
tags: 'devops, 90daysofdevops, learning'
|
||||||
|
cover_image: null
|
||||||
|
canonical_url: null
|
||||||
|
id: 1048809
|
||||||
|
---
|
||||||
|
|
||||||
|
## ArgoCD 개요
|
||||||
|
|
||||||
|
"Argo CD는 Kubernetes를 위한 선언적 GitOps 지속적 배포 도구입니다."
|
||||||
|
|
||||||
|
버전 제어가 핵심입니다. 환경을 즉석에서 변경했는데 그 변경 사항을 기억하지 못하고 불이 켜져 있고 모든 것이 초록색이기 때문에 계속 진행했던 적이 있으신가요? 변경을 시도했다가 모든 것 또는 일부가 망가진 적이 있나요? 변경한 사실을 알았다면 잘못된 스크립트나 맞춤법 오류를 빠르게 되돌릴 수 있을 것입니다. 하지만 대규모로 변경을 진행하다 보니 본인도 몰랐을 수도 있고, 바로 발견하지 못해 비즈니스가 어려움을 겪고 있을 수도 있습니다. 따라서 버전 관리가 중요합니다. 뿐만 아니라 "애플리케이션 정의, 구성 및 환경은 선언적이어야 하며 버전 관리가 이루어져야 합니다." 이 외에도 "애플리케이션 배포 및 수명 주기 관리는 자동화되고, 감시 가능하며, 이해하기 쉬워야 한다"고 언급합니다.
|
||||||
|
|
||||||
|
운영 배경을 가지고 있지만 IaC로 사용하는 데 많은 경험을 쌓은 저로서는 지속적인 배포/제공 워크플로우를 통해 이 모든 좋은 것들을 처리할 수 있는 다음 단계라고 생각합니다.
|
||||||
|
|
||||||
|
[ArgoCD란](https://argo-cd.readthedocs.io/en/stable/)
|
||||||
|
|
||||||
|
### ArgoCD 배포
|
||||||
|
|
||||||
|
이번 배포에서는 신뢰할 수 있는 Minikube Kubernetes 클러스터를 다시 로컬로 사용할 것입니다.
|
||||||
|
|
||||||
|
```Shell
|
||||||
|
kubectl create namespace argocd
|
||||||
|
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
|
||||||
|
```
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
`kubectl get pods -n argocd`로 모든 ArgoCD pod가 실행되고 있는지 확인합니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
또한, `kubectl get all -n argocd`로 네임스페이스에 배포한 모든 것을 확인해봅시다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
위의 내용이 정상적으로 보이면 포트 포워드를 통해 접근하는 것을 고려해야 합니다. 새 터미널에서 `kubectl port-forward svc/argocd-server -n argocd 8080:443` 명령을 사용합니다.
|
||||||
|
|
||||||
|
그런 다음 새 웹 브라우저를 열고 `https://localhost:8080`로 이동합니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
로그인하려면 관리자 사용자 이름이 필요하며, 생성한 암호를 비밀번호로 사용하려면 `kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d && echo`를 사용합니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
로그인하면 비어있는 CD 캔버스가 표시됩니다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
### 애플리케이션 배포
|
||||||
|
|
||||||
|
이제 ArgoCD를 실행하고 실행 중이므로 이제 Helm뿐만 아니라 Git 리포지토리에서 애플리케이션을 배포하는 데 사용할 수 있습니다.
|
||||||
|
|
||||||
|
제가 배포하고자 하는 애플리케이션은 Pac-Man입니다. 네, Pac-Man은 유명한 게임이자 데이터 관리와 관련하여 많은 데모에서 사용하는 게임이며, 우리가 Pac-Man을 보는 것은 이번이 마지막이 아닐 것입니다.
|
||||||
|
|
||||||
|
[Pac-Man](https://github.com/MichaelCade/pacman-tanzu.git)의 리포지토리는 여기에서 찾을 수 있습니다.
|
||||||
|
|
||||||
|
스크린샷을 사용하여 각 단계를 설명하는 대신, 이 특정 애플리케이션 배포를 위해 수행한 단계를 다루는 연습 동영상을 만드는 것이 더 쉬울 것이라고 생각했습니다.
|
||||||
|
|
||||||
|
[ArgoCD 데모 - 90일간의 개발 운영](https://www.youtube.com/watch?v=w6J413_j0hA)
|
||||||
|
|
||||||
|
참고 - 영상 중 앱 상태가 정상인데도 만족스럽지 않은 서비스가 있는데, 이는 Pac-Man 서비스에 대해 설정된 로드밸런서 유형이 보류 중이고, Minikube에는 로드밸런서가 구성되지 않았기 때문입니다. 이 문제를 테스트하고 싶으시다면 서비스에 대한 YAML을 ClusterIP로 변경하고 포트 포워딩을 사용하여 게임을 플레이할 수 있습니다.
|
||||||
|
|
||||||
|
이것으로 CICD 파이프라인 섹션을 마칩니다. 현재 업계에서 이 영역에 많은 관심이 집중되고 있으며, 일반적으로 CICD 내에서 사용되는 방법론과 관련된 GitOps 관련 용어도 듣게 될 것입니다.
|
||||||
|
|
||||||
|
다음 섹션에서는 새로운 개념은 아니지만 환경을 다르게 바라보면서 점점 더 중요해지고 있는 또 다른 개념 또는 영역인 Observability에 대해 살펴봅니다.
|
||||||
|
|
||||||
|
## 자료
|
||||||
|
|
||||||
|
- [Jenkins is the way to build, test, deploy](https://youtu.be/_MXtbjwsz3A)
|
||||||
|
- [Jenkins.io](https://www.jenkins.io/)
|
||||||
|
- [ArgoCD](https://argo-cd.readthedocs.io/en/stable/)
|
||||||
|
- [ArgoCD Tutorial for Beginners](https://www.youtube.com/watch?v=MeU5_k9ssrs)
|
||||||
|
- [What is Jenkins?](https://www.youtube.com/watch?v=LFDrDnKPOTg)
|
||||||
|
- [Complete Jenkins Tutorial](https://www.youtube.com/watch?v=nCKxl7Q_20I&t=3s)
|
||||||
|
- [GitHub Actions](https://www.youtube.com/watch?v=R8_veQiYBjI)
|
||||||
|
- [GitHub Actions CI/CD](https://www.youtube.com/watch?v=mFFXuXjVgkU)
|
||||||
|
|
||||||
|
[Day 77](day77.md)에서 봐요!
|
||||||
Loading…
Reference in New Issue
Block a user