ADC 0.11 & 0.12의 새로운 기능은 무엇인가요?

Zeping Bai

Zeping Bai

August 7, 2024

Technology

ADC(API Declarative CLI)의 버전 0.10이 출시된 지 두 달이 지난 후, 우리는 끊임없이 노력하여 두 가지 주요 업데이트인 버전 0.11과 0.12, 그리고 일련의 타겟팅된 패치 업데이트를 제공했습니다. 이러한 업데이트는 주로 Apache APISIX 지원, 기존 기능 개선, 버그 수정에 초점을 맞추고 있습니다.

Apache APISIX 백엔드 지원 추가

ADC 0.11부터 Apache APISIX 백엔드에 대한 실험적 지원이 도입되었습니다.

ADC는 이제 APISIX Admin API와 통합되어 효율적인 리소스 내보내기 및 동기화가 가능합니다. 우리는 계속해서 사용성을 개선할 것입니다. ADC에서 apisix 백엔드 옵션은 기본적으로 활성화되어 있으며, 사용자는 Admin API 엔드포인트와 API 키만 구성하면 연결할 수 있습니다.

ADC와 Admin API의 차이점

ADC는 APISIX의 모든 기능과 완전히 일치시키는 것을 목표로 하지 않으며, 대신 핵심 기능 집합과 모범 사례에 초점을 맞추고 있습니다. 우리는 사용자가 진정으로 필요로 하는 기능에 투자하는 것이 ADC의 발전 방향이라고 믿습니다.

APISIX는 높은 수준의 구성 유연성을 제공하지만, 이러한 자유는 종종 장기적인 유지보수의 복잡성을 동반합니다. 구성 관리가 한 관리자에서 다른 관리자로 이전될 때, 새로운 관리자는 이전 관리자의 독특한 구성 방식과 스타일을 이해해야 하는 과제에 직면하게 됩니다. 대신, 성숙하고 널리 인정받는 모범 사례 규칙을 직접 채택하는 것이 더 나은 방법입니다.

예를 들어, APISIX 플랫폼에서 사용자는 특정 서비스에 직접 바인딩되지 않은 경로를 구성할 수 있으며, 대신 경로 수준에서 직접 업스트림 리소스를 지정할 수 있습니다. 그러나 이 방법은 ADC에서 기본적으로 지원되지 않습니다. 논리적 규범과 표준화된 운영 절차에 맞추기 위해, 특정 서비스 내에 경로를 포함하고 해당 서비스 내에서 정확하게 업스트림 주소를 설정하는 것이 권장되는 접근 방식입니다.

예를 들어, 제품 서비스에서 Product Service라는 서비스를 정의하고, 업스트림을 구성하고, 플러그인을 활성화하며, 그 안에 경로를 설정합니다. 이 모델에서 여러 경로가 동일한 업스트림과 플러그인 구성을 공유할 수 있어 구성 과정을 크게 단순화합니다.

