애플리케이션을 Kubernetes로 마이그레이션할 때 로컬 파일

Kubernetes를 사용하여 CI/CD 프로세스를 구축할 때 새로운 인프라의 요구 사항과 여기에 전송되는 애플리케이션 간의 비호환성 문제가 발생하는 경우가 있습니다. 특히, 애플리케이션 구축 단계에서는 다음을 얻는 것이 중요합니다. 한 에 사용될 이미지 모든 프로젝트 환경 및 클러스터. 이 원칙은 올바른 원칙의 기초가 됩니다. 구글에 따르면 컨테이너 관리(이에 대해 두 번 이상 그는 말했다 그리고 우리 기술 부서).

그러나 사이트의 코드가 기성 프레임워크를 사용하는 상황에서는 누구도 볼 수 없으며 이를 사용하면 추가 사용이 제한됩니다. "일반 환경"에서는 이 동작을 쉽게 처리할 수 있지만 Kubernetes에서는 특히 처음으로 이러한 동작을 접할 때 문제가 될 수 있습니다. 창의적인 생각을 가진 사람은 언뜻 보기에 명백하고 좋아 보이는 인프라 솔루션을 생각해 낼 수 있지만... 대부분의 상황에서는 그럴 수 있고 또 그래야 한다는 점을 기억하는 것이 중요합니다. 구조적으로 해결하다.

클러스터를 운영할 때 불쾌한 결과를 초래할 수 있는 파일 저장에 대한 인기 있는 해결 방법을 살펴보고 보다 정확한 경로를 지적해 보겠습니다.

정적 저장

설명을 위해 일종의 정적 생성기를 사용하여 일련의 이미지, 스타일 및 기타 항목을 얻는 웹 애플리케이션을 생각해 보세요. 예를 들어 Yii PHP 프레임워크에는 고유한 디렉터리 이름을 생성하는 자산 관리자가 내장되어 있습니다. 따라서 출력은 분명히 서로 교차하지 않는 정적 사이트에 대한 경로 집합입니다(이는 여러 가지 이유로 수행되었습니다. 예를 들어 여러 구성 요소가 동일한 리소스를 사용할 때 중복을 제거하기 위해 수행되었습니다). 따라서 웹 리소스 모듈에 처음 액세스하면 기본적으로 정적 파일(실제로 심볼릭 링크인 경우가 많지만 나중에 자세히 설명)이 구성되어 이 배포에 고유한 공통 루트 디렉터리로 배치됩니다.

• webroot/assets/2072c2df/css/…
• webroot/assets/2072c2df/images/…
• webroot/assets/2072c2df/js/…

클러스터 측면에서 이는 무엇을 의미합니까?

가장 간단한 예

정적 데이터를 배포하고 간단한 요청을 처리하기 위해 PHP 앞에 nginx가 오는 매우 일반적인 경우를 살펴보겠습니다. 가장 쉬운 방법 - 전개 두 개의 컨테이너로:

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 컨테이너에 나타납니다. 그러나 하나의 포드 내에 두 개의 컨테이너가 있는 경우 nginx는 (구성에 따라) 제공되어야 하는 이러한 정적 파일에 대해 아무것도 모릅니다. 결과적으로 클라이언트는 CSS 및 JS 파일에 대한 모든 요청에 ​​대해 404 오류를 보게 됩니다. 여기서 가장 간단한 해결책은 컨테이너에 대한 공통 디렉터리를 구성하는 것입니다. 기본 옵션 - 일반 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개입니다.
• 사이트에 처음 액세스했을 때 하나의 복제본에 자산이 생성되었습니다.
• 어느 시점에서 수신은 로드 밸런싱 목적으로 두 번째 복제본에 요청을 보내기로 결정했지만 이러한 자산은 아직 거기에 없습니다. 아니면 우리가 사용하기 때문에 더 이상 존재하지 않을 수도 있습니다. RollingUpdate 현재 우리는 배포를 수행하고 있습니다.

일반적으로 결과는 다시 실수입니다.

오래된 자산을 잃지 않으려면 다음을 변경할 수 있습니다. emptyDir 에 hostPath, 클러스터 노드에 물리적으로 정적을 추가합니다. 이 접근 방식은 좋지 않습니다. 왜냐하면 실제로는 특정 클러스터 노드에 바인딩 다른 노드로 이동하는 경우 디렉터리에 필요한 파일이 포함되지 않기 때문입니다. 또는 노드 간에 일종의 백그라운드 디렉터리 동기화가 필요합니다.

해결책은 무엇입니까?

