저장소와 표준화는 네트워크 자동화 통합 과제를 해결하는 데 도움이 될 수 있습니다.

통합이라는 단어는 이를 갈고 있는 사람들의 탄식과 이를 구현하기 위한 프로젝트에 지친 사람들의 통곡을 불러일으킨다는 의미에서 항상 네 글자로 표현되어 왔습니다. 실제로 IT 의사결정권자의 59%가 "통합을 조직의 '아킬레스건'으로 규정했습니다." ( Connected Business Integration 2018 보고서 )

표면적으로 통합은 간단한 전제에서 시작됩니다. 즉, 애플리케이션 간에 데이터를 어떻게 공유할 것인가? 어떤 애플리케이션도 - 심지어 모노리스도 - 섬이 아니기 때문입니다. 아직 다른 애플리케이션과 적어도 하나의 데이터를 공유하지 않는 애플리케이션을 만나본 적이 없습니다.

우리(업계 전체)는 여러 번의 통합 시기를 거쳤습니다. 허브 앤 스포크 모델부터 엔터프라이즈(서비스) 버스, 메시지 큐에 이르기까지 통합은 항상 엔터프라이즈 애플리케이션 전략의 필수 구성 요소입니다.

우리는 더 이상 이를 기업 애플리케이션 통합(EAI)이라고 부르지 않습니다. 주로 이 단어가 젊은이들을 무서워하게 하고 우리 같은 나이든 사람들을 격노하게 만들기 때문이라고 생각합니다. 하지만 우리는 여전히 "통합"이라는 단어를 사용합니다. 그리고 우리는 이를 애플리케이션 개발 분야 밖에서도 점점 더 많이 사용하고 있습니다. 결국 CI는 지속적인 통합을 의미합니다. 우리는 통합이 배포(생산) 측면에서도 중요하다고 생각합니다. 네트워크 자동화에 직면했을 때 통합 도구가 부족하여 좌절감을 느끼는 사람들이 있듯이, 우리도 앱 개발자들만큼이나 좌절감을 느낍니다. 

운영에는 통합이 필요합니다. 이것이 없다면 우리는 프로세스를 자동화할 수 없습니다(이것이 바로 오케스트레이션입니다). 프로세스는 필연적으로 여러 시스템, 서비스, 장치에 걸쳐 진행되며, 각각은 고유한 운영 도메인과 툴셋을 가질 가능성이 높습니다. 통합 없이는 파이프라인을 구축할 수 없으며, 파이프라인 없이는 수요에 따른 빈번한 배포 요구 사항이 증가하면서 운영이 과부하 상태가 될 것입니다.

바로 이 부분에서 코드형 인프라 와 저장소가 구제책을 제공할 수 있습니다. 저장소는 구성 파일부터 Python 프로그램, 스크립트와 템플릿에 이르기까지 거의 모든 종류의 아티팩트를 저장할 수 있는 장소 그 이상입니다. 그들은 귀하의 (통합된) 배포 파이프라인에 적극적으로 참여할 수 있습니다.

저장소는 저장 상자 이상입니다.

저장소는 단순히 유물을 저장하는 장소가 아닙니다. 그렇죠. 그게 주된 목적이긴 하지만 이제는 단순한 보관함 이상으로 진화했어요. 오늘날 GitLab 및 GitHub과 같은 저장소는 자동화 파이프라인의 핵심 구성 요소가 될 수 있습니다. 트리거와 이벤트를 사용하여 저장소는 아티팩트를 저장하는 장소일 뿐만 아니라 더 큰 툴체인의 도구 역할도 합니다. 커밋은 작업을 시작하고, 작업이 완료되면 파이프라인의 다음 단계를 트리거하는 웹훅을 호출합니다.

웹훅이란 무엇인가요?

'역 API'라고도 불리는 웹훅은 리포지토리와 같은 한 애플리케이션이 URL/API를 통해 실시간으로 다른 애플리케이션으로 데이터를 보낼 수 있도록 합니다. 예를 들어, 로드 밸런서에 대한 새 구성을 커밋하면 리포지토리는 웹훅을 트리거하고, 이는 다시 구성 또는 구성의 URI를 앱(또는 로드 밸런서에 직접)으로 보내고, 앱은 다시 새 구성을 로드합니다.

