質問: dockerと一緒にpuppetを使用する理由はありますか? devopsのopsの部分を少し前に試しましたが、それはとても楽しかったですが、どのプロジェクトでも試す時間と理由がありません。しかし先週、私は新しい仕事を始めました。そこでボスは、会社のプロジェクトのステージング環境のようなものを作るようにサーバーを構成できるかどうか尋ねられました。それに加えて、私はプロジェクトを移行するだけでなく、devopsになることを考え始めました。私はdockerを使用してきましたが、これは非常に簡単でとても便利です。しかし、少し前にpuppetを試していたので、「dockerでpuppetを使用する理由はありますか?」という疑問が浮かびます。 dockerはpuppetと同じことをすべて実行しているようですが、より簡単な方法です。[〜#〜] ps [〜#〜]少し前にhacker newsに consul がありましたサービスの発見、それで設定さえ解決することができます(そして私はこれも実装することを考えています)。
回答: puppetとdockerは同じことの多くを実行できますが、アプローチは異なります。puppetはファイル+パッケージ+サービスを管理します。 (三連符と呼ばれる)。 dockerは、バイナリーと構成ファイルをコンテナー内にカプセル化します。この記事の執筆時点では、dockerはまだ不安定であり、本番環境では使用しないでください。 apiの多くは、バージョン1.0がリリースされるまで変更される可能性があります。dockerが安定した場合でも、すべてのプロセスと構成ファイルをdockerコンテナーに変換するのは大きな仕事です。一方、puppetは安定した製品であり、ツール(heira、mcollective、facter、razor)のエコシステム全体が付属しています。これらのツールは、問題が発生することを心配することなく、すばやく実装できます。以下のリソースを強くお勧めします。パペットでアプリケーションスタックを管理する方法のビデオ https://www.youtube.com/watch?v=kso_mcjxfia dockerとpuppetがどのように連携するかについてのポッドキャスト http://devopscafe.org/show/2014/1/23/devops-cafe-episode-46.html dockerと統合する方法に関する人形のブログ記事 http://puppetlabs.com/blog/building-puppet-based-applications-inside-docker パペットとドッカーの共存に関する別のブログ記事 http://puppetlabs.com/blog/can-containers-and-configuration-management-co-exist dockerと対話するための人形モジュール http://docs.docker.io/use/puppet/ devopsの用語に関するマイナーな修正。 devopsは、特定のツールよりも、開発者と運用が協力する ソフトウェア開発方法論 のようなものです。更新現在、私の会社は人形とドッカーの両方を使用しています。ここでは、puppet conf 2014で行われた、puppetとdockerを使用する理由についての素晴らしいプレゼンテーションがあります。人形劇の元雇用者であり、港湾労働者の本の著者でもあるジェームズターンブルによって与えられました。 https://puppetlabs.com/presentations/using-docker-puppet-james-turnbull-kickstarter また、sysadmincasts.comが提供するdockerの優れた短いビデオチュートリアル https://sysadmincasts.com/episodes/31-introduction-to-docker dockerプロ: インスタンスをすばやく起動できます 人形よりも学びやすい ダウンタイムが簡単 dockerの短所: devicemapperバックエンドを使用する場合、コンテナーには10gbの制限があります 小さな構成変更は、コンテナーの再構築に長い時間がかかります hub.docker.com、quay.ioなどのdockerレジストリを使用すると、費用がかかります(自己ホスト型のdockerレジストリは非常にバグが多く、guiがありません) 適切な初期化システムがありません。一部のアプリケーションは、niceを再生しません。 ネットワークをきめ細かく制御できない サブシェルを必要とするアプリケーション(rvm + rubyを見る)は、適切に機能させるのが非常に難しい windowsホストを管理できない、slesやその他のあまり人気のないオペレーティングシステムは管理できない 現在、dockerオーケストレーションは非常に若いです。 現在、ビルド時に/etc/resolv.confを設定できません / etc/localtimeおよび/ dev/urandomをマウントしてホストのlocaltimeおよびurandomディレクトリにマッピングする必要があるさまざまなバグ。 パフォーマンスはそれほど速くありません(dockerはベアメタルの99%の速度である必要があるという主張にもかかわらず、他のマシンよりも30%遅い場合があります)。 小さなコンテナには、依然として数百メガバイトのオーバーヘッドがあります。私たちのコンテナはすべて数ギガバイトです。 人形長所: スケーリングが簡単 既存のサーバー(windows、linux、sles)で動作します 小さな変更をすばやく行う 他のパペットユーザーとモジュールの強力なコミュニティ すべてのプラットフォームにパッケージをインストールするための標準化されたapi 人形の短所: 大規模なインフラストラクチャは非常に複雑になります 条件付きモジュールの依存関係がspagettiコードを作成する より重い 現在、パッカーを使用してdockerコンテナーをプロビジョニングしています。 dockerコンテナーはjenkinsビルドに使用され、ビルドごとに破棄されます。それはうまく機能し、一貫した環境を提供します。つまり、コードを1回記述すれば、ubuntu、sles、centosマシンの両方を再構築する必要があります。コンテナの再構築には約15〜30分かかりますが、これはまだ手動のプロセスです。 dockerはクイックテストvmを起動するのに最適です。つまり、パペットは既存のインフラストラクチャの管理に優れています。 dockerは、100%linuxのグリーンフィールドがあり、テクノロジースタックが小さな一時的なインスタンスで囲まれている場合に適しています。一部の機能は重複していますが、相互に排他的ではありません。