services:
  - name: Product Service
    upstream:
      type: roundrobin
      nodes:
        - host: product.ecommerce.svc.cluster.local
          port: 443
          weight: 100
      scheme: https
    plugins:
      key-auth: {}
    routes:
      - name: List Products
        uris:
          - /products
        methods: ["GET"]
      - name: Get Product
        uris:
          - /product/*
        methods: ["GET"]

위의 예제는 서비스 정의의 최소 형식입니다. 이 외에도 ADC는 서비스 발견, 타임아웃 설정, 재시도 정책, 경로 우선순위 설정과 같은 고급 기능을 지원하여 포괄적이고 유연한 구성을 보장합니다.

APISIX가 더 풍부한 구성 방법을 지원하기 때문에, ADC는 APISIX Admin API 표시와 비교하여 내보내기 구성에서 불일치가 발생할 수 있습니다. 예를 들어:

  • 서비스를 사용하지 않는 경로는 서비스-경로 계층 구조를 충족하기 위해 하나의 서비스로 클러스터링됩니다.
  • ID로 참조된 업스트림은 사용 지점에서 인라인됩니다.
  • 플러그인 템플릿 리소스는 경로를 포함하는 서비스로 대체됩니다.

따라서 사용자는 내보내기 과정에서 생성된 ADC 정의 파일을 주의 깊게 검토하여 원래 의도에 부합하는지 확인해야 합니다.

ADC를 권장하는 이유는 무엇인가요?

APISIX 대시보드를 사용할 때, 사용자는 종종 반복적인 작업을 폼에서 수행해야 하며, 이는 번거롭고 오류가 발생하기 쉽습니다. 반면, ADC를 사용한 선언적 구성은 단순히 YAML 파일을 작성하고 동기화 작업을 실행하는 것을 포함합니다. ADC는 구성을 자동으로 Admin API 호출로 변환하여 빠른 배포와 관리를 가능하게 합니다.

따라서 ADC는 관리 및 배포 과정을 단순화하는 데 도움이 되며, GitOps 시나리오를 쉽게 달성할 수 있습니다. 이는 Git 저장소를 통해 YAML 정의 파일을 관리하고 PR 워크플로우와 CI 도구를 사용하여 구성을 자동으로 업데이트하는 것을 포함합니다. 이는 수동 작업의 양을 크게 줄이고, APISIX 대시보드에서 발생하는 문제를 피하며, Admin API를 호출하는 스크립트 작성의 복잡성을 줄입니다.

새로운 프로젝트의 경우, 우리는 ADC로 시작하여 게이트웨이 구성을 구축하는 것을 강력히 권장합니다. 기존 프로젝트의 경우, 구성을 내보내고 적절히 수정하여 ADC 관리로 점진적으로 마이그레이션할 수 있습니다.

API7 Enterprise 백엔드 최적화

버전 0.11/0.12에 포함됨

버전 0.11과 0.12에서 우리는 API7 백엔드에 대한 여러 최적화를 구현하여 개발자 경험을 향상시켰습니다. ADC는 이러한 개선 사항과 완전히 호환되므로, 개발자는 기존 정의 파일을 수정하지 않고도 ADC 버전만 최신으로 유지하면 이러한 개선 사항을 누릴 수 있습니다.

ADC 정의 검사 최적화

버전 0.12에 포함됨

우리는 ADC 정의 검사를 위한 스키마 규칙을 전면적으로 최적화하고 수정하여 개발자가 잠재적인 구성 문제를 미리 감지하고 효과적으로 피할 수 있도록 도왔습니다.

JSON 스키마

또한, 우리는 이제 검증 규칙을 JSON 스키마로 내보내는 것을 지원하여 IDE를 사용하는 편집자를 돕습니다. 사용자는 파일에서 구문 힌트와 실시간 검사를 모두 활용할 수 있어 코딩 효율성과 품질을 크게 향상시킬 수 있습니다.

Visual Studio Code를 선호하는 개발자의 경우, YAML 플러그인을 활성화하고 파일 상단에 다음 주석을 추가하면 이 기능을 활성화할 수 있습니다:

# yaml-language-server: $schema=https://raw.githubusercontent.com/api7/adc/main/schema.json

결론

이전 블로그에서 언급한 바와 같이, ADC는 결국 오픈소스화될 예정입니다. 6개월 간의 내부 개발과 여러 번의 반복을 거쳐, ADC는 완전히 TypeScript 기반 코드베이스로 재구성되었으며, 원래의 Go 코드를 완전히 버렸습니다. 이는 학습과 개발을 더 쉽게 만듭니다.

ADC 버전 0.12의 공개 릴리스와 함께, 우리는 전 세계 개발자들이 ADC의 개발과 개선에 참여하도록 초대합니다. 코드베이스는 이제 https://github.com/api7/adc에서 공개되었으며, 여러분의 기여를 기대합니다.

Tags:
ADC
APISIX Basics