K8Sの高度な機能を理解するための記事

K8Sの高度な機能を理解するための記事

K8Sの高度な機能

K8S には、アプリケーションの弾力的なスケーリング (上記参照)、ローリング アップデート (上記参照)、構成管理、ストレージ ボリューム、ゲートウェイ ルーティングなど、理解する価値のある高度な機能がいくつかあります。

これらの高度な機能を理解する前に、K8S のいくつかのコア概念を確認する必要があります。

レプリカセット

ReplicaSet は、指定された数の Pod レプリカが常に実行されることを保証します。通常、指定された数の同一ポッドの可用性を確保するために使用されます。 ReplicaSet を直接使用するのではなく、Deployment を使用して管理することをお勧めします。

構成マップ

ConfigMap は、機密性のないデータをキーと値のペアに保存するために使用される API オブジェクトです。使用すると、Pod はこれを環境変数、コマンドライン パラメーター、またはストレージ ボリューム内の構成ファイルとして使用できます。 ConfigMap を使用して、構成データをアプリケーション コードから分離します。

音量

ボリュームとは、ポッド内のコンテナがアクセスできるデータ ディレクトリが含まれるストレージ ボリュームを指します。コンテナ内のファイルは一時的にディスクに保存されます。コンテナがクラッシュすると、ファイルは失われます。また、複数の Pod 間でファイルを共有することはできません。この 2 つの問題は、ストレージ ボリュームを使用することで解決できます。
一般的に使用されるストレージ ボリュームは次のとおりです。

  • configMap: configMap ボリュームは、構成データを Pod に挿入する方法を提供します。 ConfigMap オブジェクトに保存されたデータは、configMap タイプのボリュームによって参照され、Pod で実行されているコンテナ化されたアプリケーションによって使用されます。
  • emptyDir: emptyDir ボリュームはキャッシュ データを保存するために使用できます。 Pod がノードにディスパッチされると、emptyDir ボリュームが作成され、Pod がノード上で実行されている間はボリュームが存在します。 Pod がノードから削除されると、emptyDir ボリューム内のデータも完全に削除されます。
  • hostPath: hostPath ボリュームは、ホスト ノード ファイル システム上のファイルまたはディレクトリを Pod にマウントできます。 Minikube のホストは、Minikube が配置されている仮想マシンを指します。
  • ローカル: ローカル ボリュームは、ディスク、パーティション、ディレクトリなどのマウントされたローカル デバイスを表します。ローカル ボリュームは静的に作成された永続ボリュームとしてのみ使用でき、動的構成はまだサポートされていません。
  • nfs: nfs ボリュームは NFS (ネットワーク ファイル システム) を Pod にマウントできます。
  • persistentVolumeClaim: persistentVolumeClaim ボリュームは、永続ボリューム (PersistentVolume) を Pod にマウントするために使用されます。永続ボリューム (PV) は、管理者が事前にプロビジョニングしたり、ストレージ クラスを使用して動的にプロビジョニングしたりできるクラスター内のストレージの一部です。永続ボリュームは、ノードに似たクラスター リソースです。

イングレス

Ingress は、K8S の Ingress リソースを通じて Nginx と同様のドメイン名ベースのアクセスを実装し、Pod への負荷分散アクセスを実現できます。

Ingress をインストールする

https://github.com/kubernetes/ingress-nginx/blob/nginx-0.20.0/deploy/mandatory.yaml のページに移動し、内容をコピーして、k8s マスター マシン上のファイル ingress-controller.yaml に保存します。その中のイメージ アドレスを変更する必要があります。次の yaml コンテンツを直接使用できます。

ダウンロードアドレス（ポイント不要）: ダウンロードアドレス

APIバージョン: v1
種類: 名前空間
メタデータ:
  名前: ingress-nginx
  ラベル:
    app.kubernetes.io/名前: ingress-nginx
    app.kubernetes.io/一部: ingress-nginx

---

種類: ConfigMap
APIバージョン: v1
メタデータ:
  名前: nginx-configuration
  名前空間: ingress-nginx
  ラベル:
    app.kubernetes.io/名前: ingress-nginx
    app.kubernetes.io/一部: ingress-nginx

---

種類: ConfigMap
APIバージョン: v1
メタデータ:
  名前: tcp-services
  名前空間: ingress-nginx
  ラベル:
    app.kubernetes.io/名前: ingress-nginx
    app.kubernetes.io/一部: ingress-nginx

