⤴️ 🕯️ 🎎 コンテキスト：バックエンドを備えたAndroidのニュースアグリゲーター。構成監視システム（Puppet） 🐒 🏅 🧓🏾

導入部（すべての記事へのリンク付き）

ITIL（v3）で説明されているプロセスには、特に興味深いものが2つあります。「構成管理プロセス」と「変更管理プロセス」で、システム構成の変更を分析および管理します。話を続けるには、「システム」とは何かを決める必要があります。この概念には、サービスの提供に（直接的または間接的に）影響を与える膨大な数のコンポーネントが含まれます。

サーバー
- セキュリティ設定（ユーザー、グループ、権利、ファイアウォール）;
- インストールされたアプリケーションとライブラリ。
- アプリケーション設定（記述子、メモリ、CPU時間などの制限）;
- バックアップ
アプリケーションおよびシステムソフトウェアの監視システム。
製品自体の構成ファイル、そのコンポーネント、補助システム、およびアプリケーションアプリケーション
...

プロジェクトのシステムの輪郭を最小限にしようとすると（タイプ、システムの機能にはバックアップは適用されません）、自分で穴を掘ることになり、遅かれ早かれ失敗します。

このシステムコンポーネントのリストは、複数のサーバー（さらには1台）に展開されているほとんどのプロジェクトにとって最低限のものです。さらに、プロジェクトが進むにつれて、その数は変化し、増加します。会計プロセスがない場合、これが何につながるのかが明らかになります：すべてが完全に機能するテストベンチ（または開発スタンド）がありますが、製品に複製するか、新しいスタンドを作成しようとすると、

非常に長い展開/複製プロセス（障害が発生したときに何がどのように構成されているかを誰もが覚えており、多くの場合、既存のスタンドと設定を比較します）。
予想外に、展開された製品の操作中に問題が発生します（テストベンチで最後の瞬間に行われたが、製品に転送されなかった設定を忘れることがあります）。
テストプロセスの速度が低下します（内部テスターであっても、新しいアセンブリの公開は、時間と複雑さの両方で偉業です）。
そして最後に、新しいバージョンのリリース前に開発者の間で恐れがあり、その結果、新しいリリースの計算が遅れます（誰も公然と話さないが、その効果は常に感じられます）。

その結果、製品が正しく動作するための環境は制御不能になり、使用可能な自動化およびバージョン管理ツールが使用できなくなります。

やる気

物事は明らかなように見えますが、ほとんどの開発グループでは彼らに目をつぶっています-多くの人は、サーバーが1つ、設定が少なく、労働者の能力があると主張していますリスクなどなど

ITILに記載されているものの見かけの複雑さと冗長性（実際には多くの記述があります）にもかかわらず、まず、これらのプロセスの自動化のための要件をそこから取り入れる必要があります。アセンブリの自動化、テストの自動化、脆弱性の検索の自動化-これらはすべて実装されており、開発中に必要な最小限のものとみなされます。自動化はプロセスを加速し、自信を植え付け、透明性と保証された結果を提供し、時間と結果に対するパフォーマーからの恐怖を取り除きます。

単一の開発者の動機

前の段落の強力な導入部分を考えると、単一の開発者にとっての利点は、より簡単かつ簡単に説明されます。

なぜなら開発は毎日行われません。その結果、いくつかの展開機能は数日後にスムーズに消えます。
ローンの自動化-最も信頼できるパートナー。
自動化によって提供される作業の速度により、「融合」とプロジェクト開発への意欲を失うことがなくなります（これは非常に重要な特定のポイントです）。

ITILに関する重要な免責事項

ITILに記載されているプロセスから、そこに記載されているすべての手順を実行しようとしないでください。状況は以前よりも悪化します。一部の銀行システムでこのような手順がどのように実装され、それが何をもたらすかを知っています（特に自動化なし）-官僚的な機械は、動的に開発中のプロジェクト/システムを停止させます。

人形

私の場合、パペットが選ばれました。 ChefとAnsibleのどちらを選択するかは、優れたドキュメントベース、優れたサポート、十分な数のモジュール（開発者とコミュニティから）、プロジェクトの積極的な開発とRubyの実装（多かれ少なかれ知っています）を考慮して選択されました。

