DevOpsにおける構成管理

DevOpsにおける構成管理

  • ITOps・DevOps
6分で読めます 更新日 Mar 8, 2019

ポイント: 構成管理はDevOpsにおいて重要であり、プロセスを自動化して効率性と機敏性を向上させます。構成を特定、制御、監査することが含まれ、システムの一貫性を維持し、継続的インテグレーションをサポートします。

  • 自動化は運用効率を向上させます。
  • 主要な要素にはアーティファクトリポジトリ、ソースコードリポジトリ、および構成管理データアーキテクチャが含まれます。

組織内でDevOpsの概念を真に理解するためには、コーディング、ビルディング、テスト、パッケージング、リリース、構成、およびモニタリングなど、いくつかの重要な主要分野を理解する必要があります。各分野には独自のベストプラクティスがあります。構成管理はDevOpsにおいて重要であり、手作業の煩雑なタスクを自動化し、組織の機敏性を高めることを可能にします。さらに、構成管理はDevOpsを全体的にサポートし、構成管理がDevOpsにとって不可欠であると広く合意されています。この記事では、構成管理について見ていき、以下の点を強調します:

  • 構成管理とは?
  • DevOpsの包括的な構成管理を構成する3つの要素
  • 成功した構成管理の成果

企業ビジネスでDevOpsの移行を進めている場合、構成管理に関するこのガイドを見逃すわけにはいきません:

構成管理とは?

構成管理は、構成プラットフォームを使用して、手作業の構成プロセスを自動化、監視、設計、管理する際に発生します。サーバーやネットワーク、ストレージ、アプリケーション、および他の管理されたシステムにわたって、システム全体の変更が行われます。構成管理の重要な機能は、各システムの状態を定義することです。これらのプロセスをプラットフォームでオーケストレーションすることにより、組織は統合システム全体での一貫性を確保し、効率を高めることができます。その結果、企業は追加のIT管理スタッフを雇うことなく、より容易にスケールアップできます。リソースがない企業でも、DevOpsアプローチを展開することで成長することができます。構成管理は変更管理に密接に関連しており、その結果、2つの用語は時々混同されます。構成管理は、各状態での構成の自動化、管理、保守として最もよく説明されますが、変更管理は、新しいニーズや動的な状況の条件を満たすために構成が再定義され、変更されるプロセスです。構成管理を組織に実装しようとする人々のために、さまざまなツールが利用可能です。Puppetは構成管理の先駆者としての役割を果たしてきましたが、ChefやRed Hatなどの他の企業も構成管理プロセスを強化する魅力的な製品スイートを提供しています。適切な構成管理は、継続的なテストとデリバリーの中心にあり、これらはDevOpsの2つの重要な利点です。

DevOpsにおける構成管理の要素

私たちが議論してきたことに基づいて、構成管理はDevOps変革に必要な3つの広範なカテゴリーの主要な責任を担っていることがすでに明らかになっているかもしれません:識別、制御、および監査プロセス。識別:システム全体の構成ニーズを見つけてカタログ化するプロセス。制御:構成制御中、変更管理の重要性が機能しているのが見えます。構成ニーズは時間とともに変化する可能性が高いため、構成制御により、統合や既存のインフラストラクチャを不安定にすることなく、制御された方法でこれが行えるようになります。監査:ほとんどの監査プロセスと同様に、構成監査は、既存のシステムのレビューであり、コンプライアンス規制や検証に耐えることができるかどうかを確認するものです。DevOpsのように、構成管理は組織内の運用と開発の両方のバケツに広がっています。これは設計によるものです。DevOpsに必要な包括的な構成管理に入る主な要素があります:

  • アーティファクトリポジトリ
  • ソースコードリポジトリ
  • 構成管理データアーキテクチャ

アーティファクトリポジトリ

アーティファクトリポジトリは、マシンファイルを保存するために設計されています。これには、バイナリ、テストデータ、およびライブラリが含まれる場合があります。実際には、人々が一般的に使用しないファイルのデータベースです。DevOpsでは、バイナリのようなアーティファクトは継続的インテグレーションの自然な結果です。DevOpsの開発者は常にビルドをプッシュしており、その結果、保存する必要があるアーティファクトファイルが作成されますが、必ずしもアクセスされるわけではありません。

