네트워크 인프라를 제어하는 ​​방법. XNUMX장. 오토메이션. 템플릿

이 기사는 "네트워크 인프라를 제어하는 ​​방법" 시리즈의 여섯 번째 기사입니다. 시리즈의 모든 기사 내용과 링크를 확인할 수 있습니다. 여기에.

여러 가지 주제를 뒤로한 채, 나는 새로운 장을 시작하기로 결정했습니다.

보안에 대해서는 잠시 후에 다시 말씀드리겠습니다. 여기서는 어떤 형태로든 많은 사람들에게 유용할 수 있는 간단하면서도 효과적인 접근 방식에 대해 논의하고 싶습니다. 이는 자동화가 엔지니어의 삶을 어떻게 변화시킬 수 있는지에 대한 짧은 이야기에 가깝습니다. 템플릿 사용에 대해 이야기하겠습니다. 마지막에는 여기에 설명된 모든 것이 어떻게 작동하는지 확인할 수 있는 내 프로젝트 목록이 있습니다.

네트워크를 위한 DevOps

스크립트로 구성 생성, GIT를 사용하여 IT 인프라 변경 제어, 원격 "업로드" 등 이러한 아이디어는 DevOps 접근 방식의 기술적 구현을 ​​생각할 때 가장 먼저 떠오릅니다. 장점은 분명합니다. 그러나 불행히도 단점도 있습니다.

5년 전쯤에 우리 개발자들이 우리 네트워크 담당자들에게 이런 제안을 했을 때 우리는 별로 기뻐하지 않았습니다.

우리는 약 10개 업체의 장비로 구성된 다소 잡다한 네트워크를 물려받았다고 말하고 싶습니다. 우리가 선호하는 CLI를 통해 일부 항목을 구성하는 것이 편리했지만 다른 항목에서는 GUI를 사용하는 것을 선호했습니다. 또한 "라이브" 장비에 대한 오랜 작업을 통해 실시간 제어 방법을 배웠습니다. 예를 들어, 변경 작업을 할 때 cli를 통해 직접 작업하는 것이 훨씬 더 편합니다. 이렇게 하면 문제가 발생했음을 빠르게 확인하고 변경 사항을 롤백할 수 있습니다. 이 모든 것은 그들의 생각과 모순되는 것이었습니다.

예를 들어 소프트웨어 버전에 따라 인터페이스가 약간 변경될 수 있다는 것과 같은 다른 질문도 발생합니다. 이로 인해 결국 스크립트가 잘못된 "config"를 생성하게 됩니다. 나는 "실행"을 위해 프로덕션을 사용하고 싶지 않습니다.

또는 구성 명령이 올바르게 적용되었는지 이해하고 오류가 발생한 경우 어떻게 해야 합니까?

나는 이 모든 문제가 해결 불가능하다고 말하고 싶지 않습니다. "A"라고 말하는 것이 "B"라고 말하는 것도 의미가 있을 것입니다. 개발에서와 동일한 변경 제어 프로세스를 사용하려면 프로덕션 외에 개발 및 스테이징 환경도 있어야 합니다. 그렇다면 이 접근 방식은 완전해 보입니다. 그런데 비용이 얼마나 들까요?

그러나 단점이 실질적으로 평준화되고 장점 만 남는 상황이 하나 있습니다. 디자인 작업에 대해 이야기하고 있습니다.

계획

지난 5년 동안 저는 대규모 공급자를 위한 데이터 센터 구축 프로젝트에 참여해 왔습니다. 저는 이번 프로젝트에서 F3와 Palo Alto를 담당하고 있습니다. Cisco의 관점에서 보면 이는 "타사 장비"입니다.

개인적으로 이 프로젝트에는 두 가지 단계가 있습니다.

첫 번째 단계

첫해에는 끝없이 바빴고 밤과 주말에도 일했습니다. 나는 고개를 들 수 없었다. 경영진과 고객의 압력은 강력하고 지속적이었습니다. 계속되는 루틴에서는 프로세스를 최적화하려는 시도조차 할 수 없었습니다. 설계 문서 준비만큼 장비 구성도 중요하지 않았습니다.

