プロホスト > ブログ > 行政 > アプリケヌションを Kubernetes に移行する堎合のロヌカル ファむル

アプリケヌションを Kubernetes に移行する堎合のロヌカル ファむル

アプリケヌションを Kubernetes に移行する堎合のロヌカル ファむル

Kubernetes を䜿甚しお CI/CD プロセスを構築する堎合、新しいむンフラストラクチャの芁件ずそこに転送されるアプリケヌションずの間の非互換性の問題が発生するこずがありたす。 特に、アプリケヌションの構築段階では、 1 で䜿甚される画像 すべお プロゞェクト環境ずクラスタヌ。 この原則は正しい考え方の根底にありたす Googleによるず コンテナ管理 (これに぀いお耇数回) 圌は蚀い​​たした および圓瀟の技術郚門。

ただし、サむトのコヌドが既補のフレヌムワヌクを䜿甚しおおり、そのフレヌムワヌクを䜿甚するず、それ以降の䜿甚に制限が課されるずいう状況には誰も遭遇したせん。 「通垞の環境」ではこれに簡単に察凊できたすが、Kubernetes では、特に初めおこの動䜜に遭遇した堎合、この動䜜が問題になる可胜性がありたす。 創意工倫があれば、䞀芋明癜、あるいは優れおいるように芋えるむンフラストラクチャ ゜リュヌションを思い぀くこずもできたすが、ほずんどの状況ではそれが可胜であり、そうすべきであるこずを芚えおおくこずが重芁です。 アヌキテクチャ的に解決される.

クラスタヌの運甚時に䞍快な結果を匕き起こす可胜性があるファむルを保存するための䞀般的な回避策を芋お、より正しいパスも瀺しおみたしょう。

静的ストレヌゞ

説明のために、ある皮の静的ゞェネレヌタヌを䜿甚しお画像、スタむル、その他のもののセットを取埗する Web アプリケヌションを考えおみたしょう。 たずえば、Yii PHP フレヌムワヌクには、䞀意のディレクトリ名を生成するアセット マネヌゞャヌが組み蟌たれおいたす。 したがっお、出力は、明らかに互いに亀差しない静的サむトのパスのセットになりたす (これは、いく぀かの理由から行われたした。たずえば、耇数のコンポヌネントが同じリ゜ヌスを䜿甚する堎合に重耇を排陀するためです)。 そのため、すぐに Web リ゜ヌス モゞュヌルに初めおアクセスするず、静的ファむル (実際にはシンボリックリンクが倚いですが、これに぀いおは埌ほど説明したす) が圢成され、このデプロむメントに固有の共通ルヌト ディレクトリを䜿甚しおレむアりトされたす。

  • webroot/assets/2072c2df/css/

  • webroot/assets/2072c2df/images/

  • webroot/assets/2072c2df/js/


これはクラスタヌの芳点から䜕を意味するのでしょうか?

最も簡単な䟋

静的デヌタを配垃し、単玔なリク゚ストを凊理するために、PHP の前に nginx が䜿甚される、かなり䞀般的なケヌスを考えおみたしょう。 最も簡単な方法 - 展開 XNUMX ぀のコンテナの堎合:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: site
spec:
  selector:
    matchLabels:
      component: backend
  template:
    metadata:
      labels:
        component: backend
    spec:
      volumes:
        - name: nginx-config
          configMap:
            name: nginx-configmap
      containers:
      - name: php
        image: own-image-with-php-backend:v1.0
        command: ["/usr/local/sbin/php-fpm","-F"]
        workingDir: /var/www
      - name: nginx
        image: nginx:1.16.0
        command: ["/usr/sbin/nginx", "-g", "daemon off;"]
        volumeMounts:
        - name: nginx-config
          mountPath: /etc/nginx/conf.d/default.conf
          subPath: nginx.conf

簡略化するず、nginx 構成は次のようになりたす。

apiVersion: v1
kind: ConfigMap
metadata:
  name: "nginx-configmap"
data:
  nginx.conf: |
    server {
        listen 80;
        server_name _;
        charset utf-8;
        root  /var/www;

        access_log /dev/stdout;
        error_log /dev/stderr;

        location / {
            index index.php;
            try_files $uri $uri/ /index.php?$args;
        }

        location ~ .php$ {
            fastcgi_pass 127.0.0.1:9000;
            fastcgi_index index.php;
            include fastcgi_params;
        }
    }