---

種類: ConfigMap
APIバージョン: v1
メタデータ:
  名前: udp-services
  名前空間: ingress-nginx
  ラベル:
    app.kubernetes.io/名前: ingress-nginx
    app.kubernetes.io/一部: ingress-nginx

---

APIバージョン: v1
種類: サービスアカウント
メタデータ:
  名前: nginx-ingress-serviceaccount
  名前空間: ingress-nginx
  ラベル:
    app.kubernetes.io/名前: ingress-nginx
    app.kubernetes.io/一部: ingress-nginx

---

APIバージョン: rbac.authorization.k8s.io/v1beta1
種類: ClusterRole
メタデータ:
  名前: nginx-ingress-clusterrole
  ラベル:
    app.kubernetes.io/名前: ingress-nginx
    app.kubernetes.io/一部: ingress-nginx
ルール:
  -apiグループ:
      - 「」
    リソース：
      - 構成マップ
      - エンドポイント
      - ノード
      - ポッド
      - 秘密
    動詞:
      - リスト
      - 時計
  -apiグループ:
      - 「」
    リソース：
      - ノード
    動詞:
      - 得る
  -apiグループ:
      - 「」
    リソース：
      - サービス
    動詞:
      - 得る
      - リスト
      - 時計
  -apiグループ:
      - 「拡張機能」
    リソース：
      - 入口
    動詞:
      - 得る
      - リスト
      - 時計
  -apiグループ:
      - 「」
    リソース：
      - イベント
    動詞:
      - 作成する
      -パッチ
  -apiグループ:
      - 「拡張機能」
    リソース：
      - 入力/ステータス
    動詞:
      - アップデート

---

APIバージョン: rbac.authorization.k8s.io/v1beta1
種類: 役割
メタデータ:
  名前: nginx-ingress-role
  名前空間: ingress-nginx
  ラベル:
    app.kubernetes.io/名前: ingress-nginx
    app.kubernetes.io/一部: ingress-nginx
ルール:
  -apiグループ:
      - 「」
    リソース：
      - 構成マップ
      - ポッド
      - 秘密
      - 名前空間
    動詞:
      - 得る
  -apiグループ:
      - ""
    リソース：
      - 構成マップ
    リソース名:
      # デフォルトは「<election-id>-<ingress-class>」
      # ここでは: "<ingress-controller-leader>-<nginx>"
      # いずれかのパラメータを変更する場合はこれを調整する必要があります
      # nginx-ingress-controller を起動するとき。
      - 「イングレス コントローラー リーダー nginx」
    動詞:
      - 得る
      - アップデート
  -apiグループ:
      - 「」
    リソース：
      - 構成マップ
    動詞:
      - 作成する
  -apiグループ:
      - 「」
    リソース：
      - エンドポイント
    動詞:
      - 得る

---

APIバージョン: rbac.authorization.k8s.io/v1beta1
種類: RoleBinding
メタデータ:
  名前: nginx-ingress-role-nisa-binding
  名前空間: ingress-nginx
  ラベル:
    app.kubernetes.io/名前: ingress-nginx
    app.kubernetes.io/一部: ingress-nginx
ロールリファレンス:
  apiグループ: rbac.authorization.k8s.io
  種類: 役割
  名前: nginx-ingress-role
科目:
  - 種類: サービスアカウント
    名前: nginx-ingress-serviceaccount
    名前空間: ingress-nginx

---

APIバージョン: rbac.authorization.k8s.io/v1beta1
種類: ClusterRoleBinding
メタデータ:
  名前: nginx-ingress-clusterrole-nisa-binding
  ラベル:
    app.kubernetes.io/名前: ingress-nginx
    app.kubernetes.io/一部: ingress-nginx
ロールリファレンス:
  apiグループ: rbac.authorization.k8s.io
  種類: ClusterRole
  名前: nginx-ingress-clusterrole
科目:
  - 種類: サービスアカウント
    名前: nginx-ingress-serviceaccount
    名前空間: ingress-nginx

---

APIバージョン: アプリ/v1
種類: DaemonSet
メタデータ:
  名前: nginx-ingress-controller
  名前空間: ingress-nginx
  ラベル:
    app.kubernetes.io/名前: ingress-nginx
    app.kubernetes.io/一部: ingress-nginx
