Docker をベースにした継続的デリバリープラットフォームの構築実践

[[212695]]

スタートアップ企業であり DevOps エンジニアである私たちは、次のような問題に直面しました。

1. ハードウェアリソースの利用の問題により、コストの無駄が生じる

ウェブサイトの機能には、コンピューティング、IO の読み取りと書き込み、ネットワーク、メモリなど、さまざまなビジネスシナリオがあります。アプリケーションを集中的に展開すると、リソースの使用率が不合理になります。たとえば、マシンに展開されているサービスがすべてメモリを大量に消費する場合、CPU リソースは簡単に浪費されてしまいます。

2. 単一の物理マシン上の複数のアプリケーションを効果的に分離することができず、リソースの奪取やアプリケーションの相互影響が生じる

物理マシン上で複数のアプリケーションを実行する場合、使用される CPU、メモリ、プロセスを制限することはできません。アプリケーションにリソースのプリエンプションに関する問題がある場合、連鎖反応が発生し、最終的には Web サイトの一部の機能が利用できなくなります。

3. 複雑な環境とバージョン管理、オンライン展開プロセスの欠如、トラブルシューティングの複雑さの増大

非標準の内部開発プロセスにより、コードテストまたはオンラインリリース中に一部の構成項目とシステムパラメータが任意に調整され、リリース中に増分リリースが実行されます。問題が発生すると、テストコードとオンラインで実行されているコードに不整合が生じ、サービス開始のリスクが高まり、オンラインサービスの障害のトラブルシューティングが困難になります。

4. 不安定な環境、高い移行コスト、オンラインリスクの増大

開発プロセスでは、複数のプロジェクトの並行開発やサービスの依存関係の問題が発生します。環境とバージョンが非常に複雑であるため、環境を迅速に構築して移行することは不可能であり、テスト環境でテストのオンラインプロセスをシミュレートすることができません。多くの学生がオンライン環境でテストを行っていますが、これは潜在的なリスクが高く、開発効率を低下させます。

5. 従来の仮想マシンと物理マシンは、大きなスペースを占有し、起動が遅く、管理が複雑です。

従来の仮想マシンと物理マシンでは、起動プロセス中にカーネルをロードし、カーネルを実行して初期化するため、起動プロセスに時間がかかり、管理プロセス中にさまざまな管理上の問題が発生します。

運用保守技術チームは、Docker コンテナ技術をベースに、Wuage ウェブサイト用のコンテナクラウドプラットフォームを開発しました。アプリケーションサービスの 95% は、コンテナクラウドプラットフォームを通じてコンテナにデプロイされています。これらのアプリケーションは、オンデマンドのビジネス拡張と数秒でのスケーリングをサポートし、ユーザーフレンドリーなインタラクションを提供し、テストと本番のリリースプロセスを標準化し、開発者とテスターを基本的な環境構成とリリースから解放して、独自のプロジェクト開発とテストに集中できるようにします。この記事では、Wuage コンテナクラウドプラットフォームの実践と Docker コンテナテクノロジーを組み合わせて、まず 7*24 時間の「ワンストップ」継続配信を実現し、製品の発売を実現する方法を紹介します。

コンテナクラウドプラットフォームアーキテクチャ図

1. Dockerイメージの標準化

ご存知のとおり、Docker イメージは階層化されています。画像のレイヤー化について合意します。

最初のレイヤーはオペレーティングシステムレイヤーで、CentOS/Alpine などの基本イメージで構成され、いくつかの共通の基本コンポーネントをインストールします。
2 番目の層はミドルウェア層です。アプリケーションに応じて、Nginx、Tomcat など、動作に必要なさまざまなミドルウェアと依存ソフトウェアパッケージがインストールされます。
3 番目の層はアプリケーション層で、パッケージ化されたアプリケーションコードのみが含まれます。

Docker イメージの階層化

体験のまとめ: イメージを小さくして、より速くプッシュするにはどうすればよいでしょうか?

最適化前後のDockerイメージの比較

