[CloudClub] 90DaysOfDevOps 1차

박서연·2023년 9월 14일

클라우드

Cloud

목록 보기

6/13

Day1

DevOps: 소프트웨어 개발에서 좀 더 현명하게 일하는 방법. 소프트웨어 개발과 운영의 통합

애플리케이션을 지속적으로 전달(Continuous Delivery)하기 위해서 데브옵스와 애자일 방법론을 함께 다룸 => 긴 시간 소요되는 배포 프로세스를 더 작고, 자주 배포하는 방식을 통해 시간 단축

즉, 효과적이고 효율적으로 하기 위해 자동화를 최대한 활용해야 함

+애자일 방법론

What is and why do we use DevOps

Day2

애플리케이션 = 개발 + 운영

개발: 소프트웨어 개발자들이 애플리케이션을 작성하고 테스트하는 파트
운영: 애플리케이션을 서버에 배포하고 유지하는 파트

데브옵스 엔지니어의 요구사항

1) 개발
직접적인 애플리케이션 프로그래밍이 아닌, 개발 업무, 시스템, 도구, 전반적인 과정에 대한 개념 이해가 요구됨

2) 운영
서버를 설정하고 배포하도록 환경을 준비해야 하기 때문에 구성한 네트워크 및 환경이 다른 서비스들과 통신할 수 있도록 일정 수준의 네트워킹 및 구성에 대한 지식이 요구됨.
ex. DNS, DHCP, Load Balancing
서버가 아닌 컨테이너로 실행되도록 개발해야할 수도 있으므로 컨테이너화에 대한 이해 필요. ex. 가상화, IaaS(클라우드 인프라 서비스)

데브옵스 엔지니어의 핵심
(개발) 애플리케이션을 위한 기능 추가 + (운영) 실제 애플리케이션이 실행되고 필요 서비스와 통신하도록 구성 및 관리되고 있는 환경 => 새 애플리케이션 버전을 어떻게 출시하는가?

Day3

데브옵스 수명 주기 -애플리케이션 중심

1) Development(개발)
고객 또는 최종 사용자와 요구 사항을 논의하고 애플리케이션에 대한 계획이나 요구 사항 마련
요구 사항을 바탕으로 새로운 애플리케이션 생성하는 단계

데브옵스 엔지니어 관점
애플리케이션 코딩은 개발자의 역할이고 최상의 인프라 결정을 위해 일부 코드를 읽을 수 있는 것도 나쁘지 않음

필요 개념
Git

애플리케이션은 어떤 언어로든 작성할 수 있으므로 버전 관리 시스템을 사용하여 유지 관리해야함
협업하기 위한 코드 저장소 필요. ex. GitHub, GitLab

Testing (테스팅)
우리가 사용할 수 있는 모든 다양한 환경, 특히 선택한 프로그래밍 언어에서 코드를 테스트하고 있는지 확인하는 단계

데브옵스 엔지니어 관점

QA(품질 보증)가 버그를 테스트할 때(테스트 환경을 시뮬레이션하는 시점)에 컨테이너 사용이 많아져 전반적으로 물리적 또는 클라우드 인프라의 비용 오버헤드를 개선할 수 있음
지속적 통합의 일부로 자동화될 가능성이 높음
테스트를 자동화하는 것은 수동으로 수행하는 것과 비교하여 그 자체로 의미가 있으며, 스택 내에서 다른 작업에 집중하여 워터폴 방법론을 사용하는 대부분의 기존 소프트웨어 릴리스에서 지체되는 경향이 있는 버그 및 소프트웨어 테스트 대신 더 빠르게 움직이고 더 많은 기능을 개발할 수 있음

Integration (통합)

중요한 것은 통합이 데브옵스 라이프사이클의 중간에 존재한다는 것
개발자가 소스 코드에 변경 사항을 커밋할 때마다 애플리케이션은 자동화된 테스트 단계를 거치게 되며, 이를 통해 문제나 버그를 조기에 발견할 수 있음

Deployment (배포)
최종 사용자가 사용할 수 있도록 코드를 프로덕션 서버에 배포하는 단계

데브옵스 엔지니어 관점

