タグ付けされた質問 「chef」

Chefは、インフラストラクチャ自動化のためのオープンソースの構成管理フレームワークです。

7
シェルスクリプトではなくChef / Puppetを使用する理由
PuppetおよびChefツールの新機能。彼らがやっている仕事は、シェルスクリプトでできるようです。これらが登場するまで、シェルスクリプトで行われたのかもしれません。 それらがより読みやすいことに同意します。しかし、読みやすいだけでなく、シェルスクリプトに勝る他の利点はありますか？
4
Vagrant、Docker、Chef、OpenStack（または同様の製品）の関係は？
私はWeb開発者ですが、いくつかの管理タスクにも興味があります。したがって、純粋な管理からdev-opsへの新しい移行は私にとって便利です。 とにかく、私はいくつかの問題を関係に入れるためにいくつかの問題を抱えています。おそらくないので、明確にするために助けを求めたいと思いました。 基本的に、私が関係させたいのは4種類のソフトウェアです（私の理解から）。正確な製品は関係ありません。代わりに同様のソフトウェアを配置できます。 Vagrant：私の理解では、VMの作成と管理を自動化することです：VMのセットアップ、開始、停止。これは、ローカルVMまたはリモート（クラウドプラットフォームなど）を使用して実行できます。 Docker：Linuxカーネルのいくつかの概念に基づいた「軽量VM」。共有Webホスティング環境などでプロセスを分離して実行するために使用できます。 Chef：VMなどのオペレーティングシステムをセットアップおよび構成するためのツール。 OpenStack：独自のプライベートクラウドを構築できるツール。したがって、AWSなどに匹敵します。 質問＃1：私の説明は正しいですか、それともこれらの消費の一部（またはすべて）が間違っていますか？ 質問＃2：これらのツールすべてをどのように組み合わせることができますか？それは理にかなっていますか？ 私の想像力と私の理解の観点から、あなたは行くことができ、 OpenStackを使用して独自のクラウドを構築し、 Vagrantを使用して、クラウドで実行されているVMを管理します。 Chefを使用してこれらのVMをセットアップします 最後にDockerを使用してVM内でプロセスを実行します。 これは正しいです？そして、もしそうなら、これらすべての使用を開始する方法についてアドバイスをいただけますか（それは同時に非常に多く、どこから始めるべきかまだわかりません）。
6
Puppet vs Chef、ユーザーとユースケースからの賛否両論[非公開]
私はすでにグーグルで「人形に、またはシェフに」という記事を読みました。 私は、ユースケース、つまり人々が実際の問題に基づいてどちらかを選択した現実世界の実装に興味があります。 私は特にコブラーの問題との統合に興味があります（この方向ではパペットがはるかに標準的なアプローチであることはわかっています）。cobbler-chef統合の経験はありますか？ 前もって感謝します
1
シェフのベストプラクティス/質問
私はパペットを使用しています。私は新しい会社に移り、シェフを採用しています。だから私はシェフを学ぼうとしていますが、まだPuppetで考える=） これらは私の質問です： Ruby DSL、JSON、または管理コンソールからロールをセットアップする方が良いでしょうか？同じことをする複数の方法があるのはなぜですか？ クックブックをサブディレクトリに整理できますか？例：クックブックを作成してそれを使いたいカスタムソフトウェアがあります：chef-repo / cookbooks / ourcompanystuff / customsoftwarecookbookこれは良い習慣でしょうか？ 役割の種類ごとに、その役割を指定するクックブックを作成しますか？これらのクックブックには他のクックブックが含まれていますか（つまり、Webサーバーロールのクックブックにはapacheクックブックが含まれています）。クックブックの相互依存関係と継承がどのように処理されるかわかりません。 Puppetの外部ノード分類子のようなものがあり、ノードが自動的にロールを決定しますか？ ナイフまたは管理コンソール内で物事を構成できるように思われますか、JSONファイルを編集しますか？これは、物事を行う方法が非常に多い理由を私に非常に混乱させています、それは麻痺しています！どちらかを使用する理由はありますか？人形から来ると、これらのツールで何かを誤って設定するのは簡単だと思われます（つまり、何かを除外します） 開発クラスターでChefを使用してノードを自動的にプロビジョニングするにはどうすればよいですか？Puppetを使用して、puppermasterに接続してpuppetの実行を開始し、それ自体をセットアップするVMを起動します（役割は外部ノード分類子によって決定されます）。Chefでこれを行うにはどうすればよいですか？chefサーバーに結び付けるpem / rbファイルを使用してchefをインストールし、ナイフでノードの役割を手動で指示するか、管理インターフェースでこれを編集してから、chef-clientの実行を開始してセットアップしますか？ 入門チュートリアルを完了し、EC2チュートリアルがあることを確認しましたが、EC2を使用したことがないため、従うのが難しいです。この時点で、Chefの実行をホストし、単一ノードの構成をいじり始めています。ここからどこに行きますか？パブリッククックブックを見る必要がありますか？ Opscodeのドキュメントは大丈夫ですが、Puppetのドキュメントほどではありません。検索で不足している可能性のある他の優れたシェフリソースはありますか？
3
chef-soloではなくchef-serverを実行する利点は何ですか？
私は自分のチームの自動展開ソリューションを検討しており、過去数日間Chefで遊んでいます。chef-soloを使用して、ベースのRed Hat VMから実行するシンプルなWebアプリを取得できました。 最終的な目標は、Chef（または別のシステム）を使用して、ビルドを実行するときにクラウドにアプリケーショントポロジを自動的に展開することです。プロセスは基本的に次のように実行されます。 Webアプリのコード、依存関係、およびシェフクックブックはSCMに保存されます ビルドが実行され、イメージを取得してテストするための単一のパッケージが作成されます 次に、ビルドエンジンは、シェフクライアントを実行してパッケージをインストールする新しいクラウドイメージをデプロイします。 イメージは、SCMまたはChefサーバーからクックブックを取得し、すべてをインストールして起動して実行します Chef Serverを実行するための利点や使用例は何ですか？ chef-soloを使用し、SCMからクックブックをプルするスクリプトを使用する場合と比べて、Chef ServerがSCMからクックブックを保持して取得することには大きな利点がありますか？
2
レシピでChef環境を見つける方法
現在の環境が「dev」の場合にのみ、cookbook_fileリソースを実行します。これはどのように表現できますか？ ドキュメントはこれを示唆しています： レシピでは、次のようなコードブロックが役立ちます。 qa_nodes = search(:node,"chef_environment:QA") qa_nodes.each do |qa_node| # Do useful specific to qa nodes only end しかし、私はそれが私が望むものかどうかわかりません-それがループであるという事実は間違っているようです。
30 chef 
7
シェフと人形はお金がかかりますか？
私はシェフまたはパペットを使用して管理を行います（若いため、シェフのことを考えているので、より良い気持ちになります）。 どちらのホームページにも、お金がかかる「エンタープライズ版」があり、何も買おうとは思っていませんでした。シェフ/パペットを買わないと見逃しますか？ 正確にお金がかかるシェフが提供するものは何ですか？ 正確にお金がかかる人形は何を提供しますか？ それは彼らのウェブサイトから私にはあまり明確ではありませんでした。
30 puppet  chef 
10
構成管理ツール（Puppet、Chef）は、インストールされたパッケージを最新の状態に保つことができますか？
これはおそらく、構成管理ツールを既に実行しているユーザーにとっては簡単な質問です。PuppetやChefなどの構成管理ツールは、インストール済みパッケージを最新の状態に保つための適切なアプローチですか？ 主にDebianとUbuntuに基づいた多数のサーバーを実行するとします。構成管理ツールを使用すると、セキュリティの更新やバグ修正が行われたときにリポジトリからインストールされたパッケージを簡単に更新できますか？ 現在、システムにセキュリティ更新プログラムを自動的にインストールさせるために「無人アップグレード」を実行していますが、それでもサーバーに接続してaptitude update && aptitude safe-upgrade頻繁に実行する必要があります。当然、これは退屈で退屈でエラーが発生しやすくなります。 PuppetやChefなどのツールは、インストール済みパッケージを最新の状態に保つための適切なアプローチですか？これらのツールを使用aptitudeして、15台のサーバーで手動または同等のツールを実行しないようにしていますか？これらの質問に対する答えは「もちろんです！」です。 しかし、この特定のユースケースに関する詳細情報はどこで入手できますか？PuppetやChefを詳しく調べる時間はまだありません。サンプルのクックブックまたはクラスでは、sshなどの特定のパッケージをインストールするというささいな例しか示していません。公式のドキュメント以外に、推奨するリソースはありますか（もちろん、もしあれば、どのツールが自分に適しているかがわかったらドキュメントを勉強します）。
2
構成管理：プッシュベースのトポロジとプルベースのトポロジ
PuppetやChefなどのより確立された構成管理（CM）システムは、プルベースのアプローチを使用します。クライアントは、更新のために集中マスターを定期的にポーリングします。それらのいくつかは、提供マスターレスのそれは（Saltstack）や「以下スケーラブル」（人形）の生産のためではない」であること（そう、プッシュベース）にもアプローチしますが、状態。私が知っている唯一のシステムは、最初からプッシュベースです。次点のAnsibleです。 プルベースのシステムの特定のスケーラビリティの利点は何ですか？プッシュエージェントよりもプルマスターを追加するほうが簡単なのはなぜですか？ たとえば、agiletesting.blogspot.nlは次のように記述します。 「プル」システムでは、クライアントは互いに独立してサーバーに接続するため、システム全体は「プッシュ」システムよりもスケーラブルです。 一方、Rackspace は、プッシュベースのモデルで15Kシステムを処理できることを実証しています。 infastructures.orgの書き込み： SUP、CVSup、rsyncサーバー、またはcfengineなどのツールを使用して、インフラストラクチャを維持するためのプル方法論を誓います。クライアントに変更をプッシュするのではなく、個々のクライアントマシンは、起動時およびその後定期的にゴールドサーバーをポーリングして、独自の回転レベルを維持する必要があります。この観点を採用する前に、ssh、rsh、rcp、およびrdistに基づいたプッシュベースの広範なスクリプトを開発しました。rコマンド（またはssh）で見つかった問題は次のとおりです：rコマンドベースのスクリプトを実行してターゲットマシンに変更をプッシュすると、30を超えるターゲットホストがある場合、そのうちの1つがいつでもダウンしている。委託されたマ​​シンのリストを維持することは悪夢になります。これを修正するコードを書く過程で、あなたは対処するための精巧なラッパーコードになります：死んだホストからのタイムアウト。デッドホストのロギングと再試行。並列ジョブをフォークして実行し、適切な時間内に多くのホストにヒットしようとします。そして最後に、ソースマシンで使用可能なすべてのTCPソケットをすべてのアウトバウンドrshセッションで使い果たすケースを検出して防止します。その場合、将来インストールするすべての新しいホストのインストールイメージに行ったばかりのことをすべて取得するだけでなく、死んで明日再構築する必要があるすべてのホストに対してそれを繰り返すという問題があります。トラブルを経てrコマンドベースのレプリケーションを実装しましたが、それだけの価値がないことがわかりました。インフラストラクチャをrコマンドで再度管理したり、他のプッシュメカニズムで管理したりする予定はありません。プルベースの方法と同様にスケーリングしません。並列ジョブをフォークして実行し、適切な時間内に多くのホストにヒットしようとします。そして最後に、ソースマシンで使用可能なすべてのTCPソケットをすべてのアウトバウンドrshセッションで使い果たすケースを検出して防止します。その場合、将来インストールするすべての新しいホストのインストールイメージに行ったばかりのことをすべて取得するだけでなく、死んで明日再構築する必要があるすべてのホストに対してそれを繰り返すという問題があります。トラブルを経てrコマンドベースのレプリケーションを実装しましたが、それだけの価値がないことがわかりました。インフラストラクチャをrコマンドで再度管理したり、他のプッシュメカニズムで管理したりする予定はありません。プルベースの方法と同様にスケーリングしません。並列ジョブをフォークして実行し、適切な時間内に多くのホストにヒットしようとします。そして最後に、ソースマシンで利用可能なすべてのTCPソケットをすべてのアウトバウンドrshセッションで使い果たすケースを検出して防止します。その後、将来インストールされるすべての新しいホストのインストールイメージに行ったばかりのことをすべて取得し、死んで明日再構築する必要があるすべてのホストに対してそれを繰り返すという問題がまだあります。トラブルを経てrコマンドベースのレプリケーションを実装しましたが、それだけの価値がないことがわかりました。インフラストラクチャをrコマンドで再度管理したり、他のプッシュメカニズムで管理したりする予定はありません。プルベースの方法と同様にスケーリングしません。そして最後に、ソースマシンで利用可能なすべてのTCPソケットをすべてのアウトバウンドrshセッションで使い果たすケースを検出して防止します。その後、将来インストールされるすべての新しいホストのインストールイメージに行ったばかりのことをすべて取得し、死んで明日再構築する必要があるすべてのホストに対してそれを繰り返すという問題がまだあります。トラブルを経てrコマンドベースのレプリケーションを実装しましたが、それだけの価値がないことがわかりました。インフラストラクチャをrコマンドで再度管理したり、他のプッシュメカニズムで管理したりする予定はありません。プルベースの方法と同様にスケーリングしません。そして最後に、ソースマシンで利用可能なすべてのTCPソケットをすべてのアウトバウンドrshセッションで使い果たすケースを検出して防止します。その後、将来インストールされるすべての新しいホストのインストールイメージに行ったばかりのことをすべて取得し、死んで明日再構築する必要があるすべてのホストに対してそれを繰り返すという問題がまだあります。トラブルを経てrコマンドベースのレプリケーションを実装しましたが、それだけの価値がないことがわかりました。インフラストラクチャをrコマンドで再度管理したり、他のプッシュメカニズムで管理したりする予定はありません。プルベースの方法と同様にスケーリングしません。その後、将来インストールされるすべての新しいホストのインストールイメージに行ったばかりのことをすべて取得し、死んで明日再構築する必要があるすべてのホストに対してそれを繰り返すという問題がまだあります。トラブルを経てrコマンドベースのレプリケーションを実装しましたが、それだけの価値がないことがわかりました。インフラストラクチャをrコマンドで再度管理したり、他のプッシュメカニズムで管理したりする予定はありません。プルベースの方法と同様にスケーリングしません。その後、将来インストールされるすべての新しいホストのインストールイメージに行ったばかりのことをすべて取得し、死んで明日再構築する必要があるすべてのホストに対してそれを繰り返すという問題がまだあります。トラブルを経てrコマンドベースのレプリケーションを実装しましたが、それだけの価値がないことがわかりました。インフラストラクチャをrコマンドで再度管理したり、他のプッシュメカニズムで管理したりする予定はありません。プルベースの方法と同様にスケーリングしません。またはそのことについて他のプッシュメカニズムを使用します。プルベースの方法と同様にスケーリングしません。またはそのことについて他のプッシュメカニズムを使用します。プルベースの方法と同様にスケーリングしません。 それは、アーキテクチャの問題ではなく、実装の問題ではありませんか？スレッドプルサーバーよりもスレッドプッシュクライアントを記述する方が難しいのはなぜですか？
9
起動時に開始するサービスにulimitsを設定する方法は？
mysqlでラージページを使用するには、ulimitを設定する必要があります。これは、limits.confで行いました。ただし、limits.conf（pam_limits.so）はinitには読み込まれず、「実際の」シェルに対してのみ読み込まれます。以前、initscriptの開始関数に「ulimit -l」を追加することでこれを解決しました。ボックスをchefで管理し、RPMが実際に所有しているファイルを引き継ぎたくないので、これを行うための何らかの反復可能な方法が必要です。
5
構成マネージャー（Puppet / Chef / Ansibleなど）を使用するのが適切な場合
現在の職場では、2台のVMwareホストマシン、1台のOpenBSD物理マシン、3台のDebian VM、および6台のWindows Server VMを管理しています（2008/2012）。 PuppetやChefなどの構成管理ツールの実装を検討しています。これは合理的ですか、またはツールを学習するオーバーヘッドが利点を上回っていますか？管理性と実装コストの転換点はどこですか？
2
他のデプロイ戦略と比較したAWS Elastic Beanstalkの長所と短所は何ですか？
私はNetflix OSSスタック全体と展開全般についてはかなり新しいです。私の現在の知識レベルの背景として、私の主な役割はフロントエンドアプリケーションエンジニアとしてです。しかし、私は物事の運用面を楽しんでいるので、新しい展開戦略と新しいプロジェクトのツールをセットアップしようとしています。 私たちの目標 非常に簡単な展開（ボタンを押して生産を更新したい） テスト環境への自動展開（Jenkinsを使用） メンテナンスの容易さ（作成するアプリがあるため、本番の問題をいじるのに時間を費やしたくない） サービス指向アーキテクチャ（多くの小さなアプリ、さまざまな言語、データストア）を処理する機能 すぐに戦略を変更する必要がないことを保証する十分な柔軟性（すでにRightScaleから脱出しようとしています） 初期セットアップ時間をもう少し長くしても大丈夫です。そうすることで、将来の頭痛の種が減ります。 そのため、これらの方針に沿って、ポッドキャストを聞いたり、Opsのトークを見たり、たくさんのブログ投稿を読んだりして、目標とベストプラクティスを形成するために取ったものに基づいて、計画を立て始めました。 Asgard、パッケージをjarに丸め、AMIに丸めます。 これはすべて計画されていて、Chefサーバーを使用してインスタンスをオンザフライで収束するよりもプロセスの利点が好きでした（限られたタイムラインとChefサーバーワークフローに関する理解不足のため、これはエラーが発生しやすいと感じました）。しかし、同僚は自分で少し見回して、Elastic Beanstalkが私たちのニーズを満たしているように感じました。 私はそれを調べて、WARファイルとアタッチされたRDSデータベースを使用してテスト環境を作成しました。物事はうまくいくようで、Jenkinsを使用してAWS API経由でテスト環境へのデプロイを自動化できると思います。十分に単純に思えます...おそらく単純すぎます。 私が思っているのは、キャッチは何ですか？Elastic Beanstalkが非常にシンプルで効果的な場合、なぜそれ以上話されないのですか？2つの異なる展開戦略について十分な客観的な意見や事実を見つけるのに苦労しているので、周りに尋ねると思いました。 Elastic Beanstalkを使用していますか？もしそうなら、なぜ、どのような要因がその決定につながりますか？何が好きで嫌いですか？ Elastic Beanstalkを使用せずに検討した場合、何を使用し、なぜElastic Beanstalkを使用しなかったのですか？ SOAのElastic Beanstalkベースの展開戦略の長所と短所は何ですか？つまり、Elastic Beanstalkは、互いに依存して動作する多くの小さなアプリケーションでうまく機能しますか？
5
既存の構成管理システムの長所と短所は何ですか？[閉まっている]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 6年前に閉鎖されました。 CFEngine、Puppet、Chef、bcfg2、AutomateIt、およびその他の構成管理システムの比較を求めてここを探していましたが、Server Faultでほとんど何も見つからなかったことに非常に驚きました。たとえば、上記の最初の3つのリンクだけを知っていました-他の2つは関連するGoogle検索で見つけました。 だから、私は人々が最高のものだと思うもの、または彼らが好きなものには興味がありません。次のことを知りたい： 構成管理システムの名前。 既存のソリューションを使用するのではなく、作成された理由。 相対的な強さ。 相対的な弱点。 ライセンス。 プロジェクトと例へのリンク。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.