Chelyabinsk의 Southbridge와 Kubernetes의 Bitrix

Sysadminka 시스템 관리자 모임이 Chelyabinsk에서 열리고 있으며 마지막 모임에서는 Kubernetes의 1C-Bitrix에서 애플리케이션을 실행하기 위한 솔루션에 대한 보고서를 제공했습니다.

Bitrix, Kubernetes, Ceph - 훌륭한 조합인가요?

이 모든 것에서 효과적인 솔루션을 구성하는 방법을 알려 드리겠습니다.

가자!

밋업은 18월 XNUMX일 첼랴빈스크에서 열렸습니다. 다음에서 우리의 모임에 대해 읽어보실 수 있습니다. 타임패드 그리고 봐 유튜브.

보고서를 가지고 오시거나 청취자로 우리에게 오시려면 환영합니다. [이메일 보호] 그리고 텔레그램 t.me/vadimisakanov에서 확인하세요.

내 보고서

슬라이드

솔루션 "Kubernetes의 Bitrix, 버전 Southbridge 1.0"

저는 밋업에서 했던 것처럼 "Kubernetes 입문자를 위한" 형식으로 우리 솔루션에 대해 이야기하겠습니다. 하지만 적어도 Wikipedia의 기사 수준에서는 Bitrix, Docker, Kubernetes, Ceph라는 단어를 알고 있다고 가정합니다.

Kubernetes의 Bitrix에 대해 무엇이 준비되어 있나요?

Kubernetes에서 Bitrix 애플리케이션의 작동에 대한 정보는 인터넷 전체에 거의 없습니다.
제가 찾은 자료는 다음과 같습니다.

Qsoft의 Alexander Serbul, 1C-Bitrix 및 Anton Tuzlukov의 보고서:

꼭 들어보시길 권합니다.

사용자로부터 자체 솔루션 개발 세르키론 아브레에.
더 많은 것을 발견했습니다 그런 결정.

아 그리고... 사실 그게 다에요.

경고합니다. 우리는 위 링크에 있는 솔루션의 품질을 확인하지 않았습니다. :)
그건 그렇고, 솔루션을 준비할 때 Alexander Serbul과 이야기를 나눴는데 그의 보고서가 아직 나타나지 않았기 때문에 내 슬라이드에 "Bitrix는 Kubernetes를 사용하지 않습니다."라는 항목이 있습니다.

그러나 Docker에서 Bitrix를 실행하기 위해 이미 만들어진 Docker 이미지가 많이 있습니다. https://hub.docker.com/search?q=bitrix&type=image

Kubernetes에서 Bitrix를 위한 완전한 솔루션을 생성하기에 충분합니까?
아니요. 해결해야 할 문제가 많습니다.

Kubernetes에서 Bitrix의 문제점은 무엇입니까?

첫째, Dockerhub의 기성 이미지는 Kubernetes에 적합하지 않습니다.

마이크로서비스 아키텍처를 구축하려면(Kubernetes에서는 일반적으로 그렇게 함) Kubernetes 애플리케이션을 컨테이너로 분리하고 각 컨테이너가 하나의 작은 기능을 수행하도록 해야 합니다(그리고 이를 잘 수행해야 합니다). 왜 하나만? 즉, 단순할수록 신뢰성이 높아집니다.
더 구체적으로 알아보려면 이 기사와 동영상을 시청하세요. https://habr.com/ru/company/southbridge/blog/426637/

Dockerhub의 Docker 이미지는 주로 올인원 원칙에 따라 구축되었으므로 우리는 여전히 자체 자전거를 만들고 처음부터 이미지를 생성해야 했습니다.

두 번째 - 사이트 코드는 관리자 패널에서 편집됩니다.

사이트에 새 섹션을 만들었습니다. 코드가 업데이트되었습니다(새 섹션 이름의 디렉터리가 추가되었습니다).

관리자 패널에서 구성 요소의 속성을 변경하면 코드가 변경됩니다.

Kubernetes는 "기본적으로" 이를 사용할 수 없습니다. 컨테이너는 상태 비저장이어야 합니다.

