Linkerd が新しいバージョン 2.12 にアップグレードされました

Linkerd が新しいバージョン 2.12 にアップグレードされました

Linkerd の最新バージョン 2.12 がリリースされました。この大規模なバージョンでは、Linkerd にルーティングベースのポリシーが導入され、ユーザーは完全にゼロ トラスト方式で HTTP ルーティングベースの承認ポリシーを定義および実行できるようになります。これらのポリシーは、Linkerd の強力なワークロード ID に基づいて構築され、相互 TLS によって保護され、Kubernetes の新しい Gateway API の型を使用して構成されます。

変更履歴

Linkerd 2.12 は、Gateway API をコア構成メカニズムとして採用するための第一歩です。この API はまだサービス メッシュのユース ケースには最適ではありませんが、このリリースの強力な出発点となります。さらに重要なのは、Gateway API 上に構築することで、新しい機能を導入しても Linkerd 固有の構成オブジェクトの数を最小限に抑えることができることです。これは、Kubernetes 向けの最もシンプルで軽量なサービス メッシュを作成するという私たちの目標の重要な部分です。さらに、バージョン 2.12 では、Linkerd が Apache スタイルのリクエスト ログを生成できるようにする待望の機能であるアクセス ログが導入されました。 iptables-nft のサポートが追加され、その他多くの改善とパフォーマンス強化が導入されています。

ルートごとの戦略

Linkerd の新しいルートごとのポリシーは、既存のポートベースのポリシーを拡張して、サービスが相互に通信する方法をより細かく制御できるようにします。これらのポリシーは、暗号化だけでなく、強力なワークロード ID と明確な承認も必要とするゼロトラスト セキュリティ アプローチを採用している組織向けに設計されています。

  • ネットワークを敵対的なものとして扱います。IP アドレスに依存せず、CNI レイヤーや基盤となるネットワークのその他の側面が安全である必要もありません。
  • 安全なワークロード ID を使用する: Linkerd のワークロード ID は ServiceAccounts によって自動的に生成され、接続時に相互 TLS を介して暗号的に検証されます。
  • Pod レベルで適用: すべての接続とすべてのリクエストが認証されます。
  • 簡単に許可できるモデル: セキュリティを重視する採用者は、明示的に許可されない限り、デフォルトで機密リソースへのアクセスを簡単に拒否できます (「最小権限の原則」)。

ヘルス プローブと準備プローブは許可なしに通過する必要があるため、Kubernetes ではデフォルトで拒否する構成が問題になる可能性があります。 Linkerd 2.12 では、ヘルス プローブと準備プローブがデフォルトで承認されるようになりましたが、他のアプリケーション エンドポイントをロックダウンしながら明示的に承認することもできます。

ゲートウェイAPI

Linkerd 2.12 は、Kubernetes Gateway API のサポートに向けた第一歩を提供します。 Gateway API はもともと、Kubernetes の長年使用されてきた Ingress リソースのより豊富で柔軟な代替として設計されましたが、サービス メッシュ トラフィックを記述するための優れた基盤を提供し、Linkerd が増分構成を最小限に抑えることを可能にします。

Linkerd 2.12 では、Linkerd は、Linkerd のルートベースのポリシーを構成するための Gateway API の部分的な実装を提供します。この方法により、Linkerd にとって意味をなさない仕様の部分を実装することなく、Gateway API の使用を開始できます。 Gateway API が進化するにつれて、Linkerd のニーズを徐々に満たすようになります。

アクセスログ

Linkerd 2.12 ではアクセス ログも導入され、プロキシが Apache スタイルのリクエスト ログを出力できるようになりました。この機能は、パフォーマンスとリソース使用率の理由から（特にトラフィック量の多いワークロードの場合）、デフォルトではオフになっていますが、必要に応じて簡単に有効にすることができます。

その他の更新

Linkerd 2.12 には、他にも次のような数多くの改善、パフォーマンス強化、バグ修正が含まれています。

  • プロキシが正常にシャットダウンするための最大猶予期間を構成するための新しい config.linkerd.io/shutdown-grace-period アノテーション。
  • Linkerd の init コンテナで iptables-nft をサポートするための新しい iptables-nft モード。
  • 信頼のルートのローテーション後に、一部のコントロール プレーン コンポーネントが要求どおりに再起動されない問題を修正しました。
  • Linkerd 名前空間で予期しない Pod が見つかった場合に linkerd check コマンドで発生するクラッシュを修正しました。
  • proxy.await Helm 値を変更し、ユーザーがコントロール プレーン コンポーネントで linkerd-await を無効にできるようになりました。
  • 必要に応じて、Linkerd 拡張機能のデプロイメントをオートスケーラーによって削除できるようにするアノテーション。
  • Linkerd CNI プラグインをスタンドアロン モードで実行する機能。
  • マルチクラスター拡張機能の ServiceAccount トークン シークレットは、Kubernetes バージョン >= v1.24 をサポートします。