率直に言って、パペットの学習曲線はまったく穏やかではありませんでした。開発されたシステムはあらゆる種類の要素を大量に使用するため、それぞれを別々に構成し、すべてを異なるスタンドに展開できます。ツールの徹底的かつ徹底的な調査が必要でした。ツールが研究されるにつれて、その欠点（ほとんどの場合、「設計による」）と制限（いくつかのアーキテクチャソリューションを説明するPuppet哲学に関する優れた記事）のいくつかが明らかになりました。また、必要なスクリプトを研究し、すでに部分的に実装していたため、Puppetに存在する問題の一部を解決したAnsibleについてもう少し学びました（Puppetにない独自の問題が発生する可能性を排除しません）。したがって、その後のストーリーはPuppetの広告ではなく、使用の可能性と経験の説明です。

Puppetについて

Puppetは、システム管理者がアクセスできるように開発された独自の構成言語（DSL）を使用します。 Puppet言語は、正式なプログラミング知識を必要としないと位置付けられており、その構文はNagios構成ファイル形式の影響下で形成されました。

Puppet言語の主な目的は、リソース（Puppetのリソース-ファイル、ディレクトリ、サービス、制限、ファイアウォール、ユーザーなど）を定義することです。言語の他の部分はすべて、リソースの定義方法に柔軟性と利便性を追加するためにのみ存在しています。

リソースグループは、より大きな構成単位であるクラスに編成できます。リソースは単一のファイル/ディレクトリまたはパッケージを記述することができますが、クラスはサービスまたはアプリケーションの構成に必要なすべてを記述することができます（必要な数のパッケージ、構成ファイル、デーモン/サービス、メンテナンスタスクを含む）。小さいクラスを組み合わせて、システム全体の役割を記述する大きなクラス（「データベースサーバー」または「クラスター作業ノード」）にすることができます。

内部にリソースがあるクラスの例：

class apache (String $version = 'latest') { package {'httpd': ensure => $version, # Using the class parameter from above before => File['/etc/httpd.conf'], } file {'/etc/httpd.conf': ensure => file, owner => 'httpd', content => template('apache/httpd.conf.erb'), # Template from a module } service {'httpd': ensure => running, enable => true, subscribe => File['/etc/httpd.conf'], } }

異なる役割を実行するマシンは、一般的な場合、異なるクラスのセットを受け取る必要があります。どのクラスをどのマシンに適用するかを構成するタスクは、Puppetノードのタスクです。

Puppetノードの定義例

 node 'www1.example.com', 'www2.example.com', 'www3.example.com' { include common include apache, squid } node /^(foo|bar)\.example\.com$/ { include common }

Hieraの事実とデータベース。 Puppetコードを実行する前に、ノードに関する情報が収集され、収集された情報は事前定義されたファクト（コード内のどこでも使用できる変数）の形式で表示されます。 Hieraは、組み込みの「キー値」データベースです。デフォルトでは、YAMLまたはJSONファイルがデータソースとして使用されますが、任意のデータソースを使用するように拡張することもできます。その階層とノードに応じてデータを変更する機能により、その使用はほとんどのモジュール/クラスの作業の不可欠な部分です。

モジュールは、コードとデータの自己完結型ブロックです（クラス、テンプレート、ファイルなど）。これらの再利用可能で一般にアクセス可能なアイテムは、Puppetの主要な構成要素です。

Puppetの使用を計画している人は、ほとんどの場合クラスと、時にはモジュールを作成する必要があります。

展開オプション

Puppetを実装する場合、集中構成ストレージを使用する場合と使用しない場合の2つのオプションがあります。

一元化された構成ストレージ：多くのサーバーがある場合、その利点は明確に見えます。この場合、マシンのみに関する情報がクライアントマシンに送信されます。これにより、一定レベルのセキュリティが提供され、トラフィックが最小限に抑えられます。
構成の分散ストレージ：少数のサーバーで正当化されますが、マシンには構成スクリプトとファイルの完全なセットが必要であり、エージェントの起動時にそれらがコンパイルされ、このマシンの一部が実行されます。 15分ごとに実行される通常のcronタスクによって実装されます。

私のスクリプトは次のようになります。