애플리케이션마다 필요한 하드웨어나 구성이 다르기 때문에 Application Configuration Management(애플리케이션 구성 관리)와 Infrastructure as Code(코드형 인프라) 가 데브옵스 라이프사이클에서 중요한 역할을 할 수 있음

애플리케이션이 Containerised(컨테이너화)되어 있지만 가상 머신에서 실행할 수 있는 경우도 있을 수 있으며, 이러한 컨테이너를 오케스트레이션하고 최종 사용자가 원하는 상태를 사용할 수 있도록 하는 Kubernetes와 같은 플랫폼으로 이어짐

Monitoring (관제)

애플리케이션 성능을 지속적으로 모니터링하여 개발자가 향후 릴리스에서 애플리케이션을 개선하여 최종 사용자에게 더 나은 서비스를 제공할 수 있도록 하는 단계
구현된 기능에 대한 피드백을 수집하고 최종 사용자가 어떻게 개선하기를 원하는지에 대한 피드백을 수집할 것
안정성이 핵심 요소이며 지속적으로 모니터링해야 하는 다른 observability, security and data management(관찰 가능성, 보안 및 데이터 관리) 영역으로 이어짐

데브옵스 엔지니어 관점

일부 의견은 지속적인 프로세스의 일부로 FinOps 팀도 참여해야 한다고 언급 => 앱과 데이터는 어딘가에서 실행되고 저장되므로 리소스 관점에서 상황이 변경될 경우 비용이 클라우드 요금에 큰 재정적 고통을 주지 않도록 지속적으로 모니터링해야함

DevOps 엔지니어

어떤 직책이든 위에서 설명한 데브옵스 프로세스와 문화를 채택해야하므로 데브옵스 엔지니어라는 직책이 목표가 되어서는 안 됨
데브옵스는 클라우드 네이티브 엔지니어/아키텍트, 가상화 관리자, 클라우드 아키텍트/엔지니어, 인프라 관리자와 같은 다양한 직책에서 사용되어야 함

워터폴 방법론
"애플리케이션을 만들지 않고 소프트웨어 공급 업체에서 기성품을 구입할 것"의 의미

Day4

DevOps & Agile (데브옵스&애자일)

1) Agile Development
제품의 큰 결과물을 한 번에 출시하기보다 작은 결과물을 더 빠르게 제공하는 데 중점을 두는 접근 방식으로 소프트웨어는 반복적으로 개발됨
애자일의 최종 목표는 최종 사용자에게 최적의 경험을 제공하는 것

2) DevOps
일반적으로 소프트웨어 개발자와 운영 전문가 간의 협력을 기반으로 하는 배포 관행
데브옵스의 주요 이점은 간소화된 개발 프로세스를 제공하고 잘못된 커뮤니케이션을 최소화하는 것

애자일과 데브옵스의 차이점
선입견

애자일은 짧은 반복을 원하는데, 이는 데브옵스가 제공하는 자동화를 통해서만 가능
애자일은 고객이 특정 버전을 사용해보고 신속하게 피드백을 주기를 원하는데, 이는 데브옵스가 새로운 환경을 쉽게 만들 수 있을 때만 가능

