中小規模のチーム向けの Docker ベースの DevOps プラクティス

私が所属する技術チームは、数十のプロジェクトの開発と保守を担当しています。各プロジェクトには、少なくとも 4 つの環境 (開発、QA、非表示、製品) があり、数百台のマシンがあります。私たちはさまざまなシステム間を行き来しながら、さまざまな些細な問題を解決するのに忙しくしています。どうすれば私たちはこうした些細なことから解放されるのでしょうか? DevOps が私たちの唯一の選択肢になりました。

この記事は、現在の環境とチーム規模に基づいた DevOps の実践の概要です。このソリューションは理解しやすく、実装も簡単で、大きな効果があります。

実装

まずフローチャートを見てみましょう。

エンジニアはローカルで開発し、開発が完了したらコードをコード リポジトリに送信します。これにより、継続的な統合とデプロイメントのために Jenkins が自動的にトリガーされます。展開が完了すると、結果のメールが届きます。プロジェクトの運用中は、ログ システムを通じてプログラム ログを表示でき、異常が発生すると監視システムがトリガーされてアラームが送信されます。エンジニアは独立してオンラインになった後、コーディングから結果のフィードバックまですべてのタスクを完了でき、完全なクローズドループを形成できます。運用と保守は、プロセス全体にわたるツール チェーンを提供し、異常な状況への対処を支援する責任を負います。作業負荷が軽減され、効率が向上します。

Jenkins デプロイメントの自動トリガーは、SVN および GIT フックを通じて実現されます。自動的にトリガーされるかどうかは、プロジェクトの内部コミュニケーションによって異なります。現在、自動トリガーはありません。これは、テスト中に自動的にトリガーされるデプロイメントによって QA が中断されることを望まないためです。ただし、Jenkins で手動で実行をトリガーすることも便利です。

Jenkins は SVN からコードを取得し、コンパイルし、JS/CSS をマージして圧縮し、その他の初期化操作を実行し、オンラインで実行される最終的なコード パッケージを生成し、Dockerfile を通じてイメージにパッケージ化して Docker Hub にアップロードし、Kubernetes ローリング アップデートをトリガーします。

イメージにはベースイメージ + プロジェクトコードが含まれています。ベースイメージは、プロジェクトの動作環境に合わせてパッケージ化された最小限の動作環境（プロジェクトコードを除く）です。プロジェクトが依存するさまざまなテクノロジー スタックに応じて、nginx サービスを含むベース イメージや jdk+tomcat を含むベース イメージなど、さまざまな種類のベース イメージをパッケージ化しました。

プログラムがエラーでオンラインになったり、バグが短時間で解決できない場合は、Jenkins を介して以前のイメージ バージョンにすばやくロールバックできるため、非常に便利です。

トラフィックが突然増加した場合は、Kubernetesを介してコンテナのコピー数をすばやく調整できます。

ソフトウェアとツール

コード管理: svn、git

継続的インテグレーション: Jenkins、シェル、Python

Docker 化: docker、harbor、kubernetes

監視アラーム: zabbix、prometheus

ログシステム: filebeat、kafka、logstash、elasticsearch、kibana

コード管理

ほとんどのプロジェクトは依然として SVN を通じて管理されています。ここでは SVN を例に挙げます。各プロジェクトには、dev、trunk、releases の 3 つのコード行があります。

dev:ローカル開発。関数またはタスクを開発した後、それを dev ブランチに送信し、自己テストのために dev 環境にデプロイできます。

トランク:大規模な機能が開発され、リリースが計画されている場合、コードはトランク ブランチにマージされ、QA によってトランク環境にデプロイされて詳細なテストが行​​われます。

リリース: QA テストに合格し、プロジェクトがオンラインになる場合、コードはリリース ブランチにマージされ、非表示の環境 (シミュレーション環境、すべての構成、コードなどがオンライン環境と一致している) が再度回帰テストのためにデプロイされます。回帰テストに合格すると、製品の正式な環境が起動されます。

一部のプロジェクトはバージョンに基づいてリリースされます。コードがリリースにマージされた後、ブランチ/タグを通じて非表示のテストにデプロイされます。

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

このステップの主なタスクは、要件に従ってソース コードを最終的なオンライン プロジェクトにパッケージ化することです。 SVN からのコードの取得、ソース コードのコンパイル、静的リソース ファイルのマージと圧縮など、作業のほとんどは、シェルと Python で記述されたスクリプトによって完了します。Jenkins を使用して、多数の散在するステップを 1 つの完全なプロセスにまとめます。運用や保守の方はこの部分についてはよくご存知かと思いますが、ここでは詳しく紹介しません。