 #!/bin/sh PUPPET_BIN='/opt/puppetlabs/bin/puppet' #      apt-get update && apt-get -y install git mc htop apt-transport-https nano wget lsb-release apt-utils curl python #    `puppet-agent` if [ ! -d /etc/puppetlabs ]; then rm *.deb.* *.deb # possible trash wget https://apt.puppetlabs.com/puppetlabs-release-pc1-xenial.deb && dpkg -i puppetlabs-release-pc1-xenial.deb apt-get update && apt-get -y install puppet-agent fi #   `environment` /opt/puppetlabs/bin/puppet config set environment $PUPPET_ENV if [ ! -d /etc/puppetlabs/code/environments/$PUPPET_ENV ]; then cp -r /etc/puppetlabs/code/environments/production /etc/puppetlabs/code/environments/$PUPPET_ENV fi # Install puppet modules $PUPPET_BIN module install puppetlabs-ntp $PUPPET_BIN module install aco-oracle_java $PUPPET_BIN module install puppetlabs-firewall $PUPPET_BIN module install saz-ssh $PUPPET_BIN module install saz-sudo $PUPPET_BIN module install saz-limits $PUPPET_BIN module install thias-sysctl $PUPPET_BIN module install yo61-logrotate $PUPPET_BIN module install puppetlabs-apt $PUPPET_BIN module install puppet-archive # git pull "deployment" project and go in it only if POVISION_NO_GIT_CLONE set to "true" if [ ${POVISION_NO_GIT_CLONE:-"false"} = "true" ]; then echo "do nothing" else LOCAL_REV="" if [ -f local_latest.sha1 ]; then LOCAL_REV=`cat local_latest.sha1` fi REMOTE_REV=`git ls-remote --tags | grep "latest" | awk '{print $1}'` if [ $LOCAL_REV = $REMOTE_REV ]; then exit 0 fi git fetch --all --tags --prune git checkout -f tags/latest fi # replace puppet configs cp puppet_config/hiera.yaml /etc/puppetlabs/code/environments/$PUPPET_ENV/ # replace hiera db rm /etc/puppetlabs/code/environments/$PUPPET_ENV/hieradata/* cp -r $PUPPET_ENV/hieradata/* /etc/puppetlabs/code/environments/$PUPPET_ENV/hieradata # replace storyline_* modules rm -r /etc/puppetlabs/code/environments/$PUPPET_ENV/modules/storyline_* cp -r modules/* /etc/puppetlabs/code/environments/$PUPPET_ENV/modules # copy site.pp cp $PUPPET_ENV/site.pp /etc/puppetlabs/code/environments/$PUPPET_ENV/manifests/site.pp #echo "hostname:" #hostname $PUPPET_BIN apply /etc/puppetlabs/code/environments/$PUPPET_ENV/manifests/site.pp echo $REMOTE_REV > local_latest.sha1

私の場合、もちろん、分散システムが使用されます。なぜなら、実装が簡単で（インフラストラクチャの編成の観点から）、テストベンチを展開するためのビルドスクリプトが大幅に簡素化されます。テストベンチは1日に数十回作成して実行します。

指定されたスクリプトを実行する場合：

Puppetクライアント自体と必要なパッケージがインストールされている
必要なPuppetモジュールがインストールされています
「最新の」ラベルのコミット番号の変更が検証されます（新しいバージョンの統合テストが成功したときに行われます）
現在の環境のHiera Puppetデータベースの構成（hiera.yaml）が置き換えられます（$ PUPPET_ENV変数）。
Hiera Puppetデータベースのデータを含むYAMLファイルは置き換えられます。
モジュールの説明を置き換えるためにコピーされました。
ノード（私のシステムのサーバー）の構成がコピーされます。
コピー/インストールされたすべての設定のアプリケーションが呼び出されます（$ PUPPET_BIN apply ....）

Puppetクライアントが起動時に実行するタスクのリストは膨大です（手動での検証と必要な実行は単に不可能です）：

開いているファイル、関連するメモリ量、スワップ、接続数に制限が設定されます。
ログローテーションが構成されます（システムと、アプリケーションと必要なサービスの両方）。
必要なグループと権限で必要な管理アカウントが作成されます。
NTPサーバーがインストールおよび構成されています。
SSHサーバーがインストールおよび構成されています。
Oracle JDKのインストール
ファイアウォールを構成する
この特定のノードでプロジェクトまたはそのコンポーネントが機能するために必要な多数のコンポーネントがインストールおよび構成されます。

人生の例

スタンド用のPuppetスクリプトシステムを開発するとき、Puppetコードが実行されたマシン/コンテナにコピーされる独自のモジュールを開発しました。モジュールには、データ（ほとんどの構成ファイル内）および構成用のPuppetコードが含まれています。 Hieraのスクリプトから基本設定を行いました。その結果、スクリプトは非常に普遍的で、実行されるノードに依存しないことが判明しました。

コードと設定の例をいくつか示します。

ngnixの設定（パッケージからではなく、ネイティブリポジトリから）（サイズのためにユニットにスポイラーを隠しました。しかし、興味がある人は、勉強するときに非常に多くのニュアンスが見えるようにする必要があります）

storyline_infraモジュールのNginxクラス