Different participants (서로 다른 참여자)
애자일은 최종 사용자와 개발자 간의 커뮤니케이션을 최적화하는 데 중점을 둠
데브옵스는 개발자와 운영, 팀원을 대상으로 함
따라서 애자일은 고객을 향한 외부 지향적인 반면 데브옵스는 일련의 내부 관행
팀
애자일은 일반적으로 소프트웨어 개발자와 프로젝트 관리자에게 적용됨
데브옵스 엔지니어의 역량은 제품 주기의 모든 단계에 관여하고 애자일 팀의 일원이므로 개발, QA(품질 보증) 및 운영이 교차하는 지점에 있음
적용된 프레임워크
애자일에는 유연성과 투명성을 달성하기 위한 다양한 관리 프레임워크 존재: Scrum > Kanban > Lean > Extreme > Crystal > Dynamic > Feature-Driven
데브옵스는 협업을 통한 개발 접근 방식에 중점을 두지만 구체적인 방법론을 제공하지는 않음. 하지만 코드형 인프라, 코드형 아키텍처, 모니터링, 자가 치유, 엔드투엔드 테스트 자동화와 같은 관행 장려 (이것은 그 자체로 프레임워크가 아닌 관행일뿐)
피드백
애자일에서는 피드백의 주요 출처가 최종 사용자인 반면, 데브옵스에서는 이해관계자와 팀 자체의 피드백이 더 높은 우선순위를 가짐
대상영역
애자일은 배포 및 유지 관리보다 소프트웨어 개발에 더 중점을 둠
데브옵스는 소프트웨어 개발에도 중점을 두지만 그 가치와 도구는 모니터링, 고가용성, 보안 및 데이터 보호와 같은 배포 및 릴리스 후 단계에도 적용됨
문서
애자일은 문서화 및 모니터링보다 유연성과 당면한 작업에 우선순위를 둠
데브옵스는 프로젝트 문서를 필수 프로젝트 구성 요소 중 하나로 간주
위험요소
애자일 리스크는 방법론의 유연성에서 비롯되며 애자일 프로젝트는 우선순위와 요구사항이 계속 변하기 때문에 예측하거나 평가하기 어려움
데브옵스 위험은 용어에 대한 오해와 적절한 도구의 부재에서 비롯됨
사용 툴
애자일은 경영진의 커뮤니케이션 협업, 메트릭 및 피드백 처리에 중점을 둠. ex. JIRA, Trello, Slack, Zoom, SurveyMonkey
데브옵스는 팀 커뮤니케이션, 소프트웨어 개발, 배포 및 통합 중점. ex. Jenkins, GitHub Actions, BitBucket

3) 애자일 + 데브옵스 이점

유연한 관리와 강력한 기술
애자일 관행은 데브옵스 팀이 우선순위를 보다 효율적으로 소통하는 데 도움이 됨
데브옵스 관행을 위해 지불해야 하는 자동화 비용은 신속하고 자주 배포해야하는 애자일 요구 사항에 따라 정당화됨
애자일 방식을 채택하는 팀은 협업을 개선하고 팀의 동기를 높이며 직원 이직률을 낮출 수 있음
결과적으로 제품 품질 향상

Day5

데브옵스 환경에서의 애플리케이션의 시작부터 끝까지 개별 단계: 계획 > 코드 작성 > 빌드 > 테스트 > 릴리즈 > 배포 > 운영 > 모니터링

1) 계획
개발 팀이 다음 스프린트에서 출시할 기능과 버그 수정을 결정하는 단계
데브옵스 엔지니어가 참여해 앞으로 어떤 일이 발생할지 파악하고 개발팀이 더 나은 방향으로 나아갈 수 있도록 안내

2) 코드 작성
인프라에 대한 이해도를 높여서 어떤 서비스를 사용할 수 있는지, 그 서비스와 어떻게 상호작용할 수 있는지를 더 잘 이해할 수 있도록 도움

3) 빌드

자동화 프로세스의 첫 번째 단계로, (코드를 가져와서) 사용하는 언어에 따라 변환하거나 컴파일하거나 해당 코드에서 도커 이미지를 생성할 수 있기 때문에 CI 파이프라인을 사용하여 이러한 프로세스를 자동화함
이로써 코드를 변경하거나 새 코드를 추가할 때마다 자동화된 프로세스를 통해 더욱 효율적이고 일관성 있는 작업을 수행할 수 있게 됨

