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 を使用する場合 (経験の共有)

推薦する

Linux での rpm、yum、ソースコードの 3 つのインストール方法の詳細な紹介

第1章 ソースコードのインストールRPM パッケージは特定のシステムとプラットフォームに応じて指定さ...

Tomcat8はcronologを使用してCatalina.Outログを分割します

背景tomcat によって生成された catalina.out ログ ファイルが分割されていない場合...

リアルタイムコンピューティングフレームワークFlinkクラスタの構築と動作メカニズムについての簡単な説明

目次1. Flinkの概要1.1 基本的な紹介1.2 アプリケーションシナリオ2. 環境の展開2.1...

Linux サーバーに SSH パスワードなしでログインする方法

テスト サーバーにログインするたびに、必ず ssh ログインのパスワードを入力する必要があります。ロ...

Vue における v-for のキーの一意性の詳細な説明

目次1. DOM の違い2. 同じレイヤーの同じタイプの要素にキー属性を追加する3. キーはインデッ...

英語の単語の出現頻度を数えるtrコマンドの魔法

置換を削除したり文字列を削除したりできる tr コマンドは、誰もがよく知っています。 英語では、英語...

正規表現に基づくあいまい文字列置換を実装するMySQLの方法の分析

この記事では、例を使用して、MySQL を使用して正規表現に基づくあいまい文字列置換を実装する方法を...

WeChatミニプログラム開発のためのコンポーネント設計仕様

WeChat ミニプログラム コンポーネント設計仕様コンポーネントベースの開発という考え方は、私の開...

中国語でのNginx設定パラメータの詳細な説明（負荷分散とリバースプロキシ）

PS: 最近、nginx を詳細に紹介している <<High-Performance ...

HTMLの行間設定方法と問題点

<p></p> の行間隔を設定するには、style="line-h...

HTMLフォームアプリケーションにはチェックボックスとラジオボタンの使用が含まれます

チェックボックスやラジオボタンの使用を含むコードをコピーコードは次のとおりです。 <!DOCT...

エレメントアバターアップロード練習

この記事は、Element公式サイトとQiniu Cloud公式サイトを使用しています。 eleme...

Linuxで中断されたシステムを呼び出す方法

序文低速システム コールとは、決して戻らない可能性があり、プロセスを永久にブロックするシステム コー...

chkconfig および systemctl コマンドを使用して Linux サービスを有効または無効にする方法

これは Linux 管理者にとって重要な (そして素晴らしい) トピックなので、誰もが Linux ...

擬似静的およびクライアント適応型 Nginx の設定方法

バックエンドは thinkphp3.2.3 フレームワークを使用します。他の言語を使用している場合は...