Slurm DevOps: Git에서 SRE까지 모든 단계를 포함

4월 6~XNUMX일 상트페테르부르크의 Selectel 컨퍼런스 홀에서 XNUMX일간 슬럼 데브옵스.

우리는 도구 매뉴얼과 같은 DevOps의 이론적 작업을 누구나 스스로 읽을 수 있다는 생각을 바탕으로 프로그램을 구축했습니다. 오직 경험과 실천만이 흥미롭습니다. 어떻게 해야 하는지, 무엇을 하면 안 되는지에 대한 설명, 그리고 어떻게 해야 하는지에 대한 이야기입니다.

모든 회사, 모든 관리자 또는 개발자는 고유한 DevOps 수준을 가지고 있습니다. 어떤 사람들은 Git을 잘못 사용하고 다른 사람들은 SRE를 구현합니다. 이 과정은 모든 사람이 지금 여기에서 실행할 수 있는 관련성을 찾을 수 있도록 구성되었습니다.

Git으로 시작한 다음 애플리케이션 개발, 코드와 인프라 간의 상호 작용, CI/CD 구축, 코드형 인프라(IaC) 설명, 결과 솔루션 테스트, 모니터링 설정, 로그 수집 및 연구를 거쳐 마지막으로 SRE로: 신뢰성을 측정 가능하고 관리 가능한 스토리로 전환합니다.

힘내

요즘 Git을 사용하지 않는 사람은 어제 처음으로 노트북을 구입한 사람뿐이다. 이것은 사소하고 어디에나 있는 도구이지만 마스터에 강제로 푸시하는 것부터 Ctrl-C, Ctrl-V를 통해 Git에서 서버로 파일을 복사하는 것까지 오용되는 경우가 많습니다.

사우스브리지에서 하는 것처럼, 하지 말아야 할 것과 어떻게 해야 하는지 알려드립니다.
우리는 기타의 기본, 팀워크를 연습하고 있습니다.

주제 #1: Git 기초

• 기본 명령 git init, commit, add, diff, log, status, pull, push
• Git 흐름, 분기 및 태그, 병합 전략
• 여러 원격 저장소로 작업하기

주제 #2: Git을 사용한 팀워크

• GitHub 흐름
• 포크, 원격, 풀 요청
• 팀과 관련된 Gitflow 및 기타 흐름에 대한 충돌, 릴리스, 다시 한 번

관리자와 개발자가 업무에 있어 모든 실무를 즉시 구현할 수 있도록 자료가 구성되어 있습니다.

DevOps 관점에서 Git을 적절하게 사용하면 개발 및 관리 프로세스를 간소화 및 자동화하고 반복되는 여러 문제를 제거하며 생산성을 높일 수 있습니다.

DevOps 개발자

우리는 개발자의 눈으로 DevOps를 봅니다. 로컬 환경을 시작하고, 애플리케이션을 작성하고, 모니터링 및 로깅을 설정하고, 로컬에서 테스트하고, 변수/비밀 및 서비스 검색 저장소를 구성하고, 오픈 트레이싱을 관찰합니다.

주제 #3: 개발 관점에서 애플리케이션 작업

• 로컬 환경 설정: 실제 권장 사항
• Python으로 마이크로서비스 작성(테스트 포함)
• 개발 시 docker-compose 사용

주제 #4: 코드와 인프라 간의 상호 작용

• 구성 작업 연습

결과적으로 개발자는 코드가 로그를 보내는 방법, 테스트하는 방법, 향후 디버깅하는 방법을 확인할 수 있습니다. 관리자는 코드에 어떤 오류가 있는지, 개발자를 위한 테스트를 구성하는 방법, 프로젝트 자체를 테스트하는 방법 등 개발자의 요구 사항을 이해합니다.

이 단계에서는 DevOps의 주요 임무가 해결됩니다. Dev와 Ops 간의 상호 이해와 공동 작업이 구축됩니다. 이는 작업 공유에서 책임 있는 협업으로 전환하는 핵심 단계입니다.

결과적으로 작업 속도와 품질이 향상됩니다.

CI / CD

현대 자동화에는 CI/CD가 포함됩니다. makefile, githook, 스크립트 등 수동 자동화부터 살펴보겠습니다. 이러한 도구가 여전히 관련성이 있는 경우와 사용해서는 안 되는 경우를 살펴보겠습니다.

그럼 Gitlab을 예로 들어 현대 CI의 모범 사례를 살펴보겠습니다.

주제 #5: 자동화에 대한 CI/CD 소개

• 자동화 소개
• 도구(bash, make, gradle)
• git-hooks를 사용하여 프로세스 자동화
• 공장 조립 라인 및 IT 분야의 응용
• "일반" 파이프라인 구축의 예
• CI/CD용 최신 소프트웨어: Drone CI, BitBucket Pipelines, Travis 등

주제 #6: CI/CD: Gitlab 작업

