configuration management devops practices
DevOpsプラクティスの構成管理とは何ですか？
のコンセプト DevOpsでの継続的テスト 以前のチュートリアルで詳細に説明されました。
DevOpsの構成管理の重要なハイライトは、
- コードとしてのインフラストラクチャ
- コードとしての構成
読み通す必要があります=> 独占的なDevOpsチュートリアルシリーズ
最高のyoutubeビデオコンバーターは何ですか
DevOpsの実践には、「コードとしてのインフラストラクチャ」と「コードとしての構成」の多くの利点があります。
-
- 構成はバージョン管理されています
- 自動化および標準化
- 依存関係を削除します
- エラーのないインフラ設定
- 運用チームと開発チーム間のコラボレーションを促進します
- 構成のドリフトを修正する
- インフラストラクチャを柔軟なリソースとして扱う
- インフラストラクチャの自動スケーリング
- セットアップの一貫性を維持する
ビデオパート4ブロック1：構成管理–23分7秒
トランスクリプト：
このパートでは、 DevOpsでの構成管理、リリース管理、およびアプリケーションパフォーマンスの監視。
ここでは、ブロック1で、構成管理に焦点を当て、構成管理とは何か、DevOpsと従来の方法との違いを理解します。
まず、構成管理とは何ですか？
名前自体が説明するように、構成管理は、ソフトウェアアプリケーションがホストする環境のすべての構成を管理することに他なりません。
ご存知のとおり、DevOpsのSDLC全体で、単体テスト、統合テスト、システムテスト、受け入れテスト、エンドユーザーテストから始まるさまざまな環境があります。
また、以前のチュートリアルで、これらのテスト用に設定された環境は、実稼働前および実稼働環境に移行するにつれて、次第に複雑になることを説明しました。
したがって、基本的に、構成管理は、これらの各環境のすべての構成を管理するための自動化されたプロセスです。
では、従来の構成管理とDevOps構成管理の違いは何ですか？
従来の構成管理方法では、チームは正式なドキュメントを介してさまざまな環境のこれらの構成を管理していました。各構成はドキュメントに記録され、構成チームまたはマネージャーはこれらのドキュメントのバージョン管理を処理していました。
また、変更が加えられると、環境のセットアップと構成の手動管理も担当します。
現在、DevOpsでは、通常、これらすべての構成管理プロセスは非常によく自動化されており、構成はコードまたはスクリプトの形式でカプセル化され、バージョン管理ツールを介して制御されます。
このコンテキストでは、運用チームは、単一のバージョン管理ツールを介して環境を管理する際に開発と統合されていると言えます。
したがって、DevOpsの構成管理の重要なハイライトは、
-
-
- コードとしてのインフラストラクチャ
- コードとしての構成
-
実際に「コードとしてのインフラストラクチャ」とはどういう意味ですか？ これは、正式なドキュメントに記録するのではなく、環境定義全体をコードまたはスクリプトとして定義しています。
では、環境定義には何が含まれていますか？環境の定義には、通常、サーバーのセットアップ、ネットワークの構成、およびITインフラストラクチャのセットアップの一部である他のコンピューティングリソースのセットアップが含まれます。したがって、これらの詳細はすべて、ファイルまたはコードの形式で書き出され、バージョン管理ツールにチェックインされます。
バージョン管理にチェックインされるこのスクリプトまたはコードは、環境を定義したり、それらの環境を更新したりするための単一のソースになります。
簡単に言うと 例 、特定の環境にサーバーを追加する必要がある場合は、追加したサーバーを使用して新しい環境を手動でスピンアウトしたり、シークしたりするのではなく、これらの情報を環境スクリプトに更新して配信パイプラインを実行するだけです。これを行うためのシステム管理者の助け。
したがって、ここでの利点は、開発者またはテスターが、開発またはテスト活動用にサーバーをセットアップするためにシステム管理者の専門家である必要がないことです。
そのため、DevOpsでセットアップされたインフラストラクチャは完全に自動化され、基本的に、サーバーのインストール、構成、OSのインストールから始まり、これらのインスタンスの通信チャネルがデプロイされた状態で確立されるまで、バージョン管理にチェックインされるスクリプトに従います。ソフトウェア。
コードとしての構成は何ですか？
コードとしての構成は、サーバーまたはその他のリソースのすべての構成をコードまたはスクリプトとして定義し、それらをバージョン管理にチェックインすることに他なりません。
バージョン管理にチェックインされるこれらの構成スクリプトは、インフラストラクチャとその構成を自動化された方法でセットアップするために、デプロイメントパイプラインの一部として実行されます。
構成の定義には、ソフトウェアを正常に実行するための推奨設定を定義するパラメーターが含まれています。または、ソフトウェアアプリケーションをセットアップするために最初に実行される一連のコマンド。または、設定するソフトウェアの各コンポーネントの構成、または特定のユーザーロール、ユーザー特権などである可能性もあります。
シンプル 例 フィーチャートグルを設定することで、デフォルト値が構成パラメーターの一部として設定されます。
ファイアウォールに別のポートを追加することは別のことです 例 、スクリプトで更新でき、後でこれらのスクリプトは配信パイプラインの一部として実行されます。
市場でインフラストラクチャの自動化を実行するために、いくつかのツールが利用可能です。 Chef、Puppet、Terraformなどはほとんどありません。ChefとPuppetはルビーベースの構成管理ツールですが、Terraformはプロビジョニングツールです。
また、最近ではほとんどすべてのアプリケーションがクラウドAWSでホストされるため、それら自体がRESTAPIを提供し、この目的に活用できます。
インフラストラクチャと構成をコードとして定義するのではなく、DevOpsでの構成管理の利点の膨大なリストがあります。
それらを1つずつ見ていきましょう。
すべての構成とインフラストラクチャの詳細はバージョン管理されており、DevOpsの実装に大きなメリットがあります。
＃1） これにより、チームはサーバーと構成への変更を自動化された方法で管理し、障害が発生した場合に短期間で迅速にデバッグできるようになります。また、顧客に影響を与えることなく、以前のバージョンにすばやくロールバックできます。
＃二） これらのスクリプトは中央サーバーに配置されており、チームの全員がこれらの各スクリプトに何が含まれているか、およびこれらの各バージョンでどのような変更が加えられているかを知っているためです。これにより、チームは、最新バージョンで問題が発生した場合に、古いバージョンに戻ることもできます。
サーバーがクラッシュした場合、手動で復元するのにどれくらいの時間がかかるか想像してみてください。そして今、インフラストラクチャをスクリプトおよびバージョン管理として定義することにより、以前のバージョンに移動することですぐに復元できます。
＃3） 構成をコードとして管理することで、誰かが誤ってシステムに変更を加えることを防ぎ、本番環境の後半で発生する損傷を防ぐこともできます。
構成管理は完全に自動化されているため、セットアップまたは更新のための手動による介入が完全に排除されます。
以前は、人的資源に依存してこれらの構成を手動で実行したり、特定の構成が欠落したり、必要に応じて設定されなかったりした場合の、コスト、品質、および時間への影響を想像してみてください。
したがって、構成管理の自動化は、時間の節約だけでなく、そのような人的エラーの排除と品質の向上にも役立ちました。また、コーディング標準は、構成ガイドを作成する各人の幻想に従うのではなく、コーディングと自動化で指定された標準に従うことでチームを支援しました。
前に説明したように、コードとして配信する構成により、構成マネージャーまたは構成チームと呼ばれる1人のユーザーまたはチームへの依存がなくなりました。開発チームは、構成チームが来てインフラまたは構成の問題を修正するのを待つ必要はありません。
または、完全に自動化され、バージョン管理されているインフラストラクチャと構成をセットアップする場合でも同様です。したがって、開発者であれテスターであれ、チームの誰もがサーバーをスピンして、開発とテストの目的で構成を実行できます。したがって、サーバーと構成のセットアップは人に依存しなくなりました。
これにより、開発チームとQAチームの両方が、以前は一般的にそうであったように、同じサーバーをアクティビティに使用しないようにすることもできます。
共通コードとして定義されたインフラストラクチャと構成、および自動化とバージョン管理により、すべての環境とセットアップが標準化されます。したがって、これにより、開発者はデバッグタスクを簡単に実行できるだけでなく、人的エラーを排除してエラーのないインフラセットアップを実現できます。そうしないと、早期に検出されないと大きな損害が発生します。
ここでは、DevとOpsの間の明確なコラボレーションを明確に見ることができます。どちらも、インフラストラクチャのセットアップを実行するために単一のソースに依存しており、両方のチームが構成管理全体の自動化とセットアップに積極的に関与しています。
共通の目標を達成するために協力することで、開発と運用の両方のチーム間のコラボレーションが促進されます。
構成ドリフトの修正
構成ドリフトとは何ですか？
サーバー間の小さな違いや不整合は、手動更新が原因で発生することがあり、一定期間にわたって蓄積されます。これは、構成ドリフトと呼ばれます。
これは良い状況ではありません。サーバー内のこの不整合により、マニフェスト、プレイブックなどの特定のプログラムファイルがすべてのサーバーで確実に実行されず、自動化の失敗につながるためです。したがって、チームが構成の自動化を効果的に使用できるようにするには、これを回避する必要があります。
インフラストラクチャと構成をコードとして管理し、それらを制御するバージョンは、すべてのサーバー間で構成を一貫して維持することにより、チームがさまざまな環境間または開発と本番のセットアップ間でのあらゆる種類の構成のずれを回避または修正するのに役立ちました。
したがって、チームは、本番環境と同様の開発セットアップでの構成セットアップを最も確実に行うことができます。これは、開発環境での本番環境の問題をシミュレートするのにも役立ちます。
したがって、これは、チームメンバーのいずれかがインフラストラクチャで実行しようとする可能性のある予期しない変更を防ぐのに役立ちます。これにより、セットアップが破損し、チームが次のようにログインしない限り、セットアップに変更を加えないように強制されます。リポジトリへのコード。
インフラストラクチャとその構成をコードとして提供することで、チームはインフラストラクチャを柔軟なリソースとして管理し、顧客の動的なビジネスニーズを満たすことができます。
その一種のプラグアンドプレイになりました。チームは特に特定のサーバーまたはネットワークにアクセスして、それらに変更を加えることができます。プロビジョニングサーバーを更新したり、特定のネットワークのストレージを追加または変更したり、OSを更新したりするだけで、すべてを柔軟なリソースとして個別に更新できます。
以前は、1つの構成パラメーターを変更するために、特にすべてのサーバーで更新する必要があったときに、実際には多くの時間がかかりましたが、今では1回で済みます。スクリプトを更新してバージョン管理ツールにアップロードすると、すべて完了です。
既存のインフラストラクチャを完全に廃棄し、別のインフラストラクチャを完全に立ち上げる柔軟性があります。そのため、インフラストラクチャと構成の管理が非常に簡単になりました。クラウドベースのソリューションにより、必要に応じてコンピューティングリソースまたはストレージリソースを追加し、不要な場合はスケールダウンすることで、インフラストラクチャを自動的にスケールアップできます。
これにより、需要に基づいてリソース使用量を最適化できるようになりました。マシンのサイズを大きくしてインフラストラクチャをスケールアップしたい場合は、すぐに実行できます。同様に、スケールアウトしたり、別のセットアップを追加したり、フロントエンドを追加したりする場合は、コードで更新して自動パイプラインを実行するだけで、数秒で実行できます。
最後になりましたが、インフラストラクチャは、制御された環境でコードとして配信することで、さまざまなセットアップ間で環境の一貫性を維持するのに役立ちます。これは、問題のデバッグにも役立ちます。この点については、構成のドリフトについて話しているときに、ある程度前に説明しました。
これで、インフラストラクチャとコードとしての構成、およびその利点について、DevOpsでの構成管理に関する説明は終わりです。
今後のチュートリアルでは、 DevOpsのリリース管理の側面。