기본적으로, 우리는 "프로세스"를 완료하기 위해 다양한 애플리케이션과 서비스에서 데이터를 공유하고 작업을 시작하기 위해 엔터프라이즈 서비스 버스를 사용하던 것과 같은 방식으로 저장소를 사용하고 있습니다. 비즈니스 세계에서 그 과정은 고객 주문을 완료하는 것일 수 있으며, 여기에는 고객 정보 시스템(CIS), 주문 처리 시스템, 청구 및 공급망 요소가 포함될 수 있습니다.

운영 분야에서 해당 프로세스는 애플리케이션이나 정책의 배포를 이행하는 데 관련된 인프라, 네트워크, 보안 서비스에 걸쳐 있습니다.

"기술"을 가장 큰 과제로 꼽은 사람들에게 더욱 흥미로운 점은, 저장소를 거의 전적으로 명령줄에서 제어할 수 있다는 것입니다. 네, 대부분의 NetOps가 이미 보유하고 있는 것과 동일한 기술을 사용하면 됩니다. 약간의 bash와 PERL*, curl을 통한 API만 있으면 됩니다!

하지만 이는 공급업체 솔루션 부족으로 인한 좌절감으로 표현되는 장치 계층에서의 통합에 대한 더 깊은 필요성을 해결하지 못합니다. 궁극적으로 저장소에 저장되어 있고 Webhook에 의해 트리거되는 구성이나 구성에 대한 변경 사항은 여전히 장치 언어로 번역되어야 합니다.

여기서 표준화와 솔루션이 중요한 역할을 합니다.

표준화는 운영 통합 부담을 줄입니다.

자동화는 현재 F5의 많은 구성원이 집중하고 있는 분야입니다. 우리가 찾아낸 솔루션 중 하나가 F5 자동화 툴체인 입니다. 여기에는 F5 애플리케이션 서비스 3 확장(AS3), F5 선언적 온보딩(DO), F5 원격 측정 스트리밍 및 F5 API 서비스 게이트웨이가 포함됩니다. 저장소와 함께 사용하면 조직에서 애플리케이션(및 비즈니스)에 필요한 애플리케이션 서비스를 배포하는 데 필요한 파이프라인을 구축하여 앱을 빠르고 안전하게, 그리고 가용성 있게 유지할 수 있습니다.
 

하지만 로리, 당신은 그것이 내가 자동화하고 통합해야 할 다른 모든 장치와 서비스에 도움이 되지 않는다고 생각할 겁니다.

진실. 이는 공통 애플리케이션 서비스 플랫폼의 표준화가 도움이 될 수 있는 방법 중 하나입니다.  BIG-IP 플랫폼은 광범위한 애플리케이션 서비스에 동일하므로 자동화 툴체인을 사용하여 WAF, 부하 분산 장치, 액세스 제어, DDoS 보호 등을 배포할 수 있습니다. 가능한 한 적은 플랫폼을 표준화하면 네트워크, 인프라, 보안 등 모든 운영의 통합 부담을 줄여서 가치를 더할 수 있습니다.

이는 데이터 센터 내부와 멀티 클라우드 시나리오에서 사실입니다. 여러 애플리케이션 서비스와 클라우드 환경에서 단일 플랫폼을 표준화하면 어디에든 앱을 배포할 때 가치 실현 시간이 단축됩니다. 

(완전히 무료로 사용할 수 있는) F5 자동화 툴체인은 여러 위치에서 찾을 수 있습니다.

• GitHub 에서
• Docker Hub 에서
• F5 Ansible 모듈

그러니 기억하세요, 저장소는 단순히 물건을 저장하는 장소가 아닙니다. 이러한 도구는 파이프라인의 모든 분산된 부분을 자동화하는 데 도움이 되는 자동화 도구 상자의 귀중한 도구입니다. 애플리케이션 서비스 플랫폼과 함께 저장소를 표준화하면 통합이라는 네 글자 단어가 부과하는 운영 부담을 크게 줄이는 데 도움이 될 수 있습니다. 

"PERL"을 Python이나 실제로 사용 가능한 스크립팅 언어로 해석합니다. PERL은 curl 과 운율이 맞는 유일한 언어이고, wget 과 운율이 맞는 좋은 언어는 찾지 못했습니다.