2020年にデータベースの変更を開発、デバッグ、提供するプロセスをどのように発明したか

中庭は2020年で、「Kubernetesが答えです！」、「Microservices！」、「Service mesh！」、「Sesuritiポリシー！」などのバックグラウンドノイズを聞くことに慣れています。周りの誰もが明るい未来に向かって走っています。



当社は、アプリケーションよりもデータベースに関して、より保守的なアプローチを採用しています。データベースはKubernetesではなく、ハードウェアまたは仮想マシンで回転しています。支払い処理データベースを変更するための確立されたプロセスがあります。これには、多くの自動チェック、大規模なレビュー、およびDBAの参加によるリリースが含まれます。この場合のチェックの数と関係者は、市場投入までの時間に悪影響を及ぼします。一方、それはデバッグされており、本番環境に確実に変更を加えることができるため、何かが壊れる可能性を最小限に抑えることができます。そして、何かが壊れた場合、適切な人がすでに修理プロセスに含まれています。このアプローチにより、会社のメインサービスの作業がより安定します。



PostgreSQL上のマイクロサービス用の新しいリレーショナルデータベースのほとんどを開始します。Oracleのデバッグされたプロセスは、信頼性はありますが、小さなデータベースでは不必要に複雑になります。困難なプロセスを過去から明るい未来に引きずり込みたいと思う人は誰もいません。誰も前もって明るい未来のためのプロセスに取り組み始めませんでした。その結果、標準とraznozhopitsuが不足しました。 これがどのような問題を引き起こし、どのように解決したかを知りたい場合は、catへようこそ。

私たちが解決した問題

統一されたバージョン管理基準はありません

最良の場合、これらは、マイクロサービスのあるリポジトリのdbディレクトリのどこかにあるDDLSQLファイルです。これがデータベースの現在の状態であり、テストと本番で異なり、データベーススキーマの参照スクリプトがない場合は非常に悪いです。

デバッグ中に、テストベースを粉砕します

「私は今、テストデータベースを少し揺さぶっています、そこで心配しないでください」-そしてテストデータベースに新しく書かれたスキーマ変更コードをデバッグしに行きました。時間がかかる場合がありますが、その間、テスト回路は機能しません。



同時に、他のマイクロサービスがマイクロサービスと相互作用する部分でテスト回路が破損する可能性があります。マイクロサービスのベースは開発者が破壊しました。

DAOメソッドはテストの対象外であり、CIで検証されていません

開発およびデバッグ時に、DAOメソッドは、外側のハンドルを数層上に引くことによって呼び出されます。これにより、マイクロサービスとデータベース間の特定の相互作用ではなく、ビジネスロジックのシナリオ全体が公開されます。



将来何も崩壊しないという保証はありません。マイクロサービスの品質と保守性が低下します。

メディアの非同形性

変更ループがテストと本番環境で異なる方法で配信される場合、同じように機能するかどうかはわかりません。特に、開発とデバッグが実際にテストで実行される場合。



テスト上のオブジェクトは、開発者またはアプリケーションのアカウントで作成できます。助成金はランダムに渡され、通常はすべての特権を付与します。アプリケーションの助成金は、「ログにエラーが表示されます-助成金を出します」という原則に基づいて発行されます。助成金はリリース時に忘れられることがよくあります。リリース後、smokテストがすべての新機能をカバーしておらず、助成金の欠如がすぐに発生しない場合があります。

生産に転がる重くて壊れやすいプロセス

本番環境へのロールインは手動で行われましたが、Oracleのプロセスと同様に、DBA、リリースマネージャーの承認、リリースエンジニアによるロールフォワードが行われました。



これにより、リリースが遅くなります。また、問題が発生した場合、ダウンタイムが増加し、開発者のデータベースへのアクセスが複雑になります。Oracle以外のパッチ設定標準がなく、テストが最後まで行われていたため、exec.sqlスクリプトとrollback.sqlスクリプトはテストでテストされないことがよくありました。



したがって、開発者は、このプロセスをまったく行わずに、重要ではないサービスに変更を加えることがあります。

どうすれば良くなることができますか

Dockerコンテナ内のローカルDBでのデバッグ

一部の人にとっては、この記事で説明されているすべての技術的解決策は明白に思えるかもしれません。しかし、どういうわけか、毎年、同じレーキを熱心に踏む人がいます。



