少し前まで、AcronisはChefで仮想マシンの一部を提供することに切り替えました。 特に新しいことはありません。すべての仮想マシンはESXIを使用して作成され、中央のシェフサーバーがレシピを配布し、役割に基づいて環境を自動的に上げます。 このようなシステムは問題なく機能し、しばらくの間クラッシュしました。 シェフサーバーウェブコンソールを開いて必要なノードを選択し、そのロールと設定をすべて表示するだけで十分なため、多くの手動作業、マシンの環境の継続的な監視、およびそれらのソフトウェアと設定を記憶する必要性から解放されました。
1つのサイトを外部ホスティングからサーバーに転送するというタスクを実行するまで、すべてが順調でしたが、最終的にはバグハントとScooby-Dooスタイルの調査につながりました。
興味があれば、猫にようこそ。
最初は、いつものように、ITサービスにESXIで空のDebian仮想マシンを起動するように依頼しました。 標準設定、それ以上。 これは既に1回または2回以上行われており、プロセスがデバッグされたため、キャッチは期待していませんでした。 アクセスのためのIPと資格情報を受け取った後、標準のknife bootstrapコマンドを実行してchef-clientをインストールし、中央のchef-serverに接続しました。 すべてがスムーズに進み、必要な役割をすべて設定し、新しいノードの属性を設定するために、Webインターフェースに進みました。
ここで、インストール中にchefが仮想マシン全体を実行し、システムに関するすべての必要なデータ（ハードウェアパラメーター、OS設定など）を収集することに注意してください。 次に、それらをchef-serverに送信し、ノード設定で確認できます。 通常、これらのデータは多数あり、私はめったにそれらを調べませんが、今回は、この新しいノードが何らかの形でそれらのほとんどを持たないという事実に注目しました。 その属性を他のマシンの属性と比較することで、私は再びこれを確信しました。 しかし、最も奇妙なことは、新しいノードの最後に表示された属性がgceと呼ばれ、他のマシンに存在しなかったことです。 また、展開すると、何も表示されなくなります。
なぜなら 仮想マシンは実稼働環境に直接送信されるように計画されていましたが、この状況は私には適さず、何が問題だったのかを明らかにすることにしました。 まず、ブラウザコンソールを見て、ブラウザがiframeの読み込みを拒否するという奇妙なエラーが表示されました。
www2.searchnut.com/?subid=704003&domain=
httpsのあるページの
www2.searchnut.com/?subid=704003&domain=
Webコンソールはhttps経由でのみ開きます）。 このアドレスをグーグル検索することで、これがマルウェアの一種であると告げる結果を見て、それを削除するオプションさえ提供しました。 ページのソースコードを見て、属性値が通常表示される場所に、6つの同一のHTMLコードが表示されていることがわかりました。
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> <head> <title>metadata.google.internal [6]</title> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <meta http-equiv="pragma" content="no-cache"> <style> body { margin:0; padding:0; } </style> </head> <body scroll="no"> <div style="position:absolute; top:0px; left:0px; width:100%; height:100%;"> <div id="plBanner"><script id="parklogic" type="text/javascript" src="http://parking.parklogic.com/page/enhance.js?pcId=5&domain="></script></div> <iframe src="http://www2.searchnut.com/?subid=704003&domain=" style="height:100%; width:100%; border:none;" frameborder="0" scrolling="yes" id="park" /> </div> </body> </html>
当時、多くの選択肢はありませんでした。 私は、仮想マシンが壊れているか、シェフ自身が壊れていて、何らかのゴミがパッケージに導入されていると判断しました。 いずれにせよ、良いことは何も期待されていなかったので、サポートシェフに直接連絡することにしました。 問題を説明してチケットを送信した後、別の仮想マシンを自分のマシンに同時に展開し、同じアクションを実行しました。 gceがないことがわかったときの驚きは何でしたか！ 彼女は他の皆と同じように問題なく働いた。
サポートからの回答を待っている間に、略語gceの意味を調べることにしました。 Google Compute EngineはGCE、つまりGoogleのクラウドの背後にあり、仮想マシンのホストを許可しており、シェフがそれらを構成できることが判明しました。
この時点で、彼らはサポートから私に答え、コマンド
ohai -l debug > ohai.log 2>&1
を実行して、この属性がどのように表示されるかを確認することを
ohai -l debug > ohai.log 2>&1
。 Ohaiはシェフシステムの一部であり、システムに関するすべての情報を収集するだけであることに注意することが重要です。 ログでは、次のことがわかりました。
[2014-10-03T08:27:30-04:00] DEBUG: has_ec2_mac? == false [2014-10-03T08:27:30-04:00] DEBUG: looks_like_ec2? == false [2014-10-03T08:27:30-04:00] DEBUG: can_metadata_connect? == true [2014-10-03T08:27:30-04:00] DEBUG: looks_like_gce? == true [2014-10-03T08:27:31-04:00] DEBUG: has_euca_mac? == false [2014-10-03T08:27:31-04:00] DEBUG: has_euca_mac? == false [2014-10-03T08:27:31-04:00] DEBUG: has_euca_mac? == false [2014-10-03T08:27:31-04:00] DEBUG: looks_like_euca? == false
最も重要なインデントを強調しました。 何らかの理由で、Ohaiはこの仮想マシンはGoogle Cloudでホストされていると判断しましたが、そうではありませんでした。 さらに、can_metadata_connect行に惹かれましたが、他のすべての仮想マシンではfalseが表示されました。 ITで合理的な質問をしたところ、非常に合理的な答えが得られました。これは私たち自身のサーバー上の通常のESXI仮想マシンであり、GCEの話はありません。
Ohaiのようなシェフ-オープンソース製品とそのソースコードは、私が行ったgithubで見つけることができます。 Ohaiソースで文字列looks_like_gceを検索した後、gce_metadata.rbファイルで興味深いコードを見つけました。
GCE_METADATA_ADDR = "metadata.google.internal" unless defined?(GCE_METADATA_ADDR) GCE_METADATA_URL = "/computeMetadata/v1beta1/?recursive=true" unless defined?(GCE_METADATA_URL) def can_metadata_connect?(addr, port, timeout=2) t = Socket.new(Socket::Constants::AF_INET, Socket::Constants::SOCK_STREAM, 0) saddr = Socket.pack_sockaddr_in(port, addr) connected = false begin t.connect_nonblock(saddr) rescue Errno::EINPROGRESS r,w,e = IO::select(nil,[t],nil,timeout) if !w.nil? connected = true else begin t.connect_nonblock(saddr) rescue Errno::EISCONN t.close connected = true rescue SystemCallError end end rescue SystemCallError end Ohai::Log.debug("can_metadata_connect? == #{connected}") connected end
Ohaiが仮想マシンからmetadata.google.internalリソースをリクエストして応答を取得できる場合、そのマシンは自動的にGCEと見なされます。 Googleで文字列metadata.google.internalを検索すると、これはネットワークからのみアクセス可能なGoogle Cloud内部APIのアドレスであることがわかりました。したがって、ノードからアクセスできませんでした。
古い仮想マシンでこの確信を確認した後、私は見ました：
$ wget http://metadata.google.internal --2014-10-04 13:47:29-- http://metadata.google.internal/ Resolving metadata.google.internal... failed: nodename nor servname provided, or not known. wget: unable to resolve host address 'metadata.google.internal'
しかし、この新しい仮想マシンでは、リクエストは問題なく通過しました。
$ wget http://metadata.google.internal.com --2014-10-04 13:50:38-- http://metadata.google.internal.com/ Resolving metadata.google.internal.com... 74.200.250.131 Connecting to metadata.google.internal.com|74.200.250.131|:80... connected. HTTP request sent, awaiting response... 302 Found Location: http://ww2.internal.com [following] --2014-10-04 13:50:39-- http://ww2.internal.com/ Resolving ww2.internal.com... 208.73.211.246, 208.73.211.166, 208.73.211.232, ... Connecting to ww2.internal.com|208.73.211.246|:80... connected. HTTP request sent, awaiting response... 200 (OK) Length: 1372 (1.3K) [text/html] Saving to: 'index.html' 100%[==============================================>] 1,372 --.-K/s in 0s 2014-10-04 13:50:40 (28.4 MB/s) - 'index.html' saved [1372/1372]
index.htmlの内容を見て、同じ不運なHTMLコードを見ました。 しかし、これはどうでしょうか？ 結局のところ、すべての仮想マシンはまったく同じであり、同じDNS 8.8.8.8を使用しています。 そして、どのような種類のww2.internal.comがリクエストされていますか？ nslookupを実行すると、私は見た：
$ nslookup metadata.google.internal Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: metadata.google.internal.com canonical name = internal.com. Name: internal.com Address: 74.200.250.131
何らかの理由で、 metadata.google.internalが metadata.google.internal.comでミスを犯し、それが問題でした。 /etc/resolv.confをすばやく見ると、他のマシンでは生成されなかった行
search com
見えました。
答えは簡単でした。 この仮想マシンを作成するときに、 new-site.comという名前が付けられました。 OSインストーラーはこの名前を選択し、comを分離し、resolv.confに自動的に追加しました。
したがって、Ohaiがシステムを実行し、metadata.google.internalにリクエストを行ったとき、metadata.google.internal.comから応答を受け取り、GCEマシンにいると考えました。 その後、GCE APIにリクエストを行い、iframeでこれらのページのみを受信しました。
彼らのvirtualkaを何かと呼ぶ誰もが判明した。 comはこのような問題を自動的に取得します。 当然、私はサポートシェフの登録を解除しました。そこで、彼らはこのオハイを書いている人に直接チケットを送ることを保証しました。 したがって、この問題がすぐに修正されることを願っています。
これで調査は終了です。 有罪は罰せられ、善は再び勝ち取られた。 一緒にいてくれてありがとう！