이유: 클러스터의 각 컨테이너(포드)는 트래픽의 일부만 처리합니다. 하나의 컨테이너(포드)에서만 코드를 변경하면 포드마다 코드가 달라지고, 사이트는 다르게 작동하며, 사이트의 다른 버전이 다른 사용자에게 표시됩니다. 그렇게 살 수는 없습니다.

셋째 - 배포 문제를 해결해야 합니다.

단일체와 하나의 "클래식" 서버가 있는 경우 모든 것이 매우 간단합니다. 새 코드 베이스를 배포하고, 데이터베이스를 마이그레이션하고, 트래픽을 새 버전의 코드로 전환합니다. 전환이 즉시 발생합니다.
Kubernetes에 사이트가 있고 마이크로서비스로 분할된 경우 코드가 포함된 컨테이너가 많이 있습니다. 새 버전의 코드로 컨테이너를 수집하고, 이전 코드 대신 이를 롤아웃하고, 데이터베이스를 올바르게 마이그레이션하고, 이상적으로는 방문자가 눈치채지 못하게 수행해야 합니다. 다행스럽게도 Kubernetes는 다양한 유형의 배포를 지원하여 이를 도와줍니다.

넷째 - 정적 저장 문제를 해결해야 합니다.

사이트가 10GB에 불과하고 전체를 컨테이너에 배포하는 경우 배포하는 데 시간이 오래 걸리는 10GB 컨테이너가 됩니다.
사이트의 "가장 무거운" 부분을 컨테이너 외부에 저장해야 하며 이를 올바르게 수행하는 방법에 대한 의문이 생깁니다.

우리 솔루션에서 무엇이 빠졌나요?

전체 Bitrix 코드는 마이크로 기능/마이크로 서비스로 구분되지 않습니다(등록이 별도, 온라인 상점 모듈이 별도 등). 우리는 전체 코드 베이스를 각 컨테이너에 저장합니다.

또한 우리는 Kubernetes에 데이터베이스를 저장하지 않습니다(저는 여전히 개발 환경을 위해 Kubernetes에 데이터베이스가 있는 솔루션을 구현했지만 프로덕션용은 아닙니다).

사이트가 Kubernetes에서 실행된다는 사실은 사이트 관리자에게 여전히 눈에 띕니다. "시스템 확인" 기능이 제대로 작동하지 않습니다. 관리자 패널에서 사이트 코드를 편집하려면 먼저 "코드를 편집하고 싶습니다" 버튼을 클릭해야 합니다.

문제가 확인되었고, 마이크로서비스 구현의 필요성이 결정되었으며, 목표는 명확합니다. Bitrix의 기능과 Kubernetes의 장점을 모두 유지하면서 Kubernetes의 Bitrix에서 애플리케이션을 실행하기 위한 작동 시스템을 확보하는 것입니다. 구현을 시작해 보겠습니다.

구조

웹 서버(작업자)와 함께 "작동하는" 포드가 많이 있습니다.
cron 작업이 있는 아래 하나(하나만 필요함)
관리자 패널에서 사이트 코드를 편집하기 위한 업그레이드 XNUMX개(또한 하나만 필요함)

우리는 질문을 해결합니다:

• 세션을 어디에 저장하나요?
• 캐시는 어디에 저장하나요?
• 여러 컨테이너에 기가바이트의 정적을 배치하지 않고 정적을 어디에 저장할 것인가?
• 데이터베이스는 어떻게 작동하나요?

도커 이미지

Docker 이미지를 구축하는 것부터 시작합니다.

이상적인 옵션은 하나의 범용 이미지를 갖고 이를 기반으로 작업자 포드, Crontask가 있는 포드 및 업그레이드 포드를 얻는 것입니다.

우리는 그런 이미지를 만들었습니다.

여기에는 nginx, apache/php-fpm(빌드 중에 선택 가능), 메일 전송을 위한 msmtp 및 cron이 포함됩니다.

이미지를 어셈블할 때 사이트의 전체 코드 베이스가 /app 디렉터리에 복사됩니다(별도의 공유 저장소로 이동할 부분은 제외).

마이크로서비스, 서비스

작업자 포드:

• nginx가 포함된 컨테이너 + 컨테이너 apache/php-fpm + msmtp
• msmtp를 별도의 마이크로서비스로 옮기는 건 잘 안 됐고, Bitrix는 직접 메일을 보낼 수 없다는 것에 분개하기 시작했습니다.
• 각 컨테이너에는 완전한 코드베이스가 있습니다.
• 컨테이너의 코드 변경을 금지합니다.