Dockerfile はアプリケーションイメージを構築します。ミドルウェア層にインストールする必要があるソフトウェアパッケージに遭遇した場合は、可能な限り、パッケージ管理ツール (yum など) を使用するか、git clone モードでソースコードパッケージをダウンロードしてインストールしてください。目的は、ソフトウェアパッケージのコピーとインストールを同じレイヤーで制御することです。ソフトウェアが正常に展開された後、いくつかの不要な rpm パッケージまたはソースコードパッケージがクリアされ、基本イメージのサイズが小さくなります。
Java アプリケーションイメージには、イメージ内の JDK ソフトウェアパッケージが含まれていません。 JDK は各ホストにデプロイされます。イメージを実行すると、ディレクトリをマウントすることで、ホスト上の Java ホームディレクトリがコンテナーで指定されたディレクトリにマウントされます。ベースイメージが非常に大きくなるためです。
アプリケーションイメージを構築するとき、Docker はこれら 2 つのレイヤーをキャッシュして直接使用し、コードが変更されたアプリケーションレイヤーのみを再作成します。これにより、アプリケーションイメージのビルド速度と、ビルド成功後のイメージリポジトリへのプッシュ速度が向上し、全体的なプロセスからのアプリケーションの展開効率が向上します。

2. コンテナオーケストレーション管理

編集ツールの選択:

Dockerオーケストレーションツールの比較

Rancher のグラフィカル管理インターフェースは、導入が簡単で便利です。 AD、LDAP、GitHub と統合し、ユーザーまたはユーザーグループに基づいてアクセス制御を実行し、システムのオーケストレーションツールを Kubernetes または Swarm に迅速にアップグレードできます。同時に、サポートを提供する専門の技術チームがあり、コンテナ技術の導入の難しさが軽減されます。

Rancher アーキテクチャ図

上記の利点に基づいて、コンテナクラウドプラットフォームのオーケストレーションツールとして Rancher を選択しました。アプリケーションコンテナインスタンスの統合オーケストレーションとスケジューリングを実行する場合、Docker-Compose コンポーネントと組み合わせて、複数のホストで同時にスケジューリング操作を実行できます。同時に、サービスアクセスがピークに達したときや谷に達したときに、独自の rancher-compose.yml ファイルを使用して「SCALE」機能を呼び出し、アプリケーションクラスターを動的に拡張および縮小し、アプリケーションが必要に応じてさまざまな要求を処理できるようにします。 https:/zhuanlan.zhihu.com/p/29093407

コンテナネットワークモデルの選択:

Docker ネットワークの比較

バックエンド開発は Alibaba の HSF フレームワークに基づいているため、プロデューサーとコンシューマー間のネットワークが到達可能である必要があり、ネットワークに高い要件が課され、登録とプルサービスに実際の IP アドレスを使用する必要があります。そのため、コンテナネットワークを選択する際には、ホストモードを使用しました。コンテナの起動プロセス中に、ホストをチェックし、競合を避けるためにコンテナに別のポートを割り当てるスクリプトが実行されます。

3. 継続的インテグレーションと継続的デプロイメント

継続的インテグレーション、コード送信ステータスの監視、コードの継続的インテグレーション、インテグレーションプロセス中のユニットテストの実行、Sonar とセキュリティツールを使用したコードの静的スキャン、開発者への結果の通知と同時のインテグレーション環境のデプロイ、デプロイ成功後の自動テストのトリガー (自動テストの部分は後で更新されます)。

継続的インテグレーション

静的スキャン結果:

静的スキャン結果

継続的デプロイメントは、パッケージを必要な場所に迅速にデプロイできるようにする非常に重要な機能です。プラットフォームは分散型の構築と展開を採用しています。マスターは複数のスレーブノードを管理し、各スレーブノードは異なる環境に属します。マスターにプラグインをインストールおよび更新し、ジョブを作成し、各開発チームの権限を管理します。スレーブはジョブを実行するために使用されます。

継続的デプロイメント

上記のアーキテクチャに基づいて、継続的なデプロイメント仕様のプロセスを定義しました。

開発者は GitLab にコードを送信します。
プロジェクトコードと構成項目ファイルをプルし、コンパイルタスクを実行します。
ベースイメージをプルし、コンパイルされたアプリケーションパッケージを挿入して最新のアプリケーションイメージを生成し、イメージウェアハウスにプッシュします。
現在のアプリケーションとその環境に基づいてカスタマイズされた docker-compose.yml ファイルを生成し、このファイルに基づいて rancher-compose コマンドを実行し、アプリケーションイメージをプレプロダクション環境 (関連する構成、サービス依存関係があり、本番環境と同じである、本番リリース前のテスト環境) にデプロイします。
プレリリース環境のテストに合格すると、アプリケーションイメージがオンライン環境にデプロイされ、テスト結果がバックエンドテスターに通知されます。

4. コンテナの運用と管理