仕様:
  セレクタ：
    一致ラベル:
      app.kubernetes.io/名前: ingress-nginx
      app.kubernetes.io/一部: ingress-nginx
  テンプレート：
    メタデータ:
      ラベル:
        app.kubernetes.io/名前: ingress-nginx
        app.kubernetes.io/一部: ingress-nginx
      注釈:
        prometheus.io/ポート: "10254"
        prometheus.io/scrape: "true"
    仕様:
      ホストネットワーク: true
      サービスアカウント名: nginx-ingress-serviceaccount
      コンテナ:
        - 名前: nginx-ingress-controller
          イメージ: siriuszg/nginx-ingress-controller:0.20.0
          引数:
            - /nginx-イングレスコントローラー
            - --configmap=$(POD_NAMESPACE)/nginx-configuration
            - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services
            - --udp-services-configmap=$(POD_NAMESPACE)/udp-services
            - --publish-service=$(POD_NAMESPACE)/ingress-nginx
            - --annotations-prefix=nginx.ingress.kubernetes.io
          セキュリティコンテキスト:
            権限昇格を許可: true
            機能:
              落とす：
                - 全て
              追加：
                -NET_BIND_SERVICE
            # wwwデータ -> 33
            実行ユーザー: 33
          環境:
            - 名前: POD_NAME
              値:
                フィールド参照:
                  フィールドパス: metadata.name
            - 名前: POD_NAMESPACE
              値:
                フィールド参照:
                  フィールドパス: metadata.namespace
          ポート:
            - 名前: http
              コンテナポート: 80
            - 名前: https
              コンテナポート: 443
          ライブネスプローブ:
            失敗しきい値: 3
            httpGet:
              パス: /healthz
              ポート: 10254
              スキーム: HTTP
            初期遅延秒数: 10
            期間秒数: 10
            成功しきい値: 1
            タイムアウト秒数: 1
          準備プローブ:
            失敗しきい値: 3
            httpGet:
              パス: /healthz
              ポート: 10254
              スキーム: HTTP
            期間秒数: 10
            成功しきい値: 1
            タイムアウト秒数: 1

---

APIバージョン: v1
種類: サービス
メタデータ:
  名前: ingress-nginx
  名前空間: ingress-nginx
仕様:
  ポート:
    - 名前: http
      ポート: 80
      ターゲットポート: 80
      プロトコル: TCP
    - 名前: https
      ポート: 443
      ターゲットポート: 443
      プロトコル: TCP
  セレクタ：
    app.kubernetes.io/名前: デフォルトのhttp-backend
    app.kubernetes.io/一部: ingress-nginx

---

インストールが成功したか確認する

kubectl get pods -n ingress-nginx -o ワイド

Ingress アクセス ルールを構成して (nginx プロキシ転送構成を構成するのと同様)、Ingress がドメイン名 tomcat.core.com をバックエンドの tomcat-service-yaml サービスに転送できるようにします。次の内容を含む新しいファイル ingress-tomcat.yaml を作成します。

APIバージョン: networking.k8s.io/v1beta1
種類: イングレス
メタデータ:
 名前: web-ingress
仕様:
 ルール:
 - ホスト: tomcat.core.com # 転送ドメイン名 http:
    パス:
    - パス：​​ /
      バックエンド: 
       サービス名: tomcat-service-yaml
       servicePort: 80 # サービスポート

有効なイングレス ルールを表示します。

kubectl 取得

アクセス マシン上のホストを構成し、マスター ディレクトリ: /etc/hosts で、ホストに次のホストを追加します (Ingress によってデプロイされたマシン IP は、アクセスするドメイン名に対応します)

192.168.159.131 コア
または 192.168.159.132 tomcat.core.com

設定後、クライアント ブラウザーで http://tomcat.core.com/ に直接アクセスして、通常どおり Tomcat にアクセスします。

高度な機能

構成管理

ConfigMap を使用すると、構成ファイルをイメージ ファイルから分離して、コンテナー化されたアプリケーションを移植可能にすることができます。次に、ConfigMap のプロパティを Pod の環境変数に挿入する方法を示します。

ConfigMap を作成するには、設定ファイル nginx-config.yaml を追加します。ConfigMap の名前は nginx-config で、ストレージ情報はデータ ノードの下に配置されます。