アップグレード

ここで、クラスター内の Linkerd を最新バージョン 2.12 にアップグレードします。

まず、次のコマンドを実行して Linkerd CLI ツールを更新する必要があります。 

 $ curl -- proto '=https' -- tlsv1 .2 - sSfL https://run.linkerd.io/install |シュ

これにより、ローカル CLI が最新バージョンにアップグレードされます。もちろん、Linkerd のリリース ページから、対応するプラットフォームの CLI インストール パッケージを直接ダウンロードすることもできます。 

 $ wget https://github.91chi.fun/https://github.com//linkerd/linkerd2/releases/download/stable-2.12.0/linkerd2-cli-stable-2.12.0-darwin-arm64
 $ sudo mv linkerd2 -cli -stable - 2.12.0 - darwin - arm64 / usr / local / bin / linkerd
 $ chmod + x / usr / local / bin / linkerd

CLI が正しくインストールされ、実行されていることを確認します。 

 $ linkerd バージョン
クライアントバージョン: 安定版- 2.12.0
 サーバーバージョン: 安定版- 2.11.1

CLI アップグレードが成功したことがわかります。コントロールプレーンはまだアップグレードされていないため、現在のバージョン 2.11.1 が引き続き表示されます。

これで、Kubernetes クラスター上の Linkerd コントロール プレーンをアップグレードできます。心配しないでください。既存のデータ プレーンは、コントロール プレーンの更新されたバージョンで引き続き実行され、メッシュ サービスが失敗することはありません。

viz プラグインに付属する Prometheus コンポーネントを使用している場合、アップグレード後にデータが失われます。外部 Prometheus を構成する場合、この問題を心配する必要はありません。

Linkerd SMI 拡張

CLI を使用して Linkerd 2.11.x をインストールし、TrafficSplit CRD を使用している場合は、TS CRD が不足していることに注意する必要があります。この CRD を使用していない場合は、この通知を無視できます。

TrafficSplit CRD は Linkerd 2.12.0 には同梱されなくなり、代わりに Linkerd SMI 拡張機能によって提供されるようになりました。

まず、リリース ページから対応する実行可能パッケージをダウンロードします。 

 $ wget https://github.91chi.fun/https://github.com//linkerd/linkerd-smi/releases/download/v0.2.0/linkerd-smi-0.2.0-darwin-arm64
 $ chmod + x linkerd - smi - 0.2.0 - darwin - arm64
 $ sudo mv linkerd - smi - 0.2.0 - darwin - arm64 / usr / local / bin / linkerd - smi
 $ linkerd - smi バージョン
v0.2.0

Linkerd SMI は CLI ツール経由でインストールすることもできます。この拡張機能には、SMI リソースをネイティブ Linkerd リソースに変換する SMI アダプターが含まれています。 

 $ linkerd smi をインストール| kubectl を適用-f -
 $ linkerd smi チェック

あるいは、次の Helm メソッドを使用して Linkerd SMI 拡張機能をインストールすることもできます。ただし、拡張機能をインストールする前に、linkerd-smi チャートがそれを取得できるように、CRD に次の注釈とタグを追加する必要があります。 

 $ kubectl annotate -- crd / trafficsplits を上書きします。 スプリット。 smi スペック。 io \
 メタ。 ヘルム。 sh / リリース- 名前= linkerd - smi \
 meta.helm.sh/release-namespace=linkerd-smi
 #smi リポジトリウェアハウスを追加
$ helm リポジトリにl5d - smi を追加しますhttps://linkerd.github.io/linkerd-smi
 $ helm アップグレード-- linkerd - smi -n をインストールlinkerd - smi -- 名前空間l5d - smi / linkerd - smi を作成します
リリース「linkerd-smi」がアップグレードされました。 ヘルミングを楽しんでください！
 名前: linkerd - smi
 最終デプロイ日: 2022年9月11日( 日) 14:54:02
 名前空間: linkerd - smi
 ステータス: 展開済み
改訂: 1
 テストスイート: なし