ソースコードリポジトリ

逆に、ソースコードリポジトリは、開発者が使用するソースコードのデータベースです。このデータベースは、すべての作業コードのコンテナとして機能します。ソースコードに加え、さまざまなスクリプトや構成ファイルなど、役立つコンポーネントを多数保存します。一部の開発者は、このリポジトリにバイナリを保存しますが、それはベストプラクティスではありません。DevOpsの世界では、ビルドや派生バイナリの数が多いため、バイナリや他のアーティファクトを保存する目的でアーティファクトリポジトリを開発することが推奨されています。ソースコードリポジトリに何が入るかを判断するのは簡単です。簡単なリトマステストは、「ファイルは人間が読めるか?」と自問することです。もしそうであれば、それらはソースコードリポジトリに属する可能性が高いです。他にも、ソースコードリポジトリには2つのタイプがあります:集中型バージョン管理システム(CVCS)と分散型バージョン管理システム(DVCS)。CVCSでは、ソースコードは集中管理された場所に存在し、取得および保存ができます。しかし、DVCSでは、コードは開発プロセスで役立つ複数の端末に存在します。より迅速で信頼性が高いです。今日のDevOpsプロフェッショナルの多くはDVCSをソースコードリポジトリとして選択しています。

構成管理データアーキテクチャ

構成管理に特化したデータアーキテクチャを持つことは、ITILサービス管理フレームワークの原則です。構成管理データベース(CMDB)は、サービス、サーバー、アプリケーション、およびデータベースなど、構成管理に関連する複数のシステムやアプリケーションにまたがるリレーショナルデータベースです。CMDBは、変更管理に役立つものであり、構成変更が行われる前に統合システム間の関係を監査することを可能にします。また、サーバーのようなオブジェクトの識別情報を得るためのプロビジョニングにも便利です。CMDBは、インシデント管理においても重要なツールであり、チームが問題を解決にエスカレートするのを助けます。

適切に管理された構成の成果

システムが適切に構成され、管理されている場合、特定の成果を期待できます。これらの成果の中には、インフラストラクチャをコードとして提供し、構成をコードとして提供することが含まれます。以下に、各成果が構成管理において果たす役割を見ていきます:

インフラストラクチャをコードとして

インフラストラクチャをコードとして(IaaC)は、最も簡単に言うと、開発に必要な環境を自動化するコードまたはスクリプトであり、環境を構築するために必要なすべてのステップを手動で完了することなく作成されます。このように「環境」という言葉を使用する場合、DevOpsアクションを実行するために必要なすべてのコンピュータリソースのセットアップを指します。これには、サーバー、ネットワークの構成、およびその他のリソースが含まれる可能性があります。

構成をコードとして

名前が示すように、構成をコードとして(CaaC)は、サーバーやネットワークなど、特定のリソース内の構成を標準化するコードまたはスクリプトの文字列です。これらの構成は、デプロイメントフェーズ中に適用され、インフラストラクチャの構成がアプリケーションに適していることを保証します。

IaaCとCaaCの利点

継続的インテグレーションのファンは、IaaCとCaaCの利点に非常に精通しているはずですが、DevOpsに不慣れな人には、何を期待するかを知っておく必要があります。これらは、このセクションで定義された2つの主要な成果のいくつかの利点です:

  • インフラストラクチャ環境の自動化は標準化を提供します
  • セットアップには人的エラーがありません
  • 運用と開発間のコラボレーションが強化されます
  • 構成が漂流するのを防ぎます
  • インフラストラクチャをより柔軟にし、スケールアップの準備ができます
  • すべてのリソースにわたって各ステップが一貫しています
  • バージョン管理は当然のことです

これらの利点が組織に適用されることで、効率とより大きな機敏性が自然な結果となります。DevOpsは構成管理、IaaC、およびCaaCとほぼ同義です。