APIバージョン: v1
種類: ConfigMap
メタデータ: 
 名前: nginx-config
 名前空間: デフォルト
データ：
 nginx-env:テスト

nginx-config.yaml ファイルを適用して ConfigMap を作成します。

kubectl 作成 -f nginx-config.yaml

すべてのConfigMapを取得します。

kubectl 設定マップを取得する

ConfigMap の内容を yaml 形式で表示します。

kubectl get configmaps nginx-config -o yaml

構成ファイル nginx-deployment.yaml を追加して、デプロイメントを作成し、nginx サービスをデプロイし、Nginx 環境変数の ConfigMap 内のプロパティを参照します。

APIバージョン: アプリ/v1
種類: デプロイメント
メタデータ: 
 名前: nginx-deployment
 ラベル:
  アプリ: nginx
仕様:
 レプリカ: 1
 セレクタ：
  一致ラベル:
   アプリ: nginx
 テンプレート：
  メタデータ:
   ラベル:
    アプリ: nginx
  仕様:
   コンテナ:
    - 名前: nginx
      イメージ: nginx:1.10
      ポート:
       - コンテナポート: 80
      環境:
       - name: NGINX_ENV # Nginx で環境変数を設定します valueFrom:
          configMapKeyRef:
           name: nginx-config # ConfigMapの名前を設定します key: nginx-env # 取得するキー

構成ファイルを適用してデプロイメントを作成します。

kubectl を適用 -f nginx-deployment.yaml

作成が成功したら、Pod 内の環境変数を確認し、NGINX_ENV 変数が挿入されていることを確認します。

kubectl get pod -o ワイド


kubectl exec -it nginx-deployment-5ff74658b6-rlft8 --sh
# コンテナコンソールに入り、次のコマンドを実行します ECHO $NGINX_ENV

ストレージボリュームの使用状況

ストレージ ボリュームを使用すると、外部データをコンテナーにマウントして、コンテナー内のアプリケーションからアクセスできるようにすることができます。これにより、コンテナーがクラッシュしても、データは存在し続けることができます。

以前、Docker を使用して Nginx をデプロイしたときに、Nginx の html、logs、conf ディレクトリを外部からコンテナーにマウントしたことを思い出してください。

docker run -p 80:80 --name nginx \
-v /mydata/nginx/html:/usr/share/nginx/html \
-v /mydata/nginx/logs:/var/log/nginx \
-v /mydata/nginx/conf:/etc/nginx \
-d nginx:1.10

Minikubeは仮想マシンとみなすことができます。Minikubeのsshコマンドを使用してアクセスできます。

ミニキューブSSH

Minikube にはデフォルトで docker ユーザーが存在します。まずはそのパスワードをリセットしましょう。

sudo パスワード docker

Minikubeにmydataディレクトリを作成する

mkdir /home/docker/mydata

ディレクトリをマウントするには、nginx ディレクトリを Minikube にコピーする必要があります。docker ユーザーは /home/docker ディレクトリ内のファイルのみを変更できることに注意してください。scp コマンドを使用してファイルをコピーします。

scp -r /home/macro/mydata/nginx [email protected]:/home/docker/mydata/nginx

デプロイメントを作成するには、設定ファイル nginx-volume-deployment.yaml を追加します。

APIバージョン: アプリ/v1
種類: デプロイメント
メタデータ: 
 名前: nginx-ボリュームデプロイメント
 ラベル:
  アプリ: nginx
仕様:
 レプリカ: 1
 セレクタ：
  一致ラベル:
   アプリ: nginx
 テンプレート：
  メタデータ:
   ラベル:
    アプリ: nginx
  仕様:
   コンテナ:
    - 名前: nginx
      イメージ: nginx:1.10
      ポート:
       - コンテナポート: 80
      ボリュームマウント:
       - マウントパス: /usr/share/nginx/html
         名前: html-ボリューム
       -マウントパス: /var/logs/nginx
         名前: ログボリューム
       - マウントパス: /etc/nginx
         名前: conf-volume
   ボリューム:
    - 名前: html-ボリューム
      ホストパス:
       パス: /home/docker/mydata/nginx/html
       タイプ: ディレクトリ
    - 名前: ログボリューム
      ホストパス:
       パス: /home/docker/mydata/nginx/logs
       タイプ: ディレクトリ
    - 名前: conf-volume
      ホストパス:
       パス: /home/docker/mydata/nginx/conf
       タイプ: ディレクトリ

