チェリャビンスクのサウスブリッジとKubernetesのBitrix

Sysadminka システム管理者のミートアップはチェリャビンスクで開催されており、最後のミートアップでは、Kubernetes の 1C-Bitrix でアプリケーションを実行するためのソリューションについてレポートしました。

Bitrix、Kubernetes、Ceph - 素晴らしい組み合わせですか?

これらすべてから実用的なソリューションをどのようにまとめたかを説明します。

行こう！

交流会は18月XNUMX日にチェリャビンスクで開催された。 私たちのミートアップについては、次の URL でご覧いただけます。 タイムパッド そして見てください YouTube.

レポートを持って、またはリスナーとして私たちに来たい場合は、大歓迎です。 [メール保護] Telegram t.me/vadimisakanov で。

私の報告書

スライド

ソリューション「Kubernetes の Bitrix、バージョン Southbridge 1.0」

ミートアップで行ったように、「Kubernetes のダミー向け」形式でソリューションについて話します。 ただし、Bitrix、Docker、Kubernetes、Ceph という言葉は、少なくとも Wikipedia の記事レベルでは知っていると思います。

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 アプリケーションをコンテナに分割し、各コンテナに XNUMX つの小さな機能を実行させる (そしてそれを適切に実行させる) 必要があります。 なぜ XNUMX つだけですか? 要するに、シンプルなほど信頼性が高くなります。
より具体的には、この記事とビデオをご覧ください。 https://habr.com/ru/company/southbridge/blog/426637/

Dockerhub の Docker イメージは主にオールインワンの原則に基づいて構築されているため、それでも独自のバイクを作成し、イメージを最初から作成する必要がありました。

XNUMX 番目 - サイトコードは管理パネルから編集されます

サイトに新しいセクションを作成しました。コードが更新されました (新しいセクションの名前のディレクトリが追加されました)。

管理パネルからコンポーネントのプロパティを変更すると、コードが変更されます。

Kubernetes は「デフォルトでは」これでは動作できません。コンテナはステートレスでなければなりません。

理由: クラスター内の各コンテナー (ポッド) は、トラフィックの一部のみを処理します。 XNUMX つのコンテナー (ポッド) のみでコードを変更した場合、コードはポッドごとに異なり、サイトの動作も異なり、サイトの異なるバージョンが異なるユーザーに表示されます。 そんなんじゃ生きていけないよ。

XNUMX 番目 - 導入に関する問題を解決する必要がある

モノリス サーバーと XNUMX つの「クラシック」サーバーがある場合、すべては非常に簡単です。新しいコード ベースをデプロイし、データベースを移行し、トラフィックを新しいバージョンのコードに切り替えます。 切り替えは瞬時に行われます。
Kubernetes のサイトがマイクロサービスに分割されている場合、コードを含むコンテナーが多数存在します。 新しいバージョンのコードを含むコンテナを収集し、古いコードの代わりにそれらをロールアウトし、データベースを正しく移行する必要があります。理想的には、訪問者に気付かれずにこれを実行します。 幸いなことに、Kubernetes はこれを支援し、さまざまなタイプのデプロイメントをサポートします。

XNUMX 番目 - 静的データの保存の問題を解決する必要があります

サイトが 10 ギガバイト「のみ」で、サイト全体をコンテナーにデプロイすると、最終的に 10 ギガバイトのコンテナーが作成され、デプロイに永遠に時間がかかります。
サイトの「最も重い」部分をコンテナの外に保存する必要がありますが、これをどのように正しく行うかという問題が生じます。

私たちのソリューションには何が欠けているのでしょうか?

Bitrix コード全体はマイクロ関数/マイクロサービスに分割されていません (登録が分離され、オンライン ストア モジュールが分離されるなど)。 コードベース全体を各コンテナに保存します。

また、データベースを Kubernetes に保存しません (開発環境では Kubernetes のデータベースを使用したソリューションを実装しましたが、運用環境では実装しませんでした)。

サイト管理者は、サイトが Kubernetes 上で実行されていることを認識します。 「システムチェック」機能が正しく動作しないため、管理パネルからサイトコードを編集するには、まず「コードを編集する」ボタンをクリックする必要があります。