테스트
빌드가 완료되면 프로덕션에 문제가 발생하지 않도록 테스트 진행. 최대한 이전에 작동하던 것이 깨지지 않도록 보장하기 위해 노력해야함
릴리즈
애플리케이션 유형에 따라 릴리즈 프로세스가 수행되는데 작업 중인 애플리케이션에 따라 생략될 수도 있음. 일반적으로 GitHub 리포지토리나 git 리포지토리에서 가져온 코드나 빌드된 도커 이미지를 프로덕션 서버에 배포하기 위해 레지스토리나 리포지토리에 저장
배포
모든 개발 과정의 최종 단계로, 프로덕션 환경에 코드를 적용하는 과정
운영
한 번 배포가 완료되면 해당 제품이 운영되기 시작. 애플리케이션 사용 시 발생하는 문제를 파악하고 이에 대한 대처 방안을 마련하는 것이 포함됨
ex. 사이트가 느리게 실행되는 문제 발생
=> 피크 기간 동안은 서버 수를 늘리고, 사용량이 적은 기간에는 서버 수를 줄이는 자동 확장 기능 구축. 자동화하는 것이 좋으며 자동화 프로세스에서는 배포가 발생했음을 알 수 있도록 알림을 포함하는 것이 좋음
모니터링
메모리 사용률, CPU 사용률, 디스크 공간, API 엔드포인트, 응답 시간, 엔드포인트가 얼마나 빨리 응답하는지 등을 모니터링할 수 있으며, 특히 로그를 통해 개발자는 프로덕션 시스템을 액세스하지 않고도 무슨 일이 일어나고 있는지 확인할 수 있음
다듬기&반복

2) Continuous Cycle
데브옵스 라이프사이클

Continuous
모든 코드와 클라우드 인프라 또는 모든 환경을 완전히 자동화하는 것이 궁극적인 목표이며, 지속적 통합/지속적 배포(CI/CD)라 설명
Continuous Delivery
Continuous Delivery = 계획 > 코드 작성 > 빌드 > 테스트
Continuous Integration
Continuous Integration = 계획 > 코드 > 빌드 > 테스트 > 릴리즈

성공적인 CI 릴리즈 후 CD 단계로 이동

Continuous Deployment
Continuous Deployment = 배포 > 운영 > 모니터링

Day6

데브옵스 실제 사례
=> 데브옵스를 올바르게 수행하면 비즈니스의 소프트웨어 개발 속도와 품질을 개선하는 데 큰 도움이 됨

1) Amazon
물리적 서버 공간인 AWS에 지속적인 배포 프로세스를 채택하여 개발자가 원할 때 필요한 서버에 코드를 배포할 수 있게 됨

2) Netflix
배포 가능한 웹 이미지로 코드를 자동으로 빌드할 수 있음. 이미지가 업데이트되면 맞춤형으로 구축된 웹 기반 플랫폼을 사용하여 넷플릭스 인프라에 통합됨
이미지 배포에 실패하면 롤백되어 이전 버전으로 트래픽이 다시 라우팅되도록 지속적인 모니터링이 이루어짐

3) Etsy
개발자가 코드를 배포할 수 있도록 해뒀을 가능성 존재

데브옵스 요약

데브옵스는 전체 애플리케이션 개발 라이프사이클인 개발, 테스트, 배포, 운영을 단일 팀이 관리할 수 있도록 하는 개발과 운영의 조합
데브옵스의 주요 초점과 목표는 개발 라이프사이클을 단축하면서도 비즈니스 목표와 긴밀하게 연계하여 기능 및 수정 사항을 자주 제공하는 것
데브옵스는 소프트웨어를 안정적이고 신속하게 배포하고 개발할 수 있는 소프트웨어 개발 접근 방식으로, 이를 지속적인 개발, 테스트, 배포, 모니터링이라고도 부름

Understand Networking

Day21

넷데브옵스(= 네트워크 데브옵스)

프로비저닝, 구성, 테스트, 버전 제어 및 배포와 관련된 자동화 원칙을 사용하는 것이 좋음
자동화는 전반적으로 배포 속도, 네트워킹 인프라의 안정성, 지속적인 개선을 가능하게 할 뿐만 아니라 테스트가 완료되면 여러 환경에서 프로세스를 공유할 수 있음

네트워킹 기본 사항

1) 네트워크 장치
호스트
트래픽을 보내거나 받는 모든 장치

IP 주소
각 호스트의 신원

네트워크
호스트 간에 트래픽을 전송하는 역할로 네트워크가 없을 경우 데이터를 수동으로 이동해야함
비슷한 연결이 필요한 호스트의 논리적 그룹으로 네트워크의 호스트는 동일한 IP 주소 공간 공유

스위치
네트워크 내에서 통신을 촉진하는 역할. 호스트 간에 데이터 패킷을 전달