アプリケーションコンテナーがオンライン環境にデプロイされました。コンテナのライフサイクル全体において、次の 2 つの問題に対処する必要があります。

アプリケーションによって生成された操作ログやその他の業務ログを保存する方法。
バックエンドサービスの変更後に nginx が構成の更新を自動的に検出して完了できるようにする方法。

5. ログ管理

コンテナが実行されると、読み取り専用レイヤーの上に読み取り/書き込みレイヤーが作成されます。アプリケーションへのすべての書き込み操作はこのレイヤーで実行されます。コンテナを再起動すると、読み取り/書き込み層のデータ（ログを含む）もクリアされます。このような問題は、コンテナ内のログディレクトリをホストにマウントすることで解決できますが、コンテナが複数のホスト間を頻繁に移動すると、各ホストにアプリケーション名を含む部分的なログが存在することになり、開発者が問題を確認してトラブルシューティングすることが難しくなります。

要約すると、ログサービスプラットフォームは、Wuage Web サイトのログウェアハウスとして、アプリケーション操作中に生成されたログを均一に保存し、複数のクエリ操作をサポートします。

ログ管理

ログサービスの管理インターフェイスでログ収集パスを設定し、コンテナーにエージェントをデプロイしてアプリケーションログを Logstore に均一に配信し、Logstore でフルテキストインデックスと単語区切り文字を設定することで、開発者はキーワードで目的のログコンテンツを検索およびクエリできます。

体験のまとめ: 重複したログ収集を回避するにはどうすればよいでしょうか?

ログサービスエージェントは、構成ファイル「ilogtailconfig.json」に構成パラメータ「checkpoint_filename」を追加し、チェックポイントファイルの絶対パスを指定して、このパスをホストディレクトリにマウントする必要があります。これにより、コンテナーの再起動時にチェックポイントファイルが失われず、重複した収集が発生しなくなります。

6. サービスの登録

etcd は、高可用性と強力な一貫性を備えたキーバリューストレージウェアハウスです。ファイルシステムに似たツリー構造を使用し、すべてのデータは「/」で始まります。 etcd データは、キーとディレクトリの 2 つのタイプに分かれています。キーには個々の文字列値が保存され、ディレクトリにはキーのコレクションまたはその他のサブディレクトリが保存されます。

アプリ登録

Wuage 環境では、etcd に登録された各アプリケーションサービスのルートディレクトリの名前は「/${APPNAME}${ENVIRONMENT}」になります。ルートディレクトリには各アプリケーションインスタンスのキー情報が保存され、すべて「${IP}-${PORT}」の形式で名前が付けられます。

次の図は、上記の規則を使用して etcd に保存されたアプリケーションインスタンスのデータ構造を示しています。

etcd データストレージ構造

get メソッドを使用して etcd にリクエストを送信していることがわかります。要求は、プレリリース環境 (PRE) に展開された検索サービス (検索) に対するものです。ルートディレクトリ "/search_PRE" には、アプリケーションインスタンスが 1 つだけ保存されます。このインスタンスのキーは「172.18.100.31-86」です。対応する値は「172.18.100.31:86」です。登録プロセス全体は次のとおりです。

コードを通じてコンテナアプリケーションのランダムポートを生成し、それをホストマシンで現在使用されているポートと比較し、ポートの競合がないことを確認した後、プログラム構成ファイルに書き込みます。
Python で記述されたサービス登録ツールと etcd モジュールをスクリプトに統合し、前の手順で取得した IP アドレスとランダムポートをパラメーターとしてサービス登録ツールに渡します。
アプリケーションが完全に起動すると、サービス登録ツールは合意されたデータ構造でアプリケーションインスタンスを etcd クラスターに書き込み、サービス登録を完了します。
コンテナは、生存を報告し、TTL 時間を更新するために、定期的に etcd にハートビートを送信します。
コンテナスクリプトは、Rancher からアプリケーションインスタンスに送信された信号端末シグナルをキャプチャし、シグナルを受信した後、インスタンスデータを削除するために etcd に削除要求を送信します。

注: TTL に基づいて、アクティブクリア機能が追加されます。サービスが正常にリリースされると、ttl 時間を待たずに、etcd 上の登録情報を即時クリアできます。

学んだ教訓: コンテナが再起動されたり、誤って破棄されたりした場合に、このプロセス中にコンテナとレジストリが何を行うかを見てみましょう。