注記:
 Linkerd SMI 拡張機能が正常にインストールされました🎉
 $ kubectl get pods -n linkerd -smi を実行します。
 名前準備完了ステータス再起動年齢
名前空間- メタデータ-- 1 - jnttx 0 / 1 完了0 17 分
smi - アダプタ- 5788 b875d4 - r4b7w 2 / 2 実行中6 ( 5 分53秒前) 17 分

最後に、通常の CLI アップグレード手順を続行できますが、TrafficSplit CRD が削除されないように、linkerd upgrade --crds の出力を適用するときに --prune フラグを使用しないでください。

アップグレード

次に、linkerd アップグレード コマンドを使用してコントロール プレーンを直接アップグレードします。これにより、コントロール プレーンの既存の構成と mTLS がすべて保持されます。 

 $ kubectl でcrd を取得します| grep リンク
サーバー認証。 ポリシー。 リンクされました。 2022-08-19 T04 : 06 : 33Z ...
 サーバー。 ポリシー。 リンクされました。 2022-08-19 T04 : 06 : 33Z ...
 サービスプロファイル。 リンクされました。 イオ2022-08-19 T04 : 06 : 33Z
 linkerd をアップグレードします--crds | \
 kubectl apply --prune -l linkerd を実行します。 io / コントロールプレーン- ns = linkerd \ ​
 --prune - ホワイトリスト= apiextensions.k8s.io / v1 / カスタムリソース定義\
 --prune - ホワイトリスト= split.smi-spec.io / v1alpha2 / トラフィックスプリット\
 -f-
 カスタムリソース定義。 api拡張機能。 k8s 。 io / 認証ポリシー。 ポリシー。 リンクされました。 io 作成
カスタムリソース定義。 api拡張機能。 k8s 。 io / httproutes 。 ポリシー。 リンクされました。 io 作成
カスタムリソース定義。 api拡張機能。 k8s 。 io / meshtlsauthentications 。 ポリシー。 リンクされました。 io 作成
カスタムリソース定義。 api拡張機能。 k8s 。 io / ネットワーク認証。 ポリシー。 リンクされました。 io 作成
カスタムリソース定義。 api拡張機能。 k8s 。 io / サーバー認証。 ポリシー。 リンクされました。 io 設定済み
カスタムリソース定義。 api拡張機能。 k8s 。 io / サーバー。 ポリシー。 リンクされました。 io 設定済み
カスタムリソース定義。 api拡張機能。 k8s 。 io / サービスプロファイル。 リンクされました。 io 設定済み
カスタムリソース定義。 api拡張機能。 k8s 。 io / トラフィック分割。 スプリット。 smi スペック。 io 設定済み

上記の更新コマンドでは --prune フラグを使用していることに注意してください。これにより、新しいバージョンには存在しない以前のバージョンの Linkerd リソースが削除されます。上記では、CRD リソースの新しいバージョンを更新しています。 Gateway API が導入されたため、4 つの新しい CRD が追加されたことがわかります。 

 $ kubectl でcrd を取得します| grep リンク
承認ポリシー。 ポリシー。 リンクされました。 2022-09-11 T02 : 56 : 13Z 2022-09-11 T02 : 56 : 13Z
 httpルート。 ポリシー。 リンクされました。 2022-09-11 T02 : 56 : 13Z 2022-09-11 T02 : 56 : 13Z
 メッシュTLS認証。 ポリシー。 リンクされました。 2022-09-11 T02 : 56 : 14Z 2022-09-11 T02 : 56 : 14Z
 ネットワーク認証。 ポリシー。 リンクされました。 2022-09-11 T02 : 56 : 14Z 2022-09-11 T02 : 56 : 14Z
 サーバー認証。 ポリシー。 リンクされました。 2022-08-19 T04 : 06 : 33Z ...
 サーバー。 ポリシー。 リンクされました。 2022-08-19 T04 : 06 : 33Z ...
 サービスプロファイル。 リンクされました。 イオ2022-08-19 T04 : 06 : 33Z

ただし、新しく追加された Gateway API 関連の CRD は、元の Kubernetes の下に定義されておらず、policy.linkerd.io グループの下にも定義されていることに注意してください。これは、Linkerd もこれらの CRD にいくつかの適応を行ったためです。

次に、次のコマンドを直接使用して、コントロール プレーン リソース オブジェクトを更新します。 

 $ linkerd アップグレード| \
 kubectl apply --prune -l linkerd を実行します。 io / コントロールプレーンns = linkerd f - ​ ​ ​

