Rackspaceのクラウドサイトには多くの愚かな制限があります。たとえば、SSH(入力または出力)、シェル、RSYNCなどはありません...(cronを介しても)。
最近、クラウドサイトでシンボリックリンクを確実に使用できないことを知りました。どうやらこれは、多くのディスク/サーバー間で分割された共有ホスト環境であるため、サイトの絶対パスがいつでも変更される可能性があるためです。 Rackspaceが決定するたびに、異なるアカウントのサイトがディスクからディスクに移動すると思います。おそらく全体的な効率を高めるためです。
したがって、Rackspaceの技術者と話した後、彼は、シンボリックリンクが常に機能することを保証できないと述べました。明らかにこれは、次のような絶対パスを使用するシンボリックリンクがある場合です。
//mnt/disk-34566/home/user34566/files/sites/www.mysite.com/mydir
ファイルを別のディスク(またはファイルが行うもの)に移動すると、絶対パスが異なり、リンクが切断されます。それは理にかなっている。
そこで次に、Rackspaceの技術者に相対パスのシンボリックリンクが信頼できるかどうか尋ねました。したがって、次のリンクがある場合:
files/sites/www.mysite.com/mylink --> ../www.myothersite.com/anotherdir
シンボリックリンクが単に近くのディレクトリのサブディレクトリを指していることがわかります。彼は、それらでさえ常に機能することを保証することはできないと述べた。近くにある別のディレクトリへの相対パスを使用しているため、Rackspaceが行うことからどのように中断できるかわかりません。相対シンボリックリンクはどういうわけかその下の絶対パスに依存していますか?それとも、Rackspaceは、絶対パスの変更から抜け出す奇妙なカスタムファイルシステムを使用していますか?
相対パスのシンボリックリンクは問題ないようで、ユーザーが関連するディレクトリを台無しにするために何かをした場合にのみ壊れます。しかし、技術者が「いかなる種類のシンボリックリンクも公式にはサポートしていません」と言った場合、クラウドサイトの大規模な商用Webサイトにそれらを使用することを躊躇します。
Rackspaceの経験がある人は誰でもこのトピックについて意見を述べることができますか?
私はRackspaceを使用していませんが、ホスティングプロバイダーで働いていたので、一般的なアドバイスを1つ挙げることができます。
あなたのプロバイダーが「Xが機能することを保証することはできません」という趣旨の何かを言い、あなたがとにかくそれをすることを選択した場合、あなたはあなたをサポートする誰かの能力の範囲外です。
それがうまくいけば、「それは素晴らしいです!私たちはあなたに本当に幸せです!」
ある日機能しなくなった場合-「私たちに泣きに来ないでください、そうしないように言ったのです!」 (つまり、破損を自分で修正するか、プロバイダーに相談料金$を支払うことになります)。
技術的な観点からはわかりませんなぜ相対パスシンボリックリンクが壊れます。ただし、シンボリックリンクをサポートするファイルシステムを常に使用している場合に限ります。いつの日か、クラウドサイトがFlippyのFreaky Fantasy Filesystemに魔法のように移行する可能性がありますが、これはシンボリックリンクの概念をサポートしていません。これがクラウドの性質です。