問題が特定され、マイクロサービスを実装する必要性が決定され、目標は明確です。それは、Bitrix の機能と Kubernetes の利点の両方を維持しながら、Kubernetes の Bitrix 上でアプリケーションを実行するための動作するシステムを取得することです。 実装を始めましょう。

アーキテクチャ

Web サーバー (ワーカー) を備えた「動作中の」ポッドが多数あります。
cron タスクで XNUMX つ下にあります (XNUMX つだけが必要です)。
管理パネルからサイト コードを編集するための XNUMX つのアップグレード (必要なアップグレードも XNUMX つだけです)。

疑問を解決します:

• セッションをどこに保存するか?
• キャッシュをどこに保存するか?
• 静的データを大量のコンテナに置くのではなく、どこに保存するか?
• データベースはどのように機能するのでしょうか?

Dockerイメージ

まず、Docker イメージを構築します。

理想的なオプションは、XNUMX つのユニバーサル イメージがあり、それに基づいてワーカー ポッド、Crontasks を含むポッド、およびアップグレード ポッドを取得することです。

まさにそんなイメージを作りました.

これには、nginx、apache/php-fpm (ビルド中に選択可能)、メール送信用の msmtp、および cron が含まれます。

イメージをアセンブルするとき、サイトのコード ベース全体が /app ディレクトリにコピーされます (別の共有ストレージに移動する部分を除く)。

マイクロサービス、サービス

ワーカーポッド:

• nginx を含むコンテナ + コンテナ apache/php-fpm + msmtp
• msmtpを別のマイクロサービスに移動するのはうまくいかなかった、Bitrixはメールを直接送信できないことに憤慨し始めている
• 各コンテナには完全なコードベースがあります。
• コンテナ内のコード変更の禁止。

cron の下:

• Apache、php、cronを使用したコンテナ
• 完全なコードベースが含まれています
• コンテナ内のコード変更の禁止

以下の下でアップグレードします:

• nginx コンテナ + apache/php-fpm コンテナ + msmtp
• コンテナ内のコードを変更することは禁止されていません

セッションストレージ

Bitrix キャッシュ ストレージ

もう XNUMX つ重要なことは、データベースからメールに至るまで、あらゆるものに接続するためのパスワードを kubernetes シークレットに保存していることです。 ボーナスも得られます。パスワードは、プロジェクトのコード ベースにアクセスできるすべてのユーザーではなく、シークレットへのアクセスを許可したユーザーのみに表示されます。

静電気の保存

ceph、nfs (ただし実稼働環境には nfs はお勧めしません)、クラウド プロバイダーのネットワーク ストレージなど、何でも使用できます。

ストレージは、コンテナ内でサイトの /upload/ ディレクトリおよび静的コンテンツを含む他のディレクトリに接続する必要があります。

データベース

簡単にするために、データベースを Kubernetes の外に移動することをお勧めします。 Kubernetes のベースは別個の複雑なタスクであり、スキームが桁違いに複雑になります。

セッションストレージ

私たちはmemcachedを使用します:)

セッションストレージを適切に処理し、クラスター化されており、php の session.save_path として「ネイティブ」にサポートされています。 このようなシステムは、多数の Web サーバーでクラスターを構築する際に、古典的なモノリシック アーキテクチャで何度もテストされてきました。 デプロイには Helm を使用します。

$ helm install stable/memcached --name session

php.ini - ここのイメージには、memcached にセッションを保存するための設定が含まれています

環境変数を使用して、memcached でホストに関するデータを渡しました。 https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/.
これにより、dev、stage、test、prod 環境で同じコードを使用できるようになります (それらの memcached ホスト名は異なるため、セッションに一意のホスト名を各環境に渡す必要があります)。
Bitrix キャッシュ ストレージ

すべてのポッドが書き込みおよび読み取りできるフォールト トレラントなストレージが必要です。

memcached も使用します。
このソリューションは Bitrix 自体によって推奨されています。

$ helm install stable/memcached --name cache

bitrix/.settings_extra.php - ここ Bitrix では、キャッシュの保存場所が指定されています