次に、このコマンドを再度実行し、クラスター全体の特定のリソースが適切にプルーニングされるようにするために必要な --prune-whitelist フラグをいくつか追加します。 

 $ linkerd アップグレード| kubectl apply --prune -l linkerd を実行します。 io / コントロールプレーン- ns = linkerd \ ​
 --prune - ホワイトリスト= rbac.authorization.k8s.io / v1 / clusterrole \
 --prune - ホワイトリスト= rbac.authorization.k8s.io / v1 / clusterrolebinding \
 --prune - ホワイトリスト= apiregistration.k8s.io / v1 / apiservice - f-

アップグレード プロセスが完了したら、チェック コマンドを実行して、すべてがうまくいったかどうかを確認することもできます。 

 $ linkerd チェック

このコマンドは、コントロール プレーンに対して一連のチェックを実行し、コントロール プレーンが適切に機能していることを確認します。

ここで、Linkerd のバージョンを再度確認すると、通常のサーバー バージョンも更新されています。 

 $ linkerd バージョン
クライアントバージョン: 安定版- 2.12.0
 サーバーバージョン: 安定版- 2.12.0

その後、データ プレーンをアップグレードできます。これを行う最も簡単な方法は、サービス上でローリング デプロイメントを実行し、プロキシ インジェクターが最新バージョンのプロキシを利用可能になったときに挿入できるようにすることです。 

 $ kubectl -n < 名前空間> ロールアウト再起動デプロイ

一般的に、コントロール プレーンの安定バージョンはデータ プレーンの以前の安定バージョンと互換性があるため、コントロール プレーンのアップグレード後はいつでもデータ プレーンをアップグレードできますが、1 つの安定バージョンのギャップを超えることは推奨されません。

更新が完了したら、チェック コマンドを使用してデータ プレーンのステータスを確認できます。 

 $ linkerd チェック--proxy
 # ......
 linkerd - データ- プレーン
------------------
 √ データプレーン名前空間が存在する
√ データプレーンプロキシが準備完了
‼ データプレーンは最新です​ ​ ​
 一部のプロキシは現在のバージョンを実行していません:
 * 絵文字- 696 d9d8f95-5 vn9w ( 安定版- 2.11.1 )
 * 投票- ボット- 646 b9fd6fd - 8 xj2j ( 安定版- 2.11.1 )
 * 投票- ff4c54b8d - xhjv7 ( 安定版- 2.11.1 )
 * ウェブ- 5f 86686 c4d - 58 p7k ( 安定版- 2.11.1 )
 * web - svc - 2 - f9d77474f - vxlrh ( 安定版- 2.11.1 )
 * イングレス- nginx - コントローラー- f56c7f6fd - rxhrs ( 安定版- 2.11.1 )
 ヒントについては、 https://linkerd.io/2.12/checks/#l5d-data-plane-version を参照してください。
 ‼ データプレーンとCLI のバージョンが一致
emoji - 696 d9d8f95 - 5 vn9wは安定版- 2.11 .1 で実行されていますが、 cli は安定版- 2.12 .0 で実行されています
ヒントについては、 https://linkerd.io/2.12/checks/#l5d-data-plane-cli-version を参照してください。
 √ データプレーンポッドラベルが正しく構成されている
√ データプレーンサービスラベルが正しく構成されている
√ データプレーンサービスアノテーションが正しく構成されている
√ 不透明なポートは適切に注釈が付けられている

Linkerd 拡張機能のチェック
=========================

 - smi 拡張チェックを実行中

このコマンドは、一連のチェックを通じてデータ プレーンが適切に実行されていることを確認し、古いバージョンのプロキシをまだ実行しているポッドを一覧表示します。その後、実際の状況に応じて対応するポッドをアップグレードできます。

Linkerd Viz 拡張機能

注目すべきもう 1 つの点は、viz プラグインです。最新バージョンでは Grafana が組み込まれなくなったため、ここではまずプラグインを直接アンインストールし (プラグインはグリッドのコア機能に影響を与えません)、その後最新バージョンを再インストールします。 

 $ linkerd viz をインストール| kubectl 削除-f -

アンインストール後、再インストールしてください。新しいバージョンには Grafana が組み込まれていないため、再インストール時に --set grafana.url を介して外部 Grafana アドレスを指定できます (クラスター外部のアドレスの場合は、grafana.externalUrl パラメータを介して指定できます)。外部の Prometheus を使用することもできます。 

 $ linkerd viz install -- set grafana 。 url = grafana : 3000 、 prometheusUrl = http : //prometheus.kube-mon.svc.cluster.local:9090,prometheus.enabled=false | kubectl を適用 -f -

