ADC 0.11 & 0.12 の新機能は？

Zeping Bai

Zeping Bai

August 7, 2024

Technology

ADC (API Declarative CLI)のバージョン0.10がリリースされてから2ヶ月が経ちました。この間、私たちは2つのメジャーアップデート（バージョン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は高い設定の柔軟性を提供していますが、この自由度は長期的なメンテナンスの複雑さを伴うことが多いです。設定管理が1人のメンテナーから別のメンテナーに引き継がれる場合、新しいメンテナーは通常、前のメンテナーの独自の設定アプローチとスタイルを理解するという課題に直面し、成熟した広く認められたベストプラクティスのルールを直接採用するのではなくなります。

例えば、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 Schema

さらに、検証ルールをJSON Schemaとしてエクスポートする機能をサポートし、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の公開リリースに伴い、世界中の開発者にその開発と改善への参加を呼びかけます。コードベースは現在https://github.com/api7/adcで公開されており、皆さんの貢献を楽しみにしています。

Tags:
ADC
APISIX Basics