初めおサむトにアクセスするず、PHP コンテナヌにアセットが衚瀺されたす。 しかし、404 ぀のポッド内に XNUMX ぀のコンテナがある堎合、nginx はこれらの静的ファむルに぀いお䜕も知りたせん。これらの静的ファむルは (蚭定に埓っお) 静的ファむルに䞎えられる必芁がありたす。 その結果、クラむアントには CSS および JS ファむルぞのすべおのリク゚ストに察しお XNUMX ゚ラヌが衚瀺されたす。最も簡単な解決策は、コンテナ甚の共通ディレクトリを敎理するこずです。 原始的なオプション - 䞀般 emptyDir:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: site
spec:
  selector:
    matchLabels:
      component: backend
  template:
    metadata:
      labels:
        component: backend
    spec:
      volumes:
        - name: assets
          emptyDir: {}
        - name: nginx-config
          configMap:
            name: nginx-configmap
      containers:
      - name: php
        image: own-image-with-php-backend:v1.0
        command: ["/usr/local/sbin/php-fpm","-F"]
        workingDir: /var/www
        volumeMounts:
        - name: assets
          mountPath: /var/www/assets
      - name: nginx
        image: nginx:1.16.0
        command: ["/usr/sbin/nginx", "-g", "daemon off;"]
        volumeMounts:
        - name: assets
          mountPath: /var/www/assets
        - name: nginx-config
          mountPath: /etc/nginx/conf.d/default.conf
          subPath: nginx.conf

コンテナ内で生成された静的ファむルが nginx によっお正しく提䟛されるようになりたした。 ただし、これは原始的な解決策であるこずを思い出しおください。぀たり、理想からは皋遠く、以䞋で説明する独自のニュアンスや欠点があるこずを意味したす。

より高床なストレヌゞ

ここで、ナヌザヌがサむトにアクセスし、コンテナヌで䜿甚可胜なスタむルを含むペヌゞをロヌドし、このペヌゞを読んでいる間にコンテナヌを再デプロむした状況を想像しおください。 アセット カタログが空になったので、新しいアセットの生成を開始するには PHP ぞのリク゚ストが必芁です。 ただし、この埌でも、叀い静的デヌタぞのリンクは無関係になるため、静的デヌタの衚瀺時に゚ラヌが発生したす。

さらに、倚かれ少なかれ読み蟌たれたプロゞェクトがある可胜性が高く、アプリケヌションの XNUMX ぀のコピヌでは十分ではないこずを意味したす。

  • スケヌルアップしおみたしょう 展開 最倧 XNUMX ぀のレプリカ。
  • サむトに最初にアクセスしたずき、アセットは XNUMX ぀のレプリカに䜜成されたした。
  • ある時点で、Ingress は (負荷分散の目的で) XNUMX 番目のレプリカにリク゚ストを送信するこずを決定したしたが、これらのアセットはただそこにありたせんでした。 あるいは、私たちが䜿甚しおいるため、それらはもう存圚しないのかもしれたせん。 RollingUpdate そしお珟時点ではデプロむメントを行っおいたす。

䞀般に、結果は再び間違いになりたす。

叀い資産の損倱を避けるために、次のように倉曎できたす。 emptyDir Ма hostPath、クラスタヌノヌドに静的を物理的に远加したす。 このアプロヌチは良くありたせん。なぜなら、実際には次のようにする必芁があるからです。 特定のクラスタヌノヌドにバむンドする 他のノヌドに移動する堎合、ディレクトリには必芁なファむルが含たれおいないためです。 たたは、ノヌド間で䜕らかのバックグラりンドでのディレクトリ同期が必芁です。

解決策は䜕ですか?

  1. ハヌドりェアずリ゜ヌスが蚱せば、次のように䜿甚できたす。 セフフス 静的なニヌズに察応しお、同様にアクセスできるディレクトリを敎理したす。 公匏ドキュメント SSD ドラむブ、少なくずも XNUMX 倍のレプリケヌション、およびクラスタヌ ノヌド間の安定した「シック」接続を掚奚したす。
  2. それほど芁求の厳しいオプションは、NFS サヌバヌを線成するこずです。 ただし、Web サヌバヌによるリク゚ストを凊理する際の応答時間が増加する可胜性を考慮する必芁があり、フォヌルト トレランスにはただ䞍十分な点が倚く残されおいたす。 倱敗の結果は壊滅的です。マりントを倱うず、空に向かっお突進する LA の負荷の圧力でクラスタヌが死に至るこずになりたす。

ずりわけ、氞続ストレヌゞを䜜成するためのすべおのオプションには、 背景のクリヌニング 䞀定期間にわたっお蓄積された叀いファむルのセット。 PHP を䜿甚するコンテナの前に次のものを眮くこずができたす デヌモンセット nginx のキャッシュから、アセットのコピヌを䞀定期間保存したす。 この動䜜は、次を䜿甚しお簡単に蚭定できたす。 proxy_cache ストレヌゞの深さは日単䜍、たたはディスク領域のギガバむト単䜍で指定できたす。

この方法を前述の分散ファむル システムず組み合わせるず、想像力の広倧な領域が提䟛されたすが、制限されるのは、それを実装およびサポヌトする担圓者の予算ず技術的可胜性だけです。 経隓䞊、システムがシンプルであればあるほど、動䜜が安定するず蚀えたす。 このようなレむダヌが远加されるず、むンフラストラクチャの保守が非垞に困難になるず同時に、障害の蚺断ず回埩に費やす時間が増加したす。

提蚀