아래의 크론:

• Apache, PHP, Cron이 포함된 컨테이너
• 완전한 코드 베이스 포함
• 컨테이너의 코드 변경 금지

아래에서 업그레이드:

• nginx 컨테이너 + apache/php-fpm 컨테이너 + msmtp
• 컨테이너의 코드 변경에 대한 금지는 없습니다.

세션 저장

Bitrix 캐시 스토리지

또 다른 중요한 점은 데이터베이스부터 메일까지 모든 것에 연결하기 위한 비밀번호를 kubernetes 비밀에 저장한다는 것입니다. 보너스도 있습니다. 비밀번호는 비밀에 대한 액세스 권한을 부여한 사람에게만 표시되며 프로젝트의 코드 베이스에 액세스할 수 있는 모든 사람에게는 표시되지 않습니다.

정전기 보관

ceph, nfs(그러나 프로덕션에는 nfs를 권장하지 않음), 클라우드 제공업체의 네트워크 스토리지 등 무엇이든 사용할 수 있습니다.

저장소는 사이트의 /upload/ 디렉터리와 정적 콘텐츠가 있는 기타 디렉터리에 컨테이너로 연결되어야 합니다.

데이터베이스

단순화를 위해 데이터베이스를 Kubernetes 외부로 이동하는 것이 좋습니다. Kubernetes의 기반은 별도의 복잡한 작업이므로 구성표를 훨씬 더 복잡하게 만듭니다.

세션 저장

우리는 memcached를 사용합니다 :)

세션 저장을 잘 처리하고 클러스터링되어 있으며 PHP에서 session.save_path로 "기본적으로" 지원됩니다. 이러한 시스템은 많은 수의 웹 서버로 클러스터를 구축할 때 고전적인 모놀리식 아키텍처에서 여러 번 테스트되었습니다. 배포에는 helm을 사용합니다.

$ helm install stable/memcached --name session

php.ini - 여기 이미지에는 memcached에 세션을 저장하기 위한 설정이 포함되어 있습니다.

memcached를 사용하여 호스트에 대한 데이터를 전달하기 위해 환경 변수를 사용했습니다. https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/.
이를 통해 개발, 단계, 테스트, 프로덕션 환경에서 동일한 코드를 사용할 수 있습니다(Memcached 호스트 이름은 다르기 때문에 각 환경에 대한 세션의 고유한 호스트 이름을 전달해야 합니다).
Bitrix 캐시 스토리지

모든 포드에서 쓰고 읽을 수 있는 내결함성 스토리지가 필요합니다.

우리는 또한 memcached를 사용합니다.
이 솔루션은 Bitrix 자체에서 권장됩니다.

$ helm install stable/memcached --name cache

bitrix/.settings_extra.php - 여기 Bitrix에서는 캐시가 저장되는 위치가 지정됩니다.

우리는 또한 환경 변수를 사용합니다.

크론타스키

Kubernetes에서 Crontask를 실행하는 데는 다양한 접근 방식이 있습니다.

• Crontask 실행을 위한 Pod를 사용한 별도 배포
• crontask 실행을 위한 cronjob(웹 앱인 경우 - wget 사용) https://$host$cronjobname또는 작업자 Pod 중 하나 내부의 kubectl exec 등)
• 등

가장 정확한 것에 대해 논쟁할 수 있지만 이 경우에는 "Crontask용 포드를 사용한 별도 배포" 옵션을 선택했습니다.

완료 방법:

• ConfigMap 또는 config/addcron 파일을 통해 cron 작업 추가
• 어떤 경우에는 작업자 포드와 동일한 컨테이너를 시작하고 그 안에서 크라운 작업을 실행할 수 있습니다.
• 동일한 코드 기반이 사용되며, 통합 덕분에 컨테이너 조립이 간단합니다.

우리가 얻는 이점:

• 우리는 개발자 환경(docker)과 동일한 환경에서 Crontask를 작동하고 있습니다.
• Crontask는 Kubernetes용으로 "다시 작성"할 필요가 없으며 이전과 동일한 형식과 동일한 코드 베이스에서 작동합니다.
• 관리자뿐만 아니라 프로덕션 브랜치에 대한 커밋 권한이 있는 모든 팀 구성원이 cron 작업을 추가할 수 있습니다.

