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 とセキュリティツールを使用したコードの静的スキャン、開発者への結果の通知と同時のインテグレーション環境のデプロイ、デプロイ成功後の自動テストのトリガー (自動テストの部分は後で更新されます)。

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

静的スキャン結果:

静的スキャン結果

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

継続的デプロイメント

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

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

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

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

1. アプリケーションによって生成された操作ログやその他の業務ログを保存する方法。
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」です。登録プロセス全体は次のとおりです。

1. コードを通じてコン​​テナ アプリケーションのランダム ポートを生成し、それをホスト マシンで現在使用されているポートと比較し、ポートの競合がないことを確認した後、プログラム構成ファイルに書き込みます。
2. Python で記述されたサービス登録ツールと etcd モジュールをスクリプトに統合し、前の手順で取得した IP アドレスとランダム ポートをパラメーターとしてサービス登録ツールに渡します。
3. アプリケーションが完全に起動すると、サービス登録ツールは合意されたデータ構造でアプリケーション インスタンスを etcd クラスターに書き込み、サービス登録を完了します。
4. コンテナは、生存を報告し、TTL 時間を更新するために、定期的に etcd にハートビートを送信します。
5. コンテナ スクリプトは、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 プログラムを再ロードして構成を有効にします。