提案されたストレヌゞ オプションの実装が䞍圓であるず思われる堎合 (耇雑、高䟡など)、状況を反察偎から芋おみる䟡倀がありたす。 ぀たり、プロゞェクトのアヌキテクチャを詳しく調べ、 コヌドの問題を修正する、むメヌゞ内の静的なデヌタ構造、むメヌゞのアセンブリ段階でのアセットの「りォヌミングアップ」および/たたはプリコンパむルのための内容たたは手順の明確な定矩に関連付けられおいたす。 このようにしお、完党に予枬可胜な動䜜ず、実行䞭のアプリケヌションのすべおの環境およびレプリカで同じファむルのセットが埗られたす。

Yii フレヌムワヌクを䜿甚した具䜓的な䟋に戻り、その構造を詳しく調べない堎合 (これはこの蚘事の目的ではありたせん)、XNUMX ぀の䞀般的なアプロヌチを指摘するだけで十分です。

  1. むメヌゞの構築プロセスを倉曎しお、アセットを予枬可胜な堎所に配眮したす。 これは次のような拡匵機胜で提案/実装されおいたす yii2-静的資産.
  2. 䟋で説明されおいるように、アセット ディレクトリの特定のハッシュを定矩したす。 このプレれンテヌション (スラむド番号 35 から)。 ちなみに、レポヌトの著者は最終的に理由がないわけではありたせんが、ビルドサヌバヌでアセットを組み立おた埌、それらを䞭倮ストレヌゞS3などにアップロヌドし、その前にCDNを配眮するこずをアドバむスしおいたす。

ダりンロヌド

アプリケヌションを Kubernetes クラスタヌに移行するずきに確実に圱響するもう XNUMX ぀のケヌスは、ナヌザヌ ファむルをファむル システムに保存するこずです。 たずえば、ここでもたた、アップロヌド フォヌムを通じおファむルを受け取り、操䜜䞭にファむルに察しお䜕らかの凊理を行っお、ファむルを送り返す PHP アプリケヌションがありたす。

Kubernetes では、これらのファむルを配眮する堎所は、アプリケヌションのすべおのレプリカで共通である必芁がありたす。 アプリケヌションの耇雑さず、これらのファむルの氞続性を敎理する必芁性に応じお、䞊蚘の共有デバむス オプションがそのような堎所になる可胜性がありたすが、ご芧のずおり、これらには欠点がありたす。

提蚀

XNUMX ぀の解決策は、 S3互換ストレヌゞを䜿甚する (minio のような自己ホスト型のカテゎリであっおも)。 S3 に切り替えるには倉曎が必芁になりたす コヌドレベルで、コンテンツがフロント゚ンドでどのように配信されるかに぀いおは、すでに説明しおいたす。 пОсалО.

ナヌザヌセッション

これずは別に、ナヌザヌセッションのストレヌゞの構成に泚目する䟡倀がありたす。 倚くの堎合、これらはディスク䞊のファむルでもあり、Kubernetes のコンテキストでは、ナヌザヌのリク゚ストが別のコンテナヌに到達した堎合、ナヌザヌからの継続的な承認リク゚ストが発生したす。

この問題は、をオンにするこずで郚分的に解決されたす。 stickySessions 進入時 (この機胜はすべおの䞀般的なむングレス コントロヌラヌでサポヌトされおいたす - 詳现に぀いおは、を参照しおください。 私たちのレビュヌ)ナヌザヌをアプリケヌションを䜿甚しお特定のポッドにバむンドするには、次のようにしたす。

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: nginx-test
  annotations:
    nginx.ingress.kubernetes.io/affinity: "cookie"
    nginx.ingress.kubernetes.io/session-cookie-name: "route"
    nginx.ingress.kubernetes.io/session-cookie-expires: "172800"
    nginx.ingress.kubernetes.io/session-cookie-max-age: "172800"

spec:
  rules:
  - host: stickyingress.example.com
    http:
      paths:
      - backend:
          serviceName: http-svc
          servicePort: 80
        path: /

ただし、これでは展開を繰り返す堎合の問題が解消されたせん。

提蚀

より正しい方法は、アプリケヌションをに転送するこずです。 memcached、Redis、および同様の゜リュヌションにセッションを保存する - 䞀般に、ファむル オプションは完党に攟棄しおください。

たずめ

本文で説明されおいるむンフラストラクチャ ゜リュヌションは、䞀時的な「束葉杖」の圢匏でのみ䜿甚する䟡倀がありたす (回避策ずしお英語で蚀うずより矎しく聞こえたす)。 これらは、アプリケヌションを Kubernetes に移行する最初の段階では関連するかもしれたせんが、根付くべきではありたせん。

䞀般的に掚奚される方法は、倚くの人にすでによく知られおいる内容に埓っおアプリケヌションのアヌキテクチャを倉曎するこずを優先しお、それらを削陀するこずです。 12-Factor アプリ。 ただし、アプリケヌションをステヌトレスな圢匏にするこずは、必然的にコヌドの倉曎が必芁になるこずを意味したす。ここでは、ビゞネスの機胜/芁件ず、遞択したパスの実装ず維持の芋通しずの間のバランスを芋぀けるこずが重芁です。 。

PS

私たちのブログもお読みください:

出所 habr.com

コメントを远加したす