構成管理はDevOpsです

構成管理をDevOpsから分離して見ることは、誤った視点を生み出します。この記事で説明した包括的な構成管理は、適切に機能するDevOps組織にとって不可欠であり、直接的に影響を与える以上の自動化の基盤を築きます。IaaCとCaaCを開発環境に取り入れることで、企業はより良くコミュニケーションを取り、継続的インテグレーションと継続的デリバリーに焦点を当てたより機敏な開発ユニットとして機能します。適切なツールは構成管理に不可欠です。構成管理において組織を支援するために、多くの重鎮がその役割を果たしています。BMCはDevOps教育とコンサルテーションのための重要なリソースであり、DevOpsインフラストラクチャに適切な要素を統合する手助けをすることができます。構成管理に関して、BMCは信頼できるパートナーです。エンタープライズ組織を向上させる可能性のあるソリューションに関する詳細については、本日中にお問い合わせください。

DevOpsガイド

  1. DevOpsとは?包括的な紹介
  2. DevOpsの簡単な歴史
  3. DevOpsアーキテクチャの紹介
  4. DevOpsにおける自動化:なぜ自動化するのか、そしてその方法
  5. CI/CDとは?継続的インテグレーションと継続的デリバリーの解説
  6. Jenkinsを使用してCI/CDパイプラインを構築する方法
  7. CI/CDパイプラインの最適化のためのDevOpsメトリクス
  8. 継続的デリバリーメトリクス
  9. 継続的インテグレーションから継続的デプロイメントへの進展は進展か?
  10. 継続的インテグレーション(CI)、デリバリー(CD)、デプロイメントの違い
  11. DevOpsにおけるソースとバージョン管理
  12. 継続的テストとは?
  13. テスト自動化フレームワーク:究極のガイド
  14. DevOpsにおけるリリース管理
  15. 解説:DevOpsにおけるモニタリングとテレメトリー
  16. DevOpsにおけるアプリケーションパフォーマンス管理
  17. SDLCにおけるDevOpsオーケストレーション
  18. データベースDevOpsの紹介
  19. DevOpsにおけるマイクロサービスの役割
  20. DevOpsにおける仮想化の役割
  21. コンテナとDevOps:コンテナがDevOpsデリバリーパイプラインにどのようにフィットするか
  22. コンテナパイプラインとは?
  23. DevOpsツールチェーンとは?
  24. DevOpsのためのコンテナとコードの管理
  25. DevOpsにおけるアジャイルの役割
  26. DevOpsにおけるクラウドの役割
  27. FinDevOpsとは?
  28. 2022年のDevOpsトレンド
  29. DevOpsの価値と原則
  30. DevOpsメトリクスとKPI
  31. 小規模、中規模、大規模組織のためのDevOpsアドバイス
  32. DevOpsチームの構造
  33. 今日読むべきトップDevOps書籍
  34. 『The Phoenix Project: DevOps For Everyone』の書評
  35. DevOpsインフルエンサー:Twitterでフォローすべき11人のDevOps専門家
  36. GitHub、GitLab、Bitbucket & Azure DevOps:何が違うのか?
  37. ベストプラクティス:Kubernetes向けにアプリケーションを設計する方法
  38. DevOpsにおける構成管理
  39. DevOpsのブランチ戦略の解説
  40. DevOpsの職種、役割、責任
  41. DevOpsにおけるテスト:概念、ベストプラクティスなど
  42. 2022年の完全なDevOps認定ガイド
  43. Kubernetesオペレーターパターンとは?

これらの投稿は私自身の意見であり、BMCの立場、戦略、または意見を必ずしも表しているわけではありません。

ITOps・DevOpsの関連記事

The Briefを購読する

このオファーに登録することで、あなたはBMCのプライバシーポリシーを読み、同意したことを確認します。

ありがとう

あなたはThe Briefに登録されました
The Briefはメインフレームとエンタープライズオーケストレーション—BMC AMIとControl-M—および、両者に関するアナリストの研究、顧客の展開、イベントをカバーしています。