woose/90DaysOfDevOps
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch 'MichaelCade:main' into main

Browse Source
This commit is contained in:
Mau Ha Quang 2023-05-04 10:22:26 +09:00 committed by GitHub
commit 4b755f9b90
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
108 changed files with 10649 additions and 33 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

BIN
.DS_Store vendored Normal file
View File

Binary file not shown.

2
2022/Days/day34.md
View File

@ -179,7 +179,7 @@ Following [Module 09a](https://microsoftlearning.github.io/AZ-104-MicrosoftAzure
- Task 6: Configure and test autoscaling of the Azure web app
This script I am using can be found in (Cloud/05Serverless)
This script I am using can be found in (Cloud/04Serverless)
![](Images/Day34_Cloud36.png)

4
2022/Days/day55.md
View File

@ -102,7 +102,7 @@ We also have two other types of volumes that we will not get into detail on but
In the session yesterday we walked through creating a stateless application, here we want to do the same but we want to use our minikube cluster to deploy a stateful workload.
A recap on the minikube command we are using to have the capability and addons to use persistence is `minikube start --addons volumesnapshots,csi-hostpath-driver --apiserver-port=6443 --container-runtime=containerd -p mc-demo --Kubernetes-version=1.21.2`
A recap on the minikube command we are using to have the capability and addons to use persistence is `minikube start --addons volumesnapshots,csi-hostpath-driver --apiserver-port=6443 --container-runtime=containerd -p mc-demo --kubernetes-version=1.21.2`
This command uses the CSI-hostpath-driver which is what gives us our storageclass, something I will show later.
@ -208,7 +208,7 @@ We can then create this in our ingress namespace with `kubectl create -f Pacman-
![](Images/Day55_Kubernetes15.png)
Then if we run `kubectl get ingress -n Pacman
Then if we run `kubectl get ingress -n Pacman`
![](Images/Day55_Kubernetes16.png)

86
2022/ko/Days/day05.md Normal file
View File

@ -0,0 +1,86 @@
---
title: '#90DaysOfDevOps - Plan > Code > Build > Testing > Release > Deploy > Operate > Monitor > - Day 5'
published: false
description: 90DaysOfDevOps - Plan > Code > Build > Testing > Release > Deploy > Operate > Monitor >
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048830
---
## 계획 > 코드 작성 > 빌드 > 테스트 > 릴리즈 > 배포 > 운영 > 모니터링 >
오늘은 데브옵스 환경에서 애플리케이션의 시작부터 끝까지 개별 단계와 continuous cycle에 대해 집중적으로 살펴보겠습니다.
![DevOps](/2022/Days/Images/Day5_DevOps8.png)
### 계획
개발팀이 다음 스프린트에서 출시할 기능과 버그 수정을 결정하는 계획 프로세스는 데브옵스 엔지니어가 참여하여, 앞으로 어떤 일이 발생할지 파악하고 개발팀의 결정이나 경로에 영향을 미치고, 그들이 구축한 인프라로 작업하도록 돕거나 그들이 다른 경로를 따를 경우 더 나은 방향으로 안내할 수 있는 기회입니다. 중요한 점은 개발자나 소프트웨어 엔지니어링 팀이 데브옵스 엔지니어의 고객이 되므로, 고객이 나쁜 방향으로 가기 전에 고객과 협력할 수 있는 기회라는 것입니다.
### 코드 작성
이제 계획 세션을 마치고 코드 작성 단계에 진입합니다. 이 단계에서 당신이 참여할 수 있는 역할 중 하나는 코드를 작성하는 동안 인프라에 대한 이해도를 높여서 어떤 서비스를 사용할 수 있는지, 그 서비스와 어떻게 상호작용할 수 있는지를 더 잘 이해할 수 있도록 돕는 것입니다. 또한, 코드 작성이 완료되면 해당 코드를 리포지토리에 병합하는 일도 중요한 역할입니다.
### 빌드
여기에서는 자동화 프로세스의 첫 번째로, 코드를 가져와서 사용하는 언어에 따라 변환하거나 컴파일하거나 해당 코드에서 도커 이미지를 생성할 수 있기 때문에, CI 파이프라인을 사용하여 이러한 프로세스를 자동화할 것입니다. 이렇게 함으로써, 코드를 변경하거나 새 코드를 추가할 때마다 일일이 수동으로 작업하는 것이 아니라, 자동화된 프로세스를 통해 더욱 효율적이고 일관성 있는 작업을 수행할 수 있게 됩니다.
## 테스트
빌드가 완료되면 몇 가지 테스트를 실행합니다. 개발 팀은 보통 어떤 테스트를 작성할지 제안할 수 있지만, 이를 실행해야 합니다. 테스트는 프로덕션에 문제가 발생하지 않도록 최소화하기 위한 시도입니다. 새로운 버그가 발생하지 않도록 보장하는 것은 불가능하지만, 최대한 이전에 작동하던 것이 깨지지 않도록 보장하기 위해 노력합니다.
## 릴리즈
테스트가 모두 통과되면, 애플리케이션 유형에 따라 릴리스 프로세스가 수행됩니다. 하지만 이 단계는 작업 중인 애플리케이션에 따라 생략될 수도 있습니다. 일반적으로, GitHub 리포지토리나 git 리포지토리에서 가져온 코드나 빌드된 도커 이미지를 프로덕션 서버에 배포하기 위해 레지스트리나 리포지토리에 저장합니다. 이를 통해 배포 프로세스가 진행됩니다.
## 배포
배포는 모든 개발과정의 최종 단계이기 때문에, 프로덕션 환경에 코드를 적용하는 과정입니다. 이 단계에서 비즈니스에서는 여러분과 소프트웨어 엔지니어링 팀이 지금까지 이 제품에 투자한 모든 시간과 노력의 가치를 실현할 수 있습니다.
## 운영
한 번 배포가 완료되면, 해당 제품이 운영되기 시작하게 됩니다. 운영에는 고객이 사이트나 애플리케이션을 사용할 때 발생하는 문제를 파악하고, 이에 대한 대처 방안을 마련하는 것이 포함됩니다. 예를 들어, 사이트가 느리게 실행되는 문제가 발생하면, 운영팀은 이유를 파악하고 피크 기간 동안은 서버 수를 늘리고, 사용량이 적은 기간에는 서버 수를 줄이는 자동 확장 기능을 구축할 수 있습니다. 또한, 운영 유형 메트릭 처리와 같은 다양한 작업도 수행됩니다. 가능한 경우에는 이러한 작업을 자동화하는 것이 좋습니다. 그러나, 몇 가지 단계를 수행해야 하는 환경에서는 자동화가 어려울 수도 있습니다. 그런 경우에는 가능한 한 자동화를 시도하면서도, 일부 작업을 수동으로 처리해야 할 수도 있습니다. 그리고, 자동화 프로세스에서는 운영팀이 배포가 발생했음을 알 수 있도록 몇 가지 유형의 알림을 포함하는 것이 좋습니다.
## 모니터링
위의 모든 부분이 마지막 단계로 이어지는데, 특히 운영 문제 자동 확장 문제 해결과 관련된 모니터링이 필요하기 때문입니다.
문제가 있다는 것을 알려주는 모니터링이 없다면 문제가 있는 것이므로 메모리 사용률 CPU 사용률 디스크 공간, API 엔드포인트, 응답 시간, 엔드포인트가 얼마나 빨리 응답하는지 등을 모니터링할 수 있으며, 이 중 큰 부분은 로그입니다. 개발자는 로그를 통해 프로덕션 시스템에 액세스하지 않고도 무슨 일이 일어나고 있는지 확인할 수 있습니다.
## 다듬기 & 반복
여태까지 수행한 프로세스를 검토하고 개선할 부분을 찾습니다. 그리고 이를 바탕으로 다시 계획 단계로 돌아가 전체 과정을 재진행합니다. 이는 지속적인 개선과 반복적인 프로세스 개선을 위한 사이클을 형성하며, 더 나은 제품과 높은 품질의 서비스를 제공하기 위한 필수적인 단계입니다.
## Continuous
여러 도구들이 지속적인 프로세스를 달성하는 데 도움을 줍니다. 이 모든 코드와 클라우드 인프라 또는 모든 환경을 완전히 자동화하는 것이 궁극적인 목표이며, 이를 지속적 통합/지속적 배포/지속적 배포 또는 줄여서 "CI/CD"로 설명하기도 합니다. 이번에는 90일 후에 CI/CD에 대한 기본 사항을 예제와 함께 배울 수 있는 워크숍을 제공할 예정입니다.
### Continuous Delivery
Continuous Delivery = 계획 > 코드 작성 > 빌드 > 테스트
### Continuous Integration
이는 위에서 설명한 지속적 배포 단계와 릴리스 단계의 결과를 합친 것입니다. 이 단계는 성공과 실패 모두에 해당하며, 지속적 배포를 통해 피드백을 받거나 지속적 배포로 진행될 수 있습니다.
Continuous Integration = 계획 > 코드 > 빌드 > 테스트 > 릴리즈
### Continuous Deployment
성공적인 CI 릴리스 후, CD 단계로 이동합니다.
성공적인 CI 릴리즈 = Continuous Deployment = 배포 > 운영 > 모니터링
위의 세 가지 개념은 데브옵스 라이프사이클의 각 단계를 간단히 정리한 것으로 볼 수 있습니다.
이전에 다룬 Day 3 를 약간 요약했었지만, 이제는 더 이해하기 쉬워진 것 같습니다.
### 자료
- [DevOps for Developers – Software or DevOps Engineer?](https://www.youtube.com/watch?v=a0-uE3rOyeU)
- [Techworld with Nana -DevOps Roadmap 2022 - How to become a DevOps Engineer? What is DevOps?](https://www.youtube.com/watch?v=9pZ2xmsSDdo&t=125s)
- [How to become a DevOps Engineer in 2021 - DevOps Roadmap](https://www.youtube.com/watch?v=5pxbp6FyTfk)
여기까지 왔다면 이 여정이 자신이 찾던 여정인지 아닌지를 판단할 수 있을 것입니다.
[Day 6](day06.md)에서 봐요!

75
2022/ko/Days/day06.md Normal file
View File

@ -0,0 +1,75 @@
---
title: '#90DaysOfDevOps - DevOps - The real stories - Day 6'
published: false
description: 90DaysOfDevOps - DevOps - The real stories
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048855
---
## 데브옵스 - 실제 사례
처음에는 넷플릭스나 포춘지 선정 500대 기업처럼 데브옵스를 실행하는 기업이 없었기 때문에 많은 사람들이 데브옵스를 쉽게 접하기 어려웠습니다. 그러나 현재는 많은 기업이 데브옵스를 도입하면서, 데브옵스가 점차 일상적인 개발 방법으로 자리 잡게 되었다고 생각합니다.
뒤에 나올 예시를 통해 다양한 산업과 업종에서 DevOps를 적용하고 있으며, 이로 인해 비즈니스의 목표 달성에 큰 긍정적인 영향을 미치고 있다는 것을 알 수 있습니다.
여기서 가장 중요한 이점은 데브옵스를 올바르게 수행하면, 비즈니스의 소프트웨어 개발 속도와 품질을 개선하는 데 큰 도움이 된다는 것입니다.
저는 오늘 이 자리를 통해, 데브옵스를 성공적으로 도입한 기업들의 사례를 살펴보고 이와 관련된 몇 가지 리소스를 공유하고자 합니다. 이 자리는 여러분들이 함께 참여하여, 서로 도움을 주고받을 수 있는 좋은 기회가 될 것입니다. 여러분의 비즈니스에 데브옵스 문화를 도입하셨나요? 그렇다면, 성공적이었나요?
앞서 언급한 넷플릭스는 매우 좋은 사례이며, 오늘날 우리가 일반적으로 볼 수 있는 것들과 비교하면 상당히 발전된 모델입니다. 그러나, 성공하고 있는 다른 대형 브랜드들에 대해서도 언급하고자 합니다.
## Amazon
2010년에 아마존은 물리적 서버 공간을 AWS(Amazon Web Services) 클라우드로 이전하여, 아주 작은 단위로 용량을 확장하거나 축소함으로써 리소스를 절약할 수 있게 되었습니다. 이를 통해 아마존은 리테일 지점을 운영하면서 뿐만 아니라, AWS 자체적으로도 높은 수익을 창출하게 되었다는 사실도 알려져 있습니다.
아마존은 2011년에 (자료를 통해 확인할 수 있는 바와 같이) 지속적인 배포 프로세스를 채택하여, 개발자가 원할 때 필요한 서버에 코드를 배포할 수 있게 되었습니다. 이를 통해 아마존은 새로운 소프트웨어를 평균 11.6초 만에 프로덕션 서버에 배포할 수 있게 되었습니다!
## Netflix
넷플릭스를 사용하지 않는 사람이 있을까요? 그들은 고품질의 스트리밍 서비스를 제공하며, 개인적으로도 훌륭한 사용자 경험을 제공합니다.
사용자 경험이 왜 그렇게 좋을까요? 글쎄요, 기억에 남는 결함 없이 서비스를 제공하려면 속도, 유연성, 품질에 대한 관심이 필요합니다.
넷플릭스 개발자는 IT 운영에 의존하지 않고도 배포 가능한 웹 이미지로 코드를 자동으로 빌드할 수 있습니다. 이미지가 업데이트되면 맞춤형으로 구축된 웹 기반 플랫폼을 사용하여 넷플릭스 인프라에 통합됩니다.
이미지 배포에 실패하면, 롤백 되어 이전 버전으로 트래픽이 다시 라우팅 되도록 지속적인 모니터링이 이루어집니다.
Netflix 팀 내에서 수행해야 할 일과 수행하지 말아야 할 일에 대해 자세히 설명하는 훌륭한 강연이 뒤에 있습니다.
## Etsy
많은 회사에서는 배포가 느리고 고통스러워서 어려움을 겪는 경우가 많습니다. 이와 관련하여, 많은 팀이 사일로에 갇혀 협력하지 못하는 문제가 있습니다.
Amazon과 Netflix에 관한 글을 읽으면서 알게 된 것 중 하나는, Etsy가 2009년 말에 이미 개발자가 코드를 배포할 수 있도록 해뒀을 가능성이 높다는 것입니다. 이는 다른 두 회사보다 훨씬 앞선 시기였습니다. (흥미로운 사실이죠!)
더 흥미로운 점은, 개발자가 배포 책임감을 느낄 때 애플리케이션 성능, 가동 시간 및 기타 목표에 대한 책임감도 함께 갖게 된다는 것을 깨달았다는 것입니다.
학습 문화는 데브옵스의 핵심적인 부분입니다. 실패를 통해 교훈을 얻는다면, 실패도 성공으로 이어질 수 있다는 내용은 인용된 것 같지만, 어느 정도 일리가 있는 것 같습니다!
일부 대규모 기업에서는 데브옵스가 판도를 바꾼 다른 사례도 뒤에 추가했습니다.
## 자료
- [How Netflix Thinks of DevOps](https://www.youtube.com/watch?v=UTKIT6STSVM)
- [16 Popular DevOps Use Cases & Real Life Applications [2021]](https://www.upgrad.com/blog/devops-use-cases-applications/)
- [DevOps: The Amazon Story](https://www.youtube.com/watch?v=ZzLa0YEbGIY)
- [How Etsy makes DevOps work](https://www.networkworld.com/article/2886672/how-etsy-makes-devops-work.html)
- [Adopting DevOps @ Scale Lessons learned at Hertz, Kaiser Permanente and lBM](https://www.youtube.com/watch?v=gm18-gcgXRY)
- [Interplanetary DevOps at NASA JPL](https://www.usenix.org/conference/lisa16/technical-sessions/presentation/isla)
- [Target CIO explains how DevOps took root inside the retail giant](https://enterprisersproject.com/article/2017/1/target-cio-explains-how-devops-took-root-inside-retail-giant)
### 데브옵스에 대해 살펴본 첫 며칠의 요약
- 데브옵스는 전체 애플리케이션 개발 라이프사이클인 **개발**, **테스트**, **배포**, **운영**을 단일 팀이 관리할 수 있도록 하는 개발과 운영의 조합입니다.
- 데브옵스의 주요 초점과 목표는 개발 라이프사이클을 단축하면서도 비즈니스 목표와 긴밀하게 연계하여 기능 및 수정 사항을 자주 제공하는 것입니다.
- 데브옵스는 소프트웨어를 안정적이고 신속하게 배포하고 개발할 수 있는 소프트웨어 개발 접근 방식으로, 이를 **지속적인 개발, 테스트, 배포, 모니터링**이라고도 합니다.
여기까지 왔다면 이 여정이 자신이 찾던 여정인지 아닌지를 판단할 수 있을 것입니다. [Day 7](day07.md)에 뵙겠습니다.
Day 7 에서는 개발자가 되는 것이 목표가 아니라, 개발자들이 하는 일을 이해할 수 있도록 프로그래밍 언어에 대해 알아보게 됩니다.
일주일 안에 모든 것을 배울 수는 없겠지만, 7일 또는 7시간 동안 무언가를 배운다면 처음 시작할 때보다 더 많은 것을 알게 될 것입니다.

71
2022/ko/Days/day07.md Normal file
View File

@ -0,0 +1,71 @@
---
title: '#90DaysOfDevOps - The Big Picture: Learning a Programming Language - Day 7'
published: false
description: 90DaysOfDevOps - The Big Picture DevOps & Learning a Programming Language
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048856
---
## 큰 그림: 데브옵스 및 프로그래밍 언어 학습
장기적으로 데브옵스 엔지니어로 성공하려면, 적어도 하나의 프로그래밍 언어를 기초 수준에서 이해하는 것이 매우 중요합니다. 이번 섹션에서는 이러한 중요성에 대해 자세히 알아보고, 이번 주나 섹션이 끝날 때까지 학습 계획을 수립하기 위해 왜, 어떻게, 무엇을 해야 하는지 더 잘 이해하도록 합니다.
소셜 미디어에서 데브옵스 관련 직무를 수행하기 위해 프로그래밍 기술이 필요한지 묻는다면 대부분 '그렇다'고 대답할 것입니다. 하지만 이러한 역할을 위해 어떤 프로그래밍 언어를 배워야 하는지에 대한 질문은 대답하기 어렵습니다. 일반적으로 Python을 추천하지만, Go(Golang)를 추천하는 경우도 점점 늘어나고 있습니다.
제 생각에는 데브옵스에서 성공하려면 프로그래밍 기술에 대한 탄탄한 기초를 갖추는 것이 중요합니다. 그러나 이러한 기술이 왜 필요한지 이해해야 목표를 달성하기 위한 적절한 길을 선택할 수 있습니다.
## 프로그래밍 언어를 배워야 하는 이유를 이해합니다.
데브옵스에서 사용되는 대부분의 도구가 Python 또는 Go로 작성되어 있기 때문에 데브옵스 엔지니어에게 Python과 Go를 자주 권장합니다. 이러한 도구를 만들거나 이러한 도구를 만드는 팀에 합류하는 데 관심이 있다면 데브옵스 도구를 만드는 데 사용되는 언어를 배우는 것이 좋습니다. Kubernetes나 컨테이너에 많이 관여하고 있다면 프로그래밍 언어로 Go를 배우는 것이 더 유리할 수 있습니다. 제 경우에는 클라우드 네이티브 에코시스템에 속해 있으며 Kubernetes의 데이터 관리에 중점을 두는 회사로, 모든 도구가 Go로 작성되어 있는 Kasten by Veeam에서 일하고 있습니다.
아직 명확한 결정이 내려지지 않은 학생이나 경력 전환기의 경우, 진로를 선택하는 것이 쉽지 않을 수 있습니다. 이런 상황에서는 자신이 만들고 싶은 애플리케이션과 가장 잘 맞고 가장 공감할 수 있는 것을 선택하는 것이 가장 좋습니다.
저는 소프트웨어 개발자가 되고자 하는 것이 아닙니다. 프로그래밍 언어에 대한 기본적인 이해를 바탕으로 다양한 도구의 기능을 이해하고 이를 개선할 수 있는 방법을 찾는 것이 목표입니다.
Kasten K10이나 Terraform, HCL과 같은 데브옵스 도구와 상호 작용하는 방법을 이해하는 것이 중요합니다. 이는 일반적으로 YAML로 작성되는 구성 파일을 통해 이루어집니다. 이러한 파일을 통해 DevOps 도구로 작업을 수행할 수 있습니다. (이 섹션의 마지막 날에는 YAML에 대해 더 자세히 살펴보겠습니다.)
## 제가 방금 프로그래밍 언어를 배우지 말라고 설득한 건가요?
많은 경우, 데브옵스 엔지니어의 주된 책임은 엔지니어링 팀과 협력하여 데브옵스 관행을 워크플로우에 통합하는 것입니다. 여기에는 애플리케이션에 대한 광범위한 테스트와 워크플로우가 앞서 설명한 데브옵스 원칙을 준수하는지 확인하는 작업인 경우가 많습니다. 그러나 작업의 상당 부분에는 애플리케이션 성능 또는 기타 기술적 결함과 관련된 문제 해결도 포함될 수 있습니다. 따라서 작업 중인 애플리케이션에서 사용하는 프로그래밍 언어에 대한 전문 지식을 갖추는 것이 중요합니다. 예를 들어, 애플리케이션이 Node.js로 작성된 경우 Go나 Python을 알아도 별 도움이 되지 않습니다.
## 왜 Go인가요?
Go가 데브옵스를 위한 유망한 프로그래밍 언어인 이유. Go는 최근 몇 년 동안 상당한 인기를 얻었으며, 2021년 StackOverflow 설문조사에서 가장 선호하는 프로그래밍, 스크립팅 및 마크업 언어 중 하나로 4위에 올랐고, 1위는 Python이었습니다. 자세히 살펴보겠습니다. [StackOverflow 2021 Developer Survey – Most Wanted Link](https://insights.stackoverflow.com/survey/2021#section-most-loved-dreaded-and-wanted-programming-scripting-and-markup-languages)
앞서 언급했듯이, Kubernetes, Docker, Grafana, Prometheus 등 가장 잘 알려진 데브옵스 도구 및 플랫폼 중 일부는 Go로 작성되었습니다.
데브옵스 목적에 특히 적합한 Go의 주요 기능이나 특성은 무엇일까요?
## Go 프로그램 구축 및 배포
데브옵스 역할에서 Python과 같은 언어를 사용하면 프로그램을 실행하기 전에 컴파일할 필요가 없다는 이점이 있습니다. 빌드 프로세스가 길어지면 불필요하게 프로세스 속도가 느려질 수 있으므로 소규모 자동화 작업에 특히 유용합니다. Go는 컴파일 언어이긴 하지만 **머신 코드로 직접 컴파일되며** 컴파일 시간이 빠른 것으로 알려져 있다는 점에 집중할 필요가 있습니다.
## 데브옵스를 위한 Go vs Python
Go 프로그램은 정적으로 링크됩니다. 즉, Go 프로그램을 컴파일할 때 모든 것이 단일 바이너리 실행 파일에 포함되며 원격 시스템에 외부 종속성을 설치할 필요가 없습니다. 따라서 외부 라이브러리에 의존하는 경우가 많은 Python 프로그램에 비해 Go 프로그램을 더 쉽게 배포할 수 있습니다. Python을 사용하면 프로그램을 실행하려는 원격 머신에 필요한 모든 라이브러리가 설치되어 있는지 확인해야 합니다.
Go는 특정 플랫폼에 종속되지 않는 언어이기 때문에 Linux, Windows, macOS 등 \*다양한 운영 체제용 바이너리 실행 파일을 쉽게 만들 수 있습니다. 반면에 Python으로 특정 운영 체제용 바이너리 실행 파일을 생성하는 것은 더 어려울 수 있습니다.
Go는 Python에 비해 컴파일 및 실행 시간이 빠르고 CPU와 메모리 측면에서 리소스 소비가 적은 매우 효율적인 프로그래밍 언어입니다. 이 언어에는 다양한 최적화가 구현되어 있어 뛰어난 성능을 제공합니다. (자세한 내용은 아래 리소스를 참조하세요.)
특정 프로그래밍 작업을 위해 종종 서드파티 라이브러리에 의존하는 Python에 비해 Go에는 데브옵스에 필요한 대부분의 기능을 바로 사용할 수 있는 표준 라이브러리가 있습니다. 여기에는 파일 처리, HTTP 웹 서비스, JSON 처리, 동시성 및 병렬 처리를 위한 기본 지원, 심지어 테스트 기능까지 포함됩니다.
제가 Go를 선택한 이유는 파이썬을 비판하기 위해서가 아니라는 점을 분명히 말씀드리고 싶습니다. 제가 근무하는 회사에서 Go로 소프트웨어를 개발하기 때문에 Go를 사용하는 것이 합리적입니다.
프로그래밍 언어 하나를 배우면 다른 언어를 배우기가 더 쉬워진다는 말을 들었습니다. 어느 회사에서든 자바스크립트 및 Node.js 애플리케이션을 관리, 설계, 오케스트레이션, 디버깅하게 될 가능성이 있고, 지금 Go를 배워두면 도움이 될 것입니다.
## 자료
- [StackOverflow 2021 Developer Survey](https://insights.stackoverflow.com/survey/2021)
- [Why we are choosing Golang to learn](https://www.youtube.com/watch?v=7pLqIIAqZD4&t=9s)
- [Jake Wright - Learn Go in 12 minutes](https://www.youtube.com/watch?v=C8LgvuEBraI&t=312s)
- [Techworld with Nana - Golang full course - 3 hours 24 mins](https://www.youtube.com/watch?v=yyUHQIec83I)
- [**NOT FREE** Nigel Poulton Pluralsight - Go Fundamentals - 3 hours 26 mins](https://www.pluralsight.com/courses/go-fundamentals)
- [FreeCodeCamp - Learn Go Programming - Golang Tutorial for Beginners](https://www.youtube.com/watch?v=YS4e4q9oBaU&t=1025s)
- [Hitesh Choudhary - Complete playlist](https://www.youtube.com/playlist?list=PLRAV69dS1uWSR89FRQGZ6q9BR2b44Tr9N)
앞으로 6일 동안 위에서 언급한 자료를 공부하고 매일 진행 상황을 메모할 계획입니다. 전체 과정은 약 3시간 정도 걸리지만, 저는 이 학습에 하루 한 시간씩 할애할 예정입니다. 시간이 여유가 있으신 분들도 함께 하며 깊이 있게 공부하실 수 있도록 전체 리소스 목록을 공유해 드립니다.
[Day 8](day08.md)에서 봐요!

118
2022/ko/Days/day08.md Normal file
View File

@ -0,0 +1,118 @@
---
title: '#90DaysOfDevOps - Setting up your DevOps environment for Go & Hello World - Day 8'
published: false
description: 90DaysOfDevOps - Setting up your DevOps environment for Go & Hello World
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048857
---
## Go를 위한 데브옵스 환경 설정 및 Hello World
Go 언어에 대한 몇 가지 기본 사항을 살펴보기 전에, 먼저 컴퓨터에 Go를 설치하고 모든 "learning programming 101" 모듈에서 가르치는 Hello World 앱을 만들어야 합니다. 이 문서에서는 컴퓨터에 Go를 설치하는 단계를 안내하며, 그림으로 문서화하여 사람들이 쉽게 따라 할 수 있도록 하겠습니다.
먼저, [go.dev/dl](https://go.dev/dl/)로 이동하면 다운로드할 수 있는 몇 가지 옵션이 나타납니다.
![](/2022/Days/Images/Day8_Go1.png)
여기까지 오셨다면, 현재 사용 중인 컴퓨터의 운영 체제를 확인하고 해당하는 다운로드를 선택하여 설치를 시작하시면 됩니다. 제가 사용하는 운영 체제는 Windows입니다. 기본적으로 다음 화면부터는 모든 기본값을 그대로 두어도 됩니다. **(최신 버전이 나오면 스크린샷과 다르게 나올 수도 있으니 참고해주세요.)**
![](/2022/Days/Images/Day8_Go2.png)
만약 이전 버전의 Go가 설치되어 있다면, 먼저 해당 버전을 제거해야 합니다. Windows에서는 이를 위한 내장 제거 기능을 제공하며, 이를 통해 이전 버전을 제거하고 하나의 설치 프로그램으로 설치할 수 있습니다.
작업을 완료한 후 명령 프롬프트/터미널을 열어서 Go가 설치되어 있는지 확인해야 합니다. 만약 아래와 같은 출력이 표시되지 않았다면, Go가 설치되지 않은 것이므로 단계를 되짚어봐야 합니다.
`go version`
![](/2022/Days/Images/Day8_Go3.png)
다음으로 Go 환경변수를 확인하겠습니다. 작업 디렉토리가 올바르게 구성되었는지 항상 확인하는 것이 좋으므로, 아래 디렉토리가 시스템에 있는지 확인해야 합니다.
![](/2022/Days/Images/Day8_Go4.png)
확인하셨나요? 지금까지 잘 따라오고 있나요? 해당 디렉토리로 이동하면 아래와 같은 메시지가 나타납니다.
![](/2022/Days/Images/Day8_Go5.png)
그럼 PowerShell 터미널에서 mkdir 명령어를 사용하여 디렉토리를 만들어 보겠습니다. 또한, 아래에서 보이듯이 Go 폴더 내에 3개의 폴더를 생성해야 합니다.
![](/2022/Days/Images/Day8_Go6.png)
이제 Go를 설치하고 작업 디렉토리를 준비했습니다. 이제 통합 개발 환경(IDE)이 필요합니다. 사용 가능한 IDE는 여러 가지가 있지만, 가장 일반적이고 제가 사용하는 것은 VSCode(Visual Studio Code)입니다. IDE에 대한 자세한 내용은 [여기](https://www.youtube.com/watch?v=vUn5akOlFXQ)에서 확인할 수 있습니다. _(엄밀히 말하면 VSCode는 IDE가 아닌 코드 에디터입니다. - 옮긴이)_
만약 컴퓨터에 아직 VSCode를 다운로드하고 설치하지 않았다면, [여기](https://code.visualstudio.com/download)로 이동하여 설치할 수 있습니다. 아래에서 확인할 수 있는 것처럼, 다양한 운영체제를 제공됩니다.
![](/2022/Days/Images/Day8_Go7.png)
Go 설치와 마찬가지로, 기본값으로 다운로드하여 설치합니다. 설치가 완료되면, 파일 열기를 선택하고 Go 디렉토리를 만들었던 곳으로 이동하여 VSCode를 열 수 있습니다.
![](/2022/Days/Images/Day8_Go8.png)
신뢰에 관한 팝업이 표시될 수 있는데, 원한다면 이를 읽고 '예, 작성자를 신뢰합니다'를 누르세요. (나중에 신뢰하지 않는 파일을 열기 시작해도 저는 책임지지 않습니다!)
이전에 만든 세 개의 폴더를 모두 볼 수 있습니다. 이제 `src` 폴더를 마우스 오른쪽 버튼으로 클릭하고 `Hello`라는 새 폴더를 생성하겠습니다.
![](/2022/Days/Images/Day8_Go9.png)
여기까지는 꽤 쉬운 내용이었죠? 이제 다음 단계에서는 아무것도 이해하지 못한 상태에서 첫 번째 Go 프로그램을 만들 것입니다.
다음으로, `Hello` 폴더에 `main.go` 파일을 생성합니다. `main.go` 파일을 열고 Enter 키를 누르면 Go 확장 프로그램과 패키지를 설치할 것인지 묻는 메시지가 나타납니다. 이전에 만든 빈 `pkg` 폴더를 확인하면 이제 새로운 패키지가 추가된 것을 확인할 수 있습니다.
![](/2022/Days/Images/Day8_Go10.png)
이제 Hello World 앱을 실행하고 다음 코드를 새 `main.go` 파일에 복사하여 저장해 보겠습니다.
```go
package main
import "fmt"
func main() {
fmt.Println("Hello #90DaysOfDevOps")
}
```
이해가 어려울 수도 있지만, 함수, 패키지 등에 대해 더 자세하게 다룰 예정입니다. 현재는 앱을 실행해보겠습니다. 터미널에서 `Hello` 폴더로 돌아가서 제대로 작동하는지 확인할 수 있습니다. 다음 명령을 사용하여 프로그램이 제대로 작동하는지 확인할 수 있습니다.
```
go run main.go
```
![](/2022/Days/Images/Day8_Go11.png)
여기서 끝이 아닙니다. 다른 Windows 컴퓨터에서 이 프로그램을 실행하려면 어떻게 해야 할까요? 다음 명령을 사용하여 바이너리로 빌드하면 됩니다.
```
go build main.go
```
![](/2022/Days/Images/Day8_Go12.png)
_(Mac 운영체제의 경우 `main` 파일이 생성됩니다. - 옮긴이)_
이를 실행한다면 동일한 결과를 볼 수 있습니다:
```bash
# Windows
$ ./main.exe
Hello #90DaysOfDevOps
# Mac - 올긴이
$ ./main
Hello #90DaysOfDevOps
```
## 자료
- [StackOverflow 2021 Developer Survey](https://insights.stackoverflow.com/survey/2021)
- [Why we are choosing Golang to learn](https://www.youtube.com/watch?v=7pLqIIAqZD4&t=9s)
- [Jake Wright - Learn Go in 12 minutes](https://www.youtube.com/watch?v=C8LgvuEBraI&t=312s)
- [Techworld with Nana - Golang full course - 3 hours 24 mins](https://www.youtube.com/watch?v=yyUHQIec83I)
- [**NOT FREE** Nigel Poulton Pluralsight - Go Fundamentals - 3 hours 26 mins](https://www.pluralsight.com/courses/go-fundamentals)
- [FreeCodeCamp - Learn Go Programming - Golang Tutorial for Beginners](https://www.youtube.com/watch?v=YS4e4q9oBaU&t=1025s)
- [Hitesh Choudhary - Complete playlist](https://www.youtube.com/playlist?list=PLRAV69dS1uWSR89FRQGZ6q9BR2b44Tr9N)
[Day 9](day09.md)에서 봐요!
![](/2022/Days/Images/Day8_Go13.png)

82
2022/ko/Days/day09.md Normal file
View File

@ -0,0 +1,82 @@
---
title: "#90DaysOfDevOps - Let's explain the Hello World code - Day 9"
published: false
description: 90DaysOfDevOps - Let's explain the Hello World code
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1099682
---
## Hello World 코드를 설명해 보겠습니다.
### Go 작동 방식
[Day 8](day08.md)에서는 컴퓨터에 Go를 설치하는 방법을 안내하고, 그 후 첫 번째 Go 애플리케이션을 만들었습니다.
이 섹션에서는 코드를 더 자세히 살펴보고 Go 언어를 더 잘 이해해보겠습니다.
### 컴파일이 무엇인가요?
[Hello World 코드](/2022/Days/Go/hello.go)를 이해하기 전에 컴파일에 대한 이해가 필요합니다.
파이썬, 자바, Go, C++ 등은 우리가 일반적으로 사용하는 고수준 프로그래밍 언어입니다. 이는 사람이 이해하기 쉽지만, 기계가 실행하기 위해서는 기계가 이해할 수 있는 형태로 변환되어야 합니다. 이러한 변환 작업을 컴파일이라고 합니다. 컴파일은 사람이 작성한 코드를 기계가 이해할 수 있는 코드로 변환하는 과정입니다.
![](/2022/Days/Images/Day9_Go1.png)
이전에 [Day 8](day08.md)에서 수행한 작업을 위 그림으로 확인할 수 있습니다. 우선 간단한 Hello World를 출력하는 main.go를 작성하고, 이를 `go build main.go` 명령을 사용하여 실행 파일로 컴파일했습니다.
### 패키지가 무엇인가요?
패키지는 같은 디렉토리에 있는 여러 개의 .go 확장자 파일의 모음으로 구성됩니다. 더 간단히 말하면, 패키지는 같은 디렉토리 내에서 함께 컴파일되는 소스 파일들입니다. 또한, 더 복잡한 Go 프로그램에서는 여러 패키지가 폴더1, 폴더2, 폴더3 등에 분산되어 있을 수 있으며, 각 패키지는 서로 다른 .go 파일들로 이루어질 수 있습니다.
패키지를 사용하면 다른 사람들의 코드를 재사용하여 처음부터 모든 것을 새로 작성할 필요가 없어집니다. 만약 프로그램에서 계산기가 필요하다면, 기존에 Go 언어로 작성된 패키지에서 수학 함수를 가져와 코드에 적용시키면 장기적으로 많은 시간과 노력을 절약할 수 있습니다.
Go 언어는 코드를 패키지로 구성하여 소스 코드의 재사용성과 유지 보수성을 쉽게 확보할 수 있도록 권장합니다.
### Hello #90DaysOfDevOps 한 줄 한 줄
이제 Hello #90DaysOfDevOps main.go 파일을 살펴보겠습니다.
![](/2022/Days/Images/Day9_Go2.png)
Go 언어에서는 모든 .go 파일은 패키지에 속해야 하며, `package something`과 같이 첫 줄에 패키지 이름을 명시해야 합니다. 이때, `package main`은 이 파일이 main 함수를 포함하는 패키지임을 나타냅니다.
패키지 이름은 원하는 대로 지정할 수 있습니다. 하지만 이 프로그램 시작점에서의 패키지는 `main`으로 지정해야 하며, 이는 규칙입니다. (이 규칙에 대해 추가적인 이해가 필요한가요?)
![](/2022/Days/Images/Day9_Go3.png)
코드를 컴파일하고 실행할 때, 시작해야 하는 위치를 컴퓨터에게 알려주어야 합니다. 이를 위해 'main'이라는 함수를 작성합니다. 컴퓨터는 프로그램의 시작점을 찾기 위해 'main' 함수를 찾습니다.
함수는 특정 작업을 수행하는 코드 블록으로, 프로그램 전체에서 사용할 수 있습니다.
`func`를 사용하여 함수를 어떤 이름으로든 선언할 수 있지만, 이 경우 코드가 시작되는 곳이므로 `main`이라는 이름을 지정해야 합니다.
![](/2022/Days/Images/Day9_Go4.png)
다음으로, 코드의 세 번째 줄인 'import'를 살펴보겠습니다. 이 줄은 메인 프로그램에 다른 패키지를 가져오고자 하는 것을 의미합니다. 'fmt'는 Go에서 제공하는 표준 패키지 중 하나이며, `Println()` 함수를 포함하고 있기 때문에, 이를 'import' 했으므로 여섯 번째 줄에서 이 함수를 사용할 수 있습니다. 프로그램에서 사용하거나 재사용할 수 있는 여러 표준 패키지가 있으므로, 처음부터 작성해야 하는 번거로움을 줄일 수 있습니다. [Go Standard Library](https://pkg.go.dev/std)
![](/2022/Days/Images/Day9_Go5.png)
여기에 있는 `Println()`은 실행 파일이 성공적으로 실행됐을 때 터미널에 STDOUT(standard output)을 출력하는 함수입니다. 괄호 안에는 원하는 메시지를 자유롭게 입력할 수 있습니다.
![](/2022/Days/Images/Day9_Go6.png)
### TLDR
- **1행** = 이 파일은 `main` 패키지에 있으며, 프로그램의 진입점을 포함하고 있으므로 `main`으로 불러야 합니다.
- **3행** = `Println()`을 사용하려면 6행에서 'fmt' 패키지를 'import'하여야 합니다.
- **5행** = 프로그램의 실제 시작점은 `main` 함수입니다.
- **6행** = 이렇게 하면 시스템에 "Hello #90DaysOfDevOps"을 출력할 수 있습니다.
## 자료
- [StackOverflow 2021 Developer Survey](https://insights.stackoverflow.com/survey/2021)
- [Why we are choosing Golang to learn](https://www.youtube.com/watch?v=7pLqIIAqZD4&t=9s)
- [Jake Wright - Learn Go in 12 minutes](https://www.youtube.com/watch?v=C8LgvuEBraI&t=312s)
- [Techworld with Nana - Golang full course - 3 hours 24 mins](https://www.youtube.com/watch?v=yyUHQIec83I)
- [**NOT FREE** Nigel Poulton Pluralsight - Go Fundamentals - 3 hours 26 mins](https://www.pluralsight.com/courses/go-fundamentals)
- [FreeCodeCamp - Learn Go Programming - Golang Tutorial for Beginners](https://www.youtube.com/watch?v=YS4e4q9oBaU&t=1025s)
- [Hitesh Choudhary - Complete playlist](https://www.youtube.com/playlist?list=PLRAV69dS1uWSR89FRQGZ6q9BR2b44Tr9N)
[Day 10](day10.md)에서 봐요!

99
2022/ko/Days/day10.md Normal file
View File

@ -0,0 +1,99 @@
---
title: '#90DaysOfDevOps - The Go Workspace - Day 10'
published: false
description: 90DaysOfDevOps - The Go Workspace
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048701
---
### Go 워크스페이스
[Day 8](day08.md)에서 Go 워크스페이스를 간략히 살펴보고 'Hello #90DaysOfDevOps'의 데모를 실행했습니다. 그러나 Go 워크스페이스에 대해 좀 더 자세히 설명해야 합니다.
기본값을 선택한 다음 이미 정의된 GOPATH에 Go 폴더가 생성됐지만, 실제로는 이 GOPATH를 원하는 위치로 변경할 수 있습니다.
다음 명령어를 실행하면
```
echo $GOPATH
```
출력은 다음과 유사해야 합니다.(사용자 아이디가 다를 수 있습니다.)
```
/home/michael/projects/go
```
그런 다음 여기에 3개의 디렉토리를 생성했습니다. **src**, **pkg**, **bin**.
![](/2022/Days/Images/Day10_Go1.png)
**src**는 Go 프로그램과 프로젝트를 저장하는 곳으로, 모든 Go 리포지토리의 네임스페이스 패키지 관리를 담당합니다. 컴퓨터에서 Hello #90DaysOfDevOps 프로젝트를 위한 Hello 폴더를 확인할 수 있습니다.
![](/2022/Days/Images/Day10_Go2.png)
**pkg**는 프로그램에 설치되거나 설치되었던 패키지의 파일을 저장하는 곳입니다. 이것은 사용 중인 패키지가 수정되었는지 여부에 따라 컴파일 프로세스의 속도를 향상하는 데 도움이 됩니다.
![](/2022/Days/Images/Day10_Go3.png)
**bin**은 컴파일된 모든 바이너리가 저장되는 곳입니다.
![](/2022/Days/Images/Day10_Go4.png)
Hello #90DaysOfDevOps는 복잡한 프로그램이 아니기 때문에, 다른 훌륭한 리소스인 [GoChronicles](https://gochronicles.com/)에서 가져온 좀 더 복잡한 Go 프로그램의 예시를 소개해 드리겠습니다.
![](/2022/Days/Images/Day10_Go5.png)
이 페이지는 [GoChronicles](https://gochronicles.com/project-structure/)에 언급되지 않은 다른 폴더에 대한 자세한 설명과 함께, 레이아웃이 왜 이렇게 구성되었는지에 대해 자세히 설명합니다.
### 코드 컴파일 및 실행
[Day 9](day09.md)에서도 코드 컴파일에 대한 간략한 소개를 다루었지만, 이번에는 더 자세히 살펴보겠습니다.
코드를 실행하기 위해서는 먼저 코드를 **컴파일**해야 합니다. Go에서 컴파일하는 방법은 세 가지가 있습니다.
- go build
- go install
- go run
컴파일을 진행하기 전에 Go를 설치하면 무엇을 얻을 수 있는지 살펴봅시다.
8일 차에 Go를 설치하는 동안 Go 소스 파일의 빌드 및 처리를 용이하게 하는 다양한 프로그램으로 구성된 Go 도구를 얻었습니다. 이러한 도구 중 하나가 `Go`입니다.
표준 Go 설치에 포함되지 않은 추가 도구도 설치할 수 있다는 점에 유의하세요.
Go가 제대로 설치되었는지 확인하려면 명령 프롬프트를 열고 `go`를 입력합니다. 아래 이미지와 비슷한 내용이 표시되고 그 뒤에 "Additional Help Topics"가 표시됩니다. 현재로서는 이것에 대해 생각할 필요는 없습니다.
![](/2022/Days/Images/Day10_Go6.png)
8일째인 지금까지 이미 이 도구 중 최소 두 가지를 사용했다는 사실을 기억하실 겁니다.
![](/2022/Days/Images/Day10_Go7.png)
자세히 알고 싶은 것은 "build", "install", 그리고 "run"입니다.
![](/2022/Days/Images/Day10_Go8.png)
- `go run` - 이 명령은 command line에 지정한 .go 파일로 구성된 기본 패키지를 컴파일하고 실행합니다. 이때, 컴파일된 실행 파일은 임시 폴더에 저장됩니다.
- `go build` - 현재 디렉토리에서 패키지와 종속성을 컴파일합니다. 만약 프로젝트에 `main` 패키지가 포함되어 있다면, 실행 파일이 현재 디렉토리에 생성됩니다. 그렇지 않은 경우, 실행 파일은 `pkg` 폴더에 생성되며, 이후 다른 Go 프로그램에서 가져와서 사용할 수 있습니다. 또한 `go build`를 사용하면 Go가 지원하는 모든 OS 플랫폼에 대해 실행 파일을 빌드할 수 있습니다.
- `go install` - go build와 비슷하지만, 실행 파일을 `bin` 폴더에 저장합니다.
`go build`과 `go run`을 실행했지만, 원하는 경우 이곳에서 다시 실행할 수 있습니다. `go install`은 실행 파일을 bin 폴더에 넣는 것으로 설명한 대로 수행됩니다.
![](/2022/Days/Images/Day10_Go9.png)
이 글을 따라오면서 아래의 재생 목록이나 동영상 중 하나를 시청하시기 바랍니다. 제 목표는 여러분과 함께하는 7일 또는 7시간 동안의 여정에서 제가 발견한 흥미로운 정보들을 공유하는 것이기에 저는 이 모든 자료에서의 핵심 정보를 모아서 Go 언어의 기본 개념을 설명하고자 합니다. 아래 자료들은 여러분이 이해해야 할 필수적인 주제에 대한 이해에 도움을 줄 수 있습니다.
## 자료
- [StackOverflow 2021 Developer Survey](https://insights.stackoverflow.com/survey/2021)
- [Why we are choosing Golang to learn](https://www.youtube.com/watch?v=7pLqIIAqZD4&t=9s)
- [Jake Wright - Learn Go in 12 minutes](https://www.youtube.com/watch?v=C8LgvuEBraI&t=312s)
- [Techworld with Nana - Golang full course - 3 hours 24 mins](https://www.youtube.com/watch?v=yyUHQIec83I)
- [**NOT FREE** Nigel Poulton Pluralsight - Go Fundamentals - 3 hours 26 mins](https://www.pluralsight.com/courses/go-fundamentals)
- [FreeCodeCamp - Learn Go Programming - Golang Tutorial for Beginners](https://www.youtube.com/watch?v=YS4e4q9oBaU&t=1025s)
- [Hitesh Choudhary - Complete playlist](https://www.youtube.com/playlist?list=PLRAV69dS1uWSR89FRQGZ6q9BR2b44Tr9N)
[Day 11](day11.md)에서 봐요!

176
2022/ko/Days/day11.md Normal file
View File

@ -0,0 +1,176 @@
---
title: '#90DaysOfDevOps - Variables & Constants in Go - Day 11'
published: false
description: 90DaysOfDevOps - Variables & Constants in Go
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048862
---
오늘의 주제에 들어가기 전에, [Techworld with Nana](https://www.youtube.com/watch?v=yyUHQIec83I)에서 다룬 Go의 기초에 대한 환상적이고 간결한 여정에 대해 큰 박수를 보내고 싶습니다.
[Day 8](day08.md)에는 환경을 설정하였고, [Day 9](day09.md)에는 Hello #90DaysOfDevOps 코드를 검토하였으며, [Day 10](day10.md)에는 Go 워크스페이스를 살펴보고 코드를 컴파일한 후 실행하는 과정까지 자세히 학습했습니다.
오늘은 새로운 프로그램을 만들어보면서 변수, 상수 그리고 데이터 타입에 대해 살펴볼 예정입니다.
## Go의 변수 및 상수
우선, 애플리케이션을 계획하는 것으로 시작하겠습니다. #90DaysOfDevOps 챌린지가 얼마나 남았는지 알려주는 프로그램을 만드는 것이 좋을 것 같습니다.
프로그램을 실행하기 전에 고려해야 할 사항은 앱을 빌드하고 참가자를 환영하며 완료한 일 수에 대한 피드백을 줄 때 "#90DaysOfDevOps"이란 용어를 여러 번 사용할 수 있다는 것입니다. 이것은 프로그램에서 #90DaysOfDevOps를 변수로 사용할 좋은 상황입니다.
- 변수는 값을 저장하기 위해 사용됩니다.
- 저장된 정보나 값이 담긴 작은 상자와 같은 것입니다.
- 변수는 프로그램 전체에서 사용할 수 있으며, 챌린지나 변수가 변경되더라도 한 곳에서만 변경하면 되는 장점이 있습니다. 즉, 변수 하나만 변경하면 커뮤니티의 다른 챌린지에도 적용할 수 있습니다.
Go 프로그램에서는 변수를 선언하고 값을 정의하기 위해 **키워드(var, const...)**를 사용합니다. 이러한 변수 선언은 `func main` 코드 블록 내에서 이루어집니다. `키워드`에 대한 자세한 내용은 [여기](https://go.dev/ref/spec#Keywords)에서 확인할 수 있습니다.
변수 이름이 명시적인지 항상 확인하세요. 변수를 선언하면 반드시 사용해야 하며, 그렇지 않으면 오류가 발생합니다. 이는 사용되지 않는 코드(죽은 코드)를 방지할 수 있습니다. 사용되지 않는 패키지도 마찬가지입니다.
```go
var challenge = "#90DaysOfDevOps"
```
다음 코드 스니펫에서 볼 수 있듯이 위와 같이 선언하면 변수를 사용할 수 있음을 알 수 있습니다.
```go
package main
import "fmt"
func main() {
var challenge = "#90DaysOfDevOps"
fmt.Println("Welcome to", challenge, "")
}
```
위 코드 스니펫은 [day11_example1.go](/2022/Days/Go/day11_example1.go)에서 볼 수 있습니다.
위 예제를 사용하여 코드를 빌드하면 아래와 같이 출력되는 것을 볼 수 있습니다.
![](/2022/Days/Images/Day11_Go1.png)
이번 챌린지의 기간은 90일이지만, 다음 챌린지에서는 100일이 될 수도 있으므로, 이번 챌린지에서 사용되는 변수가 다음 챌린지에서도 유용하게 사용될 수 있도록 정의하고 싶습니다. 하지만 우리 프로그램에서는 이 변수를 상수로 정의하고자 합니다. 상수는 값을 변경할 수 없지만, 변수와 유사합니다.(이 코드를 사용하여 새로운 앱을 만들 경우 상수를 변경할 수 있지만, 애플리케이션을 실행하는 동안에는 이 90이 변경되지 않습니다.)
`const` 키워드를 코드에 추가하고, 출력을 위해 다른 코드 라인을 추가합니다.
```go
package main
import "fmt"
func main() {
var challenge = "#90DaysOfDevOps"
const daystotal = 90
fmt.Println("Welcome to", challenge, "")
fmt.Println("This is a", daystotal, "challenge")
}
```
위 코드 스니펫은 [day11_example2.go](/2022/Days/Go/day11_example2.go)에서 볼 수 있습니다.
`go build`를 다시 실행하면 아래와 같은 결과를 확인할 수 있습니다.
![](/2022/Days/Images/Day11_Go2.png)
이것이 우리 프로그램의 끝은 아니며 [Day 12](day12.md)에서 더 많은 기능을 추가할 예정입니다. 현재 완료한 일 수 외에도 다른 변수를 추가하려고 합니다.
`dayscomplete` 변수를 추가하였고, 완료한 일 수도 함께 기록하였습니다.
```go
package main
import "fmt"
func main() {
var challenge = "#90DaysOfDevOps"
const daystotal = 90
var dayscomplete = 11
fmt.Println("Welcome to", challenge, "")
fmt.Println("This is a", daystotal, "challenge and you have completed", dayscomplete, "days")
fmt.Println("Great work")
}
```
위 코드 스니펫은 [day11_example3.go](/2022/Days/Go/day11_example3.go)에서 볼 수 있습니다.
`go build`를 다시 실행하거나 `go run`을 실행할 수 있습니다.
![](/2022/Days/Images/Day11_Go3.png)
코드를 더 쉽게 읽고 편집하기 위해 몇 가지 다른 예제입니다. 이전에는 `Println`을 사용했지만, `Printf`를 사용하여 코드 줄 끝에 변수를 순서대로 정의하는 `%v`를 사용하면 코드를 간단히 만들 수 있습니다. 또한 줄 바꿈은 `\n`을 사용합니다.
기본값을 사용하기 때문에 `%v`를 사용하고 있지만, 다른 옵션은 [fmt package documentation](https://pkg.go.dev/fmt)의 코드 예제 [day11_example4.go](/2022/Days/Go/day11_example4.go)에서 확인할 수 있습니다.
변수를 정의하는 방법 중에는 '변수'와 '타입'을 명시하는 대신 더 간단한 형태로 정의하는 것도 있습니다. 이렇게 코딩하면 코드의 기능은 동일하지만, 더 깔끔하고 간결해집니다. 하지만 이 방법은 변수에만 적용되며 상수에는 적용되지 않습니다.
```go
func main() {
challenge := "#90DaysOfDevOps"
const daystotal = 90
```
## 데이터 타입
예제에서는 변수의 타입을 정의하지 않았습니다. 이는 값을 지정하고 Go가 해당 타입을 유추할 수 있을 만큼 똑똑하거나 저장한 값에 기반하여 타입을 결정할 수 있기 때문입니다. 그러나 사용자가 입력하도록 하려면 특정 타입을 명시해야 합니다.
지금까지 코드에서는 문자열과 정수를 사용했습니다. 정수는 일 수를, 문자열은 챌린지 이름을 나타내는 데 사용했습니다.
각 데이터 타입은 서로 다른 작업을 수행하며, 이에 따라 다르게 작동한다는 것을 유의해야 합니다. 예를 들어, 정수는 문자열과는 곱할 수 없습니다.
총 네 가지 타입이 있습니다:
- **Basic type**: 숫자, 문자열, 불리언 값이 해당 범주에 속합니다.
- **Aggregate type**: 배열과 구조체가 해당 범주에 속합니다.
- **Reference type**: 포인터, 슬라이스, 맵, 함수, 채널이 해당 범주에 속합니다.
- **Interface type**
데이터 타입은 프로그래밍에서 매우 중요한 개념입니다. 이는 변수의 크기와 타입을 지정하는 데 사용됩니다.
Go는 정적으로 타입이 지정되어 있어서 변수의 타입이 정의된 후에는 해당 타입의 데이터만 저장할 수 있습니다.
Go 언어에는 다음과 같이 세 가지 기본 데이터 타입이 있습니다:
- **bool**: 참(True) 또는 거짓(False) 값을 나타냅니다.
- **Numeric**: 정수형(integer), 부동 소수점 값(floating-point), 복소수형(complex)을 나타냅니다.
- **string**: 문자열 값을 나타냅니다.
[Golang by example](https://golangbyexample.com/all-data-types-in-golang-with-examples/)에서 데이터 타입에 대해 매우 자세하게 설명되어 있습니다.
[Techworld with Nana](https://www.youtube.com/watch?v=yyUHQIec83I&t=2023s)에서도 데이터 타입에 대해 자세히 다루고 있으니 추천해드립니다.
변수의 타입을 정의해야 하는 경우 다음과 같이 정의할 수 있습니다:
```go
var TwitterHandle string
var DaysCompleted uint
```
Go 언어에서 변수는 값이 할당되는 것을 의미합니다. 따라서 해당 값을 출력하려면 다음과 같이 할 수 있습니다:
```go
fmt.Printf("challenge is %T, daystotal is %T, dayscomplete is %T\n", conference, daystotal, dayscomplete)
```
여러 종류의 정수 및 부동 소수점 타입이 있으며, 앞의 링크들에서 자세한 내용을 확인할 수 있습니다.
- **int** = 정수
- **unint** = 양의 정수
- **floating point types** = 소수점이 있는 실수
## 자료
- [StackOverflow 2021 Developer Survey](https://insights.stackoverflow.com/survey/2021)
- [Why we are choosing Golang to learn](https://www.youtube.com/watch?v=7pLqIIAqZD4&t=9s)
- [Jake Wright - Learn Go in 12 minutes](https://www.youtube.com/watch?v=C8LgvuEBraI&t=312s)
- [Techworld with Nana - Golang full course - 3 hours 24 mins](https://www.youtube.com/watch?v=yyUHQIec83I)
- [**NOT FREE** Nigel Poulton Pluralsight - Go Fundamentals - 3 hours 26 mins](https://www.pluralsight.com/courses/go-fundamentals)
- [FreeCodeCamp - Learn Go Programming - Golang Tutorial for Beginners](https://www.youtube.com/watch?v=YS4e4q9oBaU&t=1025s)
- [Hitesh Choudhary - Complete playlist](https://www.youtube.com/playlist?list=PLRAV69dS1uWSR89FRQGZ6q9BR2b44Tr9N)
이제부터는 프로그램에 몇 가지 사용자 입력 기능을 추가해서 완료된 일수를 입력받도록 하겠습니다.
[Day 12](day12.md)에서 봐요!

85
2022/ko/Days/day12.md Normal file
View File

@ -0,0 +1,85 @@
---
title: '#90DaysOfDevOps - Getting user input with Pointers and a finished program - Day 12'
published: false
description: 90DaysOfDevOps - Getting user input with Pointers and a finished program
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048864
---
## 포인터를 이용하여 사용자 입력을 받아 프로그램 완성하기
어제([Day 11](day11.md)) 독립적인 첫 번째 Go 프로그램을 만들 때, 코드 내에서 사용자 입력을 받기 위한 변수를 생성하고 값을 할당했습니다. 이제 사용자에게 입력을 요청하여 최종 메시지 값을 변수에 할당하려고 합니다.
## 사용자 입력 받기
사용자 입력을 받기 전에 애플리케이션을 다시 살펴보고 변수를 점검해보겠습니다.
어제 우리는 [day11_example4.go](/2022/Days/Go/day11_example4.go) 코드에서 `challenge, daystotal, dayscomplete`를 변수와 상수로 정의했습니다.
이제 새로운 변수 `TwitterName`을 추가하겠습니다. 이 변수는 [day12_example1.go](/2022/Days/Go/day12_example1.go) 코드에서 찾을 수 있습니다. 코드를 실행하면 아래와 같이 출력됩니다.
![](/2022/Days/Images/Day12_Go1.png)
현재 12일째인데, 코드가 하드코딩되어 있다면 매일 `dayscomplete`를 수정하고 매일 코드를 컴파일해야 하기 때문에 효율적이지 않습니다.
사용자로부터 이름과 수행한 일수를 입력받아야 합니다. 이를 위해서는 `fmt` 패키지 내의 다른 함수를 사용할 수 있습니다.
`fmt` 패키지는 포맷된 입력 및 출력(I/O)을 위한 다양한 기능을 제공합니다. 이 패키지에 대한 요약은 다음과 같습니다.
- 메시지 출력
- 사용자 입력 수집
- 파일에 쓰기
이 방법은 변수에 값을 할당하는 대신 사용자로부터 입력을 요청하는 방식입니다.
```go
fmt.Scan(&TwitterName)
```
변수 앞에 `&`를 사용하는 것도 주목해 주세요. 이것은 포인터라 불리며, 다음 섹션에서 다룰 예정입니다.
[day12_example2.go](/2022/Days/Go/day12_example2.go) 코드에서는 사용자로부터 `TwitterName`과 `DaysCompleted`라는 두 변수를 입력받고 있습니다.
프로그램을 실행하면 위의 두 변수 모두에 대한 입력을 받는 걸 볼 수 있습니다.
![](/2022/Days/Images/Day12_Go2.png)
사용자 의견을 반영하여 메시지를 출력하는 기능도 좋지만, 챌린지 종료까지 남은 일수를 알려주는 기능도 추가하는 것이 어떨까요?
이를 위해 `remainingDays`라는 변수를 만들고, `90`이라는 값을 할당하겠습니다. 그리고 `DaysCompleted`로 사용자 입력을 받으면 남은 날짜를 계산하여 `remainingDays`의 값을 변경하겠습니다. 다음과 같이 간단하게 변수를 변경하면 됩니다.
```go
remainingDays = remainingDays - DaysCompleted
```
[day12_example2.go](/2022/Days/Go/day12_example3.go) 코드에서 완성된 프로그램의 모습을 확인할 수 있습니다.
프로그램을 실행하면, 사용자 입력을 기반으로 `remainingDays` 값을 계산하는 것을 볼 수 있습니다.
![](/2022/Days/Images/Day12_Go3.png)
## 포인터가 무엇인가요?(특수 변수)
포인터는 다른 변수의 메모리 주소를 가리키는 (특수)변수입니다.
이에 대한 자세한 설명은 [geeksforgeeks](https://www.geeksforgeeks.org/pointers-in-golang/)에서 확인할 수 있습니다.
출력 명령에 `&`를 사용할 때와 사용하지 않은 코드 예시를 통해 포인터의 메모리 주소를 확인해 볼 수 있습니다. [day12_example4.go](/2022/Days/Go/day12_example4.go)에 코드 예제를 추가했습니다.
아래는 이 코드를 실행한 모습입니다.
![](/2022/Days/Images/Day12_Go4.png)
## 자료
- [StackOverflow 2021 Developer Survey](https://insights.stackoverflow.com/survey/2021)
- [Why we are choosing Golang to learn](https://www.youtube.com/watch?v=7pLqIIAqZD4&t=9s)
- [Jake Wright - Learn Go in 12 minutes](https://www.youtube.com/watch?v=C8LgvuEBraI&t=312s)
- [Techworld with Nana - Golang full course - 3 hours 24 mins](https://www.youtube.com/watch?v=yyUHQIec83I)
- [**NOT FREE** Nigel Poulton Pluralsight - Go Fundamentals - 3 hours 26 mins](https://www.pluralsight.com/courses/go-fundamentals)
- [FreeCodeCamp - Learn Go Programming - Golang Tutorial for Beginners](https://www.youtube.com/watch?v=YS4e4q9oBaU&t=1025s)
- [Hitesh Choudhary - Complete playlist](https://www.youtube.com/playlist?list=PLRAV69dS1uWSR89FRQGZ6q9BR2b44Tr9N)
[Day 13](day13.md)에서 봐요!

322
2022/ko/Days/day13.md Normal file
View File

@ -0,0 +1,322 @@
---
title: '#90DaysOfDevOps - Tweet your progress with our new App - Day 13'
published: false
description: 90DaysOfDevOps - Tweet your progress with our new App
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048865
---
## 새로운 앱으로 진행 상황을 트윗하세요
프로그래밍 언어를 살펴본 마지막 날입니다. 우리는 프로그래밍 언어의 겉 부분만 살짝 살펴봤을 뿐이고 앞으로는 더 큰 흥미와 관심을 가지고 더욱 깊이 파고들어야 합니다.
최근 며칠간 애플리케이션에 작은 아이디어를 추가하면서 기능을 개선했습니다. 이번 세션에서는 앞서 언급한 패키지를 활용하여 화면에 진행 상황을 업데이트하는 것뿐만 아니라, 챌린지의 세부 정보와 상태를 트윗할 수 있는 기능을 만들어보려고 합니다.
## 진행 상황을 트윗하는 기능 추가
이 기능을 사용하려면 먼저 트위터에서 개발자 API 접근을 설정해야 합니다.
[Twitter Developer Platform](https://developer.twitter.com)으로 이동하여 내 트위터로 계정으로 로그인하면, 이미 만든 앱이 없는 경우 아래와 같은 화면이 표시됩니다.
![](/2022/Days/Images/Day13_Go1.png)
여기에서 Elevated 등급 계정을 요청할 수 있습니다. 시간이 조금 걸릴 수 있지만, 제 경우에는 빠르게 승인이 됐습니다.
다음으로, 프로젝트 및 앱을 선택하여 앱을 생성합니다. 보유한 계정 액세스 권한에 따라 제한이 있으며, Essential 계정은 하나의 앱과 하나의 프로젝트만, Elevated 계정은 3개의 앱만 만들 수 있습니다.
![](/2022/Days/Images/Day13_Go2.png)
애플리케이션의 이름을 지정합니다.
![](/2022/Days/Images/Day13_Go3.png)
API token이 제공됩니다. 이를 안전한 장소에 저장해야 합니다.(저는 이후 앱을 삭제했습니다.) 나중에 Go 애플리케이션에서 이 토큰이 필요할 것입니다.
![](/2022/Days/Images/Day13_Go4.png)
이제 앱이 생성되었습니다.(스크린샷에 보이는 앱 이름은 이미 생성된 것이기 때문에, 고유해야 하므로 앱 이름을 변경해야 했습니다.)
![](/2022/Days/Images/Day13_Go5.png)
"consumer keys"는 이전에 생성한 key를 의미하며, access token과 비밀번호도 필요합니다. 이 정보는 "Keys & Tokens" 탭에서 확인할 수 있습니다.
![](/2022/Days/Images/Day13_Go6.png)
트위터 개발자 포털에서 필요한 모든 작업을 마쳤습니다. 나중에 필요하실 수 있으니 key를 안전한 곳에 보관해주세요.
## Go 트위터 봇
애플리케이션을 시작했던 코드인 [day13_example1](/2022/Days/Go/day13_example1.go)를 기억해주세요. 하지만 먼저 올바른 코드로 트윗을 생성할 수 있는지 확인해야 합니다.
트위터에 메시지나 출력을 트윗 형태로 전달하기 위한 코드를 생각해봐야 합니다. 이를 위해 [go-twitter](https://github.com/dghubble/go-twitter) 라이브러리를 사용할 것입니다. 이 라이브러리는 Go 언어로 작성된 트위터 API 클라이언트 라이브러리입니다.
메인 애플리케이션에 적용하기 전에 `src` 폴더에 'go-twitter-bot'이라는 새 디렉토리를 만들고, 해당 폴더에서 `go mod init github.com/michaelcade/go-Twitter-bot` 명령을 실행하여 `go.mod` 파일을 생성한 후, 새로운 'main.go' 파일을 작성하여 테스트해 보았습니다.
트위터 개발자 포털에서 생성한 key, token 및 비밀번호가 필요하며, 이를 환경 변수로 설정해야 합니다. 하지만 이는 실행 중인 운영 체제에 따라 다를 수 있습니다.
환경 변수와 관련하여 몇 가지 질문이 있어, 블로그 게시물을 소개해드립니다. 해당 게시물은 환경 변수 설정 방법을 더 자세히 설명하고 있습니다. [How To Set Environment Variables](https://www.twilio.com/blog/2017/01/how-to-set-environment-variables.html)를 통해 확인해보세요.
Windows
```
set CONSUMER_KEY
set CONSUMER_SECRET
set ACCESS_TOKEN
set ACCESS_TOKEN_SECRET
```
Linux / MacOS
```
export CONSUMER_KEY
export CONSUMER_SECRET
export ACCESS_TOKEN
export ACCESS_TOKEN_SECRET
```
이 단계에서는 [day13_example2](/2022/Days/Go/day13_example2.go) 코드를 살펴볼 수 있습니다. 이 코드에서는 구조체를 사용하여 key, secret, token을 정의합니다.
Credentials를 분석하고 트위터 API에 연결하는 `func`가 있습니다.
이후 성공 여부에 따라 트윗을 전송합니다.
```go
package main
import (
// ...
"fmt"
"log"
"os"
"github.com/dghubble/go-twitter/twitter"
"github.com/dghubble/oauth1"
)
// Credentials는 트위터 REST API에 대한 인증에 필요한
// 모든 access/consumer token과 secret key를 저장합니다.
type Credentials struct {
ConsumerKey string
ConsumerSecret string
AccessToken string
AccessTokenSecret string
}
// getClient는 인증에 필요한 모든 것을 포함하며,
// 트위터 클라이언트 또는 오류에 대한 포인터를 반환하는
// Credentials 구조체에 대한 포인터를 받아 나중에 트윗을 보내거나
// 새 트윗을 스트리밍하는 데 사용할 수 있는 헬퍼 함수입니다.
func getClient(creds *Credentials) (*twitter.Client, error) {
// consumer key(API key)와 consumer secret(API secret)을 전달합니다.
config := oauth1.NewConfig(creds.ConsumerKey, creds.ConsumerSecret)
// access token과 access token secret을 전달합니다.
token := oauth1.NewToken(creds.AccessToken, creds.AccessTokenSecret)
httpClient := config.Client(oauth1.NoContext, token)
client := twitter.NewClient(httpClient)
// Credentials 확인
verifyParams := &twitter.AccountVerifyParams{
SkipStatus: twitter.Bool(true),
IncludeEmail: twitter.Bool(true),
}
// 사용자를 검색하고 Credentials가 올바른지 확인할 수 있고,
// 성공적으로 로그인할 수 있는지 확인할 수 있습니다!
user, _, err := client.Accounts.VerifyCredentials(verifyParams)
if err != nil {
return nil, err
}
log.Printf("User's ACCOUNT:\n%+v\n", user)
return client, nil
}
func main() {
fmt.Println("Go-Twitter Bot v0.01")
creds := Credentials{
AccessToken: os.Getenv("ACCESS_TOKEN"),
AccessTokenSecret: os.Getenv("ACCESS_TOKEN_SECRET"),
ConsumerKey: os.Getenv("CONSUMER_KEY"),
ConsumerSecret: os.Getenv("CONSUMER_SECRET"),
}
client, err := getClient(&creds)
if err != nil {
log.Println("Error getting Twitter Client")
log.Println(err)
}
tweet, resp, err := client.Statuses.Update("A Test Tweet from the future, testing a #90DaysOfDevOps Program that tweets, tweet tweet", nil)
if err != nil {
log.Println(err)
}
log.Printf("%+v\n", resp)
log.Printf("%+v\n", tweet)
}
```
위와 같이 작성하면 상황에 따라 오류가 발생하거나 성공하여 코드에 적힌 메시지가 포함된 트윗이 전송됩니다.
## 두 가지의 결합 - Go-Twitter-Bot + 우리의 앱
이제 이 두 가지를 `main.go`에서 병합해야 합니다. 이 작업을 수행하는 더 좋은 방법이 있을 것이며, 프로젝트에 둘 이상의 `.go` 파일을 가질 수 있으므로 이에 대해 의견을 제시해 주시기 바랍니다.
[day13_example3](/2022/Days/Go/day13_example3.go)에서 병합된 코드를 볼 수 있지만 아래에서도 보여드리겠습니다.
```go
package main
import (
// ...
"fmt"
"log"
"os"
"github.com/dghubble/go-twitter/twitter"
"github.com/dghubble/oauth1"
)
// Credentials는 트위터 REST API에 대한 인증에 필요한
// 모든 access/consumer token과 secret key를 저장합니다.
Credentials REST API에 대한 인증에 필요한 모든 액세스/소비자 토큰과 비밀 키를 저장합니다.
type Credentials struct {
ConsumerKey string
ConsumerSecret string
AccessToken string
AccessTokenSecret string
}
// getClient는 인증에 필요한 모든 것을 포함하며,
// 트위터 클라이언트 또는 오류에 대한 포인터를 반환하는
// Credentials 구조체에 대한 포인터를 받아 나중에 트윗을 보내거나
// 새 트윗을 스트리밍하는 데 사용할 수 있는 헬퍼 함수입니다.
func getClient(creds *Credentials) (*twitter.Client, error) {
// consumer key(API key)와 consumer secret(API secret)을 전달합니다.
config := oauth1.NewConfig(creds.ConsumerKey, creds.ConsumerSecret)
// access token과 access token secret을 전달합니다.
token := oauth1.NewToken(creds.AccessToken, creds.AccessTokenSecret)
httpClient := config.Client(oauth1.NoContext, token)
client := twitter.NewClient(httpClient)
// Verify Credentials
verifyParams := &twitter.AccountVerifyParams{
SkipStatus: twitter.Bool(true),
IncludeEmail: twitter.Bool(true),
}
// we can retrieve the user and verify if the credentials
// we have used successfully allow us to log in!
user, _, err := client.Accounts.VerifyCredentials(verifyParams)
if err != nil {
return nil, err
}
log.Printf("User's ACCOUNT:\n%+v\n", user)
return client, nil
}
func main() {
creds := Credentials{
AccessToken: os.Getenv("ACCESS_TOKEN"),
AccessTokenSecret: os.Getenv("ACCESS_TOKEN_SECRET"),
ConsumerKey: os.Getenv("CONSUMER_KEY"),
ConsumerSecret: os.Getenv("CONSUMER_SECRET"),
}
{
const DaysTotal int = 90
var remainingDays uint = 90
challenge := "#90DaysOfDevOps"
fmt.Printf("Welcome to the %v challenge.\nThis challenge consists of %v days\n", challenge, DaysTotal)
var TwitterName string
var DaysCompleted uint
// asking for user input
fmt.Println("Enter Your Twitter Handle: ")
fmt.Scanln(&TwitterName)
fmt.Println("How many days have you completed?: ")
fmt.Scanln(&DaysCompleted)
// Credentials 확인
remainingDays = remainingDays - DaysCompleted
//fmt.Printf("Thank you %v for taking part and completing %v days.\n", TwitterName, DaysCompleted)
//fmt.Printf("You have %v days remaining for the %v challenge\n", remainingDays, challenge)
//fmt.Println("Good luck")
client, err := getClient(&creds)
if err != nil {
log.Println("Error getting Twitter Client, this is expected if you did not supply your Twitter API tokens")
log.Println(err)
}
message := fmt.Sprintf("Hey I am %v I have been doing the %v for %v days and I have %v Days left", TwitterName, challenge, DaysCompleted, remainingDays)
tweet, resp, err := client.Statuses.Update(message, nil)
if err != nil {
log.Println(err)
}
log.Printf("%+v\n", resp)
log.Printf("%+v\n", tweet)
}
}
```
결과는 트윗으로 표시되어야 하지만, 환경 변수가 제공되지 않은 경우 아래와 같은 오류가 발생해야 합니다.
![](/2022/Days/Images/Day13_Go7.png)
만약 이 문제를 해결하거나 트위터 인증을 사용하지 않기로 선택했다면, 어제 작성한 코드를 사용할 수 있습니다. 성공한 경우 터미널 출력은 다음과 유사하게 표시됩니다:
![](/2022/Days/Images/Day13_Go8.png)
결과 트윗은 아래와 같이 표시되어야 합니다:
![](/2022/Days/Images/Day13_Go9.png)
## 여러 OS에 맞게 컴파일하는 방법
"여러 운영체제에서 컴파일하려면 어떻게 해야 할까요?"라는 질문에 대해 다루고자 합니다. Go의 가장 장점 중 하나는 다양한 운영체제에 대해 쉽게 컴파일할 수 있다는 점입니다. 아래 명령어를 실행하면 모든 운영체제 목록을 확인할 수 있습니다:
```
go tool dist list
```
지금까지 `go build` 명령을 사용하여 HM(host machine)과 빌드 대상을 환경 변수 `GOOS`와 `GOARCH`를 이용하여 결정할 수 있었습니다. 그러나 아래 예제와 같이 다른 바이너리를 생성할 수도 있습니다.
```
GOARCH=amd64 GOOS=darwin go build -o ${BINARY_NAME}_0.1_darwin main.go
GOARCH=amd64 GOOS=linux go build -o ${BINARY_NAME}_0.1_linux main.go
GOARCH=amd64 GOOS=windows go build -o ${BINARY_NAME}_0.1_windows main.go
GOARCH=arm64 GOOS=linux go build -o ${BINARY_NAME}_0.1_linux_arm64 main.go
GOARCH=arm64 GOOS=darwin go build -o ${BINARY_NAME}_0.1_darwin_arm64 main.go
```
위의 모든 플랫폼에 대한 바이너리가 디렉토리에 생성됩니다. 이후 코드에 새로운 기능을 추가할 때마다, 바이너리로 빌드하기 위해 [makefile](/2022/Days/Go/makefile)을 사용할 수도 있습니다.
지금 리포지토리에서 볼 수 있는 릴리스를 만드는 데 사용한 [repository](https://github.com/MichaelCade/90DaysOfDevOps/releases)입니다.
## 자료
- [StackOverflow 2021 Developer Survey](https://insights.stackoverflow.com/survey/2021)
- [Why we are choosing Golang to learn](https://www.youtube.com/watch?v=7pLqIIAqZD4&t=9s)
- [Jake Wright - Learn Go in 12 minutes](https://www.youtube.com/watch?v=C8LgvuEBraI&t=312s)
- [Techworld with Nana - Golang full course - 3 hours 24 mins](https://www.youtube.com/watch?v=yyUHQIec83I)
- [**NOT FREE** Nigel Poulton Pluralsight - Go Fundamentals - 3 hours 26 mins](https://www.pluralsight.com/courses/go-fundamentals)
- [FreeCodeCamp - Learn Go Programming - Golang Tutorial for Beginners](https://www.youtube.com/watch?v=YS4e4q9oBaU&t=1025s)
- [Hitesh Choudhary - Complete playlist](https://www.youtube.com/playlist?list=PLRAV69dS1uWSR89FRQGZ6q9BR2b44Tr9N)
- [A great repo full of all things DevOps & exercises](https://github.com/bregman-arie/devops-exercises)
- [GoByExample - Example based learning](https://gobyexample.com/)
- [go.dev/tour/list](https://go.dev/tour/list)
- [go.dev/learn](https://go.dev/learn/)
7일간의 프로그래밍 언어 학습을 마무리합니다. 앞으로도 더 많은 내용을 다룰 예정이며, 이번 학습을 통해 Go 프로그래밍 언어의 다른 측면도 이해할 수 있었기를 바랍니다.
다음으로, Linux와 Linux에서 알아야 할 몇 가지 기본 사항에 대해 살펴보겠습니다.
[Day 14](day14.md)에서 봐요!

116
2022/ko/Days/day14.md Normal file
View File

@ -0,0 +1,116 @@
---
title: '#90DaysOfDevOps - The Big Picture: DevOps and Linux - Day 14'
published: false
description: 90DaysOfDevOps - The Big Picture DevOps and Linux
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1049033
---
## 큰 그림: 데브옵스와 Linux
Linux와 데브옵스는 유사한 문화와 관점을 공유하며, 둘 다 커스터마이징과 확장성에 중점을 둡니다. 이 두 가지 측면은 특히 데브옵스에서 중요한 역할을 합니다.
특히 소프트웨어 개발이나 인프라 관리와 관련 기술들이 Linux에서 개발되었습니다.
또한 많은 오픈 소스 프로젝트, 특히 DevOps 도구는 Linux에서 바로 실행되도록 설계되었습니다.
DevOps나 운영 역할 관점에서는 대부분 Linux를 다룰 가능성이 높습니다. WinOps를 다루는 일도 있지만, 보통은 Linux 서버를 관리하고 배포하는 일이 많을 것입니다.
저는 몇 년 동안 Linux를 사용해왔지만, 메인 데스크탑 컴퓨터는 주로 macOS나 Windows였습니다. 하지만 클라우드 네이티브 역할로 전환한 후에는 노트북에서 Linux를 기본 운영 체제로 사용하기로 결정했습니다. 일부 오디오 및 비디오 장비는 Linux와 호환되지 않기 때문에 업무 관련 애플리케이션은 여전히 Windows가 필요하지만, 앞으로 7일간은 개념을 더 잘 이해하기 위해 데스크탑에서 Linux를 사용하겠습니다.
## 시작하기
더 쉬운 방법이 있기 때문에 여러분도 저와 똑같이 하라고 권하고 싶지는 않지만, 저처럼 단계를 밟으면 Linux를 더 빨리 배울 수 있다는 걸 알려드리고 싶습니다.
이번 7일 동안, 저는 Windows에서 VirtualBox를 사용해 가상 머신을 띄울 계획입니다. 데스크탑 버전의 Linux 배포판도 함께 사용할 예정이지만, 여러분이 관리하게 될 대부분의 Linux 서버는 GUI가 없이 shell 기반으로 운영될 것입니다. 하지만, 앞서 90일 동안 학습한 많은 도구들이 Linux에서 시작되었다는 것을 언급했듯이, Linux 데스크탑을 실행해 보는 것도 강력히 추천합니다.
이 글의 나머지 부분에서는 Virtual Box 환경에서 우분투 데스크탑 가상 머신 실행에 초점을 맞출 것입니다. [Virtual Box](https://www.virtualbox.org/)를 다운로드하고 링크된 사이트에서 최신 [Ubuntu ISO](https://ubuntu.com/download)를 가져와서 데스크탑 환경을 구축할 수도 있지만, 그렇게 하는 것은 데브옵스답지 않겠죠?
Linux 배포판을 선택한 또 다른 이유는 대부분 무료이며 오픈 소스이기 때문입니다. 또한, 모바일 디바이스와 엔터프라이즈 RedHat Enterprise 서버를 제외하고 가장 널리 배포된 배포판인 우분투를 선택했습니다. 제가 틀렸을 수도 있지만 CentOS의 역사를 살펴보면 우분투가 목록에서 높은 순위에 있으며 매우 간단한 편이라고 생각합니다.
## HashiCorp Vagrant 소개
Vagrant는 CLI 유틸리티로 가상 머신의 수명 주기를 관리합니다. vSphere, Hyper-v, Virtual Box, Docker 등 다양한 플랫폼에서 Vagrant를 사용하여 가상 머신을 생성하고 제거할 수 있습니다. 다른 대안도 있지만, 저는 Virtual Box를 사용할 것입니다.
먼저 해야 할 일은 Vagrant를 컴퓨터에 설치하는 것입니다. [HashiCorp Vagrant](https://www.vagrantup.com/downloads) 다운로드 페이지에서는 사용 가능한 모든 운영 체제를 볼 수 있습니다. 저는 Windows를 사용 중이기 때문에 시스템용 바이너리를 다운로드하여 설치하였습니다.
다음으로 [Virtual Box](https://www.virtualbox.org/wiki/Downloads)를 설치해야 합니다. 이 프로그램은 다양한 운영체제에서 실행할 수 있으며, 윈도우, 맥 OS, 또는 리눅스를 실행할 경우 필요합니다.
두 설치 모두 매우 간단하며, 훌륭한 커뮤니티도 있어서 문제가 발생하면 언제든지 연락하시면 도움을 드릴 수 있습니다.
## 첫 번째 VAGRANTFILE
VAGRANTFILE은 배포하려는 가상 머신의 유형을 정의하고, 해당 머신의 구성과 프로비저닝을 설정합니다.
VAGRANTFILE을 저장하고 정리할 때, 저는 워크스페이스의 폴더에 파일을 저장합니다. 제 시스템에서의 예시를 아래에서 확인하실 수 있습니다. 이 방법을 따라 하면 다른 시스템으로 쉽게 전환할 수 있으며, Linux 데스크탑을 "distro hopping"_(리눅스 사용자들이 사용하는 운영체제를 자주 바꾸는 행위 - 옮긴이)_ 하는 "rabbit hole"_(위험을 대비한 대안을 여러 개 준비하는 행위 - 옮긴이)_ 에도 적합합니다.
![](/2022/Days/Images/Day14_Linux1.png)
VAGRANTFILE을 살펴보고 우리가 현재 만들고 있는 것을 확인해 봅시다.
```
Vagrant.configure("2") do |config|
config.vm.box = "chenhan/ubuntu-desktop-20.04"
config.vm.provider :virtualbox do |v|
v.memory = 8096
v.cpus = 4
v.customize ["modifyvm", :id, "--vram", "128"]
end
end
```
이건 매우 간단한 VAGRANTFILE입니다. 특정 "box"를 원한다는 뜻이며, 이 box는 여러분이 찾고 있는 시스템의 공개 이미지 또는 비공개 빌드일 가능성이 높습니다. 공개적으로 사용 가능한 "box"들의 목록은 [public catalogue of Vagrant boxes](https://app.vagrantup.com/boxes/search)에서 찾을 수 있습니다.
다음 줄에서는 `VirtualBox`라는 특정한 공급자를 사용하고자 합니다. 또한 컴퓨터의 메모리를 `8GB`로, CPU 수를 `4`로 정의합니다. 제 경험상, 디스플레이 문제가 발생하면 비디오 메모리를 추가하는 것이 좋습니다. 이렇게 하면 비디오 메모리를 `128MB`까지 늘릴 수 있지만 시스템에 따라 다를 수 있습니다.
```
v.customize ["modifyvm", :id, "--vram", ""]
```
이 vagrant 파일은 [Linux Folder](/2022/Days/Linux/VAGRANTFILE)에서 확인할 수 있습니다.
## Linux 데스크탑 프로비저닝
제 첫 번째 Linux 데스크탑을 시작하고 실행할 준비가 된 상태입니다. 저는 Windows 운영체제에서 PowerShell을 사용하고 있습니다. 프로젝트 폴더로 이동하여 VAGRANTFILE이 위치한 경로로 이동해주세요. 그곳에서 `vagrant up` 명령어를 입력하면 아래와 같은 내용이 표시됩니다.
![](/2022/Days/Images/Day14_Linux2.png)
추가해야 할 사항은 이 가상 머신에서 네트워크가 `NAT`로 설정된다는 것입니다. 현재 단계에서는 NAT에 대해 알 필요가 없으며, 네트워킹 세션에서 이에 대해 자세히 설명할 계획입니다. 가상 머신을 홈 네트워크에 연결하는 가장 간단한 방법이기도 하며, Virtual Box의 기본 네트워킹 모드입니다. 추가적인 정보는 [Virtual Box documentation](https://www.virtualbox.org/manual/ch06.html#network_nat)에서 확인할 수 있습니다.
`vagrant up`이 완료되면 `vagrant ssh`를 사용하여 새 VM의 터미널로 바로 이동할 수 있습니다.
![](/2022/Days/Images/Day14_Linux3.png)
앞으로 며칠 동안 이곳에서 대부분의 작업을 진행할 예정입니다. 또한 개발자 워크스테이션에 몇 가지 사용자 지정 기능을 추가하여 일상적인 작업을 훨씬 더 간편하게 만들 계획입니다. 비표준 터미널이 없다면, 스스로를 DevOps 전문가로 여길 수 있을까요?
확인을 위해 가상 머신을 선택하면 로그인 프롬프트가 표시되어야 합니다.
![](/2022/Days/Images/Day14_Linux4.png)
여기까지 읽으셨는데 "Username과 Password가 무엇인가요?"라는 질문이 계속 나오신다면?
- Username = vagrant
- Password = vagrant
내일은 터미널에서의 몇 가지 명령어와 그 명령어들이 하는 일에 대해 알아보도록 하겠습니다.
## 자료
- [Learn the Linux Fundamentals - Part 1](https://www.youtube.com/watch?v=kPylihJRG70)
- [Linux for hackers (don't worry you don't need to be a hacker!)](https://www.youtube.com/watch?v=VbEx7B_PTOE)
앞으로 더 많은 자원을 확보할 예정이며, Go 언어 자료와 마찬가지로 일반적으로 무료 콘텐츠를 제공하여 모두가 참여하고 배울 수 있도록 할 것입니다.
다음 글에서는 자주 사용할 수 있는 Linux 환경의 명령어에 대해 살펴볼 것입니다.
[Day 15](day15.md)에서 봐요!

195
2022/ko/Days/day15.md Normal file
View File

@ -0,0 +1,195 @@
---
title: '#90DaysOfDevOps - Linux Commands for DevOps (Actually everyone) - Day 15'
published: false
description: 90DaysOfDevOps - Linux Commands for DevOps (Actually everyone)
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048834
---
## 데브옵스(실제로는 모든 사용자)를 위한 Linux 명령
[어제](day14.md) 터미널에서 몇 가지 명령을 사용하여 작업을 수행하는 데 많은 시간을 할애하게 될 것이라고 언급했습니다.
또한 vagrant 프로비저닝된 VM을 사용하면 `vagrant ssh`를 사용하여 box에 액세스할 수 있다고도 언급했습니다. 프로비저닝한 디렉토리와 동일한 디렉토리에 있어야 합니다.
SSH의 경우 username과 password는 필요하지 않으며, 가상 box 콘솔에 로그인하려는 경우에만 필요합니다.
아래는 우리가 원하는 위치입니다:
![](/2022/Days/Images/Day15_Linux1.png)
## 명령어들
여기서 다루지 않은 명령어도 있습니다. 이러한 명령어를 다루는 문서 페이지가 있지만, 특정 명령에 대한 옵션을 이해해야 할 때는 `man` 페이지를 사용할 수 있습니다. `man` 페이지를 사용하면 이 글에서 다루는 각 명령어에 대한 더 많은 옵션을 찾을 수 있습니다. `man man`을 실행하면 `man` 페이지에 대한 도움말을 볼 수 있습니다. `Q`를 눌러 매뉴얼 페이지를 종료할 수 있습니다.
![](/2022/Days/Images/Day15_Linux2.png)
![](/2022/Days/Images/Day15_Linux3.png)
Windows에서 `관리자 권한으로 실행`을 마우스 오른쪽 버튼으로 클릭으로 하는 것에 익숙하다면, `sudo` 명령어를 비슷하게 생각할 수 있습니다. 이 명령어를 사용하면 명령을 `root` 권한으로 실행하며, 명령 실행 전에 암호를 입력해야 하는 메시지가 표시됩니다.
![](/2022/Days/Images/Day15_Linux4.png)
일회성 작업이 아니라 여러 작업을 수행하며 일시적으로 `sudo` 권한을 유지하려면 어떻게 해야 할까요? `sudo su`를 사용하면 `sudo`와 동일한 권한을 가질 수 있습니다. 그러나 이 방법은 보안상 위험할 수 있습니다. `root` 권한을 오랜 시간 동안 유지하는 것은 위험하기 때문입니다. 테스트 VM에서는 문제가 되지 않을 수 있지만 실제 서버에서는 위험할 수 있습니다. 따라서 작업을 마치면 `exit`를 입력하여 `root` 권한을 해제해야 합니다.
![](/2022/Days/Images/Day15_Linux5.png)
저는 항상 `clear` 명령어를 사용합니다. 이 명령어는 이전 명령의 출력 화면을 모두 지우고 깔끔한 작업 공간을 제공하기 때문에 프롬프트를 맨 위에 위치시키는 것과 같은 효과를 가집니다. 윈도우 운영체제에서는 이 명령어를 `cls`로 사용할 수 있습니다.
![](/2022/Days/Images/Day15_Linux6.png)
이제 시스템 내에서 무언가를 생성한 후에 터미널에서 시각화할 수 있는 몇 가지 명령어를 살펴보겠습니다. 먼저 `mkdir` 명령어를 사용하여 시스템에 폴더를 생성할 수 있습니다. 예를 들어, 홈 디렉토리에 Day15라는 폴더를 생성하려면 `mkdir Day15` 명령어를 사용하면 됩니다.
![](/2022/Days/Images/Day15_Linux7.png)
`cd`를 사용하면 디렉토리를 변경할 수 있으므로, 새로운 디렉토리로 이동하려면 `cd D`에서 탭을 사용하여 `cd Day15` 같이 가능한 디렉토리를 자동 완성할 수 있습니다. 시작 위치로 돌아가려면 `cd ..`을 사용하면 됩니다.
![](/2022/Days/Images/Day15_Linux8.png)
`rmdir` 명령어를 사용하면 디렉토리를 삭제할 수 있습니다. 예를 들어, `rmdir Day15` 명령어를 실행하면 폴더가 삭제됩니다.(단, 해당 폴더가 비어있을 경우에만 작동합니다.)
![](/2022/Days/Images/Day15_Linux9.png)
가끔 파일 시스템의 깊은 곳에서 디렉토리를 찾았지만, 그 위치를 모르는 경우가 있습니다. `pwd` 명령어는 작업 디렉토리의 경로를 출력해주는데, 비밀번호처럼 보이지만 실제로는 "print working directory"의 약자입니다.
![](/2022/Days/Images/Day15_Linux10.png)
폴더와 디렉토리를 만드는 방법은 알고 있지만, 파일을 만드는 방법은 어떨까요? 파일을 생성하는 방법 중 하나는 `touch` 명령을 사용하는 것입니다. 예를 들어, `touch Day15` 명령을 실행하면 파일이 생성됩니다. `mkdir` 명령은 이후에 살펴볼 예정이므로, 지금은 무시하셔도 됩니다.
![](/2022/Days/Images/Day15_Linux11.png)
현재 디렉토리 내 모든 파일과 폴더를 나열하려면 `ls` 명령을 반복해서 사용해야 할 것입니다. 해당 명령어로 방금 생성한 파일이 있는지 확인해보겠습니다.
![](/2022/Days/Images/Day15_Linux12.png)
우리는 리눅스 시스템에서 어떻게 파일을 찾을 수 있을까요? `locate` 명령어를 사용하면 파일 시스템을 검색할 수 있습니다. 만약 `locate Day15`와 같이 입력하면 해당 파일의 위치를 알려줍니다. 또한, 파일이 존재하는데 검색 결과가 없다면 `sudo updatedb` 명령어를 실행하여 파일 시스템의 모든 파일을 인덱싱한 후 다시 `locate` 명령어를 실행하세요. 만약 `locate` 명령어가 없다면 `sudo apt install mlocate` 명령어를 사용하여 설치할 수 있습니다.
![](/2022/Days/Images/Day15_Linux13.png)
리눅스 시스템에서 파일을 찾으려면 어떻게 해야 할까요? `mv` 명령어를 사용하면 파일을 이동할 수 있습니다. 예를 들어, `mv Day15 90DaysOfDevOps` 명령어는 Day15 파일을 90DaysOfDevOps 폴더로 이동시킵니다.
![](/2022/Days/Images/Day15_Linux14.png)
파일을 옮겼는데, 이름을 변경하고 싶다면 어떻게 해야 할까요? 이름을 변경하려면 `mv` 명령어를 다시 사용하면 됩니다. 예를 들어, 대소문자를 변경하려면 `mv Day15 day15`와 같이 입력하고, 파일 이름을 완전히 바꾸려면 `mv day15 AnotherDay`와 같이 입력하면 됩니다. 변경 후에는 `ls` 명령어를 사용하여 파일이 정상적으로 변경되었는지 확인할 수 있습니다.
![](/2022/Days/Images/Day15_Linux15.png)
이제 파일과 디렉토리가 생성되면 디렉토리를 삭제해 보겠습니다. 파일을 삭제하려면 간단히 `rm AnotherDay` 명령어를 사용할 수 있습니다. 폴더를 재귀적으로(하위 폴더까지) 삭제하려면 `rm -R` 명령어를 사용하는 것이 일반적입니다. 또한, `rm -R -f` 명령어를 사용하여 해당 파일을 강제로 삭제할 수도 있습니다. 시스템과 영원한 작별 인사를 하고 싶다면 `sudo rm -R -f /`를 입력하면 됩니다._(주의: 이 명령어는 시스템을 완전히 삭제합니다. - 옮긴이)_
![](/2022/Days/Images/Day15_Linux16.png)
파일 이동에 대해 살펴봤는데, 한 폴더에서 다른 폴더로 파일을 복사하고 싶을 때는 `mv` 명령어 대신 `cp` 명령어를 사용해야 합니다. 이제 `cp Day15 Desktop`으로 파일을 복사할 수 있습니다.
![](/2022/Days/Images/Day15_Linux17.png)
폴더와 파일을 만들었지만, 폴더에는 아직 내용이 없습니다. 내용을 추가하는 몇 가지 방법이 있지만, 가장 쉬운 방법은 `echo`를 사용하는 것입니다. `echo`를 사용하면 터미널에서 많은 내용을 출력할 수 있습니다. 저는 시스템 변수가 설정되어 있는지를 확인하기 위해 시스템 변수를 출력할 때 echo를 자주 사용합니다. 파일에 내용을 추가하려면 `echo "Hello #90DaysOfDevOps" > Day15`를 사용할 수 있습니다. 또는 `echo "Commands are fun!" >> Day15`를 사용할 수도 있습니다.
![](/2022/Days/Images/Day15_Linux18.png)
`cat`은 매우 자주 사용하는 명령어 중 하나입니다. `cat`은 "concatenate(연결)"의 약어로, `cat Day15` 명령어를 사용하여 파일 내용을 확인할 수 있습니다. 이 명령어는 구성 파일을 빠르게 읽을 때 유용합니다.
![](/2022/Days/Images/Day15_Linux19.png)
복잡한 구성 파일에서 모든 줄을 읽는 대신에, 특정한 단어를 찾고 싶거나 찾아야 하는 경우 `grep`을 사용할 수 있습니다. 예를 들면 `cat Day15 | grep "#90DaysOfDevOps"`를 입력하여 파일에서 원하는 단어를 검색할 수 있습니다. 이렇게 하면 빠르게 결과를 얻을 수 있습니다.
![](/2022/Days/Images/Day15_Linux20.png)
제가 `clear` 명령을 자주 사용하여 이전에 실행한 일부 명령을 놓칠 수 있기 때문에, `history` 명령을 사용하여 이전에 실행한 모든 명령을 찾을 수 있습니다. `history -c` 명령은 기록을 제거합니다.
`history`를 실행하고 특정 명령을 선택하려는 경우 `!3`을 사용하여 목록에서 세 번째 명령을 선택할 수 있습니다.
또한 `history | grep "Command"`를 사용하여 특정 명령을 검색할 수도 있습니다.
서버에서 명령이 언제 실행되었는지 추적하려면 히스토리 파일의 각 명령에 날짜와 시간을 추가할 수도 있습니다.
다음 시스템 변수가 이 동작을 제어합니다:
```
HISTTIMEFORMAT="%d-%m-%Y %T "
```
bash_profile에 쉽게 추가할 수 있습니다:
```bash
echo 'export HISTTIMEFORMAT="%d-%m-%Y %T "' >> ~/.bash_profile
```
히스토리 파일을 더 크게 만들 수도 있습니다:
```bash
echo 'export HISTSIZE=100000' >> ~/.bash_profile
echo 'export HISTFILESIZE=10000000' >> ~/.bash_profile
```
![](/2022/Days/Images/Day15_Linux21.png)
비밀번호를 변경해야 하나요? `passwd` 명령어를 사용하여 비밀번호를 변경할 수 있습니다. 비밀번호가 숨겨져 있을 때는 이 명령어를 실행해도 `history`에 표시되지 않지만, 명령에 `-p PASSWORD`가 포함되면 `history`에 표시됩니다.
![](/2022/Days/Images/Day15_Linux22.png)
새로운 사용자를 시스템에 추가하고 싶을 경우 `sudo` 명령어를 사용하여 `sudo useradd NewUser`를 입력해야 합니다.
![](/2022/Days/Images/Day15_Linux23.png)
그룹을 재생성하려면 `sudo` 권한이 필요합니다. `sudo groupadd DevOps` 명령을 사용하여 새로운 사용자를 해당 그룹에 추가하려면 `sudo usermod -a -G DevOps` 명령을 실행하세요. `-a`는 추가를, `-G`는 그룹 이름을 나타냅니다.
![](/2022/Days/Images/Day15_Linux24.png)
`sudo` 그룹에 새로운 사용자를 추가하는 것은 드물기는 하지만, 이를 위해서는 `usermod -a -G sudo NewUser` 명령어를 입력하면 됩니다.
### 권한
읽기, 쓰기, 실행 권한은 Linux 시스템의 모든 파일과 폴더에 대한 권한입니다.
전체 목록입니다:
- 0 = 없음 `---`
- 1 = 실행만 `--X`
- 2 = 쓰기만 `-W-`
- 3 = 쓰기 및 실행 `-WX`
- 4 = 읽기 전용 `R--`
- 5 = 읽기 & 실행 `R-X`
- 6 = 읽기 및 쓰기 `RW-`
- 7 = 읽기, 쓰기 및 실행 `RWX`
또한 `777` 또는 `775`로도 표시되며 이는 위 목록과 동일한 숫자를 나타내지만 각각 **User - Group - Everyone**을 나타냅니다.
파일을 살펴봅시다. `ls -al Day15`를 실행하면 위에서 언급한 3개의 그룹을 볼 수 있으며, 사용자와 그룹은 읽기 및 쓰기 권한을 가지고 있지만 모두 읽기 권한만 있습니다.
![](/2022/Days/Images/Day15_Linux25.png)
시스템에서 많은 양의 바이너리를 생성하고 실행할 수 있는 기능을 제공해야 한다면, `chmod`를 사용하여 해당 바이너리에 대한 권한을 변경할 수 있습니다. 예를 들어, `chmod 750 Day15` 명령어를 실행하면 Day15 파일에 대한 권한을 설정할 수 있으며, `ls -al Day15` 명령어로 권한이 설정되었는지 확인할 수 있습니다. 전체 폴더에 대해 이 작업을 실행하려면 `-R` 옵션을 사용하여 재귀적으로(하위 폴더까지) 설정할 수 있습니다.
![](/2022/Days/Images/Day15_Linux26.png)
파일 소유자를 변경하는 것은 어떨까요? 이 작업에는 `chown`을 사용할 수 있습니다. `Day15`의 소유권을 사용자 `vagrant`에서 `NewUser`로 변경하려면 `sudo chown NewUser Day15`를 다시 `-R`로 실행할 수 있습니다.
![](/2022/Days/Images/Day15_Linux27.png)
특정 데이터만 필요한 출력을 얻을 때, 실제로 사용되는 명령어는 `awk`입니다. 예를 들어, `who`를 실행하면 정보가 포함된 줄을 얻을 수 있지만, 이름만 필요한 경우도 있습니다. 이때는 `who | awk '{print $1}'`를 실행하여 첫 번째 열에 해당하는 이름 목록만 가져올 수 있습니다.
![](/2022/Days/Images/Day15_Linux28.png)
데이터 스트림을 표준 입력에서 읽으려면 커맨드라인을 생성하고 실행해야 합니다. 이렇게 하면 명령의 출력을 가져와 다른 명령의 인수로 전달할 수 있습니다. 이러한 사용 사례에 유용한 도구로 `xargs`가 있습니다. 예를 들어, 실행 가능한 시스템에서 모든 Linux 사용자 계정의 목록을 가져오고 싶다면, `cut -d: -f1 < /etc/passwd`를 실행하면 아래와 같은 긴 목록이 생성됩니다.
![](/2022/Days/Images/Day15_Linux29.png)
이 목록을 압축하려면 `cut -d: -f1 < /etc/passwd | sort | xargs`와 같은 명령을 사용하면 됩니다. `xargs`를 추가로 사용합니다.
![](/2022/Days/Images/Day15_Linux30.png)
이미 언급된 것은 아니지만, `cut` 명령어는 파일에서 각 줄의 섹션을 제거하는 데 사용할 수 있습니다. 이 명령어는 바이트 위치, 문자 또는 필드 단위로 줄의 일부를 잘라내는 데 사용됩니다. 예를 들어, `cut -d " " -f 2 list.txt` 명령어를 사용하면 첫 글자를 제거하고 숫자만 표시할 수 있습니다. 많은 조합이 있기 때문에 수동으로 데이터를 추출하는 것보다 이 명령어를 사용하는 것이 더 빠를 수 있습니다.
![](/2022/Days/Images/Day15_Linux31.png)
명령을 입력을 멈추고 때는 컨트롤 + C를 누르면 해당 줄이 취소되고 새로 시작됩니다.
## 자료
- [Learn the Linux Fundamentals - Part 1](https://www.youtube.com/watch?v=kPylihJRG70)
- [Linux for hackers (don't worry you don't need to be a hacker!)](https://www.youtube.com/watch?v=VbEx7B_PTOE)
[Day 16](day16.md)에서 봐요!
목록이 꽤 길지만, 리눅스 서버를 관리하거나 리눅스 데스크톱에서 작업하는 등 일상에서 이 명령어를 모두 활용한다고 자신 있게 말할 수 있습니다. Windows나 macOS에서는 UI를 탐색하는 것이 간단하지만, 터미널을 통해 모든 것이 이루어지는 Linux 서버에서는 그렇지 않습니다.

166
2022/ko/Days/day16.md Normal file
View File

@ -0,0 +1,166 @@
---
title: '#90DaysOfDevOps - Managing your Linux System, Filesystem & Storage - Day 16'
published: false
description: '90DaysOfDevOps - Managing your Linux System, Filesystem & Storage'
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048702
---
## Linux 시스템, 파일 시스템 및 스토리지 관리
지금까지 우리는 리눅스와 데브옵스에 대한 간략한 개요를 살펴보았고, [Day 14](day14.md)에서는 실습 환경을 설정하였으며, [Day 15](day15.md)에서는 터미널에서 작업을 수행할 때 자주 사용되는 명령어들을 살펴보았습니다.
여기서는 업데이트, 소프트웨어 설치, 시스템 폴더의 용도와 스토리지에 대해 살펴보겠습니다. 이는 이해해야 할 핵심 영역 세 가지입니다.
## 우분투 및 소프트웨어 관리
가장 먼저 살펴볼 사항은 운영체제 업데이트 방법입니다. 대부분의 사용자는 Windows OS와 macOS에서 이 프로세스에 익숙할 것이며, Linux 데스크톱과 서버에서는 조금 다릅니다.
업데이트 및 소프트웨어 설치를 위해 Ubuntu VM에서 사용할 apt 패키지 관리자를 살펴볼 것입니다.
일반적으로, 개발 워크스테이션에서 소프트웨어를 설치하기 전에 중앙 리포지토리에서 사용 가능한 최신 업데이트가 있는지 확인하기 위해 이 명령을 실행하는 것이 좋습니다.
`sudo apt-get update`
![](/2022/Days/Images/Day16_Linux1.png)
이제 최신 OS 업데이트가 설치된 업데이트된 우분투 가상 머신이 생겼습니다. 이제 여기에 몇 가지 소프트웨어를 설치하려고 합니다.
텍스트 배너를 생성하는 프로그램인 `figlet`을 선택해 보겠습니다.
터미널에 `figlet`을 입력하면 시스템에 이 프로그램이 설치되어 있지 않다는 것을 알 수 있습니다.
![](/2022/Days/Images/Day16_Linux2.png)
위의 내용을 보면 시도해 볼 수 있는 몇 가지 `apt` 설치 옵션이 제공된다는 것을 알 수 있습니다. 기본 리포지토리에는 figlet이라는 프로그램이 있기 때문입니다. `sudo apt install figlet`을 시도해 보겠습니다.
![](/2022/Days/Images/Day16_Linux3.png)
이제 아래에서 볼 수 있듯이 `figlet` 앱을 사용할 수 있습니다.
![](/2022/Days/Images/Day16_Linux4.png)
`apt` 패키지 관리자를 사용하여 해당 소프트웨어나 다른 소프트웨어를 제거할 수도 있습니다.
`sudo apt remove figlet`
![](/2022/Days/Images/Day16_Linux5.png)
시스템에 추가할 수 있는 타사 리포지토리도 있는데, 바로 액세스할 수 있는 리포지토리는 Ubuntu 기본 리포지토리입니다.
Ubuntu 가상 머신에 Vagrant를 설치하려면 현재로서는 불가능합니다. 이를 확인하려면 아래의 첫 번째 명령어를 실행하면 됩니다. 그다음에는 HashiCorp 리포지토리를 신뢰하는 키를 추가하고, 리포지토리를 시스템에 추가해야 합니다.
![](/2022/Days/Images/Day16_Linux6.png)
HashiCorp 리포지토리를 추가했으면 이제 `sudo apt install vagrant`를 실행하여 시스템에 vagrant를 설치할 수 있습니다.
![](/2022/Days/Images/Day16_Linux7.png)
우분투에는 소프트웨어 설치와 관련하여 내장된 패키지 관리자를 사용할 수 있는 다양한 옵션이 있으며, 스냅을 이용한 소프트웨어 설치도 가능합니다.
이 글을 통해 Linux에서 OS 및 소프트웨어 설치를 관리하는 방법에 대한 감을 잡으셨기를 바랍니다.
## 파일 시스템 설명
Linux는 구성 파일들로 이루어져 있으며, 변경하고자 하는 내용이 있다면 해당 구성 파일을 수정하면 됩니다.
Windows 운영체제에서는 C 드라이브가 루트 디렉토리입니다. 반면 Linux 운영체제에서는 `/` 디렉토리가 중요한 위치로, 시스템 내의 여러 폴더를 찾을 수 있는 기본적인 디렉토리입니다.
![](/2022/Days/Images/Day16_Linux8.png)
- `/bin` - 바이너리의 줄임말로, 시스템에서 필요한 실행 파일, 도구 및 바이너리가 있는 폴더입니다.
![](/2022/Days/Images/Day16_Linux9.png)
- `/boot` - 시스템 부팅에 필요한 모든 파일이 위치합니다. 부팅 방법과 부팅할 드라이브를 찾을 수 있습니다.
![](/2022/Days/Images/Day16_Linux10.png)
- `/dev` - 이 폴더에서는 장치 정보를 찾을 수 있으며, 디스크 드라이브에 대한 포인터를 찾을 수 있습니다. 일반적으로 `sda`는 기본 OS 디스크입니다.
![](/2022/Days/Images/Day16_Linux11.png)
- `/etc` - 리눅스 시스템에서 가장 중요한 폴더로, 대부분의 구성 파일이 있는 곳입니다.
![](/2022/Days/Images/Day16_Linux12.png)
- `/home` - 사용자 폴더와 파일이 위치하는 곳입니다. 이 폴더에는 vagrant 사용자 폴더뿐만 아니라 명령어 섹션에서 작업한 `Document` 및 `Desktop` 폴더 있습니다.
![](/2022/Days/Images/Day16_Linux13.png)
- `/lib` - `/bin` 폴더가 바이너리 및 실행 파일을 가지고 있다면, 이 폴더는 이러한 파일들에 대한 공유 라이브러리를 가지고 있는 곳입니다.
![](/2022/Days/Images/Day16_Linux14.png)
- `/media` - 이동식 디바이스를 찾을 수 있는 곳입니다.
![](/2022/Days/Images/Day16_Linux15.png)
- `/mnt` - 임시 마운트 지점입니다. 스토리지 섹션에서 자세히 다루겠습니다.
![](/2022/Days/Images/Day16_Linux16.png)
- `/opt` - 옵션 소프트웨어 패키지가 위치하는 폴더입니다. 이 폴더에는 몇 가지 vagrant 및 가상 머신 패키지가 저장되어 있습니다.
![](/2022/Days/Images/Day16_Linux17.png)
- `/proc` - 커널 및 프로세스 정보를 찾을 수 있는 곳으로, `/dev`와 유사합니다.
![](/2022/Days/Images/Day16_Linux18.png)
- `/root` - 액세스 권한을 얻으려면 sudo를 사용해야 하는 루트의 홈 폴더입니다.
![](/2022/Days/Images/Day16_Linux19.png)
- `/run` - 애플리케이션 상태를 위한 자리 표시자입니다.
![](/2022/Days/Images/Day16_Linux20.png)
- `/sbin` - `bin` 폴더와 유사하지만 시스템에서 슈퍼유저 권한이 필요한 도구들이 위치합니다. 즉, `sudo bin`입니다.
![](/2022/Days/Images/Day16_Linux21.png)
- `/tmp` - 임시 파일이 위치하는 폴더입니다.
![](/2022/Days/Images/Day16_Linux22.png)
- `/usr` - 일반 사용자가 소프트웨어 패키지를 설치한 경우, 일반적으로 `/usr/bin` 위치에 설치됩니다.
![](/2022/Days/Images/Day16_Linux23.png)
- `/var` - 애플리케이션은 `bin` 폴더에 설치됩니다. 모든 로그 파일을 저장할 위치가 필요한데, 이 위치가 바로 `/var`입니다.
![](/2022/Days/Images/Day16_Linux24.png)
## 스토리지
Linux 시스템이나 다른 시스템에서도 사용 가능한 디스크와 해당 디스크의 여유 공간을 확인하는 것은 유용합니다. 아래의 명령어 몇 가지는 스토리지를 식별하고 사용 및 관리하는 데 도움이 됩니다.
- `lblk`는 블록 장치를 나열합니다. `sda`는 물리적 디스크이고 `sda1, sda2, sda3`는 해당 디스크의 파티션입니다.
![](/2022/Days/Images/Day16_Linux25.png)
- `df` 명령어는 파티션 정보, 전체 사용량 및 사용 가능한 용량에 대한 더 자세한 정보를 제공합니다. 다른 플래그를 사용하여 구문 분석할 수 있습니다. 일반적으로 `df -h` 명령어를 사용하여 인간이 읽기 쉬운 출력을 생성합니다.
![](/2022/Days/Images/Day16_Linux26.png)
새로운 디스크를 시스템에 추가할 경우, Windows에서와 마찬가지로 디스크 관리에서 디스크를 포맷해야 합니다. 그러나 Linux 터미널에서는 추가된 새 디스크와 관련된 sdb와 함께 `sudo mkfs -t ext4 /dev/sdb` 명령어를 사용하여 포맷할 수 있습니다.
새로 포맷한 디스크를 사용하기 위해서는 `/mnt` 폴더에서 `sudo mkdir NewDisk` 명령어로 디렉토리를 생성한 후, `sudo mount /dev/sdb NewDisk`를 사용하여 해당 위치에 디스크를 마운트해야 합니다.
시스템에서 스토리지를 안전하게 마운트 해제해야 할 때도 있고, 구성에서 그냥 가져와야 할 때도 있습니다. 이 작업은 `sudo umount /dev/sdb` 명령어로 수행할 수 있습니다.
만약에 당신이 해당 디스크를 마운트 해제하고 싶지 않고, 이 디스크를 데이터베이스나 지속적으로 사용할 다른 용도로 사용하려는 경우, 시스템을 재부팅 할 때 그 디스크가 있어야 합니다. 이를 위해, 이 디스크를 `/etc/fstab` 구성 파일에 추가하여 지속성을 유지해야 합니다. 그렇지 않으면 기계가 재부팅될 때 사용할 수 없으며 수동으로 위의 프로세스를 진행해야 합니다. 데이터는 여전히 디스크에 남아 있지만, 이 파일에 구성을 추가하지 않으면 자동으로 마운트되지 않습니다.
`fstab` 구성 파일을 편집한 후 `sudo mount -a` 명령을 실행하여 작동을 확인할 수 있습니다. 오류가 없다면, 이제 변경 사항이 재시작 시에도 지속됩니다.
텍스트 편집기를 사용하여 파일을 편집하는 방법은 다음 세션에서 다루겠습니다.
## 자료
- [Learn the Linux Fundamentals - Part 1](https://www.youtube.com/watch?v=kPylihJRG70)
- [Linux for hackers (don't worry you don't need to be a hacker!)](https://www.youtube.com/watch?v=VbEx7B_PTOE)
[Day 17](day17.md)에서 봐요!

86
2022/ko/Days/day17.md Normal file
View File

@ -0,0 +1,86 @@
---
title: '#90DaysOfDevOps - Text Editors - nano vs vim - Day 17'
published: false
description: 90DaysOfDevOps - Text Editors - nano vs vim
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048703
---
## 텍스트 편집기 - nano vs vim
대부분의 Linux 시스템은 서버로 사용되며, 이러한 시스템에는 GUI가 없습니다. 또한 이전 세션에서 언급했듯이, Linux 시스템은 대부분 구성 파일로 구성되어 있어 변경하려면 이러한 구성 파일을 편집하여 시스템의 모든 것을 변경해야 합니다.
다양한 옵션이 있지만, 가장 일반적으로 사용되는 두 가지 터미널 텍스트 편집기를 소개하고자 합니다. 제 경험상, 빠른 수정 작업에는 `nano`가 더 편리하지만, `vim`은 다양한 기능을 제공하여 더 복잡한 편집 작업을 수행할 수 있습니다.
### nano
- 모든 시스템에서 사용할 수 있는 것은 아닙니다.
- 처음 시작할 때 좋습니다.
`nano 90DaysOfDevOps.txt`를 실행하면 아무 내용도 없는 새 파일이 생성되며, 이 파일에 텍스트를 추가할 수 있습니다. 하단에 도움말 메뉴가 있습니다.
![](/2022/Days/Images/Day17_Linux1.png)
이제 `Ctrl X + enter`를 입력한 다음 `ls`를 실행하면 새 텍스트 파일을 볼 수 있습니다.
![](/2022/Days/Images/Day17_Linux2.png)
이제 해당 파일을 읽기 위해 `cat` 명령어를 실행할 수 있습니다. 그리고 `nano 90DaysOfDevOps.txt` 명령어를 사용하여 파일에 추가 텍스트를 입력하거나 수정할 수 있습니다.
제게 있어서 nano는 구성 파일에 작은 변경 사항을 적용하기 매우 편리한 편집기입니다.
### vim
1976년에 출시된 UNIX 텍스트 편집기인 vi의 형제 버전인 vim은 다양한 기능을 제공하여 가장 일반적인 텍스트 편집기 중 하나일까요?
- 대부분의 Linux 배포판에서 지원됩니다.
- vim만 다루는 7시간짜리 강좌를 찾을 수 있다는 것은 매우 놀랍습니다!
`vim` 명령어를 사용하여 vim 에디터로 이동하거나 새 텍스트 파일을 편집하려면 `vim 90DaysOfDevOps.txt`와 같은 명령어를 실행할 수 있습니다. 그러나 이 경우 하단에 도움말 메뉴가 없음을 확인할 수 있습니다.
첫 번째 질문은 "vim을 어떻게 종료할까요?"일 수 있습니다. 종료 방법으로는 `ESC` 키가 있으며, 변경 사항이 없다면 `:q`를 입력하면 됩니다.
![](/2022/Days/Images/Day17_Linux3.png)
기본적으로 `normal` 모드에서 시작하고 `command, normal, visual, insert` 모드도 있습니다. 텍스트를 추가하려면 `i`를 눌러 `normal` 모드에서 `insert` 모드로 전환해야 합니다. 변경 사항을 저장하고 텍스트를 추가한 후에는 `ESC` 키를 누르고 `:wq`를 입력하면 됩니다.
![](/2022/Days/Images/Day17_Linux4.png)
![](/2022/Days/Images/Day17_Linux5.png)
`cat` 명령으로 변경 사항을 저장했는지 확인할 수 있습니다.
vim은 단축키만 알고 있다면 작은 작업도 매우 빠르게 수행할 수 있는 멋진 기능이 있습니다. 예를 들어, 반복되는 단어 목록을 추가한 후 이를 변경해야 한다고 가정해 봅시다. 구성 파일에서 네트워크 이름이 반복되는 경우, 이를 빠르게 변경하고 싶을 수 있습니다. 이 예시에서는 'day'라는 단어를 사용하고 있습니다.
![](/2022/Days/Images/Day17_Linux6.png)
'day'를 '90DaysOfDevOps'로 변경하려면, `ESC` 키를 누르고 `:%s/Day/90DaysOfDevOps`를 입력하면 됩니다.
![](/2022/Days/Images/Day17_Linux7.png)
이제 Enter 키를 누르면 'day'라는 단어가 '90DaysOfDevOps로' 바뀝니다.
![](/2022/Days/Images/Day17_Linux8.png)
복사 및 붙여넣기는 저에게 정말 큰 도움이 됐습니다. normal 모드에서는 키보드의 `yy`를 사용하여 복사할 수 있으며, 같은 줄에 `p`를 사용하여 붙여넣기하거나, 새 줄에 `P`를 사용하여 붙여넣기할 수 있습니다.
특정 줄을 삭제하려면 삭제할 줄 수를 선택한 후 `dd`를 입력하면 됩니다.
때로는 파일을 검색해야 할 필요가 있습니다. 이전 세션에서 언급한 것처럼 `grep`을 사용할 수 있지만, `/word`를 사용하면 첫 번째 일치 항목을 찾을 수 있으며, `n` 키를 사용하여 다음 항목으로 이동할 수 있습니다.
제가 드릴 수 있는 가장 큰 조언은 가능한 한 직접 사용해 보라는 것입니다.
일반적으로 면접에서 물어보는 질문 중 하나는, "Linux에서 가장 좋아하는 텍스트 편집기는 무엇인가요?" 입니다. 이 질문에 대답하려면 적어도 두 가지 이상의 텍스트 편집기를 알고 있어야 하며, nano에 대한 대답도 괜찮습니다. 이 질문에 대답하는 것은 적어도 텍스트 편집기가 무엇인지 이해했음을 보여주는 것입니다. 하지만 더욱 능숙하게 사용하려면 직접 사용해 보는 것이 좋습니다.
vim에서 방향키로 사용할 수 있는 키는 화살표 키뿐만 아니라 `H,J,K,L`도 사용할 수 있습니다.
## 자료
- [Vim in 100 Seconds](https://www.youtube.com/watch?v=-txKSRn0qeA)
- [Vim tutorial](https://www.youtube.com/watch?v=IiwGbcd8S7I)
- [Learn the Linux Fundamentals - Part 1](https://www.youtube.com/watch?v=kPylihJRG70)
- [Linux for hackers (don't worry you don't need to be a hacker!)](https://www.youtube.com/watch?v=VbEx7B_PTOE)
[Day 18](day18.md)에서 봐요!

213
2022/ko/Days/day18.md Normal file
View File

@ -0,0 +1,213 @@
---
title: '#90DaysOfDevOps - SSH & Web Server - Day 18'
published: false
description: 90DaysOfDevOps - SSH & Web Server
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048733
---
## SSH 및 웹 서버
앞서 언급한 바와 같이, 여러분은 다수의 원격 Linux 서버를 관리할 가능성이 높습니다. 그러므로 이러한 원격 서버와의 연결이 안전한지 확인하는 것이 중요합니다. 본 섹션에서는 원격 시스템과의 보안 터널 구축을 돕기 위해, 모든 사용자가 알아야 할 SSH의 주요 기본 개념들을 살펴볼 것입니다.
- SSH로 연결 설정하기
- 파일 전송하기
- 개인 키 만들기
### SSH 소개
- 보안 shell
- 네트워킹 프로토콜
- 보안 통신 허용
- 모든 네트워크 서비스를 보호
- 일반적으로 원격 command line 액세스에 사용
사실 우린 이미 vagrant 구성과 자동화를 통해 SSH를 사용하고 있었습니다. `vagrant ssh`만 실행해도 원격 가상 머신에 접근할 수 있었습니다.
원격 머신이 워크스테이션과 동일한 시스템이 아니라 원격 위치, 클라우드 기반 시스템이거나 인터넷을 통해서만 접근할 수 있는 데이터 센터에서 실행될 경우, 시스템을 안전하게 관리하기 위한 접근 방법이 필요합니다.
SSH는 클라이언트와 서버 간의 보안 터널을 제공하여 공격자가 정보를 가로챌 수 없게 합니다.
![](/2022/Days/Images/Day18_Linux1.png)
서버에는 항상 특정한 TCP 포트(22)에서 실행되어 대기 중인 서버 측 SSH 서비스가 존재합니다.
올바른 자격증명이나 SSH 키를 가진 클라이언트를 사용하면 해당 서버에 접근할 수 있습니다.
### 시스템에 브리지 네트워크 어댑터 추가하기
현재의 virtual box VM과 함께 사용하려면, 우리 시스템에 브리지 네트워크 어댑터를 추가해야 합니다.
가상 머신을 종료한 다음, Virtual Box 내의 머신을 마우스 우클릭 후 Settings를 선택합니다. 새 창에서 Network를 선택하세요.
![](/2022/Days/Images/Day18_Linux2.png)
이제 가상 머신을 다시 시작하면 로컬 머신에서 IP 주소를 갖게 됩니다. `IP addr` 명령어로 확인할 수 있습니다.
### SSH 서버 실행 확인
우리는 vagrant를 사용해왔기 때문에 SSH가 우리 머신에 이미 설정되어 있다는 것을 알고 있지만, 다음 명령어를 실행하여 확인할 수도 있습니다.
`sudo systemctl status ssh`
![](/2022/Days/Images/Day18_Linux3.png)
시스템에 SSH 서버가 없으면 `sudo apt install OpenSSH-server` 명령어를 사용하여 설치할 수 있습니다.
방화벽이 실행 중인 경우 SSH가 허용되도록 하려면 `sudo ufw allow ssh`를 사용할 수 있습니다. 하지만 vagrant 프로비저닝을 사용하여 자동화했으므로 이 작업은 필요하지 않습니다.
### 원격 접속 - SSH password
이제 SSH 서버가 포트 22에서 들어오는 연결 요청을 수신하도록 설정했고 브리지 네트워킹을 추가했으므로, 로컬 머신의 putty 또는 SSH 클라이언트를 사용하여 SSH로 시스템에 연결할 수 있습니다.
[# PuTTy installation Guide](https://www.cuit.columbia.edu/putty)
![](/2022/Days/Images/Day18_Linux4.png)
Open을 클릭하세요. 이 IP 주소를 통해 처음으로 이 시스템에 연결하는 경우 경고가 표시됩니다. 이 시스템이 우리 것임을 알고 있으므로 Yes를 선택할 수 있습니다.
![](/2022/Days/Images/Day18_Linux5.png)
username(vagrant)과 password(기본 - vagrant)를 입력하라는 메시지가 표시됩니다. 아래에서 SSH 클라이언트(PuTTY)를 사용하여 username과 password로 머신에 연결하는 것을 확인할 수 있습니다.
![](/2022/Days/Images/Day18_Linux6.png)
이제부터 우리의 원격 클라이언트는 VM에 연결되어 있으며, 시스템에서 명령어를 실행할 수 있습니다.
### 원격 접속 - SSH 키
앞서 설명한 방법으로 시스템에 쉽게 액세스할 수 있지만, username과 password에 의존하고 있습니다. 악의적인 사용자가 이 정보와 시스템의 공용 주소 또는 IP를 알게 되면 쉽게 침입할 수 있습니다. 이 때문에 SSH 키가 선호됩니다.
SSH 키를 사용하면, 클라이언트와 서버 모두 이 장치가 신뢰할 수 있는 것임을 알 수 있는 키 쌍을 제공합니다.
키를 생성하는 것은 쉽습니다. 로컬 머신(Windows)에서 다음 명령어를 실행하면 됩니다. 시스템에 SSH 클라이언트가 설치되어 있다면 이 명령어가 작동할 것입니다.
`ssh-keygen -t ed25519`
여기에서 `ed25519`가 무엇인지에 대해 자세히 설명하지는 않겠지만, 암호학에 관심이 있다면 [cryptography](https://en.wikipedia.org/wiki/EdDSA#Ed25519)를 참고해보세요.
![](/2022/Days/Images/Day18_Linux7.png)
생성된 SSH 키는 `C:\Users\micha/.ssh/`에 저장되어 있습니다.
하지만 이 키로 Linux VM에 연결하려면 키를 복사해야 합니다. `ssh-copy-id vagrant@192.168.169.135`를 사용하여 이 작업을 수행할 수 있습니다.
Windows 클라이언트에서 Powershell을 사용하여 키를 생성했지만, Windows에는 `ssh-copy-id`를 실행할 수 없습니다. Windows에서 이 작업을 수행하는 방법이 있으며, 온라인에서 간단한 검색을 통해 대체 방법을 찾을 수 있습니다. 여기서는 Windows 머신에서 git bash를 사용하여 복사하는 것을 보여 드리겠습니다.
![](/2022/Days/Images/Day18_Linux8.png)
이제 Powershell로 돌아와 password 없이 SSH 키로 연결이 작동하는지 테스트할 수 있습니다.
`ssh vagrant@192.168.169.135`
![](/2022/Days/Images/Day18_Linux9.png)
필요한 경우 passphrase를 사용하여 더욱 안전하게 만들 수 있습니다. 또한 password 없이 키 쌍만을 사용하여 SSH를 허용하도록 설정할 수 있습니다. 이렇게 하려면 다음 설정 파일에서 수정하면 됩니다.
`sudo nano /etc/ssh/sshd_config`
여기에 `#` 주석 처리가 되어있는 `PasswordAuthentication yes`라는 줄이 있고, 이를 주석 처리 해제하고 yes를 no로 변경해야 합니다. 그런 다음 `sudo systemctl reload sshd`를 실행해서 SSH 서비스를 다시 로드해야 합니다.
## 웹 서버 설정하기
위에서 설명한 SSH와는 별개로, 이번에는 웹 서버를 구축하는 방법을 다루고자 합니다. 처음에는 조금 어려워 보일 수 있지만, 실제로는 그렇지 않습니다.
리눅스 가상 머신을 이미 구축해 두었다고 가정하고, 이 가상 머신에 아파치 웹 서버를 추가하여 내부 네트워크에서 접근할 수 있는 간단한 웹 사이트를 호스팅하려고 합니다. 인터넷에서 접근할 수 있는 웹 사이트는 아니며, 그에 대한 내용은 여기서 다루지 않습니다.
이 과정은 LAMP 스택이라고도 불립니다.
- **L**inux 운영 체제
- **A**pache 웹 서버
- **M**ySQL 데이터베이스
- **P**HP
### Apache2
Apache2는 오픈 소스 HTTP 서버입니다. 아래 명령어를 사용하여 Apache2를 설치할 수 있습니다.
`sudo apt-get install apache2`
Apache2가 정상적으로 설치되었는지 확인하려면 `sudo service apache2 restart`를 실행합니다.
SSH 통합 네트워크 주소를 사용하여 브라우저에서 해당 주소로 이동합니다. 예를 들면 `http://192.168.169.135/`와 같습니다.
![](/2022/Days/Images/Day18_Linux10.png)
### MySQL
MySQL은 웹 사이트의 데이터를 저장하는 데이터베이스입니다. `sudo apt-get install mysql-server` 명령어를 사용하여 MySQL을 설치합니다.
### PHP
PHP는 서버 측 스크립팅 언어로, MySQL 데이터베이스와 상호 작용하기 위해 사용합니다. PHP 및 종속성을 설치하려면 `sudo apt-get install php libapache2-mod-php php-mysql`을 사용합니다.
기본적으로 Apache는 index.html을 사용하지만, 대신 index.php를 사용하도록 설정하려고 합니다.
`sudo nano /etc/apache2/mods-enabled/dir.conf`를 사용하여 index.php를 목록의 첫 번째 항목으로 이동시킵니다.
![](/2022/Days/Images/Day18_Linux11.png)
Apache2 서비스를 다시 시작합니다. `sudo systemctl restart apache2`
이제 PHP가 올바르게 구성되었는지 확인해 보겠습니다. 다음 명령어를 사용하여 새 파일을 생성합니다.
`sudo nano /var/www/html/90Days.php`
아래 내용을 복사한 후 Ctrl + X를 눌러 종료하고 파일을 저장합니다.
```php
<?php
phpinfo();
?>
```
다음 URL로 이동하여 PHP가 올바르게 구성되었는지 확인합니다. `http://192.168.169.135/90Days.php` 이 주소로 이동하면 PHP가 올바르게 설정되었음을 확인할 수 있는 화면이 표시됩니다.
![](/2022/Days/Images/Day18_Linux12.png)
### 워드프레스 설치
LAMP 스택에 워드프레스를 설치하기 위해 [How to install WordPress on Ubuntu with LAMP](https://blog.ssdnodes.com/blog/how-to-install-wordpress-on-ubuntu-18-04-with-lamp-tutorial/)을 참고하였습니다. 이 글에 나와 있는 명령어들은 아래와 같습니다.
`sudo mysql -u root -p`
`CREATE DATABASE wordpressdb;`
`CREATE USER 'admin-user'@'localhost' IDENTIFIED BY 'password';`
`GRANT ALL PRIVILEGES ON wordpressdb.* TO 'admin-user'@'localhost';`
`FLUSH PRIVILEGES;`
`EXIT;`
`sudo apt install php-curl php-gd php-mbstring php-xml php-xmlrpc php-soap php-intl php-zip`
`sudo systemctl restart apache2`
`cd /var/www`
`sudo curl -O https://wordpress.org/latest.tar.gz`
`sudo tar -xvf latest.tar.gz`
`sudo rm latest.tar.gz`
위 링크의 Step 4에 도달했습니다. 워드프레스 디렉토리에 대한 모든 권한이 올바르게 설정되어 있는지 확인해야 합니다.
내부 네트워크 전용이므로 이 단계에서 "generate security keys"를 할 필요가 없습니다. 아파치 구성을 워드프레스로 변경하는 Step 5로 이동합니다.
모든 설정이 올바르게 구성되어 있다면, 내부 네트워크 주소를 통해 워드프레스 설치를 진행할 수 있습니다.
## 자료
- [Client SSH GUI - Remmina](https://remmina.org/)
- [The Beginner's guide to SSH](https://www.youtube.com/watch?v=2QXkrLVsRmk)
- [Vim in 100 Seconds](https://www.youtube.com/watch?v=-txKSRn0qeA)
- [Vim tutorial](https://www.youtube.com/watch?v=IiwGbcd8S7I)
- [Learn the Linux Fundamentals - Part 1](https://www.youtube.com/watch?v=kPylihJRG70)
- [Linux for hackers (don't worry you don't need to be a hacker!)](https://www.youtube.com/watch?v=VbEx7B_PTOE)
[Day 19](day19.md)에서 봐요!

310
2022/ko/Days/day19.md Normal file
View File

@ -0,0 +1,310 @@
---
title: '#90DaysOfDevOps - Automate tasks with bash scripts - Day 19'
published: false
description: 90DaysOfDevOps - Automate tasks with bash scripts
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048774
---
## bash 스크립팅을 이용한 작업 자동화
오늘 사용할 shell은 bash이지만, 내일 ZSH에 대해 다룰 때 다른 shell도 다룰 예정입니다.
BASH - **B**ourne **A**gain **Sh**ell
프로그래밍 언어처럼 shell 스크립팅에도 거의 일주일 동안의 섹션을 쓸 수 있습니다. bash는 다른 자동화 도구와 함께 작업하는 기능을 제공합니다.
여전히 많은 사람들이 복잡한 shell 스크립트를 만들어 무언가를 실행하게 하고, 비즈니스에서 가장 중요한 부분을 이 스크립트에 의존하고 있다고 합니다. 하지만 이런 이유로 shell/bash 스크립팅을 이해해야 한다고 말하는 것은 아닙니다. 자동화 도구와 함께 사용하고 ad-hoc(특별한) 작업을 위해 shell/bash 스크립팅을 배워야 합니다.
이 섹션에서 사용한 예로, 매주 월요일 아침에 리눅스 VM을 새로 생성하고, 해당 리눅스 기계에 필요한 모든 소프트웨어 스택을 추가하는 등의 작업을 할 수 있는 간단한 bash 스크립트로 VAGRANTFILE을 감쌀 수 있습니다.
면접에서 스크립팅 경험 관련 질문이 점점 더 많아지고 있다는 소식도 종종 듣고 있습니다.
### 시작하기
이 90일 동안 다루는 많은 것들과 마찬가지로, 진정한 배움은 경험을 통해 알게 됩니다. 실제로 경험을 통해 배우면 기억에 오래 남습니다.
우선, 텍스트 에디터가 필요합니다. [Day 17](day17.md)에 가장 일반적인 텍스트 에디터 두 가지와 그것들을 어떻게 사용하는지에 대해 다뤘습니다.
첫 번째 shell 스크립트를 생성해봅시다.
`touch 90DaysOfDevOps.sh`
그다음 `nano 90DaysOfDevOps.sh`를 입력하면 nano에서 새로운 빈 shell 스크립트가 열립니다. 여기서 원하는 텍스트 에디터를 선택할 수 있습니다.
모든 bash 스크립트의 첫 줄은 다음과 같아야 합니다: `#!/usr/bin/bash`(bash 바이너리의 경로입니다.)
터미널에서 `which bash`를 실행하여 이를 확인해야 합니다. Ubuntu를 사용하지 않는 경우 터미널에서는 `whereis bash`도 시도해 볼 수 있습니다.
그러나 이미 생성된 shell 스크립트는 다른 경로들이 있을 수도 있습니다:
- `#!/bin/bash`
- `#!/usr/bin/env bash`
스크립트의 다음 줄에는 주석을 추가하여 스크립트의 목적이나 스크립트에 대한 정보를 제공합니다. `#`을 사용하면 코드의 특정 줄에 주석을 달고 다가올 명령어가 무엇을 할 것인지 설명할 수 있습니다. 주석을 많이 남길수록 사용자 경험이 향상된다고 생각합니다. 특히 공유할 때 그렇습니다.
리눅스 섹션에서 설치한 figlet 프로그램을 사용하여 스크립트에서 asci 아트를 만들 때도 있습니다.
![](/2022/Days/Images/Day19_Linux1.png)
이 리눅스 섹션에서 앞서 다룬 모든 명령어들([Day 15](day15.md))은 스크립트를 테스트하는 간단한 명령어로 사용할 수 있습니다.
스크립트에 간단한 코드 블록을 추가해 봅시다.
```bash
mkdir 90DaysOfDevOps
cd 90DaysOfDevOps
touch Day19
ls
```
텍스트 에디터를 저장하고 종료한 후, `./90DaysOfDevOps.sh`를 실행하면 권한이 거부되었다는 메시지가 표시됩니다. `ls -al` 명령을 사용하여 이 파일의 권한을 확인할 수 있는데 이 파일에 실행 권한이 없음을 확인할 수 있습니다.
![](/2022/Days/Images/Day19_Linux2.png)
`chmod +x 90DaysOfDevOps.sh`를 사용하여 이를 변경한 다음 `x`인 것을 봤을 때 스크립트를 실행할 수 있음을 확인할 수 있습니다.
![](/2022/Days/Images/Day19_Linux3.png)
`./90DaysOfDevOps.sh`를 사용하여 스크립트를 다시 실행할 수 있습니다. 스크립트를 실행한 후 새 디렉토리가 생성되고 해당 디렉토리로 이동한 다음 새 파일이 생성됩니다.
![](/2022/Days/Images/Day19_Linux4.png)
기본적인 것들이지만, 다른 도구를 호출하여 일상적인 작업을 쉽게 만들고 자동화하는 데 사용할 수 있다는 것을 알 수 있습니다.
### 변수, 조건문
이 섹션의 대부분은 Golang을 배울 때 다룬 것과 중복되지만, 여기에서 다시 살펴볼 가치가 있다고 생각합니다.
- ### 변수
변수를 사용하면 스크립트 내에서 반복되는 특정 용어를 한 번만 정의할 수 있습니다.
스크립트에 변수를 추가하려면 다음과 같이 새로운 줄에 입력하면 됩니다.
`challenge="90DaysOfDevOps"`
이렇게 하면 코드에서 `$challenge`를 사용할 때 변수가 변경되면 전체에 반영됩니다.
![](/2022/Days/Images/Day19_Linux5.png)
이제 `sh` 스크립트를 실행하면 스크립트에 추가된 출력이 표시됩니다.
![](/2022/Days/Images/Day19_Linux6.png)
또한 다음과 같이 사용자 입력을 요청하여 변수를 설정할 수도 있습니다:
```bash
echo "Enter your name"
read name
```
이렇게 하면 입력이 변수 `$name`으로 정의됩니다. 이후에 이를 사용할 수 있습니다.
- ### 조건문
우리는 도전 과제에 참여한 사람과 그들이 완료한 날짜 수를 알아보고 싶을 수도 있습니다. 이를 `if`, `if-else`, `else-if` 조건문을 사용해 정의할 수 있습니다. 아래 스크립트에 이를 정의한 것을 확인할 수 있습니다.
```bash
#!/bin/bash
# ___ ___ ____ ___ __ ____ ___
# / _ \ / _ \| _ \ __ _ _ _ ___ / _ \ / _| _ \ _____ __/ _ \ _ __ ___
#| (_) | | | | | | |/ _` | | | / __| | | | |_| | | |/ _ \ \ / / | | | '_ \/ __|
# \__, | |_| | |_| | (_| | |_| \__ \ |_| | _| |_| | __/\ V /| |_| | |_) \__ \
# /_/ \___/|____/ \__,_|\__, |___/\___/|_| |____/ \___| \_/ \___/| .__/|___/
# |___/ |_|
#
# 이 스크립트는 bash 스크립팅을 시연하기 위한 것입니다!
# 정의할 변수
ChallengeName=#90DaysOfDevOps
TotalDays=90
# 사용자 입력
echo "Enter Your Name"
read name
echo "Welcome $name to $ChallengeName"
echo "How Many Days of the $ChallengeName challenge have you completed?"
read DaysCompleted
if [ $DaysCompleted -eq 90 ]
then
echo "You have finished, well done"
elif [ $DaysCompleted -lt 90 ]
then
echo "Keep going you are doing great"
else
echo "You have entered the wrong amount of days"
fi
```
다음 단계로 이동하기 위해 값을 비교하거나 확인하는 과정을 위에서 볼 수 있습니다. 여기서 주목할 만한 다양한 옵션이 있습니다.
- `eq` - 두 값이 같으면 TRUE 반환
- `ne` - 두 값이 같지 않으면 TRUE 반환
- `gt` - 첫 번째 값이 두 번째 값보다 크면 TRUE 반환
- `ge` - 첫 번째 값이 두 번째 값보다 크거나 같으면 TRUE 반환
- `lt` - 첫 번째 값이 두 번째 값보다 작으면 TRUE 반환
- `le` - 첫 번째 값이 두 번째 값보다 작거나 같으면 TRUE 반환
파일 및 폴더에 대한 정보를 결정하기 위해 bash 스크립팅을 사용할 수도 있습니다. 이를 파일 조건이라고 합니다.
- `-d file` 파일이 디렉토리인 경우 True
- `-e file` 파일이 존재하는 경우 True
- `-f file` 제공된 문자열이 파일인 경우 True
- `-g file` 파일에 그룹 ID가 설정된 경우 True
- `-r file` 파일이 읽을 수 있는 경우 True
- `-s file` 파일의 크기가 0이 아닌 경우 True
```bash
FILE="90DaysOfDevOps.txt"
if [ -f "$FILE" ]
then
echo "$FILE is a file"
else
echo "$FILE is not a file"
fi
```
![](/2022/Days/Images/Day19_Linux7.png)
디렉토리에 파일이 아직 있다면 첫 번째 echo를 반환해야 합니다. 그러나 파일을 제거하면 두 번째 echo를 반환하게 됩니다.
![](/2022/Days/Images/Day19_Linux8.png)
특정 항목을 시스템에서 검색할 때 시간을 절약하는 데 사용할 수 있는 방법을 확인하실 수 있습니다.
GitHub에서 놀라운 저장소를 발견했습니다. 많은 스크립트를 가진 것 같습니다. [DevOps Bash Tools](https://github.com/HariSekhon/DevOps-Bash-tools/blob/master/README.md)
### 예제
**시나리오**: 우리 회사는 "90DaysOfDevOps"라는 이름을 가지고 있으며, 이제 확장할 때가 왔습니다. 1인 팀에서 다음 몇 주 동안 더 많은 사람으로 늘리려고 합니다. 지금까지 나만이 온보딩 과정을 알고 있으므로, 이러한 작업 중 일부를 자동화하여 병목 현상을 줄이고자 합니다.
**요구 사항**:
- 사용자 이름이 커맨드 라인 인수로 전달될 수 있습니다.
- 커맨드 라인 인수의 이름으로 사용자가 생성됩니다.
- password가 커맨드 라인 인수로 전달될 수 있습니다.
- 사용자의 password가 설정됩니다.
- 계정 생성이 성공적으로 이루어졌음을 나타내는 메시지가 표시됩니다.
먼저 `touch create_user.sh`를 사용하여 shell 스크립트를 생성합시다.
계속 진행하기 전에, `chmod +x create_user.sh`를 사용하여 이를 실행 가능하게 만들어줍시다.
그런 다음 `nano create_user.sh`를 사용하여 설정한 시나리오에 대한 스크립트 편집을 시작하겠습니다.
첫 번째 요구 사항인 "사용자 이름이 커맨드 라인 인수로 전달될 수 있습니다."는 다음과 같이 사용할 수 있습니다.
```bash
#! /usr/bin/bash
# 사용자 이름이 커맨드 라인 인수로 전달될 수 있습니다.
echo "$1"
```
![](/2022/Days/Images/Day19_Linux9.png)
이를 실행하려면 `./create_user.sh Michael`을 사용하십시오. Michael 대신에 당신의 이름을 사용하세요.
![](/2022/Days/Images/Day19_Linux10.png)
다음으로 두 번째 요구 사항인 "커맨드 라인 인수의 이름으로 사용자가 생성됩니다."를 처리할 수 있습니다. 이는 `useradd` 명령어를 사용하여 수행할 수 있습니다. `-m` 옵션은 사용자 홈 디렉토리를 /home/username으로 생성하기 위한 것입니다.
```bash
#! /usr/bin/bash
# 사용자 이름이 커맨드 라인 인수로 전달될 수 있습니다.
echo "$1 user account being created."
# 커맨드 라인 인수의 이름으로 사용자가 생성됩니다.
sudo useradd -m "$1"
```
경고: 사용자 계정 이름을 제공하지 않으면 `$1` 변수가 채워지지 않아 오류가 발생합니다.
계정이 생성되었는지 확인하려면 `awk -F: '{ print $1}' /etc/passwd` 명령을 사용합니다.
![](/2022/Days/Images/Day19_Linux11.png)
다음 요구 사항은 "password가 커맨드 라인 인수로 전달될 수 있습니다."입니다. 먼저, 이는 실제 환경에서는 절대 사용하지 않는 것이 좋습니다. 이는 단지 연습을 위한 것이며, 이를 통해 요구 사항을 이해할 수 있습니다.
```bash
#! /usr/bin/bash
# 사용자 이름이 커맨드 라인 인수로 전달될 수 있습니다.
echo "$1 user account being created."
# 커맨드 라인 인수의 이름으로 사용자가 생성됩니다.
sudo useradd -m "$1"
# password가 커맨드 라인 인수로 전달될 수 있습니다.
sudo chpasswd <<< "$1":"$2"
```
두 개의 파라미터로 이 스크립트를 실행하려면 `./create_user.sh 90DaysOfDevOps password`를 사용하세요.
아래 이미지에서 스크립트를 실행하여 사용자와 password를 생성한 다음, 수동으로 해당 사용자로 전환하고 `whoami` 명령으로 확인했다는 것을 알 수 있습니다.
![](/2022/Days/Images/Day19_Linux12.png)
마지막 요구 사항은 "계정 생성이 성공적으로 이루어졌음을 나타내는 메시지가 표시됩니다."입니다. 우리는 이미 코드의 첫 번째 줄에 이를 포함하고 있으며, 위의 스크린샷에서 `90DaysOfDevOps user account being created`라는 메시지가 표시되는 것을 볼 수 있습니다. 이는 `$1` 매개변수로 테스트할 때 남겨진 것입니다.
이제 이 스크립트를 사용하여 리눅스 시스템에 새 사용자를 빠르게 온보딩하고 설정할 수 있습니다. 하지만 기존 사용자 중 몇 명이 이 과정을 거쳐 다른 사람들에게 새 사용자 이름이나 password를 알려주는 대신 앞서 다룬 사용자 입력을 추가하여 변수를 수집할 수 있습니다.
```bash
#! /usr/bin/bash
echo "What is your intended username?"
read username
echo "What is your password"
read password
# 사용자 이름이 커맨드 라인 인수로 전달될 수 있습니다.
echo "$username user account being created."
# 커맨드 라인 인수의 이름으로 사용자가 생성됩니다.
sudo useradd -m $username
# password가 커맨드 라인 인수로 전달될 수 있습니다.
sudo chpasswd <<< $username:$password
```
단계를 더욱 인터랙티브하게 만들면
![](/2022/Days/Images/Day19_Linux14.png)
마무리하기 위해, 새 사용자 계정이 생성되었다는 성공적인 출력을 원할 수도 있습니다.
![](/2022/Days/Images/Day19_Linux15.png)
한 가지 눈에 띄는 점은 입력 시 비밀번호가 표시된다는 점인데, 코드 `read -s password`에서의 `-s` 플래그를 사용하여 이를 숨길 수 있습니다.
![](/2022/Days/Images/Day19_Linux16.png)
실험 목적으로 생성한 사용자를 삭제하려면 `sudo userdel test_user`를 사용할 수 있습니다.
[예제 스크립트](/2022/Days/Linux/create-user.sh)
한 번 더 강조하고 싶은 바는, 이것은 shell 스크립팅이 유연하게 활용될 수 있는 다양한 용도를 갖는다는 것을 강조하기 위해 만들어진 것이라는 것입니다.
매일, 매주, 매월 반복되는 작업이 어떤 것이 있는지 생각해보고, 그것을 어떻게 더 잘 자동화할 수 있을지 생각해보세요. 첫 번째 옵션은 주로 bash 스크립트를 사용하는 것이며, 그 이후에는 더 복잡한 영역으로 이동할 수 있습니다.
저는 제 로컬 머신에서 minikube를 사용하여 쿠버네티스 클러스터를 빠르게 생성하고 데이터 서비스 및 Kasten K10을 사용하여 데이터 관리에 대한 요구 사항과 필요성을 보여주기 위한 매우 간단한 [bash 파일](https://github.com/MichaelCade/project_pace/blob/main/singlecluster_demo.sh)을 생성했습니다만, 아직 쿠버네티스를 다루지 않았기 때문에 여기서 다루는 것이 적절하지 않다고 생각합니다.
## 자료
- [Bash in 100 seconds](https://www.youtube.com/watch?v=I4EWvMFj37g)
- [Bash script with practical examples - Full Course](https://www.youtube.com/watch?v=TPRSJbtfK4M)
- [Client SSH GUI - Remmina](https://remmina.org/)
- [The Beginner's guide to SSH](https://www.youtube.com/watch?v=2QXkrLVsRmk)
- [Vim in 100 Seconds](https://www.youtube.com/watch?v=-txKSRn0qeA)
- [Vim tutorial](https://www.youtube.com/watch?v=IiwGbcd8S7I)
- [Learn the Linux Fundamentals - Part 1](https://www.youtube.com/watch?v=kPylihJRG70)
- [Linux for hackers (don't worry you don't need to be a hacker!)](https://www.youtube.com/watch?v=VbEx7B_PTOE)
[Day 20](day20.md)에서 봐요!

166
2022/ko/Days/day20.md Normal file
View File

@ -0,0 +1,166 @@
---
title: '#90DaysOfDevOps - Dev workstation setup - All the pretty things - Day 20'
published: false
description: 90DaysOfDevOps - Dev workstation setup - All the pretty things
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048734
---
## 개발 워크스테이션 설정 - 예쁜 모든 것들
이 내용은 Linux 서버를 설정하는 것과 혼동되지 않도록 주의해야 하며, Linux 데스크톱의 선택성 및 유연성을 보여주고자 합니다.
저는 거의 일 년 동안 Linux 데스크톱을 사용해 왔고, 외관과 느낌 측면에서 원하는 대로 구성했습니다. Ubuntu VM과 Virtual Box를 이용하여 사용자 지정 맞춤 구성을 해봅시다.
더 쉽게 따라 할 수 있는 분들을 위해 설명 외의 부분에 대한 YouTube 동영상을 준비했습니다.
[![Click to access YouTube Video](/2022/Days/Images/Day20_YouTube.png)](https://youtu.be/jeEslAtHfKc)
기본적으로 시스템은 아래와 같이 표시됩니다.
![](/2022/Days/Images/Day20_Linux1.png)
기본 bash shell은 아래에서 볼 수 있습니다.
![](/2022/Days/Images/Day20_Linux2.png)
이 중 많은 부분이 dotfiles와 관련이 있으며, 이 시리즈의 마지막 Linux 세션에서 다루게 됐습니다.
### dotfiles
먼저 dotfiles에 대해 알아보고 싶습니다. 리눅스가 구성 파일로 구성되어 있다고 이전에 언급했습니다. 이 dotfiles는 리눅스 시스템과 응용 프로그램의 구성 파일입니다.
또한 dotfiles는 데스크톱을 꾸미고 예쁘게 만드는 데 사용되는 것뿐만 아니라 생산성을 돕는 구성 변경 및 설정이 있다고 덧붙입니다.
앞서 언급했듯이 많은 소프트웨어 프로그램들이 이 dotfiles에 구성을 저장합니다. 이 dotfiles는 기능 관리를 돕습니다.
각 dotfile은 `.`으로 시작합니다. 이름이 어떻게 지어졌는지 짐작할 수 있을 것입니다.
지금까지 우리는 shell로서 bash를 사용해 왔으므로 홈 폴더에 .bashrc와 .bash_profile이 있을 것입니다. 아래에서 시스템에 있는 몇 가지 dotfiles를 볼 수 있습니다.
![](/2022/Days/Images/Day20_Linux3.png)
우리는 shell을 변경할 것이므로, 나중에 새로운 `.zshrc` dotfile을 볼 수 있습니다.
dotfiles은 구성 파일임을 알 수 있습니다. 우리는 이것들을 사용하여 명령 프롬프트에 별칭을 추가하거나 다른 위치로 경로를 추가할 수 있습니다. 일부 사람들은 자신의 dotfiles를 공개적으로 사용할 수 있도록 게시합니다. 제 dotfiles는 [MichaelCade/dotfiles](https://github.com/MichaelCade/dotfiles)에서 찾을 수 있습니다. 여기에는 저의 맞춤형 `.zshrc` 파일, 제가 선택한 터미널인 terminator의 구성 파일이 폴더에 있고, 그리고 일부 배경 옵션이 있습니다.
### ZSH
앞에서 언급했듯이, 지금까지의 상호 작용에서 우리는 기본 shell인 Ubuntu와 함께 제공되는 bash shell을 사용했습니다. ZSH는 매우 유사하지만, bash보다 몇 가지 이점이 있습니다.
Zsh에는 대화형 탭 완성, 자동 파일 검색, 정규식 통합, 명령 범위를 정의하는 고급 단축어 및 풍부한 테마 엔진과 같은 기능이 있습니다.
우리는 `apt` 패키지 관리자를 사용하여 시스템에 zsh를 설치할 수 있습니다. bash 터미널에서 `sudo apt install zsh`를 실행해 봅시다. 이 작업은 VM 콘솔 내에서 수행할 예정이며 SSH를 통해 연결하는 대신에 진행합니다.
설치 명령이 완료되면 터미널 내에서 `zsh`를 실행할 수 있으며, 이렇게 하면 shell 구성 스크립트가 시작됩니다.
![](/2022/Days/Images/Day20_Linux4.png)
위 질문에 대해 `1`을 선택했고, 이제 더 많은 옵션을 볼 수 있습니다.
![](/2022/Days/Images/Day20_Linux5.png)
이 메뉴에서 몇 가지 기본 제공 편집을 통해 필요에 따라 ZSH를 구성할 수 있음을 알 수 있습니다.
`0`으로 종료한 다음 `ls -al | grep .zshrc`를 사용하면 새로운 구성 파일이 있는 것을 확인할 수 있습니다.
이제 우리는 터미널을 열 때마다 zsh를 기본 shell로 사용하려고 합니다. 이를 위해 shell을 변경하는 `chsh -s $(which zsh)` 명령을 실행할 수 있습니다. 그런 다음 로그아웃하고 다시 로그인하여 변경 사항이 적용되도록 해야 합니다.
로그인 후 터미널을 열면 아래와 같이 보일 것입니다. 또한 `which $SHELL`을 실행하여 shell이 변경되었음을 확인할 수 있습니다.
![](/2022/Days/Images/Day20_Linux6.png)
일반적으로 저는 각 Ubuntu 데스크톱에서 이 단계를 수행하며, 이 외에도 zsh shell이 bash보다 약간 빠르다고 느낍니다.
### OhMyZSH
다음으로 터미널 내에서 조금 더 나은 모습과 추가 기능을 제공하고자 합니다.
OhMyZSH는 zsh 구성을 관리하기 위한 무료 오픈 소스 프레임워크입니다. 플러그인, 테마 등 많은 것들이 있어 zsh shell과 상호 작용하는 것이 훨씬 재밌습니다.
[ohmyzsh](https://ohmyz.sh/)에 대한 자세한 정보를 확인해보세요.
Oh My ZSH를 설치합시다. `curl`, `wget` 또는 `fetch` 중에서 선택할 수 있는데, 첫 번째 두 가지는 시스템에서 사용 가능하지만, `curl`로 시작하겠습니다.
`sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"`
위 명령을 실행하면 아래와 같은 출력을 볼 수 있습니다.
![](/2022/Days/Images/Day20_Linux7.png)
이제 우리의 경험을 위한 테마를 시작할 수 있습니다. Oh My ZSH에는 100개 이상의 테마가 포함되어 있지만, 저의 모든 애플리케이션과 모든 것에 대한 기본값은 Dracula 테마입니다.
또한 Oh My ZSH를 사용할 때 다음 두 가지 플러그인을 반드시 사용해야 한다고 강조하고 싶습니다.
`git clone https://github.com/zsh-users/zsh-autosuggestions.git $ZSH_CUSTOM/plugins/zsh-autosuggestions`
`git clone https://github.com/zsh-users/zsh-syntax-highlighting.git $ZSH_CUSTOM/plugins/zsh-syntax-highlighting`
`nano ~/.zshrc`
플러그인을 편집하여 이제 `plugins=(git zsh-autosuggestions zsh-syntax-highlighting)`를 포함하도록 합니다.
### Gnome Extensions
저는 Gnome Extensions도 사용하며, 특히 아래 목록을 사용합니다.
[Gnome extensions](https://extensions.gnome.org)
- Caffeine
- CPU Power Manager
- Dash to Dock
- Desktop Icons
- User Themes
## 소프트웨어 설치
`apt`를 사용하여 제 컴퓨터에 설치한 프로그램 목록입니다.
- VSCode
- azure-cli
- containerd.io
- docker
- docker-ce
- google-cloud-sdk
- insomnia
- packer
- terminator
- terraform
- vagrant
### Dracula 테마
[Dracula Theme](https://draculatheme.com/)는 제가 유일하게 사용하는 테마입니다. 깔끔하고 명확한 모습이며 모든 것이 훌륭해 보입니다. 이 사이트에서는 컴퓨터에서 사용하는 다양한 프로그램을 지원합니다.
위 링크에서 zsh를 검색하면 최소 두 가지 옵션을 찾을 수 있습니다.
수동 설치 또는 git을 사용하여 설치할 수 있는 지침을 따릅니다. 그런 다음 아래와 같이 `.zshrc` 구성 파일을 편집해야 합니다.
![](/2022/Days/Images/Day20_Linux8.png)
다음으로 [Gnome Terminal Dracula theme](https://draculatheme.com/gnome-terminal)를 원하게 될 텐데, 여기에 모든 지침이 나와 있습니다.
모든 단계를 문서화하는 데 오랜 시간이 걸릴 것이므로, 저는 과정을 동영상으로 제공했습니다.(아래 이미지를 클릭하세요)
[![](/2022/Days/Images/Day20_YouTube.png)](https://youtu.be/jeEslAtHfKc)
여기까지 왔다면, 이제 #90DaysOfDevOps의 Linux 섹션을 완료했습니다. 다시 한번, 피드백과 추가 자료에 대해서는 언제든지 환영입니다.
여기에 적는 것보다 동영상을 통해 많은 단계를 보여드리는 것이 더 쉬울거라고 생각했는데, 이에 대해 어떻게 생각하시나요? 저는 이 글을 다시 읽어보고 가능하면 동영상 연습을 만들어서 우리가 다룬 내용들을 더 잘 설명하고 보여줄 수 있도록 하고자 합니다. 어떻게 생각하시나요?
## 자료
- [Bash in 100 seconds](https://www.youtube.com/watch?v=I4EWvMFj37g)
- [Bash script with practical examples - Full Course](https://www.youtube.com/watch?v=TPRSJbtfK4M)
- [Client SSH GUI - Remmina](https://remmina.org/)
- [The Beginner's guide to SSH](https://www.youtube.com/watch?v=2QXkrLVsRmk)
- [Vim in 100 Seconds](https://www.youtube.com/watch?v=-txKSRn0qeA)
- [Vim tutorial](https://www.youtube.com/watch?v=IiwGbcd8S7I)
- [Learn the Linux Fundamentals - Part 1](https://www.youtube.com/watch?v=kPylihJRG70)
- [Linux for hackers (don't worry you don't need to be a hacker!)](https://www.youtube.com/watch?v=VbEx7B_PTOE)
내일부터 7일간 네트워킹에 대해 알아보는 시간을 가지며, 데브옵스와 관련된 네트워킹에 대한 기초적인 지식과 이해를 쌓을 것입니다.
[Day 21](day21.md)에서 봐요!

115
2022/ko/Days/day21.md Normal file
View File

@ -0,0 +1,115 @@
---
title: '#90DaysOfDevOps - The Big Picture: DevOps and Networking - Day 21'
published: false
description: 90DaysOfDevOps - The Big Picture DevOps and Networking
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048761
---
## 큰 그림: 데브옵스와 네트워킹
모든 섹션과 마찬가지로 공개 및 무료 교육 자료를 사용하고 있으며 많은 콘텐츠가 다른 사람의 저작물일 수 있습니다. 네트워킹 섹션의 경우, 표시된 콘텐츠의 대부분은 [Practical Networking](https://www.practicalnetworking.net/)의 무료 [Networking Fundamentals series](https://www.youtube.com/playlist?list=PLIFyRwBY_4bRLmKfP1KnZA6rZbRHtxmXi)에서 가져온 것입니다. 리소스에도 링크와 함께 언급되어 있지만 커뮤니티의 관점에서 특정 기술 분야에 대한 이해를 돕기 위해 이 과정을 활용했기 때문에 이 점을 강조하는 것이 적절합니다. 이 저장소는 제 메모를 저장하고 커뮤니티가 이 과정과 나열된 리소스로부터 혜택을 받을 수 있도록 하는 저장소입니다.
21일 차에 오신 것을 환영합니다! 앞으로 7일 동안 네트워킹과 데브옵스가 가장 중요한 주제이지만, 네트워킹의 기본에 대해서도 살펴볼 필요가 있을 것입니다.
궁극적으로 앞서 말씀드렸듯이 데브옵스는 조직 내 문화와 프로세스 변화에 관한 것으로, 앞서 논의한 것처럼 가상 머신, 컨테이너 또는 Kubernetes가 될 수도 있지만 네트워크가 될 수도 있습니다. 데브옵스 관점에서 네트워크를 더 많이 포함해야 하는 인프라에 이러한 데브옵스 원칙을 사용한다면 사용 가능한 다양한 Topology 및 네트워킹 도구와 스택에서와 같이 네트워크에 대해서도 알아야 합니다.
저는 코드로 인프라스트럭처의 네트워킹 디바이스를 구성하고 가상 머신처럼 모든 것을 자동화해야 한다고 주장하지만, 그렇게 하려면 무엇을 자동화할지 잘 이해해야 합니다.
### 넷데브옵스 | 네트워크 데브옵스란 무엇인가요?
네트워크 데브옵스 또는 넷데브옵스라는 용어를 들어보셨을 수도 있습니다. 이미 네트워크 엔지니어이고 인프라 내의 네트워크 구성 요소를 잘 파악하고 있다면 DHCP, DNS, NAT 등과 같은 네트워킹에 사용되는 요소를 이해하고 있을 것입니다. 또한 하드웨어 또는 소프트웨어 정의 네트워킹 옵션, 스위치, 라우터 등에 대해서도 잘 이해하고 있을 것입니다.
하지만 네트워크 엔지니어가 아니라면 네트워크 데브옵스의 최종 목표를 이해하려면 이러한 영역 중 일부에 대한 전반적인 기초 지식이 필요할 수 있습니다.
그러나 이러한 용어와 관련하여 NetDevOps 또는 네트워크 데브옵스를 네트워크에 데브옵스 원칙과 관행을 적용하고 버전 제어 및 자동화 도구를 네트워크 생성, 테스트, 모니터링 및 배포에 적용하는 것으로 생각할 수 있습니다.
네트워크 데브옵스를 자동화가 필요한 것으로 생각한다면, 앞서 데브옵스가 팀 간의 사일로를 허무는 것에 대해 언급했습니다. 네트워킹 팀이 유사한 모델과 프로세스로 변경하지 않으면 병목 현상이 발생하거나 전체적으로 장애가 발생할 수 있습니다.
프로비저닝, 구성, 테스트, 버전 제어 및 배포와 관련된 자동화 원칙을 사용하는 것이 좋은 출발점입니다. 자동화는 전반적으로 배포 속도, 네트워킹 인프라의 안정성, 지속적인 개선을 가능하게 할 뿐만 아니라 테스트가 완료되면 여러 환경에서 프로세스를 공유할 수 있습니다. 예를 들어 한 환경에서 완전히 테스트 된 네트워크 정책은 이전에는 수동으로 작성된 프로세스와 달리 코드로 되어 있기 때문에 다른 위치에서도 빠르게 사용할 수 있습니다.
이러한 사고에 대한 좋은 관점과 개요는 여기에서 찾을 수 있습니다. [Network DevOps](https://www.thousandeyes.com/learning/techtorials/network-devops)
## 네트워킹 기본 사항
여기서는 데브옵스 측면은 잠시 접어두고 이제 네트워킹의 기본 사항에 대해 간략히 살펴보겠습니다.
### 네트워크 장치
이 콘텐츠를 동영상으로 보고 싶으시다면 Practical Networking에서 다음 동영상을 확인하세요:
- [Network Devices - Hosts, IP Addresses, Networks - Networking Fundamentals - Lesson 1a](https://www.youtube.com/watch?v=bj-Yfakjllc&list=PLIFyRwBY_4bRLmKfP1KnZA6rZbRHtxmXi&index=1)
- [Network Devices - Hub, Bridge, Switch, Router - Networking Fundamentals - Lesson 1b](https://www.youtube.com/watch?v=H7-NR3Q3BeI&list=PLIFyRwBY_4bRLmKfP1KnZA6rZbRHtxmXi&index=2)
**호스트**는 트래픽을 보내거나 받는 모든 장치입니다.
![](/2022/Days/Images/Day21_Networking1.png)
**IP 주소**는 각 호스트의 신원입니다.
![](/2022/Days/Images/Day21_Networking2.png)
**네트워크**는 호스트 간에 트래픽을 전송하는 역할을 합니다. 네트워크가 없다면 데이터를 수동으로 많이 이동해야 할 것입니다!
비슷한 연결이 필요한 호스트의 논리적 그룹입니다.
![](/2022/Days/Images/Day21_Networking3.png)
**스위치**는 네트워크 내에서 통신을 촉진합니다. 스위치는 호스트 간에 데이터 패킷을 전달합니다. 스위치는 호스트에 직접 패킷을 보냅니다.
- 네트워크: 유사한 연결이 필요한 호스트들의 그룹.
- 네트워크의 호스트는 동일한 IP 주소 공간을 공유합니다.
![](/2022/Days/Images/Day21_Networking4.png)
**라우터**는 네트워크 간의 통신을 용이하게 합니다. 앞서 스위치가 네트워크 내의 통신을 관리한다고 말했듯이 라우터는 이러한 네트워크를 함께 연결하거나 최소한 허용되는 경우 서로에 대한 액세스 권한을 부여할 수 있게 해줍니다.
라우터는 트래픽 제어 지점(보안, 필터링, 리디렉션)을 제공할 수 있습니다. 최근에는 이러한 기능 중 일부를 제공하는 스위치도 점점 더 많아지고 있습니다.
라우터는 자신이 연결된 네트워크를 학습합니다. 이를 라우트라고 하며 라우팅 테이블은 라우터가 알고 있는 모든 네트워크입니다.
라우터는 연결된 네트워크에 IP 주소를 가지고 있습니다. 이 IP는 게이트웨이라고도 하는 각 호스트가 로컬 네트워크에서 나가는 통로가 되기도 합니다.
라우터는 또한 앞서 언급한 네트워크에서 계층 구조를 생성합니다.
![](/2022/Days/Images/Day21_Networking5.png)
## 스위치 대 라우터
**라우팅**은 네트워크 간에 데이터를 이동하는 프로세스입니다.
- 라우터는 라우팅을 주요 목적으로 하는 장치입니다.
**스위칭**은 네트워크 내에서 데이터를 이동하는 프로세스입니다.
- 스위치는 스위칭을 주목적으로 하는 장치입니다.
다음과 같이 다양한 네트워크 장치가 있다는 것을 알고 있으므로 이는 장치에 대한 기본적인 개요입니다:
- 액세스 포인트
- 방화벽
- 로드 밸런서
- 레이어 3 스위치
- IDS/IPS
- 프록시
- 가상 스위치
- 가상 라우터
이러한 모든 장치는 라우팅 및/또는 스위칭을 수행합니다.
앞으로 며칠 동안 이 목록에 대해 조금 더 자세히 알아보도록 하겠습니다.
- OSI 모델
- 네트워크 프로토콜
- DNS(도메인 이름 시스템)
- NAT
- DHCP
- 서브넷
## 자료
- [Networking Fundamentals](https://www.youtube.com/playlist?list=PLIFyRwBY_4bRLmKfP1KnZA6rZbRHtxmXi)
- [Computer Networking full course](https://www.youtube.com/watch?v=IPvYjXCsTg8)
[Day 22](day22.md)에서 봐요!

111
2022/ko/Days/day22.md Normal file
View File

@ -0,0 +1,111 @@
---
title: '#90DaysOfDevOps - The OSI Model - The 7 Layers - Day 22'
published: false
description: 90DaysOfDevOps - The OSI Model - The 7 Layers
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1049037
---
아래 콘텐츠는 대부분 실용적인 네트워킹의 [Networking Fundamentals series](https://www.youtube.com/playlist?list=PLIFyRwBY_4bRLmKfP1KnZA6rZbRHtxmXi)에서 가져온 것입니다. 이 콘텐츠를 동영상으로 보고 싶으시다면 다음 두 동영상을 확인해 보세요:
- [The OSI Model: A Practical Perspective - Layers 1 / 2 / 3](https://www.youtube.com/watch?v=LkolbURrtTs&list=PLIFyRwBY_4bRLmKfP1KnZA6rZbRHtxmXi&index=3)
- [The OSI Model: A Practical Perspective - Layers 4 / 5+](https://www.youtube.com/watch?v=0aGqGKrRE0g&list=PLIFyRwBY_4bRLmKfP1KnZA6rZbRHtxmXi&index=4)
## OSI 모델 - 7개의 Layers
산업으로서 네트워킹의 전반적인 목적은 두 호스트가 데이터를 공유할 수 있도록 하는 것입니다. 네트워킹 이전에는 이 호스트에서 이 호스트로 데이터를 가져오려면 이 호스트에 무언가를 꽂고 다른 호스트에 가서 다른 호스트에 꽂아야 했습니다.
네트워킹을 사용하면 호스트가 유선을 통해 데이터를 자동으로 공유할 수 있으므로 이 작업을 자동화할 수 있으며, 이 작업을 수행하려면 호스트가 일련의 규칙을 따라야 합니다.
이는 모든 언어와 다르지 않습니다. 영어에는 두 명의 영어 사용자가 따라야 하는 일련의 규칙이 있습니다. 스페인어에도 고유한 규칙이 있습니다. 프랑스어에는 고유한 규칙이 있으며, 네트워킹에도 고유한 규칙이 있습니다.
네트워킹에 대한 규칙은 7가지 계층으로 나뉘며, 이러한 계층을 OSI 모델이라고 합니다.
### OSI 모델 소개
OSI 모델(개방형 시스템 상호 연결 모델)은 네트워킹 시스템의 기능을 설명하는 데 사용되는 프레임워크입니다. OSI 모델은 서로 다른 제품과 소프트웨어 간의 상호 운용성을 지원하기 위해 컴퓨팅 기능을 보편적인 규칙과 요구 사항으로 특성화합니다. OSI 참조 모델에서 컴퓨팅 시스템 간의 통신은 7가지 추상화 계층으로 나뉩니다: **물리적, 데이터 링크, 네트워크, 전송, 세션, 프레젠테이션 및 애플리케이션**.
![](/2022/Days/Images/Day22_Networking1.png)
### 물리적
OSI 모델에서 Layer 1은 물리적이라고 하며, 물리적 케이블 등 수단을 통해 한 호스트에서 다른 호스트로 데이터를 전송할 수 있다는 전제하에 이 Layer에서도 Wi-Fi를 고려할 수 있습니다. 또한 한 호스트에서 다른 호스트로 데이터를 전송하기 위해 허브와 중계기 주변에서 더 많은 레거시 하드웨어를 볼 수 있습니다.
![](/2022/Days/Images/Day22_Networking2.png)
### 데이터 링크
Layer 2의 데이터 링크는 데이터가 프레임으로 패키지화되는 노드 간 전송을 가능하게 합니다. 또한 물리 계층에서 발생했을 수 있는 오류를 수정하는 수준도 있습니다. 또한 이 단계에서 MAC 주소가 도입되거나 처음 등장합니다.
네트워킹 첫날인 [Day 21](day21.md)
에서 다룬 스위치에 대한 첫 번째 언급도 여기에서 볼 수 있습니다.
![](/2022/Days/Images/Day22_Networking3.png)
### 네트워크
Layer 3 스위치 또는 Layer 2 스위치라는 용어를 들어보셨을 것입니다. OSI 모델인 Layer 3에서 네트워크는 End to End 전송을 목표로 하며, 첫날 개요에서 언급한 IP 주소가 있는 곳입니다.
라우터와 호스트는 Layer 3에 존재하며, 라우터는 여러 네트워크 간에 라우팅하는 기능이라는 점을 기억하세요. IP가 있는 모든 것은 Layer 3으로 간주할 수 있습니다.
![](/2022/Days/Images/Day22_Networking4.png)
그렇다면 왜 Layer 2와 3 모두에 주소 체계가 필요할까요? (MAC 주소와 IP 주소)
한 호스트에서 다른 호스트로 데이터를 전송하는 것을 생각해 보면, 각 호스트에는 IP 주소가 있지만 그사이에는 여러 개의 스위치와 라우터가 있습니다. 각 장치에는 Layer 2 MAC 주소가 있습니다.
Layer 2 MAC 주소는 호스트에서 스위치/라우터로만 이동하며 hop에 중점을 두는 반면, Layer 3 IP 주소는 데이터 패킷이 최종 호스트에 도달할 때까지 해당 패킷을 유지합니다. (End to End)
IP 주소 - Layer 3 = End to End 전송
MAC 주소 - Layer 2 = Hop to Hop 전송
이제 Layer3와 Layer2 주소를 연결하는 ARP(주소 확인 프로토콜)라는 네트워크 프로토콜이 있지만 오늘은 다루지 않겠습니다.
### 전송
서비스 간 전송, Layer 4는 데이터 스트림을 구분하기 위해 존재합니다. Layer 3과 Layer 2에 주소 체계가 있는 것과 마찬가지로 Layer 4에는 포트가 있습니다.
![](/2022/Days/Images/Day22_Networking5.png)
### 세션, 프레젠테이션, 애플리케이션
Layers 5,6,7의 구분이 다소 모호해졌습니다.
보다 최근의 이해를 돕기 위해 [TCP IP Model](https://www.geeksforgeeks.org/tcp-ip-model/)을 살펴보는 것이 좋습니다.
이제 이 네트워킹 스택을 사용하여 호스트가 서로 통신할 때 어떤 일이 일어나는지 설명해 보겠습니다. 이 호스트에는 다른 호스트로 전송할 데이터를 생성하는 애플리케이션이 있습니다.
소스 호스트는 캡슐화 프로세스라고 하는 과정을 거치게 됩니다. 이 데이터는 먼저 Layer 4로 전송됩니다.
Layer 4는 해당 데이터에 헤더를 추가하여 서비스 간 전송이라는 Layer 4의 목표를 용이하게 할 수 있습니다. 이 헤더는 TCP 또는 UDP를 사용하는 포트가 될 것입니다. 또한 소스 포트와 대상 포트도 포함됩니다.
이를 세그먼트(데이터 및 포트)라고도 합니다.
이 세그먼트는 OSI 스택을 통해 네트워크 계층인 Layer 3으로 전달되고, 네트워크 계층은 이 데이터에 또 다른 헤더를 추가합니다.
이 헤더는 End to End 전송이라는 Layer 3의 목표를 달성하기 위한 것으로, 이 헤더에는 소스 IP 주소와 대상 IP가 있으며, 헤더와 데이터를 합쳐 패킷이라고도 합니다.
그러면 Layer 3이 해당 패킷을 받아 Layer 2로 전달하고, Layer 2는 다시 한번 해당 데이터에 또 다른 헤더를 추가하여 Layer 2의 목표인 Hop to Hop 전송을 달성하게 되는데, 이 헤더에는 소스 및 대상 맥 주소가 포함됩니다.
Layer 2 헤더와 데이터가 있을 때 이를 프레임이라고 합니다.
그런 다음 이 프레임은 1과 0으로 변환되어 Layer 1 물리적 케이블 또는 Wi-Fi를 통해 전송됩니다.
![](/2022/Days/Images/Day22_Networking6.png)
위에서 헤더와 데이터의 각 Layer에 대한 네이밍에 대해 언급했지만, 이것도 그려보기로 했습니다.
![](/2022/Days/Images/Day22_Networking7.png)
데이터를 전송하는 애플리케이션은 어딘가로 데이터를 전송하고 있으므로 수신은 스택을 거슬러 올라가 수신 호스트에 전달하기 위해 다소 역방향으로 이루어집니다.
![](/2022/Days/Images/Day22_Networking8.png)
## 자료
- [Networking Fundamentals](https://www.youtube.com/playlist?list=PLIFyRwBY_4bRLmKfP1KnZA6rZbRHtxmXi)
* [Computer Networking full course](https://www.youtube.com/watch?v=IPvYjXCsTg8)
[Day 23](day23.md)에서 봐요!

122
2022/ko/Days/day23.md Normal file
View File

@ -0,0 +1,122 @@
---
title: '#90DaysOfDevOps - Network Protocols - Day 23'
published: false
description: 90DaysOfDevOps - Network Protocols
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048704
---
아래 콘텐츠는 대부분 실용적인 네트워킹의 [Networking Fundamentals series](https://www.youtube.com/playlist?list=PLIFyRwBY_4bRLmKfP1KnZA6rZbRHtxmXi)에서 가져온 것입니다. 이 콘텐츠를 동영상으로 보고 싶으시다면 이 동영상을 확인해보세요:
- [Network Protocols - ARP, FTP, SMTP, HTTP, SSL, TLS, HTTPS, DNS, DHCP](https://www.youtube.com/watch?v=E5bSumTAHZE&list=PLIFyRwBY_4bRLmKfP1KnZA6rZbRHtxmXi&index=12)
## 네트워크 프로토콜
인터넷 표준을 구성하는 일련의 규칙과 메시지입니다.
- ARP - 주소 확인 프로토콜
ARP에 대해 자세히 알고 싶으시다면 여기에서 인터넷 표준을 읽어보세요. [RFC 826](https://datatracker.ietf.org/doc/html/rfc826)
Layer 2 네트워크에서 IP 주소를 고정된 물리적 컴퓨터 주소(MAC 주소라고도 함)에 연결합니다.
![](/2022/Days/Images/Day23_Networking1.png)
- FTP - 파일 전송 프로토콜
소스에서 대상으로 파일을 전송할 수 있습니다. 일반적으로 이 프로세스는 인증되지만, 익명 액세스를 사용하도록 구성한 경우 사용할 수 있습니다. 이제 더 나은 보안을 위해 클라이언트에서 FTP 서버로 SSL/TLS 연결을 제공하는 FTPS를 더 자주 보게 될 것입니다. 이 프로토콜은 OSI 모델의 애플리케이션 계층에서 찾을 수 있습니다.
![](/2022/Days/Images/Day23_Networking2.png)
- SMTP - 단순 메일 전송 프로토콜
전자 메일 전송에 사용되는 메일 서버는 SMTP를 사용하여 메일 메시지를 보내고 받습니다. Microsoft 365를 사용하더라도 SMTP 프로토콜이 동일한 용도로 사용된다는 것을 알 수 있습니다.
![](/2022/Days/Images/Day23_Networking3.png)
- HTTP - 하이퍼 텍스트 전송 프로토콜
HTTP는 인터넷과 콘텐츠 탐색의 기초입니다. 우리가 즐겨 찾는 웹사이트에 쉽게 액세스할 수 있게 해줍니다. HTTP는 여전히 많이 사용되고 있지만, 대부분의 즐겨 찾는 사이트에서는 HTTPS가 더 많이 사용되고 있거나 사용되어야 합니다.
![](/2022/Days/Images/Day23_Networking4.png)
- SSL - 보안 소켓 계층 | TLS - 전송 계층 보안
SSL의 뒤를 이어 등장한 TLS는 네트워크를 통해 안전한 통신을 제공하는 **암호화 프로토콜**입니다. 메일, 인스턴트 메시징 및 기타 애플리케이션에서 찾을 수 있지만 가장 일반적으로 HTTPS를 보호하는 데 사용됩니다.
![](/2022/Days/Images/Day23_Networking5.png)
- HTTPS - SSL/TLS로 보호되는 HTTP
네트워크를 통한 보안 통신에 사용되는 HTTP의 확장인 HTTPS는 위에서 언급한 것처럼 TLS로 암호화됩니다. 호스트 간에 데이터가 교환되는 동안 인증, 개인 정보 보호 및 무결성을 제공하는 데 중점을 두었습니다.
![](/2022/Days/Images/Day23_Networking6.png)
- DNS - 도메인 이름 시스템
DNS는 인간 친화적인 도메인 이름을 매핑하는 데 사용됩니다. 예를 들어 우리가 모두 알고 있는 [google.com](https://google.com)은 브라우저를 열고 [8.8.8.8](https://8.8.8.8)을 입력하면 우리가 거의 알고 있는 Google이 표시됩니다. 하지만 모든 웹사이트의 IP 주소를 모두 기억하기란 쉽지 않으며, 일부 웹사이트는 정보를 찾기 위해 구글을 사용하기도 합니다.
호스트, 서비스 및 기타 리소스에 연결할 수 있도록 하는 DNS의 역할이 바로 여기에 있습니다.
모든 호스트에서 인터넷 연결이 필요한 경우 해당 도메인 이름을 확인할 수 있도록 DNS가 있어야 합니다. DNS는 며칠 또는 몇 년을 투자하여 학습할 수 있는 영역입니다. 또한 경험상 네트워킹과 관련된 모든 오류의 일반적인 원인은 대부분 DNS라고 말하고 싶습니다. 하지만 네트워크 엔지니어가 동의할지는 모르겠습니다.
![](/2022/Days/Images/Day23_Networking7.png)
- DHCP - 동적 호스트 구성 프로토콜
인터넷에 액세스하거나 서로 간에 파일을 전송하는 등 호스트가 작동하는 데 필요한 프로토콜에 대해 많이 논의했습니다.
이 두 가지 작업을 모두 수행하기 위해 모든 호스트에 필요한 4가지 사항이 있습니다.
- IP 주소
- 서브넷 마스크
- 기본 게이트웨이
- DNS
IP 주소는 호스트가 위치한 네트워크에서 호스트의 고유 주소로, 집 번호라고 생각하시면 됩니다.
서브넷 마스크는 곧 다루겠지만 우편번호나 우편번호로 생각하시면 됩니다.
기본 게이트웨이는 일반적으로 네트워크에서 Layer 3 연결을 제공하는 라우터의 IP입니다. 이를 우리 동네를 빠져나갈 수 있는 하나의 도로라고 생각할 수 있습니다.
그리고 방금 설명한 DNS는 복잡한 공인 IP 주소를 보다 적합하고 기억하기 쉬운 도메인 이름으로 변환하는 데 도움을 줍니다. 어쩌면 이것을 올바른 게시물을 얻기 위한 거대한 분류 사무실이라고 생각할 수 있습니다.
각 호스트마다 이 네 가지가 필요하다고 말씀드렸듯이 호스트가 1,000개 또는 10,000개라면 이 네 가지를 개별적으로 결정하는 데 매우 오랜 시간이 걸릴 것입니다. 이때 DHCP가 등장하여 네트워크의 범위를 결정하면 이 프로토콜이 네트워크에서 사용 가능한 모든 호스트에 배포됩니다.
또 다른 예로 커피숍에 가서 커피를 마시고 노트북이나 휴대폰을 들고 앉았다고 가정해 봅시다. 호스트를 커피숍 와이파이에 연결하면 인터넷에 접속할 수 있고, 메시지와 메일이 핑을 받기 시작하며, 웹 페이지와 소셜 미디어를 탐색할 수 있습니다. 커피숍 와이파이에 연결했을 때 컴퓨터는 전용 DHCP 서버 또는 DHCP를 처리하는 라우터에서 DHCP 주소를 선택했을 것입니다.
![](/2022/Days/Images/Day23_Networking8.png)
### 서브넷
서브넷은 IP 네트워크의 논리적 세분화입니다.
서브넷은 대규모 네트워크를 더 효율적으로 실행할 수 있는 더 작고 관리하기 쉬운 네트워크로 나눕니다.
각 서브넷은 더 큰 네트워크의 논리적 세분화입니다. 충분한 서브넷을 가진 연결된 장치는 공통 IP 주소 식별자를 공유하여 서로 통신할 수 있습니다.
라우터는 서브넷 간의 통신을 관리합니다.
서브넷의 크기는 연결 요구 사항과 사용되는 네트워크 기술에 따라 달라집니다.
조직은 사용 가능한 주소 공간의 한도 내에서 서브넷의 수와 크기를 결정할 책임이 있습니다.
사용 가능한 주소 공간의 한도 내에서 서브넷의 수와 크기를 결정할 책임이 있으며, 세부 사항은 해당 조직에 로컬로 유지됩니다. 서브넷은 지점 간 링크 또는 몇 개의 디바이스를 지원하는 서브네트워크와 같이 더 작은 서브넷으로 세분화할 수도 있습니다.
무엇보다도 대규모 네트워크를 서브넷으로 세분화하면
네트워크를 서브넷으로 분할하면 IP 주소
재할당을 가능하게 하고 네트워크 혼잡, 간소화, 네트워크 통신 및 효율성을 완화합니다.
서브넷은 네트워크 보안도 향상시킬 수 있습니다.
네트워크의 한 섹션이 손상되면 해당 섹션을 격리하여 악의적인 공격자가 더 큰 네트워크에서 이동하기 어렵게 만들 수 있습니다.
![](/2022/Days/Images/Day23_Networking9.png)
## 자료
- [Networking Fundamentals](https://www.youtube.com/playlist?list=PLIFyRwBY_4bRLmKfP1KnZA6rZbRHtxmXi)
- [Subnetting Mastery](https://www.youtube.com/playlist?list=PLIFyRwBY_4bQUE4IB5c4VPRyDoLgOdExE)
- [Computer Networking full course](https://www.youtube.com/watch?v=IPvYjXCsTg8)
[Day 24](day24.md)에서 봐요!

147
2022/ko/Days/day24.md Normal file
View File

@ -0,0 +1,147 @@
---
title: '#90DaysOfDevOps - Network Automation - Day 24'
published: false
description: 90DaysOfDevOps - Network Automation
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048805
---
## 네트워크 자동화
### 네트워크 자동화의 기본 사항
네트워크 자동화의 주요 동인
- 민첩성 달성
- 비용 절감
- 오류 제거
- 규정 준수 보장
- 중앙 집중식 관리
자동화 도입 프로세스는 각 비즈니스에 따라 다릅니다. 자동화를 배포하는 데 있어 모든 것에 적합한 방법은 없으며, 조직에 가장 적합한 접근 방식을 파악하고 수용하는 능력은 보다 민첩한 환경을 유지하거나 만드는 데 매우 중요하며, 항상 비즈니스 가치와 최종 사용자 경험에 초점을 맞춰야 합니다. (처음에 DevOps 전체와 문화 변화 및 이로 인한 자동화된 프로세스와 관련하여 비슷한 내용을 말씀드렸습니다.)
이를 세분화하려면 자동화하려는 작업이나 프로세스가 최종 사용자 경험 또는 비즈니스 가치를 어떻게 달성하고 개선할 수 있는지 파악하고 단계별 체계적인 접근 방식을 따라야 합니다.
"어디로 가는지 모르면 어떤 길이라도 그곳에 도달할 수 있습니다."
달성하고자 하는 프레임워크 또는 설계 구조를 통해 최종 목표가 무엇인지 파악한 다음, 비즈니스 결과를 기반으로 다양한 단계에서 자동화 성공 여부를 측정하면서 목표 달성을 위해 단계적으로 작업하세요.
기존 애플리케이션을 중심으로 모델링된 개념 구축 자동화는 애플리케이션, 서비스, 인프라에 적용해야 하기 때문에 거창하게 개념을 설계할 필요가 없으므로 기존 인프라, 즉 기존 애플리케이션을 중심으로 모델링하여 개념을 구축하기 시작하세요.
### 네트워킹 자동화에 대한 접근 방식
작업을 식별하고 네트워크 변경 요청에 대한 검색을 수행하여 솔루션을 자동화할 가장 일반적인 이슈와 문제를 파악해야 합니다.
- 현재 수동으로 처리하고 있는 모든 변경 요청과 워크플로우의 목록을 작성합니다.
- 가장 일반적이고 시간이 오래 걸리며 오류가 발생하기 쉬운 활동을 파악하세요.
- 비즈니스 중심 접근 방식을 취하여 요청의 우선순위를 정하세요.
- 이는 자동화 프로세스를 구축하기 위한 프레임워크이며, 자동화해야 하는 작업과 자동화하지 않아야 하는 작업을 구분합니다.
그런 다음 작업을 나누고 서로 다른 네트워크 기능이 어떻게 작동하고 상호 작용하는지 분석해야 합니다.
- 인프라/네트워크 팀은 애플리케이션을 배포하기 위해 여러 계층에서 변경 티켓을 받습니다.
- 네트워크 서비스를 기반으로 여러 영역으로 나누고 서로 어떻게 상호 작용하는지 이해합니다.
- 애플리케이션 최적화
- ADC(애플리케이션 전송 컨트롤러)
- 방화벽
- DDI(DNS, DHCP, IPAM 등)
- 라우팅
- 기타
- 다양한 종속성을 파악하여 비즈니스 및 문화적 차이를 해결하고 팀 간 협업을 유도하세요.
재사용 가능한 정책, 재사용 가능한 서비스 작업, 프로세스 및 입출력을 정의하고 단순화하세요.
- 다양한 서비스, 프로세스 및 입출력을 위한 오퍼링을 정의하세요.
- 배포 프로세스를 간소화하면 신규 워크로드와 기존 워크로드 모두의 시장 출시 시간을 단축할 수 있습니다.
- 표준 프로세스가 마련되면, 멀티스레드 접근 방식과 제공을 위해 개별 요청에 따라 프로세스를 순서화 및 조정할 수 있습니다.
정책을 비즈니스별 활동과 결합하세요. 이 정책을 구현하면 비즈니스에 어떤 도움이 되나요? 시간이 절약되나요? 비용이 절감되나요? 더 나은 비즈니스 결과를 제공하나요?
- 서비스 작업이 상호 운용 가능한지 확인하세요.
- 증분 서비스 작업을 연결하여 비즈니스 서비스를 만들 수 있도록 정렬하세요.
- 필요에 따라 서비스 작업을 연결하고 다시 연결할 수 있는 유연성을 제공하세요.
- 셀프 서비스 기능을 배포하고 운영 효율성을 개선할 수 있는 기반을 마련하세요.
- 감독 및 규정 준수에 지속적으로 기여할 수 있도록 다양한 기술 스킬셋을 허용합니다.
가용성과 서비스를 유지하면서 정책과 프로세스를 **반복**하여 추가하고 개선하세요.
- 기존 작업을 자동화하여 작게 시작하세요.
- 자동화 프로세스에 익숙해져서 자동화를 통해 이점을 얻을 수 있는 다른 영역을 식별할 수 있습니다.
- 자동화 이니셔티브를 반복하여 필요한 가용성을 유지하면서 민첩성을 점진적으로 추가합니다.
- 점진적인 접근 방식을 취하면 성공의 길을 열 수 있습니다!
네트워크 서비스를 오케스트레이션하세요!
- 애플리케이션을 신속하게 제공하려면 배포 프로세스의 자동화가 필요합니다.
- 민첩한 서비스 환경을 구축하려면 기술 전반에 걸쳐 관리해야 할 다양한 요소가 필요합니다.
- 자동화와 배포 순서를 제어할 수 있는 End To End 오케스트레이션을 준비하세요.
## 네트워크 자동화 도구
여기서 좋은 소식은 대부분의 경우 네트워크 자동화에 사용하는 도구는 다른 자동화 영역에 사용하거나 지금까지 이미 다룬 내용 또는 향후 세션에서 다룰 내용과 동일하다는 것입니다.
운영 체제 - 이번 챌린지 내내 그랬듯이 저는 대부분의 학습을 Linux OS로 하는 데 집중하고 있으며, 그 이유는 Linux 섹션에서 설명했지만, 크로스 OS 플랫폼이긴 하지만 오늘 다룰 거의 모든 도구는 처음부터 모두 Linux 기반 애플리케이션 또는 도구로 시작되었습니다.
통합 개발 환경(IDE) - 다양한 언어에서 사용할 수 있는 광범위한 플러그인을 기반으로 Visual Studio Code를 IDE로 추천한다는 것 외에는 여기서 더 이상 설명할 것이 없습니다.
구성 관리 - 아직 구성 관리 섹션은 다루지 않았지만, 이 영역에서 구성 관리 및 자동화를 위해 Ansible이 가장 선호되는 것은 분명합니다. Ansible은 Python으로 작성되었지만, Python을 알 필요는 없습니다.
- 에이전트리스
- SSH만 필요
- 대규모 지원 커뮤니티
- 다양한 네트워크 모듈
- 푸시 전용 모델
- YAML로 구성
- 오픈 소스!
[Link to Ansible Network Modules](https://docs.ansible.com/ansible/2.9/modules/list_of_network_modules.html)
구성 관리 섹션에서 **Ansible Tower**에 대해서도 다룰 예정이며, 이를 Ansible의 GUI로 보시면 됩니다.
CI/CD - 이와 관련된 개념과 도구에 대해서는 다시 다룰 예정이지만, 네트워킹뿐만 아니라 서비스 및 플랫폼의 모든 프로비저닝에 걸쳐 있기 때문에 최소한 여기서 언급하는 것이 중요합니다.
특히 Jenkins는 네트워크 자동화를 위한 인기 있는 도구를 제공하거나 제공하는 것으로 보입니다.
- 변경사항이 있는지 git 리포지토리를 모니터링한 다음 변경을 시작합니다.
버전 관리 - 이 역시 나중에 자세히 살펴볼 내용입니다.
- Git은 로컬 디바이스에서 코드의 버전 제어를 제공합니다 - 크로스 플랫폼
- GitHub, GitLab, BitBucket 등은 리포지토리를 정의하고 코드를 업로드할 수 있는 온라인 웹사이트입니다.
언어 | 스크립팅 - 우리가 아직 다루지 않은 Python입니다. 상황에 따라 프로그래밍 언어로 Go를 사용하기로 결정했는데, Golang과 Python이 박빙의 승부를 펼쳤으며 네트워크 자동화에는 Python이 승자가 된 것 같습니다.
- 여기서 언급해야 할 것이 바로 파이썬으로 작성된 자동화 프레임워크인 Nornir입니다. 이것은 Ansible의 역할을 하는 것으로 보이지만 특히 네트워크 자동화를 중심으로 합니다. [Nornir documentation](https://nornir.readthedocs.io/en/latest/)
API 분석 - Postman은 RESTful API를 분석하기 위한 훌륭한 도구입니다. API를 빌드, 테스트 및 수정하는 데 도움이 됩니다.
- POST >>> 리소스 객체를 생성합니다.
- GET >>> 리소스를 검색합니다.
- PUT >>> 리소스를 생성하거나 교체합니다.
- PATCH >>> 리소스 오브젝트를 생성하거나 업데이트합니다.
- DELETE >>> 리소스를 삭제합니다.
[Postman tool Download](https://www.postman.com/downloads/)
### 기타 언급할 도구
[Cisco NSO (Network Services Orchestrator)](https://www.cisco.com/c/en/us/products/cloud-systems-management/network-services-orchestrator/index.html)
[NetYCE - Simplify Network Automation](https://netyce.com/)
[Network Test Automation](https://pubhub.devnetcloud.com/media/genie-feature-browser/docs/#/)
앞으로 3일 동안은 지금까지 다룬 내용 중 몇 가지를 좀 더 실습해보고 Python과 네트워크 자동화에 관한 작업을 해볼 계획입니다.
지금까지 네트워킹 주제를 모두 다루지는 못했지만, 아래에 추가하는 리소스를 통해 계속 학습하면서 따라갈 수 있을 정도로 폭넓게 다루고자 합니다.
## 자료
- [3 Necessary Skills for Network Automation](https://www.youtube.com/watch?v=KhiJ7Fu9kKA&list=WL&index=122&t=89s)
- [Computer Networking full course](https://www.youtube.com/watch?v=IPvYjXCsTg8)
- [Practical Networking](http://www.practicalnetworking.net/)
- [Python Network Automation](https://www.youtube.com/watch?v=xKPzLplPECU&list=WL&index=126)
[Day 25](day25.md)에서 봐요!

175
2022/ko/Days/day25.md Normal file
View File

@ -0,0 +1,175 @@
---
title: '#90DaysOfDevOps - Python for Network Automation - Day 25'
published: false
description: 90DaysOfDevOps - Python for Network Automation
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1049038
---
## 네트워크 자동화를 위한 Python
Python은 자동화된 네트워크 운영에 사용되는 표준 언어입니다.
네트워크 자동화뿐만 아니라 리소스를 찾을 때 어디에나 있는 것 같고, 앞서 언급했듯이 파이썬이 아니라면 일반적으로 파이썬으로도 작성된 Ansible입니다.
이미 언급한 것 같지만 '프로그래밍 언어 배우기' 섹션에서 제가 파이썬 대신 Go를 선택한 이유는 회사에서 Go로 개발 중이어서 배울 수 있는 좋은 이유였지만, 그렇지 않았다면 파이썬을 배우는 데 시간이 더 걸렸을 것입니다.
- 가독성 및 사용 편의성 - 파이썬은 그냥 말이 되는 것 같습니다. 코드에서 블록을 시작하고 끝내기 위해 `{}`에 대한 요구 사항이 없는 것 같습니다. 여기에 VS Code와 같은 강력한 IDE를 결합하면 파이썬 코드를 실행할 때 매우 쉽게 시작할 수 있습니다.
여기서 언급할 만한 또 다른 IDE는 Pycharm일 수 있습니다.
- 라이브러리 - 파이썬의 확장성은 네트워크 자동화뿐만 아니라 실제로 모든 종류의 장치와 구성을 위한 라이브러리가 많이 있다는 점을 앞서 언급했습니다. 여기에서 방대한 양을 확인할 수 있습니다. [PyPi](https://pypi.python.org/pypi)
라이브러리를 워크스테이션에 다운로드하려면 `pip`라는 도구를 사용하여 PyPI에 연결하고 로컬로 다운로드하면 됩니다. Cisco, 주니퍼, 아리스타와 같은 네트워크 벤더는 자사 디바이스에 쉽게 액세스할 수 있도록 라이브러리를 개발했습니다.
- 강력하고 효율적 - Go 파트에서 "Hello World" 시나리오를 진행하면서 6줄 정도의 코드를 작성했던 것을 기억하시나요? Python에서는
```python
print('hello world')
```
위의 모든 사항을 종합하면 자동화 작업 시 파이썬이 언급되는 이유를 쉽게 알 수 있을 것입니다.
몇 년 전에도 네트워크 장치와 상호 작용하여 구성 백업을 자동화하거나 장치에 대한 로그 및 기타 인사이트를 수집하는 스크립트가 있었을 가능성이 있다는 점에 유의하는 것이 중요하다고 생각합니다. 여기서 말하는 자동화는 조금 다른데, 이는 전반적인 네트워킹 환경이 이러한 사고방식에 더 잘 맞도록 변화하여 더 많은 자동화를 가능하게 했기 때문입니다.
- 소프트웨어 정의 네트워크 - SDN 컨트롤러는 네트워크의 모든 디바이스에 컨트롤 플레인 구성을 제공하는 책임을 지므로 네트워크 변경에 대한 단일 접점만 있으면 더 이상 모든 디바이스에 텔넷 또는 SSH로 접속할 필요가 없으며, 사람이 이 작업을 수행해야 하므로 실패 또는 구성 오류의 가능성이 반복적으로 발생할 수 있습니다.
- 높은 수준의 오케스트레이션 - 이러한 SDN 컨트롤러에서 한 단계 더 올라가면 서비스 수준을 오케스트레이션 할 수 있으며, 이 오케스트레이션 계층을 원하는 플랫폼(VMware, Kubernetes, 퍼블릭 클라우드 등)에 통합할 수 있습니다.
- 정책 기반 관리 - 무엇을 원하시나요? 원하는 상태는 무엇인가요? 이를 설명하면 시스템에서 원하는 상태가 되기 위한 모든 세부 사항을 파악합니다.
## 실습 환경 설정하기
모든 사람이 실제 라우터, 스위치 및 기타 네트워킹 장치에 액세스할 수 있는 것은 아닙니다.
저는 앞서 언급한 몇 가지 도구를 살펴보면서 네트워크 구성을 자동화하는 방법을 직접 실습하고 배울 수 있도록 하고 싶었습니다.
옵션에 관해서는 몇 가지를 선택할 수 있습니다.
- [GNS3 VM](https://www.gns3.com/software/download-vm)
- [Eve-ng](https://www.eve-ng.net/)
- [Unimus](https://unimus.net/) 실험실 환경은 아니지만 흥미로운 개념입니다.
앞서 언급했듯이 [Eve-ng](https://www.eve-ng.net/)를 사용하여 랩을 구축할 예정입니다. 가상 환경은 다양한 시나리오를 테스트할 수 있는 샌드박스 환경을 가질 수 있다는 것을 의미하며, 다양한 디바이스와 Topology로 실행 수 있다는 점도 흥미로울 수 있습니다.
저희는 커뮤니티 에디션을 통해 EVE-NG의 모든 것을 보여드리려고 합니다.
### 시작하기
[커뮤니티 에디션](https://www.eve-ng.net/index.php/download/)은 ISO 및 OVF 형식으로 제공됩니다.
저희는 OVF 다운로드를 사용할 예정이지만, ISO를 사용하면 하이퍼바이저 없이 베어메탈 서버에서 빌드할 수 있습니다.
![](/2022/Days/Images/Day25_Networking1.png)
여기서는 vExpert를 통해 라이선스가 있는 VMware Workstation을 사용하지만, [documentation](https://www.eve-ng.net/index.php/documentation/installation/system-requirement/)에 언급된 다른 옵션이나 VMware Player도 동일하게 사용할 수 있습니다. 안타깝게도 이전에 사용하던 가상 박스는 사용할 수 없습니다!
가상 박스가 지원되기는 하지만 GNS3에서 문제가 발생했던 부분이기도 합니다.
[Download VMware Workstation Player - FREE](https://www.vmware.com/uk/products/workstation-player.html)
[VMware Workstation PRO](https://www.vmware.com/uk/products/workstation-pro.html) 역시 무료 평가판 기간이 있다고 합니다!
### VM웨어 워크스테이션 프로에 설치하기
이제 하이퍼바이저 소프트웨어 다운로드 및 설치가 완료되었고, EVE-NG OVF가 다운로드되었습니다. VMware Player를 사용 중이시라면 이 과정이 동일한지 알려주시기 바랍니다.
이제 구성할 준비가 되었습니다.
VMware 워크스테이션을 열고 `file`과 `open`를 선택합니다.
![](/2022/Days/Images/Day25_Networking2.png)
EVE-NG OVF 이미지를 다운로드하면 압축 파일 안에 들어 있습니다. 해당 폴더에 내용을 압축을 풀면 다음과 같은 모양이 됩니다.
![](/2022/Days/Images/Day25_Networking3.png)
EVE-NG OVF 이미지를 다운로드한 위치로 이동하여 가져오기를 시작합니다.
알아볼 수 있는 이름을 지정하고 시스템 어딘가에 가상 머신을 저장합니다.
![](/2022/Days/Images/Day25_Networking4.png)
가져오기가 완료되면 프로세서 수를 4개로 늘리고 할당된 메모리를 8GB로 늘립니다. (최신 버전으로 가져온 후 그렇지 않은 경우 VM 설정을 편집해야 합니다.)
또한 Intel VT-x/EPT 또는 AMD-V/RVI 가상화 확인란이 활성화되어 있는지 확인합니다. 이 옵션은 VMware 워크스테이션이 가상화 플래그를 게스트 OS에 전달하도록 지시합니다(중첩 가상화). CPU가 이를 허용함에도 불구하고 가상 박스가 있는 GNS3에서 이 문제가 발생했습니다.
![](/2022/Days/Images/Day25_Networking5.png)
### 전원 켜기 및 액세스
사이드노트 & Rabbit hole: 가상박스에서는 작동하지 않는다고 말씀드린 것을 기억하세요! 네, VM웨어 워크스테이션과 EVE-NG에서도 같은 문제가 발생했지만, 가상화 플랫폼의 잘못은 아니었습니다!
Windows 머신에서 WSL2를 실행 중이며 이로 인해 환경 내부에 중첩된 모든 것을 실행할 수 있는 기능이 제거된 것 같습니다. WSL2를 사용할 때 CPU의 인텔 VT-d 가상화 측면이 제거되는 것처럼 보이는데 왜 우분투 VM이 실행되는지 혼란스럽습니다.
이 문제를 해결하려면 Windows 시스템에서 다음 명령을 실행하고 시스템을 재부팅 할 수 있으며, 이 명령이 꺼져 있는 동안에는 WSL2를 사용할 수 없다는 점에 유의하세요.
`bcdedit /set hypervisorlaunchtype off`
다시 돌아가서 WSL2를 사용하려면 이 명령을 실행하고 재부팅 해야 합니다.
`bcdedit /set hypervisorlaunchtype auto`
이 두 명령은 모두 관리자 권한으로 실행해야 합니다!
다시 돌아와서, 이제 VMware Workstation에 전원이 켜진 머신이 있어야 하며 다음과 유사한 프롬프트가 표시되어야 합니다.
![](/2022/Days/Images/Day25_Networking6.png)
위의 프롬프트에서 다음을 사용할 수 있습니다:
username = root
password = eve
그러면 루트 password를 다시 입력하라는 메시지가 표시되며, 이 password는 나중에 호스트에 SSH할 때 사용됩니다.
그런 다음 호스트 이름을 변경할 수 있습니다.
![](/2022/Days/Images/Day25_Networking7.png)
다음으로 DNS 도메인 이름을 정의합니다. 저는 아래 이름을 사용했지만, 나중에 변경해야 할지는 아직 모르겠습니다.
![](/2022/Days/Images/Day25_Networking8.png)
그런 다음 네트워킹을 구성하고, 재부팅 후에도 주어진 IP 주소가 영구적으로 유지되도록 정적을 선택합니다.
![](/2022/Days/Images/Day25_Networking9.png)
마지막 단계로 워크스테이션에서 연결할 수 있는 네트워크의 고정 IP 주소를 제공합니다.
![](/2022/Days/Images/Day25_Networking10.png)
여기에는 네트워크, 기본 게이트웨이 및 DNS에 대한 서브넷 마스크를 제공해야 하는 몇 가지 추가 단계가 있습니다.
완료되면 재부팅되고 백업이 완료되면 고정 IP 주소를 가져와 브라우저에 입력할 수 있습니다.
![](/2022/Days/Images/Day25_Networking11.png)
GUI의 기본 username은 `admin`이고 password는 `eve`이며, SSH의 기본 username은 `root`이고 password는 `eve`이지만 설정 중에 변경한 경우 변경되었을 수 있습니다.
![](/2022/Days/Images/Day25_Networking12.png)
다른 콘솔을 탐색할 때 브라우저에 새 탭이 열리므로 콘솔과 네이티브에 대해 HTML5를 선택했습니다.
다음 단계는 다음과 같습니다:
- EVE-NG 클라이언트 팩 설치
- 일부 네트워크 이미지를 EVE-NG에 로드합니다.
- 네트워크 Topology 빌드
- 노드 추가하기
- 노드 연결하기
- 파이썬 스크립트 빌드 시작
- telnetlib, Netmiko, Paramiko, Pexpect 살펴보기
## 자료
- [Free Course: Introduction to EVE-NG](https://www.youtube.com/watch?v=g6B0f_E0NMg)
- [EVE-NG - Creating your first lab](https://www.youtube.com/watch?v=9dPWARirtK8)
- [3 Necessary Skills for Network Automation](https://www.youtube.com/watch?v=KhiJ7Fu9kKA&list=WL&index=122&t=89s)
- [Computer Networking full course](https://www.youtube.com/watch?v=IPvYjXCsTg8)
- [Practical Networking](http://www.practicalnetworking.net/)
- [Python Network Automation](https://www.youtube.com/watch?v=xKPzLplPECU&list=WL&index=126)
[Day 26](day26.md)에서 봐요!

121
2022/ko/Days/day26.md Normal file
View File

@ -0,0 +1,121 @@
---
title: '#90DaysOfDevOps - Building our Lab - Day 26'
published: false
description: 90DaysOfDevOps - Building our Lab
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048762
---
## 실험실 구축
EVE-NG를 사용하여 에뮬레이트된 네트워크를 계속 설정한 다음 몇 가지 디바이스를 배포하고 이러한 디바이스의 구성을 자동화할 수 있는 방법에 대해 생각해 보겠습니다. [Day 25](day25.md)에서는 VMware Workstation을 사용하여 머신에 EVE-NG를 설치하는 방법을 다루었습니다.
### EVE-NG 클라이언트 설치하기
장치에 SSH를 할 때 사용할 애플리케이션을 선택할 수 있는 클라이언트 팩도 있습니다. 또한 링크 간 패킷 캡처를 위해 Wireshark를 설정합니다. 사용 중인 OS(윈도우, 맥OS, 리눅스)에 맞는 클라이언트 팩을 다운로드할 수 있습니다.
[EVE-NG Client Download](https://www.eve-ng.net/index.php/download/)
![](/2022/Days/Images/Day26_Networking1.png)
빠른 팁: Linux를 클라이언트로 사용하는 경우 이 [client pack](https://github.com/SmartFinn/eve-ng-integration)이 있습니다.
설치는 간단하며, 기본값을 그대로 두는 것이 좋습니다.
### 네트워크 Images 가져오기
이 단계는 어려웠습니다. 마지막에 링크할 몇 가지 동영상을 통해 라우터 및 스위치 이미지를 업로드하는 방법과 위치를 알려주면서 몇 가지 리소스와 다운로드 링크를 제공합니다.
저는 모든 것을 교육 목적으로 사용한다는 점에 유의하는 것이 중요합니다. 네트워크 공급업체에서 공식 이미지를 다운로드하는 것이 좋습니다.
[Blog & Links to YouTube videos](https://loopedback.com/2019/11/15/setting-up-eve-ng-for-ccna-ccnp-ccie-level-studies-includes-multiple-vendor-node-support-an-absolutely-amazing-study-tool-to-check-out-asap/)
[How To Add Cisco VIRL vIOS image to Eve-ng](https://networkhunt.com/how-to-add-cisco-virl-vios-image-to-eve-ng/)
전반적으로 단계가 조금 복잡하고 훨씬 더 쉬울 수도 있지만 위의 블로그와 동영상은 EVE-NG 박스에 이미지를 추가하는 과정을 안내합니다.
저는 FileZilla를 사용하여 SFTP를 통해 qcow2를 VM으로 전송했습니다.
실습에는 Cisco vIOS L2(스위치)와 Cisco vIOS(라우터)가 필요합니다.
### 실습 만들기
EVE-NG 웹 인터페이스 내에서 새로운 네트워크 Topology를 생성하겠습니다. 외부 네트워크에 대한 게이트웨이 역할을 할 스위치 4개와 라우터 1개가 있습니다.
| Node | IP Address |
| ------- | ------------ |
| Router | 10.10.88.110 |
| Switch1 | 10.10.88.111 |
| Switch2 | 10.10.88.112 |
| Switch3 | 10.10.88.113 |
| Switch4 | 10.10.88.114 |
#### EVE-NG에 노드 추가하기
EVE-NG에 처음 로그인하면 아래와 같은 화면이 표시되며, 첫 번째 랩을 생성하는 것부터 시작하겠습니다.
![](/2022/Days/Images/Day26_Networking2.png)
랩 이름을 지정하고 다른 필드는 선택 사항입니다.
![](/2022/Days/Images/Day26_Networking3.png)
그러면 네트워크 생성을 시작할 수 있는 빈 캔버스가 표시됩니다. 캔버스를 마우스 오른쪽 버튼으로 클릭하고 노드 추가를 선택합니다.
여기에서 긴 노드 옵션 목록이 표시되며, 위의 과정을 따라 했다면 아래 표시된 파란색 두 개가 선택되어 있고 나머지는 회색으로 표시되어 선택할 수 없습니다.
![](/2022/Days/Images/Day26_Networking4.png)
실습에 다음을 추가하려고 합니다:
- Cisco vIOS 라우터 1대
- Cisco vIOS 스위치 4개
간단한 마법사를 실행하여 실습에 추가하면 다음과 같은 화면이 나타납니다.
![](/2022/Days/Images/Day26_Networking5.png)
#### 노드 연결하기
이제 라우터와 스위치 사이에 연결을 추가해야 합니다. 장치 위로 마우스를 가져가면 아래와 같이 연결 아이콘이 표시되고 이를 연결하려는 장치에 연결하면 아주 쉽게 연결할 수 있습니다.
![](/2022/Days/Images/Day26_Networking6.png)
환경 연결이 완료되면 마우스 오른쪽 클릭 메뉴에서 찾을 수 있는 상자나 원을 사용하여 물리적 경계나 위치를 정의하는 방법을 추가할 수도 있습니다. 실험실의 이름이나 IP 주소를 정의하고 싶을 때 유용한 텍스트를 추가할 수도 있습니다.
저는 아래와 같이 실험실을 만들었습니다.
![](/2022/Days/Images/Day26_Networking7.png)
위의 실습은 모두 전원이 꺼져 있으며, 모든 것을 선택하고 마우스 오른쪽 버튼을 클릭한 후 선택된 시작을 선택하면 실습을 시작할 수 있습니다.
![](/2022/Days/Images/Day26_Networking8.png)
실습을 시작하고 실행하면 각 장치에 콘솔을 연결할 수 있으며, 이 단계에서는 아무 구성도 하지 않은 상태로 매우 멍청한 상태임을 알 수 있습니다. 각 터미널에서 직접 복사하거나 생성하여 각 노드에 구성을 추가할 수 있습니다.
참조를 위해 리포지토리의 네트워킹 폴더에 구성을 남겨두겠습니다.
| Node | Configuration |
| ------- | -------------------------------- |
| Router | [R1](/2022/Days/Networking/R1) |
| Switch1 | [SW1](/2022/Days/Networking/SW1) |
| Switch2 | [SW2](/2022/Days/Networking/SW2) |
| Switch3 | [SW3](/2022/Days/Networking/SW3) |
| Switch4 | [SW4](/2022/Days/Networking/SW4) |
## 자료
- [Free Course: Introduction to EVE-NG](https://www.youtube.com/watch?v=g6B0f_E0NMg)
- [EVE-NG - Creating your first lab](https://www.youtube.com/watch?v=9dPWARirtK8)
- [3 Necessary Skills for Network Automation](https://www.youtube.com/watch?v=KhiJ7Fu9kKA&list=WL&index=122&t=89s)
- [Computer Networking full course](https://www.youtube.com/watch?v=IPvYjXCsTg8)
- [Practical Networking](http://www.practicalnetworking.net/)
- [Python Network Automation](https://www.youtube.com/watch?v=xKPzLplPECU&list=WL&index=126)
저는 네트워크 엔지니어가 아니기 때문에 여기서 사용하는 대부분의 예제는 무료는 아니지만 네트워크 자동화를 이해하는 데 도움이 되는 시나리오 중 일부를 이 방대한 책에서 가져온 것입니다.
- [Hands-On Enterprise Automation with Python (Book)](https://www.packtpub.com/product/hands-on-enterprise-automation-with-python/9781788998512)
[Day 27](day27.md)에서 봐요!

139
2022/ko/Days/day27.md Normal file
View File

@ -0,0 +1,139 @@
---
title: '#90DaysOfDevOps - Getting Hands-On with Python & Network - Day 27'
published: false
description: 90DaysOfDevOps - Getting Hands-On with Python & Network
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048735
---
## 파이썬 및 네트워크 실습하기
네트워킹 기초의 마지막 섹션에서는 [Day 26](day26.md)에 만든 실습 환경으로 몇 가지 자동화 작업과 도구를 다뤄보겠습니다.
클라이언트 vs telnet에서 장치에 연결하기 위해 SSH 터널을 사용할 것입니다. 클라이언트와 기기 사이에 생성된 SSH 터널은 암호화됩니다. [Day 18](day18.md)의 Linux 섹션에서도 SSH에 대해 다루었습니다.
## 가상 에뮬레이트 환경에 액세스하기
스위치와 상호 작용하려면 EVE-NG 네트워크 내부에 워크스테이션이 필요하거나 Python이 설치된 Linux 박스를 배포하여 자동화를 수행할 수 있습니다([Resource for setting up Linux inside EVE-NG](https://www.youtube.com/watch?v=3Qstk3zngrY)) 또는 저처럼 워크스테이션에서 액세스할 수 있는 클라우드를 정의할 수 있습니다.
![](/2022/Days/Images/Day27_Networking3.png)
이를 위해 캔버스를 마우스 오른쪽 버튼으로 클릭하고 네트워크를 선택한 다음 "Management(Cloud0)"를 선택하면 홈 네트워크에 연결됩니다.
![](/2022/Days/Images/Day27_Networking4.png)
하지만 이 네트워크 내부에는 아무것도 없으므로 새 네트워크에서 각 장치로 연결을 추가해야 합니다. (제 네트워킹 지식이 더 필요한데, 다음 단계로 최상위 라우터에 이 작업을 수행한 다음, 이 하나의 케이블을 통해 나머지 네트워크에 연결할 수 있을 것 같나요?)
그런 다음 각 장치에 로그온하고 클라우드가 들어오는 위치에 적용되는 인터페이스에 대해 다음 명령을 실행했습니다.
```
enable
config t
int gi0/0
IP add DHCP
no sh
exit
exit
sh ip int br
```
마지막 단계에서는 홈 네트워크의 DHCP 주소를 제공합니다. 내 장치 네트워크 목록은 다음과 같습니다:
| Node | IP Address | Home Network IP |
| ------- | ------------ | --------------- |
| Router | 10.10.88.110 | 192.168.169.115 |
| Switch1 | 10.10.88.111 | 192.168.169.178 |
| Switch2 | 10.10.88.112 | 192.168.169.193 |
| Switch3 | 10.10.88.113 | 192.168.169.125 |
| Switch4 | 10.10.88.114 | 192.168.169.197 |
### 네트워크 장치에 SSH
위의 설정이 완료되었으므로 이제 워크스테이션을 사용하여 홈 네트워크의 장치에 연결할 수 있습니다. 저는 Putty를 사용하고 있지만 장치에 SSH를 할 수 있는 git bash와 같은 다른 터미널에도 액세스할 수 있습니다.
아래에서 라우터 장치에 대한 SSH 연결을 확인할 수 있습니다. (R1)
![](/2022/Days/Images/Day27_Networking5.png)
### 파이썬을 사용하여 장치에서 정보 수집하기
Python을 활용하는 첫 번째 예는 모든 장치에서 정보를 수집하는 것이며, 특히 각 장치에 연결하여 간단한 명령을 실행하여 인터페이스 구성 및 설정을 제공할 수 있기를 원합니다. 이 스크립트를 여기에 저장해 두었습니다. [netmiko_con_multi.py](/2022/Days/Networking/netmiko_con_multi.py)
이제 이 스크립트를 실행하면 모든 장치에서 각 포트 구성을 볼 수 있습니다.
![](/2022/Days/Images/Day27_Networking6.png)
다양한 장치를 많이 사용하는 경우 이 스크립트를 작성하면 한 곳에서 모든 구성을 중앙에서 빠르게 제어하고 이해할 수 있어 편리합니다.
### Python을 사용하여 디바이스 구성하기
위의 내용은 유용하지만 Python을 사용하여 장치를 구성하는 것은 어떻습니까? 시나리오에서 `SW1`과 `SW2` 사이에 트렁크 포트가 있습니다. 이 작업을 여러 개의 동일한 스위치에서 자동화하고 각 스위치에 수동으로 연결하여 구성을 변경할 필요가 없다고 다시 상상해 보겠습니다.
이를 위해 [netmiko_sendchange.py](/2022/Days/Networking/netmiko_sendchange.py)를 사용할 수 있습니다. 이렇게 하면 SSH를 통해 연결되고 `SW1`에서 해당 변경을 수행하여 `SW2`로 변경됩니다.
![](/2022/Days/Images/Day27_Networking7.png)
이제 코드를 보면 `sending configuration to device`이라는 메시지가, 이것이 발생했는지 확인되지 않은 경우 스크립트에 추가 코드를 추가하여 스위치에서 해당 확인 및 유효성 검사를 수행하거나 이전에 스크립트를 수정하여 이를 표시할 수 있습니다. [netmiko_con_multi_vlan.py](/2022/Days/Networking/netmiko_con_multi_vlan.py)
![](/2022/Days/Images/Day27_Networking8.png)
### 디바이스 구성 백업하기
또 다른 사용 사례는 네트워크 구성을 캡처하여 백업하는 것이지만, 네트워크에 있는 모든 장치에 연결하고 싶지는 않으므로 [backup.py](/2022/Days/Networking/backup.py)를 사용하여 이 작업을 자동화할 수도 있습니다. 또한 백업하려는 IP 주소로 [backup.txt](/2022/Days/Networking/backup.txt)를 채워야 합니다.
스크립트를 실행하면 아래와 같은 내용이 표시됩니다.
![](/2022/Days/Images/Day27_Networking9.png)
파이썬으로 간단한 인쇄 스크립트를 작성했기 때문에 백업 파일도 함께 보여드릴 수 있습니다.
![](/2022/Days/Images/Day27_Networking10.png)
### Paramiko
SSH를 위해 널리 사용되는 Python 모듈입니다. 자세한 내용은 [공식 GitHub 링크](https://github.com/paramiko/paramiko)에서 확인할 수 있습니다.
이 모듈은 `pip install paramiko` 명령어를 사용하여 설치할 수 있습니다.
![](/2022/Days/Images/Day27_Networking1.png)
파이썬 셸에 들어가서 Paramiko 모듈을 가져와서 설치가 완료되었는지 확인할 수 있습니다.
![](/2022/Days/Images/Day27_Networking2.png)
### Netmiko
Netmiko 모듈은 네트워크 디바이스만을 대상으로 하지만, Paramiko는 SSH 연결 전반을 처리하는 더 광범위한 도구입니다.
위에서 Paramiko와 함께 사용한 Netmiko는 `pip install netmiko`를 사용하여 설치할 수 있습니다.
Netmiko는 다양한 네트워크 벤더와 디바이스를 지원하며, 지원 디바이스 목록은 [GitHub Page](https://github.com/ktbyers/netmiko#supports)에서 확인할 수 있습니다.
### 기타 모듈
우리가 살펴볼 기회가 없었지만, 네트워크 자동화와 관련하여 훨씬 더 많은 기능을 제공하는 몇 가지 다른 모듈도 언급할 가치가 있습니다.
`netaddr`은 IP 주소 작업 및 조작에 사용되며, 설치는 `pip install netaddr`로 간단합니다.
스위치 구성을 엑셀 스프레드시트에 많이 저장하고 싶을 때, `xlrd`를 사용하면 스크립트가 엑셀 통합 문서를 읽고 행과 열을 행렬로 변환할 수 있습니다. `pip install xlrd`를 실행하면 모듈을 설치할 수 있습니다.
제가 미처 살펴보지 못한 네트워크 자동화를 사용할 수 있는 더 많은 사용 사례는 [여기](https://github.com/ktbyers/pynet/tree/master/presentations/dfwcug/examples)에서 확인할 수 있습니다.
네트워킹은 제가 한동안 다루지 않았던 분야이고 다뤄야 할 내용이 훨씬 더 많지만, 제가 작성한 노트와 이 글에서 공유한 리소스가 누군가에게 도움이 되기를 바랍니다.
## 자료
- [Free Course: Introduction to EVE-NG](https://www.youtube.com/watch?v=g6B0f_E0NMg)
- [EVE-NG - Creating your first lab](https://www.youtube.com/watch?v=9dPWARirtK8)
- [3 Necessary Skills for Network Automation](https://www.youtube.com/watch?v=KhiJ7Fu9kKA&list=WL&index=122&t=89s)
- [Computer Networking full course](https://www.youtube.com/watch?v=IPvYjXCsTg8)
- [Practical Networking](http://www.practicalnetworking.net/)
- [Python Network Automation](https://www.youtube.com/watch?v=xKPzLplPECU&list=WL&index=126)
저는 네트워크 엔지니어가 아니기 때문에 여기서 사용하는 대부분의 예제는 무료는 아니지만 네트워크 자동화를 이해하는 데 도움이 되는 시나리오 중 일부를 이 방대한 책에서 가져온 것입니다.
- [Hands-On Enterprise Automation with Python (Book)](https://www.packtpub.com/product/hands-on-enterprise-automation-with-python/9781788998512)
클라우드 컴퓨팅에 대해 알아보고 주제에 대한 이해와 기초 지식을 쌓을 수 있는 [Day 28](day28.md)에서 봐요!

105
2022/ko/Days/day28.md Normal file
View File

@ -0,0 +1,105 @@
---
title: '#90DaysOfDevOps - The Big Picture: DevOps & The Cloud - Day 28'
published: false
description: 90DaysOfDevOps - The Big Picture DevOps & The Cloud
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048737
---
## 큰 그림: 데브옵스와 클라우드
클라우드 컴퓨팅과 제공되는 서비스는 데브옵스 정신 및 프로세스와 매우 잘 어울립니다. 클라우드 컴퓨팅은 기술과 서비스를 제공하는 것으로 생각할 수 있지만, 앞서 여러 번 언급했듯이 데브옵스는 프로세스와 프로세스 개선에 관한 것입니다.
그러나 클라우드 학습 여정은 가파른 여정이며 모든 요소를 알고 이해하거나 적절한 가격대에 가장 적합한 서비스를 선택하는 것은 혼란스러운 일입니다.
![](/2022/Days/Images/Day28_Cloud1.png)
퍼블릭 클라우드에 데브옵스 마인드셋이 필요한가요? 제 대답은 '아니다'이지만, 클라우드 컴퓨팅을 제대로 활용하고 많은 사람이 겪었던 막대한 클라우드 비용을 피하려면 클라우드 컴퓨팅과 데브옵스를 함께 생각하는 것이 중요합니다.
퍼블릭 클라우드의 의미를 40,000피트 상공에서 보면, 관리형 서비스에 대한 책임을 일부 제거하여 여러분과 여러분의 팀이 애플리케이션과 최종 사용자라는 더 중요한 측면에 집중할 수 있도록 하는 것입니다. 결국 퍼블릭 클라우드는 다른 사람의 컴퓨터일 뿐입니다.
![](/2022/Days/Images/Day28_Cloud2.png)
이 첫 번째 섹션에서는 퍼블릭 클라우드가 무엇인지, 그리고 전체적으로 퍼블릭 클라우드라고 불리는 몇 가지 구성 요소에 대해 조금 더 자세히 설명하고자 합니다.
### SaaS
첫 번째로 다룰 영역은 서비스로서의 소프트웨어로, 이 서비스는 온-프레미스에서 실행하던 서비스의 거의 모든 관리 오버헤드를 제거합니다. 이메일용 Microsoft Exchange를 예로 들어 보겠습니다. 예전에는 데이터 센터나 계단 아래 찬장에 있는 물리적 상자였습니다. 이 서버에 먹이를 주고 물을 주어야 했습니다. 즉, 서버 하드웨어를 구입하고, 운영 체제를 설치하고, 필요한 애플리케이션을 설치한 다음 패치를 유지해야 하며, 문제가 발생하면 문제를 해결하고 다시 실행해야 합니다.
또한 데이터를 백업하고 있는지 확인해야 하지만, 대부분의 경우 SaaS를 사용한다고 해서 달라지지는 않습니다.
SaaS의 기능, 특히 Microsoft 365의 경우 앞서 Exchange를 언급했듯이 관리 오버헤드를 없애고 메일을 통해 Exchange 기능뿐만 아니라 다른 많은 생산성(Office 365) 및 저장소 옵션(OneDrive)을 제공하는 서비스를 제공하여 전반적으로 최종 사용자에게 훌륭한 경험을 제공합니다.
Salesforce, SAP, Oracle, Google, Apple과 같은 다른 SaaS 애플리케이션도 널리 채택되고 있습니다. 모두 더 많은 스택을 관리해야 하는 부담을 덜어줍니다.
DevOps와 SaaS 기반 애플리케이션에 대한 이야기가 있을 거라고 확신하지만, 그 내용을 파악하는 데 어려움을 겪고 있습니다. Azure DevOps에 Microsoft 365와의 훌륭한 통합 기능이 있다는 것을 알고 있으므로 살펴보고 다시 보고할 수 있습니다.
![](/2022/Days/Images/Day28_Cloud3.png)
### 퍼블릭 클라우드
다음은 퍼블릭 클라우드입니다. 대부분의 사람들은 퍼블릭 클라우드를 몇 가지 다른 방식으로 생각할 수 있으며, 일부는 Microsoft Azure, Google Cloud Platform 및 AWS와 같은 하이퍼 스케일러로만 볼 수 있습니다.
![](/2022/Days/Images/Day28_Cloud4.png)
또한 퍼블릭 클라우드를 이러한 하이퍼 스케일러뿐만 아니라 전 세계 수천 개의 MSP를 포함하는 훨씬 더 광범위한 서비스로 보는 사람도 있을 것입니다. 이 글에서는 하이퍼 스케일러와 MSP를 포함한 퍼블릭 클라우드를 고려할 예정이지만, 나중에 하이퍼 스케일러 중 하나 이상을 구체적으로 살펴봄으로써 기초적인 지식을 얻도록 하겠습니다.
![](/2022/Days/Images/Day28_Cloud5.png)
_수천 개의 더 많은 회사가 이 서비스를 이용할 수 있지만, 저는 제가 함께 일했고 알고 있는 로컬, 지역, 통신사 및 글로벌 브랜드 중에서 골랐을 뿐입니다_.
앞서 SaaS 섹션에서 클라우드가 시스템의 일부를 관리해야 하는 책임이나 부담을 덜어준다고 언급했습니다. SaaS의 경우 물리적 시스템, 네트워크, 스토리지, 운영 체제, 애플리케이션 등 많은 추상화 계층이 어느 정도 제거되었습니다. 클라우드의 경우 요구 사항에 따라 제거하거나 유지할 수 있는 추상화 수준이 다양합니다.
이미 SaaS에 대해 언급했지만, 퍼블릭 클라우드와 관련하여 최소 두 가지를 더 언급할 수 있습니다.
IaaS(Infrastructure as a Service) - 이 계층을 가상 머신으로 생각할 수 있지만, 온프레미스에서는 클라우드의 물리적 계층을 관리해야 하는 반면, 클라우드에서는 물리적 계층은 클라우드 제공업체의 책임이며 운영 체제, 데이터, 실행하려는 애플리케이션을 관리 및 운영하게 됩니다.
PaaS(Platform as a Service) - 계층의 책임이 계속 제거되며, 사용자가 데이터와 애플리케이션을 제어하지만, 기반이 되는 하드웨어나 운영 체제에 대해 걱정할 필요가 없습니다.
다른 많은 aaS 제품이 있지만, 이 두 가지가 기본입니다. 스토리지 계층을 제공하지만, 그 밑에 있는 하드웨어에 대해 걱정할 필요가 없는 StaaS(Storage as a service) 관련 제품을 볼 수 있습니다. 또는 컨테이너를 위한 CaaS에 대해 들어보셨을 수도 있고, 앞으로 7일 동안 다룰 또 다른 aaS는 시스템을 항상 가동할 필요가 없고 필요할 때만 함수를 실행하기를 원하는 경우에 사용할 수 있는 FaaS(Functions as a Service입니다.
퍼블릭 클라우드는 사용자가 원하는 제어 계층의 추상화 계층을 제공하고 비용을 지불할 수 있는 여러 가지 방법이 있습니다.
![](/2022/Days/Images/Day28_Cloud6.png)
### 프라이빗 클라우드
자체 데이터 센터를 보유하는 것은 과거의 일이 아닙니다. 퍼블릭 클라우드를 사용하는 것만으로는 기술뿐만 아니라 운영 비용 모델을 관리하기 어렵다는 것을 알게 된 많은 기업들 사이에서 다시 부상하고 있다고 생각합니다.
여기서 주목해야 할 중요한 점은 퍼블릭 클라우드는 이제 기업의 책임이 될 가능성이 높으며, 온프레미스 환경이 될 것이라는 점입니다.
가상화 시대와 온프레미스 인프라 환경을 지배했던 VMware뿐만 아니라 이 분야에서도 흥미로운 일들이 일어나고 있습니다. 퍼블릭 클라우드의 온프레미스 버전을 제공하는 하이퍼 스케일러도 있습니다.
![](/2022/Days/Images/Day28_Cloud7.png)
### 하이브리드 클라우드
앞서 언급한 퍼블릭 클라우드와 프라이빗 클라우드에 이어서, 퍼블릭 클라우드에서 제공되는 서비스를 활용하면서 온프레미스 환경의 기능을 활용하거나 규제에 따라 데이터를 로컬에 저장해야 하는 경우 두 환경 간에 유연성을 제공할 수 있는 하이브리드 클라우드도 있습니다.
![](/2022/Days/Images/Day28_Cloud8.png)
이 모든 것을 종합하면 워크로드를 저장하고 실행하는 위치에 대한 선택의 폭이 넓어집니다.
![](/2022/Days/Images/Day28_Cloud9.png)
구체적인 하이퍼스케일에 들어가기 전에 트위터의 힘에 우리가 어디로 가야 할지를 물어봤습니다.
![](/2022/Days/Images/Day28_Cloud10.png)
[트위터 설문조사 링크](https://twitter.com/MichaelCade1/status/1486814904510259208?s=20&t=x2n6QhyOXSUs7Pq0itdIIQ)
어느 쪽이 가장 높은 비율을 얻든 제품에 대해 더 자세히 살펴볼 것이지만, 중요한 것은 모든 서비스의 서비스가 상당히 유사하다는 점이며, 제가 하나부터 시작하라고 말하는 이유는 하나의 기초와 가상 머신 생성, 네트워킹 설정 방법 등을 알기 때문이라고 생각하기 때문입니다. 다른 서비스로 이동하여 해당 영역에서 빠르게 성장할 수 있었습니다.
어느 쪽이든, 저는 세 가지 하이퍼 스케일러를 모두 다루는 훌륭한 **무료** 리소스를 공유하려고 합니다.
또한 다른 섹션에서 그랬던 것처럼 시나리오를 작성하여 며칠 동안 진행하면서 무언가를 구축 할 수 있습니다.
## 자료
- [Hybrid Cloud and MultiCloud](https://www.youtube.com/watch?v=qkj5W98Xdvw)
- [Microsoft Azure Fundamentals](https://www.youtube.com/watch?v=NKEFWyqJ5XA&list=WL&index=130&t=12s)
- [Google Cloud Digital Leader Certification Course](https://www.youtube.com/watch?v=UGRDM86MBIQ&list=WL&index=131&t=10s)
- [AWS Basics for Beginners - Full Course](https://www.youtube.com/watch?v=ulprqHHWlng&t=5352s)
[Day 29](day29.md)에서 봐요!

141
2022/ko/Days/day29.md Normal file
View File

@ -0,0 +1,141 @@
---
title: '#90DaysOfDevOps - Microsoft Azure Fundamentals - Day 29'
published: false
description: 90DaysOfDevOps - Microsoft Azure Fundamentals
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048705
---
## Microsoft Azure 기초
시작하기 전에 트위터 투표의 승자는 Microsoft Azure였으며, 따라서 페이지의 제목도 그렇게 정해졌습니다. 박빙의 승부가 펼쳐졌고 24시간 동안의 결과가 꽤 흥미로웠습니다.
![](/2022/Days/Images/Day29_Cloud1.png)
이 주제를 다루면서 Microsoft Azure에서 사용할 수 있는 서비스에 대해 더 잘 이해하고 업데이트할 수 있다는 측면에서 저는 오늘 하루는 Amazon AWS에 기대고 있습니다. 하지만 세 가지 주요 클라우드 제공업체 모두에 대해 준비해 둔 리소스를 남겨 두었습니다.
설문조사에는 이 세 가지 서비스만 포함되었고 특히 오라클 클라우드에 대한 의견도 몇 개 있었습니다. 실제 사용 중인 다른 클라우드 제공업체에 대한 의견을 더 듣고 싶습니다.
### 기본 사항
- 퍼블릭 클라우드 서비스 제공
- 지리적으로 분산되어 있음(전 세계 60개 이상의 지역)
- 인터넷 및/또는 개인 연결을 통해 액세스
- 멀티 테넌트 모델
- 사용량 기반 청구 - (종량제 및 사용량 증가에 따른 과금)
- 다양한 요구 사항에 맞는 다양한 서비스 유형 및 제품.
- [Microsoft Azure 글로벌 인프라](https://infrastructuremap.microsoft.com/explore)
SaaS 및 하이브리드 클라우드에 대해 많이 이야기했지만 여기서는 해당 주제를 다루지 않을 계획입니다.
시작하고 따라 하는 가장 좋은 방법은 링크를 클릭하여 [Microsoft Azure 무료 계정](https://azure.microsoft.com/en-gb/free/)을 생성하는 것입니다.
### 지역
위의 인터랙티브 지도를 링크했는데, 아래 이미지에서 전 세계 Microsoft Azure 플랫폼에서 제공되는 다양한 지역을 확인할 수 있습니다.
![](/2022/Days/Images/Day29_Cloud2.png)
[Microsoft 문서](https://docs.microsoft.com/en-us/azure/networking/microsoft-global-network)에서 가져온 이미지 - _01/05/2021_
또한 다른 지역과 연결되지 않거나 다른 지역과 대화할 수 없음을 의미하는 여러 "sovereign" 클라우드를 볼 수 있는데, 예를 들어 `AzureUSGovernment`, `AzureChinaCloud` 등과 같은 정부와 관련된 클라우드가 있습니다.
Microsoft Azure 내에서 서비스를 배포할 때 거의 모든 것에 대해 지역을 선택합니다. 하지만 모든 지역에서 모든 서비스를 이용할 수 있는 것은 아니라는 점에 유의해야 합니다. 이 글을 쓰는 시점에 [지역별 사용 가능한 제품](https://azure.microsoft.com/en-us/global-infrastructure/services/?products=all)을 보면 미국 중서부 지역에서는 Azure Databricks을 사용할 수 없다는 것을 알 수 있습니다.
또한 위에서 "거의 모든 것"이라고 언급했는데, Azure Bot Services, Bing Speech, Azure Virtual Desktop, Static Web Apps 등과 같이 지역과 연결된 특정 서비스가 있습니다.
이면에서는 region이 둘 이상의 데이터 센터로 구성될 수 있습니다. 이를 가용 영역이라고 합니다.
아래 이미지에서 볼 수 있듯이 이 이미지는 Microsoft 공식 문서에서 가져온 것으로, region이란 무엇이며 region이 가용 영역으로 어떻게 구성되는지 설명합니다. 그러나 모든 지역에 가용 영역이 여러 개 있는 것은 아닙니다.
![](/2022/Days/Images/Day29_Cloud3.png)
Microsoft 설명서는 매우 훌륭하며 [여기](https://docs.microsoft.com/en-us/azure/availability-zones/az-overview)에서 지역 및 가용 영역에 대한 자세한 내용을 읽을 수 있습니다.
### 구독
Microsoft Azure는 모든 주요 클라우드 공급자가 이 모델을 따르는 소비 모델 클라우드라고 언급했음을 기억하세요.
엔터프라이즈인 경우 회사에서 이러한 Azure 서비스를 사용할 수 있도록 Microsoft와 엔터프라이즈 계약을 원하거나 이미 설정했을 수 있습니다.
저와 같이 교육용으로 Microsoft Azure를 사용하는 경우 몇 가지 다른 옵션이 있습니다.
일반적으로 일정 기간 동안 Azure에서 사용할 수 있는 몇 가지 무료 클라우드 크레딧을 제공하는 [Microsoft Azure 무료 계정](https://azure.microsoft.com/en-gb/free/)이 있습니다.
또한 Visual Studio 연간 구독과 함께 매달 몇 가지 무료 크레딧을 제공하는 [Visual Studio](https://azure.microsoft.com/en-us/pricing/member-offers/credit-for-visual-studio-subscribers/) 구독을 사용할 수도 있습니다(몇 년 전에는 일반적으로 MSDN으로 알려짐).
마지막으로 신용카드를 건네고 [종량제](https://azure.microsoft.com/en-us/pricing/purchase-options/pay-as-you-go/) 모델을 사용하는 방법이 있습니다.
구독은 잠재적으로 비용 중심이지만 완전히 다른 환경을 가진 서로 다른 구독 간의 경계로 볼 수 있습니다. 구독은 리소스가 생성되는 곳입니다.
### 관리 그룹
관리 그룹을 사용하면 Azure AD(Active Directory) 또는 테넌트 환경 전반에서 제어를 분리할 수 있습니다. 관리 그룹을 통해 정책, RBAC(역할 기반 액세스 제어) 및 예산을 제어할 수 있습니다.
구독은 이러한 관리 그룹에 속하므로 Azure AD 테넌트에 많은 구독을 보유할 수 있으며, 이러한 구독은 정책, RBAC 및 예산도 제어할 수 있습니다.
### 리소스 관리자 및 리소스 그룹
#### Azure 리소스 관리자
- 리소스 공급자를 기반으로 구축된 JSON 기반 API입니다.
- 리소스는 리소스 그룹에 속하며 공통 수명 주기를 공유합니다.
- 병렬 처리
- JSON 기반 배포는 선언적이고 비독립적이며 리소스 간의 종속성을 이해하여 생성 및 순서를 관리합니다.
#### 리소스 그룹
- 모든 Azure Resource Manager 리소스는 하나의 리소스 그룹에만 존재합니다!
- 리소스 그룹은 지역 외부의 리소스를 포함할 수 있는 지역에서 만들어집니다.
- 리소스 그룹 간에 리소스 이동 가능
- 리소스 그룹은 다른 리소스 그룹과 차단되지 않으며, 리소스 그룹 간에 통신할 수 있습니다.
- 리소스 그룹은 정책, RBAC 및 예산도 제어할 수 있습니다.
### 실습
이제 연결하여 **Subscription**을 사용할 수 있는지 확인해 보겠습니다. 기본 제공되는 간단한 **Management Group**을 확인한 다음, 원하는 **Region**에 새로운 전용 **Resource Group**을 만들 수 있습니다.
[Azure 포털](https://portal.azure.com/#home)에 처음 로그인하면 상단에 리소스, 서비스 및 문서를 검색할 수 있는 기능이 표시됩니다.
![](/2022/Days/Images/Day29_Cloud4.png)
먼저 구독을 살펴보겠습니다. 여기에서는 매달 무료 크레딧을 제공하는 Visual Studio Professional 구독을 사용하고 있음을 알 수 있습니다.
![](/2022/Days/Images/Day29_Cloud5.png)
더 넓은 화면으로 이동하여 구독으로 어떤 일이 일어나고 있는지 또는 무엇을 할 수 있는지 살펴보면 왼쪽에 IAM 액세스 제어를 정의할 수 있는 제어 기능과 함께 청구 정보를 볼 수 있으며 더 아래로 내려가면 더 많은 리소스를 사용할 수 있습니다.
![](/2022/Days/Images/Day29_Cloud6.png)
여러 개의 구독이 있고 이를 모두 하나의 구독으로 관리하려는 시나리오가 있을 수 있는데, 이때 관리 그룹을 사용하여 책임 그룹을 분리할 수 있습니다. 아래 제 경우에는 구독이 있는 테넌트 루트 그룹만 있는 것을 볼 수 있습니다.
또한 이전 이미지에서 상위 관리 그룹이 테넌트 루트 그룹에 사용된 아이디와 동일한 것을 볼 수 있습니다.
![](/2022/Days/Images/Day29_Cloud7.png)
다음으로 리소스 그룹이 있는데, 여기에서 리소스를 결합하여 한 곳에서 쉽게 관리할 수 있습니다. 저는 다른 여러 프로젝트를 위해 몇 개를 만들었습니다.
![](/2022/Days/Images/Day29_Cloud8.png)
앞으로 며칠 동안 할 작업을 위해 리소스 그룹을 만들고 싶습니다. 이 콘솔에서 이전 이미지의 생성 옵션을 누르면 쉽게 할 수 있습니다.
![](/2022/Days/Images/Day29_Cloud9.png)
유효성 검사 단계가 수행된 후 생성한 내용을 검토한 다음 생성할 수 있습니다. 또한 하단에 "Download a template for automation"가 표시되는데, 이를 통해 JSON 형식을 가져와서 나중에 원할 경우, 이 간단한 작업을 자동화 방식으로 수행할 수 있으며, 이에 대해서도 나중에 다룰 것입니다.
![](/2022/Days/Images/Day29_Cloud10.png)
생성 버튼을 누르면 리소스 그룹 목록에 다음 세션에서 수행할 작업을 위한 "90DaysOfDevOps" 그룹이 준비됩니다.
![](/2022/Days/Images/Day29_Cloud11.png)
## 자료
- [Hybrid Cloud and MultiCloud](https://www.youtube.com/watch?v=qkj5W98Xdvw)
- [Microsoft Azure Fundamentals](https://www.youtube.com/watch?v=NKEFWyqJ5XA&list=WL&index=130&t=12s)
- [Google Cloud Digital Leader Certification Course](https://www.youtube.com/watch?v=UGRDM86MBIQ&list=WL&index=131&t=10s)
- [AWS Basics for Beginners - Full Course](https://www.youtube.com/watch?v=ulprqHHWlng&t=5352s)
[Day 30](day30.md)에서 봐요!

175
2022/ko/Days/day30.md Normal file
View File

@ -0,0 +1,175 @@
---
title: '#90DaysOfDevOps - Microsoft Azure Security Models - Day 30'
published: false
description: 90DaysOfDevOps - Microsoft Azure Security Models
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1049039
---
## Microsoft Azure 보안 모델
Microsoft Azure 개요에 이어서 Azure 보안부터 시작하여 일상적인 업무에 어떤 도움이 될 수 있는지 살펴보겠습니다. 대부분의 경우 기본 제공 역할로도 충분하지만, 다양한 인증 및 구성 영역을 만들고 작업할 수 있다는 것을 알게 되었습니다. 다른 퍼블릭 클라우드에 비해 Microsoft Azure의 Active Directory 배경이 상당히 발전되어 있다는 것을 알았습니다.
Microsoft Azure가 다른 퍼블릭 클라우드 공급자와 다르게 작동하는 것처럼 보이는 영역 중 하나는 Azure에는 항상 Azure AD가 있다는 것입니다.
### 디렉토리 서비스
- Azure Active Directory는 Microsoft Azure 및 기타 Microsoft 클라우드 서비스에서 사용하는 보안 원칙을 호스팅합니다.
- 인증은 SAML, WS-Federation, OpenID Connect 및 OAuth2와 같은 프로토콜을 통해 수행됩니다.
- 쿼리는 Microsoft Graph API라는 REST API를 통해 수행됩니다.
- 테넌트는 tenant.onmicrosoft.com을 기본 이름으로 사용하지만 사용자 지정 도메인 이름을 사용할 수도 있습니다.
- 구독은 Azure Active Directory 테넌트와 연결됩니다.
AWS와 비교하기 위해 AWS를 생각해보면 여전히 매우 다르지만, AWS IAM(ID 및 액세스 관리)이 동등한 오퍼링이 될 것입니다.
Azure AD Connect는 AD에서 Azure AD로 계정을 복제하는 기능을 제공합니다. 여기에는 그룹과 때로는 개체가 포함될 수도 있습니다. 이는 세분화 및 필터링할 수 있습니다. 여러 포리스트 및 도메인을 지원합니다.
Microsoft Azure AD(Active Directory)에서 클라우드 계정을 만들 수 있지만 대부분의 조직은 이미 온-프레미스에 있는 자체 Active Directory에서 사용자를 계정화하고 있습니다.
Azure AD Connect를 사용하면 Windows AD 서버뿐만 아니라 다른 Azure AD, Google 및 기타 서버도 볼 수 있습니다. 또한 외부 사람 및 조직과 공동 작업할 수 있는 기능을 제공하는데, 이를 Azure B2B라고 합니다.
액티브 디렉토리 도메인 서비스와 Microsoft Azure 액티브 디렉토리 간의 인증 옵션은 암호 해시와 ID 동기화를 통해 모두 가능합니다.
![](/2022/Days/Images/Day30_Cloud1.png)
암호 해시 전달은 선택 사항이며, 암호 해시를 사용하지 않는 경우 통과 인증이 필요합니다.
아래에 링크된 비디오에서 패스스루 인증에 대해 자세히 설명합니다.
[Azure Active Directory 패스스루 인증을 사용한 사용자 로그인](https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-pta)
![](/2022/Days/Images/Day30_Cloud2.png)
### 페더레이션
Microsoft 365, Microsoft Dynamics 및 온-프레미스 Active Directory를 사용하는 경우 페더레이션을 위해 Azure AD를 이해하고 통합하는 것은 매우 쉽습니다. 하지만 Microsoft 에코시스템 외부의 다른 서비스를 사용하고 있을 수도 있습니다.
Azure AD는 이러한 다른 타사 앱 및 기타 디렉토리 서비스에 대한 페더레이션 브로커 역할을 할 수 있습니다.
이는 Azure 포털에서 다양한 옵션이 있는 엔터프라이즈 애플리케이션으로 표시됩니다.
![](/2022/Days/Images/Day30_Cloud3.png)
엔터프라이즈 애플리케이션 페이지에서 아래로 스크롤 하면 추천 애플리케이션의 긴 목록을 볼 수 있습니다.
![](/2022/Days/Images/Day30_Cloud4.png)
이 옵션을 사용하면 개발 중인 애플리케이션이나 갤러리 이외의 애플리케이션을 "직접 가져와서" 통합할 수도 있습니다.
이전에 이 기능을 살펴본 적은 없지만 다른 클라우드 제공업체 및 기능과 비교할 때 상당한 기능 집합이라는 것을 알 수 있습니다.
### 역할 기반 액세스 제어
여기서 다룰 범위는 이미 [Day 29](day29.md)에서 다뤘으며, 이러한 영역 중 하나에 따라 역할 기반 액세스 제어를 설정할 수 있습니다.
- 구독
- 관리 그룹
- 리소스 그룹
- 리소스
역할은 세 가지로 나눌 수 있으며, Microsoft Azure에는 많은 기본 제공 역할이 있습니다. 이 세 가지 역할은 다음과 같습니다:
- 소유자
- 기여자
- 리더
소유자와 기여자는 범위가 매우 유사하지만, 소유자가 권한을 변경할 수 있습니다.
다른 역할은 특정 유형의 Azure 리소스 및 사용자 지정 역할에 따라 다릅니다.
그룹과 사용자에 대한 사용 권한 할당에 중점을 두어야 합니다.
사용 권한은 상속됩니다.
다시 돌아가서 우리가 만든 "90DaysOfDevOps" 리소스 그룹을 살펴보고 그 안의 액세스 제어(IAM)를 확인하면 기여자 목록과 고객 사용자 액세스 관리자 목록이 있고 소유자 목록이 있는 것을 볼 수 있습니다(하지만 이 목록은 표시할 수 없습니다).
![](/2022/Days/Images/Day30_Cloud5.png)
또한 여기에서 할당된 역할이 빌트인 역할인지 여부와 해당 역할이 어떤 카테고리에 속하는지 확인할 수 있습니다.
![](/2022/Days/Images/Day30_Cloud6.png)
이 리소스 그룹에 대해 계정을 확인하고 해당 액세스 권한을 갖고자 하는 계정에 올바른 권한이 있는지 확인하거나 사용자가 너무 많은 액세스 권한을 갖고 있는지 확인하려는 경우 액세스 확인 탭을 사용할 수도 있습니다.
![](/2022/Days/Images/Day30_Cloud7.png)
### 클라우드용 Microsoft Defender
- 클라우드용 Microsoft Defender(이전의 Azure Security Center)는 전체 Azure 환경의 보안에 대한 인사이트를 제공합니다.
- 단일 대시보드를 통해 모든 Azure 및 비 Azure 리소스의 전반적인 보안 상태를 파악할 수 있으며(Azure Arc를 통해) 보안 강화 지침을 제공합니다.
- 프리티어에는 지속적인 평가 및 보안 권장 사항이 포함됩니다.
- 보호되는 리소스 유형(예: Servers, AppService, SQL, Storage, Containers, KeyVault)에 대한 유료 플랜.
다른 구독으로 전환하여 Azure 보안 센터를 확인했으며, 여기에서 몇 가지 리소스를 기반으로 한 곳에서 몇 가지 권장 사항을 확인할 수 있습니다.
![](/2022/Days/Images/Day30_Cloud8.png)
### Azure 정책
- Azure Policy는 조직 표준을 적용하고 대규모로 규정 준수를 평가하는 데 도움이 되는 Azure 기본 서비스입니다.
- 클라우드용 Microsoft Defender에 통합됩니다. Azure Policy는 규정을 준수하지 않는 리소스를 감사하고 수정 사항을 적용합니다.
- 리소스 일관성, 규정 준수, 보안, 비용 및 관리 표준을 관리하는 데 일반적으로 사용됩니다.
- JSON 형식을 사용하여 평가 로직을 저장하고 리소스의 규정 준수 여부와 규정 미준수 시 취할 조치(예: 감사, AuditIfNotExists, 거부, 수정, DeployIfNotExists)를 결정합니다.
- 무료로 사용할 수 있습니다. 단, Azure 정책 게스트 구성 사용량에 대해 서버/월당 청구되는 Azure Arc 연결 리소스는 예외입니다.
### 실습
www.90DaysOfDevOps.com 도메인을 구입했는데 이 도메인을 내 Azure Active Directory 포털에 추가하고 싶습니다. [Azure Active Directory 포털을 사용하여 사용자 지정 도메인 이름 추가](https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/add-custom-domain)
![](/2022/Days/Images/Day30_Cloud9.png)
이제 새 Active Directory 도메인에 새 사용자를 만들 수 있습니다.
![](/2022/Days/Images/Day30_Cloud10.png)
이제 모든 새로운 90DaysOfDevOps 사용자를 하나의 그룹으로 묶는 그룹을 만들고 싶습니다. 아래와 같이 그룹을 만들 수 있으며, Azure AD가 사용자 계정을 쿼리하여 동적으로 추가하는 "Dynamic User"와 수동으로 사용자를 그룹에 추가하는 "Assigned"를 사용하고 있음을 알 수 있습니다.
![](/2022/Days/Images/Day30_Cloud11.png)
쿼리를 작성할 때 많은 옵션이 있지만, 저는 단순히 대표 이름을 찾아 이름에 @90DaysOfDevOps.com이 포함되어 있는지 확인하려고 합니다.
![](/2022/Days/Images/Day30_Cloud12.png)
이제 michael.cade@90DaysOfDevOps.com 에 대한 사용자 계정을 이미 만들었으므로 규칙이 작동하는지 확인할 수 있습니다. 비교를 위해 다른 도메인에 연결한 다른 계정도 여기에 추가했는데, 이 규칙으로 인해 사용자가 이 그룹에 속하지 않는 것을 볼 수 있습니다.
![](/2022/Days/Images/Day30_Cloud13.png)
그 후 user1@90DaysOfDevOps.com 을 새로 추가했고 그룹을 확인하면 회원을 볼 수 있습니다.
![](/2022/Days/Images/Day30_Cloud14.png)
이 요구 사항이 많아진다면, 콘솔에서 이 모든 작업을 수행하지 않고 대량 옵션을 사용하여 사용자를 만들고, 초대하고, 삭제하거나 PowerShell을 사용하여 자동화된 확장 방식을 사용하고 싶을 것입니다.
이제 리소스 그룹으로 이동하여 90DaysOfDevOps 리소스 그룹에서 소유자가 방금 만든 그룹이 되도록 지정할 수 있습니다.
![](/2022/Days/Images/Day30_Cloud15.png)
마찬가지로 여기로 이동하여 리소스 그룹에 대한 할당 액세스를 거부할 수도 있습니다.
이제 새 사용자 계정으로 Azure Portal에 로그인하면 액세스 권한이 없기 때문에 이전 그림에서 볼 수 있는 다른 리소스 그룹에는 액세스 권한이 없고 90DaysOfDevOps 리소스 그룹에만 액세스 권한이 있는 것을 볼 수 있습니다.
![](/2022/Days/Images/Day30_Cloud16.png)
모든 사용자가 포털을 알고 있을 필요는 없지만, 액세스 권한을 확인하기 위해 [앱 포털](https://myapps.microsoft.com/)을 사용하여 테스트할 수 있는 싱글 사인온 포털입니다.
![](/2022/Days/Images/Day30_Cloud17.png)
이 포털을 브랜딩으로 사용자 지정할 수 있으며, 이 부분은 나중에 다시 다룰 수 있습니다.
## 자료
- [Hybrid Cloud and MultiCloud](https://www.youtube.com/watch?v=qkj5W98Xdvw)
- [Microsoft Azure Fundamentals](https://www.youtube.com/watch?v=NKEFWyqJ5XA&list=WL&index=130&t=12s)
- [Google Cloud Digital Leader Certification Course](https://www.youtube.com/watch?v=UGRDM86MBIQ&list=WL&index=131&t=10s)
- [AWS Basics for Beginners - Full Course](https://www.youtube.com/watch?v=ulprqHHWlng&t=5352s)
[Day 31](day31.md)에서 봐요!

114
2022/ko/Days/day31.md Normal file
View File

@ -0,0 +1,114 @@
---
title: '#90DaysOfDevOps - Microsoft Azure Compute Models - Day 31'
published: false
description: 90DaysOfDevOps - Microsoft Azure Compute Models
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1049040
---
## Microsoft Azure 컴퓨팅 모델
어제 Microsoft Azure의 보안 모델에 대한 기본 사항을 다룬 데 이어 오늘은 Azure에서 사용할 수 있는 다양한 컴퓨팅 서비스에 대해 살펴보겠습니다.
### 서비스 가용성 옵션
이 섹션은 데이터 관리에서 제 역할을 고려할 때 제 마음에 와닿는 부분입니다. 온-프레미스와 마찬가지로 서비스의 가용성을 보장하는 것이 중요합니다.
- 고가용성(지역 내 보호)
- 재해 복구(지역 간 보호)
- 백업(특정 시점으로부터의 복구)
Microsoft는 지정학적 경계 내에 여러 지역을 배포합니다.
서비스 가용성을 위한 Azure의 두 가지 개념엔 Sets와 영역이 있습니다.
가용성 Sets - 데이터 센터 내에서 복원력 제공
가용성 영역 - 지역 내 데이터 센터 간에 복원력을 제공합니다.
### 가상 머신
퍼블릭 클라우드의 시작점일 가능성이 높습니다.
- 다양한 기능을 갖춘 다양한 계열 및 [크기](https://docs.microsoft.com/en-us/azure/virtual-machines/sizes)의 가상 머신을 제공합니다(때로는 압도적일 수 있음).
- 고성능, 짧은 지연 시간, 높은 메모리 옵션의 VM에 이르기까지 다양한 옵션과 초점이 있는 VM을 제공합니다.
- 또한 B-Series에서 찾을 수 있는 burstable VM 유형도 있습니다. 이는 대부분의 경우 CPU 요구 사항이 낮지만, 한 달에 한 번 정도 성능 급증이 필요한 워크로드에 적합합니다.
- 가상 머신은 모든 네트워크에 연결을 제공할 수 있는 가상 네트워크에 배치됩니다.
- Windows 및 Linux 게스트 OS 지원.
- 특정 Linux 배포판의 경우 [Azure 튜닝된 커널](https://docs.microsoft.com/en-us/azure/virtual-machines/linux/endorsed-distros#azure-tuned-kernels)도 있습니다.
### 템플릿
앞서 마이크로소프트 애저의 이면이나 밑에 있는 모든 것이 JSON이라고 언급했습니다.
리소스를 생성하는 데 사용할 수 있는 여러 가지 관리 포털과 콘솔이 있지만, 가장 선호하는 경로는 JSON 템플릿을 통한 것입니다.
증분 또는 전체 모드, 즉 반복 가능한 원하는 상태의 무동력 배포.
배포된 리소스 정의를 내보낼 수 있는 다양한 템플릿이 있습니다. 저는 이 템플릿 기능을 AWS CloudFormation과 같은 것에 적용하거나 멀티클라우드 옵션을 위한 Terraform이 될 수 있다고 생각하고 있습니다. Terraform에 대해서는 IaC 섹션에서 자세히 다루겠습니다.
### 스케일링
자동 확장은 사용하지 않는 리소스를 스핀다운 하거나 필요할 때 스핀업할 수 있는 퍼블릭 클라우드의 큰 기능입니다.
Azure에는 IaaS용 VMSS(Virtual Machine Scale Sets)라는 것이 있습니다. 이를 통해 일정 및 메트릭을 기반으로 골드 스탠다드 이미지를 자동으로 생성하고 확장할 수 있습니다.
이는 윈도우를 업데이트하는 데 이상적이므로 이미지를 업데이트하고 최소한의 영향을 미치면서 배포할 수 있습니다.
Azure 앱 서비스와 같은 다른 서비스에는 자동 확장 기능이 내장되어 있습니다.
### 컨테이너
컨테이너를 사용 사례로 다루지 않았고 DevOps 학습 여정에서 컨테이너가 필요한 이유와 방법을 다루지 않았지만, Azure에는 몇 가지 특정 컨테이너 중심 서비스가 있다는 점을 언급할 필요가 있습니다.
Azure Kubernetes Service(AKS) - 기반 클러스터 관리의 control plane이나 관리에 대해 걱정할 필요가 없는 관리형 Kubernetes 솔루션을 제공합니다. 나중에 Kubernetes에 대해 자세히 알아보세요.
Azure Container Instances - 초당 과금 방식의 서비스형 컨테이너. 컨테이너 오케스트레이션이 필요 없이 이미지를 실행하고 가상 네트워크와 통합할 수 있습니다.
Service Fabric - 많은 기능을 제공하지만, 컨테이너 인스턴스에 대한 오케스트레이션이 포함되어 있습니다.
Azure에는 Docker 이미지, Helm 차트, OCI 아티팩트 및 이미지에 대한 비공개 레지스트리를 제공하는 컨테이너 레지스트리도 있습니다. 이에 대해서는 컨테이너 섹션에서 다시 자세히 설명하겠습니다.
또한 많은 컨테이너 서비스가 실제로 컨테이너를 내부적으로 활용할 수도 있지만 이는 관리 요구 사항에서 추상화되어 있다는 점도 언급해야 합니다.
앞서 언급한 컨테이너 중심 서비스는 다른 모든 퍼블릭 클라우드에서도 비슷한 서비스를 찾을 수 있습니다.
### 애플리케이션 서비스
- Azure Application Services는 서비스를 쉽게 설정할 수 있는 애플리케이션 호스팅 솔루션을 제공합니다.
- 자동 배포 및 확장.
- Windows 및 Linux 기반 솔루션을 지원합니다.
- 서비스는 유형과 크기가 지정된 앱 서비스 플랜에서 실행됩니다.
- 웹 앱, API 앱, 모바일 앱 등 다양한 서비스를 지원합니다.
- 안정적인 테스트 및 홍보를 위한 배포 슬롯 지원.
### 서버리스 컴퓨팅
저에게 서버리스는 더 배우고 싶은 흥미진진한 다음 단계입니다.
서버리스의 목표는 함수의 런타임에 대해서만 비용을 지불하고 가상 머신이나 PaaS 애플리케이션을 항상 실행할 필요가 없다는 것입니다. 필요할 때 함수를 실행하기만 하면 사라집니다.
Azure Functions - 서버리스 코드를 제공합니다. 퍼블릭 클라우드에 대해 처음 살펴본 것을 기억한다면 관리의 추상화 계층을 기억할 수 있는데, 서버리스 함수를 사용하면 코드만 관리하게 됩니다.
대규모의 이벤트 기반은 나중에 실습을 하게 되면 무언가를 구축할 계획이 있습니다.
많은 Azure 및 타사 서비스에 대한 입력 및 출력 바인딩을 제공합니다.
다양한 프로그래밍 언어를 지원합니다. (C#, NodeJS, Python, PHP, batch, bash, Golang 및 Rust. 또는 모든 실행 파일)
Azure Event Grid를 사용하면 서비스 및 이벤트에서 로직을 트리거할 수 있습니다.
Azure Logic App은 그래픽 기반 워크플로 및 통합을 제공합니다.
또한 일관된 관리 및 예약을 통해 Windows 및 Linux 노드 모두에서 대규모 작업을 실행할 수 있는 Azure Batch도 살펴볼 수 있습니다.
## 자료
- [Hybrid Cloud and MultiCloud](https://www.youtube.com/watch?v=qkj5W98Xdvw)
- [Microsoft Azure Fundamentals](https://www.youtube.com/watch?v=NKEFWyqJ5XA&list=WL&index=130&t=12s)
- [Google Cloud Digital Leader Certification Course](https://www.youtube.com/watch?v=UGRDM86MBIQ&list=WL&index=131&t=10s)
- [AWS Basics for Beginners - Full Course](https://www.youtube.com/watch?v=ulprqHHWlng&t=5352s)
[Day 32](day32.md)에서 봐요!

191
2022/ko/Days/day32.md Normal file
View File

@ -0,0 +1,191 @@
---
title: '#90DaysOfDevOps - Microsoft Azure Storage Models - Day 32'
published: false
description: 90DaysOfDevOps - Microsoft Azure Storage Models
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048775
---
## Microsoft Azure 스토리지 모델
### 스토리지 서비스
- Azure 스토리지 서비스는 스토리지 계정으로 제공됩니다.
- 스토리지 계정은 주로 REST API를 통해 액세스합니다.
- 스토리지 계정은 DNS 이름(`<Storage Account name>.core.windows.net`)의 일부인 고유한 이름을 가져야 합니다.
- 다양한 복제 및 암호화 옵션.
- 리소스 그룹 내에 위치
Azure Portal 상단의 검색 창에서 저장소 그룹을 검색하여 저장소 그룹을 만들 수 있습니다.
![](/2022/Days/Images/Day32_Cloud1.png)
그런 다음 이 이름은 고유해야 하며 공백 없이 모두 소문자이어야 하지만 숫자를 포함할 수 있다는 점을 기억하고 스토리지 계정을 만들기 위한 단계를 실행할 수 있습니다.
![](/2022/Days/Images/Day32_Cloud2.png)
또한 스토리지 계정과 여기에 저장하는 모든 항목에 대해 원하는 중복성 수준을 선택할 수 있습니다. 목록에서 아래로 내려갈수록 옵션은 더 비싸지만, 데이터는 더 많이 분산됩니다.
기본 중복 옵션조차도 데이터의 사본 3개를 제공합니다.
[Azure 스토리지 이중화](https://docs.microsoft.com/en-us/azure/storage/common/storage-redundancy)
위 링크의 요약은 아래와 같습니다:
- **Locally-redundant storage** - 기본 지역의 단일 데이터 센터 내에서 데이터를 세 번 복제합니다.
- **Geo-redundant storage** - LRS를 사용하여 기본 지역의 단일 물리적 위치 내에서 데이터를 세 번 동기식으로 복사합니다.
- **Zone-redundant storage** - 기본 지역의 Azure 가용성 영역 3개에 걸쳐 Azure 스토리지 데이터를 동기식으로 복제합니다.
- **Geo-zone-redundant storage** - 가용성 영역 간 중복으로 제공되는 고가용성과 지리적 복제를 통해 제공되는 지역 중단으로부터의 보호를 결합합니다. GZRS 스토리지 계정의 데이터는 기본 지역의 Azure 가용 영역 3개에 복사되며, 지역 재해로부터 보호하기 위해 두 번째 지리적 영역에도 복제됩니다.
![](/2022/Days/Images/Day32_Cloud3.png)
다시 성능 옵션으로 이동합니다. 스탠다드와 프리미엄 중에서 선택할 수 있습니다. 여기서는 스탠다드를 선택했지만, 프리미엄은 몇 가지 구체적인 옵션을 제공합니다.
![](/2022/Days/Images/Day32_Cloud4.png)
드롭다운에서 다음 세 가지 옵션 중에서 선택할 수 있습니다.
![](/2022/Days/Images/Day32_Cloud5.png)
스토리지 계정에 사용할 수 있는 고급 옵션은 훨씬 더 많지만, 지금은 이러한 영역에 대해 자세히 설명할 필요가 없습니다. 이러한 옵션은 암호화와 데이터 보호에 관한 것입니다.
### 관리 디스크
몇 가지 방법으로 스토리지에 액세스할 수 있습니다.
인증된 액세스를 통한 액세스:
- 전체 제어를 위한 공유키.
- 위임된 세분화된 액세스를 위한 공유 액세스 서명.
- Azure Active Directory(사용 가능한 경우)
공용 액세스:
- 공용 액세스를 부여하여 HTTP를 통한 익명 액세스를 활성화할 수도 있습니다.
- 예를 들어 기본 콘텐츠와 파일을 블록 블롭에 호스팅하여 브라우저가 이 데이터를 보고 다운로드할 수 있도록 할 수 있습니다.
다른 Azure 서비스에서 스토리지에 액세스하는 경우 트래픽은 Azure 내에 유지됩니다.
스토리지 성능에는 두 가지 유형이 있습니다:
- **Standard** - 최대 IOPS 수
- **Premium** - 보장된 IOPS 수
IOPS => 초당 입/출력 작업 수.
작업에 적합한 스토리지를 선택할 때 고려해야 할 비관리형 디스크와 관리형 디스크의 차이점도 있습니다.
### 가상 머신 스토리지
- 가상 머신 OS 디스크는 일반적으로 persistent 스토리지에 저장됩니다.
- 일부 상태 비저장 워크로드에는 persistent 스토리지가 필요하지 않으며 레이턴시 감소가 더 큰 이점이 됩니다.
- 노드-로컬 스토리지에 생성되는 임시 OS 관리 디스크를 지원하는 VM이 있습니다.
- 이러한 디스크는 VM 스케일 세트와 함께 사용할 수도 있습니다.
관리 디스크는 Azure Virtual 머신과 함께 사용할 수 있는 내구성 있는 블록 스토리지입니다. Ultra Disk Storage, Premium SSD, Standard SSD 또은 Standard HDD를 사용할 수 있습니다. 또한 몇 가지 특징이 있습니다.
- 스냅샷 및 이미지 지원
- SKU 간 간단한 이동
- 가용성 세트와 결합하여 가용성 향상
- 사용한 스토리지가 아닌 디스크 크기를 기준으로 요금이 청구됩니다.
## 아카이브 스토리지
- **Cool Tier** - 블롭을 차단하고 추가할 수 있는 쿨 티어 스토리지를 사용할 수 있습니다.
- 스토리지 비용 절감
- 트랜잭션 비용이 더 높습니다.
- **Archive Tier** - 블록 블롭에 아카이브 스토리지를 사용할 수 있습니다.
- 이것은 블롭 단위로 구성됩니다.
- 더 저렴한 비용, 더 긴 데이터 검색 대기 시간.
- 일반 Azure 스토리지와 동일한 데이터 내구성.
- 필요에 따라 사용자 지정 데이터 계층화를 사용하도록 설정할 수 있습니다.
### 파일 공유
위에서 스토리지 계정을 만들었으므로 이제 파일 공유를 만들 수 있습니다.
![](/2022/Days/Images/Day32_Cloud6.png)
이렇게 하면 Azure에서 SMB2.1 및 3.0 파일 공유가 제공됩니다.
Azure 내부에서 사용할 수 있으며 인터넷에 연결된 SMB3 및 포트 445를 통해 외부에서도 사용할 수 있습니다.
Azure에서 공유 파일 스토리지를 제공합니다.
REST API 외에 표준 SMB 클라이언트를 사용하여 매핑할 수 있습니다.
[Azure NetApp Files](https://vzilla.co.uk/vzilla-blog/azure-netapp-files-how)(SMB 및 NFS)도 참조하세요.
### 캐싱 및 미디어 서비스
Azure 콘텐츠 전송 네트워크는 전 세계에 위치한 정적 웹 콘텐츠의 캐시를 제공합니다.
Azure 미디어 서비스는 재생 서비스 외에 미디어 트랜스코딩 기술을 제공합니다.
## Microsoft Azure 데이터베이스 모델
지난 [Day 28](day28.md)에서 다양한 서비스 옵션에 대해 다뤘습니다. 그중 하나는 많은 양의 인프라와 운영 체제를 추상화하고 애플리케이션 또는 이 경우 데이터베이스 모델만 제어할 수 있는 PaaS(서비스형 플랫폼)였습니다.
### 관계형 데이터베이스
Azure SQL 데이터베이스는 Microsoft SQL Server를 기반으로 하는 서비스로서의 관계형 데이터베이스를 제공합니다.
이는 특정 기능 버전이 필요한 경우 데이터베이스 호환성 수준을 사용할 수 있는 최신 SQL 브랜치를 실행하는 SQL입니다.
이를 구성하는 방법에는 몇 가지 옵션이 있는데, 인스턴스에서 하나의 데이터베이스를 제공하는 단일 데이터베이스를 제공할 수 있으며, 탄력적 풀을 사용하면 용량 풀을 공유하고 집합적으로 확장하는 여러 데이터베이스를 사용할 수 있습니다.
이러한 데이터베이스 인스턴스는 일반 SQL 인스턴스처럼 액세스할 수 있습니다.
MySQL, PostgreSQL 및 MariaDB를 위한 추가 관리형 제품.
![](/2022/Days/Images/Day32_Cloud7.png)
### NoSQL 솔루션
Azure Cosmos DB는 스키마에 구애받지 않는 NoSQL 구현입니다.
99.99% SLA
자동 유도를 통해 전 세계 어디서나 99번째 백분위수에서 한 자릿수 지연 시간을 제공하는 전 세계에 분산된 데이터베이스입니다.
데이터의 partitioning/sharding/distribution에 파티션 키를 활용합니다.
다양한 데이터 모델 지원(documents, key-value, graph, column-friendly)
다양한 API 지원(DocumentDB SQL, MongoDB, Azure Table Storage, Gremlin)
![](/2022/Days/Images/Day32_Cloud9.png)
[CAP 정리](https://en.wikipedia.org/wiki/CAP_theorem)를 기반으로 다양한 정합성 모델을 제공합니다.
![](/2022/Days/Images/Day32_Cloud8.png)
### 캐싱
Redis와 같은 캐싱 시스템에 대한 자세한 설명은 생략하고 Microsoft Azure에는 Azure Cache for Redis라는 서비스가 있다는 점을 말씀드리고 싶었습니다.
Azure Cache for Redis는 Redis 소프트웨어를 기반으로 하는 인메모리 데이터 저장소를 제공합니다.
- 이 서비스는 오픈 소스 Redis Cache를 구현한 것입니다.
- 호스팅된 보안 Redis 캐시 인스턴스입니다.
- 다양한 티어를 사용할 수 있습니다.
- 캐시를 활용하려면 애플리케이션을 업데이트해야 합니다.
- 쓰기에 비해 읽기 요구 사항이 높은 애플리케이션을 대상으로 합니다.
- 키-값 저장소 기반.
![](/2022/Days/Images/Day32_Cloud10.png)
지난 며칠 동안 Microsoft Azure에 대해 많은 메모를 하고 이론을 공부했지만, 이러한 구성 요소가 어떻게 결합되고 작동하는지에 대한 실무적인 측면으로 들어가기 전에 기본 구성 요소를 다루고 싶었습니다.
시나리오 기반 서비스 배포를 시작하고 실행하기 전에 네트워킹과 관련된 이론이 한 가지 더 남아 있습니다. 또한 지금까지 사용하던 포털을 사용할 때와 Microsoft Azure와 상호 작용할 수 있는 몇 가지 다른 방법도 살펴보고자 합니다.
## 자료
- [Hybrid Cloud and MultiCloud](https://www.youtube.com/watch?v=qkj5W98Xdvw)
- [Microsoft Azure Fundamentals](https://www.youtube.com/watch?v=NKEFWyqJ5XA&list=WL&index=130&t=12s)
- [Google Cloud Digital Leader Certification Course](https://www.youtube.com/watch?v=UGRDM86MBIQ&list=WL&index=131&t=10s)
- [AWS Basics for Beginners - Full Course](https://www.youtube.com/watch?v=ulprqHHWlng&t=5352s)
[Day 33](day33.md)에서 봐요!

190
2022/ko/Days/day33.md Normal file
View File

@ -0,0 +1,190 @@
---
title: '#90DaysOfDevOps - Microsoft Azure Networking Models + Azure Management - Day 33'
published: false
description: 90DaysOfDevOps - Microsoft Azure Networking Models + Azure Management
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048706
---
## Microsoft Azure 네트워킹 모델 + Azure 관리
오늘이 Microsoft Azure의 12번째 생일을 기념하는 날인 것 같습니다! (2022년 2월 1일) 아무튼, 이번 포스팅에서는 Microsoft Azure 내의 네트워킹 모델과 Azure 관리 옵션에 대해 알아보려고 합니다. 지금까지는 Azure 포털만 사용했지만, 플랫폼 내에서 리소스를 구동하고 생성하는 데 사용할 수 있는 다른 영역에 대해서도 언급했습니다.
## Azure 네트워크 모델
### 가상 네트워크
- 가상 네트워크는 Azure에서 생성된 구조입니다.
- 가상 네트워크에는 하나 이상의 IP 범위가 할당됩니다.
- 가상 네트워크는 지역 내 구독 내에 존재합니다.
- 가상 서브넷은 네트워크 범위를 분할하기 위해 가상 네트워크에 생성됩니다.
- 가상 머신은 가상 서브넷에 배치됩니다.
- 가상 네트워크 내의 모든 가상 머신은 통신할 수 있습니다.
- 가상 네트워크당 65,536개의 프라이빗 IP.
- 리전으로부터의 송신 트래픽에 대해서만 비용을 지불합니다. (리전을 벗어나는 데이터)
- IPv4 및 IPv6 지원.
- 퍼블릭 대면 및 가상 네트워크 내 IPv6.
Azure 가상 네트워크는 AWS VPC에 비유할 수 있습니다. 하지만 몇 가지 주의해야 할 차이점이 있습니다:
- AWS에서는 기본 VNet이 생성되지만 Microsoft Azure에서는 그렇지 않으므로 요구 사항에 맞게 첫 번째 가상 네트워크를 생성해야 합니다.
- Azure의 모든 가상 머신은 기본적으로 인터넷에 대한 NAT 액세스 권한을 갖습니다. AWS에 따른 NAT 게이트웨이가 없습니다.
- Microsoft Azure에는 사설 또는 공용 서브넷의 개념이 없습니다.
- 공용 IP는 vNIC 또는 로드 밸런서에 할당할 수 있는 리소스입니다.
- 가상 네트워크와 서브넷에는 서브넷 수준 위임을 가능하게 하는 자체 ACL이 있습니다.
- AWS에서는 가용 영역별로 서브넷이 있는 반면, 가상 네트워크에서는 가용 영역 전체에 걸쳐 서브넷이 있습니다.
또한 가상 네트워크 피어링도 있습니다. 이를 통해 테넌트 및 리전 전반의 가상 네트워크를 Azure 백본을 사용하여 연결할 수 있습니다. 전이되지는 않지만, 허브 가상 네트워크의 Azure 방화벽을 통해 활성화할 수 있습니다. 게이트웨이 트랜짓을 사용하면 피어링된 가상 네트워크가 연결된 네트워크에 연결할 수 있으며, 그 예로 ExpressRoute to On-Premises를 들 수 있습니다.
### 액세스 제어
- Azure는 네트워크 보안 그룹을 활용하며, 이는 stateful합니다.
- 규칙을 만든 다음 네트워크 보안 그룹에 할당할 수 있습니다.
- 네트워크 보안 그룹은 서브넷 또는 VM에 적용됩니다.
- 서브넷에 적용되는 경우에도 가상 머신 NIC에서는 여전히 "Edge" 디바이스가 아닌 것으로 적용됩니다.
![](/2022/Days/Images/Day33_Cloud1.png)
- 규칙은 네트워크 보안 그룹에 결합됩니다.
- 우선순위에 따라 유연한 구성이 가능합니다.
- 우선순위 숫자가 낮을수록 우선순위가 높습니다.
- 대부분의 로직은 IP 주소로 구축되지만, 일부 태그와 레이블도 사용할 수 있습니다.
| Description | Priority | Source Address | Source Port | Destination Address | Destination Port | Action |
| ---------------- | -------- | ------------------ | ----------- | ------------------- | ---------------- | ------ |
| Inbound 443 | 1005 | \* | \* | \* | 443 | Allow |
| ILB | 1010 | Azure LoadBalancer | \* | \* | 10000 | Allow |
| Deny All Inbound | 4000 | \* | \* | \* | \* | DENY |
또한 애플리케이션 보안 그룹(ASG)도 있습니다.
- NSG가 성장하는 환경에서 유지 관리가 어려울 수 있는 IP 주소 범위에 초점을 맞추는 경우.
- ASG를 사용하면 다양한 애플리케이션 역할(웹서버, DB 서버, WebApp1 등)에 대한 실제 이름(Monikers)을 정의할 수 있습니다.
- 가상 머신 NIC는 하나 이상의 ASG의 멤버가 됩니다.
그런 다음 ASG는 네트워크 보안 그룹의 일부인 규칙에서 통신 흐름을 제어하는 데 사용할 수 있으며 서비스 태그와 같은 NSG 기능을 계속 사용할 수 있습니다.
| Action | Name | Source | Destination | Port |
| ------ | ------------------ | ---------- | ----------- | ------------ |
| Allow | AllowInternettoWeb | Internet | WebServers | 443(HTTPS) |
| Allow | AllowWebToApp | WebServers | AppServers | 443(HTTPS) |
| Allow | AllowAppToDB | AppServers | DbServers | 1443 (MSSQL) |
| Deny | DenyAllinbound | Any | Any | Any |
### 로드 밸런싱
Microsoft Azure에는 두 가지 로드 밸런싱 솔루션이 있습니다. (퍼스트 파티, Azure 마켓플레이스에서 사용할 수 있는 타사도 있습니다.) 두 솔루션 모두 외부 또는 내부 엔드포인트에서 작동할 수 있습니다.
- Load Balancer (Layer 4)는 해시 기반 배포 및 포트 포워딩을 지원합니다.
- App Gateway (Layer 7)는 SSL offload, 쿠키 기반 세션 선호도, URL 기반 콘텐츠 라우팅과 같은 기능을 지원합니다.
또한 앱 게이트웨이를 사용하면 선택적으로 웹 애플리케이션 방화벽 구성 요소를 사용할 수 있습니다.
## Azure 관리 도구
대부분의 이론 시간을 Azure 포털을 살펴보는 데 할애했는데, 데브옵스 문화를 따르고 이러한 작업, 특히 프로비저닝과 관련된 많은 작업을 처리할 때 API 또는 커맨드라인 도구를 통해 수행한다고 제안하고 싶습니다. Azure 환경의 프로비저닝을 자동화할 때 이를 알아야 하므로 사용할 수 있는 다른 관리 도구 몇 가지를 언급하고 싶었습니다.
### Azure 포털
Microsoft Azure Portal은 커맨드라인 도구의 대안을 제공하는 웹 기반 콘솔입니다. Azure 포털에서 구독을 관리할 수 있습니다. 간단한 웹 앱부터 복잡한 클라우드 배포까지 모든 것을 빌드, 관리 및 모니터링할 수 있습니다. 포털 내에서 찾을 수 있는 또 다른 것은 이러한 이동 경로이며, 앞서 언급했듯이 JSON은 모든 Azure 리소스의 기반이며, 포털에서 시작하여 기능, 서비스 및 기능을 이해한 다음 나중에 자동화된 워크플로우에 통합하기 위해 그 아래에 있는 JSON을 이해할 수 있습니다.
![](/2022/Days/Images/Day33_Cloud2.png)
Azure Preview Portal도 있으며, 이 포털을 사용하여 새로운 서비스 및 향후 개선 사항을 보고 테스트할 수 있습니다.
![](/2022/Days/Images/Day33_Cloud3.png)
### PowerShell
Azure PowerShell을 살펴보기 전에 PowerShell에 대해 먼저 소개할 필요가 있습니다. PowerShell은 작업 자동화 및 구성 관리 프레임워크, 커맨드라인 셸 및 스크립팅 언어입니다. Linux 섹션에서 셸 스크립팅에 대해 다룬 것과 비슷하다고 감히 말할 수 있습니다. PowerShell은 Windows OS에서 처음 발견되었지만, 이제는 크로스 플랫폼입니다.
Azure PowerShell은 PowerShell 커맨드라인에서 직접 Azure 리소스를 관리하기 위한 cmdlets의 집합입니다.
아래에서 PowerShell 명령 `Connect-AzAccount`를 사용하여 구독에 연결할 수 있음을 확인할 수 있습니다.
![](/2022/Days/Images/Day33_Cloud4.png)
그런 다음 Azure VM과 관련된 특정 명령을 찾으려면 다음 명령을 실행하면 됩니다. 이 PowerShell 프로그래밍 언어에 대해 더 많이 배우고 이해하는 데 몇 시간을 투자할 수 있습니다.
![](/2022/Days/Images/Day33_Cloud5.png)
[여기](https://docs.microsoft.com/en-us/powershell/azure/get-started-azureps?view=azps-7.1.0)에서 PowerShell에서 서비스를 시작하고 프로비저닝하는 방법에 대한 Microsoft의 훌륭한 빠른 시작 가이드를 확인하세요.
### Visual Studio Code
많은 분들께서 보셨듯이 제가 자주 사용하는 IDE는 Visual Studio Code입니다.
Visual Studio Code는 Microsoft에서 Windows, Linux 및 macOS용으로 만든 무료 소스 코드 편집기입니다.
아래에서 Visual Studio Code에 내장된 많은 통합 및 도구를 사용하여 Microsoft Azure 및 그 안의 서비스와 상호 작용할 수 있음을 확인할 수 있습니다.
![](/2022/Days/Images/Day33_Cloud6.png)
### Cloud Shell
Azure Cloud Shell은 Azure 리소스를 관리하기 위한 대화형, 인증된 브라우저 액세스 가능 셸입니다. 작업 방식에 가장 적합한 셸 환경을 선택할 수 있는 유연성을 제공합니다.
![](/2022/Days/Images/Day33_Cloud7.png)
아래에서 볼 수 있듯이 포털 내에서 Cloud Shell을 처음 실행하면 Bash와 PowerShell 중에서 선택할 수 있습니다.
![](/2022/Days/Images/Day33_Cloud8.png)
Cloud Shell을 사용하려면 구독에 약간의 저장 공간을 제공해야 합니다.
Cloud Shell을 사용하도록 선택하면 머신이 스핀업되며, 이러한 머신은 일시적이지만 파일은 디스크 이미지와 마운트된 파일 공유를 통해 두 가지 방식으로 유지됩니다.
![](/2022/Days/Images/Day33_Cloud9.png)
- Cloud Shell은 세션별, 사용자별로 제공되는 임시 호스트에서 실행됩니다.
- 대화형 활동이 없으면 20분 후에 Cloud Shell이 시간 초과됨
- Cloud Shell을 사용하려면 Azure 파일 공유를 마운트해야 함
- Cloud Shell은 Bash와 PowerShell 모두에 동일한 Azure 파일 공유를 사용합니다.
- Cloud Shell은 사용자 계정당 하나의 머신이 할당됨
- Cloud Shell은 파일 공유에 보관된 5GB 이미지를 사용하여 $HOME을 유지합니다.
- 권한은 Bash에서 일반 Linux 사용자로 설정됨
위 내용은 [Cloud Shell 개요](https://docs.microsoft.com/en-us/azure/cloud-shell/overview)에서 복사한 것입니다.
### Azure CLI
마지막으로 Azure CLI에 대해 알아보겠습니다. Azure CLI는 윈도우, 리눅스, 맥OS에서 설치할 수 있습니다. 설치가 완료되면 `az`를 입력한 후 다른 명령어를 입력해 Azure 리소스를 생성, 업데이트, 삭제, 조회할 수 있습니다.
처음 Azure 학습에 들어갔을 때 Azure PowerShell과 Azure CLI가 있어서 약간 혼란스러웠습니다.
이에 대한 커뮤니티의 피드백이 있으면 좋겠습니다. 하지만 제가 알기로 Azure PowerShell은 Windows PowerShell 또는 PowerShell Core에 추가된 모듈(다른 OS에서도 사용 가능하지만 전부는 아님)인 반면, Azure CLI는 Azure에 연결하여 해당 명령을 실행하는 크로스 플랫폼 커맨드라인 프로그램이라고 알고 있습니다.
이 두 옵션 모두 구문은 다르지만, 제가 보기에는 매우 유사한 작업을 수행할 수 있습니다.
예를 들어 PowerShell에서 가상 머신을 만들려면 `New-AzVM` cmdlet을 사용하는 반면, Azure CLI는 `az VM create`를 사용합니다.
앞서 시스템에 Azure PowerShell 모듈이 설치되어 있고 Windows 컴퓨터에서 PowerShell을 통해 호출할 수 있는 Azure CLI도 설치되어 있는 것을 보았습니다.
![](/2022/Days/Images/Day33_Cloud10.png)
이미 언급했듯이 여기서 중요한 점은 올바른 도구를 선택하는 것입니다. Azure는 자동화를 기반으로 실행됩니다. 포털 내에서 수행하는 모든 작업은 리소스를 읽거나, 만들거나, 수정하거나, 삭제하기 위해 실행되는 코드로 변환됩니다.
Azure CLI
- Windows, macOS, Linux에 설치할 수 있는 크로스 플랫폼 커맨드라인 인터페이스
- Windows PowerShell, Cmd, Bash 및 기타 Unix 셸에서 실행됩니다.
Azure PowerShell
- 크로스 플랫폼 PowerShell 모듈, Windows, macOS, Linux에서 실행됨
- Windows PowerShell 또는 PowerShell 필요
사용 중인 환경에서 PowerShell을 사용할 수 없지만 .mdor bash를 사용할 수 있는 경우 Azure CLI를 선택하는 것이 좋습니다.
다음으로 지금까지 살펴본 모든 이론을 바탕으로 몇 가지 시나리오를 만들어 Azure에서 실습해 보겠습니다.
## 자료
- [Hybrid Cloud and MultiCloud](https://www.youtube.com/watch?v=qkj5W98Xdvw)
- [Microsoft Azure Fundamentals](https://www.youtube.com/watch?v=NKEFWyqJ5XA&list=WL&index=130&t=12s)
- [Google Cloud Digital Leader Certification Course](https://www.youtube.com/watch?v=UGRDM86MBIQ&list=WL&index=131&t=10s)
- [AWS Basics for Beginners - Full Course](https://www.youtube.com/watch?v=ulprqHHWlng&t=5352s)
[Day 34](day34.md)에서 봐요!

197
2022/ko/Days/day34.md Normal file
View File

@ -0,0 +1,197 @@
---
title: '#90DaysOfDevOps - Microsoft Azure Hands-On Scenarios - Day 34'
published: false
description: 90DaysOfDevOps - Microsoft Azure Hands-On Scenarios
tags: 'DevOps, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048763
---
## Microsoft Azure 실습 시나리오
지난 6일 동안 Microsoft Azure와 퍼블릭 클라우드 전반에 대해 집중적으로 살펴봤는데요, Azure의 빌딩 블록을 이해하기 위해서는 많은 이론이 필요했지만, 다른 주요 클라우드 제공업체에도 잘 적용될 수 있을 것입니다.
처음에 퍼블릭 클라우드에 대한 기초 지식을 얻고 최소한 한 공급자를 선택하는 것에 대해 언급했는데, 여러 클라우드를 얕게 다룰 경우 길을 잃기 쉽지만, 한 공급자를 선택한 후 기본 사항을 이해하면 다른 클라우드로 이동하여 학습을 가속화하는 것이 매우 쉽다고 생각됩니다.
이번 마지막 세션에서는 Microsoft에서 만든 참고 자료로 [AZ-104 Microsoft Azure Administrator](https://microsoftlearning.github.io/AZ-104-MicrosoftAzureAdministrator/) 시험 준비에 사용되는 이 페이지에서 실습 시나리오를 골라보겠습니다.
여기에는 컨테이너와 쿠버네티스와 같이 아직 자세히 다루지 않은 내용도 있으므로 아직은 여기에 뛰어들지 않겠습니다.
이전 포스팅에서 Module 1,2,3의 대부분을 만들었습니다.
### 가상 네트워킹
[Module 04](https://microsoftlearning.github.io/AZ-104-MicrosoftAzureAdministrator/Instructions/Labs/LAB_04-Implement_Virtual_Networking.html) 따라 하기:
위의 내용을 살펴보고 #90DaysOfDevOps의 이름을 몇 가지 변경했습니다. 또한 클라우드 셸을 사용하는 대신 Windows 머신에서 Azure CLI를 사용하여 전날 생성한 새 사용자로 로그인했습니다.
브라우저를 열고 계정에 인증할 수 있는 `az login`을 사용하여 이 작업을 수행할 수 있습니다.
그런 다음 아래 작업 중 일부를 빌드하는 데 사용할 PowerShell 스크립트와 Module에서 몇 가지 참조를 만들었습니다. 관련 파일은 이 폴더에서 찾을 수 있습니다.
(/2022/Days/Cloud/01VirtualNetworking)
스크립트의 파일 위치를 사용자 환경에 맞게 변경해야 합니다.
첫 번째 단계에서는 환경에 가상 네트워크나 가상 머신이 생성되어 있지 않고 리소스 그룹에 클라우드 셸 스토리지 위치만 구성되어 있습니다.
먼저 [PowerShell 스크립트](/2022/Days/Cloud/01VirtualNetworking/Module4_90DaysOfDevOps.ps1)를 실행합니다.
![](/2022/Days/Images/Day34_Cloud1.png)
- Task 1: 가상 네트워크 생성 및 구성
![](/2022/Days/Images/Day34_Cloud2.png)
- Task 2: 가상 네트워크에 가상 머신 배포
![](/2022/Days/Images/Day34_Cloud3.png)
- Task 3: Azure VM의 프라이빗 및 퍼블릭 IP 주소 구성
![](/2022/Days/Images/Day34_Cloud4.png)
- Task 4: 네트워크 보안 그룹 구성
![](/2022/Days/Images/Day34_Cloud5.png)
![](/2022/Days/Images/Day34_Cloud6.png)
- Task 5: 내부 이름 확인을 위한 Azure DNS 구성
![](/2022/Days/Images/Day34_Cloud7.png)
![](/2022/Days/Images/Day34_Cloud8.png)
### 네트워크 트래픽 관리
[Module 06](https://microsoftlearning.github.io/AZ-104-MicrosoftAzureAdministrator/Instructions/Labs/LAB_06-Implement_Network_Traffic_Management.html)에 이어서
다음 단계에서는 지난번 리소스 그룹으로 이동하여 리소스를 삭제했는데, 저처럼 사용자 계정을 해당 리소스 그룹에만 접근하도록 설정하지 않았다면 Module 이름을 '90Days\*'로 변경하여 모든 리소스와 리소스 그룹을 삭제할 수 있습니다. 이것이 다음 실습 각각에 대한 제 프로세스입니다.
이 실습에서는 아래 작업 중 일부를 구축하는 데 사용할 Module의 일부 참조와 PowerShell 스크립트도 만들었습니다. 관련 파일은 이 폴더에서 찾을 수 있습니다.
(/2022/Days/Cloud/02TrafficManagement)
- Task 1: 실습 환경 프로비저닝
먼저 [PowerShell 스크립트](/2022/Days/Cloud/02TrafficManagement/Mod06_90DaysOfDevOps.ps1)를 실행합니다.
![](/2022/Days/Images/Day34_Cloud9.png)
- Task 2: 허브 및 스포크 네트워크 Topology 구성
![](/2022/Days/Images/Day34_Cloud10.png)
- Task 3: 가상 네트워크 피어링의 전이성 테스트
이 작업의 경우 90DaysOfDevOps 그룹은 권한 때문에 네트워크 감시자에 액세스할 수 없었는데, 이는 네트워크 감시자가 리소스 그룹에 묶여 있지 않은 리소스 중 하나이기 때문인 것으로 예상됩니다(이 사용자에 대해 RBAC이 적용된 곳). 미국 동부 네트워크 감시자 기여자 역할을 90DaysOfDevOps 그룹에 추가했습니다.
![](/2022/Days/Images/Day34_Cloud11.png)
![](/2022/Days/Images/Day34_Cloud12.png)
![](/2022/Days/Images/Day34_Cloud13.png)
두 개의 스포크 가상 네트워크가 서로 피어링되지 않기 때문에 예상되는 현상입니다(가상 네트워크 피어링은 전이적이지 않음).
- Task 4: 허브 및 스포크 Topology에서 라우팅 구성하기
여기서 제 계정이 90DaysOfDevOps 그룹 내에서 제 사용자로 스크립트를 실행할 수 없는 또 다른 문제가 있었는데, 잘 모르겠으므로 다시 기본 관리자 계정으로 이동했습니다. 90DaysOfDevOps 그룹은 90DaysOfDevOps 리소스 그룹의 모든 소유자이므로 VM 내에서 명령을 실행할 수 없는 이유를 알고 싶습니다.
![](/2022/Days/Images/Day34_Cloud14.png)
![](/2022/Days/Images/Day34_Cloud15.png)
그런 다음 michael.cade@90DaysOfDevOps.com 계정으로 돌아가서 이 섹션을 계속할 수 있었습니다. 여기서 동일한 테스트를 다시 실행하고 있지만 이제 결과에 도달할 수 있습니다.
![](/2022/Days/Images/Day34_Cloud16.png)
- Task 5: Azure 로드밸런싱 장치 구현하기
![](/2022/Days/Images/Day34_Cloud17.png)
![](/2022/Days/Images/Day34_Cloud18.png)
- Task 6: Azure 애플리케이션 게이트웨이 구현
![](/2022/Days/Images/Day34_Cloud19.png)
![](/2022/Days/Images/Day34_Cloud20.png)
### Azure 스토리지
[Module 07](https://microsoftlearning.github.io/AZ-104-MicrosoftAzureAdministrator/Instructions/Labs/LAB_07-Manage_Azure_Storage.html)에 이어서 진행합니다:
이 실습에서는 아래 작업 중 일부를 빌드하는 데 사용할 PowerShell 스크립트와 Module의 일부 참조도 만들었습니다. 관련 파일은 이 폴더에서 찾을 수 있습니다.
(/2022/Days/Cloud/03Storage)
- Task 1: 실습 환경 프로비저닝
먼저 [PowerShell 스크립트](/2022/Days/Cloud/03Storage/Mod07_90DaysOfDeveOps.ps1)를 실행합니다.
![](/2022/Days/Images/Day34_Cloud21.png)
- Task 2: Azure Storage 계정 만들기 및 구성
![](/2022/Days/Images/Day34_Cloud22.png)
- Task 3: 블롭 스토리지 관리
![](/2022/Days/Images/Day34_Cloud23.png)
- Task 4: Azure 스토리지에 대한 인증 및 권한 부여 관리
![](/2022/Days/Images/Day34_Cloud24.png)
![](/2022/Days/Images/Day34_Cloud25.png)
이 기능이 허용되기를 기다리는 동안 조금 조바심이 났지만 결국 작동했습니다.
![](/2022/Days/Images/Day34_Cloud26.png)
- Task 5: Azure 파일 공유 만들기 및 구성하기
실행 명령에서 michael.cade@90DaysOfDevOps.com 에서는 작동하지 않아서 승격된 계정을 사용했습니다.
![](/2022/Days/Images/Day34_Cloud27.png)
![](/2022/Days/Images/Day34_Cloud28.png)
![](/2022/Days/Images/Day34_Cloud29.png)
- Task 6: Azure 스토리지에 대한 네트워크 액세스 관리
![](/2022/Days/Images/Day34_Cloud30.png)
### 서버리스(웹 앱 구현)
[Module 09a](https://microsoftlearning.github.io/AZ-104-MicrosoftAzureAdministrator/Instructions/Labs/LAB_09a-Implement_Web_Apps.html)를 따릅니다:
- Task 1: Azure 웹 앱 만들기
![](/2022/Days/Images/Day34_Cloud31.png)
- Task 2: 스테이징 배포 슬롯 만들기
![](/2022/Days/Images/Day34_Cloud34.png)
- Task 3: 웹 앱 배포 설정 구성
![](/2022/Days/Images/Day34_Cloud33.png)
- Task 4: 스테이징 배포 슬롯에 코드 배포
![](/2022/Days/Images/Day34_Cloud32.png)
- Task 5: 스테이징 슬롯 교체
![](/2022/Days/Images/Day34_Cloud35.png)
- Task 6: Azure 웹 앱의 자동 확장 구성 및 테스트
제가 사용하는 이 스크립트는 (/2022/Days/Cloud/04Serverless)에서 찾을 수 있습니다.
![](/2022/Days/Images/Day34_Cloud36.png)
이것으로 Microsoft Azure와 퍼블릭 클라우드 전반에 대한 섹션을 마무리합니다. 이 시나리오를 작업하는 것이 매우 즐거웠다고 말씀드리고 싶습니다.
## 자료
- [Hybrid Cloud and MultiCloud](https://www.youtube.com/watch?v=qkj5W98Xdvw)
- [Microsoft Azure Fundamentals](https://www.youtube.com/watch?v=NKEFWyqJ5XA&list=WL&index=130&t=12s)
- [Google Cloud Digital Leader Certification Course](https://www.youtube.com/watch?v=UGRDM86MBIQ&list=WL&index=131&t=10s)
- [AWS Basics for Beginners - Full Course](https://www.youtube.com/watch?v=ulprqHHWlng&t=5352s)
다음으로 버전 관리 시스템, 특히 git과 코드 저장소 개요에 대해 살펴볼 것이며, 제가 선호하는 옵션인 GitHub를 선택하겠습니다.
[Day 35](day35.md)에서 봐요!

140
2022/ko/Days/day35.md Normal file
View File

@ -0,0 +1,140 @@
---
title: '#90DaysOfDevOps - The Big Picture: Git - Version Control - Day 35'
published: false
description: 90DaysOfDevOps - The Big Picture Git - Version Control
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1049041
---
## 큰 그림: Git - 버전 관리
Git을 시작하기 전에 버전 관리가 무엇이며 왜 필요한지 이해해야 하나요? 이번 Git 시작 단계에서는 버전 관리가 무엇인지, 그리고 Git의 기본 사항에 대해 살펴보겠습니다.
### 버전 제어란 무엇인가요?
Git이 유일한 버전 관리 시스템은 아니므로 여기서는 버전 관리와 관련하여 어떤 옵션과 방법론을 사용할 수 있는지 살펴보고자 합니다.
버전 관리의 가장 분명하고 큰 장점은 프로젝트의 이력을 추적할 수 있다는 것입니다. 우리는 `git log`를 사용하여 이 리포지토리를 되돌아보고 많은 커밋과 많은 코멘트가 있으며 프로젝트에서 지금까지 무슨 일이 일어났는지 확인할 수 있습니다. 명령어에 대해서는 나중에 설명할 테니 걱정하지 마세요. 이제 이것이 소스 코드로 가득 찬 실제 소프트웨어 프로젝트이고 여러 사람이 서로 다른 시간에 소프트웨어에 커밋하고, 다른 작성자와 검토자가 모두 여기에 기록되어 무슨 일이 언제, 누가, 누가 검토했는지 알 수 있다고 생각해보세요.
![](/2022/Days/Images/Day35_Git1.png)
과거 버전 제어는 변경을 하기 전에 수동으로 버전 복사본을 만드는 것과 같은 방식이었을 것입니다. 또한 혹시 모른다는 생각으로 쓸모없는 오래된 코드를 주석 처리했을 수도 있습니다.
![](/2022/Days/Images/Day35_Git2.png)
저는 소스 코드뿐만 아니라 거의 모든 프로젝트에 버전 관리를 사용하기 시작했고, 이와 같은 프로젝트에 대해 이야기합니다(90DaysOfDevOps). 진행된 모든 것을 롤백하고 기록하는 기능을 받아들이는 것은 어떨까요?
그러나 **버전 제어는 백업이 아닙니다!**
버전 관리의 또 다른 이점은 프로젝트의 여러 버전을 관리할 수 있다는 점입니다. 예를 들어 모든 운영 체제에서 사용할 수 있는 무료 앱이 있고 모든 운영 체제에서 사용할 수 있는 유료 앱이 있다고 가정해 봅시다. 대부분의 코드는 두 애플리케이션 간에 공유됩니다. 각 앱에 코드를 복사하여 붙여 넣을 수도 있지만, 개발 인원이 한 명 이상으로 늘어나면 매우 지저분해지고 실수도 발생할 수 있습니다.
프리미엄 앱에는 추가 기능을 프리미엄 커밋이라고 부르고 무료 버전에는 일반 커밋만 포함할 수 있습니다.
버전 관리에서 이를 달성하는 방법은 branch를 사용하는 것입니다.
![](/2022/Days/Images/Day35_Git3.png)
branch를 사용하면 위에서 설명한 것처럼 동일한 앱에 대해 두 개의 코드 스트림을 사용할 수 있습니다. 하지만 소스 코드가 없는 버전에 포함된 새로운 기능이 프리미엄 버전에 포함되기를 원하며, 이를 위해 Merge라는 기능을 사용합니다.
![](/2022/Days/Images/Day35_Git4.png)
무료 버전에서 작업하는 팀과 프리미엄 유료 버전에서 작업하는 팀이 있을 수 있고, 둘 다 전체 코드의 일부에 영향을 주는 코드를 변경하면 어떻게 될지 모르기 때문에 merge는 복잡할 수 있습니다. 변수가 업데이트되어 무언가를 망가뜨릴 수도 있습니다. 그러면 기능 중 하나가 중단되는 충돌이 발생합니다. 버전 관리로는 이러한 충돌을 해결할 수 없습니다. 하지만 버전 제어를 사용하면 이를 쉽게 관리할 수 있습니다.
지금까지 버전 관리를 선택하지 않았다면 일반적으로 가장 큰 이유는 공동 작업 기능입니다. 개발자 간에 코드를 공유할 수 있는 기능, 그리고 앞서 말씀드린 대로 코드라고 하면 동료와 함께 작업하는 공동 프레젠테이션이나 프로젝트 전반에 걸쳐 커뮤니티가 수정 및 업데이트를 제공하는 90DaysOfDevOps 챌린지 등 다른 이유로 소스 제어를 사용하는 사례가 점점 더 많아지고 있습니다.
버전 관리가 없다면 소프트웨어 개발자 팀은 어떻게 이런 일을 처리할 수 있을까요? 저는 프로젝트를 진행하면서 상황을 추적하는 것만으로도 충분히 힘들다는 것을 느낍니다. 저는 그들이 코드를 각 기능 모듈로 분리할 것이라고 예상합니다. 아마도 퍼즐 조각을 한데 모은 다음 릴리스하기 전에 문제와 이슈를 파악했을 것입니다.
버전 관리를 통해 우리는 단일 소스를 확보할 수 있습니다. 여전히 서로 다른 모듈에서 작업할 수 있지만 협업이 더 잘 이루어질 수 있습니다.
![](/2022/Days/Images/Day35_Git5.png)
여기서 한 가지 더 언급할 것은 버전 관리의 이점을 누릴 수 있는 것은 개발자뿐만 아니라 모든 팀원이 가시성을 확보할 수 있을 뿐만 아니라 프로젝트 관리 도구도 여기에 연결하여 작업을 추적할 수 있다는 것입니다. 다른 모듈에서 다룰 Jenkins와 같은 빌드 머신도 있을 수 있습니다. 시스템을 빌드하고 패키징하여 배포 테스트와 메트릭을 자동화하는 도구입니다.
### Git이란 무엇인가요?
Git은 소스 코드 또는 모든 파일의 변경 사항을 추적하는 도구이며, 오픈소스 분산 버전 관리 시스템이라고도 할 수 있습니다.
시스템에서 Git을 사용할 수 있는 방법은 여러 가지가 있는데, 가장 일반적으로는 커맨드라인에서 사용하는 것이 가장 일반적이지만, GUI와 Visual Studio Code와 같은 도구에서도 Git을 인식하는 작업을 활용할 수 있습니다.
이제 로컬 머신에 Git을 설치하기 전에 개략적인 개요를 살펴보겠습니다.
앞서 만든 폴더를 살펴보겠습니다.
![](/2022/Days/Images/Day35_Git2.png)
이 폴더를 버전 제어에 사용하려면 먼저 `git init` 명령을 사용하여 이 디렉토리를 초기화해야 합니다. 지금은 이 명령이 디렉토리를 컴퓨터 어딘가에 있는 데이터베이스의 리포지토리로 저장한다고 생각하면 됩니다.
![](/2022/Days/Images/Day35_Git6.png)
이제 몇 가지 파일과 폴더를 만들 수 있으며 소스 코드가 시작될 수도 있고 이미 여기에 무언가가 있을 수도 있습니다. 우리는 `git add .` 명령을 사용하여 디렉토리의 모든 파일과 폴더를 스냅샷에 넣을 수 있지만 아직 해당 데이터베이스에 아무것도 커밋하지 않았습니다. 우리는 단지 `.`가 있는 모든 파일을 추가할 준비가 되었다고 말하는 것입니다.
![](/2022/Days/Images/Day35_Git7.png)
이제 파일을 커밋하고 싶으면 `git commit -m "My First Commit"` 명령으로 이 작업을 수행합니다. 커밋에 대한 설명을 할 수 있으며 각 커밋에 대해 무슨 일이 일어났는지 알 수 있도록 도와줍니다.
![](/2022/Days/Images/Day35_Git8.png)
이제 프로젝트의 히스토리에서 어떤 일이 일어났는지 확인할 수 있습니다. `git log` 명령어를 사용합니다.
![](/2022/Days/Images/Day35_Git9.png)
`samplecode.ps1`라는 파일을 추가로 생성하면 상태가 달라집니다. 또한 `git status`를 사용하여 리포지토리의 상태를 확인할 수 있는데, 커밋할 항목이 없음을 보여주며 samplecode.ps1이라는 새 파일을 추가할 수 있습니다. 그런 다음 동일한 `git status`를 실행하면 커밋할 파일이 있는 것을 볼 수 있습니다.
![](/2022/Days/Images/Day35_Git10.png)
`git add samplecode.ps1`명령을 사용하여 새 파일을 추가한 다음`git status`를 다시 실행하면 파일이 커밋될 준비가 된 것을 확인할 수 있습니다.
![](/2022/Days/Images/Day35_Git11.png)
그런 다음 `git commit -m "My Second Commit"` 명령을 실행합니다.
![](/2022/Days/Images/Day35_Git12.png)
`git status`를 한 번 더 입력하면, 모든 것이 다시 깨끗해졌음을 확인할 수 있습니다.
![](/2022/Days/Images/Day35_Git13.png)
이제 최신 변경 사항과 첫 번째 커밋을 보여주는 `git log` 명령을 사용할 수 있습니다.
![](/2022/Days/Images/Day35_Git14.png)
커밋 사이의 변경 사항, 즉 어떤 파일이 추가되거나 수정되었는지 확인하려면 `git diff b8f8 709a`를 사용하면 됩니다.
![](/2022/Days/Images/Day35_Git15.png)
그러면 새 파일을 추가한 경우 변경된 내용이 표시됩니다.
![](/2022/Days/Images/Day35_Git16.png)
나중에 더 자세히 설명하겠지만 커밋을 이동하면서 시간 여행을 할 수 있습니다! 커밋 번호를 사용하면 `git checkout 709a` 명령을 사용하여 새 파일을 잃지 않고 시간을 거슬러 올라갈 수 있습니다.
![](/2022/Days/Images/Day35_Git17.png)
마찬가지로 커밋 번호와 같은 방법으로 앞으로 이동하고 싶을 수도 있고, 여기서 `git switch -` 명령을 사용하여 작업을 취소할 수도 있습니다.
![](/2022/Days/Images/Day35_Git18.png)
TLDR;
- 프로젝트 히스토리 추적하기
- 프로젝트의 여러 버전 관리
- 개발자 및 더 넓은 범위의 팀과 도구 간에 코드 공유
- 팀워크 조정
- 아, 그리고 시간 여행!
너무 많은 내용을 설명한 것 같지만, 어떤 명령어를 사용하는지 몰라도 버전 관리의 큰 그림을 이해할 수 있기를 바랍니다.
다음에는 로컬 머신에 Git을 설치 및 설정하고 Git을 통해 얻을 수 있는 다른 사용 사례와 명령어에 대해 좀 더 자세히 살펴보겠습니다.
## 자료
- [What is Version Control?](https://www.youtube.com/watch?v=Yc8sCSeMhi4)
- [Types of Version Control System](https://www.youtube.com/watch?v=kr62e_n6QuQ)
- [Git Tutorial for Beginners](https://www.youtube.com/watch?v=8JJ101D3knE&t=52s)
- [Git for Professionals Tutorial](https://www.youtube.com/watch?v=Uszj_k0DGsg)
- [Git and GitHub for Beginners - Crash Course](https://www.youtube.com/watch?v=RGOj5yH7evk&t=8s)
- [Complete Git and GitHub Tutorial](https://www.youtube.com/watch?v=apGV9Kg7ics)
[Day 36](day36.md)에서 봐요!

154
2022/ko/Days/day36.md Normal file
View File

@ -0,0 +1,154 @@
---
title: '#90DaysOfDevOps - Installing & Configuring Git - Day 36'
published: false
description: 90DaysOfDevOps - Installing & Configuring Git
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048738
---
## Git 설치 및 구성
Git은 버전 관리를 위한 오픈 소스 크로스 플랫폼 도구입니다. 저처럼 우분투 또는 대부분의 Linux 환경을 사용하는 경우 이미 Git이 설치되어 있을 수 있지만 설치 및 구성 과정을 살펴보겠습니다.
시스템에 이미 git이 설치되어 있더라도 최신 버전인지 확인하는 것도 좋은 방법입니다.
### Git 설치하기
이미 언급했듯이 Git은 크로스 플랫폼이므로 Windows와 Linux를 통해 실행할 것이지만 [여기](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)에서 macOS도 찾을 수 있습니다.
[Windows](https://git-scm.com/download/win)의 경우 공식 사이트에서 설치할 수 있습니다.
Windows 컴퓨터에서 `winget`을 사용할 수도 있는데, 이것을 Windows 애플리케이션 패키지 관리자라고 생각하면 됩니다.
설치하기 전에 Windows 머신에 어떤 버전이 있는지 확인해 보겠습니다. PowerShell 창을 열고 `git --version`을 실행합니다.
![](/2022/Days/Images/Day36_Git1.png)
WSL 우분투 버전의 Git도 확인할 수 있습니다.
![](/2022/Days/Images/Day36_Git2.png)
이 글을 쓰는 시점에 최신 Windows 릴리스는 `2.35.1`이므로 업데이트해야 할 사항이 몇 가지 있는데 이를 살펴보겠습니다. 리눅스도 마찬가지일 것으로 예상합니다.
저는 최신 설치 프로그램을 다운로드하고 마법사를 실행했으며 여기에 이를 문서화할 것입니다. 주의해야 할 중요한 점은 최신 버전을 설치하기 전에 git이 이전 버전을 제거한다는 것입니다.
즉, 아래에 표시된 프로세스도 대부분 git을 사용하지 않고 설치하는 것과 동일한 프로세스입니다.
매우 간단한 설치입니다. 다운로드가 완료되면 두 번 클릭하고 시작하세요. GNU 라이선스 계약을 읽어보세요. 하지만 이 소프트웨어는 무료 오픈소스 소프트웨어라는 점을 기억하세요.
![](/2022/Days/Images/Day36_Git3.png)
이제 추가로 설치할 컴포넌트를 선택해 git과 연결할 수 있습니다. 저는 Windows에서 bash 스크립트를 실행할 수 있는 Git Bash를 항상 설치합니다.
![](/2022/Days/Images/Day36_Git4.png)
그런 다음 사용할 SSH 실행 파일을 선택할 수 있습니다. 리눅스 섹션에서 보셨을 번들 OpenSSH를 그대로 두겠습니다.
![](/2022/Days/Images/Day36_Git5.png)
그다음에는 실험적인 기능을 활성화할 수 있는데, 저는 필요하지 않으므로 활성화하지 않고 나중에 설치를 통해 돌아와서 언제든지 활성화할 수 있습니다.
![](/2022/Days/Images/Day36_Git6.png)
설치가 완료되었으므로 이제 Git Bash 및 최신 릴리스 노트를 열도록 선택할 수 있습니다.
![](/2022/Days/Images/Day36_Git7.png)
마지막 확인은 PowerShell 창에서 현재 어떤 버전의 git이 있는지 살펴보는 것입니다.
![](/2022/Days/Images/Day36_Git8.png)
매우 간단하며 이제 최신 버전을 사용하고 있습니다. 리눅스 머신에서는 업데이트가 조금 늦은 것 같아서 업데이트 과정을 안내해 드리겠습니다.
`sudo apt-get install git` 명령을 실행하기만 하면 됩니다.
![](/2022/Days/Images/Day36_Git9.png)
다음을 실행하여 소프트웨어 설치를 위한 git 저장소를 추가할 수도 있습니다.
```
sudo add-apt-repository ppa:git-core/ppa -y
sudo apt-get update
sudo apt-get install git -y
git --version
```
### Git 구성하기
처음 git을 사용할 때는 몇 가지 설정을 정의해야 합니다,
- Name
- Email
- 기본 에디터
- Line Ending
이 설정은 세 가지 수준에서 수행할 수 있습니다.
- System = 모든 사용자
- Global = 현재 사용자의 모든 리포지토리
- Local = 현재 리포지토리
예제
`git config --global user.name "Michael Cade"`
`git config --global user.email Michael.Cade@90DaysOfDevOPs.com"`
운영 체제에 따라 기본 텍스트 편집기가 결정됩니다. 다음 명령을 설정하지 않은 제 우분투 머신에서는 Nano를 사용하고 있습니다. 아래 명령은 이를 비주얼 스튜디오 코드로 변경합니다.
`git config --global core.editor "code --wait"`
이제 모든 git 구성을 보려면 다음 명령을 사용하면 됩니다.
`git config --global -e`
![](/2022/Days/Images/Day36_Git10.png)
어떤 머신에서든 이 파일의 이름은 `.gitconfig`입니다. 제 Windows 머신에서는 사용자 계정 디렉토리에서 이 파일을 찾을 수 있습니다.
![](/2022/Days/Images/Day36_Git11.png)
### Git 이론
어제 포스트에서 다른 버전 관리 유형이 있으며 이를 두 가지 유형으로 나눌 수 있다고 언급했습니다. 하나는 "클라이언트-서버"이고 다른 하나는 "분산"입니다.
### 클라이언트-서버 버전 제어
git이 등장하기 전에는 클라이언트-서버가 버전 관리를 위한 사실상 유일한 방법이었다. 그 예로 2000년에 설립된 오픈소스 버전 관리 시스템인 [Apache Subversion](https://subversion.apache.org/)을 들 수 있습니다.
이 클라이언트-서버 버전 제어 모델에서는 개발자가 서버에서 소스 코드와 실제 파일을 다운로드하는 것이 첫 번째 단계입니다. 이렇게 한다고 해서 충돌이 예방되는 것은 아니지만 충돌의 복잡성과 해결 방법이 예방됩니다.
![](/2022/Days/Images/Day36_Git12.png)
예를 들어 두 명의 개발자가 같은 파일을 작업하고 있는데 한 개발자가 새로운 변경 사항을 먼저 커밋하거나 서버에 파일을 다시 업로드한다고 가정해 보겠습니다. 두 번째 개발자가 업데이트를 하려고 할 때 충돌이 발생합니다.
![](/2022/Days/Images/Day36_Git13.png)
이때, 첫 번째 개발자의 코드 변경 사항을 가져와서 자신의 작업과 충돌하는 부분을 모두 처리한 다음, 커밋해야 합니다.
![](/2022/Days/Images/Day36_Git15.png)
### 분산 버전 제어
Git이 유일한 분산 버전 제어 시스템은 아닙니다. 하지만 사실상 거의 유일한 시스템입니다.
Git의 주요 이점은 다음과 같습니다:
- 빠름
- 스마트
- 유연함
- 안전 및 보안
클라이언트-서버 버전 제어 모델과 달리 각 개발자는 커밋 히스토리, 모든 branch 등을 의미하는 소스 리포지토리를 다운로드합니다.
![](/2022/Days/Images/Day36_Git16.png)
## 자료
- [What is Version Control?](https://www.youtube.com/watch?v=Yc8sCSeMhi4)
- [Types of Version Control System](https://www.youtube.com/watch?v=kr62e_n6QuQ)
- [Git Tutorial for Beginners](https://www.youtube.com/watch?v=8JJ101D3knE&t=52s)
- [Git for Professionals Tutorial](https://www.youtube.com/watch?v=Uszj_k0DGsg)
- [Git and GitHub for Beginners - Crash Course](https://www.youtube.com/watch?v=RGOj5yH7evk&t=8s)
- [Complete Git and GitHub Tutorial](https://www.youtube.com/watch?v=apGV9Kg7ics)
[Day 37](day37.md)에서 봐요!

170
2022/ko/Days/day37.md Normal file
View File

@ -0,0 +1,170 @@
---
title: '#90DaysOfDevOps - Gitting to know Git - Day 37'
published: false
description: 90DaysOfDevOps - Gitting to know Git
tags: 'DevOps, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048707
---
## Gitting to know Git(Git에 대해 알아보기)
제목과 글 전체에 끔찍한 말장난이 들어가서 죄송합니다. Git을 아재 개그로 바꾼 사람이 제가 처음은 아닐 겁니다!
지난 두 번의 포스팅에서 버전 관리 시스템과 버전 관리 시스템으로서의 Git의 기본적인 워크플로우에 대해 배웠고, [Day 35](day35.md)에서는 시스템에 Git을 설치하고 업데이트와 구성을 했습니다. 또한 클라이언트-서버 버전 관리 시스템과 분산 버전 관리 시스템인 Git [Day 36](day36.md) 사이의 이론에 대해 조금 더 자세히 알아보았습니다.
이제 Git에서 흔히 볼 수 있는 몇 가지 명령어와 사용 사례를 살펴보겠습니다.
### git은 어디에서 도움을 받을 수 있나요?
git으로 작업을 완료하는 데 필요한 명령이 기억나지 않거나 모를 때가 있을 것입니다. 도움이 필요할 것입니다.
Google이나 검색 엔진이 도움을 찾을 때 가장 먼저 찾을 수 있는 곳일 것입니다.
두 번째는 공식 git 사이트와 문서입니다. [git-scm.com/docs](http://git-scm.com/docs) 여기에서 사용 가능한 모든 명령어에 대한 확실한 정보뿐만 아니라 다양한 리소스를 찾을 수 있습니다.
![](/2022/Days/Images/Day37_Git1.png)
터미널에 연결할 수 없는 경우에도 동일한 문서에 액세스할 수 있어 매우 유용합니다. 예를 들어 `git add` 명령어를 선택했다면 `git add --help`를 실행하면 아래에 설명서가 표시됩니다.
![](/2022/Days/Images/Day37_Git2.png)
셸에서 `git add -h`를 사용하면 사용 가능한 옵션에 대한 요약을 볼 수 있습니다.
![](/2022/Days/Images/Day37_Git3.png)
### Git을 둘러싼 오해
"Git에는 액세스 제어 기능이 없다." - 리더에게 소스 코드를 유지 관리할 수 있는 권한을 부여할 수 있습니다.
"Git은 너무 무겁다." - Git은 대규모 프로젝트의 경우 기록을 줄여주는 얕은(shallow) 저장소를 제공할 수 있습니다.
### 실제 단점
바이너리 파일에는 적합하지 않습니다. 소스 코드에는 적합하지만 실행 파일이나 동영상 등에는 적합하지 않습니다.
도구의 명령어와 기능에 대해 설명하는 데 시간을 할애해야 한다는 점이 사용자 친화적이지 않다는 것을 보여주는 대표적인 예입니다.
하지만 전반적으로 Git은 배우기는 어렵지만 사용하기는 쉽습니다.
### git 생태계
여기서는 git과 관련된 생태계를 간략하게 다루되 일부 영역에 대해 깊이 있게 다루지는 않겠지만 개략적인 수준에서 알아두는 것이 중요하다고 생각합니다.
거의 모든 최신 개발 도구는 Git을 지원합니다.
- 개발자 도구 - 이미 비주얼 스튜디오 코드에 대해 언급했지만, 서브블룸 텍스트 및 기타 텍스트 편집기 및 IDE에 대한 git 플러그인 및 통합을 찾을 수 있습니다.
- 팀 도구 - CI/CD 관점에서의 Jenkins, 메시징 프레임워크의 Slack, 프로젝트 관리 및 이슈 추적을 위한 Jira와 같은 도구에 대해서도 언급했습니다.
- 클라우드 제공업체 - 모든 대형 클라우드 제공업체는 git, Microsoft Azure, Amazon AWS 및 Google Cloud Platform을 지원합니다.
- Git 기반 서비스 - 나중에 더 자세히 다룰 GitHub, GitLab 및 BitBucket이 있습니다. 이러한 서비스는 코드를 위한 소셜 네트워크입니다!
### Git 치트시트
대부분의 명령어를 다루지는 않았지만, 온라인에서 제공되는 몇 가지 치트 시트를 살펴본 후 몇 가지 git 명령어와 그 용도를 문서화하고 싶었습니다. 이 명령어들을 모두 기억할 필요는 없으며, 더 많은 실습과 사용을 통해 최소한 git 기본 명령어 정도는 익힐 수 있을 것입니다.
[Atlassian](https://www.atlassian.com/git/tutorials/atlassian-git-cheatsheet)에서 가져온 것이지만, 적어두고 설명을 읽어보면 명령이 무엇인지 알 수 있을 뿐만 아니라 일상적인 작업에서 실습을 해볼 수 있는 좋은 방법입니다.
### Git 기본 사항
| Command | Example | Description |
| ------------- | --------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| git init | `git init <directory>` | 지정한 디렉토리에 빈 git 리포지토리를 만듭니다. |
| git clone | `git clone <repo>` | \<repo>에 있는 리포지토리를 로컬 머신에 복제합니다. |
| git config | `git config user.name` | 현재 리포지토리 `system`, `global`, `local` 플래그의 모든 commit에 사용할 작성자 이름을 정의하여 구성 옵션을 설정합니다. |
| git add | `git add <directory>` | 다음 commit을 위해 \<directory>의 모든 변경 사항을 스테이징합니다. 모든 항목에 대해 \<files>와 \<.>을 추가할 수도 있습니다. |
| git commit -m | `git commit -m "<message>"` | 스테이징된 스냅샷을 commit하고, \<message>를 사용하여 commit되는 내용을 자세히 설명합니다. |
| git status | `git status` | 스테이징된 파일, 스테이징되지 않은 파일 및 추적되지 않은 파일을 나열합니다. |
| git log | `git log` | 기본 형식을 사용하여 모든 commit 기록을 표시합니다. 이 명령에는 추가 옵션이 있습니다. |
| git diff | `git diff` | 인덱스와 작업 디렉토리 사이의 스테이징되지 않은 변경 내용을 표시합니다. |
### Git 변경사항 되돌리기
| Command | Example | Description |
| ---------- | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| git revert | `git revert <commit>` | \<commit>의 모든 변경 사항을 취소하는 새 commit을 만든 다음 현재 branch에 적용합니다. |
| git reset | `git reset <file>` | 스테이징 영역에서 \<file>을 제거하지만 작업 디렉토리는 변경하지 않고 그대로 둡니다. 이렇게 하면 변경 내용을 덮어쓰지 않고 파일을 스테이징 해제할 수 있습니다. |
| git clean | `git clean -n` | 작업 디렉토리에서 어떤 파일을 제거할지 표시합니다. clean을 실행하려면 `-n` 대신 `-f`를 사용해야 합니다. |
### Git 수정 기록
| Command | Example | Description |
| ---------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| git commit | `git commit --amend` | 마지막 commit을 단계적 변경 사항과 마지막 commit을 결합한 것으로 바꿉니다. 아무것도 준비하지 않은 상태에서 사용하면 마지막 commit의 메시지를 편집할 수 있습니다. |
| git rebase | `git rebase <base>` | 현재 branch를 \<base>로 rebase합니다. \<base>는 commit ID, branch 이름, 태그 또는 HEAD에 대한 레퍼런스가 될 수 있습니다. |
| git reflog | `git reflog` | 로컬 리포지토리의 HEAD에 대한 변경 로그를 표시합니다. 날짜 정보를 표시하려면 --relative-date 플래그를 추가해야 하고, 모든 레퍼런스를 표시하려면 --all을 추가해야 합니다. |
### Git Branchs
| Command | Example | Description |
| ------------ | -------------------------- | ---------------------------------------------------------------------------------------------------------------- |
| git branch | `git branch` | 리포지토리에 있는 모든 branch를 나열합니다. \<branch> 인수를 추가하여 \<branch>라는 이름의 새 branch를 만듭니다. |
| git checkout | `git checkout -b <branch>` | \<branch>라는 이름의 새 branch를 생성하고 checkout합니다. 기존 branch를 checkout하려면 -b 플래그를 지웁니다. |
| git merge | `git merge <branch>` | \<branch>를 현재 branch에 merge합니다. |
### Git 원격 리포지토리
| Command | Example | Description |
| -------------- | ----------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
| git remote add | `git remote add <name> <url>` | 원격 리포지토리에 대한 새 연결을 생성합니다. 리모트를 추가한 후 \<name>을 다른 명령에서 \<url>에 대한 바로 가기로 사용할 수 있습니다. |
| git fetch | `git fetch <remote> <branch>` | 리포지토리에서 특정 \<branch>를 가져옵니다. 모든 원격 레퍼런스를 가져오려면 \<branch>를 생략하세요. |
| git pull | `git pull <remote>` | 지정된 리모트의 현재 branch 복사본을 가져와서 로컬 복사본에 즉시 merge합니다. |
| git push | `git push <remote> <branch>` | branch를 필요한 commit 및 오브젝트와 함께 \<remote>로 push합니다. 원격 리포지토리에 이름이 지정된 branch가 없는 경우 branch를 생성합니다. |
### Git Diff
| Command | Example | Description |
| ----------------- | ------------------- | ----------------------------------------------------- |
| git diff HEAD | `git diff HEAD` | 작업 디렉토리와 마지막 commit의 diff를 표시합니다. |
| git diff --cached | `git diff --cached` | 단계적 변경 사항과 마지막 commit의 diff를 표시합니다. |
### Git Config
| Command | Example | Description |
| ------------------------------------------------------ | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| git config --global user.name \<name> | `git config --global user.name <name>` | 현재 사용자가 모든 commit에 사용할 작성자 이름을 정의합니다. |
| git config --global user.email \<email> | `git config --global user.email <email>` | 현재 사용자가 모든 commit에 사용할 작성자 이메일을 정의합니다. |
| git config --global alias \<alias-name> \<git-command> | `git config --global 별칭 <alias-name> <git-command>` | git 명령에 대한 단축어를 만듭니다. |
| git config --system core.editor \<editor> | `git config --system core.editor <editor>` | 컴퓨터의 모든 사용자에 대한 명령에서 사용할 텍스트 편집기를 설정합니다. \<editor> 인수는 원하는 편집기를 실행하는 명령이어야 합니다. |
| git config --global --edit | `git config --global --edit ` | 수동 편집을 위해 텍스트 편집기에서 전역 구성 파일을 엽니다. |
### Git Rebase
| Command | Example | Description |
| --------------------- | ---------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| git rebase -i \<base> | `git rebase -i <base>` | 현재 branch를 \<base>로 rebase합니다. 편집기를 사용하여 각 commit을 새 저장소로 옮기는 방법에 대한 명령을 입력해야 합니다. |
### Git Pull
| Command | Example | Description |
| --------------------------- | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| git pull --rebase \<remote> | `git pull --rebase <remote>` | 현재 branch의 리모트 복사본을 가져와서 로컬 복사본으로 rebase합니다. branch를 통합하기 위해 merge 대신 git rebase를 사용합니다. |
### Git Reset
| Command | Example | Description |
| -------------------------- | --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| git reset | `git reset` | 스테이징 영역을 가장 최근 commit과 일치하도록 reset하되 작업 디렉토리는 변경하지 않습니다. |
| git reset --hard | `git reset --hard` | 스테이징 영역과 작업 디렉토리를 가장 최근 commit과 일치하도록 reset하고 작업 디렉토리의 모든 변경 내용을 덮어씁니다. |
| git reset \<commit> | `git reset <commit>` | 현재 branch 끝을 \<commit> 뒤로 이동하고 스테이징 영역을 일치하도록 reset하되 작업 디렉토리는 그대로 둡니다 |
| git reset --hard \<commit> | `git reset --hard <commit>` | 이전과 동일하지만 스테이징 영역과 작업 디렉토리를 모두 일치하도록 reset합니다. commit되지 않은 변경 사항과 \<commit> 이후의 모든 commit을 삭제합니다. |
### Git Push
| Command | Example | Description |
| -------------------------- | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
| git push \<remote> --force | `git push <remote> --force` | non-fast-forward merge가 아닌 경우에도 git push를 강제로 수행합니다. 자신이 무엇을 하고 있는지 확실하지 않으면 --force 플래그를 사용하지 말아야 합니다. |
| git push \<remote> --all | `git push <remote> --all` | 모든 로컬 branch를 지정한 리모트로 push 합니다. |
| git push \<remote> --tags | `git push <remote> --tags` | branch를 push하거나 --all 플래그를 사용하면 태그가 자동으로 push되지 않습니다. tags 플래그는 모든 로컬 태그를 원격 리포지토리에 보냅니다. |
## 자료
- [What is Version Control?](https://www.youtube.com/watch?v=Yc8sCSeMhi4)
- [Types of Version Control System](https://www.youtube.com/watch?v=kr62e_n6QuQ)
- [Git Tutorial for Beginners](https://www.youtube.com/watch?v=8JJ101D3knE&t=52s)
- [Git for Professionals Tutorial](https://www.youtube.com/watch?v=Uszj_k0DGsg)
- [Git and GitHub for Beginners - Crash Course](https://www.youtube.com/watch?v=RGOj5yH7evk&t=8s)
- [Complete Git and GitHub Tutorial](https://www.youtube.com/watch?v=apGV9Kg7ics)
- [Git cheatsheet](https://www.atlassian.com/git/tutorials/atlassian-git-cheatsheet)
[Day 38](day38.md)에서 봐요!

127
2022/ko/Days/day38.md Normal file
View File

@ -0,0 +1,127 @@
---
title: '#90DaysOfDevOps - Staging & Changing - Day 38'
published: false
description: 90DaysOfDevOps - Staging & Changing
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1049042
---
## 스테이징 및 변경
이미 몇 가지 기본 사항을 다뤘지만, 이렇게 연습을 해보면 어떻게 그리고 왜 이런 방식으로 작업하는지 더 잘 이해하고 배울 수 있습니다. GitHub와 같은 git 기반 서비스에 들어가기 전에 로컬 워크스테이션에서 활용할 수 있는 git의 강력한 기능을 살펴봅시다.
git 세션을 시작할 때 만든 프로젝트 폴더를 가지고 git으로 할 수 있는 몇 가지 간단한 예제를 보여드리겠습니다. 로컬 머신에 폴더를 생성하고 `git init` 명령으로 초기화했습니다.
![](/2022/Days/Images/Day38_Git1.png)
이제 폴더를 초기화했으므로 디렉토리에 숨겨진 폴더가 있는 것을 볼 수 있습니다.
![](/2022/Days/Images/Day38_Git2.png)
이 폴더에는 branch 및 커밋에 관한 정보뿐만 아니라 git 저장소의 세부 정보가 저장됩니다.
### 스테이징 파일
그런 다음 빈 폴더에서 작업을 시작하고 작업 첫날에 소스 코드를 추가할 수 있습니다. README.md 파일을 생성하면 디렉토리에서 해당 파일을 볼 수 있고, 다음으로 `git status`를 확인하면 새 README.md 파일이 보이지만, 아직 그 파일을 커밋하지는 않은 상태입니다.
![](/2022/Days/Images/Day38_Git3.png)
이제 `git add README.md` 명령으로 README.md 파일을 스테이징하면 이전에 없던 변경 사항과 초록색으로 표시되는 새 파일을 커밋할 수 있는 상태가 됩니다.
![](/2022/Days/Images/Day38_Git4.png)
다음으로 프로젝트의 첫 번째 커밋 또는 첫 번째 스냅샷인 이 파일을 커밋하고 싶습니다. 각 커밋에 대해 변경된 내용을 쉽게 확인할 수 있도록 `git commit -m "의미 있는 메시지"` 명령을 사용하여 이 작업을 수행할 수 있습니다. 또한 노란색 십자가가 이제 녹색 체크 표시로 바뀐 것을 확인할 수 있습니다. 이것은 제가 터미널에서 사용하는 테마로, 리눅스 섹션에서 다룬 내용입니다.
![](/2022/Days/Images/Day38_Git5.png)
### 변경 사항 커밋
파일을 더 추가하거나 디렉토리에 있는 파일을 변경하고 싶을 때가 많습니다. 위에서 이미 첫 번째 커밋을 했습니다. 하지만 이제 더 많은 세부 사항으로 더 많은 파일을 추가하겠습니다.
이전 프로세스를 반복하여 파일을 만들거나 수정한 다음 `git add .`를 실행하여 모든 파일을 스테이징 영역에 추가한 다음 `git commit -m "의미 있는 메시지"`를 실행하면 정상적으로 작동할 수 있습니다. 그러나 커밋에 변경된 내용에 대한 의미 있는 메시지를 제공하려면 `git commit -m "음, 일부 코드가 작동하지 않아서 변경했으며, 이를 수정할 때 모든 사람이 사용자 경험에 대해 알 수 있도록 README.md에 새로운 내용을 추가했습니다."`와 같이 설명적인 내용을 작성하는 것도 가능하지만 여기서는 텍스트 편집기를 사용하여 추가하는 것이 더 바람직할 수 있습니다.
`git add`를 실행한 후 `git commit`을 실행하면 기본 텍스트 편집기(여기서는 nano)가 열립니다. 다음은 파일에 몇 가지 변경 사항을 추가하기 위해 수행한 단계이며, `git status`를 실행하여 스테이징된 항목과 스테이징되지 않은 항목을 표시합니다. 그런 다음 `git add`를 사용하여 파일을 스테이징 영역에 추가한 다음 `git commit`을 실행하여 nano를 열었습니다.
![](/2022/Days/Images/Day38_Git6.png)
Nano가 열리면 설명을 추가한 다음 파일을 저장할 수 있습니다.
![](/2022/Days/Images/Day38_Git7.png)
### 커밋 모범 사례
커밋 시기와 커밋 횟수 사이에는 균형이 필요합니다. 프로젝트가 끝날 때까지 기다렸다가 커밋하는 것은 바람직하지 않으며, 각 커밋은 의미가 있어야 하고 서로 관련 없는 작업들은 함께 커밋해서는 안 됩니다. 버그 수정과 오타를 해결한 경우, 두 가지 커밋을 분리하여 커밋하는 것이 좋습니다.
커밋 메시지에 의미를 부여하세요.
문구 측면에서, 팀이나 본인이 각 커밋에 대해 동일한 문구를 사용해야 합니다.
### 스테이징 영역 건너뛰기
변경 사항을 커밋하기 전에 항상 스테이징해야 할까요?
정답은 '예'이지만, 롤백할 스냅샷이 필요하지 않다는 것을 100% 확신해야 하며, 이는 위험할 수 있습니다.
![](/2022/Days/Images/Day38_Git8.png)
### 파일 제거
프로젝트에서 파일을 제거하는 것은 어떨까요? 디렉토리에 커밋했지만 이제 프로젝트에 더 이상 필요하지 않거나 사용하지 않는 다른 파일이 있는 경우, 파일을 제거해야 합니다.
디렉토리에서 파일을 제거해도 git은 여전히 이 파일을 인식하므로 리포지토리에서도 파일을 제거해야 합니다. 아래에서 이를 위한 워크플로우를 확인할 수 있습니다.
![](/2022/Days/Images/Day38_Git9.png)
이동하는 파일과 폴더가 많은 대규모 프로젝트의 경우 기억하거나 처리하는 것이 다소 번거로울 수 있습니다. 이 작업은 `git rm oldcode.ps1` 명령 하나로 수행할 수 있습니다.
![](/2022/Days/Images/Day38_Git10.png)
### 파일 이름 바꾸기 또는 이동
운영 체제 내에서 파일 이름을 바꾸고 이동할 수 있습니다. 프로젝트에서 때때로 이 작업을 해야 할 때가 있을 것입니다. 2단계 프로세스가 있지만 제거와 유사하게, OS에서 파일을 변경한 다음 스테이징 영역이나 파일이 올바르게 추가되었는지 수정하고 확인해야 합니다. 단계는 다음과 같습니다:
![](/2022/Days/Images/Day38_Git11.png)
그러나 운영 체제에서 파일을 제거한 다음 git 리포지토리에서 파일을 제거하는 것과 마찬가지로 git 명령을 사용하여 이름 변경을 할 수 있습니다.
![](/2022/Days/Images/Day38_Git12.png)
### 파일 무시하기
프로젝트 내 로컬에서만 사용 중이거나 전체 프로젝트에 공유되면 공간 낭비일 수 있는 파일이나 폴더를 무시해야 하는 경우가 있는데, 그 좋은 예로 로그를 들 수 있습니다. 또한 공개적으로 또는 팀 간에 공유하고 싶지 않은 비밀에 대해서도 이 기능을 사용할 수 있다고 생각합니다.
프로젝트 디렉토리의 `.gitignore` 파일에 폴더나 파일을 추가하여 파일을 무시할 수 있습니다.
![](/2022/Days/Images/Day38_Git13.png)
`.gitignore` 파일을 열면 logs/ 디렉토리가 있는 것을 확인할 수 있습니다. 여기에 무시할 파일과 폴더를 추가할 수도 있습니다.
![](/2022/Days/Images/Day38_Git14.png)
이제 `git status`를 보고 어떤 일이 일어났는지 확인할 수 있습니다.
![](/2022/Days/Images/Day38_Git15.png)
로그 폴더를 이미 공유했지만, 나중에 공유하면 안 된다는 것을 깨달았을 때 파일과 폴더를 무시해야 하는 경우도 있습니다. 이전에 추적한 폴더가 있지만 이제 무시하고 싶은 경우 `git rm --cached`를 사용하여 스테이징 영역에서 파일과 폴더를 제거해야 합니다.
### 간략한 status
준비 영역에 무엇이 있고 무엇이 없는지 파악하기 위해 `git status`를 많이 사용해왔는데, 이 명령은 매우 포괄적이고 세부적인 내용을 담고 있습니다. 대부분의 경우 무엇이 수정되었는지 또는 무엇이 새로운 것인지 알고 싶을 것입니다. 이 세부 사항에 대한 간단한 상태를 확인하려면 `git status -s`를 사용할 수 있습니다. 저는 보통 시스템에서 단축어로 설정하여 더 자세한 명령 대신 `git status -s`만 사용하도록 합니다.
![](/2022/Days/Images/Day38_Git16.png)
내일 포스트에서는 이러한 일반적인 git 명령에 대한 간략한 예제를 계속 살펴보겠습니다.
## 자료
- [What is Version Control?](https://www.youtube.com/watch?v=Yc8sCSeMhi4)
- [Types of Version Control System](https://www.youtube.com/watch?v=kr62e_n6QuQ)
- [Git Tutorial for Beginners](https://www.youtube.com/watch?v=8JJ101D3knE&t=52s)
- [Git for Professionals Tutorial](https://www.youtube.com/watch?v=Uszj_k0DGsg)
- [Git and GitHub for Beginners - Crash Course](https://www.youtube.com/watch?v=RGOj5yH7evk&t=8s)
- [Complete Git and GitHub Tutorial](https://www.youtube.com/watch?v=apGV9Kg7ics)
- [Git cheatsheet](https://www.atlassian.com/git/tutorials/atlassian-git-cheatsheet)
[Day 39](day39.md)에서 봐요!

212
2022/ko/Days/day39.md Normal file
View File

@ -0,0 +1,212 @@
---
title: '#90DaysOfDevOps - Viewing, unstaging, discarding & restoring - Day 39'
published: false
description: '90DaysOfDevOps - Viewing, unstaging, discarding & restoring'
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048827
---
## 보기, 스테이징 해제, 삭제 및 복원
어제에 이어서 git에서 사용할 수 있는 몇 가지 명령어와 프로젝트에서 git을 활용하는 방법에 대해 알아보겠습니다. 아직 GitHub나 다른 git 기반 서비스에 대해서는 다루지 않았지만, 지금은 로컬에서 프로젝트를 제어하는 데 도움이 되는 내용이며, 향후 해당 도구에 통합되기 시작하면 모두 유용하게 사용할 수 있을 것입니다.
### 스테이징된 변경 사항과 스테이징되지 않은 변경 사항 보기
commit하기 전에 스테이징된 코드와 스테이징되지 않은 코드를 확인하는 것이 좋습니다. 다음 `git diff --staged` 명령을 실행하면 됩니다.
![](/2022/Days/Images/Day39_Git1.png)
그러면 우리가 수행한 모든 변경 사항과 추가하거나 삭제한 모든 새 파일이 표시됩니다.
수정한 파일의 변경 사항은 `---` 또는 `+++`로 표시되며, 아래에서 방금 + 추가한 텍스트는 새로운 줄임을 의미합니다.
![](/2022/Days/Images/Day39_Git2.png)
또한 `git diff`를 실행하여 스테이징 영역과 작업 디렉토리를 비교할 수 있습니다. 새로 추가한 code.txt 파일을 변경하고 몇 줄의 텍스트를 추가하면 다음과 같습니다.
![](/2022/Days/Images/Day39_Git3.png)
그런 다음 `git diff`를 실행하면 아래와 같은 출력을 비교하여 확인할 수 있습니다.
![](/2022/Days/Images/Day39_Git4.png)
### 시각적 Diff 도구
저는 위의 방법이 혼란스럽다고 생각하기 때문에 시각적 도구를 사용하는 편이 낫습니다,
몇 가지 시각적 Diff 도구를 소개합니다:
- KDiff3
- P4Merge
- WinMerge (Windows 전용)
- VSCode
git에서 설정하려면 다음 명령 `git config --global diff.tool vscode`를 실행합니다.
위의 명령어를 실행하고 VScode를 시작할 때 몇 가지 매개 변수를 설정하겠습니다.
![](/2022/Days/Images/Day39_Git5.png)
또한 `git config --global -e`로 설정을 확인할 수 있습니다.
![](/2022/Days/Images/Day39_Git6.png)
이제 `git difftool`을 사용하여 Diff 시각화 도구를 열 수 있습니다.
![](/2022/Days/Images/Day39_Git7.png)
이제 Diff 페이지에서 VScode 에디터를 열고 두 파일을 비교하면, 아무것도 없는 상태에서 오른쪽에 코드 한 줄을 추가한 파일 하나만 수정했습니다.
![](/2022/Days/Images/Day39_Git8.png)
이 방법은 변경 사항을 추적하기가 훨씬 쉬우며, GitHub와 같은 Git 기반 서비스를 살펴볼 때 보게 될 것과 비슷한 방식입니다.
또한 `git difftool --staged`를 사용하여 commit된 파일과 스테이지를 비교할 수 있습니다.
![](/2022/Days/Images/Day39_Git9.png)
그러면 commit하기 전에 변경된 파일들을 확인할 수 있게 됩니다.
![](/2022/Days/Images/Day39_Git10.png)
저는 IDE로 VScode를 사용하고 있으며 대부분의 IDE와 마찬가지로 이미 내장되어 있는 명령어이므로 터미널에서 직접 실행해야 하는 경우는 매우 드물지만, 어떤 이유로 IDE가 설치되어 있지 않은 경우 유용합니다.
### 히스토리 보기
앞서 리포지토리에서 수행한 모든 commit을 종합적으로 볼 수 있는 `git log`에 대해 살펴봤습니다.
![](/2022/Days/Images/Day39_Git11.png)
각 commit에는 리포지토리에 고유한 16진수 문자열이 있습니다. 여기에서 작업 중인 branch와 작성자, 날짜, commit 메시지를 확인할 수 있습니다.
또한 `git log --oneline`을 사용하면 다른 `diff` 명령에서 사용할 수 있는 훨씬 더 작은 버전의 16진수 문자열을 얻을 수 있습니다. 또한 한 줄 설명 또는 commit 메시지만 있습니다.
![](/2022/Days/Images/Day39_Git12.png)
`git log --oneline --reverse`를 실행하면 페이지 상단에 첫 번째 commit이 표시됩니다.
![](/2022/Days/Images/Day39_Git13.png)
### commit 보기
commit 메시지를 볼 수 있는 것은 모범 사례를 따르고 의미 있는 commit 메시지를 추가한 경우 매우 유용하지만, commit을 검사하고 볼 수 있는 `git show` 명령도 있습니다.
우리는 `git log --oneline --reverse`를 사용하여 commit 목록을 가져올 수 있습니다. 그런 다음 이를 가져와서 `git show <commit ID>`를 실행할 수 있습니다.
![](/2022/Days/Images/Day39_Git14.png)
이 명령의 출력은 commit, 작성자 및 변경된 내용에 대한 세부 정보와 함께 아래와 같이 표시됩니다.
![](/2022/Days/Images/Day39_Git15.png)
`git show HEAD~1`을 사용할 수도 있습니다. 여기서 1은 현재 버전에서 몇 단계 뒤로 돌아가려는지 나타냅니다.
이 방법은 파일에 대한 세부 정보를 원하지만, 전체 스냅샷 디렉토리에 대한 트리의 모든 파일을 나열하려는 경우에 유용합니다. 마지막 commit에서 다시 한 스냅샷을 거슬러 올라가는 `git ls-tree HEAD~1` 명령을 사용하면 이 작업을 수행할 수 있습니다. 아래에서 두 개의 blob이 있는 것을 볼 수 있는데, blob은 파일을 나타내고 트리는 디렉토리를 나타냅니다. 이 정보에서 commit과 태그도 볼 수 있습니다.
![](/2022/Days/Images/Day39_Git16.png)
이제 위의 내용을 사용하여 `git show` 명령을 사용하여 파일(blob)의 내용을 자세히 확인할 수 있습니다.
![](/2022/Days/Images/Day39_Git17.png)
그러면 특정 버전의 파일 내용이 표시됩니다.
![](/2022/Days/Images/Day39_Git18.png)
### 파일 스테이징 해제
`git add .`를 사용했지만 아직 해당 스냅샷에 commit하고 싶지 않은 파일이 있는 경우가 있을 수 있습니다. 아래 예제에서는 스테이징 영역에 newfile.txt를 추가했지만, 이 파일을 commit할 준비가 되지 않았으므로 `git restore --staged newfile.txt`를 사용하여 `git add` 단계를 실행 취소하겠습니다.
![](/2022/Days/Images/Day39_Git19.png)
위 그림에서 수정된 파일(예: main.js)에 대해서도 동일한 작업을 수행하여 commit의 스테이징을 해제할 수 있습니다.
![](/2022/Days/Images/Day39_Git20.png)
저는 이 명령어가 90DaysOfDevOps 기간 동안 매우 유용하다는 것을 알았습니다. 다음 날을 위한 메모를 작성하고 싶지만, 공개 GitHub 리포지토리에 commit하고 push하고 싶지 않은 날을 앞두고 작업하는 경우가 종종 있기 때문입니다.
### 로컬 변경 사항 삭제하기
때때로 우리는 변경을 했지만, 그 변경이 마음에 들지 않아서 버리고 싶을 때가 있습니다. 다시 `git restore` 명령을 사용하여 스냅샷 또는 이전 버전에서 파일을 복원할 수 있습니다. 디렉토리에 대해 `git restore .`를 실행하면 스냅샷에서 모든 것을 복원할 수 있지만 추적되지 않은 파일이 여전히 존재한다는 것을 알 수 있습니다. 추적 중인 이전 파일은 newfile.txt라는 파일이 없습니다.
![](/2022/Days/Images/Day39_Git21.png)
이제 새로운 파일 txt 또는 추적되지 않은 파일을 제거합니다. 우리는 `git clean`을 사용하면 경고만 받을 수 있습니다.
![](/2022/Days/Images/Day39_Git22.png)
또는 결과를 알고 있다면 `git clean -fd`를 실행하여 모든 디렉토리를 강제로 제거할 수 있습니다.
![](/2022/Days/Images/Day39_Git23.png)
### 파일을 이전 버전으로 복원하기
앞서 언급했듯이 Git의 큰 장점 중 하나는 스냅샷에서 파일 사본을 복원할 수 있다는 점입니다(백업은 아니지만 매우 빠른 복원 방법입니다). 백업 솔루션을 사용하여 코드 사본을 다른 위치에도 저장하는 것을 추천드립니다.
예시로 디렉토리에서 가장 중요한 파일을 삭제해 보겠습니다. 디렉토리에서 이 파일을 제거하기 위해 git 명령이 아닌 Unix 기반 명령을 사용하고 있음을 알 수 있습니다.
![](/2022/Days/Images/Day39_Git24.png)
이제 작업 디렉토리에 readme.md가 없습니다. `git rm readme.md`를 사용하면 git 데이터베이스에 반영될 수 있습니다. 완전히 제거된 것을 시뮬레이션하기 위해 여기서도 삭제해 보겠습니다.
![](/2022/Days/Images/Day39_Git25.png)
이제 이 내용을 메시지와 함께 commit하고 작업 디렉토리 또는 스테이징 영역에 더 이상 아무것도 없음을 증명해 보겠습니다.
![](/2022/Days/Images/Day39_Git26.png)
실수가 있었으니 이제 이 파일을 되돌릴 필요가 있습니다!
`git undo` 명령을 사용하여 마지막 commit을 취소할 수 있지만, 오래된 commit이라면 어떻게 해야 할까요? `git log` 명령을 사용하여 commit 기록을 찾을 수 있습니다. 파일이 마지막 commit에 포함되어 있다는 것을 확인했지만, 모든 commit을 취소하고 싶지는 않습니다. 이 경우 `git restore --source=HEAD~1 README.md` 명령을 사용하여 특정 파일을 찾고 스냅샷에서 복원할 수 있습니다.
이 프로세스를 통해 파일을 작업 디렉토리에 다시 가져온 것을 볼 수 있습니다.
![](/2022/Days/Images/Day39_Git27.png)
이제 추적되지 않은 새 파일이 생겼으며 앞서 언급한 명령을 사용하여 파일과 변경 사항을 추적, 스테이징 및 commit할 수 있습니다.
### Rebase와 Merge
git 리포지토리에서 언제 rebase를 사용해야 하는지, 언제 merge를 사용해야 하는지가 가장 골치 아픈 문제인 것 같습니다.
가장 먼저 알아야 할 것은 `git rebase`와 `git merge`이 모두 같은 문제를 해결한다는 것입니다. 둘 다 한 branch의 변경 내용을 다른 branch에 통합하는 것입니다. 하지만 다른 방식으로 이 작업을 수행합니다.
새로운 feature branch로 새로운 기능을 만들어보겠습니다. main branch는 새로운 commit이 계속 추가되고 있습니다.
![](/2022/Days/Images/Day39_Git28.png)
여기서 쉬운 옵션은 `git merge feature main`을 사용하여 main branch를 feature branch에 merge하는 것입니다.
![](/2022/Days/Images/Day39_Git29.png)
merge는 비파괴적이기 때문에 간단합니다. 기존 branch는 어떤 방식으로도 변경되지 않습니다. 하지만 feature branch에 업스트림 변경 사항을 통합해야 할 때마다 관련 없는 merge commit이 발생하게 됩니다. main branch가 매우 바쁘거나 활성 상태인 경우 feature branch 히스토리를 오염시킬 수도 있습니다.
다른 옵션으로, feature branch를 main branch에 rebase하는 방법도 있습니다.
```
git checkout feature
git rebase main
```
이렇게 하면 feature branch(전체 feature branch)가 main branch에 모든 새 commit을 효과적으로 통합합니다. 그러나 merge commit을 사용하는 대신 rebase는 원래 branch에 있는 각 commit에 대해 새로운 commit을 생성하여 프로젝트 기록을 다시 작성하게 됩니다.
![](/2022/Days/Images/Day39_Git30.png)
rebase의 가장 큰 장점은 프로젝트 히스토리가 훨씬 깔끔해진다는 것입니다. 또한 불필요한 merge commit을 제거하며, 마지막 두 이미지를 비교하면 훨씬 더 깔끔한 선형 프로젝트 히스토리를 따라갈 수 있습니다.
아직 확실한 결론은 아니지만, 더 깔끔한 히스토리를 선택하는 것도 장단점이 있는데, [rebase의 황금률](https://www.atlassian.com/git/tutorials/merging-vs-rebasing#the-golden-rule-of-rebasing)을 따르지 않는다면 프로젝트 히스토리를 다시 작성하는 것은 협업 워크플로에 치명적일 수 있습니다. 그리고 더 중요한 것은 rebase를 하면 merge commit이 제공하는 컨텍스트가 사라져 업스트림 변경 사항이 언제 feature에 통합되었는지 알 수 없다는 것입니다.
## 자료
- [What is Version Control?](https://www.youtube.com/watch?v=Yc8sCSeMhi4)
- [Types of Version Control System](https://www.youtube.com/watch?v=kr62e_n6QuQ)
- [Git Tutorial for Beginners](https://www.youtube.com/watch?v=8JJ101D3knE&t=52s)
- [Git for Professionals Tutorial](https://www.youtube.com/watch?v=Uszj_k0DGsg)
- [Git and GitHub for Beginners - Crash Course](https://www.youtube.com/watch?v=RGOj5yH7evk&t=8s)
- [Complete Git and GitHub Tutorial](https://www.youtube.com/watch?v=apGV9Kg7ics)
- [Git cheatsheet](https://www.atlassian.com/git/tutorials/atlassian-git-cheatsheet)
- [Exploring the Git command line – A getting started guide](https://veducate.co.uk/exploring-the-git-command-line/)
[Day 40](day40.md)에서 봐요!

210
2022/ko/Days/day40.md Normal file
View File

@ -0,0 +1,210 @@
---
title: '#90DaysOfDevOps - Social Network for code - Day 40'
published: false
description: 90DaysOfDevOps - Social Network for code
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1049044
---
## 코드를 위한 소셜 네트워크
GitHub 살펴보기 | GitLab | BitBucket
오늘은 우리 모두가 들어봤을 법한, 그리고 우리도 매일 사용할 것으로 예상되는 몇 가지 git 기반 서비스를 다루고자 합니다.
그런 다음 이전 세션에서 배운 지식을 사용하여 데이터의 사본을 각 주요 서비스로 이동해 보겠습니다.
이 섹션을 "코드를 위한 소셜 네트워크"라고 부른 이유를 설명해드릴까요?
### GitHub
적어도 저에게 가장 일반적인 것은 GitHub입니다. GitHub는 Git을 위한 웹 기반 호스팅 서비스입니다. 소프트웨어 개발자가 코드를 저장하는 데 가장 일반적으로 사용합니다. git 버전 관리 기능뿐만 아니라 다양한 추가 기능을 통해 소스 코드를 관리할 수 있습니다. 팀이나 오픈 컨트리뷰터가 쉽게 소통할 수 있으며 코딩에 소셜 측면을 제공합니다. (따라서 소셜 네트워킹이라는 제목을 붙였습니다.) 2018년부터 GitHub는 Microsoft의 일부가 되었습니다.
GitHub는 2007/2008년에 설립되어 꽤 오래전부터 존재해 왔습니다. 현재 4천만 명 이상의 사용자가 이 플랫폼을 사용하고 있습니다.
GitHub 주요 기능
- 코드 리포지토리
- Pull Requests
- 프로젝트 관리 도구 세트 - Issues
- CI/CD 파이프라인 - GitHub Actions
가격 측면에서 GitHub는 사용자에 따라 다양한 수준의 가격을 책정합니다. 자세한 내용은 [가격](https://github.com/pricing)에서 확인할 수 있습니다.
여기서는 프리티어를 다루겠습니다.
이 안내에서는 이미 생성한 GitHub 계정을 사용할 예정이므로 계정이 없는 경우, GitHub 시작 페이지에서 가입 옵션과 몇 가지 간단한 단계를 통해 설정할 수 있습니다.
### GitHub 시작 페이지
GitHub 계정에 처음 로그인하면 다양한 위젯이 포함된 페이지가 표시되어 어디에서 무엇을 보고 싶고 무엇을 할 것인지에 대한 옵션을 제공합니다. 먼저 "All Activity"를 통해 리포지토리에서 어떤 일이 일어나고 있는지 또는 조직이나 계정과 관련된 일반적인 활동을 살펴볼 수 있습니다.
![](/2022/Days/Images/Day40_Git1.png)
다음으로, 자체 리포지토리 또는 최근에 상호 작용한 리포지토리가 있는 코드 리포지토리가 있습니다. 새 리포지토리나 검색 리포지토리를 빠르게 생성할 수도 있습니다.
![](/2022/Days/Images/Day40_Git2.png)
최근 활동은 제가 최근에 만들었거나 기여한 issues와 pull requests입니다.
![](/2022/Days/Images/Day40_Git3.png)
페이지 오른쪽에는 최근 활동 또는 자체 프로젝트를 기반으로 관심을 가질 만한 리포지토리에 대한 추천이 있습니다.
![](/2022/Days/Images/Day40_Git4.png)
솔직히 저는 방금 보고 설명한 홈페이지에 거의 들어가지 않지만, 특정 프로젝트에서 커뮤니티와 좀 더 잘 소통하는 데 이 피드가 정말 유용할 수 있다는 것을 깨달았습니다.
다음으로 GitHub 프로필로 이동하려면 오른쪽 상단 모서리로 이동하면 이미지에 계정을 탐색할 수 있는 드롭다운이 있습니다. 여기에서 프로필에 액세스하려면 "Your Profile"을 선택합니다.
![](/2022/Days/Images/Day40_Git5.png)
다음으로 프로필 페이지가 표시되는데, 기본적으로 설정을 변경하지 않는 한 내가 가진 것을 볼 수 없으며, [vZilla](https://vzilla.co.uk)의 최근 블로그 게시물과 내 [YouTube](https://m.youtube.com/c/MichaelCade1) 채널의 최신 동영상을 보여주는 기능을 추가했습니다.
프로필을 보는 데 많은 시간을 할애하지는 않겠지만, 현재 진행 중인 멋진 프로젝트를 볼 수 있도록 네트워크에 공유하기에 좋은 프로필 페이지입니다.
![](/2022/Days/Images/Day40_Git6.png)
이제 GitHub의 빌딩 블록인 리포지토리를 자세히 살펴볼 수 있습니다. 여기에서 리포지토리를 볼 수 있으며 비공개 리포지토리가 있는 경우 이 긴 목록에 해당 리포지토리도 표시됩니다.
![](/2022/Days/Images/Day40_Git7.png)
리포지토리는 GitHub에서 매우 중요하기 때문에 최근에 많이 사용된 리포지토리를 선택하여 로컬 시스템에서 git으로 "코드"를 편집할 때 이미 사용하고 있는 모든 기능 외에 여기서 사용할 수 있는 핵심 기능 몇 가지를 살펴보겠습니다.
우선, 이전 창에서 90DaysOfDevOps 리포지토리를 선택했더니 다음과 같은 보기가 표시됩니다. 이 보기에서 많은 정보를 볼 수 있으며, 리포지토리에 저장된 파일과 폴더를 보여주는 기본 코드 구조가 있습니다. 맨 아래에는 README.md이 표시됩니다. 페이지 오른쪽에는 리포지토리에 대한 설명과 목적이 있는 정보 섹션이 있습니다. 그리고 그 아래에는 얼마나 많은 사람들이 프로젝트에 참여하고, folk하고, 봤는지 보여주는 많은 정보가 있습니다.
![](/2022/Days/Images/Day40_Git8.png)
조금 더 아래로 스크롤하면 릴리즈가 있는 것을 볼 수 있는데, 이는 챌린지의 Go 언어 부분에서 나온 것입니다. 우리 프로젝트에는 패키지가 없으며 여기에 기여자가 나열되어 있습니다. (오타와 사실 확인에 도움을 주신 커뮤니티에 감사드립니다.) 그런 다음 챌린지의 다른 섹션에서 다시 사용된 언어가 있습니다.
![](/2022/Days/Images/Day40_Git9.png)
페이지 상단에 탭 목록이 표시됩니다. 탭은 다양할 수 있으며 필요한 탭만 표시하도록 수정할 수 있습니다. 이 탭들을 모두 사용하지 않으므로 전체 리포지토리를 깔끔하게 정리하려면 이 탭들을 제거해야 한다는 것을 알 수 있습니다.
먼저 방금 설명한 코드 탭이 있는데, 이 탭은 리포지토리를 탐색할 때 항상 사용할 수 있으므로 섹션 사이를 빠르고 쉽게 이동할 수 있어 매우 유용합니다. 다음으로 issues 탭이 있습니다.
issues를 사용하면 개발이 이루어지는 GitHub에서 작업을 추적할 수 있습니다. 이 특정 리포지토리에는 다이어그램이나 오타를 추가하는 데 중점을 둔 몇 가지 issues가 있지만 중국어 버전의 리포지토리에 대한 필요성 또는 요구 사항을 명시하는 issues도 있음을 알 수 있습니다.
이 리포지토리가 코드 리포지토리라면 유지 관리자에게 우려 사항이나 문제를 제기하기에 좋은 곳이지만, 보고하는 내용을 염두에 두고 가능한 한 자세하게 설명해야 함을 잊지 마세요.
![](/2022/Days/Images/Day40_Git10.png)
다음 탭은 pull requests이며, pull requests를 사용하면 리포지토리의 branch에 push한 변경 사항을 다른 사람에게 알릴 수 있습니다. 누군가 리포지토리를 folk하여 버그 수정이나 기능 개선 등의 변경을 하거나 이 리포지토리의 많은 경우, 오타를 수정했을 수 있습니다.
folk에 대해서는 나중에 다루겠습니다.
![](/2022/Days/Images/Day40_Git11.png)
다음 탭은 꽤 새로운 탭이라고 생각되죠? #90DaysOfDevOps와 같은 프로젝트에서는 이 탭이 콘텐츠 여정을 안내하는 데 도움이 될 뿐만 아니라 커뮤니티가 학습 여정을 걸어가는 데도 도움이 될 수 있다고 생각했습니다. 챌린지의 각 섹션에 대한 토론 그룹을 만들어 사람들이 참여하여 토론할 수 있도록 했습니다.
![](/2022/Days/Images/Day40_Git12.png)
Actions 탭을 사용하면 GitHub 내에서 바로 코드를 빌드, 테스트 및 배포하는 등 다양한 작업을 수행할 수 있습니다. GitHub 작업은 챌린지의 CI/CD 섹션에서 다루겠지만, 여기에서 몇 가지 구성을 설정하여 단계를 자동화할 수 있습니다.
제 기본 GitHub 프로필에서는 GitHub Actions를 사용하여 최신 블로그 게시물과 YouTube 동영상을 가져와 홈 화면에 최신 정보를 표시하고 있습니다.
![](/2022/Days/Images/Day40_Git13.png)
위에서 GitHub가 단순한 소스 코드 리포지토리가 아니라 프로젝트 관리 도구라고 말씀드렸는데, Projects 탭에서는 프로젝트 테이블을 칸반 형식의 보드로 구성하여 issues와 PR을 연결하여 프로젝트에 대한 협업을 개선하고 해당 작업에 대한 가시성을 확보할 수 있습니다.
![](/2022/Days/Images/Day40_Git14.png)
issues가 기능 요청을 기록하기에 좋은 곳인 것 같고 실제로도 그렇지만 Wiki 페이지를 사용하면 프로젝트에 대한 포괄적인 로드맵을 현재 상태와 함께 설명할 수 있고 일반적으로 문제 해결 또는 방법 유형 콘텐츠 등 프로젝트에 대한 문서화를 더 잘 할 수 있습니다.
![](/2022/Days/Images/Day40_Git15.png)
이 프로젝트에는 해당되지 않지만, Security 탭은 기여자가 특정 작업을 처리하는 방법을 알 수 있도록 하기 위한 탭으로, 여기에서 정책을 정의할 수 있을 뿐만 아니라 코드 검사 애드온을 사용하여 코드에 비밀 환경 변수가 포함되어 있지 않은지 확인할 수도 있습니다.
![](/2022/Days/Images/Day40_Git16.png)
Insight 탭은 리포지토리의 활동량부터 commit 및 issues에 이르기까지 리포지토리에 대한 많은 정보를 제공할 뿐만 아니라 리포지토리에 대한 트래픽도 보고해줘서 매우 유용합니다. 왼쪽에 리포지토리의 메트릭에 대해 자세히 살펴볼 수 있는 목록이 표시됩니다.
![](/2022/Days/Images/Day40_Git17.png)
마지막으로 Settings 탭이 있는데, 여기서 리포지토리를 실행하는 방법에 대한 세부 정보를 확인할 수 있으며, 현재 리포지토리의 유일한 관리자는 저이지만, 여기서 다른 사람에게 권한을 부여할 수 있습니다. 여기에서 통합 및 기타 작업을 정의할 수 있습니다.
![](/2022/Days/Images/Day40_Git18.png)
지금까지 GitHub에 대한 간략한 개요를 살펴봤는데, 좀 더 자세히 설명해야 할 부분이 몇 가지 더 있을 것 같습니다. 앞서 언급했듯이 GitHub에는 수백만 개의 리포지토리가 있으며, 대부분 소스 코드가 저장되어 있고 공개 또는 비공개로 액세스할 수 있습니다.
### Folk
내일 세션에서 오픈소스에 대해 더 자세히 다룰 예정이지만, 코드 리포지토리의 가장 큰 장점은 커뮤니티와 협업할 수 있다는 점입니다. 리포지토리에 몇 가지 변경을 하고 싶어서, 버그를 수정하고 싶어서, 또는 원래 코드 관리자가 의도한 사용 사례가 아닌 다른 사용 사례에 사용하기 위해 무언가를 변경하고 싶어서 리포지토리의 복사본을 원하는 시나리오를 생각해 봅시다. 이를 리포지토리 folk라고 합니다. folk는 리포지토리의 복사본입니다. 리포지토리를 folk하면 원래 프로젝트에 영향을 주지 않고 자유롭게 변경 사항을 실험할 수 있습니다.
로그인 후 시작 페이지로 돌아가서 추천 리포지토리 중 하나를 살펴보겠습니다.
![](/2022/Days/Images/Day40_Git19.png)
해당 리포지토리를 클릭하면 방금 살펴본 90DaysOfDevOps 리포지토리와 동일한 모습을 볼 수 있습니다.
![](/2022/Days/Images/Day40_Git20.png)
아래에서 3가지 옵션이 있음을 알 수 있습니다. Watch, Folk, Star가 있습니다.
- Watch - 리포지토리에 어떤 일이 발생하면 업데이트합니다.
- Folk - 리포지토리의 복사본.
- Star - "프로젝트가 멋진 것 같아요"
![](/2022/Days/Images/Day40_Git21.png)
이 리포지토리의 복사본을 작업하고 싶다는 시나리오를 고려할 때, folk 옵션을 사용하겠습니다. 여러 조직의 구성원인 경우, folk가 발생할 위치를 선택해야 하는데, 저는 제 프로필을 선택하겠습니다.
![](/2022/Days/Images/Day40_Git22.png)
이제 우리는 자유롭게 작업하고 필요에 따라 변경할 수 있는 리포지토리 사본을 갖게 되었습니다. 이것이 앞서 잠깐 언급했던 pull requests 프로세스의 시작이지만 내일 더 자세히 다루겠습니다.
![](/2022/Days/Images/Day40_Git23.png)
이 리포지토리와 코드가 웹사이트에 있는 경우, 웹사이트에 가서 편집할 수는 있지만 로컬 시스템에서 좋아하는 색상 테마로 좋아하는 IDE를 사용하는 것과는 다를 것입니다. 로컬 시스템에서 이 리포지토리의 복사본을 얻으려면 리포지토리의 복제를 수행합니다. 이렇게 하면 로컬에서 작업한 다음 변경 사항을 folk된 리포지토리 사본에 다시 push할 수 있습니다.
아래에서 볼 수 있듯이 이 코드의 복사본을 얻는 데는 몇 가지 옵션이 있습니다.
변경 사항을 추적하고 로컬과 GitHub 간에 변경 사항을 push 및 pull할 수 있는 시각적 데스크톱 애플리케이션을 제공하는 GitHub Desktop의 로컬 버전이 있습니다.
이 작은 데모에서는 여기에 표시된 HTTPS URL을 사용하겠습니다.
![](/2022/Days/Images/Day40_Git24.png)
이제 로컬 컴퓨터에서 이 리포지토리를 다운로드할 디렉토리로 이동한 다음 `git clone url`을 실행하겠습니다.
![](/2022/Days/Images/Day40_Git25.png)
이제 VScode로 가져가서 몇 가지 변경을 할 수 있습니다.
![](/2022/Days/Images/Day40_Git26.png)
이제 몇 가지 변경을 해보겠습니다. 모든 링크를 변경하고 다른 것으로 바꾸고 싶습니다.
![](/2022/Days/Images/Day40_Git27.png)
이제 GitHub를 다시 확인하고 해당 리포지토리에서 README.md을 찾으면 파일에 몇 가지 변경한 내용을 볼 수 있을 것입니다.
![](/2022/Days/Images/Day40_Git28.png)
이 단계에서는 이 작업이 완료되고 우리만 새로운 변경 사항을 사용할 것이므로 변경 사항에 만족할 수도 있지만, 버그 변경일 수도 있으며 이 경우, pull requests를 통해 기여하여 원래 리포지토리 관리자에게 변경 사항을 알리고 변경 사항을 수락하는지 확인하고 싶을 것입니다.
아래 강조 표시된 기여 버튼을 사용하여 이 작업을 수행할 수 있습니다. 내일 오픈소스 워크플로우를 살펴보면서 이에 대해 더 자세히 다루겠습니다.
![](/2022/Days/Images/Day40_Git29.png)
오랜 시간 동안 GitHub를 살펴봤는데 다른 옵션은 없는지 궁금해하시는 분들도 계실 것 같습니다!
글쎄요, 그런 옵션도 있고 그중 일부에 대한 기본 사항을 다루는 몇 가지 리소스를 찾아보려고 합니다. 앞으로 GitLab과 BitBucket을 만나게 될 텐데, 이 두 서비스는 git 기반 서비스이긴 하지만 차이점이 있습니다.
또한 호스팅 옵션도 있습니다. 호스팅 버전인 GitLab과 무료 호스팅 GitHub도 있을 거라고 생각하지 않으신가요?
## 자료
- [Learn GitLab in 3 Hours | GitLab Complete Tutorial For Beginners](https://www.youtube.com/watch?v=8aV5AxJrHDg)
- [BitBucket Tutorials Playlist](https://www.youtube.com/watch?v=OMLh-5O6Ub8&list=PLaD4FvsFdarSyyGl3ooAm-ZyAllgw_AM5)
- [What is Version Control?](https://www.youtube.com/watch?v=Yc8sCSeMhi4)
- [Types of Version Control System](https://www.youtube.com/watch?v=kr62e_n6QuQ)
- [Git Tutorial for Beginners](https://www.youtube.com/watch?v=8JJ101D3knE&t=52s)
- [Git for Professionals Tutorial](https://www.youtube.com/watch?v=Uszj_k0DGsg)
- [Git and GitHub for Beginners - Crash Course](https://www.youtube.com/watch?v=RGOj5yH7evk&t=8s)
- [Complete Git and GitHub Tutorial](https://www.youtube.com/watch?v=apGV9Kg7ics)
- [Git cheatsheet](https://www.atlassian.com/git/tutorials/atlassian-git-cheatsheet)
[Day 41](day41.md)에서 봐요!

127
2022/ko/Days/day41.md Normal file
View File

@ -0,0 +1,127 @@
---
title: '#90DaysOfDevOps - The Open Source Workflow - Day 41'
published: false
description: 90DaysOfDevOps - The Open Source Workflow
tags: 'DevOps, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048806
---
## 오픈 소스 워크플로
지난 7회에 걸친 Git 섹션을 통해 Git이 무엇인지, 그리고 GitHub와 같은 Git 기반 서비스가 어떻게 소스 코드 저장소를 제공할 뿐만 아니라 더 많은 커뮤니티가 함께 코드와 프로젝트를 협업할 수 있는 방법을 제공하는지 더 잘 이해하셨기를 바랍니다.
GitHub의 기본 사항을 살펴볼 때 임의의 프로젝트를 fork하고 로컬 리포지토리를 변경하는 과정을 거쳤습니다. 여기서는 한 단계 더 나아가 오픈소스 프로젝트에 기여하고자 합니다. 기여는 반드시 버그 수정이나 코딩 기능일 필요는 없으며 문서화일 수도 있다는 점을 기억하세요. 작은 도움이라도 모두 의미 있으며, 지금까지 다룬 몇 가지 git 기능을 직접 사용해 볼 수 있습니다.
## 프로젝트 fork하기
가장 먼저 해야 할 일은 우리가 기여할 수 있는 프로젝트를 찾는 것입니다. 저는 최근 [Kanister 프로젝트](https://github.com/kanisterio/kanister)에서 발표를 하고 있는데, 현재 유튜브에 올라와 있는 프레젠테이션을 프로젝트의 메인 README.md 파일에 공유하고자 합니다.
우선 프로젝트를 fork해야 합니다. 그 과정을 살펴보겠습니다. 위에서 공유한 링크로 이동하여 리포지토리를 fork하겠습니다.
![](/2022/Days/Images/Day41_Git1.png)
이제 전체 리포지토리의 복사본을 얻었습니다.
![](/2022/Days/Images/Day41_Git2.png)
참고로 README.md 파일에 나열된 원본 프레젠테이션은 이 두 개뿐이므로 프로세스를 통해 이 문제를 해결해야 합니다.
![](/2022/Days/Images/Day41_Git3.png)
## 로컬 머신에 복제
이제 fork를 로컬로 가져와서 파일에 대한 편집을 시작할 수 있습니다. 리포지토리의 코드 버튼을 사용하여 URL을 가져온 다음 리포지토리를 배치하려는 디렉토리에 `git clone url`을 사용하면 됩니다.
![](/2022/Days/Images/Day41_Git4.png)
## 변경하기
프로젝트가 로컬에 있으므로 VSCode 또는 원하는 IDE 또는 텍스트 편집기를 열어 수정 사항을 추가할 수 있습니다.
![](/2022/Days/Images/Day41_Git5.png)
READEME.md 파일은 마크다운 언어로 작성되었으며, 다른 사람의 프로젝트를 수정하고 있으므로 기존 프로젝트 형식을 따라 콘텐츠를 추가하겠습니다.
![](/2022/Days/Images/Day41_Git6.png)
## 변경 사항 테스트하기
코드 변경 후에도 애플리케이션이 계속 작동하는지 확인하려면 변경 사항을 테스트하는 것이 가장 좋은 방법이며, 문서 형식이 올바르게 지정되어 있는지 확인해야 합니다.
VSCode에서는 많은 플러그인을 추가할 수 있는데, 그중 하나가 마크다운 페이지를 미리 볼 수 있는 기능입니다.
![](/2022/Days/Images/Day41_Git7.png)
## 변경 사항을 fork된 리포지토리로 push하기
변경 사항을 Kanister 리포지토리로 직접 push할 수 있는 권한이 없으므로 이 경로를 사용해야 합니다. 이제 변경 사항에 만족하므로 이제 잘 알려진 몇 가지 git 명령을 실행할 수 있습니다.
![](/2022/Days/Images/Day41_Git8.png)
이제 GitHub로 돌아가서 변경 사항을 다시 한번 확인한 다음 마스터 프로젝트에 다시 기여합니다.
좋아 보이네요.
![](/2022/Days/Images/Day41_Git9.png)
이제 Kanister의 fork된 리포지토리 상단으로 돌아가서 kanisterio:master branch보다 commit이 1개 앞선 것을 볼 수 있습니다.
![](/2022/Days/Images/Day41_Git10.png)
다음으로 위에 강조 표시된 기여 버튼을 누릅니다. "Open Pull Request" 옵션이 표시됩니다.
![](/2022/Days/Images/Day41_Git11.png)
## Open Pull Request
다음 이미지에서 꽤 많은 일이 진행되고 있습니다. 왼쪽 위에는 이제 원본 또는 마스터 리포지토리에 있는 것을 볼 수 있습니다. 그리고 비교 대상인 원본 마스터 리포지토리와 fork된 리포지토리를 볼 수 있습니다. 이제 Create Pull Request 버튼이 있는데, 곧 다시 설명하겠습니다. 단일 commit이 있지만 변경 사항이 더 많으면 여기에 여러 개의 commit이 있을 수 있습니다. 그러면 README.md 파일에 변경 사항이 있습니다.
![](/2022/Days/Images/Day41_Git12.png)
위의 변경 사항을 검토했으며 녹색 버튼을 눌러 pull requests를 생성할 준비가 되었습니다.
그런 다음 프로젝트 관리자가 리포지토리에 pull requests 기능을 어떻게 설정했는지에 따라 관리자가 보고자 하는 내용을 알려주는 템플릿이 있을 수도 있고 없을 수도 있습니다.
여기서도 자신이 한 일에 대해 명확하고 간결하면서도 충분히 상세하게 의미 있는 설명을 작성해야 합니다. 간단한 변경 개요를 작성하고 문서화를 체크한 것을 볼 수 있습니다.
![](/2022/Days/Images/Day41_Git13.png)
## Create Pull Request
이제 pull requests를 만들 준비가 되었습니다. 페이지 상단의 "Create Pull Request"를 누르면 pull requests에 대한 요약이 표시됩니다.
![](/2022/Days/Images/Day41_Git14.png)
아래로 스크롤하면 일부 자동화가 진행 중인 것을 볼 수 있는데, 이 경우 검토가 필요하며 몇 가지 확인이 진행 중입니다. Travis CI가 진행 중이고 빌드가 시작되었음을 알 수 있으며, 업데이트를 확인하여 merge하기 전에 추가한 내용이 손상되지 않았는지 확인합니다.
![](/2022/Days/Images/Day41_Git15.png)
위 스크린샷에서 보이는 빨간색은 약간 위협적으로 보일 수 있으며, 마치 실수를 저질렀다고 생각할 수 있습니다. 걱정하지 마세요, 아무것도 망가뜨린 것이 없습니다. 여기서 가장 중요한 팁은 이 과정이 당신과 프로젝트 관리자를 돕기 위한 것이라는 것입니다. 혹시 실수를 저질렀다면 제 경험에 따르면 관리자가 연락하여 다음에 무엇을 해야 할지 조언해줄 것입니다.
이 pull requests는 이제 모든 사람이 볼 수 있도록 공개되었습니다 [added Kanister presentation/resource #1237](https://github.com/kanisterio/kanister/pull/1237).
merge 및 pull requests가 수락되기 전에 이 글을 게시하려고 합니다. 따라서 여전히 관심을 가지고 있는 사람들에게 성공적인 PR의 사진을 추가할 수 있는 작은 보상을 제공할 수 있을 것입니다.
1. 이 저장소를 귀하의 GitHub 계정으로 folk하세요.
2. 사진과 함께 텍스트를 추가해 주세요.
3. 변경 사항을 folk된 저장소에 push하세요.
4. 제가 볼 수 있고 승인할 수 있는 PR을 생성하세요.
5. 일종의 보상을 생각해 볼게요.
이것으로 Git과 GitHub에 대해 살펴본 내용을 마무리하고, 다음에는 컨테이너를 어떻게, 왜 사용하는지에 대한 큰 그림부터 시작하여 가상화에 대해 살펴보고 여기까지 오게 된 과정을 살펴볼 것입니다.
## 자료
- [Learn GitLab in 3 Hours | GitLab Complete Tutorial For Beginners](https://www.youtube.com/watch?v=8aV5AxJrHDg)
- [BitBucket Tutorials Playlist](https://www.youtube.com/watch?v=OMLh-5O6Ub8&list=PLaD4FvsFdarSyyGl3ooAm-ZyAllgw_AM5)
- [What is Version Control?](https://www.youtube.com/watch?v=Yc8sCSeMhi4)
- [Types of Version Control System](https://www.youtube.com/watch?v=kr62e_n6QuQ)
- [Git Tutorial for Beginners](https://www.youtube.com/watch?v=8JJ101D3knE&t=52s)
- [Git for Professionals Tutorial](https://www.youtube.com/watch?v=Uszj_k0DGsg)
- [Git and GitHub for Beginners - Crash Course](https://www.youtube.com/watch?v=RGOj5yH7evk&t=8s)
- [Complete Git and GitHub Tutorial](https://www.youtube.com/watch?v=apGV9Kg7ics)
- [Git cheatsheet](https://www.atlassian.com/git/tutorials/atlassian-git-cheatsheet)
[Day 42](day42.md)에서 봐요!

136
2022/ko/Days/day42.md Normal file
View File

@ -0,0 +1,136 @@
---
title: '#90DaysOfDevOps - The Big Picture: Containers - Day 42'
published: false
description: 90DaysOfDevOps - The Big Picture Containers
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048826
---
## 큰 그림: 컨테이너
이제 다음 섹션을 시작하겠습니다. 이번 섹션에서는 컨테이너, 특히 컨테이너에 대해 더 많이 이해하기 위해 몇 가지 핵심 영역에 대해 살펴보는 Docker를 중점적으로 다룰 것입니다.
또한 이 섹션뿐만 아니라 챌린지 후반부의 다음 섹션에서도 사용할 수 있는 컨테이너를 만들기 위한 실습도 해보려고 합니다.
언제나 그렇듯이 이번 첫 번째 포스팅에서는 우리가 어떻게 여기까지 왔는지, 그리고 이 모든 것이 무엇을 의미하는지에 대한 큰 그림에 초점을 맞출 것입니다.
플랫폼 및 애플리케이션 개발의 역사 가상화 및 컨테이너화에 대해 이야기하고 싶습니다.
### 왜 애플리케이션을 실행하는 다른 방법일까요?
가장 먼저 살펴봐야 할 것은 소프트웨어나 애플리케이션을 실행하는 다른 방법이 필요한 이유입니다. 다양한 형태로 애플리케이션을 실행할 수 있기 때문입니다. 물리적 하드웨어에 운영 체제와 단일 애플리케이션이 배포된 애플리케이션을 볼 수도 있고, 가상 머신 또는 클라우드 기반 IaaS 인스턴스가 애플리케이션을 실행한 다음 다시 가상 머신의 데이터베이스에 통합되거나 퍼블릭 클라우드의 PaaS 제품으로 통합되는 것을 볼 수도 있습니다. 또는 애플리케이션이 컨테이너에서 실행되는 것을 볼 수도 있습니다.
위의 옵션 중 어느 것도 틀린 것도, 옳은 것도 아니지만 각 옵션이 존재해야 하는 이유가 있으며, 저는 이 중 어느 것도 사라지지 않을 것이라고 굳게 믿습니다. 컨테이너와 가상 머신을 비교하는 콘텐츠를 많이 봤는데, 이는 사과와 배를 비교하는 것과 같이 둘 다 과일(애플리케이션을 실행하는 방법)이지만 같은 과일이 아니기 때문에 논쟁을 해서는 안 됩니다.
또한 애플리케이션을 개발 중이라면 나중에 이러한 영역 중 일부를 다루겠지만 효율성, 속도 및 크기에 관한 것이므로 컨테이너에 기대야 한다고 말씀드리고 싶습니다. 하지만 여기에는 대가가 따르는데, 컨테이너에 대해 전혀 모른다면 그 이유를 이해하고 그 사고방식에 익숙해지려면 학습 곡선을 밟아야 할 것입니다. 애플리케이션을 특정 방식으로 개발했거나 그린필드 환경이 아니라면 컨테이너를 고려하기 전에 해결해야 할 문제가 더 많을 수 있습니다.
특정 소프트웨어를 다운로드할 때 사용할 수 있는 운영 체제가 다양하기 때문에 선택의 폭이 넓어집니다. 그리고 애플리케이션을 설치하기 위해 수행해야 하는 작업에 대한 구체적인 지침도 있습니다.
![](/2022/Days/Images/Day42_Containers1.png)
최근에는 예전에는 전체 서버 OS, 가상 머신, 물리적 또는 클라우드 인스턴스가 필요했던 애플리케이션이 이제 컨테이너 기반 버전의 소프트웨어를 출시하는 경우가 점점 더 많아지고 있습니다. 이는 애플리케이션 개발자에게만 초점을 맞추는 것이 아니라 모든 사람에게 컨테이너와 쿠버네티스의 세계를 열어준다는 점에서 흥미롭습니다.
![](/2022/Days/Images/Day42_Containers2.png)
앞서 말씀드렸듯이, 저는 컨테이너가 정답이라고 주장하지는 않겠습니다. 하지만 애플리케이션을 배포할 때 고려해야 할 또 다른 옵션이 컨테이너라는 점을 말씀드리고 싶습니다.
![](/2022/Days/Images/Day42_Containers4.png)
최근 10년 동안, 특히 지난 5년간 컨테이너 기술이 인기를 얻은 이유는 무엇일까요? 이미 수십 년 동안 컨테이너 기술이 존재해 왔습니다. 이 문제는 컨테이너와 이미지라는 용어를 두고, 소프트웨어 배포 방식의 도전 과제로 귀결됩니다. 만약 단순히 컨테이너 기술만을 가지고 있다면, 여전히 소프트웨어 관리에 있어서 겪었던 여러 문제들이 계속 발생할 것입니다.
docker를 도구로 생각하면, docker가 성공할 수 있었던 이유는 쉽게 찾고 사용할 수 있는 이미지 에코시스템 때문입니다. 시스템에 설치하고 실행하는 것이 간단합니다. 그중 가장 중요한 부분은 소프트웨어에서 직면하는 다양한 과제에 대한 전체 공간의 일관성입니다. MongoDB든 nodeJS든 상관없이 두 가지를 모두 실행하는 프로세스는 동일합니다. 중단하는 과정도 마찬가지입니다. 이러한 모든 문제는 여전히 존재하겠지만, 좋은 점은 좋은 컨테이너와 이미지 기술을 함께 사용하면 이러한 다양한 문제를 모두 해결하는 데 도움이 되는 단일 도구 세트를 갖게 된다는 것입니다. 이러한 문제 중 일부는 다음과 같습니다:
- 먼저 인터넷에서 소프트웨어를 찾아야 합니다.
- 그런 다음, 이 소프트웨어를 다운로드해야 합니다.
- 소스를 신뢰할 수 있는가?
- 라이선스가 필요한가요? 어떤 라이선스가 필요한가요?
- 다른 플랫폼과 호환되는가?
- 패키지는 무엇인가요? 바이너리인가요? 실행 파일인가요? 패키지 관리자?
- 소프트웨어를 어떻게 구성하나요?
- 종속성은 무엇인가요? 전체 다운로드에 포함되어 있나요, 아니면 추가로 필요한가요?
- 종속성의 종속성?
- 애플리케이션을 어떻게 시작하나요?
- 애플리케이션을 어떻게 중지하나요?
- 자동으로 다시 시작되나요?
- 부팅 시 시작되나요?
- 리소스 충돌?
- 충돌하는 라이브러리?
- 포트 충돌
- 소프트웨어 보안?
- 소프트웨어 업데이트?
- 소프트웨어를 제거하려면 어떻게 해야 하나요?
위의 내용을 소프트웨어의 복잡성 중 컨테이너와 이미지가 도움이 되는 세 가지 영역으로 나눌 수 있습니다.
| Distribution | Installation | Operation |
| ------------ | ------------- | ------------------ |
| Find | Install | Start |
| Download | Configuration | Security |
| License | Uninstall | Ports |
| Package | Dependencies | Resource Conflicts |
| Trust | Platform | Auto-Restart |
| Find | Libraries | Updates |
컨테이너와 이미지는 다른 소프트웨어와 애플리케이션에서 겪을 수 있는 이러한 문제 중 일부를 제거하는 데 도움이 될 것입니다.
높은 수준에서 설치와 운영을 동일한 목록으로 옮길 수 있으며, 이미지는 배포 관점에서, 컨테이너는 설치와 운영에 도움이 될 것입니다.
좋아요, 멋지고 흥미진진하게 들리겠지만 컨테이너가 무엇인지 이해할 필요가 있고 이제 이미지를 언급했으니 다음에는 그 부분을 다루겠습니다.
소프트웨어 개발용 컨테이너에 대해 이야기할 때 많이 보셨을 또 다른 것은 선적 컨테이너와 함께 사용되는 비유입니다. 선적 컨테이너는 대형 선박을 사용하여 바다를 가로질러 다양한 물품을 운송하는 데 사용됩니다.
![](/2022/Days/Images/Day42_Containers5.png)
이것이 컨테이너라는 주제와 어떤 관련이 있을까요? 소프트웨어 개발자가 작성하는 코드를 생각해 보세요. 특정 코드를 한 컴퓨터에서 다른 컴퓨터로 어떻게 전송할 수 있을까요?
앞서 소프트웨어 배포, 설치 및 운영에 대해 다룬 내용을 이제 환경 비주얼로 구축하기 시작하면 다음과 같습니다. 여러 애플리케이션을 실행할 하드웨어와 운영 체제가 있습니다. 예를 들어 nodejs에는 특정 종속성이 있고 특정 라이브러리가 필요합니다. 그런 다음 MySQL을 설치하려면 필요한 라이브러리와 종속성이 필요합니다. 각 소프트웨어 애플리케이션에는 해당 라이브러리와 종속성이 있습니다. 운이 좋아서 특정 라이브러리와 종속성이 충돌하여 문제를 일으키는 애플리케이션 간에 충돌이 발생하지 않을 수도 있지만, 애플리케이션이 많을수록 충돌의 가능성이나 위험은 높아집니다. 그러나 소프트웨어 애플리케이션을 모두 수정한 후 업데이트하면 이러한 충돌이 발생할 수도 있습니다.
![](/2022/Days/Images/Day42_Containers6.png)
컨테이너는 이 문제를 해결하는 데 도움이 될 수 있습니다. 컨테이너는 애플리케이션을 **구축**하고, 애플리케이션을 **배송**하고, 이러한 애플리케이션을 독립적으로 쉽게 **배포**하고 **확장**할 수 있도록 도와줍니다. 아키텍처를 살펴보면 하드웨어와 운영체제가 있고 그 위에 나중에 다룰 docker(docker)와 같은 컨테이너 엔진이 있습니다. 컨테이너 엔진 소프트웨어는 라이브러리와 종속성을 함께 패키징하는 컨테이너를 생성하는 데 도움이 되므로 라이브러리와 종속성이 컨테이너 패키지의 일부로 제공되므로 라이브러리와 종속성에 대한 걱정 없이 이 컨테이너를 한 시스템에서 다른 시스템으로 원활하게 이동할 수 있으므로 이 컨테이너는 애플리케이션이 실행하는 데 필요한 기본 종속성에 대한 걱정 없이 시스템 간에 이동이 가능합니다.
애플리케이션이 실행하는 데 필요한 모든 것이 컨테이너로 패키징되어 있기 때문에
컨테이너로 패키징되어 있기 때문입니다.
![](/2022/Days/Images/Day42_Containers7.png)
### 컨테이너의 장점
- 컨테이너는 컨테이너 내의 모든 종속성을 패키징하고 격리할 수 있습니다.
- 컨테이너를 쉽게 관리할 수 있습니다.
- 한 시스템에서 다른 시스템으로 이동할 수 있습니다.
- 컨테이너는 소프트웨어를 패키징하는 데 도움이 되며 중복 작업 없이 쉽게 배포할 수 있습니다.
- 컨테이너는 쉽게 확장할 수 있습니다.
컨테이너를 사용하면 독립적인 컨테이너를 확장하고 로드 밸런서를 사용할 수 있습니다.
또는 트래픽을 분할하는 데 도움이 되는 서비스를 사용하여 애플리케이션을 수평적으로 확장할 수 있습니다. 컨테이너는 애플리케이션 관리 방식에 있어 많은 유연성과 편의성을 제공합니다.
### 컨테이너란 무엇인가요?
컴퓨터에서 애플리케이션을 실행할 때 이 글을 읽는 데 사용하고 있는 웹 브라우저나 VScode가 컨테이너일 수 있습니다. 해당 애플리케이션은 프로세스로 실행되거나 프로세스라고 하는 것으로 알려져 있습니다. 노트북이나 시스템에서는 여러 개의 애플리케이션 또는 프로세스를 실행하는 경향이 있습니다. 새 애플리케이션을 열거나 애플리케이션 아이콘을 클릭하면 이 애플리케이션은 우리가 실행하려는 애플리케이션이며, 때로는 이 애플리케이션이 백그라운드에서 실행하려는 서비스일 수도 있으며, 운영 체제는 백그라운드에서 실행되는 서비스로 가득 차 있어 시스템에서 얻을 수 있는 사용자 경험을 제공합니다.
이 애플리케이션 아이콘은 파일 시스템 어딘가에 있는 실행 파일에 대한 링크를 나타내며, 운영 체제는 해당 실행 파일을 메모리에 로드합니다. 흥미롭게도 프로세스에 대해 이야기할 때 이 실행 파일을 이미지라고 부르기도 합니다.
컨테이너는 프로세스로, 컨테이너는 코드와 모든 종속성을 패키징하여 애플리케이션이 한 컴퓨팅 환경에서 다른 컴퓨팅 환경으로 빠르고 안정적으로 실행되도록 하는 소프트웨어의 표준 단위입니다.
컨테이너화된 소프트웨어는 인프라에 관계없이 항상 동일하게 실행됩니다. 컨테이너는 소프트웨어를 환경으로부터 분리하여 개발 환경과 스테이징 환경 간의 차이에도 불구하고 소프트웨어가 균일하게 작동하도록 보장합니다.
지난 섹션에서 컨테이너와 이미지의 결합이 어떻게 그리고 왜 우리 에코시스템에서 컨테이너가 인기를 얻게 되었는지에 관해 이미지를 언급했습니다.
### 이미지란 무엇인가요?
컨테이너 이미지는 경량의 독립형 실행형 소프트웨어 패키지입니다.
## 자료
- [TechWorld with Nana - Docker Tutorial for Beginners](https://www.youtube.com/watch?v=3c-iBn73dDE)
- [Programming with Mosh - Docker Tutorial for Beginners](https://www.youtube.com/watch?v=pTFZFxd4hOI)
- [Docker Tutorial for Beginners - What is Docker? Introduction to Containers](https://www.youtube.com/watch?v=17Bl31rlnRM&list=WL&index=128&t=61s)
- [Introduction to Container By Red Hat](https://www.redhat.com/en/topics/containers)
[Day 43](day43.md)에서 봐요!

88
2022/ko/Days/day43.md Normal file
View File

@ -0,0 +1,88 @@
---
title: '#90DaysOfDevOps - What is Docker & Getting installed - Day 43'
published: false
description: 90DaysOfDevOps - What is Docker & Getting installed
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048739
---
## Docker를 알아보고 설치하기
이전 포스팅에서 docker에 대해 한 번쯤은 언급했는데, 그 이유는 docker가 컨테이너가 오래전부터 사용되어 왔음에도 불구하고 대중화될 수 있었던 혁신적인 기술이기 때문입니다.
여기서는 docker를 사용하고 설명할 예정이지만, 벤더 종속의 위험을 피하면서 혁신을 장려하는 산업 표준 조직인 [Open Container Initiative(OCI)](https://www.opencontainers.org/)에 대해서도 언급해야 합니다. OCI 덕분에 컨테이너 툴체인을 선택할 때 Docker, [CRI-O](https://cri-o.io/), [Podman](http://podman.io/), [LXC](https://linuxcontainers.org/) 등을 선택할 수 있게 되었습니다.
docker는 컨테이너를 빌드, 실행 및 관리하기 위한 소프트웨어 프레임워크입니다. "docker"라는 용어는 도구(명령어 및 데몬) 또는 Dockerfile 파일 형식을 지칭할 수 있습니다.
여기서는 (교육 및 학습용으로) 무료인 Docker Personal을 사용하겠습니다. 여기에는 컨테이너와 도구에 대한 지식의 기초를 다지기 위해 다루어야 할 모든 필수 사항이 포함됩니다.
우리가 사용할 몇 가지 "docker" 도구와 그 용도를 세분화해 볼 가치가 있을 것입니다. docker라는 용어는 개발자와 관리자가 애플리케이션을 개발, 배포 및 실행하기 위한 플랫폼인 docker 프로젝트 전반을 지칭할 수 있습니다. 또한 이미지와 컨테이너를 관리하는 호스트에서 실행되는 docker 데몬 프로세스를 지칭할 수도 있으며, Docker Engine이라고도 합니다.
### Docker Engine
Docker Engine은 애플리케이션을 빌드하고 컨테이너화하기 위한 오픈소스 컨테이너화 기술입니다. Docker Engine은 클라이언트-서버 애플리케이션으로 작동합니다:
- 장기 실행 데몬 프로세스인 dockerd가 있는 서버.
- API는 프로그램이 Docker 데몬과 대화하고 지시하는 데 사용할 수 있는 인터페이스를 지정합니다.
- 커맨드라인 인터페이스(CLI) 클라이언트 docker입니다.
위의 내용은 공식 docker 문서와 특정 [Docker Engine 개요](https://docs.docker.com/engine/)에서 발췌한 것입니다.
### Docker Desktop
저희는 Windows와 macOS 시스템 모두를 위한 Docker Desktop을 제공합니다. 설치하기 쉬운 경량 docker 개발 환경입니다. 호스트 운영 체제의 가상화 기능을 활용하는 네이티브 OS 애플리케이션입니다.
Windows 또는 macOS에서 docker화된 애플리케이션을 빌드, 디버그, 테스트, 패키징 및 출시하려는 경우 가장 적합한 솔루션입니다.
Windows에서는 WSL2와 Microsoft Hyper-V도 활용할 수 있습니다. WSL2의 몇 가지 이점은 차근차근 살펴보도록 하겠습니다.
호스트 운영 체제의 하이퍼바이저 기능과 통합되어 있기 때문에 docker는 리눅스 운영 체제에서 컨테이너를 실행할 수 있는 기능을 제공합니다.
### Docker Compose
Docker Compose는 여러 컨테이너에서 더 복잡한 앱을 실행할 수 있는 도구입니다. 단일 파일과 명령을 사용하여 애플리케이션을 스핀업할 수 있다는 이점이 있습니다.
### Docker Hub
docker와 그 구성 요소로 작업하기 위한 중앙 집중식 리소스입니다. 가장 일반적으로는 docker 이미지를 호스팅하는 레지스트리로 알려져 있습니다. 그러나 여기에는 부분적으로 자동화와 함께 사용하거나 보안 검사뿐만 아니라 GitHub에 통합할 수 있는 많은 추가 서비스가 있습니다.
### Dockerfile
Dockerfile은 일반적으로 docker 이미지를 빌드하기 위해 수동으로 실행하는 명령이 포함된 텍스트 파일입니다. docker는 Dockerfile에 있는 지침을 읽어 이미지를 자동으로 빌드할 수 있습니다.
## Docker Desktop 설치
[Docker 문서](https://docs.docker.com/engine/install/)는 매우 훌륭하며, 이제 막 docker에 입문하는 분이라면 꼭 한 번 읽어보시기 바랍니다. 여기서는 WSL2가 설치된 Windows에서 Docker Desktop을 사용하겠습니다. 여기서 사용하는 머신에 이미 설치를 완료했습니다.
![](/2022/Days/Images/Day43_Containers1.png)
설치를 진행하기 전에 시스템 요구 사항을 참고하시기 바라며, [윈도우에 Docker Desktop 설치하기](https://docs.docker.com/desktop/windows/install/)를 참고하시고, M1 기반 CPU 아키텍처를 포함한 맥OS를 사용하시는 경우 [맥OS에 docker Desktop 설치하기](https://docs.docker.com/desktop/mac/install/)도 참고하시면 됩니다.
다른 윈도우 머신에서 윈도우용 docker Desktop 설치를 실행하고 그 과정을 아래에 기록해 보겠습니다.
### Windows
- 장치의 운영 체제로 Windows를 선택합니다.
<img src = ../../Days/Images/Day43_operatingSystem.png>
- 인스톨러를 저장할 폴더로 이동하여 저장합니다.
- 인스톨러를 실행하고 몇 초간 기다린 후 WSL에 대한 액세스 권한을 부여합니다.
<img src = ../../Days/Images/Day43_EnableWSL.png>
- 확인을 클릭하면 설치가 시작됩니다.
<img src = ../../Days/Images/Day43_install.png>
- Docker Desktop이 장치에 성공적으로 설치되었습니다. 이제 터미널에서 "docker" 명령을 실행하여 설치가 성공적으로 완료되었는지 확인할 수 있습니다.
<img src = ../../Days/Images/Day43_check.png>
## 자료
- [TechWorld with Nana - Docker Tutorial for Beginners](https://www.youtube.com/watch?v=3c-iBn73dDE)
- [Programming with Mosh - Docker Tutorial for Beginners](https://www.youtube.com/watch?v=pTFZFxd4hOI)
- [Docker Tutorial for Beginners - What is Docker? Introduction to Containers](https://www.youtube.com/watch?v=17Bl31rlnRM&list=WL&index=128&t=61s)
- [WSL 2 with Docker getting started](https://www.youtube.com/watch?v=5RQbdMn04Oc)
[Day 44](day44.md)에서 봐요!

141
2022/ko/Days/day44.md Normal file
View File

@ -0,0 +1,141 @@
---
title: '#90DaysOfDevOps - Docker Images & Hands-On with Docker Desktop - Day 44'
published: false
description: 90DaysOfDevOps - Docker Images & Hands-On with Docker Desktop
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048708
---
## Docker 이미지 및 Docker Desktop 실습하기
이제 시스템에 Docker Desktop을 설치했습니다. (Linux를 실행하는 경우 여전히 옵션은 있지만 GUI는 없지만 Docker는 Linux에서 작동합니다.)[우분투에 Docker Engine 설치](https://docs.docker.com/engine/install/ubuntu/) (다른 배포판도 사용할 수 있습니다.)
이 글에서는 몇 가지 이미지를 우리 환경에 배포하는 작업을 시작하겠습니다. Docker 이미지에 대한 요약 - Docker 이미지는 Docker 컨테이너에서 코드를 실행하는 데 사용되는 파일입니다. Docker 이미지는 템플릿처럼 Docker 컨테이너를 빌드하기 위한 일련의 지침 역할을 합니다. 또한 Docker 이미지는 Docker를 사용할 때 시작점 역할을 하기도 합니다.
지금 바로 [Docker Hub](https://hub.docker.com/)에서 계정을 생성하세요.
![](/2022/Days/Images/Day44_Containers1.png)
Docker Hub는 Docker 및 그 구성 요소로 작업하기 위한 중앙 집중식 리소스입니다. 가장 일반적으로는 docker 이미지를 호스팅하는 레지스트리로 알려져 있습니다. 그러나 여기에는 부분적으로 자동화와 함께 사용하거나 보안 검사뿐만 아니라 GitHub에 통합할 수 있는 많은 추가 서비스가 있습니다.
로그인한 후 아래로 스크롤하면 컨테이너 이미지 목록이 표시되며, MySQL, hello-world 등의 데이터베이스 이미지가 표시될 수 있습니다. 데이터베이스 이미지가 필요하거나 직접 만들 필요가 없는 경우 공식 이미지를 사용하는 것이 가장 좋습니다.
![](/2022/Days/Images/Day44_Containers2.png)
사용 가능한 이미지 보기를 더 자세히 살펴보고 카테고리, 운영 체제 및 아키텍처에 따라 검색할 수 있습니다. 아래에서 강조 표시한 것은 공식 이미지로, 이 컨테이너 이미지의 출처에 대해 안심할 수 있습니다.
![](/2022/Days/Images/Day44_Containers3.png)
특정 이미지를 검색할 수도 있습니다. 예를 들어 워드프레스가 좋은 기본 이미지가 될 수 있으므로 상단에 있는 이미지를 검색하여 워드프레스와 관련된 모든 컨테이너 이미지를 찾을 수 있습니다. 아래는 확인된 퍼블리셔에 대한 공지사항입니다.
- 공식 이미지 - Docker 공식 이미지는 엄선된 Docker 오픈 소스 및 "drop-in" 솔루션 리포지토리 집합입니다.
- 검증된 퍼블리셔 - 검증된 퍼블리셔의 고품질 Docker 콘텐츠입니다. 이러한 제품은 상업적 주체가 직접 게시하고 유지 관리합니다.
![](/2022/Days/Images/Day44_Containers4.png)
### Docker Desktop 살펴보기
저희 시스템에는 Docker Desktop이 설치되어 있으며, 이 파일을 열면 이미 설치되어 있지 않다면 아래 이미지와 비슷한 것을 볼 수 있을 것입니다. 보시다시피 컨테이너가 실행되고 있지 않고 Docker Engine이 실행되고 있습니다.
![](/2022/Days/Images/Day44_Containers5.png)
새로 설치한 것이 아니기 때문에 이미 다운로드하여 시스템에 사용할 수 있는 이미지가 몇 개 있습니다. 여기에는 아무것도 표시되지 않을 것입니다.
![](/2022/Days/Images/Day44_Containers6.png)
원격 리포지토리 아래에서 Docker Hub에 저장한 컨테이너 이미지를 찾을 수 있습니다. 아래에서 볼 수 있듯이 이미지가 없습니다.
![](/2022/Days/Images/Day44_Containers7.png)
Docker Hub 사이트에서도 리포지토리가 없음을 확인할 수 있습니다.
![](/2022/Days/Images/Day44_Containers8.png)
다음으로 Volumes 탭이 있는데, 지속성이 필요한 컨테이너가 있는 경우 여기에서 로컬 파일 시스템이나 공유 파일 시스템에 이러한 Volumes를 추가할 수 있습니다.
![](/2022/Days/Images/Day44_Containers9.png)
이 글을 쓰는 시점에 Environments 탭도 있는데, 이 탭은 다른 git branch 사이를 이동하지 않고 팀과 협업하는 데 도움이 될 것입니다. 여기서는 다루지 않겠습니다.
![](/2022/Days/Images/Day44_Containers10.png)
첫 번째 탭으로 돌아가면 시작 컨테이너를 실행할 수 있는 명령이 있음을 알 수 있습니다. 터미널에서 `docker run -d -p 80:80 docker/getting-started`를 실행해 보겠습니다.
![](/2022/Days/Images/Day44_Containers11.png)
Docker Desktop 창을 다시 확인하면 컨테이너가 실행 중인 것을 확인할 수 있습니다.
![](/2022/Days/Images/Day44_Containers12.png)
WSL2를 사용하고 있다는 것을 눈치채셨을 텐데요, 이를 사용하려면 설정에서 이 기능이 활성화되어 있는지 확인해야 합니다.
![](/2022/Days/Images/Day44_Containers13.png)
이제 Images 탭으로 다시 이동하여 확인하면 이제 사용 중인 이미지인 docker/getting-started를 볼 수 있습니다.
![](/2022/Days/Images/Day44_Containers14.png)
Containers/Apps 탭으로 돌아가서 실행 중인 컨테이너를 클릭합니다. 기본적으로 로그가 표시되고 상단에 선택할 수 있는 몇 가지 옵션이 있는데, 이 컨테이너에서 실행 중인 웹 페이지가 될 것이 확실하므로 브라우저에서 열기를 선택하겠습니다.
![](/2022/Days/Images/Day44_Containers15.png)
위의 버튼을 누르면 로컬호스트로 연결되는 웹 페이지가 열리고 아래와 비슷한 내용이 표시됩니다.
이 컨테이너에는 컨테이너와 이미지에 대한 자세한 내용도 있습니다.
![](/2022/Days/Images/Day44_Containers16.png)
이제 첫 번째 컨테이너를 실행했습니다. 아직은 쉽습니다. 컨테이너 이미지 중 하나를 Docker Hub에서 가져오고 싶다면 어떻게 해야 할까요? 아마도 우리가 사용할 수 있는 `hello world` docker 컨테이너가 있을 것입니다.
시작 컨테이너는 리소스를 많이 차지하기 때문이 아니라 몇 가지 단계를 더 진행하면서 깔끔하게 정리하기 위해 중단했습니다.
터미널로 돌아와서 `docker run hello-world`를 실행하고 어떤 일이 일어나는지 살펴봅시다.
로컬에 이미지가 없었기 때문에 이미지를 끌어내렸고, 컨테이너 이미지에 시작 및 실행에 대한 몇 가지 정보와 참조 지점에 대한 링크가 포함된 메시지가 표시되는 것을 볼 수 있습니다.
![](/2022/Days/Images/Day44_Containers17.png)
그러나 이제 Docker Desktop을 살펴보면 실행 중인 컨테이너는 없지만, hello-world 메시지를 사용한 종료된 컨테이너, 즉 시작되어 메시지를 전달한 후 종료된 컨테이너는 있습니다.
![](/2022/Days/Images/Day44_Containers18.png)
마지막으로 Images 탭을 확인해보면 시스템에 로컬로 새로운 hello-world 이미지가 있는 것을 확인할 수 있습니다. 즉, 터미널에서 `docker run hello-world` 명령을 다시 실행해도 버전이 변경되지 않는 한 아무것도 가져올 필요가 없습니다.
![](/2022/Days/Images/Day44_Containers19.png)
'hello-world' 컨테이너에서 온 메시지로 인해 조금 더 야심찬 도전을 하고 싶어졌습니다.
도전!
![](/2022/Days/Images/Day44_Containers20.png)
터미널에서 `docker run -it ubuntu bash`를 실행할 때 우리는 운영 체제의 전체 복사본이 아닌 우분투의 컨테이너화된 버전을 실행할 것입니다. 이 특정 이미지에 대한 자세한 내용은 [Docker Hub](https://hub.docker.com/_/ubuntu)에서 확인할 수 있습니다.
아래 명령어를 실행하면 대화형 프롬프트(`-it`)가 나타나고 컨테이너에 bash 셸이 생성되는 것을 볼 수 있습니다.
![](/2022/Days/Images/Day44_Containers21.png)
bash 셸이 있지만 그 이상은 없기 때문에 이 컨테이너 이미지는 30MB 미만입니다.
![](/2022/Days/Images/Day44_Containers22.png)
하지만 여전히 이 이미지를 사용할 수 있고, apt package manager를 사용하여 소프트웨어를 설치할 수 있으며, 컨테이너 이미지를 업데이트하고 업그레이드할 수도 있습니다.
![](/2022/Days/Images/Day44_Containers23.png)
또는 컨테이너에 일부 소프트웨어를 설치하고 싶을 수도 있습니다. pinta는 이미지 편집기이고 200MB가 넘기 때문에 여기서는 정말 나쁜 예를 선택했지만 제가 이걸로 무엇을 하려는지 이해하시길 바랍니다. 이렇게 하면 컨테이너의 크기가 상당히 커지지만, 여전히 GB가 아닌 MB 단위로 사용할 것입니다.
![](/2022/Days/Images/Day44_Containers24.png)
이 글에서는 사용 사례를 통해 Docker Desktop과 컨테이너의 세계에 대한 개요를 간단하고 접근하기 쉬운 방식으로 제공하고자 합니다. 그러나 컨테이너 이미지를 다운로드하고 사용하는 것 외에도 네트워킹, 보안 및 기타 사용 가능한 옵션에 대해서도 다뤄야 합니다. 이 섹션의 궁극적인 목표는 무언가를 만들어서 Docker Hub 리포지토리에 업로드하고 배포하는 것입니다.
## 자료
- [TechWorld with Nana - Docker Tutorial for Beginners](https://www.youtube.com/watch?v=3c-iBn73dDE)
- [Programming with Mosh - Docker Tutorial for Beginners](https://www.youtube.com/watch?v=pTFZFxd4hOI)
- [Docker Tutorial for Beginners - What is Docker? Introduction to Containers](https://www.youtube.com/watch?v=17Bl31rlnRM&list=WL&index=128&t=61s)
- [WSL 2 with Docker getting started](https://www.youtube.com/watch?v=5RQbdMn04Oc)
[Day 45](day45.md)에서 봐요!

119
2022/ko/Days/day45.md Normal file
View File

@ -0,0 +1,119 @@
---
title: '#90DaysOfDevOps - The anatomy of a Docker Image - Day 45'
published: false
description: 90DaysOfDevOps - The anatomy of a Docker Image
tags: 'DevOps, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048777
---
## Docker 이미지의 구조
지난 세션에서는 Docker Hub와 결합된 Docker Desktop을 사용하여 몇 가지 검증된 이미지를 배포하고 실행하는 방법에 대한 몇 가지 기본 사항을 다루었습니다. 이미지가 무엇인지에 대한 요약을 계속 언급하면 잊어버리지 않을 것입니다.
Docker 이미지는 Docker 플랫폼에서 실행할 수 있는 컨테이너를 만들기 위한 일련의 지침이 포함된 읽기 전용 템플릿입니다. 애플리케이션과 사전 구성된 서버 환경을 패키징하여 개인적으로 사용하거나 다른 Docker 사용자와 공개적으로 공유할 수 있는 편리한 방법을 제공합니다. 또한 Docker 이미지는 Docker를 처음 사용하는 모든 사용자에게 시작점이 됩니다.
자체 Docker 이미지를 만들려면 어떻게 해야 하나요? 이를 위해서는 Dockerfile을 생성해야 합니다. 우분투 컨테이너 이미지를 가져와서 소프트웨어를 추가하면 원하는 소프트웨어가 포함된 컨테이너 이미지를 갖게 되고 모든 것이 좋지만, 컨테이너가 종료되거나 폐기되면 모든 소프트웨어 업데이트와 설치가 사라져 반복할 수 있는 버전이 없습니다. 따라서 컨테이너를 실행할 때마다 동일한 소프트웨어 세트가 설치된 여러 환경에 걸쳐 이미지를 전송하는 데는 도움이 되지 않습니다.
### Dockerfile이란?
Dockerfile은 일반적으로 docker 이미지를 빌드하기 위해 수동으로 실행하는 명령이 포함된 텍스트 파일입니다. docker는 Dockerfile에 있는 지침을 읽어 이미지를 자동으로 빌드할 수 있습니다.
docker 이미지를 구성하는 각 파일을 레이어라고 하며, 이러한 레이어는 단계적으로 서로 위에 빌드되는 일련의 이미지를 형성합니다. 각 레이어는 바로 아래 레이어에 종속됩니다. 레이어의 순서는 docker 이미지의 라이프사이클 관리 효율성의 핵심입니다.
가장 자주 변경되는 레이어는 가능한 한 스택에서 가장 높은 곳에 구성해야 하는데, 이는 이미지의 레이어를 변경하면 Docker가 해당 레이어뿐만 아니라 해당 레이어에서 빌드된 모든 레이어를 다시 빌드하기 때문입니다. 따라서 맨 위에 있는 레이어를 변경하면 전체 이미지를 다시 빌드하는 데 필요한 작업량이 가장 적습니다.
docker가 이미지로부터 컨테이너를 실행할 때마다 (어제 실행한 것처럼), 컨테이너 레이어라고 하는 쓰기 가능한 레이어가 추가됩니다. 이 레이어는 컨테이너가 실행되는 동안 모든 변경 사항을 저장합니다. 이 레이어는 실제 운영 중인 컨테이너와 소스 이미지 자체 사이의 유일한 차이점입니다. 같은 이미지에 기반한 동일한 컨테이너들이 상태를 유지하면서 액세스를 공유할 수 있습니다.
예제로 돌아가서, 어제 우분투 이미지를 사용했습니다. 동일한 명령을 여러 번 실행하여 첫 번째 컨테이너에는 pinta를 설치하고 두 번째 컨테이너에는 두 개의 다른 애플리케이션, 다른 목적, 다른 크기 등을 가진 figlet을 설치할 수 있습니다. 배포한 각 컨테이너는 동일한 이미지를 공유하지만, 동일한 상태는 아니며, 컨테이너를 제거하면 해당 상태는 사라집니다.
![](/2022/Days/Images/Day45_Containers1.png)
위의 예제에서 우분투 이미지뿐만 아니라 Docker Hub 및 기타 서드파티 리포지토리에서 사용할 수 있는 다른 많은 기성 컨테이너 이미지도 마찬가지입니다. 이러한 이미지를 일반적으로 부모 이미지라고 합니다. 이 이미지는 다른 모든 레이어가 구축되는 기반이 되며 컨테이너 환경의 기본 구성 요소를 제공합니다.
개별 레이어 파일 세트와 함께 Docker 이미지에는 manifest라는 추가 파일도 포함됩니다. 이 파일은 기본적으로 이미지에 대한 JSON 형식의 설명이며 이미지 태그, 전자 서명, 다양한 유형의 호스트 플랫폼에 맞게 컨테이너를 구성하는 방법에 대한 세부 정보와 같은 정보로 구성됩니다.
![](/2022/Days/Images/Day45_Containers2.png)
### Docker 이미지를 생성하는 방법
docker 이미지를 생성하는 방법에는 두 가지가 있습니다. 어제 시작한 프로세스로 즉석에서 만들 수 있습니다. 기본 이미지를 선택하여 해당 컨테이너를 스핀업하고 컨테이너에 원하는 모든 소프트웨어와 종속성을 설치합니다.
그런 다음 `docker commit container name`을 사용하면 이 이미지의 로컬 복사본이 docker 이미지와 Docker Desktop 이미지 탭 아래에 있습니다.
매우 간단하지만, 프로세스를 이해하고 싶은 게 아니라면, 이 방법을 권장하지 않습니다. 이 방법은 라이프사이클 관리를 관리하기가 매우 어렵고 수동 구성/재구성이 많이 필요합니다. 하지만 docker 이미지를 빌드하는 가장 빠르고 간단한 방법입니다. 테스트, 문제 해결, 종속성 검증 등에 적합합니다.
우리가 이미지를 생성하려는 방법은 Dockerfile을 통한 방법입니다. 이는 이미지를 만드는 깔끔하고 간결하며 반복 가능한 방법을 제공합니다. 더 쉬운 라이프사이클 관리와 지속적인 통합 및 지속적인 배포 프로세스에 쉽게 통합할 수 있습니다. 하지만 처음 언급된 방법보다 조금 더 어려울 수 있습니다.
Dockerfile 방법을 사용하는 것이 실제 엔터프라이즈급 컨테이너 배포에 훨씬 더 잘 맞습니다.
Dockerfile은 3단계 프로세스를 통해 Dockerfile을 만들고 이미지를 조립하는 데 필요한 명령을 추가합니다.
다음 표는 사용자가 가장 많이 사용할 가능성이 높은 몇 가지 Dockerfile 설정을 보여줍니다.
| Command | Purpose |
| ---------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| FROM | 상위 이미지를 지정합니다. |
| WORKDIR | Dockerfile에서 다음에 나오는 명령의 작업 디렉터리를 설정합니다. |
| RUN | 컨테이너에 필요한 애플리케이션과 패키지를 설치합니다. |
| COPY | 특정 위치에서 파일 또는 디렉터리를 복사합니다. |
| ADD | 복사뿐만 아니라 원격 URL을 처리하고 압축 파일의 압축을 풀 수도 있습니다. |
| ENTRYPOINT | 컨테이너가 시작될 때 항상 실행되는 명령입니다. 지정하지 않으면 기본값은 "/bin/sh -c"입니다. |
| CMD | 엔트리포인트로 전달된 인자입니다. 엔트리포인트가 설정되지 않은 경우(기본값은 "/bin/sh -c"), 컨테이너가 실행하는 명령은 CMD가 됩니다. |
| EXPOSE | 컨테이너 애플리케이션에 액세스할 포트를 정의합니다. |
| LABEL | 이미지에 메타데이터를 추가합니다. |
이제 첫 번째 Dockerfile을 빌드하는 방법에 대한 세부 정보를 얻었으므로 작업 디렉터리를 생성하고 Dockerfile을 만들 수 있습니다. 이 리포지토리 내에 작업 디렉터리를 만들었는데, [여기서](/2022/Days/Containers/) 제가 살펴봐야 할 파일과 폴더를 볼 수 있습니다.
이 디렉터리에는 지난 섹션에서 사용한 .gitignore와 유사한 .dockerignore 파일을 만들겠습니다. 이 파일에는 최종 빌드에서 제외하려는 Docker 빌드 프로세스 중에 생성되는 모든 파일이 나열됩니다.
컨테이너는 부피가 커지지 않고 가능한 한 빠르게 컴팩트하게 만들어야 함을 기억하세요.
위에 링크된 폴더에서 아래 레이아웃으로 매우 간단한 Dockerfile을 만들고 싶습니다.
```dockerfile
# 공식 우분투 18.04를 기본으로 사용하세요.
FROM ubuntu:18.04
# nginx 및 curl 설치
RUN apt-get update && apt-get upgrade -y
RUN apt-get install -y nginx curl
RUN rm -rf /var/lib/apt/lists/*
```
터미널에서 이 디렉토리로 이동한 다음 `docker build -t 90daysofdevops:0.1 .`를 실행합니다. `-t`를 사용한 다에는 이미지 이름과 태그를 설정할 수 있습니다.
![](/2022/Days/Images/Day45_Containers3.png)
이제 이미지를 만들었으므로 Docker Desktop을 사용하여 이미지를 실행하거나 docker 커맨드라인을 사용할 수 있습니다. 저의 경우에는 Docker Desktop을 사용하여 컨테이너를 실행하고, 컨테이너의 cli에서 `curl`을 사용한 것을 볼 수 있습니다.
![](/2022/Days/Images/Day45_Containers4.png)
Docker Desktop에서는 UI를 활용하여 이 새로운 이미지로 몇 가지 작업을 더 수행할 수 있습니다.
![](/2022/Days/Images/Day45_Containers5.png)
이미지를 검사하면 컨테이너 내에서 실행하려고 하는 Dockerfile과 코드들을 매우 많이 볼 수 있습니다.
![](/2022/Days/Images/Day45_Containers6.png)
pull 옵션이 있지만, 이 이미지는 어디에도 호스팅되지 않기 때문에 이 옵션은 실패할 것이고 오류로 표시됩니다. 하지만 Push to hub 옵션이 있어 이미지를 DockerHub로 push할 수 있습니다.
앞서 실행한 것과 동일한 `docker build`를 사용하는 경우에도 이 방법이 작동하지 않으므로 빌드 명령을 `docker build -t {{username}}/{{imagename}}:{{version}}`로 해야 합니다.
![](/2022/Days/Images/Day45_Containers7.png)
이제 Docker Hub 리포지토리로 이동하여 살펴보면 방금 새 이미지를 push한 것을 확인할 수 있습니다. 이제 Docker Desktop에서 해당 pull 탭을 사용할 수 있습니다.
![](/2022/Days/Images/Day45_Containers8.png)
## 자료
- [TechWorld with Nana - Docker Tutorial for Beginners](https://www.youtube.com/watch?v=3c-iBn73dDE)
- [Programming with Mosh - Docker Tutorial for Beginners](https://www.youtube.com/watch?v=pTFZFxd4hOI)
- [Docker Tutorial for Beginners - What is Docker? Introduction to Containers](https://www.youtube.com/watch?v=17Bl31rlnRM&list=WL&index=128&t=61s)
- [WSL 2 with Docker getting started](https://www.youtube.com/watch?v=5RQbdMn04Oc)
- [Blog on gettng started building a docker image](https://stackify.com/docker-build-a-beginners-guide-to-building-docker-/2022/Days/images/)
- [Docker documentation for building an image](https://docs.docker.com/develop/develop-/2022/Days/images/dockerfile_best-practices/)
[Day 46](day46.md)에서 봐요!

183
2022/ko/Days/day46.md Normal file
View File

@ -0,0 +1,183 @@
---
title: '#90DaysOfDevOps - Docker Compose - Day 46'
published: false
description: 90DaysOfDevOps - Docker Compose
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048740
---
## Docker Compose
하나의 컨테이너를 실행할 수 있는 기능은 단일 사용 사례에 필요한 모든 것을 갖춘 독립적인 이미지가 있는 경우 유용할 수 있지만, 서로 다른 컨테이너 이미지 간에 여러 애플리케이션을 빌드하려는 경우 흥미로운 문제가 발생할 수 있습니다. 예를 들어, 웹사이트 프론트엔드가 있지만 백엔드 데이터베이스가 필요한 경우 모든 것을 하나의 컨테이너에 넣을 수 있지만 데이터베이스용 컨테이너를 사용하는 것이 더 효율적이고 좋을 것입니다.
이때 여러 컨테이너에서 더 복잡한 앱을 실행할 수 있는 도구인 Docker Compose가 등장합니다. 단일 파일과 명령을 사용하여 애플리케이션을 스핀업할 수 있다는 이점이 있습니다. 이 글에서 안내하는 예제는 [Docker 빠른 시작 샘플 앱(빠른 시작: 작성 및 워드프레스)](https://docs.docker.com/samples/wordpress/)에서 가져온 것입니다.
이 첫 번째 예제에서는
- Docker Compose를 사용하여 WordPress와 별도의 MySQL 인스턴스를 불러옵니다.
- 'docker-compose.yml'이라는 YAML 파일을 사용합니다.
- 프로젝트 빌드
- 브라우저를 통해 워드프레스 구성
- 종료 및 정리
### Docker Compose 설치
앞서 언급했듯이 docker compose는 도구이며, 맥OS나 윈도우를 사용하는 경우 Docker Desktop 설치에 compose가 포함되어 있습니다. 하지만, 윈도우 서버 호스트나 리눅스 서버에서 컨테이너를 실행하고 싶을 수 있으며, 이 경우 다음 [docker compose 설치](https://docs.docker.com/compose/install/) 지침을 사용하여 설치할 수 있습니다.
터미널을 열고 위의 명령어를 입력하면 시스템에 `docker-compose`가 설치되었는지 확인할 수 있습니다.
![](/2022/Days/Images/Day46_Containers1.png)
### Docker-Compose.yml(YAML)
다음에 이야기할 것은 리포지토리의 컨테이너 폴더에서 찾을 수 있는 docker-compose.yml입니다. 그 전에, YAML에 대해 조금 설명하겠습니다.
거의 모든 프로그래밍 언어에서 사용할 수 있는 YAML은 다양한 곳에서 사용될 수 있습니다.
"YAML은 모든 프로그래밍 언어에 대한 인간 친화적인 데이터 직렬화 언어입니다."
일반적으로 구성 파일과 데이터를 저장하거나 전송하는 일부 애플리케이션에서 사용됩니다. 동일한 구성 파일을 제공하는 경향이 있는 XML 파일을 접한 적이 있을 것입니다. YAML은 최소한의 구문을 제공하지만, 동일한 사용 사례를 목표로 합니다.
YAML(YAML Ain't Markup Language)은 지난 몇 년 동안 꾸준히 인기가 높아진 직렬화 언어입니다. 객체 직렬화 기능 덕분에 JSON과 같은 언어를 대체할 수 있습니다.
YAML의 약어는 Yet Another Markup Language의 약자였습니다. 그러나 유지 관리자는 데이터 지향적 기능을 더 강조하기 위해 YAML Ain't Markup Language로 이름을 변경했습니다.
어쨌든, 다시 docker-compose.yml 파일로 돌아가겠습니다. 이 파일은 단일 시스템에 여러 개의 컨테이너를 배포할 때 수행하고자 하는 작업의 구성 파일입니다.
위에 링크된 튜토리얼에서 바로 파일의 내용을 보면 다음과 같이 보입니다:
```yaml
version: '3.9'
services:
DB:
image: mysql:5.7
volumes:
- db_data:/var/lib/mysql
restart: always
environment:
MYSQL_ROOT_PASSWORD: somewordpress
MYSQL_DATABASE: wordpress
MYSQL_USER: wordpress
MYSQL_PASSWORD: wordpress
wordpress:
depends_on:
- db
image: wordpress:latest
volumes:
- wordpress_data:/var/www/html
ports:
- '8000:80'
restart: always
environment:
WORDPRESS_DB_HOST: db
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: wordpress
WORDPRESS_DB_NAME: wordpress
volumes:
db_data: {}
wordpress_data: {}
```
버전을 선언한 다음, 이 docker-compose.yml 파일의 대부분은 서비스로 구성되어 있으며, DB 서비스와 워드프레스 서비스가 있습니다. 각 서비스에는 버전 태그가 연결된 이미지가 정의되어 있는 것을 볼 수 있습니다. 이제 첫 번째 연습과 달리 구성에 상태도 도입하고 있는데, 데이터베이스를 저장할 수 있도록 볼륨을 생성하겠습니다.
그런 다음 비밀번호 및 사용자 이름과 같은 몇 가지 환경 변수가 있습니다. 이러한 파일은 매우 복잡해질 수 있지만 YAML 구성 파일을 사용하면 전체적으로 단순화할 수 있습니다.
### 프로젝트 빌드
이제 터미널로 돌아가서 docker-compose 도구로 몇 가지 명령을 사용할 수 있습니다. 디렉토리로 이동하여 docker-compose.yml 파일이 있는 디렉터리로 이동합니다.
터미널에서 `docker-compose up -d`를 실행하면 해당 이미지를 가져와 멀티 컨테이너 애플리케이션을 세우는 프로세스가 시작됩니다.
이 명령의 `-d`는 분리 모드를 의미하며, 이는 실행 명령이 백그라운드에서 실행 중이거나 실행될 것임을 의미합니다.
![](/2022/Days/Images/Day46_Containers2.png)
이제 `docker ps` 명령을 실행하면 2개의 컨테이너가 실행 중이며 하나는 WordPress이고 다른 하나는 MySQL인 것을 볼 수 있습니다.
![](/2022/Days/Images/Day46_Containers3.png)
다음으로 브라우저를 열고 `http://localhost:8000`으로 이동하면 WordPress가 실행 중인지 확인할 수 있으며, WordPress 설정 페이지가 표시됩니다.
![](/2022/Days/Images/Day46_Containers4.png)
워드프레스 설정을 완료한 다음 아래 콘솔에서 원하는 대로 웹사이트 구축을 시작할 수 있습니다.
![](/2022/Days/Images/Day46_Containers5.png)
이제 새 탭을 열고 `http://localhost:8000` 이전과 동일한 주소로 이동하면 사이트 제목이 "90DaysOfDevOps"인 간단한 기본 테마가 표시되고 샘플 게시물이 표시됩니다.
![](/2022/Days/Images/Day46_Containers6.png)
변경하기 전에 Docker Desktop을 열고 볼륨 탭으로 이동하면 컨테이너와 연결된 두 개의 볼륨(하나는 워드프레스용, 다른 하나는 DB용)을 볼 수 있습니다.
![](/2022/Days/Images/Day46_Containers7.png)
현재 워드프레스 테마는 "Twenty Twenty-Two"이며 이를 "Twenty Twenty"로 변경하고 싶습니다. 대시보드로 돌아와서 변경할 수 있습니다.
![](/2022/Days/Images/Day46_Containers8.png)
또한 사이트에 새 게시물을 추가하려고 하는데, 아래에서 새 사이트의 최신 버전을 볼 수 있습니다.
![](/2022/Days/Images/Day46_Containers9.png)
### 정리 여부
이제 `docker-compose down` 명령을 사용하면 컨테이너가 삭제됩니다. 하지만 볼륨은 그대로 유지됩니다.
![](/2022/Days/Images/Day46_Containers10.png)
Docker Desktop에서 볼륨이 여전히 존재한다는 것을 확인할 수 있습니다.
![](/2022/Days/Images/Day46_Containers11.png)
그런 다음 다시 백업하려면 동일한 디렉토리 내에서 `docker up -d` 명령을 실행하면 애플리케이션을 다시 백업하고 실행할 수 있습니다.
![](/2022/Days/Images/Day46_Containers12.png)
그런 다음 브라우저에서 동일한 주소인 `http://localhost:8000`으로 이동하면 새 글과 테마 변경 사항이 모두 그대로 유지되는 것을 확인할 수 있습니다.
![](/2022/Days/Images/Day46_Containers13.png)
컨테이너와 해당 볼륨을 제거하려면 `docker-compose down --volumes`를 실행하면 볼륨도 제거됩니다.
![](/2022/Days/Images/Day46_Containers14.png)
이제 `docker-compose up -d`를 다시 사용하면 시작하지만, 이미지는 여전히 우리 시스템의 로컬에 있으므로 Docker Hub 리포지토리에서 다시 가져올 필요가 없습니다.
docker-compose와 그 기능에 대해 알아보기 시작했을 때 이것이 Kubernetes와 같은 컨테이너 오케스트레이션 도구와 어디에 위치하는지 혼란스러웠는데, 이 짧은 데모에서 우리가 한 모든 작업은 로컬 데스크톱 머신에서 실행 중인 WordPress와 DB가 있는 호스트 하나에 초점을 맞추고 있습니다. 여러 가상 머신이나 여러 물리적 머신이 없으며 애플리케이션의 요구 사항을 쉽게 확장 및 축소할 수도 없습니다.
다음 섹션에서는 Kubernetes를 다룰 예정이지만, 먼저 컨테이너에 대한 전반적인 내용을 며칠 더 살펴보겠습니다.
[Awesome-Compose](https://github.com/docker/awesome-compose)는 여러 통합이 있는 docker-compose 애플리케이션의 샘플을 위한 훌륭한 리소스입니다.
위의 리포지토리에는 단일 노드에 Elasticsearch, Logstash, Kibana(ELK)를 배포하는 훌륭한 예제가 있습니다.
[Containers 폴더](/2022/Days/Containers/elasticsearch-logstash-kibana/)에 파일을 업로드했습니다. 이 폴더가 로컬에 있으면 해당 폴더로 이동하여 `docker-compose up -d`를 사용하면 간단하게 설치할 수 있습니다.
![](/2022/Days/Images/Day46_Containers15.png)
그런 다음 `docker ps`로 실행 중인 컨테이너가 있는지 확인할 수 있습니다.
![](/2022/Days/Images/Day46_Containers16.png)
이제 각 컨테이너에 대한 브라우저를 열 수 있습니다:
![](/2022/Days/Images/Day46_Containers17.png)
모든 것을 제거하려면 `docker-compose down` 명령을 사용할 수 있습니다.
## 자료
- [TechWorld with Nana - Docker Tutorial for Beginners](https://www.youtube.com/watch?v=3c-iBn73dDE)
- [Programming with Mosh - Docker Tutorial for Beginners](https://www.youtube.com/watch?v=pTFZFxd4hOI)
- [Docker Tutorial for Beginners - What is Docker? Introduction to Containers](https://www.youtube.com/watch?v=17Bl31rlnRM&list=WL&index=128&t=61s)
- [WSL 2 with Docker getting started](https://www.youtube.com/watch?v=5RQbdMn04Oc)
- [Blog on getting started building a docker image](https://stackify.com/docker-build-a-beginners-guide-to-building-docker-/2022/Days/images/)
- [Docker documentation for building an image](https://docs.docker.com/develop/develop-/2022/Days/images/dockerfile_best-practices/)
- [YAML Tutorial: Everything You Need to Get Started in Minute](https://www.cloudbees.com/blog/yaml-tutorial-everything-you-need-get-started)
[Day 47](day47.md)에서 봐요!

139
2022/ko/Days/day47.md Normal file
View File

@ -0,0 +1,139 @@
---
title: '#90DaysOfDevOps - Docker Networking & Security - Day 47'
published: false
description: 90DaysOfDevOps - Docker Networking & Security
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1049078
---
## Docker 네트워킹 및 보안
지금까지 컨테이너 세션에서 우리는 작업을 수행했지만, 네트워킹 관점에서 작업이 어떻게 작동했는지 살펴보지 않았으며 보안에 대해서도 다루지 않았습니다.
### Docker 네트워킹 기본 사항
터미널을 열고, 컨테이너 네트워크를 구성하고 관리하기 위한 기본 명령어인 `docker network` 명령을 입력합니다.
아래에서 이 명령어를 사용하는 방법과 사용 가능한 모든 하위 명령을 확인할 수 있습니다. 새로운 네트워크를 생성하고, 기존 네트워크를 나열하고, 네트워크를 검사 및 제거할 수 있습니다.
![](/2022/Days/Images/Day47_Containers1.png)
설치 이후 우리가 가지고 있는 기존 네트워크를 살펴보기 위해 `docker network list` 명령을 사용하는 기본 Docker 네트워킹의 모습을 살펴봅시다.
각 네트워크는 고유한 ID와 이름을 갖습니다. 각 네트워크는 또한 단일 드라이버와 연결됩니다. "bridge" 네트워크와 "host" 네트워크는 각각의 드라이버와 이름이 동일합니다.
![](/2022/Days/Images/Day47_Containers2.png)
다음으로 `docker network inspect` 명령으로 네트워크를 더 자세히 살펴볼 수 있습니다.
`docker network inspect bridge`를 실행하면 특정 네트워크 이름에 대한 모든 구성 세부 정보를 얻을 수 있습니다. 여기에는 이름, ID, 드라이버, 연결된 컨테이너 등이 포함되며 보시다시피 훨씬 더 많은 정보를 확인할 수 있습니다.
![](/2022/Days/Images/Day47_Containers3.png)
### Docker: bridge 네트워킹
위에서 보았듯이 Docker Desktop을 표준 설치하면 `bridge`라는 사전 구축된 네트워크가 제공됩니다. `docker network list` 명령을 다시 실행하면 bridge라는 네트워크가 `bridge` 드라이버와 연결되어 있는 것을 볼 수 있습니다. 이름이 같다고 해서 같은 것은 아닙니다. 연결되었지만 같은 것은 아닙니다.
위의 출력은 또한 bridge 네트워크가 로컬로 범위가 지정되었음을 보여줍니다. 이는 네트워크가 이 Docker host에만 존재한다는 것을 의미합니다. 이는 bridge 드라이버를 사용하는 모든 네트워크에 해당되며, bridge 드라이버는 단일 host 네트워킹을 제공합니다.
bridge 드라이버로 생성된 모든 네트워크는 Linux bridge(virtual switch라고도 함)를 기반으로 합니다.
### 컨테이너 연결
기본적으로 bridge 네트워크는 새 컨테이너에 할당되므로 네트워크를 지정하지 않으면 모든 컨테이너가 bridge 네트워크에 연결됩니다.
`docker run -dt ubuntu sleep infinity` 명령으로 새 컨테이너를 생성해 보겠습니다.
위의 sleep 명령은 컨테이너를 백그라운드에서 계속 실행시켜서 컨테이너를 마음대로 다룰 수 있도록 합니다.
![](/2022/Days/Images/Day47_Containers4.png)
이제 `docker network inspect bridge`로 bridge 네트워크를 확인하면 네트워크를 지정하지 않았기 때문에 방금 배포한 것과 일치하는 컨테이너가 있는 것을 볼 수 있습니다.
![](/2022/Days/Images/Day47_Containers5.png)
`docker exec -it 3a99af449ca2 bash`를 사용하여 컨테이너를 자세히 살펴볼 수도 있습니다. 컨테이너 ID를 얻으려면 `docker ps`를 사용해야 합니다.
여기에서 이미지에는 핑할 항목이 없으므로, `apt-get update && apt-get install -y iputils-ping`을 실행한 다음 외부 인터페이스 주소를 핑합니다. `ping -c5 www.90daysofdevops.com`
![](/2022/Days/Images/Day47_Containers6.png)
이 문제를 해결하기 위해 `docker stop 3a99af449ca2`를 다시 실행하고 `docker ps`를 사용하여 컨테이너 ID를 찾을 수 있지만, 이렇게 하면 컨테이너가 제거됩니다.
### 외부 연결을 위한 NAT 구성하기
이 단계에서는 새 NGINX 컨테이너를 시작하고 Docker host의 포트 8080을 컨테이너 내부의 포트 80으로 매핑합니다. 즉, 포트 8080의 Docker host에 도달하는 트래픽은 컨테이너 내부의 포트 80으로 전달됩니다.
`docker run --name web1 -d -p 8080:80 nginx`를 실행하여 공식 NGINX 이미지를 기반으로 새 컨테이너를 시작합니다.
![](/2022/Days/Images/Day47_Containers7.png)
`docker ps`를 실행하여 컨테이너 상태와 포트 매핑을 검토합니다.
![](/2022/Days/Images/Day47_Containers8.png)
맨 위 줄은 NGINX를 실행하는 새 web1 컨테이너를 보여줍니다. 컨테이너가 실행 중인 명령과 포트 매핑에 주목하세요. - `0.0.0.0:8080->80/tcp`는 모든 host 인터페이스의 8080 포트를 web1 컨테이너 내부의 80 포트에 매핑합니다. 이 포트 매핑을 통해 외부 소스에서 컨테이너의 웹 서비스에 효과적으로 액세스할 수 있습니다(포트 8080의 Docker host IP 주소를 통해).
이제 실제 host에 대한 IP 주소가 필요하며, WSL 터미널로 이동하여 `IP addr` 명령을 사용하여 이를 수행할 수 있습니다.
![](/2022/Days/Images/Day47_Containers9.png)
그런 다음, 이 IP를 가지고 브라우저를 열어 `http://172.25.218.154:8080/`로 이동하면 IP가 다를 수 있습니다. 이렇게 하면 NGINX에 액세스할 수 있음을 확인할 수 있습니다.
![](/2022/Days/Images/Day47_Containers10.png)
이 사이트의 이 지침은 2017년 DockerCon에서 가져온 것이지만 오늘날에도 여전히 유효합니다. 그러나 나머지 연습은 Docker Swarm에 대한 것이므로 여기서는 다루지 않겠습니다. [Docker 네트워킹 - DockerCon 2017](https://github.com/docker/labs/tree/master/dockercon-us-2017/docker-networking)
### 컨테이너 보안
컨테이너는 전체 서버 구성에 비해 워크로드에 안전한 환경을 제공합니다. 컨테이너는 애플리케이션을 서로 격리된 훨씬 더 작고 느슨하게 결합된 구성 요소로 분할할 수 있는 기능을 제공하므로 전체적으로 공격 표면을 줄이는 데 도움이 됩니다.
하지만 시스템의 취약점을 공격하려는 해커로부터 자유롭지는 않습니다. 우리는 여전히 이 기술의 보안 결함을 이해하고 모범 사례를 유지해야 합니다.
### 루트 권한에서 벗어나기
지금까지 배포한 모든 컨테이너는 컨테이너 내 프로세스에 대한 루트 권한을 사용해 왔습니다. 즉, 컨테이너와 host 환경에 대한 모든 관리 액세스 권한이 있다는 뜻입니다. 이제 이러한 시스템이 오래 가동되지 않을 것이라는 것을 알고 있었습니다. 하지만 시작하고 실행하는 것이 얼마나 쉬운지 보셨을 것입니다.
프로세스에 몇 단계를 추가하여 루트 사용자가 아닌 사용자가 선호하는 모범 사례를 사용할 수 있도록 할 수 있습니다. dockerfile을 만들 때 사용자 계정을 만들 수 있습니다. 이 예제는 리포지토리의 컨테이너 폴더에서도 찾을 수 있습니다.
```dockerfile
# 공식 Ubuntu 18.04를 기본으로 사용하세요.
FROM ubuntu:18.04
RUN apt-get update && apt-get upgrade -y
RUN groupadd -g 1000 basicuser && useradd -r -u 1000 -g basicuser basicuser
USER basicuser
```
`docker run --user 1009 ubuntu` 명령은 dockerfile에 지정된 모든 사용자를 재정의합니다. 따라서 다음 예제에서는 컨테이너가 항상 권한이 가장 낮은 사용자 식별자 1009로 실행되며 권한 수준도 가장 낮습니다.
그러나 이 방법은 이미지 자체의 근본적인 보안 결함을 해결하지 못합니다. 따라서 컨테이너가 항상 안전하게 실행되도록 dockerfile에 루트 사용자가 아닌 사용자를 지정하는 것이 좋습니다.
### 비공개 레지스트리
조직에서 컨테이너 이미지의 비공개 레지스트리를 설정하면 원하는 곳에서 호스팅할 수 있거나 이를 위한 관리형 서비스도 있지만, 대체로 사용자와 팀이 사용할 수 있는 이미지를 완벽하게 제어할 수 있습니다.
Docker Hub는 기준선을 제시하는 데는 훌륭하지만, 이미지 게시자를 많이 신뢰해야 하는 기본적인 서비스만 제공합니다.
### 린 & 클린
보안과 관련되지는 않았지만, 전체적으로 언급했습니다. 그러나 애플리케이션에서 사용하지 않는 리소스가 컨테이너에 필요하지 않은 경우 컨테이너의 크기는 공격 표면 측면에서 보안에 영향을 미칠 수 있습니다.
또한 `latest` 이미지를 가져올 때 이미지에 많은 부풀림을 가져올 수 있기 때문에 이것이 저의 주요 관심사입니다. Docker Hub는 리포지토리에 있는 각 이미지의 압축 크기를 표시합니다.
`docker image`를 확인하면 이미지의 크기를 확인할 수 있는 좋은 명령어입니다.
![](/2022/Days/Images/Day47_Containers11.png)
## 자료
- [TechWorld with Nana - Docker Tutorial for Beginners](https://www.youtube.com/watch?v=3c-iBn73dDE)
- [Programming with Mosh - Docker Tutorial for Beginners](https://www.youtube.com/watch?v=pTFZFxd4hOI)
- [Docker Tutorial for Beginners - What is Docker? Introduction to Containers](https://www.youtube.com/watch?v=17Bl31rlnRM&list=WL&index=128&t=61s)
- [WSL 2 with Docker getting started](https://www.youtube.com/watch?v=5RQbdMn04Oc)
- [Blog on getting started building a docker image](https://stackify.com/docker-build-a-beginners-guide-to-building-docker-/2022/Days/images/)
- [Docker documentation for building an image](https://docs.docker.com/develop/develop-/2022/Days/images/dockerfile_best-practices/)
- [YAML Tutorial: Everything You Need to Get Started in Minute](https://www.cloudbees.com/blog/yaml-tutorial-everything-you-need-get-started)
[Day 48](day48.md)에서 봐요!

115
2022/ko/Days/day48.md Normal file
View File

@ -0,0 +1,115 @@
---
title: '#90DaysOfDevOps - Alternatives to Docker - Day 48'
published: false
description: 90DaysOfDevOps - Alternatives to Docker
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048807
---
## Docker의 대안
이 섹션의 맨 처음에 Docker를 사용할 것이라고 말씀드린 이유는 단순히 리소스 측면에서 매우 많고 커뮤니티가 매우 크기 때문이기도 하지만, 컨테이너를 대중화하기 위한 시도가 바로 여기에서 시작되었기 때문입니다. Docker의 역사와 그 탄생 과정을 살펴보는 것이 매우 유용하다고 생각합니다.
하지만 앞서 언급했듯이 Docker를 대체할 수 있는 다른 대안이 있습니다. Docker가 무엇이고 무엇을 다루었는지 생각해 보면 다음과 같습니다. 애플리케이션을 개발, 테스트, 배포 및 관리하기 위한 플랫폼입니다.
앞으로 실제로 사용할 수 있거나 앞으로 사용할 수 있는 Docker의 몇 가지 대안을 강조하고 싶습니다.
### Podman
Podman이란? Podman은 리눅스 시스템에서 OCI 컨테이너를 개발, 관리, 실행하기 위한 데몬이 없는 컨테이너 엔진입니다. 컨테이너는 루트로 실행하거나 루트리스 모드로 실행할 수 있습니다.
여기서는 Windows 관점에서 살펴볼 것이지만, Docker와 마찬가지로 Windows에서는 할 수 없는 기본 OS를 사용하기 때문에 가상화가 필요하지 않습니다.
Podman은 WSL2에서도 실행할 수 있지만, Docker Desktop의 경험만큼 매끄럽지는 않습니다. 컨테이너가 실행될 Linux VM에 연결할 수 있는 Windows 원격 클라이언트도 있습니다.
제가 사용하는 WSL2의 우분투는 20.04 릴리스입니다. 다음 단계에 따라 WSL 인스턴스에 Podman을 설치할 수 있습니다.
```Shell
echo "deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/xUbuntu_20.04/ /" |
sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
```
GPG 키를 추가합니다.
```Shell
curl -L "https://download.opensuse.org/repositories/devel:/kubic:\
/libcontainers:/stable/xUbuntu_20.04/Release.key" | sudo apt-key add -
```
`sudo apt-get update && sudo apt-get upgrade`명령으로 시스템 업데이트 및 업그레이드를 실행합니다. 마지막으로`sudo apt install podman`을 사용하여 podman을 설치할 수 있습니다.
이제 docker에 사용하던 것과 동일한 명령을 많이 사용할 수 있습니다. 다만 멋진 docker 데스크톱 UI가 없다는 점에 유의하세요. 아래에서 볼 수 있듯이 `podman images`를 사용했고 설치 후 아무것도 없으므로 `podman pull ubuntu`를 사용하여 우분투 컨테이너 이미지를 끌어 내렸습니다.
![](/2022/Days/Images/Day48_Containers1.png)
그런 다음 `podman run -dit ubuntu`와 `podman ps`를 사용하여 우분투 이미지를 실행하여 실행 중인 이미지를 확인할 수 있습니다.
![](/2022/Days/Images/Day48_Containers2.png)
그런 다음 해당 컨테이너에 들어가기 위해 `podman attach dazzling_darwin`을 실행하면 컨테이너 이름이 달라질 수 있습니다.
![](/2022/Days/Images/Day48_Containers3.png)
docker에서 podman으로 이동하는 경우, 설정 파일에 `alias docker=podman`으로 변경하여 docker로 실행하는 모든 명령이 podman을 사용하도록 하는 것도 일반적입니다.
### LXC
LXC는 사용자가 다시 여러 개의 격리된 리눅스 컨테이너 환경을 생성할 수 있게 해주는 컨테이너화 엔진입니다. Docker와 달리, LXC는 별도의 시스템 파일과 네트워킹 기능을 갖춘 여러 리눅스 머신을 생성하기 위한 하이퍼바이저 역할을 합니다. docker보다 먼저 등장했다가 docker의 단점으로 인해 잠시 사용되었습니다.
LXC는 docker만큼 가볍고 쉽게 배포할 수 있습니다.
### Containerd
독립형 컨테이너 런타임. Containerd는 단순성과 견고성은 물론 이식성까지 제공합니다. 이전에는 Docker 컨테이너 서비스의 일부로 실행되는 도구로 사용되다가 Docker가 구성 요소를 독립형 구성 요소로 분리하기로 결정하기 전까지 Containerd가 사용되었습니다.
클라우드 네이티브 컴퓨팅 재단의 프로젝트로, Kubernetes, Prometheus, CoreDNS와 같은 인기 컨테이너 도구와 같은 부류에 속합니다.
### 기타 Docker 도구
Rancher와 VirtualBox와 관련된 도구와 옵션도 언급할 수 있지만 다음 기회에 더 자세히 다루겠습니다.
[**Gradle**](https://gradle.org/)
- 빌드 스캔을 통해 팀은 공동으로 스크립트를 디버깅하고 모든 빌드의 이력을 추적할 수 있습니다.
- 실행 옵션을 통해 팀은 변경 사항이 입력될 때마다 작업이 자동으로 실행되도록 지속적으로 빌드할 수 있습니다.
- 사용자 지정 리포지토리 레이아웃을 통해 팀은 모든 파일 디렉토리 구조를 아티팩트 리포지토리로 취급할 수 있습니다.
[**Packer**](https://packer.io/)
- 여러 머신 이미지를 병렬로 생성하여 개발자의 시간을 절약하고 효율성을 높일 수 있습니다.
- 패커의 디버거를 사용하여 빌드를 쉽게 디버깅할 수 있어 실패를 검사하고 빌드를 다시 시작하기 전에 솔루션을 시험해 볼 수 있습니다.
- 플러그인을 통해 다양한 플랫폼을 지원하므로 팀이 빌드를 커스터마이징할 수 있습니다.
[**Logspout**](https://github.com/gliderlabs/logspout)
- 로깅 도구 - 이 도구의 사용자 지정 기능을 통해 팀은 동일한 로그를 여러 대상에 전송할 수 있습니다.
- 이 도구는 Docker 소켓에 액세스하기만 하면 되기 때문에 팀에서 파일을 쉽게 관리할 수 있습니다.
- 완전히 오픈 소스이며 배포가 쉽습니다.
[**Logstash**](https://www.elastic.co/products/logstash)
- Logstash의 플러그형 프레임워크를 사용해 파이프라인을 사용자 정의하세요.
- 분석을 위해 데이터를 쉽게 구문 분석하고 변환하여 비즈니스 가치를 제공할 수 있습니다.
- Logstash의 다양한 출력을 통해 원하는 곳으로 데이터를 라우팅할 수 있습니다.
[**Portainer**](https://www.portainer.io/)
- 미리 만들어진 템플릿을 활용하거나 직접 템플릿을 만들어 애플리케이션을 배포하세요.
- 팀을 생성하고 팀원에게 역할과 권한을 할당하세요.
- 도구의 대시보드를 사용하여 각 환경에서 무엇이 실행되고 있는지 파악하세요.
## 자료
- [TechWorld with Nana - Docker Tutorial for Beginners](https://www.youtube.com/watch?v=3c-iBn73dDE)
- [Programming with Mosh - Docker Tutorial for Beginners](https://www.youtube.com/watch?v=pTFZFxd4hOI)
- [Docker Tutorial for Beginners - What is Docker? Introduction to Containers](https://www.youtube.com/watch?v=17Bl31rlnRM&list=WL&index=128&t=61s)
- [WSL 2 with Docker getting started](https://www.youtube.com/watch?v=5RQbdMn04Oc)
- [Blog on getting started building a docker image](https://stackify.com/docker-build-a-beginners-guide-to-building-docker-images/)
- [Docker documentation for building an image](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/)
- [YAML Tutorial: Everything You Need to Get Started in Minute](https://www.cloudbees.com/blog/yaml-tutorial-everything-you-need-get-started)
- [Podman | Daemonless Docker | Getting Started with Podman](https://www.youtube.com/watch?v=Za2BqzeZjBk)
- [LXC - Guide to building an LXC Lab](https://www.youtube.com/watch?v=cqOtksmsxfg)
[Day 49](day49.md)에서 봐요!

235
2022/ko/Days/day49.md Normal file
View File

@ -0,0 +1,235 @@
---
title: '#90DaysOfDevOps - The Big Picture: Kubernetes - Day 49'
published: false
description: 90DaysOfDevOps - The Big Picture Kubernetes
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1049049
---
## 큰 그림: Kubernetes
지난 섹션에서 컨테이너에 대해 살펴보았는데, 컨테이너는 scale과 오케스트레이션만으로는 부족합니다. 우리가 할 수 있는 최선은 docker-compose를 사용하여 여러 컨테이너를 함께 불러오는 것입니다. 컨테이너 오케스트레이터인 Kubernetes를 사용하면 애플리케이션과 서비스의 부하에 따라 자동화된 방식으로 확장 및 축소할 수 있습니다.
플랫폼으로서 Kubernetes는 요구사항과 원하는 상태에 따라 컨테이너를 오케스트레이션할 수 있는 기능을 제공합니다. 이 섹션에서는 차세대 인프라로 빠르게 성장하고 있는 Kubernetes에 대해 다룰 예정입니다. 또한 데브옵스 관점에서 볼 때 Kubernetes는 기본적인 이해가 필요한 하나의 플랫폼일 뿐이며, 베어메탈, 가상화 및 대부분의 클라우드 기반 서비스도 이해해야 합니다. Kubernetes는 애플리케이션을 실행하기 위한 또 다른 옵션일 뿐입니다.
### 컨테이너 오케스트레이션이란 무엇인가요?
앞서 Kubernetes와 컨테이너 오케스트레이션에 대해 언급했는데, Kubernetes는 기술인 반면 컨테이너 오케스트레이션은 기술 이면의 개념 또는 프로세스입니다. 컨테이너 오케스트레이션 플랫폼은 Kubernetes뿐만 아니라 Docker Swarm, HashiCorp Nomad 등도 있습니다. 하지만 Kubernetes가 점점 더 강세를 보이고 있기 때문에 Kubernetes를 다루고 싶지만, Kubernetes만이 유일한 것은 아니라는 점을 말씀드리고 싶었습니다.
### Kubernetes란 무엇인가요?
Kubernetes를 처음 접하는 경우 가장 먼저 읽어야 할 것은 공식 문서입니다. 1년 조금 전에 Kubernetes에 대해 깊이 파고든 제 경험에 따르면 학습 곡선이 가파르게 진행될 것입니다. 가상화 및 스토리지에 대한 배경지식이 있는 저는 이것이 얼마나 벅차게 느껴질지 생각했습니다.
하지만 커뮤니티, 무료 학습 리소스 및 문서는 놀랍습니다. [Kubernetes.io](https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/)
Kubernetes는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식 가능하고 확장 가능한 오픈소스 플랫폼으로, 선언적 구성과 자동화를 모두 용이하게 합니다. 빠르게 성장하는 대규모 에코시스템이 있습니다. Kubernetes 서비스, 지원, 도구는 널리 이용 가능합니다.
위의 인용문에서 주목해야 할 중요한 점은 Kubernetes는 클라우드 네이티브 컴퓨팅 재단(CNCF)에 프로젝트를 기부한 Google로 거슬러 올라가는 풍부한 역사를 가진 오픈소스이며, 현재 오픈소스 커뮤니티와 대기업 벤더가 오늘날의 Kubernetes를 만드는 데 기여하면서 발전해 왔다는 점입니다.
위에서 컨테이너가 훌륭하다고 말씀드렸고 이전 섹션에서는 컨테이너와 컨테이너 이미지가 어떻게 클라우드 네이티브 시스템의 채택을 변화시키고 가속화했는지에 대해 이야기했습니다. 하지만 컨테이너만으로는 애플리케이션에 필요한 프로덕션 지원 환경을 제공할 수 없습니다. Kubernetes는 다음과 같은 이점을 제공합니다:
- **Services discovery 및 로드 밸런싱** Kubernetes는 DNS 이름 또는 IP 주소를 사용하여 컨테이너를 노출할 수 있습니다. 컨테이너에 대한 트래픽이 많을 경우, Kubernetes는 네트워크 트래픽을 로드 밸런싱하고 분산하여 배포가 안정적으로 이루어지도록 할 수 있습니다.
- **스토리지 오케스트레이션** Kubernetes를 사용하면 로컬 스토리지, 퍼블릭 클라우드 제공자 등 원하는 스토리지 시스템을 자동으로 마운트할 수 있습니다.
- **자동화된 롤아웃 및 롤백** 배포된 컨테이너에 대해 원하는 상태를 설명할 수 있으며, 제어된 속도로 실제 상태를 원하는 상태로 변경할 수 있습니다. 예를 들어, 배포를 위한 새 컨테이너를 생성하고, 기존 컨테이너를 제거하고, 모든 리소스를 새 컨테이너에 적용하도록 Kubernetes를 자동화할 수 있습니다.
- **자동 bin 패킹** 컨테이너화된 작업을 실행하는 데 사용할 수 있는 노드 클러스터를 Kubernetes에 제공하고, 각 컨테이너에 필요한 CPU와 메모리(RAM)의 양을 Kubernetes에 알려줍니다. Kubernetes는 리소스를 최대한 활용하기 위해 컨테이너를 노드에 맞출 수 있습니다.
- **자가 복구** Kubernetes는 장애가 발생한 컨테이너를 다시 시작하고, 컨테이너를 교체하고, 사용자 정의 상태 확인에 응답하지 않는 컨테이너를 죽이고, 제공할 준비가 될 때까지 클라이언트에게 알리지 않습니다.
- **비밀 및 구성 관리** Kubernetes를 사용하면 비밀번호, OAuth 토큰, SSH 키와 같은 민감한 정보를 저장하고 관리할 수 있습니다. 컨테이너 이미지를 다시 빌드하거나 스택 구성에 시크릿을 노출하지 않고도 시크릿 및 애플리케이션 구성을 배포하고 업데이트할 수 있습니다.
Kubernetes는 분산 시스템을 탄력적으로 실행할 수 있는 프레임워크를 제공합니다.
컨테이너 오케스트레이션은 컨테이너의 배포, 배치 및 라이프사이클을 관리합니다.
또한 다른 많은 책임도 있습니다:
- 클러스터 관리는 호스트를 하나의 대상으로 묶습니다.
- 스케줄 관리는 스케줄러를 통해 컨테이너를 노드 간에 배포합니다.
- Services discovery은 컨테이너의 위치를 파악하고 클라이언트 요청을 컨테이너에 분산합니다.
- 복제는 요청된 워크로드에 적합한 수의 노드와 컨테이너를 사용할 수 있도록 보장합니다.
- 상태 관리는 건강하지 않은 컨테이너와 노드를 감지하고 교체합니다.
### 주요 Kubernetes 구성 요소
Kubernetes는 애플리케이션을 프로비저닝, 관리 및 확장하기 위한 컨테이너 오케스트레이터입니다. 이를 사용하여 VM 또는 물리적 머신과 같은 워커 머신의 모음인 노드 클러스터에서 컨테이너화된 앱의 라이프사이클을 관리할 수 있습니다.
앱을 실행하려면 데이터베이스 연결, 방화벽 백엔드와의 통신, 키 보안에 도움이 되는 볼륨, 네트워크, 시크릿 등 다른 많은 리소스가 필요할 수 있습니다. Kubernetes를 사용하면 이러한 리소스를 앱에 추가할 수 있습니다. 앱에 필요한 인프라 리소스는 선언적으로 관리됩니다.
Kubernetes의 핵심 패러다임은 선언적 모델입니다. 사용자가 원하는 상태를 제공하면 Kubernetes가 이를 실현합니다. 인스턴스 다섯 개가 필요한 경우, 사용자가 직접 다섯 개의 인스턴스를 시작하지 않습니다. 대신 인스턴스 5개가 필요하다고 Kubernetes에 알려주면 Kubernetes가 자동으로 상태를 조정합니다. 인스턴스 중 하나에 문제가 발생하여 실패하더라도 Kubernetes는 여전히 사용자가 원하는 상태를 파악하고 사용 가능한 노드에 인스턴스를 생성합니다.
### 노드
#### 컨트롤 플레인
모든 Kubernetes 클러스터에는 컨트롤 플레인 노드가 필요하며, 컨트롤 플레인의 구성 요소는 클러스터에 대한 전역 결정(예: 스케줄링)을 내리고 클러스터 이벤트를 감지 및 응답합니다.
![](/2022/Days/Images/Day49_Kubernetes1.png)
#### 워커 노드
Kubernetes 워크로드를 실행하는 워커 머신입니다. 물리적(베어메탈) 머신이거나 가상 머신(VM)일 수 있습니다. 각 노드는 하나 이상의 pod를 호스트할 수 있습니다. Kubernetes 노드는 컨트롤 플레인에 의해 관리됩니다.
![](/2022/Days/Images/Day49_Kubernetes2.png)
다른 노드 유형이 있지만 여기서는 다루지 않겠습니다.
#### kubelet
클러스터의 각 노드에서 실행되는 에이전트입니다. 컨테이너가 pod에서 실행되고 있는지 확인합니다.
kubelet은 다양한 메커니즘을 통해 제공되는 일련의 PodSpec을 가져와서 해당 PodSpec에 설명된 컨테이너가 실행 중이고 정상인지 확인합니다. kubelet은 Kubernetes가 생성하지 않은 컨테이너는 관리하지 않습니다.
![](/2022/Days/Images/Day49_Kubernetes3.png)
#### kube-proxy
kube-proxy는 클러스터의 각 노드에서 실행되는 네트워크 프록시로, Kubernetes Services 개념의 일부를 구현합니다.
kube-proxy는 노드에서 네트워크 규칙을 유지 관리합니다. 이러한 네트워크 규칙은 클러스터 내부 또는 외부의 네트워크 세션에서 pod로의 네트워크 통신을 허용합니다.
운영 체제 패킷 필터링 계층이 있고 사용 가능한 경우, kube-proxy는 이를 사용합니다. 그렇지 않으면, kube-proxy는 트래픽 자체를 전달합니다.
![](/2022/Days/Images/Day49_Kubernetes4.png)
#### 컨테이너 런타임
컨테이너 런타임은 컨테이너 실행을 담당하는 소프트웨어입니다.
Kubernetes는 여러 컨테이너 런타임을 지원합니다: docker, containerd, CRI-O 그리고 Kubernetes CRI(Container Runtime Interface)의 모든 구현
![](/2022/Days/Images/Day49_Kubernetes5.png)
### 클러스터
클러스터는 노드의 그룹으로, 노드는 물리적 머신 또는 가상 머신이 될 수 있습니다. 각 노드에는 컨테이너 런타임(Docker)이 있으며 마스터 컨트롤러(나중에 자세히 설명)의 명령을 받는 에이전트인 kubelet 서비스와 다른 구성 요소(나중에 자세히 설명)에서 pod에 대한 연결을 프록시하는 데 사용되는 프록시도 실행됩니다.
고가용성으로 만들 수 있는 컨트롤 플레인에는 워커 노드와 비교하여 몇 가지 고유한 역할이 포함되며, 가장 중요한 것은 정보를 가져오거나 Kubernetes 클러스터로 정보를 푸시하기 위한 모든 통신이 이루어지는 곳인 kube API 서버입니다.
#### Kube API 서버
Kubernetes API 서버는 pod, 서비스, 응답 컨트롤러 등을 포함하는 API 오브젝트에 대한 데이터의 유효성을 검사하고 구성합니다. API 서버는 REST 작업을 수행하고 다른 모든 구성 요소가 상호 작용하는 클러스터의 공유 상태에 대한 프론트엔드를 제공합니다.
#### 스케줄러
Kubernetes 스케줄러는 노드에 pod를 할당하는 컨트롤 플레인 프로세스입니다. 스케줄러는 제약 조건과 사용 가능한 리소스에 따라 스케줄링 대기열에서 각 pod에 대해 유효한 배치가 되는 노드를 결정합니다. 그런 다음 스케줄러는 각 유효한 노드의 순위를 매기고 pod를 적합한 노드에 바인딩합니다.
#### 컨트롤러 매니저
Kubernetes 컨트롤러 매니저는 Kubernetes와 함께 제공되는 핵심 제어 루프를 임베드하는 daemon입니다. 로보틱스 및 자동화 애플리케이션에서 제어 루프는 시스템 상태를 조절하는 비종료 루프입니다. Kubernetes에서 컨트롤러는 API 서버를 통해 클러스터의 공유 상태를 감시하고 현재 상태를 원하는 상태로 이동시키기 위해 변경을 시도하는 제어 루프입니다.
#### etcd
모든 클러스터 데이터에 대한 Kubernetes의 백업 저장소로 사용되는 일관되고 가용성이 높은 키 값 저장소입니다.
![](/2022/Days/Images/Day49_Kubernetes6.png)
#### kubectl
CLI 관점에서 이를 관리하기 위해 kubectl이 있으며, kubectl은 API 서버와 상호 작용합니다.
Kubernetes 커맨드-라인 도구인 kubectl을 사용하면 Kubernetes 클러스터에 대해 명령을 실행할 수 있습니다. kubectl을 사용하여 애플리케이션을 배포하고, 클러스터 리소스를 검사 및 관리하고, 로그를 볼 수 있습니다.
![](/2022/Days/Images/Day49_Kubernetes7.png)
### Pods
pod는 논리적 애플리케이션을 구성하는 컨테이너 그룹입니다. 예를 들어, NodeJS 컨테이너와 MySQL 컨테이너를 실행하는 웹 애플리케이션이 있는 경우, 이 두 컨테이너는 모두 단일 pod에 위치하게 됩니다. 또한 pod는 공통 데이터 볼륨을 공유할 수 있으며 동일한 네트워킹 네임스페이스도 공유합니다. pod는 임시적이며 마스터 컨트롤러에 의해 위아래로 이동될 수 있다는 것을 기억합시다. Kubernetes는 레이블(이름-값) 개념을 통해 pod를 식별하는 간단하지만, 효과적인 수단을 사용합니다.
- pod는 컨테이너의 볼륨, 시크릿 및 구성을 처리합니다.
- pod는 임시적입니다. 죽으면 자동으로 재시작되도록 설계되었습니다.
- pod는 ReplicationSet에 의해 앱이 수평으로 스케일 될 때 복사됩니다. 각 pod는 동일한 컨테이너 코드를 실행합니다.
- pod는 워커 노드에서 실행됩니다.
![](/2022/Days/Images/Day49_Kubernetes8.png)
### Deployments
- pod를 실행하기로 결정할 수 있지만 죽으면 끝입니다.
- Deployments를 사용하면 pod가 지속적으로 실행될 수 있습니다.
- Deployments를 사용하면 다운타임 없이 실행 중인 앱을 업데이트할 수 있습니다.
- 또한, Deployments는 pod가 죽었을 때 재시작하는 전략을 지정합니다.
![](/2022/Days/Images/Day49_Kubernetes9.png)
### ReplicaSets
- Deployments는 ReplicaSets을 생성할 수도 있습니다.
- ReplicaSets은 앱이 원하는 수의 pod를 갖도록 보장합니다.
- ReplicaSets은 Deployments에 따라 pod를 생성하고 확장합니다.
- Deployments, ReplicaSets, pod는 배타적이지는 않지만 그렇게 될 수 있습니다.
### StatefulSets
- 앱의 상태에 대한 정보를 유지해야 하나요?
- 데이터베이스에는 상태가 필요합니다.
- StatefulSets의 pod는 서로 호환되지 않습니다.
- 각 pod에는 컨트롤러가 모든 스케줄링에 대해 유지하는 고유하고 영구적인 식별자가 있습니다.
![](/2022/Days/Images/Day49_Kubernetes10.png)
### DaemonSets
- DaemonSets은 연속 프로세스를 위한 것입니다.
- 노드당 하나의 pod를 실행합니다.
- 클러스터에 새로운 노드가 추가될 때마다 pod가 시작됩니다.
- 모니터링 및 로그 수집과 같은 백그라운드 작업에 유용합니다.
- 각 pod에는 컨트롤러가 모든 스케줄링에 대해 유지하는 고유하고 영구적인 식별자가 있습니다.
![](/2022/Days/Images/Day49_Kubernetes11.png)
### Services
- pod에 액세스하기 위한 단일 엔드포인트입니다.
- 클러스터와 최종적으로 pod 목록으로 트래픽을 라우팅하는 통합된 방법입니다.
- Services를 사용하면 아무 영향 없이 pod를 올리고 내릴 수 있습니다.
이것은 Kubernetes의 기본 구성 요소에 대한 간략한 개요와 참고 사항일 뿐이며, 이 지식을 바탕으로 스토리지와 Ingress 관련 몇 가지 다른 영역을 추가하여 애플리케이션을 개선할 수 있지만, Kubernetes 클러스터가 실행되는 위치에 대한 선택의 폭도 넓어집니다. 다음 세션에서는 스토리지와 관련된 몇 가지 세부 사항을 살펴보면서 Kubernetes 클러스터를 실행할 수 있는 위치에 대한 이러한 옵션에 중점을 두겠습니다.
![](/2022/Days/Images/Day49_Kubernetes12.png)
### Kubernetes 시리즈에서 다룰 내용
- Kubernetes 아키텍처
- Kubectl 커맨드
- Kubernetes YAML
- Kubernetes Ingress
- Kubernetes Services
- Helm 패키지 관리자
- 영속성 스토리지
- stateful 앱
## 자료
- [Kubernetes Documentation](https://kubernetes.io/docs/home/)
- [TechWorld with Nana - Kubernetes Tutorial for Beginners [FULL COURSE in 4 Hours]](https://www.youtube.com/watch?v=X48VuDVv0do)
- [TechWorld with Nana - Kubernetes Crash Course for Absolute Beginners](https://www.youtube.com/watch?v=s_o8dwzRlu4)
- [Kunal Kushwaha - Kubernetes Tutorial for Beginners | What is Kubernetes? Architecture Simplified!](https://www.youtube.com/watch?v=KVBON1lA9N8)
[Day 50](day50.md)에서 봐요!

79
2022/ko/Days/day50.md Normal file
View File

@ -0,0 +1,79 @@
---
title: '#90DaysOfDevOps - Choosing your Kubernetes platform - Day 50'
published: false
description: 90DaysOfDevOps - Choosing your Kubernetes platform
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1049046
---
## Kubernetes 플랫폼 선택하기
이 세션을 통해 몇 가지 플랫폼 또는 배포판이라는 용어를 사용하는 것이 더 적합할 수도 있는데, Kubernetes 세계에서 도전 과제 중 하나는 복잡성을 제거하는 것입니다.
Kubernetes 어려운 길은 아무것도 없는 상태에서 완전한 기능을 갖춘 Kubernetes 클러스터로 구축하는 방법을 안내하지만, 적어도 제가 이야기하는 사람들은 점점 더 많은 사람들이 이러한 복잡성을 제거하고 관리형 Kubernetes 클러스터를 실행하기를 원하고 있습니다. 문제는 비용이 더 많이 들지만, 관리형 서비스를 사용하면 기본 노드 아키텍처와 컨트롤 플레인 노드 관점에서 무슨 일이 일어나고 있는지 알아야 하지만 일반적으로 이에 액세스할 수 없는 경우 이점을 누릴 수 있다는 것입니다.
그런 다음 시스템을 사용할 수 있는 로컬 개발 배포판이 있고, 개발자가 의도한 플랫폼에서 앱을 실행할 수 있는 완전한 작업 환경을 갖출 수 있도록 로컬 버전의 Kubernetes를 실행할 수 있습니다.
이 모든 개념의 일반적인 기본은 모두 Kubernetes의 한 종류이므로 요구 사항에 맞게 워크로드를 필요한 곳으로 자유롭게 마이그레이션하고 이동할 수 있어야 한다는 것입니다.
또한 어떤 투자가 이루어졌는지에 따라 많은 선택이 달라질 것입니다. 개발자 경험에 대해서도 언급했지만, 노트북에서 실행되는 로컬 Kubernetes 환경 중 일부는 비용을 들이지 않고도 기술을 익힐 수 있는 훌륭한 환경입니다.
### 베어 메탈 클러스터
많은 사람들이 클러스터를 생성하기 위해 여러 대의 물리적 서버에서 바로 Linux OS를 실행하는 옵션을 선택할 수 있으며, Windows일 수도 있지만 Windows, 컨테이너 및 Kubernetes와 관련된 채택률에 대해서는 많이 듣지 못했습니다. 만약 여러분이 기업이고 물리적 서버를 구매하기로 CAPEX 결정을 내렸다면, Kubernetes 클러스터를 구축할 때 이 방법을 사용할 수 있지만, 관리 및 관리자 측면에서는 여러분이 직접 구축하고 모든 것을 처음부터 관리해야 한다는 것을 의미합니다.
### 가상화
테스트 및 학습 환경이나 엔터프라이즈급 Kubernetes 클러스터에 관계없이 가상화는 일반적으로 가상 머신을 스핀업하여 노드 역할을 하도록 한 다음 함께 클러스터링할 수 있는 훌륭한 방법입니다. 가상화의 기본 아키텍처, 효율성 및 속도를 활용할 수 있을 뿐만 아니라 기존 지출을 활용할 수 있습니다. 예를 들어 VMware는 가상 머신과 Kubernetes 모두를 위한 훌륭한 솔루션을 다양한 형태로 제공합니다.
제가 처음으로 구축한 Kubernetes 클러스터는 몇 개의 VM을 노드로 실행할 수 있는 오래된 서버에서 Microsoft Hyper-V를 사용한 가상화를 기반으로 구축되었습니다.
### 로컬 데스크톱 옵션
데스크톱이나 노트북에서 로컬 Kubernetes 클러스터를 실행하는 데는 몇 가지 옵션이 있습니다. 앞서 말했듯이 개발자는 비용이 많이 들거나 복잡한 클러스터를 여러 개 보유하지 않고도 앱이 어떻게 보일지 확인할 수 있습니다. 개인적으로 저는 이 클러스터를 많이 사용해 왔으며 특히 Minikube를 사용해 왔습니다. 여기에는 무언가를 시작하고 실행하는 방식을 바꾸는 몇 가지 훌륭한 기능과 애드온이 있습니다.
### Kubernetes Managed Services
가상화에 대해 언급했는데, 이는 로컬에서 하이퍼바이저를 통해 달성할 수 있지만 이전 섹션에서 퍼블릭 클라우드의 가상 머신을 활용하여 노드 역할을 할 수도 있다는 것을 알고 있습니다. 여기서 말하는 Kubernetes 관리형 서비스란 대규모 하이퍼스케일러뿐만 아니라 최종 사용자로부터 관리 및 제어 계층을 제거하여 최종 사용자로부터 제어 플레인을 제거하는 MSP에서 제공하는 서비스를 말하며, 이는 Amazon EKS, Microsoft AKS 및 Google Kubernetes Engine에서 일어나는 일입니다. (GKE)
### 압도적인 선택
선택의 폭이 넓다는 것은 좋지만, 위에 나열된 각 카테고리의 모든 옵션에 대해 자세히 살펴본 것은 아닙니다. 위의 옵션 외에도 Red Hat의 OpenShift가 있으며, 이 옵션은 위의 모든 주요 클라우드 제공업체에서 실행할 수 있으며 클러스터가 배포된 위치에 관계없이 관리자에게 최고의 전반적인 사용성을 제공할 수 있습니다.
제가 가상화 경로로 시작했다고 말씀드렸지만, 이는 제가 목적에 맞게 사용할 수 있는 물리적 서버에 액세스할 수 있었기 때문에 감사하게도 그 이후로는 더 이상 이 옵션을 사용할 수 없었습니다.
지금 제가 드리고 싶은 조언은 Minikube를 첫 번째 옵션으로 사용하거나 Kind(Docker의 Kubernetes)를 사용하라는 것이지만, Minikube는 애드온을 사용하고 빠르게 구축한 다음 완료되면 날려버릴 수 있고, 여러 클러스터를 실행할 수 있으며, 거의 모든 곳에서 실행할 수 있고, 크로스 플랫폼 및 하드웨어에 구애받지 않기 때문에 복잡성을 거의 추상화할 수 있는 몇 가지 추가적인 이점을 제공합니다.
저는 Kubernetes에 대해 배우면서 약간의 여정을 거쳤기 때문에 플랫폼 선택과 구체적인 내용은 여기서는 플랫폼인 Kubernetes와 실행 가능한 위치에 대한 이해를 돕기 위해 시도했던 옵션들을 나열해 보겠습니다. 아래 블로그 포스팅을 다시 한번 살펴보고 블로그 게시물에 링크되어 있는 것보다 여기에 더 많이 소개할 수 있도록 하겠습니다.
- [Kubernetes playground – How to choose your platform](https://vzilla.co.uk/vzilla-blog/building-the-home-lab-kubernetes-playground-part-1)
- [Kubernetes playground – Setting up your cluster](https://vzilla.co.uk/vzilla-blog/building-the-home-lab-kubernetes-playground-part-2)
- [Getting started with Amazon Elastic Kubernetes Service (Amazon EKS)](https://vzilla.co.uk/vzilla-blog/getting-started-with-amazon-elastic-kubernetes-service-amazon-eks)
- [Getting started with Microsoft Azure Kubernetes Service (AKS)](https://vzilla.co.uk/vzilla-blog/getting-started-with-microsoft-azure-kubernetes-service-aks)
- [Getting Started with Microsoft AKS – Azure PowerShell Edition](https://vzilla.co.uk/vzilla-blog/getting-started-with-microsoft-aks-azure-powershell-edition)
- [Getting started with Google Kubernetes Service (GKE)](https://vzilla.co.uk/vzilla-blog/getting-started-with-google-kubernetes-service-gke)
- [Kubernetes, How to – AWS Bottlerocket + Amazon EKS](https://vzilla.co.uk/vzilla-blog/kubernetes-how-to-aws-bottlerocket-amazon-eks)
- [Getting started with CIVO Cloud](https://vzilla.co.uk/vzilla-blog/getting-started-with-civo-cloud)
- [Minikube - Kubernetes Demo Environment For Everyone](https://vzilla.co.uk/vzilla-blog/project_pace-kasten-k10-demo-environment-for-everyone)
### Kubernetes 시리즈에서 다룰 내용
- Kubernetes 아키텍처
- Kubectl 커맨드
- Kubernetes YAML
- Kubernetes Ingress
- Kubernetes Services
- Helm 패키지 관리자
- 영속성 스토리지
- stateful 앱
## 자료
- [Kubernetes Documentation](https://kubernetes.io/docs/home/)
- [TechWorld with Nana - Kubernetes Tutorial for Beginners [FULL COURSE in 4 Hours]](https://www.youtube.com/watch?v=X48VuDVv0do)
- [TechWorld with Nana - Kubernetes Crash Course for Absolute Beginners](https://www.youtube.com/watch?v=s_o8dwzRlu4)
- [Kunal Kushwaha - Kubernetes Tutorial for Beginners | What is Kubernetes? Architecture Simplified!](https://www.youtube.com/watch?v=KVBON1lA9N8)
[Day 51](day51.md)에서 봐요!

178
2022/ko/Days/day51.md Normal file
View File

@ -0,0 +1,178 @@
---
title: '#90DaysOfDevOps - Deploying your first Kubernetes Cluster - Day 51'
published: false
description: 90DaysOfDevOps - Deploying your first Kubernetes Cluster
tags: 'DevOps, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048778
---
## 첫 번째 Kubernetes 클러스터 배포하기
이 글에서는 Minikube를 사용하여 로컬 머신에서 Kubernetes 클러스터를 시작하고 실행해 보겠습니다. 이렇게 하면 나머지 Kubernetes 섹션을 위한 기본 Kubernetes 클러스터가 제공되지만, 나중에 VirtualBox에서도 Kubernetes 클러스터를 배포하는 방법을 살펴볼 것입니다. 퍼블릭 클라우드에서 관리형 Kubernetes 클러스터를 스핀업하는 대신 이 방법을 선택한 이유는 무료 티어를 사용하더라도 비용이 들기 때문이며, 이전 섹션 [Day 50](day50.md)에서 해당 환경을 스핀업하려는 경우 몇 가지 블로그를 공유한 바 있습니다.
### Minikube란?
> "Minikube는 macOS, Linux, Windows에서 로컬 Kubernetes 클러스터를 빠르게 설정합니다. 우리는 애플리케이션 개발자와 새로운 Kubernetes 사용자를 돕는 데 주력하고 있습니다."
위에 해당되지 않을 수도 있지만, 저는 Minikube가 Kubernetes 방식으로 무언가를 테스트하고 싶을 때 앱을 쉽게 배포할 수 있고 몇 가지 놀라운 애드온이 있다는 것을 알게 되었으며, 이 글에서도 다룰 것입니다.
우선, 워크스테이션 OS에 관계없이 Minikube를 실행할 수 있습니다. 먼저 [프로젝트 페이지](https://minikube.sigs.k8s.io/docs/start/)로 이동합니다. 첫 번째 옵션은 설치 방법을 선택하는 것입니다. 저는 이 방법을 사용하지 않았지만, 여러분은 제가 사용하는 방법과 다른 방법을 선택할 수 있습니다(곧 소개할 예정입니다).
아래에 언급된 "Container or virtual machine managers, such as Docker, Hyper kit, Hyper-V, KVM, Parallels, Podman, VirtualBox, or VMware"가 있어야 한다고 명시되어 있는데, 이것이 Minikube가 실행되는 곳이고 쉬운 옵션이며 저장소에 명시되어 있지 않은 한 저는 Docker를 사용하고 있습니다. 그리고 [여기](https://docs.docker.com/get-docker/)에서 시스템에 Docker를 설치할 수 있습니다.
![](/2022/Days/Images/Day51_Kubernetes1.png)
### Minikube 및 기타 전제조건을 설치하는 방법...
저는 한동안 arkade를 사용하여 모든 Kubernetes 도구와 CLI를 설치해왔는데, arkade를 시작하기 위한 설치 단계는 이 [github 저장소](https://github.com/alexellis/arkade)에서 확인할 수 있습니다. 설치가 필요한 다른 블로그 게시물에서도 언급했습니다. arkade get을 누른 다음 툴이나 CLI를 사용할 수 있는지 확인하는 것만으로도 간단합니다. 리눅스 섹션에서 패키지 관리자와 소프트웨어를 얻는 프로세스에 대해 이야기했는데, arkade는 모든 앱과 Kubernetes용 CLI를 위한 마켓플레이스라고 생각하시면 됩니다. 시스템에서 사용할 수 있는 매우 편리한 작은 도구로, GO로 작성되어 크로스 플랫폼을 지원합니다.
![](/2022/Days/Images/Day51_Kubernetes2.png)
arkade 내에서 사용 가능한 긴 앱 목록의 일부로 Minikube도 그중 하나이므로 간단한 `arkade get minikube` 명령으로 바이너리를 다운로드하고 이제 바로 사용할 수 있습니다.
![](/2022/Days/Images/Day51_Kubernetes3.png)
또한 도구의 일부로 kubectl이 필요하므로 arkade를 통해서도 얻을 수 있으며, 위에서 언급한 curl 명령의 일부로 Minikube 문서에 나와 있다고 생각합니다. 이 포스트의 뒷부분에서 kubectl에 대해 더 자세히 다루겠습니다.
### Kubernetes 클러스터 시작 및 실행하기
이 특정 섹션에서는 로컬 머신에서 Kubernetes 클러스터를 시작하고 실행할 때 사용할 수 있는 옵션에 대해 다루고자 합니다. 다음 명령을 실행하기만 하면 사용할 수 있는 클러스터가 스핀업됩니다.
커맨드라인에 minikube가 사용되며, 모든 설치가 완료되면 `minikube start`를 실행하여 첫 번째 Kubernetes 클러스터를 배포할 수 있습니다. 아래에서 중첩된 가상화 노드를 실행할 위치에 대한 기본값이 Docker 드라이버인 것을 확인할 수 있습니다. 게시물의 시작 부분에서 사용 가능한 다른 옵션에 대해 언급했는데, 다른 옵션은 이 로컬 Kubernetes 클러스터의 모양을 확장하고자 할 때 도움이 됩니다.
이 인스턴스에서는 단일 Minikube 클러스터가 단일 docker 컨테이너로 구성되며, 이 컨테이너에는 컨트롤 플레인 노드와 워커 노드가 하나의 인스턴스에 포함됩니다. 일반적으로는 이러한 노드를 분리합니다. 다음 섹션에서는 아직 홈 랩 유형의 Kubernetes 환경이지만 프로덕션 아키텍처에 조금 더 가까운 환경을 살펴볼 것입니다.
![](/2022/Days/Images/Day51_Kubernetes4.png)
지금까지 몇 번 언급했지만, 저는 사용 가능한 애드온 때문에 Minikube를 좋아하는데, 처음부터 필요한 모든 애드온을 포함한 간단한 명령으로 클러스터를 배포할 수 있기 때문에 매번 동일한 설정을 배포하는 데 도움이 됩니다.
아래에서 이러한 애드온 목록을 볼 수 있는데, 저는 일반적으로 `CSI-host path-driver`와 `volumesnapshots` 애드온을 사용하지만, 아래에서 긴 목록을 볼 수 있습니다. 물론 이러한 애드온은 나중에 Kubernetes 섹션에서 다루겠지만 일반적으로 Helm을 사용하여 배포할 수 있지만 훨씬 더 간단해진다.
![](/2022/Days/Images/Day51_Kubernetes5.png)
또한 프로젝트에서 몇 가지 추가 구성을 정의하고 있는데, apiserver는 임의의 API 포트 대신 6433으로 설정하고 container runtime도 containerd로 정의하고 있지만 기본값은 docker이고 CRI-O도 사용할 수 있습니다. 또한 특정 Kubernetes 버전도 설정하고 있습니다.
![](/2022/Days/Images/Day51_Kubernetes6.png)
이제 Minikube를 사용하여 첫 번째 Kubernetes 클러스터를 배포할 준비가 되었습니다. 클러스터와 상호 작용하려면 `kubectl`도 필요하다고 앞서 언급했습니다. arkade를 사용하여 `arkade get kubectl` 명령으로 kubectl을 설치할 수 있습니다.
![](/2022/Days/Images/Day51_Kubernetes7.png)
또는 다음에서 크로스 플랫폼으로 다운로드할 수 있습니다.
- [리눅스](https://kubernetes.io/docs/tasks/tools/install-kubectl-linux)
- [macOS](https://kubernetes.io/docs/tasks/tools/install-kubectl-macos)
- [윈도우](https://kubernetes.io/docs/tasks/tools/install-kubectl-windows)
kubectl을 설치했으면 `kubectl get nodes`와 같은 간단한 명령으로 클러스터와 상호 작용할 수 있습니다.
![](/2022/Days/Images/Day51_Kubernetes8.png)
### kubectl이란?
이제 Minikube와 Kubernetes 클러스터를 모두 설치하고 실행 중이며, Minikube에 대해서는 최소한 Minikube가 무엇을 하는지에 대해 설명했지만, kubectl이 무엇이고 어떤 역할을 하는지에 대해서는 설명하지 않았습니다.
kubectl은 Kubernetes 클러스터와 상호 작용하는 데 사용되거나 상호 작용할 수 있게 해주는 클리어로, 여기서는 Minikube 클러스터와 상호 작용하는 데 사용하고 있지만 퍼블릭 클라우드 전반의 엔터프라이즈 클러스터와 상호 작용하는 데도 kubectl을 사용할 수 있습니다.
우리는 애플리케이션을 배포하고 클러스터 리소스를 검사 및 관리하기 위해 kubectl을 사용합니다. 훨씬 더 자세한 개요는 Kubernetes [공식 문서](https://kubernetes.io/docs/reference/kubectl/overview/)에서 확인할 수 있습니다.
kubectl은 이전 포스트에서 간략하게 다룬 컨트롤 플레인 노드에 있는 API 서버와 상호작용합니다.
### kubectl 치트 시트
공식 문서와 함께, 필자는 kubectl 명령어를 찾을 때 [이 페이지](https://unofficial-kubernetes.readthedocs.io/en/latest/)를 항상 열어두는 것을 추천합니다.
| Listing Resources | |
| ------------------------ | ------------------------------------------ |
| kubectl get nodes | 클러스터의 모든 노드 나열 |
| kubectl get namespaces | 클러스터의 모든 네임스페이스 나열 |
| kubectl get pods | 기본 네임스페이스 클러스터에 모든 pod 나열 |
| kubectl get pods -n name | "이름" 네임스페이스에 모든 pod를 나열 |
| Creating Resources | |
| ----------------------------- | ------------------------------------------ |
| kubectl create namespace name | "name"이라는 네임스페이스를 생성 |
| kubectl create -f [filename] | JSON 또는 YAML 파일에서 리소스를 다시 생성 |
| Editing Resources | |
| ---------------------------- | ------------- |
| kubectl edit svc/servicename | 서비스를 편집 |
| More detail on Resources | |
| ------------------------ | ------------------------------------- |
| kubectl describe nodes | 원하는 수의 리소스 상태를 자세히 표시 |
| Delete Resources | |
| ------------------ | --------------------------------------------------------- |
| kubectl delete pod | 리소스를 제거할 수 있으며, 이는 stdin 또는 파일에서 제거. |
예를 들어 `-n`은 `namespace`의 줄임말로, 명령을 입력하기 쉬울 뿐만 아니라 스크립트를 작성할 때 훨씬 더 깔끔한 코드를 만들 수 있습니다.
| Short name | Full name |
| ---------- | -------------------------- |
| csr | certificatesigningrequests |
| cs | componentstatuses |
| cm | configmaps |
| ds | daemonsets |
| deploy | deployments |
| ep | endpoints |
| ev | events |
| hpa | horizontalpodautoscalers |
| ing | ingresses |
| limits | limitranges |
| ns | namespaces |
| no | nodes |
| pvc | persistentvolumeclaims |
| pv | persistentvolumes |
| po | pods |
| pdb | poddisruptionbudgets |
| psp | podsecuritypolicies |
| rs | replicasets |
| rc | replicationcontrollers |
| quota | resourcequotas |
| sa | serviceaccounts |
| svc | services |
마지막으로 추가하고 싶은 것은 데이터 서비스를 표시하기 위해 데모 환경을 빠르게 스핀업하고 Kasten K10으로 이러한 워크로드를 보호하기 위해 Minikube와 관련된 또 다른 프로젝트를 만들었습니다. [Project Pace](https://github.com/MichaelCade/project_pace)는 여기에서 찾을 수 있으며 여러분의 피드백이나 상호 작용을 원하며 Minikube 클러스터를 배포하고 다양한 데이터 서비스 애플리케이션을 만드는 몇 가지 자동화된 방법을 표시하거나 포함합니다.
다음에는 VirtualBox를 사용하여 여러 노드를 가상 머신에 배포하는 방법을 살펴보겠지만, Linux 섹션에서 vagrant를 사용하여 머신을 빠르게 스핀업하고 원하는 방식으로 소프트웨어를 배포했던 것처럼 여기에서도 쉽게 진행할 것입니다.
어제 포스트에 배포 중인 다양한 Kubernetes 클러스터에 대해 제가 수행한 워크스루 블로그인 이 목록을 추가했습니다.
- [Kubernetes playground – How to choose your platform](https://vzilla.co.uk/vzilla-blog/building-the-home-lab-kubernetes-playground-part-1)
- [Kubernetes playground – Setting up your cluster](https://vzilla.co.uk/vzilla-blog/building-the-home-lab-kubernetes-playground-part-2)
- [Getting started with Amazon Elastic Kubernetes Service (Amazon EKS)](https://vzilla.co.uk/vzilla-blog/getting-started-with-amazon-elastic-kubernetes-service-amazon-eks)
- [Getting started with Microsoft Azure Kubernetes Service (AKS)](https://vzilla.co.uk/vzilla-blog/getting-started-with-microsoft-azure-kubernetes-service-aks)
- [Getting Started with Microsoft AKS – Azure PowerShell Edition](https://vzilla.co.uk/vzilla-blog/getting-started-with-microsoft-aks-azure-powershell-edition)
- [Getting started with Google Kubernetes Service (GKE)](https://vzilla.co.uk/vzilla-blog/getting-started-with-google-kubernetes-service-gke)
- [Kubernetes, How to – AWS Bottlerocket + Amazon EKS](https://vzilla.co.uk/vzilla-blog/kubernetes-how-to-aws-bottlerocket-amazon-eks)
- [Getting started with CIVO Cloud](https://vzilla.co.uk/vzilla-blog/getting-started-with-civo-cloud)
- [Minikube - Kubernetes Demo Environment For Everyone](https://vzilla.co.uk/vzilla-blog/project_pace-kasten-k10-demo-environment-for-everyone)
- [Minikube - Deploy Minikube Using Vagrant and Ansible on VirtualBox](https://medium.com/techbeatly/deploy-minikube-using-vagrant-and-ansible-on-virtualbox-infrastructure-as-code-2baf98188847)
### Kubernetes 시리즈에서 다룰 내용
아래에 언급된 내용 중 일부를 다루기 시작했지만, 내일 두 번째 클러스터 배포를 통해 더 많은 실습을 한 후 클러스터에 애플리케이션 배포를 시작할 수 있습니다.
- Kubernetes 아키텍처
- Kubectl 커맨드
- Kubernetes YAML
- Kubernetes Ingress
- Kubernetes Services
- Helm 패키지 관리자
- 영속성 스토리지
- stateful 앱
## 자료
사용하신 무료 리소스가 있다면 리포지토리에 PR을 통해 여기에 추가해 주시면 기꺼이 포함시켜드리겠습니다.
- [Kubernetes Documentation](https://kubernetes.io/docs/home/)
- [TechWorld with Nana - Kubernetes Tutorial for Beginners [FULL COURSE in 4 Hours]](https://www.youtube.com/watch?v=X48VuDVv0do)
- [TechWorld with Nana - Kubernetes Crash Course for Absolute Beginners](https://www.youtube.com/watch?v=s_o8dwzRlu4)
- [Kunal Kushwaha - Kubernetes Tutorial for Beginners | What is Kubernetes? Architecture Simplified!](https://www.youtube.com/watch?v=KVBON1lA9N8)
- [Techbeatly - Deploy Minikube Using Vagrant and Ansible on VirtualBox](https://www.youtube.com/watch?v=xPLQqHbp9BM&t=371s)
[Day 52](day52.md)에서 봐요!

182
2022/ko/Days/day52.md Normal file
View File

@ -0,0 +1,182 @@
---
title: '#90DaysOfDevOps - Setting up a multinode Kubernetes Cluster - Day 52'
published: false
description: 90DaysOfDevOps - Setting up a multinode Kubernetes Cluster
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1049050
---
## 멀티노드 Kubernetes 클러스터 설정하기
이 제목을 "Vagrant로 멀티노드 Kubernetes 클러스터 설정하기"로 하고 싶었지만, 너무 길 것 같았습니다!
어제 세션에서는 멋진 프로젝트를 사용하여 첫 번째 Kubernetes 클러스터를 배포하고 Kubernetes를 사용할 때 접하게 될 가장 중요한 CLI 도구(kubectl)를 조금 실습해 보았습니다.
여기서는 VirtualBox를 기본으로 사용하지만, 지난번 리눅스 섹션에서 Vagrant에 대해 이야기할 때 언급했듯이 지원되는 모든 하이퍼바이저 또는 가상화 도구를 사용할 수 있습니다. 리눅스 섹션에서 우분투 머신을 배포한 것은 [Day 14](day14.md)였습니다.
### Vagrant에 대한 간략한 요약
Vagrant는 가상 머신의 라이프사이클을 관리하는 CLI 유틸리티입니다. vSphere, Hyper-v, Virtual Box, Docker 등 다양한 플랫폼에서 가상 머신을 스핀업 및 스핀다운하는 데 Vagrant를 사용할 수 있습니다. 다른 공급업체도 있지만 여기서는 Virtual Box를 사용하고 있으므로 계속 사용하겠습니다.
이 [블로그 및 리포지토리](https://devopscube.com/kubernetes-cluster-vagrant/)를 기준으로 하여 구성을 안내해 드리겠습니다. 하지만 Kubernetes 클러스터를 처음 배포하는 경우라면 수동으로 이 작업을 수행하는 방법도 살펴보고 최소한 어떤 모습인지 알고 계실 것을 권해드리고 싶습니다. Kubernetes는 릴리스될 때마다 더욱 효율적으로 개선되고 있다고 말씀드리고 싶습니다. 저는 이것을 VMware와 ESX 시절에 비유하자면, ESX 서버 3대를 배포하는 데 적어도 하루는 필요했지만, 지금은 한 시간 안에 이를 실행할 수 있습니다. 저희는 Kubernetes와 관련해서는 그 방향으로 나아가고 있습니다.
### Kubernetes 랩 환경
환경을 구축하는 데 사용할 vagrantfile을 [Kubernetes 폴더](/2022/Days/Kubernetes)에 업로드했습니다. 이 파일을 잡고 터미널에서 이 디렉토리로 이동합니다. 저는 다시 Windows를 사용하므로 PowerShell을 사용하여 vagrant로 워크스테이션 명령을 수행하겠습니다. vagrant가 없는 경우 어제 Minikube 및 기타 도구를 설치할 때 다룬 arkade를 사용할 수 있습니다. 간단한 명령어인 `arkade get vagrant`를 실행하면 최신 버전의 vagrant를 다운로드하여 설치할 수 있습니다.
디렉토리에 들어가면 `vagrant up`을 실행하고 모든 것이 올바르게 구성되었다면 터미널에 다음과 같은 킥오프가 표시됩니다.
![](/2022/Days/Images/Day52_Kubernetes1.png)
터미널에서 몇 가지 단계가 진행되는 것을 볼 수 있지만, 그동안 우리가 여기서 무엇을 빌드하고 있는지 살펴봅시다.
![](/2022/Days/Images/Day52_Kubernetes2.png)
위에서 보면 3개의 가상 머신을 빌드하고 컨트롤 플레인 노드와 두 개의 워커 노드가 있다는 것을 알 수 있습니다. [Day 49](day49.md)로 돌아가면 이미지에서 볼 수 있는 이러한 영역에 대한 설명이 더 있습니다.
또한 이미지에서는 클러스터 외부에서 kubectl 액세스가 발생하여 해당 kube apiserver에 도달하는 것으로 표시되어 있지만, 실제로는 vagrant 프로비저닝의 일부로 각 노드 내에서 클러스터에 액세스할 수 있도록 각 노드에 kubectl을 배포하고 있습니다.
이 실습을 구축하는 과정은 설정에 따라 5분에서 30분 정도 걸릴 수 있습니다.
곧 스크립트에 대해서도 다룰 예정이지만, 배포의 일부로 3개의 스크립트를 호출하는 vagrant 파일을 보면 클러스터가 실제로 생성되는 곳이라는 것을 알 수 있습니다. Vagrant boxes를 사용하여 가상 머신과 OS 설치를 배포하는 것이 얼마나 쉬운지 살펴보았지만, 배포 프로세스의 일부로 셸 스크립트를 실행할 수 있는 기능이 있다는 것은 이러한 실습 빌드 아웃 자동화와 관련하여 매우 흥미로운 부분입니다.
완료되면 터미널에서 노드 중 하나에 `vagrant ssh master`로 접속하면 액세스할 수 있으며, 기본 사용자 이름과 비밀번호는 `vagrant/vagrant`입니다.
원하는 경우 `vagrant ssh node01` 및 `vagrant ssh node02`를 사용하여 작업자 노드에 액세스할 수도 있습니다.
![](/2022/Days/Images/Day52_Kubernetes3.png)
이제 새 클러스터의 위 노드 중 하나에서 `kubectl get nodes`를 실행하여 3노드 클러스터와 그 상태를 확인할 수 있습니다.
![](/2022/Days/Images/Day52_Kubernetes4.png)
이 시점에서, 컨트롤 플레인 노드 1개와 워커 노드 2개로 구성된 3노드 클러스터가 실행되고 있습니다.
### Vagrant 파일 및 셸 스크립트 연습
vagrantfile을 살펴보면 여러 작업자 노드, VirtualBox 내의 브리지 네트워크에 대한 네트워킹 IP 주소, 그리고 일부 이름 지정을 정의하고 있음을 알 수 있습니다. 또한 특정 호스트에서 실행하려는 일부 스크립트를 호출하고 있음을 알 수 있습니다.
```shell
NUM_WORKER_NODES=2
IP_NW="10.0.0."
IP_START=10
Vagrant.configure("2") do |config|
config.vm.provision "shell", inline: <<-SHELL
apt-get update -y
echo "$IP_NW$((IP_START)) master-node" >> /etc/hosts
echo "$IP_NW$((IP_START+1)) worker-node01" >> /etc/hosts
echo "$IP_NW$((IP_START+2)) worker-node02" >> /etc/hosts
SHELL
config.vm.box = "bento/ubuntu-21.10"
config.vm.box_check_update = true
config.vm.define "master" do |master|
master.vm.hostname = "master-node"
master.vm.network "private_network", ip: IP_NW + "#{IP_START}"
master.vm.provider "virtualbox" do |vb|
vb.memory = 4048
vb.cpus = 2
vb.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]
end
master.vm.provision "shell", path: "scripts/common.sh"
master.vm.provision "shell", path: "scripts/master.sh"
end
(1..NUM_WORKER_NODES).each do |i|
config.vm.define "node0#{i}" do |node|
node.vm.hostname = "worker-node0#{i}"
node.vm.network "private_network", ip: IP_NW + "#{IP_START + i}"
node.vm.provider "virtualbox" do |vb|
vb.memory = 2048
vb.cpus = 1
vb.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]
end
node.vm.provision "shell", path: "scripts/common.sh"
node.vm.provision "shell", path: "scripts/node.sh"
end
end
end
```
실행 중인 스크립트를 분석해 보겠습니다. 특정 노드에서 실행할 세 개의 스크립트가 위의 VAGRANTFILE에 나열되어 있습니다.
`master.vm.provision "shell", path: "scripts/common.sh"`
위의 스크립트는 노드를 준비하는 데 초점을 맞출 것이며, 3개의 노드 모두에서 실행될 것이며, 기존의 모든 Docker 구성 요소를 제거하고 Docker와 ContainerD는 물론 kubeadm, kubelet 및 kubectl을 다시 설치합니다. 이 스크립트는 또한 시스템의 기존 소프트웨어 패키지도 업데이트합니다.
`master.vm.provision "shell", path: "scripts/master.sh"`
master.sh 스크립트는 컨트롤 플레인 노드에서만 실행되며, 이 스크립트는 kubeadm 커맨드를 사용하여 Kubernetes 클러스터를 생성합니다. 또한 이 클러스터에 대한 액세스를 위한 구성 컨텍스트도 준비할 것이며, 이는 다음에 다룰 것입니다.
`node.vm.provision "shell", path: "scripts/node.sh"`
이것은 단순히 마스터가 생성한 구성을 가져와서 우리 노드를 Kubernetes 클러스터에 추가하는 것이며, 이 추가 프로세스는 다시 kubeadm과 config 폴더에서 찾을 수 있는 다른 스크립트를 사용합니다.
### Kubernetes 클러스터에 액세스하기
이제 두 개의 클러스터가 배포되었습니다. 이전 섹션에서 배포한 Minikube 클러스터와 방금 VirtualBox에 배포한 새로운 3노드 클러스터가 있습니다.
또한 vagrant를 실행한 머신에서도 액세스할 수 있는 구성 파일에는 워크스테이션에서 클러스터에 액세스하는 방법이 포함되어 있습니다.
이를 보여드리기 전에 컨텍스트에 대해 말씀드리겠습니다.
![](/2022/Days/Images/Day52_Kubernetes5.png)
컨텍스트가 중요하며, 데스크톱이나 노트북에서 Kubernetes 클러스터에 액세스할 수 있는 기능이 필요합니다. 다양한 옵션이 존재하며 사람들은 각기 다른 운영 체제를 일상적으로 사용합니다.
기본적으로, Kubernetes CLI 클라이언트(kubectl)는 엔드포인트 및 자격 증명과 같은 Kubernetes 클러스터 세부 정보를 저장하기 위해 C:\Users\username.kube\config를 사용합니다. 클러스터를 배포한 경우 해당 위치에서 이 파일을 볼 수 있습니다. 하지만 지금까지 마스터 노드에서 SSH 또는 다른 방법을 통해 모든 kubectl 명령을 실행했다면 이 포스팅이 워크스테이션과 연결할 수 있는 방법을 이해하는 데 도움이 되길 바랍니다.
그런 다음 클러스터에서 kubeconfig 파일을 가져오거나 배포된 구성 파일에서 가져올 수도 있고, SCP를 통해 이 파일의 내용을 가져오거나 마스터 노드에 콘솔 세션을 열고 로컬 윈도우 머신에 복사할 수도 있습니다.
![](/2022/Days/Images/Day52_Kubernetes6.png)
그런 다음 해당 구성 파일의 복사본을 가져와서 `$HOME/.kube/config` 위치로 이동합니다.
![](/2022/Days/Images/Day52_Kubernetes7.png)
이제 로컬 워크스테이션에서 `kubectl cluster-info`와 `kubectl get nodes`를 실행하여 클러스터에 액세스할 수 있는지 확인할 수 있습니다.
![](/2022/Days/Images/Day52_Kubernetes8.png)
이렇게 하면 윈도우 머신에서 연결 및 제어가 가능할 뿐만 아니라 윈도우 머신에서 특정 서비스에 액세스하기 위해 포트 포워딩을 수행할 수 있습니다.
워크스테이션에서 여러 클러스터를 관리하는 방법에 관심이 있으시다면 [여기](https://vzilla.co.uk/vzilla-blog/building-the-home-lab-kubernetes-playground-part-6)에 더 자세한 안내가 있습니다.
이 목록은 제가 배포 중인 다양한 Kubernetes 클러스터에 대해 수행한 워크스루 블로그입니다.
- [Kubernetes playground – How to choose your platform](https://vzilla.co.uk/vzilla-blog/building-the-home-lab-kubernetes-playground-part-1)
- [Kubernetes playground – Setting up your cluster](https://vzilla.co.uk/vzilla-blog/building-the-home-lab-kubernetes-playground-part-2)
- [Getting started with Amazon Elastic Kubernetes Service (Amazon EKS)](https://vzilla.co.uk/vzilla-blog/getting-started-with-amazon-elastic-kubernetes-service-amazon-eks)
- [Getting started with Microsoft Azure Kubernetes Service (AKS)](https://vzilla.co.uk/vzilla-blog/getting-started-with-microsoft-azure-kubernetes-service-aks)
- [Getting Started with Microsoft AKS – Azure PowerShell Edition](https://vzilla.co.uk/vzilla-blog/getting-started-with-microsoft-aks-azure-powershell-edition)
- [Getting started with Google Kubernetes Service (GKE)](https://vzilla.co.uk/vzilla-blog/getting-started-with-google-kubernetes-service-gke)
- [Kubernetes, How to – AWS Bottlerocket + Amazon EKS](https://vzilla.co.uk/vzilla-blog/kubernetes-how-to-aws-bottlerocket-amazon-eks)
- [Getting started with CIVO Cloud](https://vzilla.co.uk/vzilla-blog/getting-started-with-civo-cloud)
- [Minikube - Kubernetes Demo Environment For Everyone](https://vzilla.co.uk/vzilla-blog/project_pace-kasten-k10-demo-environment-for-everyone)
### Kubernetes 시리즈에서 다룰 내용
아래에 언급된 내용 중 일부를 다루기 시작했지만, 내일 두 번째 클러스터 배포를 통해 더 많은 실습을 한 다음 클러스터에 애플리케이션 배포를 시작할 수 있습니다.
- Kubernetes 아키텍처
- Kubectl 커맨드
- Kubernetes YAML
- Kubernetes Ingress
- Kubernetes Services
- Helm 패키지 관리자
- 영속성 스토리지
- stateful 앱
## 자료
사용하신 무료 리소스가 있으시면 리포지토리에 PR을 통해 여기에 추가해 주시면 기꺼이 포함시켜 드리겠습니다.
- [Kubernetes Documentation](https://kubernetes.io/docs/home/)
- [TechWorld with Nana - Kubernetes Tutorial for Beginners [FULL COURSE in 4 Hours]](https://www.youtube.com/watch?v=X48VuDVv0do)
- [TechWorld with Nana - Kubernetes Crash Course for Absolute Beginners](https://www.youtube.com/watch?v=s_o8dwzRlu4)
- [Kunal Kushwaha - Kubernetes Tutorial for Beginners | What is Kubernetes? Architecture Simplified!](https://www.youtube.com/watch?v=KVBON1lA9N8)
[Day 53](day53.md)에서 봐요!

129
2022/ko/Days/day53.md Normal file
View File

@ -0,0 +1,129 @@
---
title: '#90DaysOfDevOps - Rancher Overview - Hands On - Day 53'
published: false
description: 90DaysOfDevOps - Rancher Overview - Hands On
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048742
---
## Rancher 개요 - 핸즈온
이 섹션에서는 Rancher에 대해 살펴볼 것인데, 지금까지는 클러스터 관리에 대한 좋은 가시성을 운영팀에 제공하는 몇 가지 좋은 UI와 멀티클러스터 관리 도구가 있지만, 지금까지 한 모든 작업은 cli와 kubectl을 사용했습니다.
Rancher는 [사이트](https://rancher.com/)에 따르면
> Rancher는 컨테이너를 도입하는 팀을 위한 완벽한 소프트웨어 스택입니다. 이 스택은 모든 인프라에서 여러 개의 Kubernetes 클러스터를 관리할 때 발생하는 운영 및 보안 문제를 해결하는 동시에 데브옵스 팀에 컨테이너화된 워크로드를 실행하기 위한 통합 도구를 제공합니다.
Rancher를 사용하면 거의 모든 위치에서 프로덕션급 Kubernetes 클러스터를 배포할 수 있으며 중앙 집중식 인증, 액세스 제어 및 통합 가시성을 제공합니다. 이전 섹션에서 Kubernetes와 관련하여 거의 압도적인 선택의 폭이 있으며, 어디에서 실행해야 하는지 또는 실행할 수 있는지에 대해 언급했지만, Rancher를 사용하면 어디에 있든 상관없습니다.
### Rancher 배포
가장 먼저 해야 할 일은 로컬 워크스테이션에 Rancher를 배포하는 것입니다. 이 단계를 진행하기 위해 선택할 수 있는 몇 가지 방법과 위치가 있는데, 저는 로컬 워크스테이션을 사용하고 Rancher를 docker 컨테이너로 실행하고 싶습니다. 아래 명령을 실행하면 컨테이너 이미지를 가져온 다음 Rancher UI에 액세스할 수 있습니다.
다른 Rancher 배포 방법은 [Rancher 빠른 시작 가이드](https://rancher.com/docs/rancher/v2.6/en/quick-start-guide/deployment/)에서 확인할 수 있습니다.
`sudo docker run -d --restart=unless-stopped -p 80:80 -p 443:443 --privileged rancher/rancher`
docker 데스크톱에서 볼 수 있듯이 실행 중인 Rancher 컨테이너가 있습니다.
![](/2022/Days/Images/Day53_Kubernetes1.png)
### Rancher UI 액세스
위의 컨테이너가 실행 중이면 웹 페이지를 통해 컨테이너로 이동할 수 있어야 합니다. `https://localhost`를 입력하면 아래와 같이 로그인 페이지가 나타납니다.
![](/2022/Days/Images/Day53_Kubernetes2.png)
아래 안내에 따라 필요한 비밀번호를 입력합니다. 저는 Windows를 사용하고, grep 명령이 필요하기 때문에 Windows용 bash를 사용하기로 했습니다.
![](/2022/Days/Images/Day53_Kubernetes3.png)
이제 위의 비밀번호를 사용하여 로그인하면 다음 페이지에서 새 비밀번호를 정의할 수 있습니다.
![](/2022/Days/Images/Day53_Kubernetes4.png)
위의 작업을 완료하면 로그인이 완료되고 시작 화면을 볼 수 있습니다. Rancher 배포의 일부로 로컬 K3 클러스터가 프로비저닝된 것도 볼 수 있습니다.
![](/2022/Days/Images/Day53_Kubernetes5.png)
### Rancher에 대한 간략한 둘러보기
가장 먼저 살펴볼 것은 로컬로 배포된 K3S 클러스터입니다. 아래에서 클러스터 내부에서 어떤 일이 일어나고 있는지 잘 볼 수 있습니다. 이것은 기본 배포이며 아직 이 클러스터에 아무것도 배포하지 않았습니다. 1개의 노드로 구성되어 있고 5개의 배포가 있는 것을 볼 수 있습니다. 그리고 pod, 코어, 메모리에 대한 몇 가지 통계가 있는 것을 볼 수 있습니다.
![](/2022/Days/Images/Day53_Kubernetes6.png)
왼쪽 메뉴에는 앱 및 마켓플레이스 탭도 있는데, 이 탭을 통해 클러스터에서 실행할 애플리케이션을 선택할 수 있습니다. 앞서 언급했듯이 Rancher는 여러 개의 다른 클러스터를 실행하거나 관리할 수 있는 기능을 제공합니다. 마켓플레이스를 사용하면 애플리케이션을 매우 쉽게 배포할 수 있습니다.
![](/2022/Days/Images/Day53_Kubernetes7.png)
또 한 가지 언급할 것은 오른쪽 상단에 있는 Rancher에서 관리 중인 클러스터에 액세스해야 하는 경우 선택한 클러스터에 대한 kubectl 셸을 열 수 있다는 것입니다.
![](/2022/Days/Images/Day53_Kubernetes8.png)
### 새 클러스터 생성
지난 두 세션에 걸쳐 로컬에서 Minikube 클러스터를 생성하고 가상박스와 함께 Vagrant를 사용하여 3노드 Kubernetes 클러스터를 생성했으며, Rancher를 사용하여 클러스터를 생성할 수도 있습니다. [Rancher 폴더](/2022/Days/Kubernetes/Rancher)에는 동일한 3개의 노드를 구축할 수 있는 추가 vagrant 파일이 있지만 Kubernetes 클러스터를 생성하는 단계가 없습니다(Rancher가 이 작업을 대신 수행하기를 원합니다).
그러나 각 노드에서 `common.sh` 스크립트가 계속 실행되는 것을 볼 수 있도록 docker가 설치되고 OS가 업데이트되기를 원합니다. 이것은 또한 Kubeadm, Kubectl 등을 설치합니다. 그러나 노드를 클러스터로 생성하고 조인하기 위한 Kubeadm 명령은 실행되지 않습니다.
vagrant 폴더 위치로 이동하여 `vagrant up`을 실행하기만 하면 가상 박스에서 3개의 가상 머신을 생성하는 프로세스가 시작됩니다.
![](/2022/Days/Images/Day53_Kubernetes9.png)
이제 노드 또는 VM이 제자리에 배치되고 준비되었으므로 Rancher를 사용하여 새로운 Kubernetes 클러스터를 생성할 수 있습니다. 클러스터를 생성하는 첫 번째 화면에서는 클러스터가 어디에 있는지, 즉 퍼블릭 클라우드 관리형 Kubernetes 서비스를 사용 중인지, vSphere 또는 다른 것을 사용 중인지에 대한 몇 가지 옵션을 제공합니다.
![](/2022/Days/Images/Day53_Kubernetes10.png)
통합 플랫폼 중 하나를 사용하지 않으므로 "custom"을 선택하겠습니다. 시작 페이지는 클러스터 이름을 정의하는 곳입니다(아래에 로컬이라고 되어 있지만 로컬을 사용할 수 없습니다. 저희 클러스터는 vagrant라고 합니다.) 여기에서 Kubernetes 버전, 네트워크 공급자 및 기타 구성 옵션을 정의하여 Kubernetes 클러스터를 시작하고 실행할 수 있습니다.
![](/2022/Days/Images/Day53_Kubernetes11.png)
다음 페이지에서는 활성화할 적절한 서비스와 함께 각 노드에서 실행해야 하는 등록 코드(etcd, 컨트롤 플레인 및 워커)를 제공합니다. 마스터 노드의 경우, etcd와 컨트롤 플레인이 필요하므로 명령은 아래와 같습니다.
![](/2022/Days/Images/Day53_Kubernetes12.png)
```
sudo docker run -d --privileged --restart=unless-stopped --net=host -v /etc/kubernetes:/etc/kubernetes -v /var/run:/var/run rancher/rancher-agent:v2.6.3 --server https://10. 0.0.1 --token mpq8cbjjwrj88z4xmf7blqxcfmwdsmq92bmwjpphdkklfckk5hfwc2 --ca-checksum a81944423cbfeeb92be0784edebba1af799735ebc30ba8cbe5cc5f996094f30b --etcd --controlplane
```
네트워킹이 올바르게 구성되었다면, 이제 첫 번째 마스터 노드가 등록되고 클러스터가 생성되고 있음을 나타내는 Rancher 대시보드에 다음과 같이 빠르게 표시되어야 합니다.
![](/2022/Days/Images/Day53_Kubernetes13.png)
그런 다음 다음 명령으로 각 워커 노드에 대한 등록 프로세스를 반복하면 얼마 후 마켓플레이스를 활용하여 애플리케이션을 배포할 수 있는 클러스터를 실행할 수 있게 됩니다.
```
sudo docker run -d --privileged --restart=unless-stopped --net=host -v /etc/kubernetes:/etc/kubernetes -v /var/run:/var/run rancher/rancher-agent:v2.6.3 --server https://10. 0.0.1 --token mpq8cbjjwrj88z4xmf7blqxcfmwdsmq92bmwjpphdkklfckk5hfwc2 --ca-checksum a81944423cbfeeb92be0784edebba1af799735ebc30ba8cbe5cc5f996094f30b --worker
```
![](/2022/Days/Images/Day53_Kubernetes14.png)
지난 세 세션 동안, 우리는 몇 가지 다른 방법으로 Kubernetes 클러스터를 시작하고 실행하는 방법을 사용했으며, 남은 날에는 플랫폼에서 가장 중요한 애플리케이션 측면을 살펴볼 것입니다. 서비스 프로비저닝과 Kubernetes에서 서비스를 프로비저닝하고 사용할 수 있는 방법에 대해 살펴보겠습니다.
부트스트랩 Rancher 노드에 대한 요구사항에 따라 해당 VM에 4GB 램이 있어야 하며 그렇지 않으면 크래시 루프가 발생한다고 들었는데, 이후 워커 노드에 2GB가 있는 것으로 업데이트했습니다.
### Kubernetes 시리즈에서 다룰 내용
아래에 언급된 내용 중 일부를 다루기 시작했지만, 내일 두 번째 클러스터 배포를 통해 더 많은 실습을 한 다음 클러스터에 애플리케이션 배포를 시작할 수 있습니다.
- Kubernetes 아키텍처
- Kubectl 커맨드
- Kubernetes YAML
- Kubernetes Ingress
- Kubernetes Services
- Helm 패키지 관리자
- 영속성 스토리지
- stateful 앱
## 자료
사용하신 무료 리소스가 있으시면 리포지토리에 PR을 통해 여기에 추가해 주시면 기꺼이 포함시켜 드리겠습니다.
- [Kubernetes Documentation](https://kubernetes.io/docs/home/)
- [TechWorld with Nana - Kubernetes Tutorial for Beginners [FULL COURSE in 4 Hours]](https://www.youtube.com/watch?v=X48VuDVv0do)
- [TechWorld with Nana - Kubernetes Crash Course for Absolute Beginners](https://www.youtube.com/watch?v=s_o8dwzRlu4)
- [Kunal Kushwaha - Kubernetes Tutorial for Beginners | What is Kubernetes? Architecture Simplified!](https://www.youtube.com/watch?v=KVBON1lA9N8)
[Day 54](day54.md)에서 봐요!

223
2022/ko/Days/day54.md Normal file
View File

@ -0,0 +1,223 @@
---
title: '#90DaysOfDevOps - Kubernetes Application Deployment - Day 54'
published: false
description: 90DaysOfDevOps - Kubernetes Application Deployment
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048764
---
## Kubernetes 애플리케이션 배포
이제 드디어 일부 애플리케이션을 클러스터에 배포하게 되었는데, 일부 사람들은 이것이 바로 애플리케이션 배포를 위해 Kubernetes가 존재하는 이유라고 말할 수 있습니다.
여기서 아이디어는 컨테이너 이미지를 가져와서 이제 컨테이너 오케스트레이터로서 Kubernetes를 활용하기 위해 컨테이너 이미지를 Kubernetes 클러스터에 pod로 배포할 수 있다는 것입니다.
### Kubernetes에 앱 배포하기
애플리케이션을 Kubernetes 클러스터에 배포하는 방법에는 여러 가지가 있지만, 가장 일반적인 두 가지 접근 방식인 YAML 파일과 Helm 차트를 다뤄보겠습니다.
이러한 애플리케이션 배포에는 Minikube 클러스터를 사용할 것입니다. 앞서 언급한 Kubernetes의 구성 요소 또는 빌딩 블록 중 일부를 살펴볼 것입니다.
이 섹션과 컨테이너 섹션을 통해 이미지와 Kubernetes의 장점, 그리고 이 플랫폼에서 확장을 매우 쉽게 처리할 수 있는 방법에 대해 논의했습니다.
이 첫 번째 단계에서는 Minikube 클러스터 내에 상태 비저장 애플리케이션을 간단히 생성해 보겠습니다. 사실상의 표준 상태 비저장 애플리케이션인 `nginx`를 사용하여 첫 번째 데모에서 배포를 구성하여 pod를 제공한 다음 nginx pod에서 호스팅하는 간단한 웹 서버로 이동할 수 있는 서비스도 생성할 것입니다. 이 모든 것이 네임스페이스에 포함될 것입니다.
![](/2022/Days/Images/Day54_Kubernetes1.png)
### YAML 생성
첫 번째 데모에서는 YAML로 수행하는 모든 작업을 정의하고자 합니다. YAML에 대한 전체 섹션이 있을 수 있지만, 여기서는 간략히 살펴보고 마지막에 YAML을 더 자세히 다룰 몇 가지 리소스를 남겨두려고 합니다.
다음을 하나의 YAML 파일로 만들 수도 있고, 애플리케이션의 각 측면별로 나눌 수도 있습니다. 즉, 네임스페이스, 배포 및 서비스 생성을 위한 별도의 파일일 수 있지만 이 파일에서는 아래에서 `---`를 사용하여 하나의 파일로 구분했습니다. 이 파일은 [여기](/2022/Days/Kubernetes)에서 찾을 수 있습니다(파일명:- nginx-stateless-demo.YAML).
```Yaml
apiVersion: v1
kind: Namespace
metadata:
name: nginx
"labels": {
"name": "nginx"
}
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
namespace: nginx
spec:
selector:
matchLabels:
app: nginx
replicas: 1
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: nginx-service
namespace: nginx
spec:
selector:
app: nginx-deployment
ports:
- protocol: TCP
port: 80
targetPort: 80
```
### 클러스터 확인
배포하기 전에 `nginx`라는 네임스페이스가 없는지 확인해야 하는데, `kubectl get namespace` 명령을 실행하여 확인할 수 있으며, 아래에서 볼 수 있듯이 `nginx`라는 네임스페이스가 없습니다.
![](/2022/Days/Images/Day54_Kubernetes2.png)
### 앱을 배포할 시간
이제 Minikube 클러스터에 애플리케이션을 배포할 준비가 되었으며, 이 프로세스는 다른 모든 Kubernetes 클러스터에서도 동일하게 작동합니다.
YAML 파일 위치로 이동한 다음 `kubectl create -f nginx-stateless-demo.yaml`을 실행하면 3개의 오브젝트가 생성되고 네임스페이스, 배포 및 서비스가 생성된 것을 확인할 수 있습니다.
![](/2022/Days/Images/Day54_Kubernetes3.png)
클러스터에서 사용 가능한 네임스페이스를 확인하기 위해 `kubectl get namespace` 명령을 다시 실행하면 이제 새 네임스페이스가 있는 것을 확인할 수 있습니다.
![](/2022/Days/Images/Day54_Kubernetes5.png)
이제 `kubectl get pods -n nginx`를 사용하여 네임스페이스에 pod가 있는지 확인하면 준비 및 실행 상태의 pod 1개가 있는 것을 볼 수 있습니다.
![](/2022/Days/Images/Day54_Kubernetes4.png)
또한 `kubectl get service -n nginx`를 실행하여 서비스가 생성되었는지 확인할 수 있습니다.
![](/2022/Days/Images/Day54_Kubernetes6.png)
마지막으로, 배포를 확인하여 원하는 구성을 어디에 어떻게 유지하는지 확인할 수 있습니다.
![](/2022/Days/Images/Day54_Kubernetes7.png)
위는 몇 가지 알아두면 좋은 명령어를 사용했지만, `kubectl get all -n nginx`를 사용하여 하나의 YAML 파일로 배포한 모든 것을 볼 수도 있습니다.
![](/2022/Days/Images/Day54_Kubernetes8.png)
위 그림에서 replicaset가 있는 것을 볼 수 있는데, 배포에서 배포할 이미지의 레플리카 개수를 정의합니다. 처음에는 1로 설정되었지만, 애플리케이션을 빠르게 확장하려면 여러 가지 방법으로 확장할 수 있습니다.
터미널 내에서 텍스트 편집기를 열고 배포를 수정할 수 있는 `kubectl edit deployment nginx-deployment -n nginx`를 사용하여 파일을 편집할 수 있다.
![](/2022/Days/Images/Day54_Kubernetes9.png)
터미널 내의 텍스트 편집기에서 위의 내용을 저장했을 때 문제가 없고 올바른 서식이 사용되었다면 네임스페이스에 추가로 배포된 것을 볼 수 있을 것입니다.
![](/2022/Days/Images/Day54_Kubernetes10.png)
또한 kubectl과 `kubectl scale deployment nginx-deployment --replicas=10 -n nginx`를 사용하여 레플리카 수를 변경할 수 있습니다.
![](/2022/Days/Images/Day54_Kubernetes11.png)
두 방법 중 하나를 사용하려는 경우 이 방법을 사용하여 애플리케이션을 다시 1로 축소할 수 있습니다. 저는 편집 옵션을 사용했지만, 위의 스케일 명령을 사용할 수도 있습니다.
![](/2022/Days/Images/Day54_Kubernetes12.png)
여기서 사용 사례를 통해 매우 빠르게 스핀업 및 스핀다운할 수 있을 뿐만 아니라 애플리케이션을 빠르게 확장 및 축소할 수 있다는 것을 알 수 있기를 바랍니다. 이것이 웹 서버라면 부하가 많을 때는 확장하고 부하가 적을 때는 축소할 수 있습니다.
### 앱 노출하기
그렇다면 어떻게 웹 서버에 접속할 수 있을까요?
위에서 저희 서비스를 보면 사용 가능한 외부 IP가 없으므로 웹 브라우저를 열고 마술처럼 접속할 수는 없습니다. 접속을 위해 몇 가지 옵션이 있습니다.
**ClusterIP** - 표시되는 IP는 클러스터 내부 네트워크에 있는 클러스터IP입니다. 클러스터 내의 사물만 이 IP에 연결할 수 있습니다.
**NodePort** - NAT를 사용하여 클러스터에서 선택한 각 노드의 동일한 포트에 서비스를 노출합니다.
**로드 밸런서** - 현재 클라우드에 외부 로드 밸런서를 생성합니다. 저희는 Minikube를 사용하고 있지만, VirtualBox에서 했던 것과 같이 자체 Kubernetes 클러스터를 구축한 경우 이 기능을 제공하려면 metallb와 같은 로드밸런서를 클러스터에 배포해야 합니다.
**포트 포워드** - 로컬 호스트에서 내부 Kubernetes 클러스터 프로세스에 액세스하고 상호 작용할 수 있는 포트 포워드 기능도 있습니다. 이 옵션은 테스트 및 결함 발견에만 사용됩니다.
이제 선택할 수 있는 몇 가지 옵션이 생겼습니다. Minikube에는 본격적인 Kubernetes 클러스터와 비교했을 때 몇 가지 제한 사항이나 차이점이 있습니다.
다음 명령을 실행하여 로컬 워크스테이션을 사용하여 액세스를 포트 포워딩할 수 있습니다.
`kubectl port-forward deployment/nginx-deployment -n nginx 8090:80`
![](/2022/Days/Images/Day54_Kubernetes13.png)
위 명령을 실행하면 로컬 머신과 포트에 대한 포트 포워딩 역할을 하므로 이 터미널을 사용할 수 없게 됩니다.
![](/2022/Days/Images/Day54_Kubernetes14.png)
이제 Minikube를 통해 애플리케이션을 노출하는 방법을 구체적으로 살펴보겠습니다. Minikube를 사용하여 서비스에 연결하기 위한 URL을 생성할 수도 있습니다. [자세한 내용](https://minikube.sigs.k8s.io/docs/commands/service/)
먼저, `kubectl delete service nginx-service -n nginx`를 사용하여 서비스를 삭제합니다.
다음으로 `kubectl expose deployment nginx-deployment --name nginx-service --namespace nginx --port=80 --type=NodePort`를 사용하여 새 서비스를 생성합니다. 여기서 expose를 사용하고 유형을 NodePort로 변경한다는 점에 유의하세요.
![](/2022/Days/Images/Day54_Kubernetes15.png)
마지막으로 새 터미널에서 `minikube --profile='mc-demo' service nginx-service --url -n nginx`를 실행하여 서비스에 대한 터널을 생성합니다.
![](/2022/Days/Images/Day54_Kubernetes16.png)
브라우저 또는 제어를 열고 터미널에서 링크를 클릭합니다.
![](/2022/Days/Images/Day54_Kubernetes17.png)
### Helm
Helm은 애플리케이션을 배포할 수 있는 또 다른 방법입니다. "Kubernetes를 위한 패키지 관리자"로 알려진 Helm에 대한 자세한 내용은 [여기](https://helm.sh/)에서 확인할 수 있습니다.
Helm은 Kubernetes를 위한 패키지 매니저입니다. Helm은 Kubernetes에서 yum이나 apt에 해당하는 것으로 간주할 수 있습니다. Helm은 패키지 애플리케이션처럼 생각할 수 있는 차트를 배포하는데, 이는 미리 구성된 애플리케이션 리소스를 사용하기 쉬운 하나의 차트로 배포할 수 있는 청사진입니다. 그런 다음 다른 구성 세트로 차트의 다른 버전을 배포할 수 있습니다.
사용 가능한 모든 Helm 차트를 찾아볼 수 있는 사이트가 있으며 물론 직접 만들 수도 있습니다. 문서도 명확하고 간결하며 이 분야의 다른 모든 신조어들 사이에서 Helm이라는 용어를 처음 들었을 때처럼 어렵지 않습니다.
Helm을 시작하고 실행하거나 설치하는 것은 매우 간단합니다. 간단합니다. RaspberryPi arm64 장치를 포함한 거의 모든 배포판에 대한 바이너리와 다운로드 링크는 여기에서 찾을 수 있습니다.
또는 설치 스크립트를 사용할 수도 있는데, 이 경우 최신 버전의 Helm이 다운로드되어 설치된다는 이점이 있습니다.
```Shell
curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3
chmod 700 get_helm.sh
./get_helm.sh
```
마지막으로, 애플리케이션 관리자를 위한 패키지 관리자, 맥용 homebrew, 윈도우용 chocolatey, Ubuntu/Debian용 apt, snap 및 pkg도 사용할 수 있습니다.
지금까지는 Helm이 클러스터에 다양한 테스트 애플리케이션을 다운로드하고 설치하는 데 가장 적합한 방법인 것 같습니다.
여기에 링크할 수 있는 좋은 리소스로는 Kubernetes 패키지를 찾고, 설치하고, 게시할 수 있는 리소스인 [ArtifactHUB](https://artifacthub.io/)를 들 수 있습니다. 또한 Helm 차트를 표시하는 UI인 [KubeApps](https://kubeapps.com/)에 대해서도 언급하겠습니다.
### Kubernetes에서 다룰 내용
아래에 언급된 내용 중 일부를 다루기 시작했지만, 내일 두 번째 클러스터 배포를 통해 더 많은 실습을 한 후 클러스터에 애플리케이션 배포를 시작할 수 있습니다.
- Kubernetes 아키텍처
- Kubectl 커맨드
- Kubernetes YAML
- Kubernetes Ingress
- Kubernetes Services
- Helm 패키지 관리자
- 영속성 스토리지
- stateful 앱
## 자료
사용하신 무료 리소스가 있으시면 리포지토리에 PR을 통해 여기에 추가해 주시면 기꺼이 포함시켜 드리겠습니다.
- [Kubernetes Documentation](https://kubernetes.io/docs/home/)
- [TechWorld with Nana - Kubernetes Tutorial for Beginners [FULL COURSE in 4 Hours]](https://www.youtube.com/watch?v=X48VuDVv0do)
- [TechWorld with Nana - Kubernetes Crash Course for Absolute Beginners](https://www.youtube.com/watch?v=s_o8dwzRlu4)
- [Kunal Kushwaha - Kubernetes Tutorial for Beginners | What is Kubernetes? Architecture Simplified!](https://www.youtube.com/watch?v=KVBON1lA9N8)
[Day 55](day55.md)에서 봐요!

239
2022/ko/Days/day55.md Normal file
View File

@ -0,0 +1,239 @@
---
title: '#90DaysOfDevOps - State and Ingress in Kubernetes - Day 55'
published: false
description: 90DaysOfDevOps - State and Ingress in Kubernetes
tags: 'DevOps, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048779
---
## Kubernetes의 State와 Ingress
이번 Kubernetes 마지막 섹션에서는 State와 Ingress에 대해 살펴보겠습니다.
지금까지 설명한 모든 것은 상태 비저장에 관한 것이며, 상태 비저장은 실제로 애플리케이션이 어떤 네트워크를 사용하든 상관하지 않고 영구적인 저장소가 필요하지 않은 경우입니다. 예를 들어 Stateful 애플리케이션과 데이터베이스가 제대로 작동하려면, 호스트 이름, IP 등 변경되지 않는 고유 ID를 통해 pod가 서로 연결될 수 있도록 해야 합니다. Stateful 애플리케이션의 예로는 MySQL 클러스터, Redis, Kafka, MongoDB 등이 있습니다. 기본적으로 데이터를 저장하는 모든 애플리케이션을 통해 가능합니다.
### Stateful 애플리케이션
StatefulSet은 Kubernetes가 스케줄링 위치에 관계없이 유지 관리하는 고유하고 영구적인 ID와 안정적인 호스트 이름을 가진 pod의 집합을 나타냅니다. 특정 StatefulSet pod의 상태 정보 및 기타 복원력 있는 데이터는 StatefulSet과 연결된 영속성 디스크 스토리지에 유지됩니다.
### Deployment vs StatefulSet
- Stateful 애플리케이션을 복제하는 것은 더 어렵다.
- 배포(Stateless 애플리케이션)에서 pod를 복제하는 것은 동일하며 상호 교환이 가능하다.
- 임의의 해시를 사용하여 임의의 순서로 pod를 생성한다.
- 모든 pod에 로드 밸런싱하는 하나의 서비스이다.
StatefulSet 또는 Stateful 애플리케이션의 경우 위의 내용이 더 어렵습니다.
- 동시에 생성하거나 삭제할 수 없다.
- 임의로 주소를 지정할 수 없다.
- 레플리카 pod는 동일하지 않다.
곧 데모에서 보게 될 것은 각 pod가 고유한 식별자를 가지고 있다는 것입니다. 상태 비저장 애플리케이션을 사용하면 임의의 이름을 볼 수 있습니다. 예를 들어 `app-7469bbb6d7-9mhxd`인 반면, 상태 저장 애플리케이션은 `mongo-0`에 더 가깝고 확장 시 `mongo-1`이라는 새 pod를 생성합니다.
이러한 pod는 동일한 사양으로 생성되지만 상호 교환할 수는 없습니다. 각 StatefulSet pod는 모든 스케줄링에 걸쳐 영구 식별자를 가지고 있습니다. 이는 데이터베이스에 쓰고 읽어야 하는 데이터베이스와 같은 Stateful 워크로드가 필요할 때, 데이터 불일치를 초래할 수 있기 때문에 두 개의 pod가 인식 없이 동시에 쓰게 할 수 없기 때문에 필요합니다. 주어진 시간에 데이터베이스에 하나의 pod만 쓰도록 해야 하지만 여러 개의 pod가 해당 데이터를 읽을 수 있습니다.
StatefulSet의 각 pod는 영구 볼륨과 데이터베이스의 복제본에 액세스하여 읽을 수 있으며, 이는 마스터로부터 지속적으로 업데이트됩니다. 또한 각 pod는 이 영속성 볼륨에 pod 상태도 저장하는데, 만약 `mongo-0`이 죽으면 새 pod가 프로비저닝될 때 스토리지에 저장된 pod 상태를 이어받게 된다는 점도 흥미롭습니다.
TLDR; StatefulSet vs Deployment
- 예측 가능한 pod 이름 = `mongo-0`
- 고정된 개별 DNS 이름
- pod 아이덴티티 - 상태 유지, 역할 유지
- Stateful 앱 복제는 복잡함
- 해야 할 일이 많음:
- 복제 및 데이터 동기화를 구성
- 원격 공유 스토리지를 사용할 수 있도록 설정
- 관리 및 백업
### 영속성 볼륨 | Claims | StorageClass
Kubernetes에서 데이터를 어떻게 지속하나요?
위에서 상태 저장 애플리케이션이 있을 때 상태를 어딘가에 저장해야 한다고 언급했는데, 바로 이 부분에서 볼륨의 필요성이 대두되는데, Kubernetes는 기본적으로 지속성을 제공하지 않습니다.
pod 라이프사이클에 의존하지 않는 스토리지 계층이 필요합니다. 이 스토리지는 모든 Kubernetes 노드에서 사용할 수 있고 액세스할 수 있어야 합니다. 또한 이 스토리지는 Kubernetes 클러스터가 충돌하더라도 생존할 수 있도록 Kubernetes 클러스터 외부에 있어야 합니다.
### 영속성 볼륨
- 데이터를 저장하기 위한 클러스터 리소스(예: CPU 및 RAM)
- YAML 파일을 통해 생성
- 실제 물리적 스토리지(NAS)가 필요
- Kubernetes 클러스터에 대한 외부 통합
- 스토리지에 다양한 유형의 스토리지를 사용
- PV는 네임스페이스가 없음
- 로컬 스토리지를 사용할 수 있지만 클러스터의 한 노드에 한정
- 데이터베이스 지속성은 원격 스토리지(NAS)를 사용
### 영구 볼륨 Claims
위의 영구 볼륨만 있어도 사용할 수 있지만 애플리케이션에서 Claims하지 않으면 사용되지 않습니다.
- YAML 파일을 통해 생성
- 영속성 볼륨 Claims은 pod 구성(볼륨 어트리뷰트)에서 사용
- PVC는 pod와 동일한 네임스페이스에 존재
- 볼륨이 pod에 마운트됨
- pod는 여러 가지 볼륨 유형(ConfigMaps, Secrets, PVC)을 사용
PV와 PVC를 생각하는 또 다른 방법은 다음과 같다.
PV는 Kubernetes 어드민에 의해 생성된다.
PVC는 사용자 또는 애플리케이션 개발자가 생성한다.
또한 자세히 설명하지는 않겠지만 언급할 가치가 있는 두 가지 다른 유형의 볼륨이 있다:
### ConfigMaps | Secrets
- pod의 구성 파일
- pod의 인증서 파일
### StorageClass
- YAML 파일을 통해 생성
- PVC가 영속성 볼륨을 Claims할 때 동적으로 프로비저닝
- 각 스토리지 백엔드에는 프로비저너가 있음
- 스토리지 백엔드는 (프로비저너 속성을 통해) YAML에 정의됨
- 기본 스토리지 공급자 추상화
- 해당 스토리지에 대한 파라미터 정의
### 연습 시간
어제 세션에서는 상태 비저장 애플리케이션을 생성하는 방법을 살펴봤는데, 여기서는 동일한 작업을 수행하되 Minikube 클러스터를 사용하여 상태 저장 워크로드를 배포하고자 합니다.
지속성을 사용하는 기능과 애드온을 갖기 위해 사용하는 Minikube 명령에 대한 요약은 `minikube start --addons volumesnapshots,csi-hostpath-driver --apiserver-port=6443 --container-runtime=containerd -p mc-demo --kubernetes-version=1.21.2`입니다.
이 명령은 나중에 보여드리는 스토리지 클래스를 제공하는 CSI-hostpath-driver를 사용합니다.
애플리케이션의 빌드 아웃은 아래와 같습니다:
![](/2022/Days/Images/Day55_Kubernetes1.png)
이 애플리케이션의 YAML 구성 파일은 여기에서 찾을 수 있습니다. [pacman-stateful-demo.yaml](/2022/Days/Kubernetes)
### StorageClass 구성
애플리케이션 배포를 시작하기 전에 실행해야 하는 한 단계가 더 있는데, 그것은 StorageClass(CSI-hostpath-sc)가 기본 StorageClass인지 확인하는 것입니다. 먼저 `kubectl get storageclass` 명령을 실행하여 확인할 수 있지만, 기본적으로 Minikube 클러스터는 표준 스토리지 클래스를 기본값으로 표시하므로 다음 명령으로 변경해야 합니다.
이 첫 번째 명령은 CSI-hostpath-sc 스토리지 클래스를 기본값으로 설정합니다.
`kubectl patch storageclass csi-hostpath-sc -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'`
이 명령은 표준 StorageClass에서 기본 어노테이션을 제거합니다.
`kubectl patch storageclass standard -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'`
![](/2022/Days/Images/Day55_Kubernetes2.png)
클러스터에 Pacman 네임스페이스가 없는 상태에서 시작합니다. `kubectl get namespace`
![](/2022/Days/Images/Day55_Kubernetes3.png)
그런 다음 YAML 파일을 배포합니다. `kubectl create -f pacman-stateful-demo.yaml` 이 명령에서 우리는 Kubernetes 클러스터 내에 여러 개의 오브젝트를 생성하고 있음을 볼 수 있습니다.
![](/2022/Days/Images/Day55_Kubernetes4.png)
이제 새로 생성된 네임스페이스가 생겼습니다.
![](/2022/Days/Images/Day55_Kubernetes5.png)
다음 이미지와 `kubectl get all -n pacman` 명령에서 네임스페이스 내부에서 여러 가지 일이 일어나고 있음을 확인할 수 있습니다. 우리는 NodeJS 웹 프론트엔드를 실행하는 pod를 가지고 있고, 백엔드 데이터베이스를 실행하는 mongo를 가지고 있습니다. Pacman과 mongo 모두 해당 pod에 액세스하기 위한 서비스가 있습니다. Pacman을 위한 배포와 mongo를 위한 StatefulSet이 있습니다.
![](/2022/Days/Images/Day55_Kubernetes6.png)
또한 영속성 볼륨과 영속성 볼륨 Claims도 가지고 있는데, `kubectl get pv`를 실행하면 네임스페이스가 없는 영속성 볼륨을 얻을 수 있고, `kubectl get pvc -n pacman`을 실행하면 네임스페이스가 있는 영속성 볼륨 Claims을 얻을 수 있습니다.
![](/2022/Days/Images/Day55_Kubernetes7.png)
### 게임 플레이하기 | 미션 크리티컬 애플리케이션에 액세스하기
앞서 언급한 바와 같이 상태 비저장 애플리케이션에서 Minikube를 사용하고 있기 때문에 애플리케이션에 액세스하는 데 있어 몇 가지 장애물이 있지만, 클러스터 내에서 Ingress 또는 로드 밸런서에 액세스하여 외부에서 액세스하기 위해 자동으로 IP를 받도록 설정되어 있습니다. (위의 Pacman 네임스페이스의 모든 구성 요소 이미지에서 이를 확인할 수 있습니다).
이 데모에서는 포트 포워드 방법을 사용하여 애플리케이션에 액세스하겠습니다. 새 터미널을 열고 다음 `kubectl port-forward svc/pacman 9090:80 -n pacman` 명령을 실행하고 브라우저를 열면 이제 애플리케이션에 액세스할 수 있다. AWS 또는 특정 위치에서 실행하는 경우, 위의 스크린샷에서 이 pod 이름을 다시 한번 확인하면 클라우드와 영역은 물론 Kubernetes 내의 pod와 동일한 호스트에 대해서도 보고됩니다.
![](/2022/Days/Images/Day55_Kubernetes8.png)
이제 데이터베이스에 저장할 높은 점수를 생성할 수 있습니다.
![](/2022/Days/Images/Day55_Kubernetes9.png)
좋아요, 이제 높은 점수를 얻었지만 `mongo-0` pod를 삭제하면 어떻게 되나요? `kubectl delete pod mongo-0 -n pacman`을 실행하면 삭제할 수 있으며, 아직 앱에 있는 경우 적어도 몇 초 동안은 높은 점수를 사용할 수 없는 것을 볼 수 있을 것입니다.
![](/2022/Days/Images/Day55_Kubernetes10.png)
이제 게임으로 돌아가서 새 게임을 만들면 제 높은 점수를 확인할 수 있습니다. 하지만 제 말을 진정으로 믿을 수 있는 유일한 방법은 직접 시도해보고 소셜 미디어에 최고 점수를 공유하는 것입니다!
![](/2022/Days/Images/Day55_Kubernetes11.png)
배포를 통해 이전 세션에서 다룬 커맨드를 사용하여 확장할 수 있지만, 특히 대규모 Pacman 파티를 주최하려는 경우 `kubectl scale deployment pacman --replicas=10 -n pacman`을 사용하여 확장할 수 있습니다.
![](/2022/Days/Images/Day55_Kubernetes12.png)
### Ingress 설명
Kubernetes에 대해 마무리하기 전에 Kubernetes의 중요한 측면인 Ingress에 대해서도 다루고 싶었습니다.
### Ingress란 무엇인가요?
지금까지 예제에서는 포트 포워드를 사용하거나 Minikube 내에서 특정 명령을 사용하여 애플리케이션에 액세스했지만, 프로덕션 환경에서는 이 방법이 작동하지 않습니다. 여러 사용자가 대규모로 애플리케이션에 액세스할 수 있는 더 나은 방법이 필요할 것입니다.
또한 NodePort가 옵션이라고 말씀드렸지만, 이 역시 테스트 목적으로만 사용해야 합니다.
Ingress는 애플리케이션을 노출하는 더 나은 방법을 제공하며, 이를 통해 Kubernetes 클러스터 내에서 라우팅 규칙을 정의할 수 있습니다.
Ingress의 경우, 애플리케이션의 내부 서비스에 대한 포워드 요청을 생성합니다.
### 언제 Ingress가 필요한가요?
클라우드 제공자를 사용하는 경우, 관리형 Kubernetes 제품에는 클러스터에 대한 Ingress 옵션이 있거나 로드 밸런서 옵션이 제공될 가능성이 높습니다. 이를 직접 구현할 필요가 없다는 것이 관리형 Kubernetes의 장점 중 하나입니다.
클러스터를 실행하는 경우 엔트리포인트를 구성해야 한다.
### Minikube에서 Ingress 구성하기
제가 실행 중인 mc-demo라는 특정 클러스터에서 다음 명령을 실행하여 클러스터에서 Ingress를 활성화할 수 있습니다.
`minikube --profile='mc-demo' addons enable ingress`
![](/2022/Days/Images/Day55_Kubernetes13.png)
이제 네임스페이스를 확인하면 새로운 ingress-nginx 네임스페이스가 있는 것을 볼 수 있습니다. `kubectl get ns`
![](/2022/Days/Images/Day55_Kubernetes14.png)
이제 Pacman 서비스를 실행하기 위해 Ingress YAML 구성을 생성해야 합니다. 이 파일을 리포지토리 [pacman-ingress.yaml](/2022/Days/Kubernetes)에 추가했습니다.
그런 다음 `kubectl create -f pacman-ingress.yaml`을 사용하여 Ingress 네임스페이스에 이 파일을 생성할 수 있습니다.
![](/2022/Days/Images/Day55_Kubernetes15.png)
그런 다음 `kubectl get ingress -n pacman`을 실행하면 다음과 같이 출력됩니다.
![](/2022/Days/Images/Day55_Kubernetes16.png)
그러면 윈도우에서 WSL2에서 실행되는 Minikube를 사용하고 있기 때문에 `minikube tunnel --profile=mc-demo`를 사용하여 Minikube 터널을 생성해야 한다는 메시지가 표시됩니다.
하지만 여전히 192.168.49.2에 액세스하여 Pacman 게임을 플레이할 수 없습니다.
누구든지 Windows 및 WSL에서 이 기능을 사용할 수 있거나 사용할 수 있다면 피드백을 보내 주시면 감사하겠습니다. 리포지토리에 이 문제를 제기하고 시간과 수정 사항이 생기면 다시 돌아오겠습니다.
업데이트: 이 블로그가 WSL에서 작동하지 않는 원인을 파악하는 데 도움이 될 것 같습니다 [Docker 런타임을 사용하여 WSL2에서 Minikube를 실행하도록 Ingress 구성하기](https://hellokube.dev/posts/configure-minikube-ingress-on-wsl2/).
## 자료
사용하신 무료 리소스가 있으시면 리포지토리에 PR을 통해 여기에 추가해 주시면 기꺼이 포함시켜 드리겠습니다.
- [Kubernetes StatefulSet simply explained](https://www.youtube.com/watch?v=pPQKAR1pA9U)
- [Kubernetes Volumes explained](https://www.youtube.com/watch?v=0swOh5C3OVM)
- [Kubernetes Ingress Tutorial for Beginners](https://www.youtube.com/watch?v=80Ew_fsV4rM)
- [Kubernetes Documentation](https://kubernetes.io/docs/home/)
- [TechWorld with Nana - Kubernetes Tutorial for Beginners [FULL COURSE in 4 Hours]](https://www.youtube.com/watch?v=X48VuDVv0do)
- [TechWorld with Nana - Kubernetes Crash Course for Absolute Beginners](https://www.youtube.com/watch?v=s_o8dwzRlu4)
- [Kunal Kushwaha - Kubernetes Tutorial for Beginners | What is Kubernetes? Architecture Simplified!](https://www.youtube.com/watch?v=KVBON1lA9N8)
이것으로 Kubernetes 섹션을 마무리합니다. Kubernetes에 대해 다룰 수 있는 추가 콘텐츠는 매우 많으며 7일 동안 기초적인 지식을 얻을 수 있지만, 사람들은 [100DaysOfKubernetes](https://100daysofkubernetes.io/overview.html)를 통해 심도 있게 살펴볼 수 있습니다.
다음 시간에는 IaC(Infrastructure as Code)와 이것이 데브옵스 관점에서 수행하는 중요한 역할에 대해 살펴보겠습니다.
[Day 56](day56.md)에서 봐요!

43
2023.md
View File

@ -87,9 +87,9 @@ Or contact us via Twitter, my handle is [@MichaelCade1](https://twitter.com/Mich
### Secrets Management
- [✔️] 🕵 35 > [Understanding the Importance of Secrets Management](2023/day35.md)
- [] 🕵 36 > [](2023/day36.md)
- [] 🕵 37 > [](2023/day37.md)
- [] 🕵 38 > [](2023/day38.md)
- [✔️] 🕵 36 > [Securing Secrets with HashiCorp Vault](2023/day36.md)
- [✔️] 🕵 37 > [Working with HashiCorp Vault's Secrets Engines](2023/day37.md)
- [✔️] 🕵 38 > [Increase the Security Posture of Your Organization with Dynamic Credentials](2023/day38.md)
- [] 🕵 39 > [](2023/day39.md)
- [] 🕵 40 > [](2023/day40.md)
- [] 🕵 41 > [](2023/day41.md)
@ -117,12 +117,12 @@ Or contact us via Twitter, my handle is [@MichaelCade1](https://twitter.com/Mich
### Red Hat OpenShift
- [✔️] ⛑️ 56 > [What does Red Hat OpenShift bring to the party? An Overview](2023/day56.md)
- [✔️] ⛑️ 57 > [Understanding the OpenShift Architecture , Installation Methods and Process](2023/day57.md)
- [✔️] ⛑️ 57 > [Understanding the OpenShift Architecture, Installation Methods and Process](2023/day57.md)
- [✔️] ⛑️ 58 > [Deploying Red Hat OpenShift on VMware vSphere](2023/day58.md)
- [] ⛑️ 59 > [Deploying applications and getting a handle on Security Constraints Context (SCC)](2023/day59.md)
- [] ⛑️ 60 > [](2023/day60.md)
- [] ⛑️ 61 > [](2023/day61.md)
- [] ⛑️ 62 > [](2023/day62.md)
- [✔️] ⛑️ 59 > [Deploying applications and getting a handle on Security Constraints Context (SCC)](2023/day59.md)
- [✔️] ⛑️ 60 > [Looking at OpenShift Projects - Creation, Configuration and Governance](2023/day60.md)
- [✔️] ⛑️ 61 > [Understanding Authentication, Role-Based Access Control (RBAC) and Auditing in Red Hat OpenShift: Control and Secure Your Cluster](2023/day61.md)
- [✔️] ⛑️ 62 > [Compliance and Vulnerability Scanning provided by Red Hat OpenShift Operators](2023/day62.md)
### Databases
@ -146,20 +146,21 @@ Or contact us via Twitter, my handle is [@MichaelCade1](https://twitter.com/Mich
### Service Mesh
- [] 🧩 77 > [](2023/day77.md)
- [] 🧩 78 > [](2023/day78.md)
- [] 🧩 79 > [](2023/day79.md)
- [] 🧩 80 > [](2023/day80.md)
- [] 🧩 81 > [](2023/day81.md)
- [] 🧩 82 > [](2023/day82.md)
- [] 🧩 83 > [](2023/day83.md)
- [✔️] 🧩 77 > [Let's break down a Service Mesh](2023/day77.md)
- [✔️] 🧩 78 > [Install and Test a Service Mesh](2023/day78.md)
- [✔️] 🧩 79 > [Comparing Different Service Meshes](2023/day79.md)
- [✔️] 🧩 80 > [Traffic Engineering Basics](2023/day80.md)
- [✔️] 🧩 81 > [Observability in your Mesh](2023/day81.md)
- [✔️] 🧩 82 > [Securing your microservices](2023/day82.md)
- [✔️] 🧩 83 > [Sidecar or Sidecar-less? Enter Ambient Mesh](2023/day83.md)
### Engineering for Day 2 Ops
- [✔] 👷🏻‍♀️ 84 > [Writing an API - What is an API?](2023/day84.md)
- [] 👷🏻‍♀️ 85 > [](2023/day85.md)
- [] 👷🏻‍♀️ 86 > [](2023/day86.md)
- [] 👷🏻‍♀️ 87 > [](2023/day87.md)
- [] 👷🏻‍♀️ 88 > [](2023/day88.md)
- [] 👷🏻‍♀️ 89 > [](2023/day89.md)
- [] 👷🏻‍♀️ 84 > [Writing an API - What is an API?](2023/day84.md)
- [] 👷🏻‍♀️ 85 > [Queues, Queue workers and Tasks (Asynchronous architecture)](2023/day85.md)
- [] 👷🏻‍♀️ 86 > [Designing for Resilience, Redundancy and Reliability](2023/day86.md)
- [] 👷🏻‍♀️ 87 > [Zero Downtime Deployments](2023/day87.md)
- [] 👷🏻‍♀️ 88 > [Monitoring, Alerting and On-Call](2023/day88.md)
- [] 👷🏻‍♀️ 89 > [Oops: When something goes wrong - Post Mortems](2023/day89.md)
- [] 👷🏻‍♀️ 90 > [](2023/day90.md)

BIN
2023/.DS_Store vendored Normal file
View File

Binary file not shown.

2
2023/day04.md
View File

@ -80,4 +80,6 @@ Also please add any additional resources.
- [Introducing the InfoSec colour wheel — blending developers with red and blue security teams.](https://hackernoon.com/introducing-the-infosec-colour-wheel-blending-developers-with-red-and-blue-security-teams-6437c1a07700)
See you on [Day 5](day05.md).

17
2023/day2-ops-code/async/generator/Dockerfile Normal file
View File

@ -0,0 +1,17 @@
# Set the base image to use
FROM golang:1.17-alpine
# Set the working directory inside the container
WORKDIR /app
# Copy the source code into the container
COPY . .
# Build the Go application
RUN go build -o main .
# Expose the port that the application will run on
EXPOSE 8080
# Define the command that will run when the container starts
CMD ["/app/main"]

17
2023/day2-ops-code/async/generator/go.mod Normal file
View File

@ -0,0 +1,17 @@
module main
go 1.20
require (
github.com/go-sql-driver/mysql v1.7.0
github.com/nats-io/nats.go v1.24.0
)
require (
github.com/golang/protobuf v1.5.3 // indirect
github.com/nats-io/nats-server/v2 v2.9.15 // indirect
github.com/nats-io/nkeys v0.3.0 // indirect
github.com/nats-io/nuid v1.0.1 // indirect
golang.org/x/crypto v0.6.0 // indirect
google.golang.org/protobuf v1.30.0 // indirect
)

32
2023/day2-ops-code/async/generator/go.sum Normal file
View File

@ -0,0 +1,32 @@
github.com/go-sql-driver/mysql v1.7.0 h1:ueSltNNllEqE3qcWBTD0iQd3IpL/6U+mJxLkazJ7YPc=
github.com/go-sql-driver/mysql v1.7.0/go.mod h1:OXbVy3sEdcQ2Doequ6Z5BW6fXNQTmx+9S1MCJN5yJMI=
github.com/golang/protobuf v1.5.0/go.mod h1:FsONVRAS9T7sI+LIUmWTfcYkHO4aIWwzhcaSAoJOfIk=
github.com/golang/protobuf v1.5.3 h1:KhyjKVUg7Usr/dYsdSqoFveMYd5ko72D+zANwlG1mmg=
github.com/golang/protobuf v1.5.3/go.mod h1:XVQd3VNwM+JqD3oG2Ue2ip4fOMUkwXdXDdiuN0vRsmY=
github.com/google/go-cmp v0.5.5/go.mod h1:v8dTdLbMG2kIc/vJvl+f65V22dbkXbowE6jgT/gNBxE=
github.com/klauspost/compress v1.16.0 h1:iULayQNOReoYUe+1qtKOqw9CwJv3aNQu8ivo7lw1HU4=
github.com/minio/highwayhash v1.0.2 h1:Aak5U0nElisjDCfPSG79Tgzkn2gl66NxOMspRrKnA/g=
github.com/nats-io/jwt/v2 v2.3.0 h1:z2mA1a7tIf5ShggOFlR1oBPgd6hGqcDYsISxZByUzdI=
github.com/nats-io/nats-server/v2 v2.9.15 h1:MuwEJheIwpvFgqvbs20W8Ish2azcygjf4Z0liVu2I4c=
github.com/nats-io/nats-server/v2 v2.9.15/go.mod h1:QlCTy115fqpx4KSOPFIxSV7DdI6OxtZsGOL1JLdeRlE=
github.com/nats-io/nats.go v1.24.0 h1:CRiD8L5GOQu/DcfkmgBcTTIQORMwizF+rPk6T0RaHVQ=
github.com/nats-io/nats.go v1.24.0/go.mod h1:dVQF+BK3SzUZpwyzHedXsvH3EO38aVKuOPkkHlv5hXA=
github.com/nats-io/nkeys v0.3.0 h1:cgM5tL53EvYRU+2YLXIK0G2mJtK12Ft9oeooSZMA2G8=
github.com/nats-io/nkeys v0.3.0/go.mod h1:gvUNGjVcM2IPr5rCsRsC6Wb3Hr2CQAm08dsxtV6A5y4=
github.com/nats-io/nuid v1.0.1 h1:5iA8DT8V7q8WK2EScv2padNa/rTESc1KdnPw4TC2paw=
github.com/nats-io/nuid v1.0.1/go.mod h1:19wcPz3Ph3q0Jbyiqsd0kePYG7A95tJPxeL+1OSON2c=
golang.org/x/crypto v0.0.0-20210314154223-e6e6c4f2bb5b/go.mod h1:T9bdIzuCu7OtxOm1hfPfRQxPLYneinmdGuTeoZ9dtd4=
golang.org/x/crypto v0.6.0 h1:qfktjS5LUO+fFKeJXZ+ikTRijMmljikvG68fpMMruSc=
golang.org/x/crypto v0.6.0/go.mod h1:OFC/31mSvZgRz0V1QTNCzfAI1aIRzbiufJtkMIlEp58=
golang.org/x/net v0.0.0-20210226172049-e18ecbb05110/go.mod h1:m0MpNAwzfU5UDzcl9v0D8zg8gWTRqZa9RBIspLL5mdg=
golang.org/x/sys v0.0.0-20201119102817-f84b799fce68/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
golang.org/x/sys v0.5.0 h1:MUK/U/4lj1t1oPg0HfuXDN/Z1wv31ZJ/YcPiGccS4DU=
golang.org/x/term v0.0.0-20201126162022-7de9c90e9dd1/go.mod h1:bj7SfCRtBDWHUb9snDiAeCFNEtKQo2Wmx5Cou7ajbmo=
golang.org/x/text v0.3.3/go.mod h1:5Zoc/QRtKVWzQhOtBMvqHzDpF6irO9z98xDceosuGiQ=
golang.org/x/time v0.3.0 h1:rg5rLMjNzMS1RkNLzCG38eapWhnYLFYXDXj2gOlr8j4=
golang.org/x/tools v0.0.0-20180917221912-90fa682c2a6e/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ=
golang.org/x/xerrors v0.0.0-20191204190536-9bdfabe68543/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0=
google.golang.org/protobuf v1.26.0-rc.1/go.mod h1:jlhhOSvTdKEhbULTjvd4ARK9grFBp09yW+WbY/TyQbw=
google.golang.org/protobuf v1.26.0/go.mod h1:9q0QmTI4eRPtz6boOQmLYwt+qCgq0jsYwAQnmE0givc=
google.golang.org/protobuf v1.30.0 h1:kPPoIgf3TsEvrm0PFe15JQ+570QVxYzEvvHqChK+cng=
google.golang.org/protobuf v1.30.0/go.mod h1:HV8QOd/L58Z+nl8r43ehVNZIU/HEI6OcFqwMG9pJV4I=

100
2023/day2-ops-code/async/generator/main.go Normal file
View File

@ -0,0 +1,100 @@
package main
import (
"database/sql"
"fmt"
_ "github.com/go-sql-driver/mysql"
nats "github.com/nats-io/nats.go"
"math/rand"
"time"
)
func generateAndStoreString() (string, error) {
// Connect to the database
db, err := sql.Open("mysql", "root:password@tcp(mysql:3306)/mysql")
if err != nil {
return "", err
}
defer db.Close()
// Generate a random string
// Define a string of characters to use
characters := "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789"
// Generate a random string of length 10
randomString := make([]byte, 64)
for i := range randomString {
randomString[i] = characters[rand.Intn(len(characters))]
}
// Insert the random number into the database
_, err = db.Exec("INSERT INTO generator_async(random_string) VALUES(?)", string(randomString))
if err != nil {
return "", err
}
fmt.Printf("Random string %s has been inserted into the database\n", string(randomString))
return string(randomString), nil
}
func main() {
err := createGeneratordb()
if err != nil {
panic(err.Error())
}
nc, _ := nats.Connect("nats://my-nats:4222")
defer nc.Close()
nc.Subscribe("generator", func(msg *nats.Msg) {
s, err := generateAndStoreString()
if err != nil {
print(err)
}
nc.Publish("generator_reply", []byte(s))
nc.Publish("confirmation", []byte(s))
})
nc.Subscribe("confirmation_reply", func(msg *nats.Msg) {
stringReceived(string(msg.Data))
})
// Subscribe to the queue
// when a message comes in call generateAndStoreString() then put the string on the
// reply queue. also add a message onto the confirmation queue
// subscribe to the confirmation reply queue
// when a message comes in call
for {
time.Sleep(1 * time.Second)
}
}
func createGeneratordb() error {
db, err := sql.Open("mysql", "root:password@tcp(mysql:3306)/mysql")
if err != nil {
return err
}
defer db.Close()
// try to create a table for us
_, err = db.Exec("CREATE TABLE IF NOT EXISTS generator_async(random_string VARCHAR(100), seen BOOLEAN, requested BOOLEAN)")
return err
}
func stringReceived(input string) {
// Connect to the database
db, err := sql.Open("mysql", "root:password@tcp(mysql:3306)/mysql")
if err != nil {
print(err)
}
defer db.Close()
_, err = db.Exec("UPDATE generator_async SET requested = true WHERE random_string = ?", input)
if err != nil {
print(err)
}
}

69
2023/day2-ops-code/async/k8s.yaml Normal file
View File

@ -0,0 +1,69 @@
apiVersion: apps/v1
kind: Deployment
metadata:
name: requestor
spec:
replicas: 1
selector:
matchLabels:
app: requestor
template:
metadata:
labels:
app: requestor
spec:
containers:
- name: requestor
image: heyal/requestor:async
imagePullPolicy: Always
ports:
- containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
name: requestor-service
spec:
selector:
app: requestor
ports:
- name: http
protocol: TCP
port: 8080
targetPort: 8080
type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: generator
spec:
replicas: 1
selector:
matchLabels:
app: generator
template:
metadata:
labels:
app: generator
spec:
containers:
- name: generator
image: heyal/generator:async
imagePullPolicy: Always
ports:
- containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
name: generator-service
spec:
selector:
app: generator
ports:
- name: http
protocol: TCP
port: 8080
targetPort: 8080
type: ClusterIP

17
2023/day2-ops-code/async/requestor/Dockerfile Normal file
View File

@ -0,0 +1,17 @@
# Set the base image to use
FROM golang:1.17-alpine
# Set the working directory inside the container
WORKDIR /app
# Copy the source code into the container
COPY . .
# Build the Go application
RUN go build -o main .
# Expose the port that the application will run on
EXPOSE 8080
# Define the command that will run when the container starts
CMD ["/app/main"]

17
2023/day2-ops-code/async/requestor/go.mod Normal file
View File

@ -0,0 +1,17 @@
module main
go 1.20
require (
github.com/go-sql-driver/mysql v1.7.0
github.com/nats-io/nats.go v1.24.0
)
require (
github.com/golang/protobuf v1.5.3 // indirect
github.com/nats-io/nats-server/v2 v2.9.15 // indirect
github.com/nats-io/nkeys v0.3.0 // indirect
github.com/nats-io/nuid v1.0.1 // indirect
golang.org/x/crypto v0.6.0 // indirect
google.golang.org/protobuf v1.30.0 // indirect
)

32
2023/day2-ops-code/async/requestor/go.sum Normal file
View File

@ -0,0 +1,32 @@
github.com/go-sql-driver/mysql v1.7.0 h1:ueSltNNllEqE3qcWBTD0iQd3IpL/6U+mJxLkazJ7YPc=
github.com/go-sql-driver/mysql v1.7.0/go.mod h1:OXbVy3sEdcQ2Doequ6Z5BW6fXNQTmx+9S1MCJN5yJMI=
github.com/golang/protobuf v1.5.0/go.mod h1:FsONVRAS9T7sI+LIUmWTfcYkHO4aIWwzhcaSAoJOfIk=
github.com/golang/protobuf v1.5.3 h1:KhyjKVUg7Usr/dYsdSqoFveMYd5ko72D+zANwlG1mmg=
github.com/golang/protobuf v1.5.3/go.mod h1:XVQd3VNwM+JqD3oG2Ue2ip4fOMUkwXdXDdiuN0vRsmY=
github.com/google/go-cmp v0.5.5/go.mod h1:v8dTdLbMG2kIc/vJvl+f65V22dbkXbowE6jgT/gNBxE=
github.com/klauspost/compress v1.16.0 h1:iULayQNOReoYUe+1qtKOqw9CwJv3aNQu8ivo7lw1HU4=
github.com/minio/highwayhash v1.0.2 h1:Aak5U0nElisjDCfPSG79Tgzkn2gl66NxOMspRrKnA/g=
github.com/nats-io/jwt/v2 v2.3.0 h1:z2mA1a7tIf5ShggOFlR1oBPgd6hGqcDYsISxZByUzdI=
github.com/nats-io/nats-server/v2 v2.9.15 h1:MuwEJheIwpvFgqvbs20W8Ish2azcygjf4Z0liVu2I4c=
github.com/nats-io/nats-server/v2 v2.9.15/go.mod h1:QlCTy115fqpx4KSOPFIxSV7DdI6OxtZsGOL1JLdeRlE=
github.com/nats-io/nats.go v1.24.0 h1:CRiD8L5GOQu/DcfkmgBcTTIQORMwizF+rPk6T0RaHVQ=
github.com/nats-io/nats.go v1.24.0/go.mod h1:dVQF+BK3SzUZpwyzHedXsvH3EO38aVKuOPkkHlv5hXA=
github.com/nats-io/nkeys v0.3.0 h1:cgM5tL53EvYRU+2YLXIK0G2mJtK12Ft9oeooSZMA2G8=
github.com/nats-io/nkeys v0.3.0/go.mod h1:gvUNGjVcM2IPr5rCsRsC6Wb3Hr2CQAm08dsxtV6A5y4=
github.com/nats-io/nuid v1.0.1 h1:5iA8DT8V7q8WK2EScv2padNa/rTESc1KdnPw4TC2paw=
github.com/nats-io/nuid v1.0.1/go.mod h1:19wcPz3Ph3q0Jbyiqsd0kePYG7A95tJPxeL+1OSON2c=
golang.org/x/crypto v0.0.0-20210314154223-e6e6c4f2bb5b/go.mod h1:T9bdIzuCu7OtxOm1hfPfRQxPLYneinmdGuTeoZ9dtd4=
golang.org/x/crypto v0.6.0 h1:qfktjS5LUO+fFKeJXZ+ikTRijMmljikvG68fpMMruSc=
golang.org/x/crypto v0.6.0/go.mod h1:OFC/31mSvZgRz0V1QTNCzfAI1aIRzbiufJtkMIlEp58=
golang.org/x/net v0.0.0-20210226172049-e18ecbb05110/go.mod h1:m0MpNAwzfU5UDzcl9v0D8zg8gWTRqZa9RBIspLL5mdg=
golang.org/x/sys v0.0.0-20201119102817-f84b799fce68/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
golang.org/x/sys v0.5.0 h1:MUK/U/4lj1t1oPg0HfuXDN/Z1wv31ZJ/YcPiGccS4DU=
golang.org/x/term v0.0.0-20201126162022-7de9c90e9dd1/go.mod h1:bj7SfCRtBDWHUb9snDiAeCFNEtKQo2Wmx5Cou7ajbmo=
golang.org/x/text v0.3.3/go.mod h1:5Zoc/QRtKVWzQhOtBMvqHzDpF6irO9z98xDceosuGiQ=
golang.org/x/time v0.3.0 h1:rg5rLMjNzMS1RkNLzCG38eapWhnYLFYXDXj2gOlr8j4=
golang.org/x/tools v0.0.0-20180917221912-90fa682c2a6e/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ=
golang.org/x/xerrors v0.0.0-20191204190536-9bdfabe68543/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0=
google.golang.org/protobuf v1.26.0-rc.1/go.mod h1:jlhhOSvTdKEhbULTjvd4ARK9grFBp09yW+WbY/TyQbw=
google.golang.org/protobuf v1.26.0/go.mod h1:9q0QmTI4eRPtz6boOQmLYwt+qCgq0jsYwAQnmE0givc=
google.golang.org/protobuf v1.30.0 h1:kPPoIgf3TsEvrm0PFe15JQ+570QVxYzEvvHqChK+cng=
google.golang.org/protobuf v1.30.0/go.mod h1:HV8QOd/L58Z+nl8r43ehVNZIU/HEI6OcFqwMG9pJV4I=

108
2023/day2-ops-code/async/requestor/main.go Normal file
View File

@ -0,0 +1,108 @@
package main
import (
"database/sql"
"errors"
"fmt"
_ "github.com/go-sql-driver/mysql"
nats "github.com/nats-io/nats.go"
"time"
)
func storeString(input string) error {
// Connect to the database
db, err := sql.Open("mysql", "root:password@tcp(mysql:3306)/mysql")
defer db.Close()
// Insert the random number into the database
_, err = db.Exec("INSERT INTO requestor_async(random_string) VALUES(?)", input)
if err != nil {
return err
}
fmt.Printf("Random string %s has been inserted into the database\n", input)
return nil
}
func getStringFromDB(input string) error {
// see if the string exists in the db, if so return nil
// if not, return an error
db, err := sql.Open("mysql", "root:password@tcp(mysql:3306)/mysql")
defer db.Close()
result, err := db.Query("SELECT * FROM requestor_async WHERE random_string = ?", input)
if err != nil {
return err
}
for result.Next() {
var randomString string
err = result.Scan(&randomString)
if err != nil {
return err
}
if randomString == input {
return nil
}
}
return errors.New("string not found")
}
func main() {
err := createRequestordb()
if err != nil {
panic(err.Error())
}
// setup a goroutine loop calling the generator every minute, saving the result in the DB
nc, _ := nats.Connect("nats://my-nats:4222")
defer nc.Close()
ticker := time.NewTicker(60 * time.Second)
quit := make(chan struct{})
go func() {
for {
select {
case <-ticker.C:
nc.Publish("generator", []byte(""))
case <-quit:
ticker.Stop()
return
}
}
}()
nc.Subscribe("generator_reply", func(msg *nats.Msg) {
err := storeString(string(msg.Data))
if err != nil {
print(err)
}
})
nc.Subscribe("confirmation", func(msg *nats.Msg) {
err := getStringFromDB(string(msg.Data))
if err != nil {
print(err)
}
nc.Publish("confirmation_reply", []byte(string(msg.Data)))
})
// create a goroutine here to listen for messages on the queue to check, see if we have them
for {
time.Sleep(10 * time.Second)
}
}
func createRequestordb() error {
db, err := sql.Open("mysql", "root:password@tcp(mysql:3306)/mysql")
if err != nil {
return err
}
defer db.Close()
// try to create a table for us
_, err = db.Exec("CREATE TABLE IF NOT EXISTS requestor_async(random_string VARCHAR(100))")
return err
}

2
2023/day2-ops-code/buildpush.sh Executable file
View File

@ -0,0 +1,2 @@
docker build ./async/requestor/ -f async/requestor/Dockerfile -t heyal/requestor:async && docker push heyal/requestor:async
docker build ./async/generator/ -f async/generator/Dockerfile -t heyal/generator:async&& docker push heyal/generator:async

49
2023/day36.md
View File

@ -0,0 +1,49 @@
# Securing Secrets with HashiCorp Vault
 
In the world of secrets management, HashiCorp Vault tends to be the de facto standard, especially when it comes to DevOps environments. Tools such as Jenkins, Terraform, or even Kubernetes have tight integrations with Vault that allow you to securely store and retrieve secrets from your infrastructure as code pipelines. With a fully featured REST API, it's relatively simple to integrate into your existing workflows. As a result, secrets are consolidated and retrieved from a secure platform, all while improving your organization's security posture.
 
## Deploying a Simple Vault Environment
 
You have plenty of options when you need to get started with HashiCorp Vault. Depending on your skill set and available environment, Vault can be deployed on a physical server, a virtual machine (Amazon EC2, VMware vSphere, etc.), or in a containerized environment like Docker or Kubernetes. You can even launch Vault on a laptop/desktop if you just want to play around with a temporary instance using Vault "dev" mode. Regardless of your preference, integrating Vault with your applications and pipelines will be very similar.
 
## Deploy Vault on Kubernetes
 
When it comes to deploying Vault on Kubernetes, HashiCorp has made it incredibly simple by providing an official Helm chart. This [Helm chart](https://github.com/hashicorp/vault-helm) can be customized per your needs and can allow you to simply "install" an entire Vault environment right to your k8s cluster. Personally, I prefer [minikube](https://minikube.sigs.k8s.io/docs/start/) on my local machine to quickly launch a k8s cluster and, ultimately, quickly deploy a Vault environment to use for testing. If you want an example of a customized Helm chart, check out this [simple example](https://github.com/btkrausen/hashicorp/blob/master/vault/k8s/values.yml) on my GitHub, which was written for an OpenShift environment. More advanced configurations can be added, but this example should get you up and running quickly.
 
## Deploying on Virtual Machines
 
If Kubernetes isn't your thing, Vault also works flawlessly on traditional virtual machines. It's not as simple as a Helm chart, but having scripts and productional-level configuration files does simplify the process. From different Linux distros to Windows, you can choose almost any operating system you're comfortable with to run Vault in your environment. The Vault binary can be downloaded from the [HashiCorp releases page](https://releases.hashicorp.com/vault). This site makes it easy to download Vault manually or through automated means. Vault simply needs to be placed in your **$PATH** to start using it.
 
Beyond installing Vault, there are additional requirements that you'll want to consider. These requirements are similar to what you would need when running any service on a server, such as configuration files, service files, etc. The following are some of the requirements to consider:
* A [Vault configuration file](https://github.com/btkrausen/hashicorp/blob/master/vault/scripts/install_vault.sh) for each server
* A [system](https://github.com/btkrausen/hashicorp/blob/master/vault/config_files/vault.service) (or similar) file to manage the service (start, stop, etc.)
* Directory to store config files and logs
* A local, non-root user to run the Vault service
* Permissions/ownership of the directories for the user
 
As somebody who has worked on Vault for over six years and a dedicated member of the HashiCorp community, I have all of this on [my GitHub](https://github.com/btkrausen/hashicorp) for your consumption. These are files that I use for production-level deployments, so they are tried and tested in the real world. Feel free to use these as a starting point and customize them per your needs.
 
> If all this seems confusing, you can check out my [Getting Started with HashiCorp Vault Course](https://btk.me/v) to learn all about these configurations (and so much more!), along with getting access to hands-on labs.
 
## Vault is Up and Running. What's Next?
 
Once you have Vault up and running, there are a few steps to complete before integrating your workflows and applications. When any Vault cluster is first started, it needs to be initialized. In short, initialization is when Vault creates the encryption key, unseal or recovery keys, and prepares the storage backend for you. The simplest way to initialize a cluster is to use the 'vault operator init' command. If you're doing this in a production environment, consider encrypting the resulting unseal/recovery keys using PGP keys to ensure no one person has access to all the keys to the kingdom (pun intended!). Check out [my video here](https://youtu.be/QErHqzGH1mk) to see how to perform this step securely. Vault initialization will also return the initial root token, which, at this point, is the ONLY authentication mechanism to gain access to Vault.
![](images/day36-1.png)
Once Vault is initialized, you're only one step away from consuming all the goodness Vault has to offer. If you decided to use auto unseal, you're already there! Without auto unseal, Vault needs to be unsealed. Unsealing is the process of reconstructing the root key used to decrypt the encryption key, which is ultimately stored in memory and used to read/write data to the storage backend. If Vault is sealed, it's essentially useless, so this is an important step. You can use the 'vault operator unseal' command to unseal Vault. Vault will request an 'unseal key,' which was returned during the initialization process discussed above. Perform this step three times (assuming the defaults) to unseal Vault. By the way, you can [migrate to an auto unseal mechanism](https://youtu.be/HolUACQutpk) when you're ready. Once Vault is unsealed, we can start configuring the various components, such as auth methods, secrets engines, and audit devices. More on those on a later day!
![](images/day36-2.png)
 
Before wrapping up the day, there are a few additional topics I wanted to mention and discuss. Some aren't required for a lab environment but should be considered (or required!) for a production environment:
 
* Use TLS everywhere. Go ahead and mint a certificate from a trusted (internal) CA and practice good security from the start. If you like running vulnerable and insecure environments, or if you are running in a lab or for testing purposes, Vault supports disabling TLS by setting 'tls_disable = true' in the configuration file (listener
stanza).
 
* Using a root token gives you complete, unrestricted access to anything in Vault. The root token is highly privileged and should NOT be shared. In fact, it is not evaluated against any Vault policies. Therefore, it is recommended to use the root token to perform the initial configuration, namely auth methods, and then the token should be revoked. [Another root token can be generated](https://youtu.be/rcQsNinVl0Y) in the future if needed.
 
* A single Vault node may be sufficient for lab environments if redundancy and high availability aren't a concern. If service uptime is essential, use a minimum of 3 nodes (assuming integrated storage). I recommend five nodes for production clusters to give you n + 2 redundancy, meaning you can lose up to two nodes, and the Vault service remains functional.
See you on [Day 37](day37.md).

86
2023/day37.md
View File

@ -0,0 +1,86 @@
# Working with HashiCorp Vault's Secrets Engines
While there are multiple components in HashiCorp Vault that are important, none are more foundational than secrets engines. That's because secrets engines are responsible for providing the functionality that you want from Vault. All other components, such as auth methods, audit devices, and storage backends, can be viewed as supporting components and ultimately provide the mechanism to get to a secrets engine.
## Enabling a Secrets Engine
By default, Vault does not enable any secrets engines. Therefore, any functionality needed from a secrets engine requires that you enable it. You can enable as many secrets engines as you need and enable many secrets engines of the same type (as long as they are enabled on different paths), which is very common with Vault customers. Many will enable 10s or 100s of the key/value secrets engine to segregate secrets by a team, business unit, or application. Or you can use a single key/value secrets engine and separate each team under it. It's totally up to you or whatever works for your organization.
Since secrets engines are the core functionality of Vault, HashiCorp has included many secrets engines out of the box. You can use a community or vendor-supported plugin if you need additional functionality. An example of the most prevalent secrets engines that Vault supports include:
• Key/Value – store and retrieve static, long-lived credentials
• PKI – configure Vault as an intermediate/issuing CA to automate TLS certificates
• Transit – centralize your encryption workflow across your organization
• AWS/Azure/GCP – dynamically generate AWS credentials to gain access to your accounts
• Database – dynamically generate credentials against your databases
You can use the `vault secrets enable <secret_engine_type>` command to enable a secrets engine. You can also enable and configure many secrets engines directly in the Vault UI.
![](images/day37-1.png)
## Working with the KV Secrets Engine
As a consultant working on Vault for quite a while, I've yet to work with a customer/client that didn't want to use the Key/Value secrets engine. I attribute this to the fact that most organizations have been using static, long-lived credentials for decades (and probably won't go away anytime soon!) and need a place to securely store them. When working with the key/value secrets engine, remember that it does NOT interact with any external source to replicate/update/retrieve secrets. It's simply a key/value store where you can store, update, and retrieve your credentials through the UI, CLI, or API request.
Let's enable a KV secrets engine (version 2) to see how this works, and we'll start storing and retrieving secrets from it. On the command line, use `vault secrets enable -path=90daysofdevops kv-v2`. This enables the KVv2 secrets engine on the path of `90daysofdevops`, which means that all interactions with this secrets engine will use the `90daysofdevops/` path, such as reading, writing, or updating secrets.
![](images/day37-2.png)
## Writing Data to the KV Secrets Engine
We now have a new, blank key/value store to store our secrets. We can organize these secrets any way that we want beneath this path. Many organizations choose to organize by teams or applications but talk with your team to determine the best structure for your organization. The biggest factor here is simplifying the policies that will permit/deny access to these secrets. If you can write a simple policy or even a templated policy, it will make your Day 2 Ops much easier. In this example, let's assume we have three different teams using this key/value secrets engine, the **cloud** team, the **automation** team, and the **development** team.
Let's write our first secret to the KV secrets engine for the cloud team. Again, like anything else in Vault, you can do this on any of the three Vault interfaces, the UI, CLI, or API. To write a secret, you can use the following command:
`vault kv put 90daysofdevops/cloud/aws secret_key=ABC123 access_key=987zyx`
![](images/day37-3.png)
In this example, we wrote two key/value pairs, one for our _secret_key_ and one for our _access_key_, each with its respective value. The path that these secrets are now stored is `90daysofdevops/data/cloud/aws`. Don't let that _data_ segment fool you. It's necessary when working with the KVv2 secrets engine. The `vault kv put` obfuscates the need to add `data` in our path but this is the path you'll need to retrieve secrets from when reading from the API and when writing policies to access this path.
Let's write some data for the development team. In this scenario, the dev team has decided to organize secrets based on the applications they are responsible for. They need to store a certificate and a private key for application deployment, along with a static database credential for another app.
`vault kv put 90daysofdevops/development/apps/customer-app user=db-admin password=P@ssw0rd1`
`vault kv put 90daysofdevops/development/apps/cache-app cert="----BEGIN CERTIFICATE----asdfwefsadfa23jjklnsdfkl2jns9n2a32sdaffgrsyhgsfwefdsan---END CERTIFICATE----" private_key="---BEGIN PRIVATE KEY----nwljdwsxcvmnrejhq394hdsfjfgadjkhfajkl----END PRIVATE KEY---"`
![](images/day37-4.png)
In this example, we wrote different types of secrets to two different paths:
• `90daysofdevops/development/apps/customer-app`
• `90daysofdevops/development/apps/cache-app`
Again, you and your team should decide how to organize and store the credentials in your organization. It's common that the Vault operators "own" the organization of the paths down to a certain level but then allow the teams to organize their data however they see fit. Different teams are, well, different and likely have different needs.
## Reading Data from the KV Secrets Engine
Ok, now that we have secrets written to our KV secrets engine, it makes sense that we will want to read these secrets. These secrets may be manually retrieved by a developer. They may be retrieved by an Azure DevOps pipeline when a containerized application is provisioned on AKS. Either way, the data is consumed by _something_ and used for deployment or configuration.
When reading a secret, you will use the same path as you used when writing the secret to the KV secrets engine. The path will vary slightly depending on if you're using the CLI vs. API (I know, it's sort of annoying!), but it's not too confusing. API calls must include that _data_ path we mentioned earlier. In this example, we will assume the CLI for now. However, remember that many orchestrators or provisioning tools include native integrations with Vault, such as the Jenkins plugin or AzureDevOps Extensions. GitLab also includes tight integrations to consume the HashiCorp Vault service as well.
To read the secret stored for the cloud team using the Vault CLI, use the following command:
`vault kv get 90daysofdevops/cloud/aws`
![](images/day37-5.png)
Note some of the key components of the response. Vault displays the API path (which includes that _data_ segment), the metadata associated with the secret (because this is a key/value version 2 secrets engine), and the data we want (the secrets!). But what if we want to return ONLY the value of our secret and not include the additional information? We can do that in several ways.
The first way is to use the -field flag on the command line:
`vault kv get -field=secret_key 90daysofdevops/cloud/aws`
![](images/day37-6.png)
In this case, Vault returned ONLY the value for `secret_key`, which may be helpful for an automated job where we don't want to parse through the entire response. The other way we can easily do this is to request the response be JSON-formatted and parse through the data using `jq` to obtain what we need:
`vault kv get -format=json 90daysofdevops/cloud/aws | jq -r '.data.data.secret_key'`
![](images/day37-7.png)
## Summary
I hope that this quick tutorial gave you a glimpse of how you can use Vault's KV secrets engine to write and read data form your applications. There are, of course, lots of additional configurations and settings you can you in the KV secrets engine to improve the security and organization of your data, but this should at least get you started.
> Don't forget to check out my [YouTube channel](https://btk.me/yt) that showcase lots of different configurations for Vault and other tools. Planning to continue to adding more and more content to this channel, so subscribe and let me know what else you want to see.
See you on [Day 38](day38.md).

93
2023/day38.md
View File

@ -0,0 +1,93 @@
# Increase the Security Posture of Your Organization with Dynamic Credentials
As we talked about yesterday, Vault is commonly used as a platform to consolidate your static, long-lived credentials. However, you're still stuck with the management nightmare of rotating those credentials based on your organization's security policies. This credential rotation "tradition" is a manual, laborious task and is susceptible to errors resulting in application downtime. But…
What if you could get rid of static credentials altogether? If your app only needs database access once a week to run reports, why do you give it a credential that is valid 24/7/365? Wouldn't it be great to have your applications generate dynamic, self-destructing credentials on-demand for the systems needed to function?
Well, it's all possible using many of the secrets engines available in Vault.
## Intro to Dynamic Secrets
Dynamic secrets are credentials that are generated on demand on behalf of the requesting Vault client. Rather than simply reading a static credential stored in the KV store, Vault can make an API call to the requested platform, create a credential, and pass the credential back to the user. In the process, Vault attaches a lease (TTL) to the credential, which indicates how long the credential is valid. The Vault client can then use the credential to communicate directly with the platform for its intended function. Once the credential's lease expires, Vault calls back to the platform and deletes the credential, making it invalid.
## Benefits of Using Dynamic Secrets
There are so many benefits of migrating to dynamic credentials. The obvious benefit is not having long-lived credentials that are manually rotated. Because these long-lived credentials are often shared between teams and application stacks, they are more susceptible to misuse or abuse. However, when you migrate to dynamic creds, each application instance can retrieve a unique credential to access the required platform when using dynamic credentials. And if that application instance is terminated (think containerization or auto-scaling), the credential will be invalidated by Vault and not impact other instances or applications in your environment.
Dynamic secrets also eliminate the manual process of rotating credentials. Rather than rotating the credentials once a year, these highly privileged creds are now rotated once a month, once a week, or once every hour. For example, consider how you might use Terraform to deploy resources on your public or private cloud. You likely create a credential on the target platform and use it repeatedly via environment variables or sensitive workspace variables in TFC/TFE. But why are you giving Terraform highly privileged credentials that are valid 24/7/365 when your Terraform runs only take 15 minutes each day? Switch to dynamic credentials. Using a combination of Vault secrets engine and the Vault provider for Terraform, you can have Terraform generate a dynamic credential for the platform it needs to access for resource deployment or management.
## Configure a Dynamic Secrets Engine
With that long-winded introduction out of the way, let's talk about how we can accomplish this goal of using dynamic credentials. HashiCorp Vault offers a plethora of secrets engines that generate dynamic credentials or data, such as:
• AWS
• Azure
• GCP
• Active Directory
• AliCloud
• Consul
• Databases (supports about 15 different database platforms)
• PKI certificates
• Kubernetes
• RabbitMQ
• SSH
• Terraform Cloud
I think you'd agree that's a lot of options for a single platform. The cool thing is that you can use as many of these secrets engines as you want, and even enable many of the same type of secrets engine. Let's take a look at how we would enable one of these, using AWS as the example.
Each secrets engine must be enabled on a path, and all interactions with the secrets engine is then done using the path. Because of this, each secrets engine must be enabled on a unique path so Vault knows where to route the request. To enable a secrets engine, use the following structure for the command `vault secrets enable -path=<name> <secrets_engine_type>`. Enabling the AWS secrets engine on the path of `cloud` would look like this:
`vault secrets engine -path=cloud aws`
> Note that if you do not provide the path flag, the secrets engine will be enabled on the default path, which is the same name of the secrets engine type. For example, the AWS secrets engine would be enabled at aws/.
Ok, so we've got a secrets engine enabled, let's start configuring it. Configuration of a secrets engine generally requires a few things. The first is a way for Vault to communicate with the platform (in this case, AWS). Just like any other AWS client, Vault needs credentials to authenticate to the target platform to perform actions. In the case of AWS, you can provide Vault with an Access Key and Secret Key or use an IAM role if Vault was deployed on AWS.
In addition to authentication, Vault needs the proper authorization to perform actions on the platform. For AWS, that equates to having an IAM policy attached to the credentials you will give to Vault. Depending on the type of credential you want to generate (Vault supports 3 types for AWS), the policy should allow permission to create/manage/delete a user, generate keys, manage the keys, etc. These policies are provided by HashiCorp in their documentation. I also have some pre-defined policies for Vault [on my GitHub](https://github.com/btkrausen/hashicorp).
To provide credentials to Vault to access your AWS account, you can use the following command:
```
vault write aws/config/root \
access_key=AKIAIOSFODNN7EXAMPLE \
secret_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY \
region=us-east-1
```
> Although you can add your credentials using this configuration, you can also provide them using environment variables as well.
Ok, now Vault has access to our AWS account, it doesn't yet know what credentials to create and the level of access those credentials should have in your AWS account. Each unique requirement for credentials will be defined in a role (that's a Vault role, not to be confused with an AWS role). Roles are used to map a user to a set of permissions on the platform. For example, you can create a role for a developer that provides read-only access to the AWS account, or you can create a role for Terraform that provides a broader set of privileges to create, manage, and delete resources. Roles can be used by many applications, but keep in mind that a different role will be required for each UNIQUE set of permissions you want to give the Vault client.
Let's create our first role. This role will be for our developer who needs read-only access to an AWS so they can obtain logs for troubleshooting an application. The role name will be `developer`.
```
vault write aws/roles/developer \
policy_arns=arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess \
credential_type=iam_user
```
> In this example, I used the IAM_USER credential type but for production environments, I'd recommend using ASSUME_ROLE so you can have a
When a developer requests credentials, they will be tied to the AWS-managed policy named ` arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess`. You can use AWS-managed policies, Customer-Managed policies, or simply provide the policy within the Vault role configuration and Vault will create the inline policy when the user is created.
## Let's Get Credentials
Ok, we have the secrets engine mounted (enabled!), the secrets engine configured to access our account, and now we have a role. The next logical step is to test it and obtain our first set of dynamic credentials. Since the role we created is named `developer`, that will come into play for the path needed to get credentials. To get creds, use the following command:
`vault read aws/creds/developer`
If successful, Vault should have returned a set of credentials that the client can use to interact directly with AWS. Woohoo!
Keep in mind that when the lease (TTL) expires, Vault will go back and delete the credentials on AWS, permanently invaliding them.
## Day 2 Ops
The last thing I wanted to touch on was managing the credentials used by Vault to access the platform. The whole purpose of a dynamic secrets engine is to eliminate your static, long-lived credentials. However, the first step here was to provide Vault…..static, long-lived credentials to access the platform? Hmm…sounds somewhat counterproductive, right? What if THAT credential gets compromised or shared?
Fear not, as Vault provides a simple endpoint for secrets engines which allows Vault to quickly rotate that 'root' credential. You can hit this endpoint as often as needed to rotate the credential Vault uses to access the platform. In this example, you can use the following command to rotate the AWS credential we provided above.
`vault write -f aws/config/rotate-root`
Once you run this command, only AWS and Vault know the credentials. No human user has the root credential, and even a Vault administrator can read back the full access key and secret key. This operation can be run as often as needed to meet your internal security policies for credential rotation.
See you on [Day 39](day39.md)

2
2023/day56.md
View File

@ -47,7 +47,7 @@ Again, this is not an exhausive list:
You can read a more indepth coverage of the benefits and features of Red Hat OpenShift in [this datasheet](https://www.redhat.com/en/resources/openshift-container-platform-datasheet), or a full breakdown on the [Red Hat Developers page](https://developers.redhat.com/products/openshift/overview)
![OpenShift Overview](images/cl-OpenShift-container-platform-datasheet-f31593_image1.png)
![OpenShift Overview](images/Day56-OpenShift-container-platform-datasheet.png)
## Where can I deploy OpenShift?

8
2023/day57.md
View File

@ -27,7 +27,7 @@ At a basic level, Red Hat OpenShift if built ontop of the open-source platform,
If you haven't visited the [#90DaysOfDevOps - Kubernetes section](https://github.com/MichaelCade/90DaysOfDevOps/blob/main/2022.md#kubernetes), then I urge you to do so, before continuing with this section on Red Hat OpenShift.
![Red Hat OpenShift - Product Architect](images/Red%20Hat%20OpenShift%20-%20Product%20Architecture.png)
![Red Hat OpenShift - Product Architect](images/Day57%20-%20Red%20Hat%20OpenShift%20Architecture/Red%20Hat%20OpenShift%20-%20Product%20Architecture.png)
Ontop of the Kubernetes platform, Red Hat then delivers it's enterprise sauce sprinkled around to help make your cloud native strategy a sucess:
@ -55,7 +55,7 @@ The below image nicely finishes off this section covering the product and it's c
- Simplification of creating and managing a cluster
- Built in tooling for the Application Developer to create and deploy their applications, with workload lifecycle management included, such as ability to monitor and scale those applications.
![Red Hat OpenShift Container Platform Lifecycle](images/OpenShift%20Container%20Platform%20lifecycle.png)
![Red Hat OpenShift Container Platform Lifecycle](images/Day57%20-%20Red%20Hat%20OpenShift%20Architecture/OpenShift%20Container%20Platform%20lifecycle.png)
For a further deep dive into the control plane architecture, you can read the [official documentation here](https://docs.openshift.com/container-platform/4.12/architecture/control-plane.html).
@ -100,7 +100,7 @@ There is also additional files which may be stored along side the root of the ``
Once you have all of these files, by running the ```openshift-install``` CLI tool, this will create the ignition files for your boostrap, control plane, and compute plane nodes. Returning to the earlier descriptions of RHCOS, these files contain the first boot information to configure the Operation System and start the process of building a consistent Kubernetes cluster with minimal to no interaction.
![OpenShift Container Platform installation targets and dependencies](images/OpenShift%20Container%20Platform%20installation%20targets%20and%20dependencies.png)
![OpenShift Container Platform installation targets and dependencies](images/Day57%20-%20Red%20Hat%20OpenShift%20Architecture/OpenShift%20Container%20Platform%20installation%20targets%20and%20dependencies.png)
## Installer provisioned infrastructure (IPI)
@ -134,7 +134,7 @@ You can find out more from this [Red Hat blog post](How to use the OpenShift Ass
A temporary bootstrap machine is provisioned using IPI or UPI, which contains the necessary information to build the OpenShift cluster itself (which becomes the permanent control plane nodes). Once the control plane is online, the control plane will initiate the creation of the compute plane (worker) nodes.
![Creating the bootstrap, control plane, and compute machines](images/Creating%20the%20bootstrap%20control%20plane%20and%20compute%20machines.png)
![Creating the bootstrap, control plane, and compute machines](images/Day57%20-%20Red%20Hat%20OpenShift%20Architecture/Creating%20the%20bootstrap%20control%20plane%20and%20compute%20machines.png)
Once the control plane is initialised, the bootstrap machine is destroyed. If you are manually provisioning the platform (UPI), then you complete a number of the provisioning steps manually.

6
2023/day58.md
View File

@ -103,7 +103,7 @@ After selecting datastore and the network, I need to now input the address for:
However I hit a bug ([GitHub PR](https://github.com/openshift/installer/pull/6783),[Red Hat Article](https://access.redhat.com/solutions/6994972)) in the installer, where by the software installer is hardcoded to only accept addresses in the 10.0.0.0/16 range.
![OpenShift-Install create cluster - Sorry, your reply was invalid: IP expected to be in one of the machine networks: 10.0.0.0/16](images/Day58%20-%20OpenShift%20Cluster%20Install/OpenShift-Install%20create%20cluster%20-%20Sorry%2C%20your%20reply%20was%20invalid-%20IP%20expected%20to%20be%20in%20one%20of%20the%20machine%20networks-%2010.0.0.0%3A16.jpg)
![OpenShift-Install create cluster - Sorry, your reply was invalid: IP expected to be in one of the machine networks: 10.0.0.0/16](images/Day58%20-%20OpenShift%20Cluster%20Install/OpenShift-Install%20create%20cluster%20-%20Sorry%2C%20your%20reply%20was%20invalid-%20IP%20expected%20to%20be%20in%20one%20of%20the%20machine%20networks-%2010.0.0.0-16.jpg)
The current work around for this is to run ````openshift-install create install-config```` provide ip addresses in the 10.0.0.0/16 range, and then alter the ```install-config.yaml``` file manually before running ````openshift-install create cluster````, which will read the available ```install-config.yaml``` file and create the cluster (rather than presenting you another wizard).
@ -233,7 +233,7 @@ If we now look within our directory where we ran the ```openshift-install``` ins
Below is a screenshot showing the directory, folders and example of my logging output.
![OpenShift-Install - .openshift_install.log output](/images/Day58%20-%20OpenShift%20Cluster%20Install/OpenShift-Install%20create%20cluster%20-%20.openshift_install.log%20output.jpg)
![OpenShift-Install - .openshift_install.log output](images/Day58%20-%20OpenShift%20Cluster%20Install/OpenShift-Install%20create%20cluster%20-%20.openshift_install.log%20output.jpg)
## Connecting to your cluster
@ -287,7 +287,7 @@ INFO Login to the console with user: "kubeadmin", and password: "ur6xT-gxmVW-WVU
````
![Red Hat OpenShift Web Console](images/Day58%20-%20OpenShift%20Cluster%20Install/Red%20Hat%20OpenShift%20Web%20Console.jpg)
Once logged in, you'll view the persona that you have access to (1). In my example, I'm using the kubeadmin account, so I see the administrative view first, and I have the ability to change this to the Developer view as well (see second screenshot).
Once logged in, you'll view the persona that you have access to (1). In my example, I'm using the kubeadmin account, so I see the administrative view first, and I can change this to the Developer view as well (see second screenshot).
Under the left-hand navigation pane (2), you can easily browse all the common areas for platform administration, and view details of the live cluster, as well as make changes to existing configurations, or commit new configurations.

489
2023/day59.md
View File

@ -0,0 +1,489 @@
# Deploying a Sample Application on Red Hat OpenShift: Handling Security Context Constraints (SCC)
On [Day 58](/day58.md) we finished looking around the developer and administrator interfaces of a newly deployed cluster.
In this submission (Day 59), we will walk through the process of deploying a sample MongoDB application to a newly deployed Red Hat OpenShift cluster. However, this deployment will fail due to the default security context constraints (SCC) in OpenShift. We will explain why the deployment fails, how to resolve the issue, and provide a brief overview of SCC in OpenShift with examples.
## Understanding Security Context Constraints (SCC)
Security context constraints in OpenShift are a security feature that allows administrators to control various aspects of the container runtime, such as user and group IDs, SELinux context, and the use of host resources. In Short, SCCs determine which security settings are allowed or disallowed for containerized applications. By default, OpenShift comes with several predefined SCCs, such as ```restricted```, ```anyuid```, and ```hostaccess```. These SCCs serve as templates for creating custom SCCs to meet specific security requirements.
> Warning: Do not modify the default SCCs. Customizing the default SCCs can lead to issues when some of the platform pods deploy or OpenShift Container Platform is upgraded. Additionally, the default SCC values are reset to the defaults during some cluster upgrades, which discards all customizations to those SCCs. Instead of modifying the default SCCs, create and modify your own SCCs as needed.
For example, the restricted SCC (default for most deployments, or restricted-v2 for new installs of OCP 4.11 and later) does not allow containers to run as root or with privileged access, while the ```anyuid``` SCC permits containers to run with any user ID, including root. By creating custom SCCs and granting them to service accounts or users, administrators can ensure that applications adhere to the desired security policies without compromising functionality.
Security context constraints allow an administrator to control:
- Whether a pod can run privileged containers with the allowPrivilegedContainer flag
- Whether a pod is constrained with the allowPrivilegeEscalation flag
- The capabilities that a container can request
- The use of host directories as volumes
- The SELinux context of the container
- The container user ID
- The use of host namespaces and networking
- The allocation of an FSGroup that owns the pod volumes
- The configuration of allowable supplemental groups
- Whether a container requires to write access to its root file system
- The usage of volume types
- The configuration of allowable seccomp profiles
To learn more details about what each of the out-of-the-box default security context constraints does, see [this official documentation page](https://docs.openshift.com/container-platform/4.12/authentication/managing-security-context-constraints.html#default-sccs_configuring-internal-oauth).
![Red Hat OpenShift - oc get scc](/2023/images/day59-Red%20Hat%20OpenShift%20-%20oc%20get%20scc.jpg)
### Anatomy of a Security Context Constraint configuration
SCCs consist of settings and strategies that control the security features that a pod has access to. These settings fall into three categories:
- Controlled by a boolean
- Fields of this type default to the most restrictive value. For example;
- ```AllowPrivilegedContainer``` is always set to ```false``` if unspecified.
- Controlled by an allowable set
- Fields of this type are checked against the set to ensure their value is allowed.
- Controlled by a strategy
- Items that have a strategy to generate a value provide:
- A mechanism to generate the value, and
- A mechanism to ensure that a specified value falls into the set of allowable values.
CRI-O has the following [default list of capabilities](https://github.com/cri-o/cri-o/blob/main/docs/crio.conf.5.md#crioruntime-table) that are allowed for each container of a pod:
````
default_capabilities = [
"CHOWN",
"DAC_OVERRIDE",
"FSETID",
"FOWNER",
"SETGID",
"SETUID",
"SETPCAP",
"NET_BIND_SERVICE",
"KILL",
]
````
You can learn more about Linux capabilities [here](https://linuxera.org/container-security-capabilities-seccomp/) and [here](https://man7.org/linux/man-pages/man7/capabilities.7.html). The containers use the capabilities from this default list, but pod manifest authors (the person writing the application YAML for Kubernetes) can alter the list by requesting additional capabilities or removing some of the default behaviors. To control the capabilities allowed or denied for Pods running in the cluster, use the ```allowedCapabilities```, ```defaultAddCapabilities```, and ```requiredDropCapabilities``` parameters in your SCC to control such requests from the pods.
#### Quick Snippet: configuring a pod with capabilities
You can [specify additional capabilities for your pod](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container) as per the below example.
````yaml
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo-4
spec:
containers:
- name: sec-ctx-4
image: gcr.io/google-samples/node-hello:1.0
securityContext:
capabilities:
add: ["NET_ADMIN", "SYS_TIME"]
````
Let's look at some of the default contexts in further detail.
### Example SCC Configurations
1. Restricted SCC:
Denies access to all host features and requires pods to be run with a UID, and SELinux context that are allocated to the namespace.
The restricted-v2 SCC:
Ensures that pods cannot run as privileged
Ensures that pods cannot mount host directory volumes
Requires that a pod is run as a user in a pre-allocated range of UIDs
Requires that a pod is run with a pre-allocated MCS label
Allows pods to use any FSGroup
Allows pods to use any supplemental group
Ensures that no child process of a container can gain more privileges than its parent (AllowPrivilegeEscalation=False)
You can get this SCC configuration by running ```oc get scc restricted-v2 -o yaml```
````yaml
allowHostDirVolumePlugin: false
allowHostIPC: false
allowHostNetwork: false
allowHostPID: false
allowHostPorts: false
allowPrivilegeEscalation: true
allowPrivilegedContainer: false
allowedCapabilities: null
apiVersion: security.openshift.io/v1
defaultAddCapabilities: null
fsGroup:
type: MustRunAs
groups: []
kind: SecurityContextConstraints
metadata:
annotations:
include.release.openshift.io/ibm-cloud-managed: "true"
include.release.openshift.io/self-managed-high-availability: "true"
include.release.openshift.io/single-node-developer: "true"
kubernetes.io/description: restricted denies access to all host features and requires
pods to be run with a UID, and SELinux context that are allocated to the namespace.
release.openshift.io/create-only: "true"
creationTimestamp: "2023-03-16T09:34:36Z"
generation: 1
name: restricted
resourceVersion: "401"
uid: 8ced4b4e-7fed-4369-a0b8-da40880f4a3d
priority: null
readOnlyRootFilesystem: false
requiredDropCapabilities:
- KILL
- MKNOD
- SETUID
- SETGID
runAsUser:
type: MustRunAsRange
seLinuxContext:
type: MustRunAs
supplementalGroups:
type: RunAsAny
users: []
volumes:
- configMap
- downwardAPI
- emptyDir
- ephemeral
- persistentVolumeClaim
- projected
- secret
````
2. Privileged SCC:
Allows access to all privileged and host features and the ability to run as any user, any group, any FSGroup, and with any SELinux context.
The privileged SCC allows:
Users to run privileged pods
Pods to mount host directories as volumes
Pods to run as any user
Pods to run with any MCS label
Pods to use the host’s IPC namespace
Pods to use the host’s PID namespace
Pods to use any FSGroup
Pods to use any supplemental group
Pods to use any seccomp profiles
Pods to request any capabilities
You can get this SCC configuration by running ```oc get scc privileged -o yaml```
````yaml
allowHostDirVolumePlugin: true
allowHostIPC: true
allowHostNetwork: true
allowHostPID: true
allowHostPorts: true
allowPrivilegeEscalation: true
allowPrivilegedContainer: true
allowedCapabilities:
- '*'
allowedUnsafeSysctls:
- '*'
apiVersion: security.openshift.io/v1
defaultAddCapabilities: null
fsGroup:
type: RunAsAny
groups:
- system:cluster-admins
- system:nodes
- system:masters
kind: SecurityContextConstraints
metadata:
annotations:
include.release.openshift.io/ibm-cloud-managed: "true"
include.release.openshift.io/self-managed-high-availability: "true"
include.release.openshift.io/single-node-developer: "true"
kubernetes.io/description: 'privileged allows access to all privileged and host
features and the ability to run as any user, any group, any fsGroup, and with
any SELinux context. WARNING: this is the most relaxed SCC and should be used
only for cluster administration. Grant with caution.'
release.openshift.io/create-only: "true"
creationTimestamp: "2023-03-16T09:34:35Z"
generation: 1
name: privileged
resourceVersion: "398"
uid: 19a16cc2-ce1f-4037-b70e-49ba261cb599
priority: null
readOnlyRootFilesystem: false
requiredDropCapabilities: null
runAsUser:
type: RunAsAny
seLinuxContext:
type: RunAsAny
seccompProfiles:
- '*'
supplementalGroups:
type: RunAsAny
users:
- system:admin
- system:serviceaccount:openshift-infra:build-controller
volumes:
- '*'
````
Now let's look at some specific items from the above YAML:
- **allowedCapabilities:** - A list of capabilities that a pod can request. An empty list means that none of the capabilities can be requested while the special symbol * allows any capabilities.
- **defaultAddCapabilities: []** - A list of additional capabilities that are added to any pod.
- **fsGroup:** - The FSGroup strategy, dictates the allowable values for the security context.
- **groups** - The groups that can access this SCC.
- **requiredDropCapabilities** A list of capabilities to drop from a pod. Or, specify ALL to drop all capabilities.
- **runAsUser:** - The runAsUser strategy type, which dictates the allowable values for the security context.
- **seLinuxContext:** - The seLinuxContext strategy type, dictates the allowable values for the security context.
- **supplementalGroups** - The supplementalGroups strategy, dictates the allowable supplemental groups for the security context.
- **users:** - The users who can access this SCC.
- **volumes:** - The allowable volume types for the security context. In the example, * allows the use of all volume types.
The users and groups fields on the SCC control which users can access the SCC. By default, cluster administrators, nodes, and the build controller are granted access to the privileged SCC. All authenticated users are granted access to the restricted-v2 SCC.
## Let's deploy a sample application
I'm going to deploy some of the basic components of my [trusty Pac-Man application for Kubernetes](https://github.com/saintdle/pacman-tanzu). The MongoDB deployment, PVC and Secret.
First, I need to create the namespace to place the components in, ```oc create ns pacman```.
Now I apply the below YAML file ```oc apply -f mongo-test.yaml```
````yaml
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
name: mongo
name: mongo
namespace: pacman
annotations:
source: "https://github.com/saintdle/pacman-tanzu"
spec:
replicas: 1
selector:
matchLabels:
name: mongo
template:
metadata:
labels:
name: mongo
spec:
initContainers:
- args:
- |
mkdir -p /bitnami/mongodb
chown -R "1001:1001" "/bitnami/mongodb"
command:
- /bin/bash
- -ec
image: docker.io/bitnami/bitnami-shell:10-debian-10-r158
imagePullPolicy: Always
name: volume-permissions
resources: {}
securityContext:
runAsUser: 0
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
volumeMounts:
- mountPath: /bitnami/mongodb
name: mongo-db
restartPolicy: Always
schedulerName: default-scheduler
securityContext:
fsGroup: 1001
serviceAccountName: default
terminationGracePeriodSeconds: 30
volumes:
- name: mongo-db
persistentVolumeClaim:
claimName: mongo-storage
containers:
- image: bitnami/mongodb:4.4.8
name: mongo
env:
- name: MONGODB_ROOT_PASSWORD
valueFrom:
secretKeyRef:
key: database-admin-password
name: mongodb-users-secret
- name: MONGODB_DATABASE
valueFrom:
secretKeyRef:
key: database-name
name: mongodb-users-secret
- name: MONGODB_PASSWORD
valueFrom:
secretKeyRef:
key: database-password
name: mongodb-users-secret
- name: MONGODB_USERNAME
valueFrom:
secretKeyRef:
key: database-user
name: mongodb-users-secret
ports:
- name: mongo
containerPort: 27017
volumeMounts:
- name: mongo-db
mountPath: /bitnami/mongodb/
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: mongo-storage
namespace: pacman
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
---
apiVersion: v1
kind: Secret
metadata:
name: mongodb-users-secret
namespace: pacman
type: Opaque
data:
database-admin-name: Y2x5ZGU=
database-admin-password: Y2x5ZGU=
database-name: cGFjbWFu
database-password: cGlua3k=
database-user: Ymxpbmt5
````
Once applied, I see the following output:
>Warning: would violate PodSecurity "restricted:v1.24": allowPrivilegeEscalation != false (containers "volume-permissions", "mongo" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (containers "volume-permissions", "mongo" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or containers "volume-permissions", "mongo" must set securityContext.runAsNonRoot=true), runAsUser=0 (container "volume-permissions" must not set runAsUser=0), seccompProfile (pod or containers "volume-permissions", "mongo" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
>
>deployment.apps/mongo created
>
>secret/mongodb-users-secret created
If I now inspect the deployment and replicaset in the ```pacman``` namespace, we'll see that's stuck, I have no pods running.
````
# oc get all -n pacman
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/mongo 0/1 0 0 3m9s
NAME DESIRED CURRENT READY AGE
replicaset.apps/mongo-56cc764fb 1 0 0 3m9s
````
## Why the Deployment Fails
The provided Kubernetes application includes an initContainer with the following security context:
````yaml
securityContext:
runAsUser: 0
````
This configuration means that the initContainer will attempt to run as the root user (UID 0). However, OpenShift's default SCCs restrict the use of the root user for security reasons. As a result, the deployment fails because it violates the default security context constraints. The same is true of the other configuration settings mentioned in the above output as well. Remember in OCP 4.11 and later (new installs), the default SCC is the restricted-v2 policy.
## How to Resolve the Issue
To resolve this issue, we need to modify the deployment configuration to comply with the SCC policies in OpenShift. There are several ways to achieve this, but in this example, we will create a custom SCC that allows the initContainer to run as root. Follow these steps:
1. Create a new custom SCC, and save the below YAML in a file called mongo-custom-scc.yaml:
````yaml
apiVersion: security.openshift.io/v1
kind: SecurityContextConstraints
metadata:
name: mongo-custom-scc
allowPrivilegedContainer: false
allowHostNetwork: false
allowHostPorts: false
allowHostPID: false
allowHostIPC: false
runAsUser:
type: RunAsAny
seLinuxContext:
type: MustRunAs
fsGroup:
type: RunAsAny
supplementalGroups:
type: RunAsAny
````
2. Apply the custom SCC to your OpenShift cluster:
````sh
oc apply -f mongo-custom-scc.yaml
````
3. Grant the mongo-custom-scc SCC to the service account that the MongoDB deployment is using:
````sh
oc adm policy add-scc-to-user mongo-custom-scc system:serviceaccount:<namespace>:default
# In my environment, I run:
oc adm policy add-scc-to-user mongo-custom-scc system:serviceaccount:pacman:default
````
Replace <namespace> with the namespace where your MongoDB deployment is located.
4. Redeploy the MongoDB application.
````
# oc scale deploy mongo -n pacman --replicas=0
deployment.apps/mongo scaled
# oc scale deploy mongo -n pacman --replicas=1
deployment.apps/mongo scaled
````
In the real world, the first port of call should always be to work to ensure your containers and applications run with the least privileges necessary and therefore don't need to run as root.
If they do need some sort of privilege, then defining tight RBAC and SCC control in place is key.
# Summary
In this post, we discussed how the default security context constraints in OpenShift can prevent deployments from running as expected. We provided a solution to the specific issue of running an initContainer as root for a MongoDB application. Understanding and managing SCCs in OpenShift is essential for maintaining secure and compliant applications within your cluster.
On [Day 60](/day60.md)](/day60.md), we will look at OpenShift Projects Creation, Configuration and Governance, for example consuming SCC via the project level, and other features of Red Hat OpenShift.
## Resources
- Red Hat OpenShift - [Managing security context constraints](https://docs.openshift.com/container-platform/4.12/authentication/managing-security-context-constraints.html)
- Red Hat Blog - [Managing SCCs in OpenShift](https://cloud.redhat.com/blog/managing-sccs-in-openshift)
- Linuxera - [Capabilities and Seccomp Profiles on Kubernetes](https://linuxera.org/capabilities-seccomp-kubernetes/)
- Red Hat OpenShift - [Important OpenShift changes to Pod Security Standards](https://connect.redhat.com/en/blog/important-openshift-changes-pod-security-standards)
- OCP 4.11 and later - With the introduction of a new built-in admission controller that enforces the [Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/), namespaces and pods can be defined with three different policies: Privileged, Baseline and Restricted. Therefore, pods not configured according to the enforced security standards defined globally, or on the namespace level, will not be admitted and will not run.
- [Pods fail to create due to "allowPrivilegeEscalation: true" in OpenShift 4.11](https://access.redhat.com/solutions/6976492)
- [Using the legacy restricted SCC in OCP 4.11+](https://access.redhat.com/articles/6973044)
- [Role-based access to security context constraints](https://docs.openshift.com/container-platform/4.12/authentication/managing-security-context-constraints.html#role-based-access-to-ssc_configuring-internal-oauth)
- You can specify SCCs as resources that are handled by RBAC. This allows you to scope access to your SCCs to a certain project or to the entire cluster.
- Kubernetes.io - [Configure a Security Context for a Pod or Container](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)

272
2023/day60.md
View File

@ -0,0 +1,272 @@
# OpenShift Projects - Creation, Configuration and Governance
## Understanding OpenShift Projects: How They Differ from Kubernetes Namespaces
Red Hat OpenShift adds many features to simplify and enhance the management of Kubernetes clusters. One such feature is OpenShift Projects, which are similar to Kubernetes Namespaces but with added benefits tailored to the enterprise environment. In this post, we will explore the concept of OpenShift Projects, how they differ from Kubernetes Namespaces, and provide examples of creating and configuring Projects.
### OpenShift Projects: A Brief Overview
OpenShift Projects are an abstraction layer built on top of Kubernetes Namespaces. They provide a convenient way to organize and manage resources within an OpenShift cluster, and they offer additional features such as:
- Simplified multi-tenancy: Projects enable better isolation between users and teams, ensuring that each group works within its own environment without impacting others.
- Access control: Projects facilitate role-based access control (RBAC), allowing administrators to define and manage user permissions at the project level.
- Resource quotas and limits: Projects support setting resource quotas and limits to prevent overconsumption of cluster resources by individual projects.
## Creating and Configuring an OpenShift Project
Let's walk through the process of creating and configuring an OpenShift Project.
1. Create a new project:
To create a new project, use the oc new-project command:
````sh
$ oc new-project my-sample-project --description="My Sample OpenShift Project" --display-name="Sample Project"
````
This command creates a new project called my-sample-project with a description and display name.
2. Switch between projects:
You can switch between projects using the oc project command:
````sh
$ oc project my-sample-project
````
This command sets the active project to my-sample-project.
3. Configure resource quotas:
You can apply resource quotas to your project to limit the consumption of resources. Create a file called resource-quota.yaml with the following content:
````yaml
apiVersion: v1
kind: ResourceQuota
metadata:
name: my-resource-quota
spec:
hard:
requests.cpu: "2"
requests.memory: 2Gi
limits.cpu: "4"
limits.memory: 4Gi
````
## Adding Resource Quotas to projects
To apply the resource quota to your project:
````sh
$ oc apply -f resource-quota.yaml -n my-sample-project
````
This command applies the resource quota to the my-sample-project, limiting the total CPU and memory consumption for the project.
5. Configure role-based access control (RBAC):
To manage access control for your project, you can define and assign roles to users. For example, create a file called developer-role.yaml with the following content:
````yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: developer
rules:
- apiGroups: [""]
resources: ["pods", "services", "configmaps", "persistentvolumeclaims"]
verbs: ["create", "get", "list", "watch", "update", "delete"]
````
Apply the role to your project:
````sh
$ oc apply -f developer-role.yaml -n my-sample-project
````
Now, you can grant the developer role to a specific user:
````sh
$ oc policy add-role-to-user developer my-user -n my-sample-project
````
This command grants the developer role to my-user in the my-sample-project.
## Adding SCC to a project
Remember in [Day 59](/2023/day59.md), we covered the Security Context Contraints, and how they provide security against the workloads we run inside the cluster, in the examples I provided, we fixed the security violation of the workload (pod) by ensuring the Service Account that it uses, is added to the correct SCC policy.
In this example, I'm going to which SCC at the project level, so that any workloads deployed to this project, conform to the correct policy.
1. Create a new project and change to that projects context
````sh
$ oc new-project scc-ns-test
$ oc project ssc-ns-test
````
2. Create a file called ```ngnix.yaml``` with the below content
````yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
selector:
matchLabels:
app: nginx
replicas: 2 # tells deployment to run 2 pods matching the template
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
````
2. Deploy an Ngnix Deployment to this project, and watch for the failure
````sh
$ oc apply -f ngnix.yaml
Warning: would violate PodSecurity "restricted:v1.24": allowPrivilegeEscalation != false (container "nginx" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "nginx" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "nginx" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "nginx" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
deployment.apps/nginx-deployment created
````
As per Day 59's example, the deployment is created, but the pod will not be running.
3. Let's inspect the project's configuration before we continue further
````sh
$ oc get project scc-ns-test -o json
````
````json
{
"apiVersion": "project.openshift.io/v1",
"kind": "Project",
"metadata": {
"annotations": {
"openshift.io/description": "",
"openshift.io/display-name": "",
"openshift.io/requester": "system:admin",
"openshift.io/sa.scc.mcs": "s0:c27,c4",
"openshift.io/sa.scc.supplemental-groups": "1000710000/10000",
"openshift.io/sa.scc.uid-range": "1000710000/10000"
},
"creationTimestamp": "2023-03-29T09:23:18Z",
"labels": {
"kubernetes.io/metadata.name": "scc-ns-test",
"pod-security.kubernetes.io/audit": "restricted",
"pod-security.kubernetes.io/audit-version": "v1.24",
"pod-security.kubernetes.io/warn": "restricted",
"pod-security.kubernetes.io/warn-version": "v1.24"
},
"name": "scc-ns-test",
"resourceVersion": "11247602",
"uid": "3f720113-1e30-4a3f-b97e-48f88735e510"
},
"spec": {
"finalizers": [
"kubernetes"
]
},
"status": {
"phase": "Active"
}
}
````
Note that under ```labels``` section, we have several pod-security settings that are specified by default. That is because the most restrictive policy is applied to namespaces and their workloads by default.
4. Now let's delete our deployment
````sh
$ oc delete -f nginx.yaml
````
5. Let's alter the configuration of this project to consume the ````privileged```` SCC, allowing us to brute force our pod to run. (In the real world, we would create an appropriate SCC and this use, rather than giving workloads god mode type access)
We are going to use the `oc patch` command and pass in the modifications to the labels. There are two ways to achieve this using the patch argument, we can either pass in the changes within the command line in JSON format, or we can pass in a file that is either JSON or YAML content. I'll detail both options below.
This first command passes JSON content as part of the executions to alert the configuration.
````sh
$ oc patch namespace/scc-ns-test -p '{"metadata":{"labels":{"pod-security.kubernetes.io/audit":"privileged","pod-security.kubernetes.io/enforce":"privileged","pod-security.kubernetes.io/warn":"privileged","security.openshift.io/scc.podSecurityLabelSync":"false"}}}'
````
To break this down further, from the above example showing the Project configuration in JSON, we are altering the "audit", "warn" and "enforce" settings for Pod-Security to have the "privileged" value, and we also add a new label called "security.openshift.io/scc.podSecurityLabelSync" with a value of false. This stops the security admission controller from overwriting our changes. As the default SCC enforced is "restricted".
Rather than including the JSON changes in the same command line, which can get very long if you have a lot of changes, you can simply create a JSON or YAML file, containing content such as below and then apply it using the ```--patch-file``` argument.
````yaml
metadata:
labels:
pod-security.kubernetes.io/audit: privileged
pod-security.kubernetes.io/enforce: privileged
pod-security.kubernetes.io/warn: privileged
security.openshift.io/scc.podSecurityLabelSync: false
````
````sh
oc patch namespace/scc-ns-test --patch-file ns-patch.yaml
````
5. Now if we inspect our Project, we will see the changes in effect.
````sh
oc get project scc-ns-test -o json
````
```json
{
"apiVersion": "project.openshift.io/v1",
"kind": "Project",
"metadata": {
"annotations": {
"openshift.io/description": "",
"openshift.io/display-name": "",
"openshift.io/requester": "system:admin",
"openshift.io/sa.scc.mcs": "s0:c27,c4",
"openshift.io/sa.scc.supplemental-groups": "1000710000/10000",
"openshift.io/sa.scc.uid-range": "1000710000/10000"
},
"creationTimestamp": "2023-03-29T09:23:18Z",
"labels": {
"kubernetes.io/metadata.name": "scc-ns-test",
"pod-security.kubernetes.io/audit": "privileged",
"pod-security.kubernetes.io/audit-version": "v1.24",
"pod-security.kubernetes.io/enforce": "privileged",
"pod-security.kubernetes.io/warn": "privileged",
"pod-security.kubernetes.io/warn-version": "v1.24",
"security.openshift.io/scc.podSecurityLabelSync": "false"
},
"name": "scc-ns-test",
"resourceVersion": "11479286",
"uid": "3f720113-1e30-4a3f-b97e-48f88735e510"
},
"spec": {
"finalizers": [
"kubernetes"
]
},
"status": {
"phase": "Active"
}
}
````
6. Redeploy the nginx instances or other containers you've been working with.
# Summary
There is just so much to cover, but hopefully you've now learned that Projects are more than just a Kubernetes Namespace with a different name. One of the areas we didn't cover, is the ability to [control Project creation](https://docs.openshift.com/container-platform/4.12/applications/projects/configuring-project-creation.html) by OpenShift users, either from a governed default template, or simply removing the ability for self-service access to create templates.
On [Day 61](/2023/day61.md), we shall cover the larger subject of RBAC within the cluster, and bring it back to applying access to projects.
## Resources
- Red Hat OpenShift Documentation - Building Applications - [Projects](https://access.redhat.com/documentation/en-us/openshift_container_platform/4.12/html/building_applications/projects#doc-wrapper)

484
2023/day61.md
View File

@ -0,0 +1,484 @@
# Understanding Authentication, Role-Based Access Control (RBAC) and Auditing in Red Hat OpenShift: Control and Secure Your Cluster
In this post, we are going to look at expanding access to our clusters to other users, we've already tackled the more complex subject of Security Contexts, which looks at the permissions that workloads have when they run on the platform, now we turn this focus to the users of the platform.
## Back to Basics: Authentication, Authorization, Accounting
AAA stands for Authentication, Authorization, and Accounting. These are three essential components of IT systems' security and access control. AAA ensures that users are who they claim to be, have the right permissions to access resources, and keep track of their activities within the system. Let's break down each component:
- **Authentication**: This is the process of validating a user's identity when they attempt to access an IT system. Authentication typically involves requesting a user to provide their credentials, such as a username and password, or using other mechanisms like multi-factor authentication (MFA) and single sign-on (SSO).
- **Authorization**: After a user has been authenticated, authorization determines the level of access they have within the system. It controls which resources a user can access and what actions they can perform. This is usually managed by defining roles or permissions and assigning them to users or groups.
- **Accounting**: Also referred to as auditing, is the process of recording and monitoring user activities within an IT system. This includes logging information like when a user logs in, what actions they perform, and what resources they access. Accounting is essential for security, compliance, and troubleshooting purposes.
Together, these three components form the AAA framework that helps IT administrators manage and secure access to their systems, ensuring that only authorized users can access resources and that their actions are logged for auditing purposes.
## Back to Red Hat Openshift: Introduction to Authentication, Access Control and Auditing
Authentication in Red Hat OpenShift is the process of validating the identity of a user or system attempting to access the cluster. OpenShift supports various identity providers (IdPs) for authentication, such as LDAP, GitHub, GitLab, Google, Keystone, and many more. The authentication process in OpenShift 4 is handled by the OAuth server, which is responsible for managing OAuth tokens and interacting with the configured identity providers.
Role-Based Access Control (RBAC) (Authorization) is an essential security feature in Red Hat OpenShift that enables administrators to manage and control access to resources within a cluster.
Red Hat OpenShift uses the Kubernetes audit logging mechanism to perform accounting. The audit logs record requests made to the Kubernetes API server, providing detailed information about the user, resource, action, and outcome. The audit logs are essential for understanding user behavior, detecting security incidents, and meeting compliance requirements.
## Configuring an Identity provider for Authorization
Before we dig into any RBAC configurations, we need to start by giving our OpenShift cluster some form of identity provider that allows our users to login. In my previous posts, I was simply using the ```kubeadmin``` god mode account that is generated at bootstrap.
To specify an identity provider, will need to create a custom resource (CR) that describes that identity provider and add it to the cluster. For the example of this post, I will detail how to configure a ldap identity provider to validate user names and passwords against an LDAPv3 server, using simple bind authentication. In my lab environment, I already have a Windows Server which is set up as a [domain controller](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/virtual-dc/active-directory-domain-services-overview).
In short, when a user logs in to the OpenShift cluster, OpenShift will contact the domain controller via a configured provided domain account, and perform a lookup of the users account, if it is returned, it will try to bind to the LDAP provider with the users account and password provided. If this bind is successful, the user will be authenticated to the OpenShift cluster.
1. On your domain controller, create a user account for the OpenShift Cluster to use for lookups, and ensure this account has the appropriate permissions. For Windows Server domain services, this user account can be a member of the standard ```domain users``` group. It is also a good time to record and have to hand the following information ready;
- LDAP server URL (e.g., ldap://ldap.example.com:389)
- Bind DN and password for the LDAP server (e.g., cn=admin,dc=example,dc=com and password)
- This password will be [base64](https://en.wikipedia.org/wiki/Base64) encoded in the secret.
- User search base and filter (e.g., ou=users,dc=example,dc=com and (uid=%u))
- Group search base and filter (e.g., ou=groups,dc=example,dc=com and (member=%u))
2. Create a secret that contains the ```bindPassword```, i.e the password of the domain account used to connect to the LDAP server for the user lookups.
````sh
$ oc create secret generic ldap-secret --from-literal=bindPassword=<secret> -n openshift-config
# my example
oc create secret generic ldap-secret --from-literal=bindPassword=VMware1! -n openshift-config
````
3. Now we apply the configuration that tells the OAuth service about our LDAP server and how to connect to it. I have not performed the extra steps to save the CA cert from the LDAP Server, as I am using the insecure LDAP port 389.
Save the below file as ```ldap-provider.yaml```, change for your user details, and apply to your cluster using ```oc apply -f ldap-provider.yaml```.
````yaml
apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
name: cluster
spec:
identityProviders:
- name: ldapidp
mappingMethod: claim
type: LDAP
ldap:
attributes:
id:
- name
name:
- cn
preferredUsername:
- sAMAccountName
bindDN: "CN=svc_openshift,OU=Services,OU=Accounts,DC=simon,DC=local"
bindPassword:
name: ldap-secret
insecure: true
url: "ldap://sc-step-01.simon.local:389/CN=Users,DC=simon,DC=local?sAMAccountName"
````
Some notes about the above configuration;
- attributes - The first non-empty attribute is used. At least one attribute is required. If none of the listed attribute have a value, authentication fails. Defined attributes are retrieved as raw, allowing for binary values to be used.
- Ensure the values provided appear as attributes in your domain controller, this is usually a cause of failures.
- bindDN - DN to use to bind during the search phase. Must be set if bindPassword is defined.
- insecure - When true, no TLS connection is made to the server. When false, ldaps:// URLs connect using TLS, and ldap:// URLs are upgraded to TLS.
- url - ensure you add the port, and that your search OU/CN path is correct, as well as the [search filter attribute](https://docs.openshift.com/container-platform/4.12/authentication/identity_providers/configuring-ldap-identity-provider.html#identity-provider-about-ldap_configuring-ldap-identity-provider), in this example it is ```sAMAccountName```
> If a CR does not exist, oc apply creates a new CR and might trigger the following warning: Warning: oc apply should be used on resources created by either oc create --save-config or oc apply. In this case you can safely ignore this warning.
4. Now you can login to the OpenShift cluster as an LDAP user either via the ```oc login``` CLI command, or via the Console UI. You can logout with ```oc logout```
![oc login](/2023/images/Day61%20-%20Authentication%20-%20Role-Based%20Access%20Control%20and%20Auditing%20in%20Red%20Hat%20OpenShift/oc%20login.jpg)
Final note on this subject which caught me out. Once you log out, you will remain in the ```oc context``` of that user you've logged in, and if you view your ```KUBECONFIG``` file, you will see that user's context has now been added. So for me, I wanted to get back to using my kubeadmin account, but I had to run ```oc config use-context admin``` command.
Now we have a way for our users to log into the platform, we can start to look at controlling what they can do on the platform.
## What is Role-Based Access Control (RBAC)?
RBAC is a method of managing permissions by assigning roles to users, groups, or service accounts. In OpenShift, roles are sets of rules that define the actions (verbs) allowed on specific resources (API objects). By granting roles to users or groups, you control their access to cluster resources based on the principle of least privilege, ensuring that users have only the necessary permissions to perform their tasks. Here, Red Hat OpenShift is just consuming the native features of Kubernetes, concerning RBAC. However, it's important to understand this area, as it then features in the enterprise features OpenShift brings, such as Projects and pipelines to name but a few.
## RBAC in Red Hat OpenShift
In OpenShift, RBAC is implemented through a set of built-in roles and custom roles, which can be assigned to users, groups, and service accounts. The key components of RBAC in OpenShift are:
- Roles: A role is a collection of policies that define a set of permissions, including what actions users can perform on resources. These are applied to a namespace.
- ClusterRoles: Similar to roles, but these permissions are applicable cluster-wide, rather than in a specific namespace.
- RoleBindings: These are objects that associate roles with users, groups, or service accounts, granting them the permissions defined by the role
The below image shows the relationships between the different components.
![Red Hat OpenShift - Relationships between cluster roles, local roles, cluster role bindings, local role bindings, users, groups and service accounts](/2023/images/Day61%20-%20Authentication%20-%20Role-Based%20Access%20Control%20and%20Auditing%20in%20Red%20Hat%20OpenShift/Red%20Hat%20OpenShift%20-%20Access%20Control%20-%20Relationship%20between%20cluster%20roles%2C%20local%20roles%20and%20role%20bindings.png)
To set up a new RBAC for a user to deploy and manage an application in a new project called "rbac-test-ns", follow the steps below:
1. First, we need to create the "rbac-test-ns" project. Run the following command:
````sh
$ oc new-project rbac-test-ns
````
2. Create a new custom role that grants the necessary permissions for deploying and managing applications. In this example, we will create a role called "app-mgr". Save the following YAML content to a file named "app-mgr-role.yaml":
````yaml
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: app-mgr
namespace: rbac-test-ns
rules:
- apiGroups: ["project.openshift.io"]
resources: ["projects"]
verbs: ["get"]
- apiGroups: [""]
resources: ["pods", "services", "endpoints", "persistentvolumeclaims", "configmaps", "secrets"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: ["apps"]
resources: ["deployments", "replicasets", "statefulsets"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
````
Create the custom role by applying the YAML file:
````sh
$ oc apply -f app-mgr-role.yaml
````
3. Now, we need to bind the custom role to the user. In this example, let's assume the user's username is "johndoe". Create a RoleBinding by saving the following YAML content to a file named "app-mgr-rolebinding.yaml":
````yaml
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: app-mgr-binding
namespace: rbac-test-ns
subjects:
- kind: User
name: test
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: app-mgr
apiGroup: rbac.authorization.k8s.io
````
Create the RoleBinding by applying the YAML file:
As a alternative to add a user to an existing role, we can use the following command line:
````sh
$ oc adm policy add-role-to-user <role> <user> -n <project>
# For my example above, once I created the "app-mgr" role in the rbac-test-ns namespace I can run the following to create the roleBinding
oc adm policy add-role-to-user app-mgr test -n rbac-test-ns
````
We can also see who can perform actions against certain resources too by using the command:
````sh
oc adm policy who-can {verb} {resource}
# for example
oc adm policy who-can create pods -n rbac-test-ns
# below is the output (shortened) you can see my test user at the bottom
resourceaccessreviewresponse.authorization.openshift.io/<unknown>
Namespace: rbac-test-ns
Verb: create
Resource: pods
Users: system:admin
system:serviceaccount:kube-system:daemon-set-controller
system:serviceaccount:kube-system:job-controller
.......
system:serviceaccount:rbac-test-ns:deployer
test
Groups: system:cluster-admins
system:masters
````
With these steps, we have successfully set up a brand new RBAC for the user "test" (from my LDAP setup and testing earlier) to deploy and manage an application in the "rbac-test-ns" project. The user can now interact with the cluster, creating deployments, managing services, and configuring resources within the scope of the "app-mgr" role in the "rbac-test-ns" namespace.
## How Accounting Works in Red Hat OpenShift 4
Here are the main components of accounting in Red Hat OpenShift:
- Audit Policy: The audit policy determines which requests should be logged and the level of detail to include in the logs. You can configure the audit policy using a YAML file that specifies rules for each type of resource and action.
- Audit Backend: The audit backend is responsible for processing and storing the audit logs. Red Hat OpenShift supports two types of audit backends: log backend and webhook backend. The log backend writes logs to a file on the API server node, while the webhook backend sends logs to an external HTTP(S) endpoint.
- Log Retention and Rotation: OpenShift provides mechanisms for managing audit log retention and rotation to ensure that logs do not consume excessive disk space. Log rotation settings can be configured to control the maximum log file size and the number of old log files to keep.
To enable and configure audit logging in OpenShift, administrators can create an audit policy, configure the audit backend, and set log retention and rotation settings. Once configured, the audit logs can be used to monitor user activities, identify security issues, and comply with regulatory requirements.
Auditing is conducted at the API Server level, as it captures all requests coming into the server. This means that the audit logs by default will be stored on each of the control-plane nodes.
Each audit log will contain the following fields:
- level - The audit level at which the event was generated.
- auditID - A unique audit ID, generated for each request.
- stage - The stage of the request handling when this event instance was generated.
- requestURI - The request URI is sent by the client to a server.
- verb - The Kubernetes verb associated with the request. For non-resource requests, this is the lowercase HTTP method.
- user - The authenticated user information.
- impersonatedUser - Optional. The impersonated user information, if the request is impersonating another user.
- sourceIPs - Optional. The source IPs, from where the request originated and any intermediate proxies.
- userAgent - Optional. The user agent string is reported by the client. Note that the user agent is provided by the client, and must not be trusted.
- objectRef - Optional. The object reference this request is targeted at. This does not apply to List-type requests, or non-resource requests.
- responseStatus - Optional. The response status is populated even when the ResponseObject is not a Status type. For successful responses, this will only include the code. For non-status type error responses, this will be auto-populated with the error message.
- requestObject - Optional. The API object from the request is in JSON format. The RequestObject is recorded as is in the request (possibly re-encoded as JSON), prior to version conversion, defaulting, admission or merging. It is an external versioned object type, and might not be a valid object on its own. This is omitted for non-resource requests and is only logged at the request level and higher.
- responseObject - Optional. The API object is returned in the response, in JSON format. The ResponseObject is recorded after conversion to the external type and serialized as JSON. This is omitted for non-resource requests and is only logged at the response level.
- requestReceivedTimestamp - The time that the request reached the API server.
- stageTimestamp - The time that the request reached the current audit stage.
- annotations - Optional. An unstructured key-value map is stored with an audit event that may be set by plugins invoked in the request serving chain, including authentication, authorization and admission plugins. Note that these annotations are for the audit event, and do not correspond to the ```metadata.annotations``` of the submitted object. Keys should uniquely identify the informing component to avoid name collisions, for example, podsecuritypolicy.admission.k8s.io/policy. Values should be short. Annotations are included in the metadata level.
Below is an example of output from the Kubernetes API Server from the official documentation:
````json
{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata","auditID":"ad209ce1-fec7-4130-8192-c4cc63f1d8cd","stage":"ResponseComplete","requestURI":"/api/v1/namespaces/openshift-kube-controller-manager/configmaps/cert-recovery-controller-lock?timeout=35s","verb":"update","user":{"username":"system:serviceaccount:openshift-kube-controller-manager:localhost-recovery-client","uid":"dd4997e3-d565-4e37-80f8-7fc122ccd785","groups":["system:serviceaccounts","system:serviceaccounts:openshift-kube-controller-manager","system:authenticated"]},"sourceIPs":["::1"],"userAgent":"cluster-kube-controller-manager-operator/v0.0.0 (linux/amd64) kubernetes/$Format","objectRef":{"resource":"configmaps","namespace":"openshift-kube-controller-manager","name":"cert-recovery-controller-lock","uid":"5c57190b-6993-425d-8101-8337e48c7548","apiVersion":"v1","resourceVersion":"574307"},"responseStatus":{"metadata":{},"code":200},"requestReceivedTimestamp":"2020-04-02T08:27:20.200962Z","stageTimestamp":"2020-04-02T08:27:20.206710Z","annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":"RBAC: allowed by ClusterRoleBinding \"system:openshift:operator:kube-controller-manager-recovery\" of ClusterRole \"cluster-admin\" to ServiceAccount \"localhost-recovery-client/openshift-kube-controller-manager\""}}
````
To view the audit logs:
1. List the available audit logs on the control-plane nodes
````sh
$ oc adm node-logs --role=master --path=openshift-apiserver/
# Example output
90days-ocp-72ptq-master-0 audit-2023-03-18T13-32-30.141.log
90days-ocp-72ptq-master-0 audit-2023-03-20T18-52-05.290.log
90days-ocp-72ptq-master-0 audit-2023-03-22T23-59-32.898.log
90days-ocp-72ptq-master-0 audit-2023-03-25T05-18-17.982.log
90days-ocp-72ptq-master-0 audit-2023-03-27T10-18-07.255.log
90days-ocp-72ptq-master-0 audit-2023-03-29T15-39-12.983.log
90days-ocp-72ptq-master-0 audit.log
90days-ocp-72ptq-master-1 audit-2023-03-18T13-40-29.849.log
90days-ocp-72ptq-master-1 audit-2023-03-20T18-48-37.329.log
90days-ocp-72ptq-master-1 audit-2023-03-23T00-03-57.031.log
90days-ocp-72ptq-master-1 audit-2023-03-25T05-14-28.573.log
90days-ocp-72ptq-master-1 audit-2023-03-27T10-25-27.601.log
90days-ocp-72ptq-master-1 audit-2023-03-29T15-34-14.462.log
90days-ocp-72ptq-master-1 audit.log
90days-ocp-72ptq-master-2 audit-2023-03-18T13-15-35.530.log
90days-ocp-72ptq-master-2 audit-2023-03-20T18-22-40.880.log
90days-ocp-72ptq-master-2 audit-2023-03-22T23-18-33.055.log
90days-ocp-72ptq-master-2 audit-2023-03-25T04-18-56.637.log
90days-ocp-72ptq-master-2 audit-2023-03-27T09-44-50.243.log
90days-ocp-72ptq-master-2 audit-2023-03-29T14-39-01.789.log
90days-ocp-72ptq-master-2 audit.log
````
2. To view a specific audit log:
````sh
$ oc adm node-logs <node_name> --path=openshift-apiserver/<log_name>
# Example command
$ oc adm node-logs 90days-ocp-72ptq-master-2 --path=openshift-apiserver/audit-2023-03-29T14-39-01.789.log
````
Example output:
````json
{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata","auditID":"5d08341a-8fa2-4fab-8e4a-4fb1c01d2d6e","stage":"ResponseStarted","requestURI":"/apis/template.openshift.io/v1/namespaces/openshift/templates?allowWatchBookmarks=true\u0026resourceVersion=9537849\u0026timeout=5m44s\u0026timeoutSeconds=344\u0026watch=true","verb":"watch","user":{"username":"system:serviceaccount:openshift-cluster-samples-operator:cluster-samples-operator","groups":["system:serviceaccounts","system:serviceaccounts:openshift-cluster-samples-operator","system:authenticated"],"extra":{"authentication.kubernetes.io/pod-name":["cluster-samples-operator-7f8d575897-s7566"],"authentication.kubernetes.io/pod-uid":["8a96caaf-1de9-4cef-915f-ace02c764e52"]}},"sourceIPs":["192.168.200.181","10.130.0.2"],"userAgent":"cluster-samples-operator/v0.0.0 (linux/amd64) kubernetes/$Format","objectRef":{"resource":"templates","namespace":"openshift","apiGroup":"template.openshift.io","apiVersion":"v1"},"responseStatus":{"metadata":{},"code":200},"requestReceivedTimestamp":"2023-03-27T09:44:50.239076Z","stageTimestamp":"2023-03-27T09:44:50.242747Z","annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":"RBAC: allowed by RoleBinding \"shared-resource-viewers/openshift\" of Role \"shared-resource-viewer\" to Group \"system:authenticated\""}}
{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata","auditID":"e65876d9-6fca-422c-93a9-110921648d1b","stage":"ResponseComplete","requestURI":"/metrics","verb":"get","user":{"username":"system:serviceaccount:openshift-monitoring:prometheus-k8s","groups":["system:authenticated"]},"sourceIPs":["10.129.2.13"],"userAgent":"Prometheus/2.39.1","responseStatus":{"metadata":{},"code":200},"requestReceivedTimestamp":"2023-03-27T09:44:51.044096Z","stageTimestamp":"2023-03-27T09:44:51.065007Z","annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":"RBAC: allowed by ClusterRoleBinding \"prometheus-k8s\" of ClusterRole \"prometheus-k8s\" to ServiceAccount \"prometheus-k8s/openshift-monitoring\""}}
````
Next, we have the OpenShift OAuth API Server audit logs, which will capture our user interactions
1. List the relevant logs on the control-plane nodes
````sh
oc adm node-logs --role=master --path=oauth-apiserver/
# Example output
90days-ocp-72ptq-master-0 audit-2023-03-22T20-22-19.424.log
90days-ocp-72ptq-master-0 audit-2023-03-29T08-44-53.926.log
90days-ocp-72ptq-master-0 audit.log
90days-ocp-72ptq-master-1 audit-2023-03-22T20-34-32.796.log
90days-ocp-72ptq-master-1 audit-2023-03-29T08-41-39.406.log
90days-ocp-72ptq-master-1 audit.log
90days-ocp-72ptq-master-2 audit-2023-03-22T20-08-20.762.log
90days-ocp-72ptq-master-2 audit-2023-03-29T08-10-51.942.log
90days-ocp-72ptq-master-2 audit.log
````
2. View a specific OAuth API Server log:
````sh
$ oc adm node-logs <node_name> --path=oauth-apiserver/<log_name>
# Example command
$ oc adm node-logs 90days-ocp-72ptq-master-2 --path=oauth-apiserver/audit-2023-03-29T08-10-51.942.log
`````
Example output
````json
{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata","auditID":"6472c130-436a-4454-9bf9-77b6066d8ce2","stage":"ResponseComplete","requestURI":"/apis/oauth.openshift.io/v1/oauthclients/console","verb":"get","user":{"username":"system:serviceaccount:openshift-console-operator:console-operator","groups":["system:serviceaccounts","system:serviceaccounts:openshift-console-operator","system:authenticated"],"extra":{"authentication.kubernetes.io/pod-name":["console-operator-7cc8457b5b-rpz7f"],"authentication.kubernetes.io/pod-uid":["4b73b593-9cde-4ae4-a8f7-00e7f7ee7902"]}},"sourceIPs":["192.168.200.181","10.129.0.2"],"userAgent":"console/v0.0.0 (linux/amd64) kubernetes/$Format","objectRef":{"resource":"oauthclients","name":"console","apiGroup":"oauth.openshift.io","apiVersion":"v1"},"responseStatus":{"metadata":{},"code":200},"requestReceivedTimestamp":"2023-03-22T23:35:00.970020Z","stageTimestamp":"2023-03-22T23:35:00.972703Z","annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":"RBAC: allowed by ClusterRoleBinding \"console-operator\" of ClusterRole \"console-operator\" to ServiceAccount \"console-operator/openshift-console-operator\""}}
{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata","auditID":"db3d3280-fcb9-4368-b7db-17b97bcb9826","stage":"ResponseComplete","requestURI":"/apis/oauth.openshift.io/v1/oauthclients/console","verb":"get","user":{"username":"system:serviceaccount:openshift-console-operator:console-operator","groups":["system:serviceaccounts","system:serviceaccounts:openshift-console-operator","system:authenticated"],"extra":{"authentication.kubernetes.io/pod-name":["console-operator-7cc8457b5b-rpz7f"],"authentication.kubernetes.io/pod-uid":["4b73b593-9cde-4ae4-a8f7-00e7f7ee7902"]}},"sourceIPs":["192.168.200.181","10.129.0.2"],"userAgent":"console/v0.0.0 (linux/amd64) kubernetes/$Format","objectRef":{"resource":"oauthclients","name":"console","apiGroup":"oauth.openshift.io","apiVersion":"v1"},"responseStatus":{"metadata":{},"code":200},"requestReceivedTimestamp":"2023-03-22T23:35:00.976516Z","stageTimestamp":"2023-03-22T23:35:00.980651Z","annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":"RBAC: allowed by ClusterRoleBinding \"console-operator\" of ClusterRole \"console-operator\" to ServiceAccount \"console-operator/openshift-console-operator\""}}
{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata","auditID":"b5a99a12-637a-4bb2-b733-1f3812ca76fe","stage":"ResponseComplete","requestURI":"/openapi/v2","verb":"get","user":{"username":"system:aggregator","groups":["system:authenticated"]},"sourceIPs":["10.128.0.2"],"responseStatus":{"metadata":{},"code":304},"requestReceivedTimestamp":"2023-03-22T23:35:21.077019Z","stageTimestamp":"2023-03-22T23:35:21.085460Z","annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":"RBAC: allowed by ClusterRoleBinding \"cluster-status-binding\" of ClusterRole \"cluster-status\" to Group \"system:authenticated\""}}
````
And finally the OAuth server audit logs
1. List the available logs on the control-plane nodes:
````sh
oc adm node-logs --role=master --path=oauth-server/
# Example output
90days-ocp-72ptq-master-0 audit.log
90days-ocp-72ptq-master-1 audit.log
90days-ocp-72ptq-master-2 audit.log
````
2. View a specific log:
````sh
$ oc adm node-logs <node_name> --path=oauth-server/<log_name>
# Example command
$ oc adm node-logs 90days-ocp-72ptq-master-2 --path=oauth-server/audit.log
````
Example output:
````json
{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata","auditID":"0ae79d4b-a44e-4f16-aadf-a600f42a63d0","stage":"RequestReceived","requestURI":"/","verb":"head","user":{"username":"system:anonymous","groups":["system:unauthenticated"]},"sourceIPs":["10.131.0.2"],"userAgent":"Go-http-client/1.1","requestReceivedTimestamp":"2023-03-30T14:13:04.446550Z","stageTimestamp":"2023-03-30T14:13:04.446550Z"}
{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata","auditID":"0ae79d4b-a44e-4f16-aadf-a600f42a63d0","stage":"ResponseComplete","requestURI":"/","verb":"head","user":{"username":"system:anonymous","groups":["system:unauthenticated"]},"sourceIPs":["10.131.0.2"],"userAgent":"Go-http-client/1.1","responseStatus":{"metadata":{},"status":"Failure","message":"forbidden: User \"system:anonymous\" cannot head path \"/\"","reason":"Forbidden","details":{},"code":403},"requestReceivedTimestamp":"2023-03-30T14:13:04.446550Z","stageTimestamp":"2023-03-30T14:13:04.456751Z","annotations":{"authorization.k8s.io/decision":"forbid","authorization.k8s.io/reason":""}}
{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata","auditID":"a151df17-578c-415f-a83e-64753a0d16dc","stage":"RequestReceived","requestURI":"/oauth/authorize?client_id=openshift-challenging-client\u0026code_challenge=L56_-VuTMU7qF36WuKxF6mnA2nj_oEEETPsAdQ-w24I\u0026code_challenge_method=S256\u0026redirect_uri=https%3A%2F%2Foauth-openshift.apps.90days-ocp.simon.local%2Foauth%2Ftoken%2Fimplicit\u0026response_type=code","verb":"get","user":{"username":"system:anonymous","groups":["system:unauthenticated"]},"sourceIPs":["10.131.0.2"],"userAgent":"Go-http-client/1.1","requestReceivedTimestamp":"2023-03-30T14:13:04.489643Z","stageTimestamp":"2023-03-30T14:13:04.489643Z"}
````
You can filter the logs using the ```jq``` tool (See the [jq Manual](https://stedolan.github.io/jq/manual/) for detailed information). An example command would be:
````sh
$ oc adm node-logs 90days-ocp-72ptq-master-2 --path=openshift-apiserver/audit.log | jq 'select(.user.username == "test")'
````
Example output:
````json
{
"kind": "Event",
"apiVersion": "audit.k8s.io/v1",
"level": "Metadata",
"auditID": "97ce5c38-4e0c-447b-8e9f-a2c8c84ebc19",
"stage": "ResponseComplete",
"requestURI": "/apis/project.openshift.io/v1/projectrequests",
"verb": "list",
"user": {
"username": "test",
"groups": [
"system:authenticated:oauth",
"system:authenticated"
],
"extra": {
"scopes.authorization.openshift.io": [
"user:full"
]
}
},
"sourceIPs": [
"10.129.0.35",
"10.129.0.2"
],
"objectRef": {
"resource": "projectrequests",
"apiGroup": "project.openshift.io",
"apiVersion": "v1"
},
"responseStatus": {
"metadata": {},
"status": "Success",
"code": 200
},
"requestReceivedTimestamp": "2023-03-30T14:42:37.237408Z",
"stageTimestamp": "2023-03-30T14:42:37.250606Z",
"annotations": {
"authorization.k8s.io/decision": "allow",
"authorization.k8s.io/reason": "RBAC: allowed by ClusterRoleBinding \"basic-users\" of ClusterRole \"basic-user\" to Group \"system:authenticated\""
}
}
{
"kind": "Event",
"apiVersion": "audit.k8s.io/v1",
"level": "Metadata",
"auditID": "5868d505-1c46-47ed-b0ab-d53d9878d495",
"stage": "ResponseStarted",
"requestURI": "/apis/project.openshift.io/v1/projects?cluster=local-cluster&watch=true",
"verb": "watch",
"user": {
"username": "test",
"groups": [
"system:authenticated:oauth",
"system:authenticated"
],
"extra": {
"scopes.authorization.openshift.io": [
"user:full"
]
}
},
"sourceIPs": [
"192.168.200.10",
"10.129.0.35",
"10.129.0.2"
],
"userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36",
"objectRef": {
"resource": "projects",
"apiGroup": "project.openshift.io",
"apiVersion": "v1"
},
"responseStatus": {
"metadata": {},
"code": 101
},
"requestReceivedTimestamp": "2023-03-30T14:42:40.166647Z",
"stageTimestamp": "2023-03-30T14:42:40.170013Z",
"annotations": {
"authorization.k8s.io/decision": "allow",
"authorization.k8s.io/reason": "RBAC: allowed by ClusterRoleBinding \"basic-users\" of ClusterRole \"basic-user\" to Group \"system:authenticated\""
}
}
````
To wrap up this section, I think it's worth highlighting that keeping the logs on the nodes themselves is not best practice, and you will want to offload these to an external logging service. I won't cover that in detail in this post, but I will provide you a [link to a blog post](https://veducate.co.uk/openshift-forward-logs-log-insight-cloud/) I created previously, showing how you can offload the logs to the VMware Aria Operations for Logs product (previously known as vRealize Log Insight)
# Summary
In this post, we've seen more of how Red Hat OpenShift takes the out-of-the-box functionality from upstream Kubernetes and entwines it with enterprise engineering, such as the ability to easily add an Identity provider for Authorization without having to pull in more open-source components. The AAA model is a basic premise when it comes to managing the security stance of your environment, and before you let users consume the Red Hat OpenShift platform, it's key to understand how this works and start putting in the structure upfront around the likes of Roles and Role Bindings for user privileges.
This post only takes you into the beginnings of setting up RBAC, and we haven't discussed a cohesive strategy of how to implement it within your organisation. It's safe to say least privilege is the best, and the outcome you need to aim for. I've included several links below for you to understand RBAC in Kubernetes and OpenShift in more detail, and I'm sure with a quick search on your favourite search engine, you'll also find lots of posts around how best to implement a least privilege model.
To wrap up this section on Red Hat OpenShift with [Day 62](/2023/day62.md) we will cover compliance and vulnerability scanning provided by Red Hat Operators.
## Resources
- Kubernetes.io
- [Authenicating](https://kubernetes.io/docs/reference/access-authn-authz/authentication/)
- [Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
- Red Hat OpenShift Documentation
- [Configuring an LDAP identity provider](https://docs.openshift.com/container-platform/4.12/authentication/identity_providers/configuring-ldap-identity-provider.html)
- [Using RBAC to define and apply permissions](https://access.redhat.com/documentation/en-us/openshift_container_platform/4.12/html/authentication_and_authorization/using-rbac)
- [Viewing Audit logs](https://docs.openshift.com/container-platform/4.12/security/audit-log-view.html)
- [Configuring the audit log policy](https://docs.openshift.com/container-platform/4.12/security/audit-log-policy-config.html#audit-log-policy-config)
- [Monitoring cluster events and logs](https://docs.openshift.com/container-platform/4.12/security/container_security/security-monitoring.html)
- Red Hat Blog - [Multiple ways of Authentication on OpenShift Container Platform (OCP), Part 2](https://cloud.redhat.com/blog/multiple-ways-of-authentication-on-openshift-container-platform-ocp-part-2)
- OpenShift Examples - [Active Directory/LDAP](https://examples.openshift.pub/cluster-configuration/authentication/activedirectory-ldap/)
- vEducate.co.uk - [How to configure Red Hat OpenShift to forward logs to VMware vRealize Log Insight Cloud](https://veducate.co.uk/openshift-forward-logs-log-insight-cloud/)

711
2023/day62.md
View File

@ -0,0 +1,711 @@
# Compliance and Vulnerability Scanning provided by Red Hat OpenShift Operators
Many components make up the security posture of a well-designed and architected platform. For a Red Hat OpenShift platform, this will include implementing the AAA model we covered on [Day 61](/2023/day61.md), container security, certificates to validate access to the platform and between the workloads that run and communicate on and with the platform, data encryption, vulnerability scanning, compliance auditing and remediation, as just a shortlisted example.
In this post, I'm going to focus on just two areas of security inside of Red Hat OpenShift; Compliance and Vulnerability Scanning.
# Red Hat OpenShift Compliance Operator
## Compliance Overview
In the context of Kubernetes, compliance refers to the adherence of OpenShift deployments to various industry standards, regulations, and best practices. Compliance is essential for organizations operating in regulated industries like healthcare, finance, or government sectors, as well as for those who prioritize security and privacy.
OpenShift, as a Kubernetes-based container orchestration platform, provides several features and tools to help organizations achieve and maintain compliance. These features include:
- Security and access control: OpenShift provides robust security features like Role-Based Access Control (RBAC), network policies, and Security Context Constraints (SCCs) to manage access to cluster resources and ensure the secure deployment and operation of applications.
- Auditing and monitoring: OpenShift's built-in auditing and monitoring capabilities make it easy to track user activities, resource usage, and system events. This information is crucial for detecting and responding to security incidents, meeting regulatory requirements, and troubleshooting issues.
- Image and container security: OpenShift's integrated container registry, image signing, and image scanning features help ensure the integrity and security of container images. Additionally, OpenShift enforces security best practices through resource constraints and pod security policies.
- Encrypted communication: OpenShift supports TLS/SSL for secure communication between cluster components, as well as between the cluster and external clients. This helps protect sensitive data in transit.
- Compliance Operator: Red Hat OpenShift provides the Compliance Operator, with an OpenShift-native tool that helps organizations evaluate and enforce compliance policies. The Compliance Operator leverages the OpenSCAP framework and can be configured to meet specific regulatory requirements or security standards, such as NIST, PCI-DSS, HIPAA, or GDPR.
Achieving and maintaining compliance in OpenShift involves configuring the platform according to industry standards, regulations, and best practices, continuously monitoring and auditing the environment, and promptly addressing any identified issues. By utilising the capabilities and resources offered by OpenShift, organisations have the opportunity to establish secure and regulation-compliant ecosystems for their applications and workloads, ensuring optimal performance and adherence to industry standards.
In this post, we'll be focusing on the Compliance Operator, which empowers the platform administrators by allowing them to define the desired compliance state for their cluster. It offers a comprehensive overview of discrepancies between the current and target states, as well as actionable insights to address these gaps effectively.
The Compliance Operator provides the ability to describe the required compliance state of a cluster and report overviews of gaps and ways to remediate them. The Compliance Operator assesses compliance of both the Kubernetes API resources of OpenShift Container Platform, as well as the nodes running the cluster. The Compliance Operator uses OpenSCAP, a NIST-certified tool, to scan and enforce security policies provided by the content. You can view details of the out-of-the-box compliance profiles that are [provided here](https://docs.openshift.com/container-platform/4.12/security/compliance_operator/compliance-operator-supported-profiles.html).
### Installing the Compliance Operator
1. We need to create a specially managed OpenShift namespace. Save the below content as ```openshift-compliance-namespace.yaml``` and apply using the ```oc apply -f openshift-compliance-namespace.yaml``` command.
````yaml
apiVersion: v1
kind: Namespace
metadata:
labels:
openshift.io/cluster-monitoring: "true"
pod-security.kubernetes.io/enforce: privileged
name: openshift-compliance
````
2. Now we need to define an ```OperatorGroup``` for the Compliance operator. Save the below content as ```openshift-compliance-operator-group.yaml``` and apply using the ```oc apply -f openshift-compliance-operator-group.yaml``` command.
````yaml
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
name: compliance-operator
namespace: openshift-compliance
spec:
targetNamespaces:
- openshift-compliance
````
3. Define and apply a subscription to the Operator. Save the below content as ```openshift-compliance-operator-subscription.yaml``` and apply using the ```oc apply -f openshift-compliance-operator-subscription.yaml``` command.
````yaml
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
name: compliance-operator-sub
namespace: openshift-compliance
spec:
channel: "release-0.1"
installPlanApproval: Automatic
name: compliance-operator
source: redhat-operators
sourceNamespace: openshift-marketplace
````
4. You can verify the Operator installation with the below command;
````sh
$ oc get csv -n openshift-compliance
$ oc get deploy -n openshift-compliance
````
### Reviewing the profiles and the rules
We can see the installed profiles by running the below command, each profile has the product name that it applies to added as a prefix to the profile’s name. ocp4-e8 applies the Essential 8 benchmark to the OpenShift Container Platform product, while rhcos4-e8 applies the Essential 8 benchmark to the Red Hat Enterprise Linux CoreOS (RHCOS) product.
````sh
$ oc get -n openshift-compliance profiles.compliance
NAME AGE
ocp4-cis 107m
ocp4-cis-node 107m
ocp4-e8 107m
ocp4-high 107m
ocp4-high-node 107m
ocp4-moderate 107m
ocp4-moderate-node 107m
ocp4-nerc-cip 107m
ocp4-nerc-cip-node 107m
ocp4-pci-dss 107m
ocp4-pci-dss-node 107m
rhcos4-e8 107m
rhcos4-high 107m
rhcos4-moderate 107m
rhcos4-nerc-cip 107m
````
We can view the details of a profile by running:
````sh
$ oc get -n openshift-compliance -oyaml profiles.compliance ocp4-cis
````
````yaml
apiVersion: compliance.openshift.io/v1alpha1
description: This profile defines a baseline that aligns to the Center for Internet
Security® Red Hat OpenShift Container Platform 4 Benchmark™, V1.1. This profile
includes Center for Internet Security® Red Hat OpenShift Container Platform 4 CIS
Benchmarks™ content. Note that this part of the profile is meant to run on the Platform
that Red Hat OpenShift Container Platform 4 runs on top of. This profile is applicable
to OpenShift versions 4.6 and greater.
id: xccdf_org.ssgproject.content_profile_cis
kind: Profile
metadata:
annotations:
compliance.openshift.io/image-digest: pb-ocp477wpm
compliance.openshift.io/product: redhat_openshift_container_platform_4.1
compliance.openshift.io/product-type: Platform
creationTimestamp: "2023-03-31T09:09:52Z"
generation: 1
labels:
compliance.openshift.io/profile-bundle: ocp4
name: ocp4-cis
namespace: openshift-compliance
ownerReferences:
- apiVersion: compliance.openshift.io/v1alpha1
blockOwnerDeletion: true
controller: true
kind: ProfileBundle
name: ocp4
uid: 19c2e4a5-094f-416a-a06b-eb0598e39618
resourceVersion: "12971302"
uid: 6dc3cca4-5649-43ae-8c46-614f82fd6744
rules:
- ocp4-accounts-restrict-service-account-tokens
- ocp4-accounts-unique-service-account
- ocp4-api-server-admission-control-plugin-alwaysadmit
- ocp4-api-server-admission-control-plugin-alwayspullimages
- ocp4-api-server-admission-control-plugin-namespacelifecycle
- ocp4-api-server-admission-control-plugin-noderestriction
- ocp4-api-server-admission-control-plugin-scc
- ocp4-api-server-admission-control-plugin-securitycontextdeny
- ocp4-api-server-admission-control-plugin-service-account
- ocp4-api-server-anonymous-auth
- ocp4-api-server-api-priority-flowschema-catch-all
- ocp4-api-server-api-priority-gate-enabled
- ocp4-api-server-audit-log-maxbackup
- ocp4-api-server-audit-log-maxsize
- ocp4-api-server-audit-log-path
- ocp4-api-server-auth-mode-no-aa
- ocp4-api-server-auth-mode-node
- ocp4-api-server-auth-mode-rbac
- ocp4-api-server-basic-auth
- ocp4-api-server-bind-address
...
- ocp4-scc-limit-privileged-containers
- ocp4-scc-limit-process-id-namespace
- ocp4-scc-limit-root-containers
- ocp4-scheduler-no-bind-address
- ocp4-secrets-consider-external-storage
- ocp4-secrets-no-environment-variables
- ocp4-version-detect-in-hypershift
- ocp4-version-detect-in-ocp
title: CIS Red Hat OpenShift Container Platform 4 Benchmark
````
To read the descriptions of one of the rules that form the policy:
````sh
$ oc get -n openshift-compliance rules ocp4-api-server-anonymous-auth -oyaml
````
````yaml
apiVersion: compliance.openshift.io/v1alpha1
checkType: Platform
description: |-
By default, anonymous access to the OpenShift API is enabled, but at the same time, all requests must be authorized. If no authentication mechanism is used, the request is assigned the system:anonymous virtual user and the system:unauthenticated virtual group. This allows the authorization layer to determin which requests, if any, is an anonymous user authorized to make. To verify the authorization rules for anonymous requests run the following:
$ oc describe clusterrolebindings
and inspect the bidnings of the system:anonymous virtual user and the system:unauthenticated virtual group. To test that an anonymous request is authorized to access the readyz endpoint, run:
$ oc get --as="system:anonymous" --raw='/readyz?verbose'
In contrast, a request to list all projects should not be authorized:
$ oc get --as="system:anonymous" projects
id: xccdf_org.ssgproject.content_rule_api_server_anonymous_auth
instructions: |-
Run the following command to view the authorization rules for anonymous requests:
$ oc describe clusterrolebindings
Make sure that there exists at least one clusterrolebinding that binds
either the system:unauthenticated group or the system:anonymous
user.
To test that an anonymous request is authorized to access the readyz
endpoint, run:
$ oc get --as="system:anonymous" --raw='/readyz?verbose'
In contrast, a request to list all projects should not be authorized:
$ oc get --as="system:anonymous" projects
kind: Rule
metadata:
annotations:
compliance.openshift.io/image-digest: pb-ocp477wpm
compliance.openshift.io/rule: api-server-anonymous-auth
control.compliance.openshift.io/CIS-OCP: 1.2.1
control.compliance.openshift.io/NERC-CIP: CIP-003-8 R6;CIP-004-6 R3;CIP-007-3
R6.1
control.compliance.openshift.io/NIST-800-53: CM-6;CM-6(1)
control.compliance.openshift.io/PCI-DSS: Req-2.2
policies.open-cluster-management.io/controls: 1.2.1,CIP-003-8 R6,CIP-004-6 R3,CIP-007-3
R6.1,CM-6,CM-6(1),Req-2.2
policies.open-cluster-management.io/standards: CIS-OCP,NERC-CIP,NIST-800-53,PCI-DSS
creationTimestamp: "2023-03-31T09:09:53Z"
generation: 1
labels:
compliance.openshift.io/profile-bundle: ocp4
name: ocp4-api-server-anonymous-auth
namespace: openshift-compliance
ownerReferences:
- apiVersion: compliance.openshift.io/v1alpha1
blockOwnerDeletion: true
controller: true
kind: ProfileBundle
name: ocp4
uid: 19c2e4a5-094f-416a-a06b-eb0598e39618
resourceVersion: "12971338"
uid: 12db5786-4ff6-4e80-90e0-2b370541f6e1
rationale: When enabled, requests that are not rejected by other configured authentication
methods are treated as anonymous requests. These requests are then served by the
API server. If you are using RBAC authorization, it is generally considered reasonable
to allow anonymous access to the API Server for health checks and discovery purposes,
and hence this recommendation is not scored. However, you should consider whether
anonymous discovery is an acceptable risk for your purposes.
severity: medium
title: Ensure that anonymous requests to the API Server are authorized
````
### Running a Scan
Now that we have the operator installed, we have two key configurations:
- ScanSettings - This is the Schema for the scansettings API, and therefore you will provide configurations for running the scan, such as where it stores data, configurations for the container that is run on the platform to perform the scan, which components are subject to be scanned, and schedules to run the scan.
- ScanSettingsBinding - This is the Schema for the scansettingbindings API. This is used to bind the ScanSettings configuration to the compliance profiles you want to run against your chosen components.
There is a default ScanSettings called ```default``` supplied when you install the Compliance Operator, which you can run against your system.
````sh
$ oc describe scansettings default -n openshift-compliance
Name: default
Namespace: openshift-compliance
Labels: <none>
Annotations: <none>
API Version: compliance.openshift.io/v1alpha1
Kind: ScanSetting
Max Retry On Timeout: 3
Metadata:
Creation Timestamp: 2023-03-31T09:09:33Z
Generation: 1
Resource Version: 12971055
UID: 78945c1e-c323-40d8-87d9-c571275d58e3
Raw Result Storage:
Node Selector:
node-role.kubernetes.io/master:
Pv Access Modes:
ReadWriteOnce
Rotation: 3
Size: 1Gi
Tolerations:
Effect: NoSchedule
Key: node-role.kubernetes.io/master
Operator: Exists
Effect: NoExecute
Key: node.kubernetes.io/not-ready
Operator: Exists
Toleration Seconds: 300
Effect: NoExecute
Key: node.kubernetes.io/unreachable
Operator: Exists
Toleration Seconds: 300
Effect: NoSchedule
Key: node.kubernetes.io/memory-pressure
Operator: Exists
Roles:
master
worker
Scan Tolerations:
Operator: Exists
Schedule: 0 1 * * *
Show Not Applicable: false
Strict Node Scan: true
Timeout: 30m
Events: <none>
````
You can read more details about the above [configuration here](https://docs.openshift.com/container-platform/4.12/security/compliance_operator/compliance-scans.html#running-compliance-scans_compliance-operator-scans), however, most of the lines are self-explanatory.
There is a second provided ScanSettings called ```default-auto-apply```, which follows the same premise as the above, however` will auto-remediate any findings as part of the scan.
Now we need to create a ScanSettingBinding to the CIS benchmark profiles. Create a YAML file using the below content called ````compliance-scansettingbinding.yaml```` and apply with ````oc apply -f compliance-scansettingbinding.yaml````.
````yaml
apiVersion: compliance.openshift.io/v1alpha1
kind: ScanSettingBinding
metadata:
name: cis-compliance
namespace: openshift-compliance
profiles:
- name: ocp4-cis-node
kind: Profile
apiGroup: compliance.openshift.io/v1alpha1
- name: ocp4-cis
kind: Profile
apiGroup: compliance.openshift.io/v1alpha1
settingsRef:
name: default
kind: ScanSetting
apiGroup: compliance.openshift.io/v1alpha1
````
At this stage of the workflow, the Compliance Operator reconciles the ScanSettingBinding object, taking into account both the ```Binding``` and ```Bound``` settings. As a result, it generates a ComplianceSuite object along with the corresponding ComplianceScan objects to streamline the compliance evaluation process.
````sh
$ oc get compliancescan -n openshift-compliance
NAME PHASE RESULT
ocp4-cis AGGREGATING NOT-AVAILABLE
ocp4-cis-node-master AGGREGATING NOT-AVAILABLE
ocp4-cis-node-worker AGGREGATING NOT-AVAILABLE
````
The scans will now work through the scanning phases and finish on the ```DONE``` phase once completed. At this point, you are probably going to find that the result is ```NON-COMPLIANT```. Now we can review the scan results and apply any necessary remediations to bring the cluster into compliance with the profile.
````sh
$ oc get compliancescan -n openshift-compliance
NAME PHASE RESULT
ocp4-cis DONE NON-COMPLIANT
ocp4-cis-node-master DONE NON-COMPLIANT
ocp4-cis-node-worker DONE NON-COMPLIANT
````
Let's look at the first scan in more detail, as we also want to capture the label attached, so we can get the full results to view.
````sh
$ oc get compliancescan -n openshift-compliance ocp4-cis -o yaml
````
````yaml
oc get compliancescan -n openshift-compliance ocp4-cis -o yaml
apiVersion: compliance.openshift.io/v1alpha1
kind: ComplianceScan
metadata:
creationTimestamp: "2023-03-31T10:49:41Z"
finalizers:
- scan.finalizers.compliance.openshift.io
generation: 1
labels:
compliance.openshift.io/suite: cis-compliance
name: ocp4-cis
namespace: openshift-compliance
ownerReferences:
- apiVersion: compliance.openshift.io/v1alpha1
blockOwnerDeletion: true
controller: true
kind: ComplianceSuite
name: cis-compliance
uid: c40db43f-0635-4731-b537-5ad3fc08cc06
resourceVersion: "13035410"
uid: 9d5b10b8-f67c-44f3-b13d-0765cb037091
spec:
content: ssg-ocp4-ds.xml
contentImage: registry.redhat.io/compliance/openshift-compliance-content-rhel8@sha256:c4bf5b2b20ff538adbc430b7ee993fbd7c291203a9810534005148304e3b169b
maxRetryOnTimeout: 3
profile: xccdf_org.ssgproject.content_profile_cis
rawResultStorage:
nodeSelector:
node-role.kubernetes.io/master: ""
pvAccessModes:
- ReadWriteOnce
rotation: 3
size: 1Gi
tolerations:
- effect: NoSchedule
key: node-role.kubernetes.io/master
operator: Exists
- effect: NoExecute
key: node.kubernetes.io/not-ready
operator: Exists
tolerationSeconds: 300
- effect: NoExecute
key: node.kubernetes.io/unreachable
operator: Exists
tolerationSeconds: 300
- effect: NoSchedule
key: node.kubernetes.io/memory-pressure
operator: Exists
scanTolerations:
- operator: Exists
scanType: Platform
showNotApplicable: false
strictNodeScan: true
timeout: 30m
status:
conditions:
- lastTransitionTime: "2023-03-31T10:51:20Z"
message: Compliance scan run is done running the scans
reason: NotRunning
status: "False"
type: Processing
- lastTransitionTime: "2023-03-31T10:51:20Z"
message: Compliance scan run is done and has results
reason: Done
status: "True"
type: Ready
phase: DONE
remainingRetries: 3
result: NON-COMPLIANT
resultsStorage:
name: ocp4-cis
namespace: openshift-compliance
warnings: |-
could not fetch /apis/flowcontrol.apiserver.k8s.io/v1alpha1/flowschemas/catch-all: the server could not find the requested resource
could not fetch /apis/logging.openshift.io/v1/namespaces/openshift-logging/clusterlogforwarders/instance: the server could not find the requested resource
could not fetch /apis/apps/v1/namespaces/openshift-sdn/daemonsets/sdn: daemonsets.apps "sdn" not found
could not fetch "/api/v1/nodes/NODE_NAME/proxy/configz": the server could not find the requested resource
could not fetch "/api/v1/nodes/NODE_NAME/proxy/configz": the server could not find the requested resource
could not fetch "/api/v1/nodes/NODE_NAME/proxy/configz": the server could not find the requested resource
could not fetch "/api/v1/nodes/NODE_NAME/proxy/configz": the server could not find the requested resource
could not fetch "/api/v1/nodes/NODE_NAME/proxy/configz": the server could not find the requested resource
could not fetch "/api/v1/nodes/NODE_NAME/proxy/configz": the server could not find the requested resource
could not fetch "/api/v1/nodes/NODE_NAME/proxy/configz": the server could not find the requested resource
could not fetch "/api/v1/nodes/NODE_NAME/proxy/configz": the server could not find the requested resource
could not fetch "/api/v1/nodes/NODE_NAME/proxy/configz": the server could not find the requested resource
could not fetch "/api/v1/nodes/NODE_NAME/proxy/configz": the server could not find the requested resource
could not fetch "/api/v1/nodes/NODE_NAME/proxy/configz": the server could not find the requested resource
could not fetch "/api/v1/nodes/NODE_NAME/proxy/configz": the server could not find the requested resource
could not fetch "/api/v1/nodes/NODE_NAME/proxy/configz": the server could not find the requested resource
could not fetch "/api/v1/nodes/NODE_NAME/proxy/configz": the server could not find the requested resource
could not fetch /apis/hypershift.openshift.io/v1beta1/namespaces/clusters/hostedclusters/None: the server could not find the requested resource
Kubelet configs for 90days-ocp-72ptq-master-1 are not consistent with role master, Diff: [{"op":"replace","path":"/address","value":"192.168.200.183"}] of KubeletConfigs for master role will not be saved.
Kubelet configs for 90days-ocp-72ptq-worker-x7v4j are not consistent with role worker, Diff: [{"op":"replace","path":"/address","value":"192.168.200.194"}] of KubeletConfigs for worker role will not be saved.
Kubelet configs for 90days-ocp-72ptq-master-2 are not consistent with role master, Diff: [{"op":"add","path":"/address","value":"192.168.200.181"}] of KubeletConfigs for master role will not be saved.
Kubelet configs for 90days-ocp-72ptq-master-0 are not consistent with role control-plane, Diff: [{"op":"replace","path":"/address","value":"192.168.200.185"}] of KubeletConfigs for control-plane role will not be saved.
Kubelet configs for 90days-ocp-72ptq-master-2 are not consistent with role control-plane, Diff: [{"op":"add","path":"/address","value":"192.168.200.181"}] of KubeletConfigs for control-plane role will not be saved.
Kubelet configs for 90days-ocp-72ptq-worker-5cgp8 are not consistent with role worker, Diff: [{"op":"add","path":"/address","value":"192.168.200.187"}] of KubeletConfigs for worker role will not be saved.
````
In the output, we can see the warnings from the results straight away. To view the full results we can run the command below using the label from the above output. Alternatively, I can list all failed results across the conducted scans by running the command:
````sh
$ oc get compliancecheckresults -n openshift-compliance -l 'compliance.openshift.io/check-status=FAIL'
NAME STATUS SEVERITY
ocp4-cis-api-server-encryption-provider-cipher FAIL medium
ocp4-cis-api-server-encryption-provider-config FAIL medium
ocp4-cis-audit-log-forwarding-enabled FAIL medium
ocp4-cis-configure-network-policies-namespaces FAIL high
ocp4-cis-kubeadmin-removed FAIL medium
ocp4-cis-node-master-kubelet-enable-protect-kernel-defaults FAIL medium
ocp4-cis-node-master-kubelet-enable-protect-kernel-sysctl FAIL medium
ocp4-cis-node-worker-kubelet-enable-protect-kernel-defaults FAIL medium
ocp4-cis-node-worker-kubelet-enable-protect-kernel-sysctl FAIL medium
````
We can look at the individual ```ComplianceRemediation``` in more detail with the command;
````sh
oc get compliancecheckresults -n openshift-compliance ocp4-cis-audit-log-forwarding-enabled -o yaml
````
Which provides us the following output:
````yaml
apiVersion: compliance.openshift.io/v1alpha1
description: |-
Ensure that Audit Log Forwarding Is Enabled
OpenShift audit works at the API server level, logging all requests coming to the server. Audit is on by default and the best practice is to ship audit logs off the cluster for retention. The cluster-logging-operator is able to do this with the
ClusterLogForwarders
resource. The forementioned resource can be configured to logs to different third party systems. For more information on this, please reference the official documentation: https://docs.openshift.com/container-platform/4.6/logging/cluster-logging-external.html
id: xccdf_org.ssgproject.content_rule_audit_log_forwarding_enabled
instructions: |-
Run the following command:
oc get clusterlogforwarders instance -n openshift-logging -ojson | jq -r '.spec.pipelines[].inputRefs | contains(["audit"])'
The output should return true.
kind: ComplianceCheckResult
metadata:
annotations:
compliance.openshift.io/rule: audit-log-forwarding-enabled
creationTimestamp: "2023-03-31T10:51:02Z"
generation: 1
labels:
compliance.openshift.io/check-severity: medium
compliance.openshift.io/check-status: FAIL
compliance.openshift.io/scan-name: ocp4-cis
compliance.openshift.io/suite: cis-compliance
name: ocp4-cis-audit-log-forwarding-enabled
namespace: openshift-compliance
ownerReferences:
- apiVersion: compliance.openshift.io/v1alpha1
blockOwnerDeletion: true
controller: true
kind: ComplianceScan
name: ocp4-cis
uid: 9d5b10b8-f67c-44f3-b13d-0765cb037091
resourceVersion: "13034914"
uid: c5b7342d-af35-4944-86bd-8a4f907acccc
rationale: Retaining logs ensures the ability to go back in time to investigate or
correlate any events. Offloading audit logs from the cluster ensures that an attacker
that has access to the cluster will not be able to tamper with the logs because
of the logs being stored off-site.
severity: medium
status: FAIL
````
This particular remediation has no automatic remediation, but you can see [another example here](https://docs.openshift.com/container-platform/4.12/security/compliance_operator/compliance-operator-remediation.html#compliance-review_compliance-remediation), whereby a ```MachineConfig``` resource will be applied by the remediation. Applying remediation can take different forms, depending on what the remediation is. Therefore I won't dive into this detail today, I think we've covered enough to understand how to run and view compliance checks against our platform. You can read more about [remediations here](https://docs.openshift.com/container-platform/4.12/security/compliance_operator/compliance-operator-remediation.html#compliance-applying_compliance-remediation). The final point I wanted to highlight on this topic, is the ```oc-compliance``` plugin, which extends the functionality of the ```oc``` CLI tool, you can few the [details and how to use it here](https://docs.openshift.com/container-platform/4.12/security/compliance_operator/oc-compliance-plug-in-using.html).
# Red Hat Quay Container Security Operator
## Vulnerability Scanning Overview
Vulnerability scanning in Red Hat OpenShift refers to the process of inspecting container images for known security issues, such as outdated software packages, misconfigurations, or exposed sensitive information. The goal of vulnerability scanning is to identify and remediate potential security risks in container images before they are deployed to the OpenShift cluster, thus enhancing the overall security posture of the platform.
OpenShift provides several features and tools to facilitate vulnerability scanning:
- Integrated container registry: OpenShift includes a built-in container registry to store and manage container images. The integrated registry allows for a more streamlined and secure process when scanning images for vulnerabilities, as it eliminates the need to rely on external registries.
- ImageStreams: An ImageStream in OpenShift is an abstraction that represents a series of related container images, typically different versions of the same application. ImageStreams simplify the process of tracking and deploying container images, making it easier to apply vulnerability scanning and remediation across multiple versions of an application.
- Image signing and trust: OpenShift supports container image signing and the enforcement of signature-based trust policies. This feature ensures that only trusted and verified images can be deployed to the cluster, helping to prevent the deployment of images with known vulnerabilities.
- Third-party integrations: OpenShift can be easily integrated with external vulnerability scanning tools and platforms, such as Aqua Security, Sysdig, or Twistlock. These tools can be configured to automatically scan container images stored in the OpenShift registry and provide detailed reports on identified vulnerabilities and suggested remediation steps.
- OpenShift Operators: OpenShift supports the use of Operators, which are automated software extensions that manage applications and their components. Operators can be used to deploy and manage vulnerability scanning tools within the OpenShift cluster, ensuring a consistent and automated scanning process. Red Hat provides the ```Red Hat Quay Container Security Operator```, however, you can also implement third-party scanners such as [Trivy](https://github.com/aquasecurity/trivy) from [Aqua Security](https://aquasec.com/).
By leveraging these features and tools, Red Hat OpenShift enables organizations to perform comprehensive vulnerability scanning on container images, reducing the risk of security breaches and enhancing the overall security of the platform.
Focusing on the ```Red Hat Quay Container Security Operator```, this provides the following:
- Watches containers associated with pods on all or specified namespaces
- Queries the container registry where the containers came from for vulnerability information, provided an image’s registry is running image scanning (such as Quay.io or a Red Hat Quay registry with Clair scanning)
- Exposes vulnerabilities via the ImageManifestVuln object in the Kubernetes API
## Installing the Red Hat Quay Container Security Operator
This time I'm going to provide instructions on how to perform these steps in the Red Hat Console interface, rather than CLI.
1. In the administrator view within the console, navigate to Operators > OperatorHub and search for "Red Hat Quay Container Security Operator".
2. Select the tile, and click to install.
3. Confirm the settings
- All namespaces and automatic approval strategy are selected, by default.
4. Select Install. The Container Security Operator appears after a few moments on the Installed Operators screen.
When you now browse to the homepage of the Red Hat OpenShit Console, you will see an "Image vulnerability" component on the status tile, which you can select to see high-level information about your estate.
![Red Hat OpenShift Console - Image vulnerability](/2023/images/Day62%20-%20Red%20Hat%20Quay%20Container%20Security%20Operator/Red%20Hat%20Console%20-%20Image%20vulnerability.jpg)
You can click on the circle graph or the namespaces to see more details which takes you to the navigation page of Adminstration (1) > Image Vulnerabilities (2).
Now you can see a list of the vulnerabilities and you can change the project view for all projects or a specific one to curate this list.
![Red Hat OpenShift Console - Administration - Image vulnerabilities](/2023/images/Day62%20-%20Red%20Hat%20Quay%20Container%20Security%20Operator/Red%20Hat%20OpenShift%20Console%20-%20Administration%20-%20Image%20vulnerabilities.jpg)
Clicking the image name (3) will show further manifest details via the OpenShift console, including which pods are affected. Or you can click the Manifest details on the right-hand side (4) which will take you to the Quay Security Scanner report hosted on [Quay.io](https://Quay.io).
Below shows the Image manifest details including each vulnerability found with that image, and links to appropriate documentation, such as CVE information held on [access.redhat.com](https://access.redhat.com
)
![Red Hat OpenShift Console - Administration - Image vulnerabilities - Manifest details](/2023/images/Day62%20-%20Red%20Hat%20Quay%20Container%20Security%20Operator/Red%20Hat%20OpenShift%20Console%20-%20Administration%20-%20Image%20vulnerabilities%20-%20Manifest%20details.jpg)
Below is the ```affected pods``` tab view on the Image manifests page.
![Red Hat OpenShift Console - Administration - Image vulnerabilities - Manifest details - Affected pods](/2023/images/Day62%20-%20Red%20Hat%20Quay%20Container%20Security%20Operator/Red%20Hat%20OpenShift%20Console%20-%20Administration%20-%20Image%20vulnerabilities%20-%20Manifest%20details%20-%20Affected%20pods.jpg)
And finally the Quay Security Scanner page for one of the images shown in the report. This was for my pacman application, you can see the Quay.io report yourself [here](https://quay.io/repository/ifont/pacman-nodejs-app/manifest/sha256:196ae9a1a33a2d32046a46739779ca273667f1d4f231f8a721e8064c3509405e?tab=vulnerabilities)(free sign up account required).
![Red Hat OpenShift Console - Administration - Image vulnerabilities - Quay Manifest](/2023/images/Day62%20-%20Red%20Hat%20Quay%20Container%20Security%20Operator/Red%20Hat%20OpenShift%20Console%20-%20Administration%20-%20Image%20vulnerabilities%20-%20Quay%20Manifest.jpg)
Of course we can also see information in the command line too, to see all vulnerabilities found, use the command:
```sh
oc get vuln --all-namespaces
NAMESPACE NAME AGE
openshift-apiserver-operator sha256.01974e4c0e0d112e09bee8fe2625d565d3d62fa42013b38d7ce43d2d40f6057a 20h
openshift-apiserver sha256.13640b919950fc648219c528ee7ed30262bae856566fbd6c4cb5e15ffd457d6f 20h
openshift-apiserver sha256.8829aefa24dd606d2fe3ff86b97858c07acedae5f5eb3f044c20395762e7c02b 20h
openshift-authentication-operator sha256.31b617cec5c22e187cc22da606fc6998ea3529b1b6e8d80d1799c3dc9705997e 20h
openshift-authentication sha256.41e06255fc823c0082a74466b69ccfb672947b7075ea43a10e729c5f39314d00 20h
openshift-cloud-controller-manager-operator sha256.a7856b6371fc4a7ade8a678daca149db6c6a55ee7137d9e308721d2d3bebf364 20h
openshift-cloud-credential-operator sha256.1986315effe0f3ee415e86df3a87765268ed1da405c7a297c278e1d7030286a4 20h
...
openshift-vsphere-infra sha256.ddf81e535cf7a6b2775f3db690ec1e6eaa1c7427a0f9b98ce120d8ad06520440 20h
test-app sha256.196ae9a1a33a2d32046a46739779ca273667f1d4f231f8a721e8064c3509405e 20h
```
You can inspect the details of a specific vulnerability by running the command:
```sh
oc describe vuln -n {namespace} {sha ID of vuln}
# Example
oc describe vuln -n openshift-apiserver-operator sha256.01974e4c0e0d112e09bee8fe2625d565d3d62fa42013b38d7ce43d2d40f6057a
```
Example output:
```yaml
Name: sha256.01974e4c0e0d112e09bee8fe2625d565d3d62fa42013b38d7ce43d2d40f6057a
Namespace: openshift-apiserver-operator
Labels: openshift-apiserver-operator/openshift-apiserver-operator-7bd84bd596-pgpct=true
Annotations: <none>
API Version: secscan.quay.redhat.com/v1alpha1
Kind: ImageManifestVuln
Metadata:
Creation Timestamp: 2023-03-30T19:01:40Z
Generation: 17
Resource Version: 13206497
UID: dbec02e5-e4c6-412f-b561-757237844d43
Spec:
Features:
Name: pip
Version: 9.0.3
Vulnerabilities:
Description: Pip 21.1 updates its dependency 'urllib3' to v1.26.4 due to security issues.
Metadata: {"UpdatedBy": "pyupio", "RepoName": "pypi", "RepoLink": "https://pypi.org/simple", "DistroName": "", "DistroVersion": "", "NVD": {"CVSSv3": {"Vectors": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N", "Score": 6.5}}}
Name: pyup.io-40291 (CVE-2021-28363)
Namespace Name: pyupio
Severity: Medium
Description: A flaw was found in python-pip in the way it handled Unicode separators in git references. A remote attacker could possibly use this issue to install a different revision on a repository. The highest threat from this vulnerability is to data integrity. This is fixed in python-pip version 21.1.
Metadata: {"UpdatedBy": "pyupio", "RepoName": "pypi", "RepoLink": "https://pypi.org/simple", "DistroName": "", "DistroVersion": "", "NVD": {"CVSSv3": {"Vectors": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:H/A:N", "Score": 5.7}}}
Name: pyup.io-42559 (CVE-2021-3572)
Namespace Name: pyupio
Severity: Medium
Description: Pip before 19.2 allows Directory Traversal when a URL is given in an install command, because a Content-Disposition header can have ../ in a filename, as demonstrated by overwriting the /root/.ssh/authorized_keys file. This occurs in _download_http_url in _internal/download.py.
Metadata: {"UpdatedBy": "pyupio", "RepoName": "pypi", "RepoLink": "https://pypi.org/simple", "DistroName": "", "DistroVersion": "", "NVD": {"CVSSv3": {"Vectors": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N", "Score": 7.5}}}
Name: pyup.io-38765 (CVE-2019-20916)
Namespace Name: pyupio
Severity: High
Name: openssl-libs
Version: 1:1.1.1k-7.el8_6
Vulnerabilities:
Description: OpenSSL is a toolkit that implements the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols, as well as a full-strength general-purpose cryptography library.
Security Fix(es):
* openssl: X.400 address type confusion in X.509 GeneralName (CVE-2023-0286)
For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.
Fixedby: 1:1.1.1k-8.el8_6
Link: https://access.redhat.com/errata/RHSA-2023:1441 https://access.redhat.com/security/cve/CVE-2023-0286
Metadata: {"UpdatedBy": "RHEL8-rhel-8.6-eus", "RepoName": "cpe:/o:redhat:rhel_eus:8.6::baseos", "RepoLink": null, "DistroName": "Red Hat Enterprise Linux Server", "DistroVersion": "8", "NVD": {"CVSSv3": {"Vectors": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:H", "Score": 7.4}}}
Name: RHSA-2023:1441: openssl security update (Important)
Namespace Name: RHEL8-rhel-8.6-eus
Severity: High
Name: urllib3
Version: 1.24.2
Vulnerabilities:
Description: Urllib3 1.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect.
Metadata: {"UpdatedBy": "pyupio", "RepoName": "pypi", "RepoLink": "https://pypi.org/simple", "DistroName": "", "DistroVersion": "", "NVD": {"CVSSv3": {"Vectors": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H", "Score": 7.5}}}
Name: pyup.io-43975 (CVE-2021-33503)
Namespace Name: pyupio
Severity: High
Description: urllib3 before 1.25.9 allows CRLF injection if the attacker controls the HTTP request method, as demonstrated by inserting CR and LF control characters in the first argument of putrequest(). NOTE: this is similar to CVE-2020-26116.
Metadata: {"UpdatedBy": "pyupio", "RepoName": "pypi", "RepoLink": "https://pypi.org/simple", "DistroName": "", "DistroVersion": "", "NVD": {"CVSSv3": {"Vectors": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N", "Score": 7.2}}}
Name: pyup.io-38834 (CVE-2020-26137)
Namespace Name: pyupio
Severity: High
Name: setuptools
Version: 39.2.0
Vulnerabilities:
Description: Python Packaging Authority (PyPA) setuptools before 65.5.1 allows remote attackers to cause a denial of service via HTML in a crafted package or custom PackageIndex page. There is a Regular Expression Denial of Service (ReDoS) in package_index.py.
Metadata: {"UpdatedBy": "pyupio", "RepoName": "pypi", "RepoLink": "https://pypi.org/simple", "DistroName": "", "DistroVersion": "", "NVD": {"CVSSv3": {"Vectors": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H", "Score": 5.9}}}
Name: pyup.io-52495 (CVE-2022-40897)
Namespace Name: pyupio
Severity: Medium
Image: quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256
Manifest: sha256:01974e4c0e0d112e09bee8fe2625d565d3d62fa42013b38d7ce43d2d40f6057a
Status:
Affected Pods:
openshift-apiserver-operator/openshift-apiserver-operator-7bd84bd596-pgpct:
cri-o://dd4fcb700a95c041d19bf7829d3e07516ccf2a36522027f920d76ed0aa57f84c
Fixable Count: 1
High Count: 4
Highest Severity: High
Last Update: 2023-03-31 15:31:32.853602342 +0000 UTC
Medium Count: 3
Events: <none>
```
# Summary
Whilst for this 2023 edition focusing on DevSecOps, we could have purely spent time focusing on Security and Compliance for Red Hat OpenShift in-depth, I wanted to start at a higher level, understanding why you would choose an enterprise Kubernetes offering, and what features will enhance your cloud-native platform. Hopefully, this has given you a solid understanding of this offering, as well as being able to understand the basics of how to run and operate it. Another area we only touched upon briefly was application deployment, instead focusing on the security posture of deploying workloads, rather than the methods of building and running the applications themselves. This topic of application build, deployment and management requires a whole section on its own.
I urge you to spend time reading through the official documentation for Red Hat OpenShift, it's quite comprehensive with the information you need to fully get to grips and operate the platform.
## Resources
- Red Hat OpenShift Documentation
- [OpenShift Container Platform security and compliance](https://docs.openshift.com/container-platform/4.12/security/index.html)
- [Understanding container security](https://docs.openshift.com/container-platform/4.12/security/container_security/security-understanding.html#security-understanding)
- [Troubleshooting the Compliance Operator](https://docs.openshift.com/container-platform/4.12/security/compliance_operator/compliance-operator-troubleshooting.html)
- [Running the Red Hat Quay Container Security Operator](https://docs.openshift.com/container-platform/4.12/security/pod-vulnerability-scan.html)
- [Securing container content](https://docs.openshift.com/container-platform/4.12/security/container_security/security-container-content.html)
- [Red Hat OpenShift security guide (ebook)](https://www.redhat.com/en/resources/openshift-security-guide-ebook)
- YouTube - [ CVE and CVSS explained | Security Detail | Presented by Red Hat](https://www.youtube.com/watch?v=oSyEGkX6sX0)

62
2023/day85.md
View File

@ -0,0 +1,62 @@
# Queues, Queue workers and Tasks (Asynchronous architecture)
Yesterday we looked at how we can use HTTP based APIs for communication between services. This works well until you need
to scale, release a new version or one of your services goes down. Then we start to see the calling service fail because
it’s dependency is not working as expected. We have tightly coupled our two services, one can’t work without the other.
There are many ways to solve this problem, a light touch approach for existing applications is to use something called a
circuit breaker to buffer failures and retry until we get a successful response. This is explained well in this blog
by [Martin Fowler](https://martinfowler.com/bliki/CircuitBreaker.html). However, this is synchronous, if we were to wrap
our calls in a circuit breaker we would start to block processes and our user could see a slowdown in response times.
Additionally, we can’t scale our applications using this approach, the way that the code is currently written every
instance of our `generator` api would be asking
the `requestor for confirmation of receiving the string. This won’t scale well when we move to having 2, 5, 10, or 100 instances running. We would quickly see the `
requestor` being overwhelmed with requests from the 100 generator applications.
There is a way to solve these problems which is to use Queues. This is a shift in thinking to using an asynchronous
approach to solving our problem. This can work well when the responses don’t need to be immediate between applications.
In this case it doesn't matter if we add some delay in the requests between the applications. As long as the data
eventually flows between them we are happy.
![Queues, producers and Consumers](./images/day84-queues.png)
(https://dashbird.io/knowledge-base/well-architected/queue-and-asynchronous-processing/)
In the drawing above we can see how we can add a Queue in between our applications and the Queue stores the intent of
the message across the bridge. If the Consumer was to fail and stop reacting messages then, providing our Queue software
has sufficient storage, the messages to the consumer would still “succeed” as far as the producer is concerned.
This is a powerful pattern that isolates components of a system from each other and limits the blast radius of failure.
It does however add complexity. The Consumer and Producer must share a common understanding of the shape of a message
otherwise the Consumer will be unable to act on the message.
We are going to implement a Queue in between our two applications in our data flows.
By the end of the section we will have the following data flows
Requestor (asks for a random string) → Queue → Generator (gets the message, generates a string and passes it back to the
Requestor on another Queue) → Requestor (gets the string back on a queue and stores it, then sends a message to the
queue saying it has received it) → Queue → Generator (marks that the message was received)
The last section here, where the Generator needs to know if the Requestor got the message is a simplification of a real
process where an application may pass back an enriched data record or some further information but it allows us to have
a simple two way communication.
Can you see how by the end of this section we will be able to stop, scale, deploy or modify each of the two components
without the other needing to know?
## Modifying our application
We are now going to modify our app to fit the model described above. Where we previously made a HTTP api call to our
partner app we are now going to place a message on a named queue and then subscribe to the corresponding response
queues.
Finally we are going to stop using HTTP endpoints to listen for requests, we are now subscribing to queues and waiting
for messages before we perform any work.
I have picked [NATSio](https://nats.io/) as the queue technology as I have worked with it previously and it’s very easy
to set up and use.
Head over to the 2023/day2-ops-code/README.md to see how to deploy day 2's application.
It sends messages to a queue and then waits for a response. The response is a message on a different queue. The message
contains the data that we are interested in.

95
2023/day86.md
View File

@ -0,0 +1,95 @@
# Designing for Resilience, Redundancy and Reliability
We now have an application which uses asynchronous queue based messaging to communicate. This gives us some real
flexibility on how we design our system to withstand failures. We are going to look at the concept of Failure Zones,
Replication, Contract testing, Logging and Tracing to build more robust systems.
## Failure Zones
Imagine building an application and deploying everything onto a single VM or server. What happens when, inevitably, this
server fails. Your application goes offline and your customers won’t be happy! There’s a fix to this. Spread your
workloads over multiple points of failure. This doesn’t just go for your application instances but you can build
multiple redundant points for every aspect of your system.
Ever wonder what some of the things large cloud providers do to keep their services running despite external and
unpredictable factors? For starters they will have generators on-site for when they inevitably suffer a power cut. They
have at least two internet connections into the datacentres and they often provide multiple availability zones in each
region. Take Amazon’s eu-west-2 (London) region. This has 3 availability zones, eu-west-2a, eu-west-2b and eu-west-2c.
There are 3 separate datacenters (physically separated) that all inter-connect to provide a single region. This means by
deploying services across these availability zones (AZs) we increase our redundancy and resilience over factors such as
a fire in one of these facilities. If you run a homelab you could distribute work over failure zones by running more
than one computer, placing these computers in separate parts of the house or buying 2 internet connections to stay
online if one goes down (This does mean checking that these connections don’t just run on the same infrastructure as
soon as they leave your door. At my house I can get fibre to my house and also a connection over the old phone lines)
## Replication
This links nicely into having multiple replicas of our “stuff”, this doesn’t just mean running 2 or 3 copies of our
application over our previously mentioned availability zones we also need to consider our data - If we ran a database in
AZ1 and our application code over AZ1, AZ2 and AZ3 what do you think would happen if AZ1 was to go offline, potentially
permanently? There have been instances of cloud datacenters being completely destroyed by fire and many customers had
not been backing up their data or running across multiple AZs. Your data in this case is… gone. Do you think the
business you workin in could survive if their data, or their customers data, just disappeared overnight?
Many of our data storage tools come with the ability to be configured for replication across multiple failure zones.
NATS.io that we used previously can be configured to replicate messages across multiple instances to survive failure of
one or more zones. Postgresql databases can be configured to stream their WAL (Write ahead log), which stores an
in-order history of all the transactions, to a standby instance running somewhere else. If our primary fails then the
most we would lose would be the amount of data in our WAL that was not transferred to the replica. Much less data loss
than if we didn’t have any replication.
## Contract Testing
We are going to change direction now and look at making our applications more reliable. This means reducing the change
of failures. You may appreciate that the time most likely to cause failures in your system is during deployments. New
code hits our system and if it has not been tested thoroughly in production-like environments then we may end up with
undefined behaviours.
There’s a concept called Contract testing where we can test the interfaces between our applications at development and
build time. This allows us to rapidly get feedback (a core principle of DevOps) on our progress.
## Async programming and queues
We have already discussed how breaking the dependencies without our system can lead to increased reliability. Our
changes become smaller, less likely to impact other areas of our application and easy to roll-back.
If our users are not expecting an immediate tactile response to an event, such as requesting a PDF be generated then we
can always place a message onto a queue and just wait for the consumer of that message to eventually get round to it. We
could see a situation where thousands of people request their PDF at once and an application that does this
synchronously would just fall over, run out of memory and collapse. This would leave all our customers without their
PDFs and needing to take an action again to wait for them to be generated. Without developer intervention we may not get
back to a state where the service can recover.
Using a queue we can slowly work away in the background to generate these PDFs and could even scale the service in the
background automatically when we noticed the queue getting longer. Each new application would just take the next message
from the queue and work through the backlog. Once we were seeing less demand we could automatically scale these services
down when our queue depth reached 0.
## Logging and Tracing
It goes without saying that our applications and systems will fail. What we are doing in this section of 90daysOfDevOps
is thinking about what we can do to make our lives less bad when things do. Logging and tracing are some really
important tools in our toolbox to keep ourselves happy.
If we log frequently with both success and failure messages we can follow the progress of our requests and customer
journeys through our system then when things go wrong we can quickly rule out specific services or focus down on
applications that are logging warning or error messages. My general rule is that you can’t log too much - its not
possible! It is however important to use a log framework that lets you tune the log level that gets printed to your
logs. For example if i have 5 log levels (as is common), TRACE, DEBUG, INFO, WARN and ERROR we should have a mechanism
for ever application to set the level of logs we want to print. Most of the time we only want WARN and ERROR to be
visible in logs, to quickly show us theres and issue. However if we are in development or debugging a specific
application its important to be able to turn up the verbosity of our logs and see those INFO/DEBUG or TRACE levels.
Tracing is a concept of being able to attack a unique identifier to a request in our system that then gets populated and
logged throughout that requests journey, we could see a HTTP request hit a LoadBalancer, get a correlationID and then we
want to see that correlationID in ever log line as our request’s actions percolate through our system.
## Conclusion
It’s hard to build a fully fault-tolerant system. It involves learning from our, and other people’s, mistakes. I have
personally made many changes to company infrastructure after we discovered a previously unknown failure zone in our
application.
We could change our application running in Kubernetes to tolerate our underlying infrastructure’s failure zones by
leveraging [topology spread constraints](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/)
to spread replicas around. We won’t in this example as we have much more to cover!

72
2023/day87.md
View File

@ -0,0 +1,72 @@
# Zero Downtime Deployments
Another important part of your application lifecycle is deployment time. There are lots of strategies for deploying
software. Like with anything there are pros and cons to the various strategies so I will run through a few options from
least complex to most complex, and as you may imagine the most complex deployment types tend come with the highest
guarantees of uptime and least disruption to your customer.
You may be asking why it's important to consider how we deploy our applications as the vast majority of our application
lifecycle time will be in the “running” state and therefore we could focus our time on strategies that support our
running application’s resilience. My answer is: Have you ever been on-call? Almost all incidents are due to code
releases or changes. The first thing I do when im on-call and called to an incident is see what was recently deployed -
I focus my main attention on that component and more often than not it was to blame.
We do also need to consider that some of these deployment strategies will require us to make specific code changes or
application architecture decisions to allow us to support the specific deployment in question.
### Rolling Deployments
One of the simplest deployment strategies is a rolling deployment. This is where we slowly, one by one (or many be many,
depending on how many instances of a service you have) we replace old deployments with their new tasks. We can check
that the new deployments are healthy before moving onto the next, only have a few tasks not healthy at a time.
This is the default deployment strategy in Kubernetes. It actually borrows some characteristics from Surge, which is
coming next. It starts slightly more new tasks and waits for them to be healthy before removing old ones.
### Surge Deployments
Surge deployments are exactly what they sound like. We start a large number of new tasks before cutting over traffic to
those tasks and then draining traffic from our old tasks. This is a good strategy when you have high usage applications
that may not cope well with reducing their availability at all. Usually surge deployments can be configured to run a
certain percentage more than the existing tasks and then wait for them to be healthy before doing a cutover.
The problem with surge deployments is that we need a large capacity of spare compute resources to spin up a lot of new
tasks before rolling over and removing the old ones. This can work well where you have very elastic compute such as AWS
Fargate where you don’t need to provision more compute yourself.
### Blue/Green
The idea behind a Blue/Green deployment is that your entire stack (or application) is spun up, tested and then finally
once you are happy you change config to send traffic to the entire new deployment. Sometimes companies will always have
both a Blue and a Green stack running. This is a good strategy where you need very fast rollback and recovery to a known
good state. You can leave your “old” stack running for any amount of time once you are running on your new stack.
### Canary
Possibly one of the most complicated deployment strategies. This involves deploying a small number of your new
application and then sending a small portion of load to the new service, checking that nothing has broken by monitoring
application performance and metrics such as 4XX or 5XX error rates and then deciding if we continue with the deployment.
In advanced setups the canary controllers can do automatic rollbacks if error thresholds are exceeded.
This approach does involve a lot more configuration, code and effort.
Interestingly the name comes from from coal mining and the phrase "canary in the coal mine." Canary birds have a lower
tolerance to toxic gases than humans, so they were used to alert miners when these gases reached dangerous levels inside
the mine.
We use our metrics and monitoring to decide if our “canary” application is healthy and if it is, we then proceed with a
larger deployment.
## Application design considerations
You may have worked out by now that the more advanced deployment strategies require you to have both old and new
versions of your application running at once. This means that we need to ensure backwards compatibility with all the
other software running at the time. For instance, you couldn't use a database migration to rename a table or column
because the old deployment would no longer work.
Additionally, our canary deployment strategy requires our application to have health checks, metrics, good logging and
monitoring so that we can detect a problem in our specific canary application deployment. Without these metrics we would
be unable to programmatically decide if our new application works.
Both these considerations, along with others, mean that we need to spend extra time both on our application code,
deployment code and our monitoring and alerting stacks to take advantage of the most robust deployments.

29
2023/day88.md
View File

@ -0,0 +1,29 @@
# Monitoring, Alerting and On-Call
As we have discussed there is no such thing as a perfect system that will never fail. Therefore we need to think about what to do when things go wrong. First and foremost the most important thing is not to panic. What tools and processes can we put in place to make incidents less stressful, easier to resolve and less likely to occur again?
## On-Call Practices
If you have never been “on-call” then you are an extremely lucky human. Being on-call for a system means being alerted when something is going wrong and being responsible for logging on, diagnosing the problem and helping to fix it.
When we build software that people and businesses rely on we become liable for keeping those systems going. Our customers expect a certain level of uptime and availability for the services they are paying for. Let’s look at two examples, a Business-To-Business internal app for tracking month-end accounting and a real-time payments system with thousands of transactions a second with cumulative values of millions of pounds a minute.
## Alerts: the good, bad and ugly
How do you even know if your application is working?
Alerts. These are notifications that inform you about the status or performance of your application. They can be configured to trigger when specific events or conditions occur, such as errors, timeouts, or spikes in traffic. I have seen `ERROR` log lines being used to trigger alerts as well as issues such as 4XX and 5XX http responses. You can practically alert on anything! If you wanted to know if your applications need to be scaled you could look at your message queue depth (number of messages in the queue) - if its growing or beyond a threshold you can either alert, or even better, you can automatically scale your application.
Alerts can be very useful in detecting and resolving issues quickly, which can help prevent downtime or other negative consequences. They allow you to proactively monitor your application and respond to issues before they become critical.
However, there can also be downsides to using alerts. If alerts are not properly configured or managed, they can generate a high volume of false alarms, which can be overwhelming and distract from real issues. This can lead to alert fatigue and decreased effectiveness in responding to issues.
It is important to carefully consider the types of alerts that are necessary for your application, and to regularly review and adjust your alert settings as needed. You should also have processes in place for responding to alerts, such as escalation procedures and clear documentation on how to resolve common issues.
## The cost of on-call
I have worked on systems similar to both of these hypothetical examples and I can tell you that the approach to on-call and incident management was wildly different. The month-end accounting software is only used by a handful of well-known customers sporadically - they may not log-in for many weeks before there being a flurry of activity for 2 days a month. The payments platform has constant and relentless use with many thousands of impacted people per minute.
There’s an important message here around knowing your users, their tolerance for downtime and their usage patterns.
For the payments platform the on-call rota was 24-7 365 days a year. Every second counts and they expected an engineer to be online within a few minutes of being notified of a problem. This puts strain on your engineers and incident staff as even simple daily tasks become challenging - I can’t walk my dog today because I’m on-call and if called I need to be online within a few minutes.
There’s very little fun about being on-call. You are tied to a location or always carrying your laptop, you get woken in the middle of your night and it's wildly unpredictable. If you can cope with some delay in fixing your system I highly recommend cutting your teams some slack and having good grace periods for getting online or muting alerts overnight. Obviously this isn't possible for all systems so where you need fast on-call cover make sure to keep an eye on your colleagues and look out for signs of stress and burnout.

25
2023/day89.md
View File

@ -0,0 +1,25 @@
# Oops: When something goes wrong - Post Mortems
As we have already discussed things will go wrong! We now know how to build applications where the impact of things breaking is less and where we know when things break. However, there will always be unknowns in the system and there will always be human error.
We need to build up a culture that fosters learning and improving from mistakes and one that understands that failure is inevitable. It’s the only way we learn. If the culture does not recognise this then we can quickly get into a situation where everyone is scared to make changes or take risks and therefore nothing improves.
## Blameless culture
We are trying to build a “Blameless culture” where people are free to experiment, change and adapt. The key to this culture is always assuming someone had the best intentions based on the available information. This means that if somebody pressed a big button on your backend dashboard that dropped your production database they only did this because they did not have enough information to know not to do this! It means not blaming the intern for taking down production (As, why did they have the ability to make such a change?).
Having a blameless culture leads to “Psychological Safety”. Psychological safety is a term used to describe a workplace environment where employees feel comfortable and safe to take interpersonal risks, such as sharing ideas, asking for help, or admitting mistakes, without fear of negative consequences.
In a psychologically safe workplace, employees feel that their opinions and contributions are valued, and they are free to express themselves without fear of ridicule, retribution, or ostracism. This can lead to increased trust and collaboration among team members, as well as improved innovation and problem-solving.
Psychological safety has been found to be an important factor in team effectiveness and organisational performance, and it has been linked to positive outcomes such as higher job satisfaction, lower turnover rates, and better overall team performance.
Can you see how important it is to have a blameless culture with psychological safety? Without it nothing gets done.
## Post Mortems
Hopefully this section will explain why we have looked into a blameless culture with psychological safety. When things go wrong we need to be able to look at the objectively and ask “What went wrong? Why and What can we do to reduce the likelihood (or risk) of this happening again?”
If your team or organisation are not mature enough to sit down together and admit their mistakes, what information was missing to them at 2AM when they were trying to fix a system outage or to take the emotion of failure out of the picture then its going to be hard for everyone to share honestly.
Can you say that your organisation would be happy to hear from a new employee on what mistake they made that had a big customer impact without blaming them? They should. If they made that mistake then it means that anyone was able to make it, at any time. Build guard rails into your system around these incidents. [This is covered well by this website covering retrospectives](https://www.funretrospectives.com/the-retrospective-prime-directive/) as at the end of the day, a post mortem is just a retrospective.
So, after an incident its very important to sit down and have an honest and open conversation about what went wrong and what should be done to fix those issues, and who is responsible for making those changes. This can be as informal as having a coffee with the key stakeholders or as formal as putting a calendar invite in and getting everyone together from across the business.

BIN
2023/images/.DS_Store vendored Normal file
View File

Binary file not shown.

0
2023/images/cl-OpenShift-container-platform-datasheet-f31593_image1.png → 2023/images/Day56-OpenShift-container-platform-datasheet.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 258 KiB

After

Width:  |  Height:  |  Size: 258 KiB

0
2023/images/Creating the bootstrap control plane and compute machines.png → 2023/images/Day57 - Red Hat OpenShift Architecture/Creating the bootstrap control plane and compute machines.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 59 KiB

After

Width:  |  Height:  |  Size: 59 KiB

0
2023/images/OpenShift Container Platform installation targets and dependencies.png → 2023/images/Day57 - Red Hat OpenShift Architecture/OpenShift Container Platform installation targets and dependencies.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 114 KiB

After

Width:  |  Height:  |  Size: 114 KiB

0
2023/images/OpenShift Container Platform lifecycle.png → 2023/images/Day57 - Red Hat OpenShift Architecture/OpenShift Container Platform lifecycle.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 97 KiB

After

Width:  |  Height:  |  Size: 97 KiB

0
2023/images/Red Hat OpenShift - Product Architecture.png → 2023/images/Day57 - Red Hat OpenShift Architecture/Red Hat OpenShift - Product Architecture.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 209 KiB

After

Width:  |  Height:  |  Size: 209 KiB

0
2023/images/Day58 - OpenShift Cluster Install/OpenShift-Install create cluster - Sorry, your reply was invalid- IP expected to be in one of the machine networks- 10.0.0.0:16.jpg → 2023/images/Day58 - OpenShift Cluster Install/OpenShift-Install create cluster - Sorry, your reply was invalid- IP expected to be in one of the machine networks- 10.0.0.0-16.jpg
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 52 KiB

After

Width:  |  Height:  |  Size: 52 KiB

BIN
2023/images/Day61 - Authentication - Role-Based Access Control and Auditing in Red Hat OpenShift/Red Hat OpenShift - Access Control - Relationship between cluster roles, local roles and role bindings.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 164 KiB

BIN
2023/images/Day61 - Authentication - Role-Based Access Control and Auditing in Red Hat OpenShift/oc login.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 39 KiB

BIN
2023/images/Day62 - Red Hat Quay Container Security Operator/Red Hat Console - Image vulnerability.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 197 KiB

BIN
2023/images/Day62 - Red Hat Quay Container Security Operator/Red Hat OpenShift Console - Administration - Image vulnerabilities - Manifest details - Affected pods.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 91 KiB

BIN
2023/images/Day62 - Red Hat Quay Container Security Operator/Red Hat OpenShift Console - Administration - Image vulnerabilities - Manifest details.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 268 KiB

BIN
2023/images/Day62 - Red Hat Quay Container Security Operator/Red Hat OpenShift Console - Administration - Image vulnerabilities - Quay Manifest.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 248 KiB

BIN
2023/images/Day62 - Red Hat Quay Container Security Operator/Red Hat OpenShift Console - Administration - Image vulnerabilities.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 197 KiB

BIN
2023/images/day36-1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 327 KiB

BIN
2023/images/day36-2.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 149 KiB

BIN
2023/images/day37-1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 188 KiB

BIN
2023/images/day37-2.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 58 KiB

Some files were not shown because too many files have changed in this diff Show More