ドッカー化

Docker は当社のソリューション全体において非常に重要な部分です。簡単に導入できます。すべての環境で同じ Docker イメージを使用することで、環境の統一性も確保され、開発環境は正常に動作しているのにオンライン操作でエラーが報告されるという状況が大幅に軽減されます。同時に、プロジェクトの負荷に応じてリソースの使用量をリアルタイムで調整できるため、コストを節約できます。

Dockerfile: Dockerfileを書いてイメージをパッケージ化する

ハーバー:簡単に統合できる Web インターフェースと API インターフェースを備えた Docker Hub イメージ リポジトリとして機能します。

kubernetes: kubernetes (k8s) は Docker インスタンスをクラスターに統合し、イメージのコピーの送信、アップグレード、ロールバック、増加、削除を容易にします。また、イングレス外部ネットワーク アクセスも提供します。これは比較的重い部分ですが、あまり高度な機能は使用せず、上記で述べた基本的な機能の一部のみを使用しています。 k8sの二次開発やカスタマイズは必要なく、デプロイして使用するだけなので、運用や保守も技術的に難しくありません。

監視アラーム

監視とアラームは、運用および保守プロセス全体において非常に重要です。不測の事態に備え、障害の発生を減らし、障害の解決を早めることができます。この部分も運用・保守の基本となる部分ですが、ここでは詳しく紹介しません。

Zabbix:ホストマシンはZabbixを通じて一様に監視され、警告されます

Prometheus: Docker コンテナの動作は Prometheus を通じて監視され、警告されます (現在未完了)

ログシステム

ヘラジカ伐採システムは、運用と保守にとって本当にありがたいものです。使った人はみんな良いと言っています。これからは、開発者から「xx、オンライン ログを取得するのを手伝ってください」と言われることを聞く必要がなくなります。私たちが使用するアーキテクチャは、filebeat/rsyslog --> kafka --> logstash --> elasticsearch --> kibana です。

filebeat /rsyslog:クライアントは filebeat または rsyslog を通じてログを収集します。 Filebeat は Go で開発されたプログラムです。デプロイが非常に簡単で、Docker と完全に一致します。当社の Docker ベース イメージには、デフォルトで構成ファイルを初期化する filebeat サービスがあります。後でプロジェクト コードを統合するときに追加の構成は必要ありません。 rsyslog を使用する利点は、ほとんどのシステムに rsyslog サービスが付属しているため、ログを収集するために追加のプログラムをインストールする必要がないことです。ただし、rsyslog は omkafka モジュールを使用してデータを kafka に転送する必要があります。 Omkafka には rsyslog バージョンに対する要件があります。ほとんどのシステムで rsyslog のバージョンをアップグレードするのは面倒なので、断念しました。

Kafka: Kafka はログ データを処理するように設計されています。 Kafka クラスターを形成するために 3 台のマシンを使用します。同時に、単一のポイントを回避するために、1 つのトピックが複数のグループに対応します。

Logstash: Kafka からデータを取得し、フィルタリング後に Elasticsearch に書き込みます。 Kafka の紹介時に、1 つのトピックが複数のグループに対応すると説明されているのはなぜでしょうか。主な目的は、1つのグループを1つのlogstashインデックスに対応させ、logstashの単一ポイントを解決することです。

Elasticsearch:フィルタリングされたデータを保存し、単一ポイントを避けるために3ノードクラスターも使用します。

Kibana:必要なデータを簡単に検索できる視覚化ツール。同僚も一目でわかるさまざまなレポートを作成できます。

要約する

1. サポート:すべての関係者のサポートを得ることで、プロジェクトは成功の半分まで到達しました。バーベキューで解決できない問題はありません。もしあれば、バーベキューは2つで十分です。
2. 仕様:多数のプロジェクトや大規模システムには、自動化の基礎となる仕様が必要です。
3. ドキュメント:実装プロセス、使用方法、保守方法に関する詳細なドキュメントを保管する必要があります。
4. トレーニング:運用保守で使用されない Jenkins や ELK などのツールについては、ユーザーに対応するトレーニングと共有を提供する必要があります。もちろん、運用・保守スタッフもプロジェクトのさまざまな詳細を共有する必要があります。