라우터
네트워크 간의 통신을 용이하게 함
네트워크를 함께 연결하거나 최소한 허용되는 경우 서로에 대한 액세스 권한을 부여할 수 있게 해줌
트래픽 제어 지점(보안, 필터링, 리디렉션)을 제공할 수 있으며 최근에는 이 중 일부 기능을 제공하는 스위치가 증가하는 추세

라우터는 자신이 연결된 네트워크를 학습(라우트)하며 라우팅 테이블은 라우터가 알고 있는 모든 네트워크
라우터는 연결된 네트워크의 IP 주소를 가지고 있으며 이 IP는 게이트웨이라고도 하는 각 호스트가 로컬 네트워크에서 나가는 통로이기도 함
네트워크에서 계층 구조를 생성

스위치 VS 라우터

1) 라우팅은 네트워크 간에 데이터를 이동하는 프로세스
=> 라우터는 라우팅을 주요 목적으로 하는 장치
2) 스위칭은 네트워크 내에서 데이터를 이동하는 프로세스
=> 스위치는 스위칭을 주요 목적으로 하는 장치

Day22

네트워킹의 전반적인 목적은 두 호스트가 데이터를 공유할 수 있도록 하는 것
네트워킹을 사용하면 데이터를 자동화할 수 있으며 그러기 위해서는 호스트가 일련의 규칙을 따라야 함

OSI 모델- 7개의 Layers
OSI는 네트워킹 시스템의 기능을 설명하는데 사용되는 프레임워크로, OSI 모델에서 컴퓨터 시스템 간의 통신은 7가지 추상화 계층으로 나뉨

1) Physical (물리적)

OSI 모델에서의 Layer1
물리적 케이블 등 수단을 통해 한 호스트에서 다른 호스트로 데이터를 전송할 수 있다는 전제하에 이 Layer에서도 wifi를 고려할 수 있음
한 호스트에서 다른 호스트로 데이터를 전송하기 위해 허브와 중계기 주변에서 더 많은 레거시 하드웨어를 볼 수 있음

Data link (데이터 링크)

OSI 모델에서의 Layer2
데이터가 프레임으로 패키지화되는 노드 간 전송을 가능하게 함
물리 계층에서 발생했을 수도 있는 오류를 수정하는 수준
해당 단계에서 MAC 주소가 도입되거나 처음 등장
스위치와 관련

network (네트워크)

OSI 모델에서의 Layer3
End to End 전송을 목표로 하며 IP 주소 존재. IP가 있는 모든 것은 Layer3로 간주
라우터와 호스트는 Layer3에 존재하며 라우터는 여러 네트워크 간에 라우팅하는 기능

왜 Layer2와 3 모두 주소 체계(MAC 주소와 IP 주소)가 필요한가?

한 호스트에서 다른 호스트로 데이터를 전송하는 것을 생각하면, 각 호스트에는 Layer3 IP 주소가 있고 그 사이에는 여러 개의 스위치와 라우터가 존재. 각 장치에는 Layer2의 MAC 주소가 존재
=> Layer2 MAC 주소는 호스트에서 스위치/라우터로만 이동하며 hop에 중점을 두고, Layer3 IP 주소는 데이터 패킷이 최종 호스트에 도달할 때까지 해당 패킷을 유지
즉, IP 주소(Layer3) = End to End 전송, MAC 주소(Layer2) = Hop to Hop 전송
이때 Layer3와 Layer2 주소를 연결하는 ARP(주소 확인 프로토콜)라는 네트워크 프로토콜 존재

transport (전송)

OSI 모델에서의 Layer4
서비스 간 전송으로 데이터 스트림을 구분하기 위해 존재
Layer2의 MAC, Layer3의 IP주소와 같이 Layer4에는 port 존재

session + presentation + application

OSI 모델과 TCP/IP 모델 비교

네트워킹 스택을 사용하여 호스트 간의 통신 과정