첫 번째 테스트가 시작되었는데, 작은 오류와 부정확성이 얼마나 많이 발생했는지 보면 놀랄 것입니다. 물론 모든 것이 작동했지만 이름에 글자가 빠졌고 명령에 줄이 빠졌습니다... 테스트는 계속되었고 저는 이미 오류, 테스트 및 문서로 인해 매일 끊임없이 어려움을 겪고 있었습니다. .

이것은 1년 동안 계속되었습니다. 내가 아는 한, 이 프로젝트는 모든 사람에게 쉬운 일은 아니었지만 점차 고객의 만족도가 높아졌고 이를 통해 스스로 루틴의 일부를 담당할 수 있는 추가 엔지니어를 고용할 수 있게 되었습니다.

이제 우리는 조금 둘러볼 수 있었습니다.
그리고 이것이 두 번째 단계의 시작이었습니다.

2 단계

나는 프로세스를 자동화하기로 결정했습니다.

당시 개발자들과의 대화를 통해 제가 이해한 것은(우리는 경의를 표해야 하며 강력한 팀이 있었습니다) 텍스트 형식은 언뜻 보기에는 DOS 운영 체제 세계의 것과 비슷해 보이지만 숫자가 있다는 것입니다. 귀중한 재산의.
예를 들어, GIT 및 모든 파생 상품을 최대한 활용하려는 경우 텍스트 형식이 유용할 것입니다. 그리고 나는 원했다.

글쎄, 단순히 구성이나 명령 목록을 저장할 수 있는 것처럼 보이지만 변경하는 것은 상당히 불편합니다. 게다가 디자인 중에는 또 다른 중요한 작업이 있습니다. 전체 설계(낮은 수준 설계)와 특정 구현(네트워크 구현 계획)을 설명하는 문서가 있어야 합니다. 이 경우 템플릿을 사용하는 것이 매우 적합한 옵션인 것 같습니다.

따라서 YAML 및 Jinja2를 사용할 때 IP 주소, BGP AS 번호 등과 같은 구성 매개변수가 있는 YAML 파일은 NIP의 역할을 완벽하게 수행하는 반면 Jinja2 템플릿에는 설계에 해당하는 구문이 포함됩니다. LLD를 반영합니다.

YAML과 Jinja2를 배우는 데 이틀이 걸렸습니다. 몇 가지 좋은 예만으로도 이것이 어떻게 작동하는지 이해하기에 충분합니다. 그런 다음 우리 디자인에 맞는 모든 템플릿을 만드는 데 약 5주가 걸렸습니다. Palo Alto의 경우 일주일, FXNUMX의 경우 일주일이 걸렸습니다. 이 모든 내용은 기업 githab에 게시되었습니다.

이제 변경 프로세스는 다음과 같습니다.

• YAML 파일을 변경했습니다.
• 템플릿(Jinja2)을 사용하여 구성 파일을 생성했습니다.
• 원격 저장소에 저장됨
• 생성된 구성을 장비에 업로드
• 오류가 발생했습니다.
• YAML 파일 또는 Jinja2 템플릿을 변경했습니다.
• 템플릿(Jinja2)을 사용하여 구성 파일을 생성했습니다.
• ...

처음에는 편집에 많은 시간이 소요되었지만 1~2주 후에는 이것이 매우 드물어졌습니다.

모든 것을 디버깅할 수 있는 좋은 테스트이자 기회는 명명 규칙을 변경하려는 클라이언트의 바람이었습니다. F5와 함께 일한 사람들은 상황의 심각성을 이해합니다. 하지만 나에게는 모든 것이 아주 간단했습니다. YAML 파일에서 이름을 변경하고 장비의 구성 전체를 삭제한 후 새로 생성하여 업로드했습니다. 버그 수정을 포함해 모든 작업에 4일이 걸렸습니다. 각 기술마다 XNUMX일이 걸렸습니다. 그 후 저는 다음 단계인 DEV 및 Staging 데이터 센터 구축을 준비했습니다.