1. 하드웨어와 리소스가 허용하는 경우 다음을 사용할 수 있습니다. 세프프 정적 요구에 맞게 동등하게 액세스 가능한 디렉토리를 구성합니다. 공식 문서 SSD 드라이브, 최소 XNUMX중 복제 및 클러스터 노드 간의 안정적인 "두꺼운" 연결을 권장합니다.
2. 덜 까다로운 옵션은 NFS 서버를 구성하는 것입니다. 그러나 웹 서버의 요청 처리에 대한 응답 시간이 증가할 수 있다는 점을 고려해야 하며 내결함성은 아직 많이 부족합니다. 실패의 결과는 치명적입니다. 마운트가 손실되면 하늘로 돌진하는 LA 부하의 압력으로 인해 클러스터가 사망하게 됩니다.

무엇보다도 영구 저장소를 생성하기 위한 모든 옵션에는 다음이 필요합니다. 배경 청소 특정 기간 동안 누적된 오래된 파일 세트. PHP가 포함된 컨테이너 앞에 다음을 넣을 수 있습니다. 데몬셋 제한된 시간 동안 자산 사본을 저장하는 nginx 캐싱에서. 이 동작은 다음을 사용하여 쉽게 구성할 수 있습니다. proxy_cache 일 단위 또는 기가바이트 단위의 디스크 공간 저장 깊이.

위에서 언급한 분산 파일 시스템과 이 방법을 결합하면 이를 구현하고 지원할 사람들의 예산과 기술적 잠재력에 의해서만 제한되는 상상의 거대한 영역이 제공됩니다. 경험을 통해 우리는 시스템이 단순할수록 더 안정적으로 작동한다고 말할 수 있습니다. 이러한 계층이 추가되면 인프라를 유지 관리하기가 훨씬 더 어려워지고 동시에 장애를 진단하고 복구하는 데 소요되는 시간도 늘어납니다.

추천

제안된 스토리지 옵션의 구현이 귀하에게 정당하지 않은 것처럼 보이면(복잡하고 비용이 많이 듭니다...) 반대편에서 상황을 살펴보는 것이 좋습니다. 즉, 프로젝트 아키텍처를 자세히 살펴보고 코드의 문제를 해결하세요, 이미지의 일부 정적 데이터 구조와 연결되어 이미지 조립 단계에서 "워밍업" 및/또는 자산 사전 컴파일을 위한 내용 또는 절차에 대한 명확한 정의입니다. 이렇게 하면 실행 중인 애플리케이션의 모든 환경과 복제본에 대해 절대적으로 예측 가능한 동작과 동일한 파일 세트를 얻을 수 있습니다.

Yii 프레임워크의 특정 예로 돌아가서 그 구조를 자세히 다루지 않는다면(이 글의 목적은 아닙니다) 두 가지 인기 있는 접근 방식을 지적하는 것으로 충분합니다.

1. 예측 가능한 위치에 자산을 배치하도록 이미지 빌드 프로세스를 변경합니다. 이것은 다음과 같은 확장 프로그램에서 제안/구현됩니다. yii2-정적 자산.
2. 예를 들어 설명된 대로 자산 디렉터리에 대한 특정 해시를 정의합니다. 이 프레젠테이션 (슬라이드 35번부터 시작) 그건 그렇고, 보고서 작성자는 궁극적으로 (그리고 이유 없이는 아닙니다!) 빌드 서버에서 자산을 조립한 후 중앙 스토리지(예: S3)에 업로드하고 그 앞에 CDN을 배치하라고 조언합니다.

다운로드

애플리케이션을 Kubernetes 클러스터로 마이그레이션할 때 확실히 중요한 또 다른 사례는 사용자 파일을 파일 시스템에 저장하는 것입니다. 예를 들어, 업로드 양식을 통해 파일을 받아들이고, 작업 중에 해당 파일로 작업을 수행하고, 다시 보내는 PHP 애플리케이션이 있습니다.

Kubernetes에서 이러한 파일을 배치해야 하는 위치는 애플리케이션의 모든 복제본에 공통되어야 합니다. 애플리케이션의 복잡성과 이러한 파일의 지속성을 구성해야 하는 필요성에 따라 위에서 언급한 공유 장치 옵션이 그러한 위치일 수 있지만, 보시다시피 단점이 있습니다.

추천

한 가지 해결책은 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팩터 앱. 그러나 이는 애플리케이션을 상태 비저장 형식으로 가져오는 것은 필연적으로 코드 변경이 필요하다는 것을 의미하며, 여기서는 비즈니스의 기능/요구 사항과 선택한 경로의 구현 및 유지에 대한 전망 사이의 균형을 찾는 것이 중요합니다. .

PS

블로그에서도 읽어보세요.

• «nginx를 사용하여 AWS S3에서 파일 프록시";
• «Google이 제시하는 컨테이너 사용에 대한 7가지 모범 사례";
• «컨테이너 기반 애플리케이션 설계를 위한 7가지 원칙» (레드햇에서);
• «7 Factor 앱에서 누락된 12가지 요소".

출처 : habr.com