環境変数も使用します。

クロンタスキー

Kubernetes で Crontask を実行するには、さまざまなアプローチがあります。

• Crontasks を実行するためのポッドを使用した個別のデプロイメント
• crontask を実行するための cronjob (これが Web アプリの場合 - wget を使用) https://$host$cronjobname、またはワーカー ポッドの XNUMX つ内の kubectl exec など)
• 等々

最も正しい方法について議論することもできますが、この場合は「Crontasks 用のポッドを使用した個別のデプロイメント」というオプションを選択しました。

それがどのように行われるか：

• ConfigMap または config/addcron ファイル経由で cron タスクを追加します
• あるインスタンスでは、ワーカー ポッドと同一のコンテナを起動し、その中でクラウン タスクの実行を許可します。
• 同じコードベースが使用されるため、統合のおかげでコンテナの組み立てが簡単になります

得られるメリット:

• 開発者の環境（docker）と同じ環境でCrontasksを動作させています。
• Crontasks は Kubernetes 用に「書き直す」必要はなく、以前と同じ形式および同じコードベースで動作します。
• cron タスクは、管理者だけでなく、運用ブランチへのコミット権限を持つすべてのチーム メンバーが追加できます。

Southbridge K8SDeploy モジュールと管理パネルからのコード編集

アップグレードについて話していましたか？
そこに交通を誘導するにはどうすればよいでしょうか?
万歳、私たちはこのモジュールを PHP で書きました :) これは Bitrix の小さな古典的なモジュールです。 まだ一般には公開されていませんが、公開する予定です。
モジュールは Bitrix の通常のモジュールと同様にインストールされます。

そしてそれは次のようになります:

これにより、サイト管理者を識別する Cookie を設定し、Kubernetes がアップグレード ポッドにトラフィックを送信できるようになります。

変更が完了したら、「git Push」をクリックする必要があります。コードの変更が git に送信され、システムは新しいバージョンのコードを含むイメージを構築し、それをクラスター全体に「ロールアウト」し、古いポッドを置き換えます。 。

はい、これは少し面倒ですが、同時にマイクロサービス アーキテクチャを維持し、管理パネルからコードを修正する Bitrix ユーザーのお気に入りの機会を奪うことはしません。 結局のところ、これはオプションであり、コード編集の問題は別の方法で解決できます。

ヘルムチャート

Kubernetes 上でアプリケーションを構築するには、通常、Helm パッケージ マネージャーを使用します。
Kubernetes の Bitrix ソリューションのために、当社の主要なシステム管理者である Sergey Bondarev が特別な Helm チャートを作成しました。

ワーカー、アップグレード、cron ポッドを構築し、イングレス、サービスを構成し、Kubernetes シークレットからポッドに変数を転送します。

コードを Gitlab に保存し、Helm ビルドも Gitlab から実行します。

要するにこんな感じです

$ 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 は環境の新しいバージョンをデプロイするパイプラインを起動します。

ステージ：

• build (新しい Docker イメージのビルド)
• テスト（テスト）
• クリーンアップ (テスト環境の削除)
• プッシュ (Docker レジストリに送信します)
• デプロイ (Helm 経由でアプリケーションを Kubernetes にデプロイします)。

万歳、準備が整ったので実装してみましょう。
そうですね、何かあれば質問してください。

それで、私たちは何をしましたか

技術的な観点から:

• Docker化されたBitrix。
• Bitrix をコンテナに「カット」し、それぞれが最小限の機能を実行します。
• コンテナのステートレス状態を実現しました。
• Kubernetes での Bitrix の更新に関する問題を解決しました。
• すべての Bitrix 機能は (ほぼすべて) 動作し続けました。
• Kubernetes へのデプロイとバージョン間のロールバックに取り組みました。

ビジネスの観点から:

• 耐障害性。
• Kubernetes ツール (Gitlab CI との簡単な統合、シームレスなデプロイメントなど)。
• 秘密のパスワード (パスワードへのアクセスを直接許可された人のみに表示されます)。
• 単一のインフラストラクチャ内に追加の環境 (開発、テストなど) を作成すると便利です。

出所： habr.com