3.0つのことがますます明らかになっているのは、Web 3.0(別名「web3」)が間もなく登場し、2022年に完全に登場することを期待する人もいます。 Web 3.0はまた、インターネットのコアメカニズムの多くを変更することを約束します。 重要な要素の1つは地方分権化です。 今日のアプリケーションの多くは一元化されており、当局は1つのプライマリサーバーを介してデータを提供および管理していますが、Web 3.0アプリケーションは分散システムを活用します。
JTオリオ、マートンエレック、クリスタスプリッグスは、これらの傾向を分析しました 彼らのプレゼンテーション, 「DockerとWeb 3.0 — Dockerを使用して分散型インフラストラクチャを活用し、分散型アプリを構築します。」 したがって、彼らはコンテナ化とツーリングがこの移行をどのように容易にしたかについて議論しました。
また、分散型データの保存と使用についても独自の考慮事項があります。 それをどのように活用しますか? そのアプローチは、分散型ノードまたはフェデレーテッドシステムでどのように機能しますか? これにアプローチするための優れた方法の1つについて説明し、さらに簡単な別のユースケースの概要を説明します。 飛び込みましょう。
例 #1: ストレージバケットをディレクトリとして使用する
分散型アプリケーション(dApp)をデプロイするプロセスは、従来の方法とは少し異なります。 ユーザーは、複数のボランティア ノード (またはフェデレーション ストレージ ノード) に分散されたアプリ データにアクセスします。 分散されているため、このデータは厳密に委任されたアクセスを持つ中央サーバーには存在しません。
これには、ストレージノードとユーザー自身の間の共有ゲートウェイブリッジのようなものが必要です。 Martonが共有したように、この共有ブリッジはローカルブリッジとネイティブサポートでうまく機能します。 このソリューションは、Kubernetes でも使用でき、Krista はデモ #1 で説明しました。 ここでは、その例に取り組み、他のツールで同様の結果を達成する方法について説明します。
前提 条件
- アクティブな Kubernetes v1.13+ のデプロイ
- あなたのデータベース (PostgreSQLこの場合)
- 分散型クラウドストレージ(DCS)ソリューション
- The Container Storage Interface (CSI) for S3 ( ctrox による、GitHub 経由)
Kubernetes 1.13+ は、CSI との互換性のために必要です。 Postgresを使用すると、データを他のアクセス可能な場所に保存およびバックアップできるため、ユーザーにもメリットがあります。 DCS は、このバックアップの場所として機能します。 最良の部分は、これがあなたがすでに精通しているほとんどのアプリケーションで機能することです。
DCS バケットを Kubernetes コンテナ内にマウントする
ストレージを分散化するために、CSI for S3 を使用して、S3 エンドポイントではなく独自のゲートウェイをポイントします。 CSIの主な利点は、「バケットを動的に割り当て、ヒューズマウントを介して任意のコンテナにマウントする」ことができることです。
まず、Kubernetes (K8s) が必要です ストレージクラス YAML ファイルにエクスポートします。 Krista の例に従って、単純な構成ファイルを作成するには、いくつかのキー フィールドを指定する必要があります。 次のような要素を指定しながら apiVersion そして メタデータ 重要なので、いくつかの重要なフィールドに焦点を当てましょう。
プロビジョナー– 永続ボリュームのプロビジョニングに使用するボリュームプラグインを K8s に指示します。 この場合は、次のように指定します。 ch.ctrox.csi.s3-driver S3 の CSI をターゲットにします。 Kubernetesには多数の内部オプションが付属していますが、この外部オプションを示すことができます プロビジョナー プロジェクトでは、公式のK8sプロビジョニング仕様に従います。マウンター–ローカル、クラウド、または仮想ファイルシステムを選択したマシンのディスクとしてマウントするようにK8sに指示します。 クリスタは提唱しています rクローン、ここではそれを使用します。 クローン は、クラウドベースのファイルを管理するためのコマンドラインプログラムであり、Amazon S3やその他の40を超えるプラットフォームと統合する際に非常に重要です。 たとえば、Google Cloud、Digital Ocean Spaces、Microsoft Azure Blob Storage などをお勧めします。 ただし、この場合はS3を使用します。bucket–コアオブジェクトが格納されている場所をK8sに指示します。 バケットに一意の名前を付けます (任意の名前にすることができます)。
また、いくつかの秘密を引き出す必要があることに気付いたかもしれません。 これには、 シークレット.yml あなたの.envsを含むファイル(または同様の名前)です。 Kubernetes のドキュメント 次の定義書式を指定します。
apiVersion: v1
kind: secret
metadata:
name: mysecret
type: Opaque
stringData:
config.yaml:
apiUrl: "https://my.api.com/api/v1"
username: <user>
password: <password>
コマンドを使用して、指定したすべてのシークレット kubectl apply -f ./secret.yaml を作成できます。 さらに、コマンドを使用してシークレットが正常に kubectl get secret mysecret -o yaml 作成されたことを確認できます。 これにより、作成時刻、型、名前空間、およびリソースのバージョンに関連する有用な詳細が出力されます。 mysecret 構成ファイル内のメタデータ名と一致するように変更されることに注意してください。
データベースプロセスのセットアップ
次に、この演習では Postgres データベースを使用します。 したがって、 pg_dump すべてのデータベース オブジェクトをバックアップ ファイルに転送します。 この次の重要なステップは、アプリケーションが分散化されているにもかかわらず、このデータにアクセスするのに役立ちます。 [ ティッカー (copy)コマンドを、優先ディレクトリと組み合わせて、ターゲットDCSマウントを指定します。 ただし、別のプロジェクトでは、MariaDB、MySQL、または使い慣れたその他の主要なデータベーステクノロジーを使用することを選択できます。
アプリケーションは、DCS ボリューム内に含まれるデータにアクセスできます。
Cronジョブの定義
さらに、Postgres バックアップはアクティブなコンテナーとして存在するため、データの最新性を確保するために一貫して実行されます。 そこで、 クロンジョブ 入ってきます。 関連付けられた YAML ファイルが部分的に見えるようになります。
なぜなら クロンジョブ はスケジュールされたタスクであるため、実行する頻度を指定することが重要です。 この頻度は、 計画 畑。 クリスタは「アグレッシブな」毎分1回のクリップで実行するように仕事を設定していますが、もっと保守的なものを選ぶこともできます。 ポリシー、ユーザーのニーズ、および「最新の」データをプッシュすることの相対的な重要性は、この頻度を決定するのに役立ちます。
最後に、あなたに特別な注意を払ってください 環境 田畑。 これらを使用して、コンテナーの DNS エントリ ポイントを指定し、CSI の永続ボリューム要求に関連するマウント ポイントを選択します。
あなたを割り当てます PG_HOST その DNS エントリを指す適切な値。 おそらく使用する必要があります 拡張されたデータクエリ クリスタのように、これによりアクティブなPostgresサービスに効果的に連絡できます。
すべてをスピンアップ
すべての依存関係が整ったら、アプリケーションを実行し、ストレージが正しく接続されていることを確認します。 このプロセスを開始するには、 kubectl apply -f base 命令。 これにより、基本 K8s リソースが作成されます。
次に、サンプル アプリケーションを適用します。 StorageClass.yaml ファイル、Postgresバックアップシェルスクリプト、および クロンジョブ.を入力します kubectl apply -f ex コマンドで実行します。
インターフェイスには、次のことを確認する出力が表示されます。 クロンジョブ および CSI 永続ボリューム要求 (塩ビ) が作成されます。
最後に、さらにいくつかの手順を実行できます。
-
- を使用して Kubernetes イベントをテールする
kubectl get events --sort-by='.metadata.creationTimestamp' --時計命令。 これにより、PVC ボリュームが正常にプロビジョニングされ、バックアップ ジョブが開始されていることが確認されます。 - を使用して、コンテナーが実行中で作成されていることを確認します。
kubectl get pods命令。 - もう一度実行して、両方のコンテナーが意図したとおりに実行
kubectl get podsされていることを確認します。
- を使用して Kubernetes イベントをテールする
確認の最後のレイヤーとして、ログを調べて、すべてが適切に実行されていることを確認することもできます。 さらに、 uplink ls --access [accessgrant] 最新のデータベースバックアップを確認するコマンド。 アプリケーションを分散型ストレージに正常に接続できました。
alias k=kubectl 後に入力 kubectl k できます。
これは素晴らしいことですが、ネイティブ統合に依存する別のアプリケーションがある場合はどうでしょうか。 2番目の例を見てみましょう。
例 #2: Docker レジストリの使用
ドッカーレジストリ は、スケーラブルでステートレスなサーバー側アプリケーションであり、Docker イメージを格納および配布できます。 画像を好きなように共有したい場合や、画像ストレージを厳密に制御したい場合に便利です。
ありがたいことに、DCSのレジストリの設定は非常に簡単です。 レジストリ設定 YAML ファイル内で、次に示すように、DCS ベンダー、アクセス許可、バケットを含むストレージ セクションを指定します。
次に、を使用してレジストリを起動する必要があります registry serve cmd/registry/config-dev.yml 命令。 出力は次のようになります。
次に、選択した画像をプルします。 この例では、次のコマンドを使用して最新のものをプルします アルパイン 画像：
ドッカープルアルパイン:最新
Alpineイメージは、サイズが小さく、完全なパッケージリポジトリにアクセスできるため、望ましいものです。 ただし、必要に応じて、プロジェクトに適した別の画像を使用できます。 その後、次のことを行う必要があります この画像に一意の名前を付ける.これは後で役に立ちます。 そのイメージをレジストリにプッシュします。 docker push image.dcs.localhost:5000/alpine:[tag 名前] 命令。 このプロセスは、完了するまでレイヤーごとに行われます。
次に、アップリンクツールを使用して、すべてがレジストリ内にあることを確認します。 入る アップリンク ls --access [アクセスグラント] sj://registry/docker/registry/v2/repositories/alpine このプロセスをジャンプスタートするには、Alpineリポジトリのリストを呼び出します。
追加 / 後 アルパイン レイヤーやマニフェストなどの追加項目を一覧表示します。 タッキングオン _manifests/タグ タグディレクトリを解析します。
万丈！これで、Docker レジストリ用の分散型ストレージ ソリューションが正常に確立されました。
結論
Web 3.0の普及はますます強くなっています。 昨年だけでも、 34,000人以上の開発者が オープンソースのWeb 3.0プロジェクトに貢献しました。 したがって、分散型ストレージの恩恵を受けることができる多くの業界とユースケースがあります。 このニーズは、Web 3.0が標準になるにつれて高まるでしょう。 Dockerを利用して、ストレージメカニズムをより簡単に設定することもできます。 コンテナとWeb 3.0の分散化は重複しているため、Dockerベースと非Dockerベースの両方で、さらに多くのアプリケーションが同様のアプローチを採用するようになります。
メンテナンスなしでより簡単にリソースをホストしたいですか? Docker Hub プロジェクトとチームの画像のための一元化された共同ストレージを提供します。 イメージを Docker Hub にプッシュしてプルダウンできます。 Docker Hub は、 Docker Desktop 展開のシームレスな管理を容易にします。 次のdAppにDockerを活用することを計画している場合、Docker DesktopのGUIを使用すると、コンテナとアプリケーションの管理プロセスが簡素化されます。