• Gitlab CI - 일반
• Gitlab Runner, 유형 및 애플리케이션
• Gitlab CI, 구성 기능, 모범 사례
• Gitlab CI 단계
• Gitlab CI 변수
• 빌드, 테스트, 배포
• 실행 제어 및 제한: 경우에만
• 아티팩트 작업
• .gitlab-ci.yml 내의 템플릿, 파이프라인의 다른 부분에서 작업을 재사용
• 포함 - 섹션
• gitlab-ci.yml의 중앙 집중식 관리(파일 XNUMX개 및 다른 저장소로 자동 푸시)

관리자와 개발자 간의 협업이 새로운 수준에 도달했습니다. 관리자는 CI 템플릿을 작성하고 개발자는 이를 편집하여 관리자와 독립적으로 CI를 구축합니다.

개발자의 관리자에 대한 의존도가 줄어들고, 수작업량이 줄어들며, “make 파일을 다룰 줄 아는 유일한 사람”이라는 문제도 사라진다. 출시는 안정적이고 신속하게 이루어집니다.

IAC

Terraform을 예로 들어 코드로서의 인프라 주제에 대해서는 Selectel 클라우드 관리자 Alexey Stepanenko가 논의합니다. 그는 서버를 자동으로 신속하게 배포하고 확장하는 방법, 이미지를 자동으로 패키징하는 방법, 구성 템플릿을 사용하여 즉시 구성된 시스템을 얻는 방법을 보여줍니다.

수천 개의 IaC 솔루션을 만든 사람이 이를 올바르게 수행하는 방법과 하지 말아야 할 것을 알려줄 것입니다.

Selectel 클라우드 솔루션은 최소한의 수정만으로 Google 및 Amazon 클라우드에 적합합니다.

Southbridge 직원 Nikolai Mesropyan은 Ansible을 예로 들어 다운타임 없이 작동하는 애플리케이션을 배포하고 성능을 확인하는 방법을 보여줍니다.

인프라를 수동으로 편집하는 경우(서버 설정, 필요에 따라 라이브러리 및 패키지 설치) 환경 복사본을 생성하려고 할 때 모든 작업을 기억하고 재현해야 합니다. 이 작업은 3~5일이 소요됩니다. 코드형 인프라를 사용하면 몇 분 안에 배포할 수 있는 환경에 대한 최신 설명을 얻을 수 있습니다.

Nikolay는 플레이북을 작성하는 방법, 어떤 실수가 발생하는지, 플레이북이 때때로 예상대로 느리게 작동하거나 작동하지 않는 이유를 알려줄 것입니다. 이는 Southbridge에서 수년간 IaC를 사용해 본 경험입니다.

주제 #7: 코드형 인프라

• IaC: 인프라를 코드로 접근
• 인프라 제공자로서의 클라우드 제공자
• 시스템 초기화 도구, 이미지 구축(패커)
• Terraform을 예시로 사용하는 IaC
• 구성 저장, 협업, 애플리케이션 자동화
• Ansible 플레이북 생성 연습
• 멱등성, 선언성
• Ansible을 예로 사용하는 IaC
• 코드형 데이터베이스/PostgreSQL 내결함성

인프라는 선언적이고 멱등성이 있게 됩니다.
관리자는 복잡한 인프라를 관리하는 방법을 배웁니다. 새로운 환경을 빠르게 생성하고, 모든 환경의 통일성을 유지하고, 변경 내역을 확인하는 등 여러 팀이 프로젝트를 진행할 때 매우 중요합니다.
개발자는 인프라를 연구하고 자신의 환경을 독립적으로 개발할 수 있습니다.

섹션 보너스: PostgreSQL 데이터베이스의 장애 조치 클러스터 생성 및 구성. 우리는 Southbridge에서 사용할 수 있는 기성 플레이북을 제공할 것이며, 귀하는 교육 스탠드에 클러스터를 배포하고 회사에서 이 솔루션을 사용할 수 있습니다.

인프라 테스트 및 모니터링

자동화를 사용하면 한 번에 수천 대의 서버에 오류를 롤아웃할 수 있습니다. 모든 변경에는 테스트가 필요합니다. 반면 수동 테스트에는 시간이 너무 많이 걸려 자동화의 이점이 무효화됩니다.

역할 테스트를 작성하는 방법을 실제로 보여 드리겠습니다. 결과적으로, 귀하는 귀하의 회사에 대한 테스트를 작성할 수 있게 됩니다. 더 이상 설정을 기억할 필요가 없습니다. 테스트에서 설정을 설명하고 이전 솔루션과 목발이 모두 제자리에 있는지 자동으로 확인합니다.

그런 다음 모든 새 서버를 모니터링에 자동으로 추가하는 방법을 알아봅니다. 인프라와 애플리케이션 모니터링을 별도로 살펴보겠습니다. 우리는 나쁜 관행과 좋은 관행을 보여줄 것입니다.

주제 #8: 인프라 테스트

• Molecule 및 Gitlab CI를 사용한 테스트 및 지속적인 통합
• 방랑자 사용

주제 #9: Prometheus를 사용한 인프라 모니터링

• 모니터링이 필요한 이유는 무엇입니까?
• 모니터링 유형
• 모니터링 시스템의 알림
• 건강한 모니터링 시스템을 구축하는 방법
• 누구나 읽을 수 있는 알림
• 건강검진, 주의해야 할 점
• 모니터링 데이터 기반 자동화