데이터 전송
[Layer5] 호스트에는 다른 호스트로 전송할 데이터를 생성하는 application 존재
소스 호스트는 캡슐화 프로세스라는 과정을 거치며 해당 데이터는 먼저 Layer4로 전송
[Layer4] 받은 데이터에 헤더를 추가하여 서비스 간 전송이 용이하도록 함. 이 헤더는 TCP 또는 UDP를 사용하는 포트가 되며 소스 포트와 대상 포트를 포함. 이를 세그먼트(데이터 및 포트)라고도 하며 이 세그먼트는 OSI 스택을 통해 Layer3로 전달
[Layer3] 받은 데이터(세그먼트)에 또 다른 헤더 추가. 이 헤더는 End to End 전송이 가능하도록 하며 소스 IP 주소와 대상 IP 주소를 포함. 헤더와 데이터를 합쳐 패킷이라 부르며 이를 Layer2로 전달
[Layer2] 받은 데이터(패킷)에 또 다른 헤더를 추가하여 Hop to Hop 전송이 가능하도록 함. 헤더에는 소스 MAC 주소와 대상 MAC 주소가 포함되며, 헤더와 데이터(패킷)를 합쳐 프레임이라 부름
[Layer1] 프레임은 1과 0으로 변환되어 Layer1 물리적 케이블 또는 Wi-Fi를 통해 전송
데이터 수신
데이터 전송의 역방향으로 이루어짐

TCP IP Model

Day23

네트워크 프로토콜
: 인터넷 표준을 구성하는 일련의 규칙과 메세지

1) ARP (주소 확인 프로토콜)
Layer2 네트워크에서 IP 주소를 고정된 물리적 컴퓨터 주소(MAC 주소)에 연결

2) FTP (파일 전송 프로토콜)
소스에서 대상으로 파일 전송. 익명 액세스를 사용하도록 구성한 경우 사용 가능
더 나은 보안을 위해 클라이언트에서 FTP 서버로 SSL/TLS 연결을 제공하는 FTPS를 더 많이 사용
애플리케이션 계층에서 해당 프로토콜 사용

3) SMTP (단순 메일 전송 프로토콜)
전자 메일 전송에 사용되는 메일 서버는 SMTP 프로토콜을 사용하여 메세지 전송 및 수신

4) HTTP (하이퍼 텍스트 전송 프로토콜)
HTTP는 인터넷과 콘텐츠 탐색의 기초로, 웹사이트에 쉽게 액세스할 수 있도록 해줌
HTTP는 여전히 많이 사용되고 있지만, 대부분의 사이트는 HTTPS가 더 많이 사용되고 있거나 사용되어야 함

5) SSL(보안 소켓 계층), TLS(전송 계층 보안)
SSL의 뒤를 이어 등장한 TLS는 네트워크를 통해 안전한 통신을 제공하는 암호화 프로토콜
메일, 인스터트 메시징 및 기타 애플리케이션에서 찾을 수 있지만 가장 일반적으로 HTTPS를 보호하는데 사용

6) HTTPS (SSL/TLS로 보호되는 HTTP)
네트워크를 통한 보안 통신에 사용되는 HTTP의 확장 프로토콜
TLS로 암호화되며 호스트 간에 데이터가 교환되는 동안 인증, 개인 정보 보호 및 무결성을 제공하는 데 중점을 둠

7) DNS (도메인 이름 시스템)
DNS는 인간 친화적인 도메인 이름을 매핑하는데 사용 : IP 주소와 도메인 이름 convert
모든 호스트에서 인터넷 연결이 필요한 경우 해당 도메인 이름을 확인할 수 있도록 DNS 존재해야함
네트워킹과 관련된 모든 오류의 일반적인 원인은 대부분 DNS이며 학습하는데 오랜 시간이 소요됨

8) DHCP (동적 호스트 구성 프로토콜)

인터넷에서 액세스하거나 서로 간에 파일을 전송하는 등 호스트가 동작하는 작업을 하기 위해 호스트에 필요한 사항
IP 주소: 호스트가 위치한 네트워크에서 호스트의 고유 주소. 집 번호st
서브넷 마스크: 우편번호st
기본 게이트웨이: 네트워크에서 Layer3 연결을 제공하는 라우터의 IP. 우리 동네를 빠져나갈 수 있는 하나의 도로st
DNS: 복잡한 공인 IP 주소를 기억하기 쉬운 도메인 이름으로 변환