アプリケーションは、キーと値を登録するときに TTL タイムアウト属性を持ちます。これは、サービスクラスター内のインスタンスがクラッシュすると、etcd に登録されている情報も無効になるためです。クリアしないと、無効な情報はゴミデータとなり永久に保存されてしまいます。構成管理ツールもこれを通常のデータとして読み取り、Web サーバーの構成ファイルに書き込みます。 etcd に保存されているデータが常に有効であることを保証するには、etcd が無効なインスタンス情報を積極的に解放する必要があります。登録センターの更新メカニズムを見てみましょう。コードは直接提供されます:

 #!/usr/bin/env
パイソン
etcdをインポートする
インポートシステム
arg_l = sys.argv [1:]
 etcd etcd_clt =etcd.Client(ホスト= '172.18.0.7' )
定義
set_key(キー、値、 ttl = 10 ):
試す：
戻る
etcd_clt.write(キー、値、TTL)
 TypeErrorを除く:
 「キーまたは値が null です」と出力します
定義
refresh_key(キー、 ttl = 10 ):
試す：
戻る
etcd_clt.refresh(キー、TTL)
 TypeErrorを除く:
 「キーがnullです」と出力します
定義
del_key(キー):
試す：
 etcd_clt.delete(キー) を返す
TypeErrorを除く:
 「キーがnullです」と出力します
arg_lの場合:
 len(arg_l) == 3の場合:
キー、値、 ttl = arg_l  
 set_key(キー、値、TTL)
 elif len(arg_l) == 2:
キー、 ttl = arg_l  
 refresh_key(キー、TTL)
 elif len(arg_l) == 1:
キー= arg_l [0]
 del_key(キー)
それ以外：
 TypeErrorが発生します。「3つだけ
ここではパラメータが必要です'
それ以外：
例外を発生させる('args is null')

7. サービス検出

Confd は、バックエンドデータソースとして etcd をサポートする軽量の構成管理ツールです。データソースデータを読み取ることで、ローカル構成ファイルが最新であることを確認します。さらに、構成ファイルを更新した後、構成ファイルの構文の妥当性をチェックし、アプリケーションを再ロードして構成を有効にすることもできます。ここで注目すべきは、Confd はデータソースとして Rancher をサポートしていますが、使いやすさやスケーラビリティなどの理由から、最終的には etcd を選択したということです。

ほとんどのデプロイメント方法と同様に、Confd は Web サーバーが配置されている ECS にデプロイされるため、データの変更を検出した後、Confd は構成ファイルを更新し、プログラムを適時に再起動できます。 Confd の関連設定ファイルとテンプレートファイルは、デフォルトのパス /etc/confd に展開されます。ディレクトリ構造は次のとおりです。

 /etc/confd/
 ├──conf.d
 ├── confd.toml
 └── テンプレート

confd.toml は TOML 形式で記述された Confd のメイン設定ファイルです。私たちの etcd は複数のノードを持つクラスターにデプロイされており、Confd の指示を長くて退屈なものにしたくないので、この構成ファイルに interval や nodes などのオプションを記述します。

cond.d ディレクトリには、Web サーバーのテンプレート構成ソースファイルも保存されます。これらも TOML 形式で記述されています。このファイルは、アプリケーションテンプレート構成ファイルパス (src)、アプリケーション構成ファイルパス (dest)、データソースキー情報 (keys) などを指定するために使用されます。

Templates ディレクトリには、Web サーバーの下にある各アプリケーションのテンプレート構成ファイルが格納されます。これは、Go でサポートされているテキスト/テンプレート言語形式で記述されています。 confd は etcd から最新のアプリケーション登録情報を読み取った後、次のステートメントを使用してそれをテンプレート構成ファイルに書き込みます。

 {{範囲 getvs "/${APP_NAME}/*"}}
サーバー {{.}};
 {{終わり}}

サービス検出

スーパーバイザーを通じて Confd プロセスを管理します。実行後、Confd は 5 秒ごとに etcd をポーリングします。アプリケーションサービスの K/V が更新されると、Confd はアプリケーションの etcd に保存されているデータを読み取り、テンプレート構成ファイルに書き込み、アプリケーション構成ファイルを生成し、最後に Confd によって構成ファイルをターゲットパスに書き込み、Nginx プログラムを再ロードして構成を有効にします。

<<: 中国オープンソースクラウドコンピューティングユーザーカンファレンス：オープンソースクラウドアーキテクチャがトレンドに

>>: オートナビは、何千人もの将来の交通専門家を育成することを目標に、産業界、学界、研究機関の統合に取り組んでいます。