 class storyline_infra::nginx () { $params = lookup({"name" => "storyline_infra.nginx", "merge" => {"strategy" => "deep"}}) $reverse_port = $params['reverse_port'] $reverse_url = $params['reverse_url'] $pid_file = $params['pid_file'] $init_script = $params['init_script'] $dir_data = $params['dir_data'] $dir_logs = $params['dir_logs'] $version = $params['version'] $enabled_startup = $params['enabled_startup'] $enabled_running = $params['enabled_running'] # topology_configuration $enabled_topology_configuration = $params['enabled_topology_configuration'] $topology_configuration_port = $params['topology_configuration_port'] #    ( ) user { 'nginx': ensure => "present", managehome => true, } #    ( ) exec { "nginx-mkdir": command => "/bin/mkdir -p /data/db && /bin/mkdir -p /data/logs", cwd => "/", unless => '/usr/bin/test -d /data/db -a -d /data/logs', } -> # working dir file { [ $dir_logs, $dir_data] : ensure => "directory", recurse => "true", owner => "nginx", group=> "nginx", require => Exec['nginx-mkdir'], } #       ( ) # see by "gpg --verify keyfile" apt::key { 'nginx-key': id => '573BFD6B3D8FBC641079A6ABABF5BD827BD9BF62', source => 'http://nginx.org/keys/nginx_signing.key', } -> #   ( ) # deb http://nginx.org/packages/ubuntu/ xenial nginx apt::source { 'nginx-repo': comment => 'nginx repo', location => "http://nginx.org/packages/ubuntu/", release => "xenial", repos => "nginx", include => { 'deb' => true, 'deb-src' => true, }, } -> #    ( ) package { 'nginx': ensure => $version, # notify => Exec['disable_nginx'], } → #        ( ).        ,    .   !!! file { "/etc/nginx/nginx.conf": replace => true, content => epp('storyline_infra/nginx.epp'), owner => "nginx", group=> "nginx", notify => Service['nginx'], }-> #        ( ) file { "/etc/nginx/conf.d/default.conf": replace => true, content => epp('storyline_infra/nginx_default.epp'), owner => "nginx", group=> "nginx", notify => Service['nginx'], }→ #        ( ) file { $init_script: replace => true, content => epp('storyline_infra/nginx_startup.epp'), mode=>"ug=rwx,o=r", notify => Service['nginx'], }→ #  /  ( ) service { 'nginx': ensure => $enabled_running, enable => $enabled_startup, start => "${init_script} start", stop => "${init_script} stop", status => "${init_script} status", restart => "${init_script} restart", hasrestart => true, hasstatus => true, } #   nginx ( ) if $enabled_topology_configuration { file { "/etc/nginx/conf.d/topology.conf": replace => true, content => epp('storyline_infra/nginx_topology.epp'), mode=>"ug=rwx,o=r", notify => Service['nginx'], } } #     ( ) if $enabled_startup != true { exec { "disable_nginx": require => Package['nginx'], command => "/bin/systemctl disable nginx", cwd => "/", } } }

各コメントでわかるように、リソース定義が示される前-「必要な場合」リソースの状態がすでに定義と一致している場合、Puppetは操作を実行しません。

この場合、コード«$params = lookup({"name" => "storyline_infra.nginx", "merge" => {"strategy" => "deep"}})»

使用してHieraからデータ«$params = lookup({"name" => "storyline_infra.nginx", "merge" => {"strategy" => "deep"}})»

取得する方法«$params = lookup({"name" => "storyline_infra.nginx", "merge" => {"strategy" => "deep"}})»

できます（例後でそのデータを提供します）、その後、すべての変数を埋めるために使用されます。

Hiera構成ファイル：