構成ファイルを適用してデプロイメントを作成する

kubectl を適用 -f nginx-ボリューム-デプロイメント.yaml

サービスを作成するために設定ファイルnginx-service.yamlを追加します。

APIバージョン: v1
種類: サービス
メタデータ: 
 名前: nginx-service
仕様:
 タイプ: NodePort
 セレクタ：
  アプリ: nginx
 ポート:
 - 名前: http
    プロトコル: TCP
    ポート: 80
    ターゲットポート: 80
    ノードポート: 30080

サービスアクセスポートを確認する

kubectl サービスを取得する

CURL コマンドを使用して Nginx ホームページ情報にアクセスします。

要約する

サービスはK8Sサービスの核であり、サービスの詳細をシールドし、サービスインターフェースを統一的に外部に公開することで、真の「マイクロサービス」を実現します。たとえば、サービス A には 3 つのバックアップ、つまり 3 つの Pod がデプロイされています。ユーザーは、1 つのサービスの入り口に注意するだけでよく、どの Pod を要求するかを心配する必要はありません。利点は非常に明白です。一方では、外部ユーザーは、Pod 上のサービスの予期しないクラッシュや K8S による Pod の再プルによって引き起こされる IP 変更を意識する必要がありません。また、外部ユーザーは、サービスのアップグレードや変更による Pod の置き換えによって引き起こされる IP 変更を意識する必要もありません。他方では、サービスはトラフィックの負荷分散も実行できます。

ただし、サービスは主に K8S クラスター内のネットワーク トポロジを担当します。では、クラスターの外部からクラスターの内部にアクセスするにはどうすればよいでしょうか?このとき、Ingress が必要になります。公式ドキュメントでの説明は次のとおりです。

Ingress は、クラスター内のサービスへの外部アクセスを管理する API オブジェクトです。一般的なアクセス方法は HTTP です。

ngress は、負荷分散、SSL 終了、名前ベースの仮想ホスティングを提供できます。

翻訳: Ingress は、K8S クラスター全体、複雑なクラスターの内部および外部通信のアクセス レイヤーです。

Ingress と Service のネットワーク トポロジ図は次のとおりです。

kubectl サービスの問題のトラブルシューティング

K8S でのサービス展開の失敗をトラブルシューティングするにはどうすればよいですか?

次のコマンドを使用します:

kubectl は ${リソース} ${名前} を記述します。

最後までスクロールして「イベント」セクションを確認します。このセクションには、このサービスのデプロイ プロセスにおける K8S の主要なログが表示されます。

一般的に、デプロイメントの失敗のほとんどは、kubectl describe pod ${POD_NAME} を通じて見つけることができます。もちろん、特定の問題には特定の分析が必要です。

K8S にデプロイされた異常なサービスをトラブルシューティングするにはどうすればよいですか?

サービスが正常にデプロイされ、ステータスが実行中の場合は、Pod 内のコンテナにアクセスしてサービス ログを表示する必要があります。

Pod 内のコンテナによって出力されたログを表示します。

kubectl log ${POD_NAME} -c ${CONTAINER_NAME} を実行します。

Pod 内にコンテナを入力します。

kubectl exec ‐it [オプション] ${POD_NAME} ‐c ${CONTAINER_NAME} [引数]

このコマンドの目的は、kubectl を介して docker exec xxx を実行し、コンテナ インスタンスに入ることです。その後、ユーザーは自分のサービスのログをチェックして問題を特定します。

K8S は本当に Docker を放棄したのでしょうか?

Docker は非常に人気のあるコンテナ技術です。K8S によって廃止され、別のコンテナ技術である containerd に置き換えられたという記事が数多くあります。実際、containerd は Docker から分離された基盤となるコンテナ ランタイムにすぎません。使い方は Docker と変わりません。Docker から containerd への移行は非常に簡単で、基本的に制限はありません。 基本的には、先ほどの Docker コマンドの docker を crictl に変更するだけで完了です。どちらも同じ会社が開発しており、使い方も同じです。したがって、K8S が Docker を放棄するかどうかに関係なく、開発者には基本的に影響はありません。

K8S クリ