개발 및 준비

스테이징은 실제로 프로덕션을 완전히 복제합니다. Dev는 주로 가상 하드웨어를 기반으로 구축된 대폭 축소된 복사본입니다. 새로운 접근 방식을 위한 이상적인 상황입니다. 전체적인 과정에서 소요된 시간을 따로 떼어내면 작업 시간은 2주도 채 걸리지 않은 것 같습니다. 주된 시간은 상대방을 기다리고 함께 문제를 찾는 것입니다. 제3자 구현은 다른 사람들이 거의 눈치 채지 못했습니다. 무언가를 배우고 Habré에 관한 몇 가지 기사를 쓸 시간도 있었습니다 :)

요약하면

그렇다면 최종 결과는 무엇입니까?

• 구성을 변경하기 위해 해야 할 일은 구성 매개변수를 사용하여 간단하고 명확하게 구조화된 YAML 파일을 변경하는 것뿐입니다. 나는 Python 스크립트를 절대 변경하지 않으며 아주 드물게(오류가 있는 경우에만) Jinja2 heatlate를 변경합니다.
• 문서화 관점에서 볼 때 이는 거의 이상적인 상황입니다. 문서를 변경하고(YAML 파일은 NIP 역할을 함) 이 구성을 장비에 업로드합니다. 이렇게 하면 문서가 항상 최신 상태로 유지됩니다.

이 모든 것이 다음과 같은 사실로 이어졌습니다.

• 오류율이 거의 0으로 떨어졌습니다.
• 일상의 90%가 사라졌습니다
• 구현 속도가 크게 향상되었습니다.

지불, F5Y, ACY

나는 그것이 어떻게 작동하는지 이해하는 데 몇 가지 예가 충분하다고 말했습니다.
다음은 제가 작업하는 동안 생성된 내용의 짧은(물론 수정된) 버전입니다.

PAY = 배포 PALO A~로부터 Yaml = Yaml의 Palo Alto
F5Y = 배포 F5 에 Y앰 = F5 에 YAML(곧 제공 예정)
ACY = 배포 AC나는 Y앰 = F5 에 Yaml

ACY에 대해 몇 마디 추가하겠습니다(ACI와 혼동하지 마세요).

ACI와 함께 일해 본 사람들은 이 기적이 (그리고 좋은 방법으로도) 확실히 네트워크 담당자가 만들어낸 것이 아니라는 것을 알고 있습니다. 네트워크에 대해 알고 있던 모든 것을 잊어버리십시오 - 그것은 당신에게 유용하지 않을 것입니다!
좀 과장되긴 했지만 지난 3년 동안 ACI와 함께 일하며 꾸준히 경험한 느낌을 대략적으로 전달한 것 같습니다.

그리고 이 경우 ACY는 변경 제어 프로세스(ACI의 경우 데이터 센터의 중심이자 가장 중요한 부분이기 때문에 특히 중요함)를 구축할 수 있는 기회일 뿐만 아니라 다음과 같은 이점도 제공합니다. 구성 생성을 위한 사용자 친화적인 인터페이스.

이 프로젝트의 엔지니어는 정확히 동일한 목적으로 Excel을 사용하여 YAML 대신 ACI를 구성합니다. 물론 Excel을 사용하면 다음과 같은 장점이 있습니다.

• NIP를 하나의 파일로
• 고객이 보기에 좋은 아름다운 간판
• 몇 가지 Excel 도구를 사용할 수 있습니다

하지만 한 가지 마이너스가 있는데 제 생각에는 그것이 전문가보다 더 중요합니다. 변경 사항을 제어하고 팀 작업을 조정하는 것이 훨씬 더 어려워집니다.

ACY는 실제로 타사에서 ACI를 구성하는 데 사용한 것과 동일한 접근 방식을 적용한 것입니다.

출처 : habr.com