再インストール後、次のポッド リストを確認します。 

 $ kubectl get pods - n linkerd - viz
 名前準備完了ステータス再起動年齢
メトリクス- api - 674 bf48d7f - kzr5b 2 / 2 実行中0 17 m
 タップ- 67 d6d8ff4d - q7nqn 2 / 2 ランニング0 5 m21s
 タップ- インジェクター- 7 c565f754 - jgvc5 2 / 2 実行中0 5 m20s
 ウェブ- 87 b958bcf - d5pfp 2 / 2 実行中0 5 分20秒

外部の Prometheus に接続されており、新しいバージョンには Grafana が組み込まれていないため、Grafana と Prometheus が使用できなくなっていることがわかります。上記で指定した Grafana アドレスは viz と同じ名前空間にあるため、ここで手動でインストールするだけです。

1 つの Grafana インスタンスが複数の Linkerd を指している場合は、各 Linkerd インスタンスの grafana.uidPrefix 設定で構成できる UID の異なるプレフィックスによってダッシュボードを分離できます。

ここでは、以下に示すように、Helm Chart を直接使用して値ファイルをインストールおよびカスタマイズします。 

 ポッド注釈:
 linkerd.io/inject:enabled
 grafana.ini :
 サーバー:
 root_url : "%(プロトコル)s://%(ドメイン)s:/grafana/"
 認証:
 ログインフォームを無効にする: true
 認証。 匿名：
 有効: true
 org_role : 編集者
認証。 基本：
 有効: false
 分析:
 更新の確認: false
 パネル:
 無効化_sanitize_html : 有効
ログ:
 モード: コンソール
ログ。 コンソール:
 フォーマット: テキスト
レベル: 情報
データソース:
 データソース。 yaml :
 apiバージョン: 1
 データソース:
 - 名前: プロメテウス
タイプ: プロメテウス
アクセス: プロキシ
組織ID : 1
 URL : http : //prometheus.kube-mon.svc.cluster.local:9090
 isDefault : 真
jsonデータ:
 時間間隔: "5秒"
 編集可能: true
 ダッシュボードプロバイダー:
 ダッシュボードプロバイダー。 yaml :
 apiバージョン: 1
 プロバイダー:
 - 名前: "デフォルト"
 組織ID : 1
 フォルダ: ""
 タイプ: ファイル
削除を無効にする: false
 編集可能: true
 オプション:
 パス: / var / lib / grafana / dashboards / default
 ダッシュボード:
 デフォルト：
 # これらのチャートはすべてhttps://grafana.com/grafana/dashboards/{id } でホストされています
トップライン:
 ネットID : 15474
 改訂: 3
 データソース: プロメテウス
健康：
 ネットID : 15486
 改訂: 2
 データソース: プロメテウス
Kubernetes : :
 ネットID : 15479
 改訂: 2
 データソース: プロメテウス
名前空間:
 ネットID : 15478
 改訂: 2
 データソース: プロメテウス
展開:
 ネットID : 15475
 改訂: 5
 データソース: プロメテウス
ポッド:
 ネットID : 15477
 改訂: 2
 データソース: プロメテウス
サービス：
 ネットID : 15480
 改訂: 2
 データソース: プロメテウス
ルート:
 ネットID : 15481
 改訂: 2
 データソース: プロメテウス
権限：
 ネットID : 15482
 改訂: 2
 データソース: プロメテウス
cronジョブ:
 ネットID : 15483
 改訂: 2
 データソース: プロメテウス
仕事：
 ネットID : 15487
 改訂: 2
 データソース: プロメテウス
デーモンセット:
 ネットID : 15484
 改訂: 2
 データソース: プロメテウス
レプリカセット:
 ネットID : 15491
 改訂: 2
 データソース: プロメテウス
ステートフルセット:
 ネットID : 15493
 改訂: 2
 データソース: プロメテウス
レプリケーションコントローラ:
 ネットID : 15492
 改訂: 2
 データソース: プロメテウス
プロメテウス:
 ネットID : 15489
 改訂: 2
 データソース: プロメテウス
プロメテウス- ベンチマーク:
 ネットID : 15490
 改訂: 2
 データソース: プロメテウス
マルチクラスター:
 ネットID : 15488
 改訂: 2
 データソース: プロメテウス