アプリケーションコードを記述してデバッグするためにssh経由でテストサーバーにアクセスすることはありませんか？テストDBインスタンスでデータベースコードを開発およびデバッグするのはばかげていると思います。例外はありますが、データベースをローカルで立ち上げることは非常に難しい場合があります。しかし、通常、軽量でレガシーではないものについて話している場合、ローカルでベースを上げて、すべての移行を一貫してロールすることは難しくありません。その見返りとして、他の開発者によって行き詰まることなく、アクセスが失われることなく、開発に必要な権限を持つ安定したインスタンスを自分の側で取得できます。



ローカルデータベースを簡単に起動できる例を次に示します



。2行のDockerfileを作成してみましょう。

FROM postgres:12.3
ADD init.sql /docker-entrypoint-initdb.d/

init.sqlで、「クリーンな」データベースを作成します。これは、テストと本番の両方で取得する予定です。次のものが含まれている必要があります。

• スキーマの所有者とスキーマ自体。
• スキーマを使用する権限を持つアプリケーションユーザー。
• 必要な拡張機能

便宜上、dbタスクをMakefileに追加できます。これにより、コンテナーがベースで（再）開始され、接続用にポートが突き出ます。

db:
    docker container rm -f my_awesome_service_db || true
    docker build -t my_awesome_service_db docker/db/.
    docker run -d --name my_awesome_service_db -p 5433:5432 my_awesome_service_db

業界標準のバージョン変更セット

また、明らかなように見えます。移行を記述し、バージョン制御システムに保持する必要があります。しかし、バインディングのない「裸の」sqlスクリプトをよく目にします。そしてこれは、誰が、何を、いつポンプしたかというロールバックとロールバックを制御できないことを意味します。構造が変更されている可能性があるため、SQLスクリプトをテストおよび本番データベースで実行できるという保証すらありません。



一般的に、あなたはコントロールが必要です。移行システムはほぼ制御です。

異なるデータベーススキーマバージョン管理システムの比較については説明しません。FlyWay vsLiquibaseはこの記事のトピックではありません。Liquibaseを選びました。



私たちのバージョン：

• DDL-データベースオブジェクトの構造（テーブルの作成）。
• ルックアップテーブルのDMLコンテンツ（挿入、更新）。
• UZアプリケーションのDCL許可（許可の選択、挿入...）。

ローカルデータベースでマイクロサービスを起動してデバッグする場合、開発者は助成金を処理する必要に直面します。そのための唯一の合法的な方法は、DCLスクリプトを変更セットに追加することです。これにより、助成金が確実に販売されます。







Liquibaseは、データベース上にdatabasechangelogテーブルを作成します。このテーブルには、ポンプアップされたチェンジセットが記録されます。

データベースにロールする必要がある変更セットの数を自動的に計算します。



データベースにロールインする必要があるいくつかのチェンジセットからスクリプトを生成する機能を備えたmavenおよびgradleプラグインがあります。

データベース移行システムのアプリケーション起動フェーズへの統合

これは、移行制御システムとアプリケーションが構築されているフレームワークの任意のアダプターである可能性があります。多くのフレームワークがあり、ORMにバンドルされています。たとえば、Ruby-On-Rails、Yii2、Nest.JS。



このメカニズムは、アプリケーションコンテキストの開始時に移行をロールするために必要です。

例えば：

1. テストデータベースでは、パッチセット001、002、003。
2. pogromistはパッチセット004、005を開発し、アプリケーションをテストにデプロイしませんでした。
3. テストにデプロイします。パッチセット004、005が展開されています。

それらが回転しない場合、アプリケーションは起動しません。ローリングアップデートは古いポッドを殺しません。



スタックはJVM + Springであり、ORMを使用していません。したがって、SpringとLiquibaseの統合が必要でした。



当社には重要なセキュリティ要件があります。アプリケーションのユーザーは、限られた一連の許可を持っている必要があり、スキーマ所有者レベルのアクセス権を持ってはなりません。Spring-Liquibaseを使用すると、スキーマ所有者ユーザーに代わって移行をロールすることができます。この場合、アプリケーションアプリケーションレベルの接続プールはLiquibaseDataSourceにアクセスできません。したがって、アプリケーションはスキーマ所有者ユーザーからアクセスを取得しません。

CIステージでのDAOテストは検証します

私たちの会社にはそのようなCIステージがあります-確認してください。この段階で、変更が内部品質基準に準拠しているかどうかがチェックされます。マイクロサービスの場合、これは通常、コードスタイルをチェックするためのリンター実行であり、バグ、ユニットテストの実行、およびコンテキストホイストを使用したアプリケーションの起動です。これで、検証段階で、データベースの移行と、アプリケーションDAOレイヤーとデータベースの相互作用を確認できます。