K8S は、コンテナ ランタイム インターフェースを統一した CRI (Container Runtime Interface) をリリースしました。CRI をサポートするコンテナ ランタイムはすべて、K8S の基盤となるコンテナ ランタイムとして使用できます。

K8S がコンテナランタイムとして Docker を放棄し、containerd を使用するのはなぜですか?

K8S コンテナ ランタイムとして Docker を使用する場合、kubelet は最初に dockershim を介して Docker を呼び出し、次に Docker を介して containerd を呼び出す必要があります。

K8S コンテナ ランタイムとして containerd を使用する場合、containerd には CRI プラグインが組み込まれているため、kubelet は containerd を直接呼び出すことができます。
containerd を使用すると、パフォーマンスが向上するだけでなく (呼び出しチェーンが短くなる)、リソースの使用量も削減されます (Docker は純粋なコンテナ ランタイムではなく、他にも多くの機能があります)。

もちろん、将来的には、Docker は K8S の基盤となる使用法と互換性を持たせるために、K8S CRI インターフェースを直接実装する可能性があります。

K8S の高度な機能に関するこの記事はこれで終わりです。K8S の高度な機能に関するより関連性の高いコンテンツについては、123WORDPRESS.COM で以前の記事を検索するか、以下の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。

以下もご興味があるかもしれません:
  • Javaプロジェクトのk8sデプロイメントの実装
  • golang grpc 負荷分散方法
  • Java Grpcインスタンスでの負荷分散の作成の詳細な説明
  • Kubernetes (K8S) コンテナ クラスタ管理環境の完全な展開の詳細チュートリアル - パート 1
  • grpc-java k8sでの負荷分散処理方法

<<:  CSS で要素を垂直方向に中央揃えする 7 つの方法

>>:  テーブルを使用する場合と CSS を使用する場合 (経験の共有)

推薦する

DockerにJava環境をインストールするための実装手順

この記事は Linux centos8 をベースにして、docker をインストールし、イメージをプ...

MySQL ストアド プロシージャの作成、呼び出し、管理の詳細な説明

目次ストアドプロシージャの概要ストアド プロシージャを使用する理由は何ですか?ストアドプロシージャの...

MySQLデータ行と行オーバーフローのメカニズムの詳細な説明

1. 行の形式は何ですか? MySQL の行形式の設定は次のように表示されます。 実際、MySQL ...

MySQL 8.0.15 winx64 のインストールと設定方法のグラフィックチュートリアル (Windows の場合)

この記事では、MySQL 8.0.15 winx64のインストールと設定方法を参考までに紹介します。...

Centos7のホスト名を変更する3つの方法

方法 1: hostnamectl の変更ステップ1 ホスト名を確認するホスト名ステップ2 ホスト名...

Tomcatを自動的に開始するサービスとして設定するにはどうすればいいでしょうか？最も簡単な方法

Tomcat が自動的にサービスを開始するように設定します。最近、問題が発生しました。サーバー上のプ...

MySQLインデックスの基本構文

インデックスはソートされたデータ構造です。 where 条件での検索や order by 条件での並...

Docker データ ストレージ tmpfs マウントの詳細な説明

この記事を読む前に、ボリュームとバインドマウントの基本を理解しておいてください。詳細については、次の...

MySQLデータのセキュリティを確保するための提案

データは企業の中核資産であり、企業にとって最も重要なタスクの 1 つです。注意しないと、データが意図...

Mac での MySQL と Squel Pro の設定

Node.js の人気に応えて、最近、いくつかのサーバー側機能を実装するために Node.js を使...

JavaScript での HTML キャンバスとページ ストレージ テクノロジの使用に関する詳細な説明

目次1. JavaScriptはHTMLでキャンバスを使用する2. ページストレージ技術1. Jav...

JS 1次元配列を3次元配列に変換する例

今日、CSDN の Q&A セクションで友人が質問をしているのを見ました。彼は 1 次元配列...

データベースのデフォルトパスを変更した後にmysqlが起動できない問題の解決策

序文mysql がデフォルトのデータベース パスを変更したため、サービスを開始できませんでした。ログ...

MySQL トランザクションの概念と使用法の詳細な説明

目次情事の概念取引の状態取引の役割取引の特徴トランザクション構文トランザクション対応ストレージエンジ...

vue.js ベースの QQ チャット ルーム

目次導入効果のデモンストレーションは次のとおりです。 MChat コンポーネントのレンダリング: I...