각 호스트마다 위의 4가지가 필요한데 호스트가 많아질 수록 4가지를 개별적으로 결정하는 데 오랜 시간이 소요됨 => DHCP 사용해 네트워크의 범위를 결정하면 이 프로토콜이 네트워크에서 사용 가능한 모든 호스트에 배포됨

ex. 호스트를 커피숍 와이파이에 연결하면 인터넷에 접속할 수 있고, 메시지와 메일이 핑을 받기 시작하며, 웹 페이지와 소셜 미디어를 탐색할 수 있게 됨 => 커피숍 와이파이를 연결했을 때 컴퓨터는 전용 DHCP 서버 또는 DHCP를 처리하는 라우터에서 DHCP 주소 선택

서브넷
IP 네트워크의 논리적 세분화이 서브넷이고 라우터는 서브넷 간의 통신을 관리
대규모 네트워크를 더 효율적으로 실행할 수 있는 더 작고 관리하기 쉬운 네트워크로 나눈 것을 의미하며 서브넷의 크기는 조직이 결정
대규모 네트워크를 서브넷으로 세분화하면 IP 주소 재할당을 가능하게 하고 네트워크 혼잡, 간소화, 네트워크 통신 및 효율성을 완화하며, 네트워크 보안도 향상시킬 수 있음

Day24

네트워크 자동화의 주요 동인
=> 민첩성 달성, 비용 절감, 오류 제거, 규정 준수 보장, 중앙 집중식 관리

But, 자동화 도입 프로세스는 조직에 따라 다름

네트워킹 자동화에 대한 접근 방식

1) 자동화할 일반적인 이슈와 문제 파악

현재 수동으로 처리하고 있는 모든 변경 요청과 workflow 목록 작성
가장 일반적이고 시간이 오래 걸리며 오류가 발생하기 쉬운 활동 파악
비즈니스 중심 접근 방식을 취하여 요청의 우선순위 결정
자동화해야 하는 작업과 자동화하지 않아야 하는 작업 구분

서로 다른 네트워크 기능이 어떻게 작동하고 상호 작용하는지 분석

인프라/네트워크 팀은 애플리케이션을 배포하기 위해 여러 계층에서 변경 티켓을 받음
네트워크 서비스를 기반으로 여러 영역으로 나누고 서로 어떻게 상호작용하는지 이해 : 애플리케이션 최적화, ADC(애플리케이션 전송 컨트롤러), 방화벽, DDI(DNS, DHCP, IPAM), 라우팅 등
다양한 종속성을 파악하여 비즈니스 및 문화적 차이를 해결하고 팀 간 협업 유도

재사용 가능한 정책, 재사용 가능한 서비스 작업, 프로세스 및 입출력을 정의하고 단순화

다양한 서비스, 프로세스 및 입출력을 위한 오퍼링 정의
배포 프로세스를 간소화하면 신규 워크로드와 기존 워크로드 모두의 시장 출시 시간 단축 가능
표준 프로세스가 마련되면 멀티스레드 접근 방식과 제공을 위해 개별 요청에 따라 프로세스를 순서화 및 조정 가능

정책을 비즈니스별 활동과 결합

서비스 작업이 상호 운용 가능한지 확인
증분 서비스 작업을 연결하여 비즈니스 서비스를 만들 수 있도록 정렬
필요에 따라 서비스 작업을 다시 연결할 수 있는 유연성 제공
셀프 서비스 기능을 배포하고 운영 효율성을 개선할 수 있는 기반 마련
감독 및 규정 준수에 지속적으로 기여할 수 있도록 다양한 기술 스킬셋 허용

가용성과 서비스를 유지하면서 정책과 프로세스를 반복하여 추가하고 개선

기존 작업을 자동화하여 작게 시작
자동화 프로세스에 익숙해져서 자동화를 통해 이점을 얻을 수 있는 다른 영역 식별 가능
자동화 이니셔티브를 반복하여 필요한 가용성을 유지하면서 민첩성을 점진적으로 추가

네트워크 서비스 오케스트레이션

애플리케이션을 신속하게 제공하려면 배포 프로세스의 자동화 필요
민첩한 서비스 환경을 구축하려면 기술 전반에 걸쳐 관리해야할 다양한 요소 필요
자동화와 배포 순서를 제어할 수 있는 End to End 오케스트레이션 준비