上記の値ファイルでは、Linkerd のプロキシを挿入するために linkerd.io/inject: enabled アノテーションを挿入し、Prometheus データ ソース アドレスも構成する必要があります。 

 $ helm リポジトリ追加grafana https://grafana.github.io/helm-charts
 $ helm アップグレード-- grafana -n linkerd -viz grafana / grafana -f values ​​.yaml をインストールします

すでに外部 Grafana がある場合は、インストール時に grafana.externalUrl を介して直接指定できます。 

 $ linkerd viz install -- set grafana 。 外部 URL = http://192.168.0.106:30403、prometheusUrl=http://prometheus.kube-mon.svc.cluster.local:9090、prometheus.enabled=false | kubectl を適用 -f -

アップデート後、Linkerd 関連のダッシュボードを外部 Grafana にインポートすることを忘れないでください。これは、Grafana の公式 Web サイト https://grafana.com/orgs/linkerd から入手できます。

たとえば、デプロイメント ダッシュボードをインポートする場合、ID 15475 をインポートするか、JSON ファイルをダウンロードしてインポート用にアップロードすることができます。

インポート後、Viz のダッシュボードを再度確認します。

同様に、ページ上の Grafana アイコンをクリックすると、Grafana ダッシュボード ページに直接ジャンプします。

この時点で、Linkerd のアップグレードは完了です。

<<:  Linkerd と Ingress-Nginx の組み合わせとサービスへのアクセス制限

>>:  クラウドコンピューティングでマルチテナントを実装する方法

推薦する

Tencent の 3 つのソーシャル広告のコツを使えば、簡単に始めることができ、インターネット スタートアップへの道はもはや困難ではありません。

2018年最もホットなプロジェクト：テレマーケティングロボットがあなたの参加を待っています今はトラフ...

#ブラックフライデー#: hostmonster-すべてのホストが月額3.95ドルから

Hostmonster も今年のブラックフライデーにプロモーションを実施しました。11 月 27 日...

クラウド ストレージの価格: 主要プロバイダーの比較

企業にとって、クラウド ストレージの価格を見積もることは複雑になる場合があります。さらに、業界をリー...

JD Financeのアプリケーション中心のDevOpsシステム構築

DevOps は、アジャイル、スクラム、XP から進化し、運用と保守の分野にまで広がった新しい動きで...

sharktech: 米国の高防御 VPS/オランダの高防御 VPS、年間 29.7 ドルから、2G メモリ/1 コア/40g SSD/4T トラフィック/60G 防御

SharkTech は、常に高度な防御力で有名です。デフォルトで 60Gbps の無料 DDoS 防...

大規模クラウドネットワーク構築におけるSDNの課題

1. 大規模クラウドネットワークの課題1.1 ネットワーク単一点問題従来のクラウド ネットワークでは...

SEOサービスプロバイダーが生き残り続けるための簡単な分析

かつて、SEO は非常に人気のあるサービス産業でした。当時、Zac、Wang Tong、Zhang ...

クラウド変革を成功させるために考慮すべき重要な要素

クラウド コンピューティングは普及し、私たちの日常生活のあらゆる側面に大きな影響を与えています。ただ...

#ブラックフライデー#: ドメイン - 特別価格のドメイン、たくさん買ってもっと節約

domain.com の最新のブラック フライデー ドメイン名プロモーションが、合計 3 つの割引コ...

クラウド ERP とオンプレミス ERP: どちらが優れているか?

企業が新しい ERP システムを選択する際に最も重要な考慮事項の 1 つは、オンプレミスの ERP ...

滴滴出行と快滴行は過去2ヶ月で15億ドルを燃やした。彼らのゴッドファーザーであるテンセントとアリババは補助金を完全に停止しようと共謀した

滴滴出行と快滴行は過去2ヶ月で15億ドルを燃やした。彼らのゴッドファーザーであるテンセントとアリババ...

ロングテールによるシングルページTaobaoプロモーションのヒントを共有する

Taobao Affiliate に関しては、ウェブサイトを構築する学生の多くはよく知っていると思い...

NDRC：電子商取引企業3社が自己点検と是正を実施し、価格規制を策定する予定

国家発展改革委員会価格監督局の関係当局者はCCTVのインタビューで、電子商取引企業3社は要求に応じて...

Bilibili、iQiyi 広告およびコンテンツ IP

11月17日、ビリビリ（以下、「ビリビリ」）とiQiyiは、2019年9月30日までの第3四半期の財...

面接官は私に尋ねました。「分散トランザクションとは何ですか?」

[[403411]]取引トランザクションは、実際には誰にとっても、特にプログラマーにとっては馴染み深...