データベースを使用してコンテナを起動し、パッチセットをローリングすると、作業中のマシンの能力とパッチセットの数に応じて、Springコンテキストの開始時間が1.5〜10秒長くなります。



これらは実際にはユニットテストではなく、アプリケーションのDAOレイヤーをデータベースに統合するためのテストです。

データベースをマイクロサービスの一部と呼ぶことで、1つのマイクロサービスの2つの部分の統合をテストしていると言えます。外部依存関係はありません。したがって、これらのテストは安定しており、検証フェーズで実行できます。マイクロサービスとデータベースの契約を修正し、将来の改善に安心を提供します。



これは、DAOをデバッグするための便利な方法でもあります。RestControllerを呼び出して、一部のビジネスシナリオでユーザーの動作をシミュレートする代わりに、必要な引数を使用してDAOをすぐに呼び出します。





検証パイプラインでこれらのテストを実行するには、2つの関連タスクがあります。

1. ビルドエージェントは、標準のPostgreSQLポート5432または静的ポートでビジー状態になる可能性があります。テストが完了した後、誰かがベースと一緒にコンテナを出さなかったことは、あなたは決して知りません。
2. これから2番目のタスク：テストが完了した後、コンテナを消す必要があります。

TestContainers ライブラリは、これら2つのタスクを解決します。既存のドッカーイメージを使用して、データベースコンテナーをinit.sql状態にします。





開発とデバッグが理解されました。次に、データベーススキーマの変更を本番環境に配信する必要があります。

Kubernetesがその答えです！質問は何ですか？

したがって、CI / CDプロセスを自動化する必要があります。実績のあるチームシティアプローチがあります。別の記事の理由はどこにあるように思われますか？



そして、理由があります。実証済みのアプローチに加えて、大企業の退屈な問題もあります。

• 誰にとっても十分なチームシティビルダーはありません。
• ライセンスにはお金がかかります。
• virtualok buildagentsの設定は、configsとpuppetを備えたリポジトリを介して、昔ながらの方法で行われます。
• ビルダーからターゲットネットワークへのアクセスは、昔ながらの方法で行う必要があります。
• ログイン-データベースへの変更をローリングするためのパスワードも、昔ながらの方法で保存されます。

そして、このすべての「昔ながらの方法」での問題は、誰もが明るい未来に向かって走っていて、レガシーからのサポートです...あなたが知っている。それは動作し、大丈夫です。動作しません-後で処理します。いつか。今日ではありません。



明るい未来にすでに膝までの深さの脚が1つあり、Kubernetesインフラストラクチャがすでにあるとします。別のマイクロサービスを生成する機会もあります。このマイクロサービスは、このインフラストラクチャですぐに開始され、必要な構成とシークレットを取得し、必要なアクセス権を持ち、サービスメッシュインフラストラクチャに登録します。そして、このすべての幸福は、* OPSの役割を持つ人を巻き込むことなく、通常の開発者が得ることができます。Kubernetesには、ある種のサービス作業を目的とした一種のジョブワークロードがあることを思い出します。さて、私たちはKotlin + Spring-Liquibaseでアプリケーションを作成するために運転し、kuberaのJVMでのマイクロサービスのために会社に存在するインフラストラクチャを可能な限り再利用しようとしました。



次の側面を再利用しましょう。

• プロジェクトの生成。
• デプロイします。
• 設定とシークレットの配信。
• アクセス。
• ログの記録とELKへのログの配信。

私たちはそのようなパイプラインを手に入れます：クリック可能

私たちは今持っています

• チェンジセットのバージョン管理。
• 実現可能性の更新→ロールバックを確認します。
• DAOのテストを作成します。TDDに従うこともあります。テストを使用してDAOデバッグを実行します。テストは、TestContainersで新しく作成されたデータベースで実行されます。
• dockerデータベースを標準ポートでローカルに実行します。データベースに残っているものを調べてデバッグしています。必要に応じて、ローカルデータベースを手動で管理できます。
• マイクロサービスと同様に、teamcityの標準パイプラインを使用してパッチセットをテストおよび自動リリースします。パイプラインは、データベースを所有するマイクロサービスの子です。
• チームシティのデータベースからのクレジットは保存されません。また、仮想ビルダーからのアクセスについては気にしません。

多くの人にとって、これは啓示ではないことを私は知っています。しかし、あなたが読み終えたので、コメントであなたの経験を共有させていただきます。