今日、多くの人がIT部門、QA、プログラマーの間の鉄のカーテンを破り、製品をより速く、より良くするためのある種の共通メカニズムを作成する方法論としてDevOpsについて話します。 DevOps開発者が直面する主なタスクは、開発展開の最大限の自動化を実現することです。 テスト、実稼働環境、およびそれらの間の移行。 したがって、この場合の主な問題の1つは、開発、テスト、および運用環境の完全な同一性を観察することです。 ネコの下で、DevOps方法論の統合中にいくつかの企業で使用したこの問題の実用的なソリューションの例を紹介します。
これは実用的な例なので、この問題を解決するときに設定される制限についてすぐに説明します。
- 大規模なコミュニティで人気のあるrpmベースのディストリビューションの安定したバージョン。OSに関連する一般的な問題の解決に役立ちます。 現在最も人気のあるrpmベースのディストリビューションであるCentOSが選ばれました。
- 環境をバージョン管理する機能。 プログラマーは、CentOS 5およびCentOS 6で一度に製品のいくつかのフォークを開発しています。
- 製品の正しい操作と展開に必要なソフトウェアのセット（これは一例であり、実際にはリストはもっと大きかった）：
CentOS 5の場合：
- python => 2.4
- python-ipy
- python-simplejson
- mysql-server> = 5.0
CentOS 6の場合：
- python => 2.6
- python-ipy
- python-simplejson
- mysql-server> = 5.1
私が最初にこの問題を提起したとき、既製の解決策はありませんでしたが、これはかなり具体的なポイントであり、一般的な解決策はまだ見つかりませんでした。 原則として、これらは特定の製品向けに強化されたいくつかの内部スクリプトです。
このソリューションを統合するために、私はbuild-toolsユーティリティhttps://github.com/scopenco/build-toolsを開発しました。これにより、XML仕様（ロール）に基づくメタパッケージ（プロジェクトパッケージ）でRHEL 、 CentOS 、 Fedora 、 Scientific yumリポジトリを作成できます。 ロールは、必要なパッケージとリポジトリのセットを記述します。これらのパッケージは、依存関係とともにローカルyumリポジトリ（ビルド）にダウンロードされます。 このリポジトリは、製品のパッケージベースとして使用されます。
したがって、 build-toolsのインストールは非常に簡単で、 READMEで説明されています 。
プロジェクトの仕様に移りましょう。
KentOS 5の仕様例：
<?xml version="1.0" encoding="UTF-8"?> <project name="myproject" summary="My First Project" repository="http://repo.domain.com/pub/repo/" version="0.1" > <!-- role with minimal set of packages --> <role path="roles/centos-5-minimal.xml" /> <!-- python packages --> <package name="python" version="2.4.3" /> <package name="python-IPy" /> <package name="python-simplejson" /> <!-- mysql packages --> <package name="mysql-server" version="5.0.95" /> <!-- yum repos --> <role path="repos/centos-5-base.xml" /> <role path="repos/centos-5-updates.xml" /> <role path="repos/centos-5-epel.xml" /> </project>
KentOS 6の仕様例：
<?xml version="1.0" encoding="UTF-8"?> <project name="myproject" summary="My First Project" repository="http://repo.domain.com/pub/repo/" version="0.2" > <!-- role with minimal set of packages --> <role path="roles/centos-6-minimal.xml" /> <!-- python packages --> <package name="python" version="2.6.6" /> <package name="python-IPy" /> <package name="python-simplejson" /> <!-- mysql packages --> <package name="mysql-server" version="5.1.71" /> <!-- yum repos --> <role path="repos/centos-6-base.xml" /> <role path="repos/centos-6-updates.xml" /> <role path="repos/centos-6-epel.xml" /> </project>
違いは基本的に、パッケージの最小限のセットを持つyumリポジトリとロールのみです。
yumリポジトリとメタパッケージを構築するには、既製のスクリプトを使用するか、より深い自動化と開発プロセスへの統合を使用して独自のスクリプトを作成できます。
cd src cp ../repository . ./build-el5.sh ./build-el6.sh
リポジトリはCentOS 5で構築する必要があります。これは、yumには下位互換性がなく、yum CentOS 6 APIで構築されたリポジトリはCentOS 5マシンにインストールされませんが、CentOS 5で構築されたリポジトリはCentOS 6、Fedoraにインストールされるためです13以上、Scientific 5以上。
クラッシュを開始すると、出力は2つのリポジトリになり、そこからキックスタートを介して物理サーバーと仮想サーバーをアップロードできます。 これにより、企業のリポジトリに保存して製品の展開に使用できる一連のソフトウェアが修正されます。
環境をカスタマイズするために、パブリックyumリポジトリとパッケージを使用して新しいロールを作成できます。
いくつかの一般的なオプションを検討してください。
- テスト環境で、実稼働環境にないRPMパッケージを追加する必要があるとします。 この場合、これらのパッケージのリストとテスト環境用の別のプロジェクトで別のロールが作成され、このロールは他の環境用のロールとともに追加されます。 すべての環境のビルドビルドは、開発および本番用のビルドのパッケージのバージョンがテストと異なるのではなく、その数だけになるように、同じ日に行う必要があります。
- すべてのプロジェクトサーバーに存在する必要があるソフトウェアの規制リストがあるとします。 この場合、このリストで個別のロールが作成され、すべてのプロジェクト仕様に追加されます。 このようにして、ソフトウェアがすべてのサーバーにインストールされることが保証されます。
属性の詳細な説明は、 wiki build-toolsにあります 。
遅かれ早かれ起こる更新について話すならば、この場合、プロジェクト仕様のバージョンを犯してビルドを再構築することで十分です。 これにより、開発、テスト、および運用環境で展開または更新できる新しいバージョンの新しいビルドが作成されます。
要約：
したがって、私は成功したビルドツールを使用して：
- ID開発、テスト、実稼働環境の問題を解決する
- プロジェクト全体で環境とソフトウェアの互換性をバージョン管理するための幅広い機会を開発者に提供します