네트워크 자동화 도구
대부분의 경우 네트워크 자동화에 사용하는 도구는 다른 자동화 영역에 사용

운영체제: LinuxOS
IDE(통합 개발 환경): Visual Studio Code
구성 관리: Ansible 선호
CI/CD: Jenkins
언어: Python
API 분석: Postman

Day25

네트워크 자동화를 위한 Python의 이점

가독성 및 사용 편의성
많은 라이브러리
강력하고 효율적

네트워크 환경 자동화

소프트웨어 정의 네트워크
높은 수준의 오케스트레이션
정책 기반 관리

네트워크 구성 자동화 실습 환경 설정
Eve-ng , VMware Workstation
=> 네트워크 시뮬레이션( Eve-ng)을 사용해 랩 구축
1) Eve-ng OVF 형식 다운로드
OVF를 사용하지만, ISO 형식을 사용할 경우 하이퍼바이저 없이 베어메탈 서버에서 빌드 가능
2) VMware Workstation 환경 설정
ENE-NG OVF 이미지 압축풀기 > 이미지 가져와 이름 지정하고 시스템 어딘가에 가상 머신(프로세서 4개, 할당된 메모리 8GB) 저장
Intel VT-x/EPT 또는 AMD-V/RVI 가상화 확인란 활성화 확인
3) 전원 켜기 및 액세스
환경 내부 중첩될 경우 아래 코드 실행

bcdedit /set hypervisorlaunchtype off
bcdedit /set hypervisorlaunchtype auto
4) VMware Workstation 전원 확인
username = root
password = eve
5) Eve-ng 환경 설정
호스트 이름 변경 > DNS 도메인 이름 정의 > IP 주소 영구적 or 유지 설정 > 워크스테이션에서 연결할 수 있는 네트워크 고정 IP 주소 제공
6) 로그인
username, password 입력 > 콘솔과 네이티브에 대해 HTML5 선택

Day26

Eve-ng 클라이언트 설치
1) Eve-ng 클라이언트 설치
2) 네트워크 Images 가져오기
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

1) Eve-ng 노드 추가
2) 네트워크 생성
3) 위 표와 같은 라우터와 스위치 추가
4) 노드 연결
5) 실습 시작

각 장치에 콘솔 연결 가능
아직 아무 구성도 하지 않은 상태

Day27

클라이언트 vs telnet에서 장치에 연결하기 위해 SSH 터널 사용
클라이언트와 기기 사이에 생성된 SSH 터널은 암호화
1. 가상 에뮬레이트 환경에 액세스
1) 스위치와 상호작용하는 법 (아래 중 하나 선택)
Eve-ng 네트워크 내부에 워크스테이션 존재
python이 설치된 Linux 박스 배포
워크스테이션에서 액세스할 수 있는 클라우드 정의
2) 워크스테이션에서 액세스할 수 있는 클라우드 사용
네트워크 선택 > Management(Cloud0) 선택 => 홈 네트워크 연결
새 네트워크에서 각 장치 연결
장치 로그온 후 아래 명령 실행 => 연결 확인

enable
config t
int gi0/0
IP add DHCP
no sh
exit
exit
sh ip int br

3) 홈 네트워크의 DHCP 주소 제공
=> 완료되면 워크스테이션을 사용하여 홈 네트워크의 장치에 연결 가능

네트워크 장치에 SSH
PuTTY를 통해 라우터 장치에 대한 SSH 연결 확인
파이썬을 사용하여 장치에서 정보 수집
1) 각 장치에 연결해 간단한 명령 실행
2) 모든 장치에서 각 포트의 구성 확인 가능
파이썬을 사용하여 디바이스 구성 가능
파이썬을 사용하여 디바이스 구성 백업 가능
Paramiko
SSH를 위해 널리 사용되는 Python 모듈로, 파이썬 셸에 들어가서 Paramiko 모듈을 가져와 설치가 완료되었는지 확인 가능
Netmiko
네트워크 디바이스만을 대상으로 접속하기 위한 라이브러리