 --- version: 5 defaults: datadir: "hieradata" data_hash: yaml_data hierarchy: - name: "1" path: "nodes/%{trusted.certname}.yaml" - name: "2" path: "version.yaml" - name: "3" path: "common.yaml"

この場合、階層は表示される（「階層」キー）ソースで、より高いレベルの各ソースはより低いレベルのキー値を再定義します。これにより、「common.yaml」の値が「80」で、「nodes / webserver1.yaml」の値が「81」である「www.server.port」などのキーを持つことができます-結果として、実行時にこのキーの値を取得しますコードパペット：「webserver1」という名前のノードでは「81」、他の全員では「80」。

Hieraのcommon.yaml

 --- limits::entries: '*/nofile': both: 1048576 '*/memlock': both: unlimited logrotate::config: su_user: root su_group: syslog compress: true # sysctl sysctl::base::purge: false sysctl::base::values: net.core.somaxconn: value: '65536' vm.swappiness: ensure: absent fs.file-max: value: '500000' vm.max_map_count: value: '262144' storyline_base: oracle_java: version: "8u92" storyline_infra: collectd: server_address: "XXX.nlp-project.ru" pid_file: '/data/logs/collectd/collectd.pid' init_script: '/etc/init.d/collectd' dir_data: '/data/db/collectd' dir_logs: '/data/logs/collectd' version: "1.2.0-1" enabled_mongodb: false mongodb_user: "collectd" mongodb_password: "######" enabled_storm: false enabled_elasticsearch: false elasticsearch_port: "####" elasticsearch_cluster: "elastic_storyline" enabled_startup: false enabled_running: true influxdb: port_http: "####" port_rpc: "####" pid_file: '/data/logs/influxdb/influxdb.pid' init_script: '/etc/init.d/influxdb' dir_data: '/data/db/influxdb' dir_logs: '/data/logs/influxdb' version: "present" enabled_auth: true enabled_startup: false enabled_running: true ….

site.pp（Puppetノードの定義を含むファイル）

 node "XXX.nlp-project.ru" { include ::limits include ::sysctl::base include ::logrotate include storyline_base::ntp include storyline_base::srv_oper include storyline_base::ssh include storyline_base::oracle_java ….. include storyline_infra::monit include storyline_base::firewall } node "YYYY.nlp-project.ru" { include ::limits include ::sysctl::base include ::logrotate include storyline_base::ntp include storyline_base::srv_oper include storyline_base::ssh include storyline_base::oracle_java …. include storyline_infra::zookeeper include storyline_components::server_storm include storyline_infra::monit include storyline_base::firewall }

誰かがタスクの特定の実装に興味がある場合：書き込み-実装をコメントで記述するか、ヒントに追加します。

Puppetは積極的に開発しています：使用状況に応じて、構文の明確な改善とクラスの動作の統一が行われます（ただし、さまざまな状況で変数を解決する特定の機能があり、混乱を招くことがあります）。

ヒント

モジュールを開発するときは、関数を追加するだけでなく、無効にするためのコードを作成することを忘れないでください。そのような機能がない場合、コンポーネントを別のサーバーに転送すると、2つのサーバーがあります。新しい場所と古い場所-古い場所では手動で削除する必要があります。これは、構成管理の自動化の主なタスクと矛盾します。
初心者のための優れた人形本- 学習人形と人形4エッセンシャル。
nexus sonatype（https://github.com/cescoffier/puppet-nexus）からアーティファクトを受信するための優れたモジュール。
ノードの構成を容易にし、モジュール自体のコードの普遍性を実現するために、Hieraデータファイルに最大数のパラメーターを取り込みます。

ご清聴ありがとうございました！

コンテキスト：バックエンドを備えたAndroidのニュースアグリゲーター。 構成監視システム（Puppet）

やる気

単一の開発者の動機

ITILに関する重要な免責事項

人形

Puppetについて

展開オプション

人生の例

ヒント

More articles:

コンテキスト：バックエンドを備えたAndroidのニュースアグリゲーター。構成監視システム（Puppet）