제대로 작동하지 않는 모니터링은 모니터링이 아닙니다. 기업에서는 결제 양식에 오류가 발생하더라도 온라인 상점의 메인 페이지에 액세스할 수 있는지 신경 쓰지 않습니다.

개발자와 관리자는 모니터링 설정 및 문제 해결에 동등하게 참여합니다. 또한 전통적으로 모니터링 작업은 관리자에게 맡겨졌습니다. 우리 과정에서는 개발자들이 효과적인 모니터링을 생성하는 데 어떤 역할을 하는지 보여줄 것입니다. 관리자는 Southbridge 모범 사례를 받게 됩니다. 결과적으로 웹사이트나 애플리케이션의 오류와 속도 저하로 인한 손실이 빠르게 줄어들 것입니다.

섹션 보너스: 모니터링 기반 자동화. 예를 들어, 모니터링은 사이트에 로드가 도달했음을 보고하고 웹 서버 확장이 자동으로 시작됩니다.

벌채 반출

로그 작업 시 가장 큰 실수는 관리자와 개발자가 서버에서 직접 로그를 본다는 것입니다. 서버가 두 개 이상인 경우 시간이 오래 걸립니다. 이는 안전하지 않습니다. 개발자가 있어서는 안되는 서버에 로그인합니다.

DevOps에는 중앙 집중식 로그 수집, 처리 및 분석이 필요합니다.

주제 #10: ELK를 사용하여 애플리케이션 로깅

• Elastic의 기본 애플리케이션 및 기능(검색, 저장, 확장 기능, 사용자 정의 유연성)
• Kibana 개요(주요 기능, 쿼리 언어, 대시보드 관리, 차트 생성)
• 탄성 기반 제품 및 응용 검토
• APM에서 지표 수집(애플리케이션 추적)
• 추가: 신제품 리뷰 - SIEM

이 접근 방식을 도입하면 로그가 애플리케이션과 인프라를 분석, 구성 및 디버깅하기 위한 간단하고 이해하기 쉬운 도구가 될 것입니다.

SRE

그리고 우리는 Southbridge가 주목하고 있는 주제와 다른 연사들이 Slurm의 마지막 날에 머물기를 원하는 주제에 도달했습니다. Booking.com의 Ivan Kruglov가 이 글을 읽는 데 동의해주셔서 기쁘게 생각합니다.

이 프로젝트는 신뢰성이 결코 절대적이지 않고 모든 결정에 비용이 드는 현실 세계에 존재합니다.

복잡한 프로젝트와 관련된 SLA란 무엇입니까? 사이트에 액세스할 수 있지만 이미지가 지연되어 로드되는지 평가하는 방법을 가정해 보겠습니다. SLA 측정항목은 무엇이며, 어디에서, 어떻게 가져갈 수 있나요?

SLA를 설정하는 방법은 무엇입니까? 어떻게 견뎌야 할까요?

주제 #11: SRE
SRE 세계의 SLA, SLO, 오류 예산 및 기타 무서운 용어의 정의
SRE: SLI 및 SLO 모니터링 방식
SRE: Error Budget 활용 실습
SRE: 인터럽트 및 운영 부하 관리(apigateway, 서비스 메시, 회로 차단기)
기업은 SRE를 원합니다. 최소한 가장 간단한 수준에서는 백업 서버를 가져와야 할까요, 아니면 백업에서 들어 올려야 할까요? 단일 데이터베이스 또는 클러스터? DDoS 보호 기능을 사전에 설치해야 합니까, 아니면 공격 시에만 설치해야 합니까?

원장은 고객이 전화를 걸어 주문 양식이 열리지 않는다고보고하면 "사이트가 작동 중"이라는 이야기에 만족하지 않을 것입니다.

따라서 DevOps 엔지니어가 SRE의 요구 사항에 대해 비즈니스와 적절하게 대화하려면 최소한 표면적으로 SRE를 이해하는 것이 중요합니다.

합계

동안 슬럼 데브옵스 관리자와 개발자는 다음을 배우게 됩니다.
— Git으로 올바르게 작동합니다.
— 지역 개발을 조직합니다.
— CI/CD 구성(관리자) 및 사용(개발자)
— 코드와 마찬가지로 인프라를 사용하여 작업합니다.
— 인프라를 테스트합니다.
— 인프라 및 애플리케이션을 모니터링합니다.
— 로깅을 구성합니다.
— SRE를 이해하고 이상적으로 사용하십시오.

세심한 독자를 위해 habrapost 프로모션 코드를 사용하여 15% 할인을 받으세요.

모든 포인트에 대한 연습과 도구를 준비하고 있습니다. 따라서 각 참가자는 Slurm에서 돌아와 회사를 DevOps의 다음 단계로 끌어올릴 수 있습니다.

비즈니스의 경우 이는 관리 및 개발 비용 절감, 가동 중지 시간 감소, 안정성 향상, 기능 제공 속도 향상 및 버그 제거를 의미합니다.

출처 : habr.com