Southbridge K8SDeploy 모듈 및 관리자 패널에서 코드 편집

우리는 업그레이드에 대해 이야기하고 있었습니까?
그곳으로 교통을 안내하는 방법은 무엇입니까?
만세, 우리는 PHP에서 이에 대한 모듈을 작성했습니다. :) 이것은 Bitrix를 위한 작은 클래식 모듈입니다. 아직 공개되지는 않았지만 공개할 계획입니다.
모듈은 Bitrix의 일반 모듈처럼 설치됩니다.

그리고 그것은 다음과 같습니다:

이를 통해 사이트 관리자를 식별하고 Kubernetes가 업그레이드 포드로 트래픽을 보낼 수 있도록 하는 쿠키를 설정할 수 있습니다.

변경이 완료되면 git push를 클릭해야 합니다. 그러면 코드 변경 사항이 git으로 전송됩니다. 그런 다음 시스템은 새 버전의 코드로 이미지를 빌드하고 클러스터 전체에 "롤아웃"하여 이전 포드를 교체합니다. .

예, 약간의 버팀목이지만 동시에 우리는 마이크로서비스 아키텍처를 유지하고 Bitrix 사용자가 관리자 패널에서 코드를 수정할 수 있는 가장 좋아하는 기회를 빼앗지 않습니다. 결국 이것은 옵션이며 코드 편집 문제를 다른 방식으로 해결할 수 있습니다.

투구 차트

Kubernetes에서 애플리케이션을 구축하려면 일반적으로 Helm 패키지 관리자를 사용합니다.
Kubernetes의 Bitrix 솔루션을 위해 최고의 시스템 관리자인 Sergey Bondarev가 특별한 Helm 차트를 작성했습니다.

작업자, 업그레이드, 크론 포드를 구축하고 수신, 서비스를 구성하고 Kubernetes 비밀에서 포드로 변수를 전송합니다.

Gitlab에 코드를 저장하고 Gitlab에서 Helm 빌드도 실행합니다.

간단히 말해서 이렇습니다.

$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=production

또한 Helm을 사용하면 배포 중에 갑자기 문제가 발생하는 경우 "원활한" 롤백을 수행할 수 있습니다. "프로드가 떨어졌기 때문에 ftp를 통해 코드를 수정"하는 당황하지 않을 때는 좋지만 Kubernetes는 가동 중지 시간 없이 자동으로 이를 수행합니다.

배포

예, 우리는 Gitlab 및 Gitlab CI의 팬이며 이를 사용합니다. :)
Gitlab에서 프로젝트 저장소에 커밋하면 Gitlab은 새 버전의 환경을 배포하는 파이프라인을 시작합니다.

단계 :

• 빌드(새 Docker 이미지 빌드)
• 테스트 (테스트)
• 정리(테스트 환경 제거)
• 푸시(Docker 레지스트리로 보냅니다)
• 배포(Helm을 통해 Kubernetes에 애플리케이션을 배포합니다).

만세, 준비되었습니다. 구현해 봅시다!
글쎄요, 아니면 질문이 있으면 물어보세요.

그래서 우리는 무엇을 했나요?

기술적인 관점에서 보면:

• 도커화된 Bitrix;
• Bitrix를 각각 최소한의 기능을 수행하는 컨테이너로 "절단"합니다.
• 상태 없는 컨테이너 상태를 달성했습니다.
• Kubernetes에서 Bitrix 업데이트 문제를 해결했습니다.
• 모든 Bitrix 기능은 계속 작동했습니다(거의 모두).
• 우리는 Kubernetes에 배포하고 버전 간 롤백 작업을 진행했습니다.

비즈니스 관점에서 보면:

• 결함 허용;
• Kubernetes 도구(Gitlab CI와의 손쉬운 통합, 원활한 배포 등)
• 비밀 비밀번호(비밀번호에 대한 접근 권한이 직접 부여된 사람에게만 표시됨)
• 단일 인프라 내에서 추가 환경(개발, 테스트 등)을 구축하는 것이 편리합니다.

출처 : habr.com