2

安全な高可用性環境でのレールの展開戦略とスクリプトに取り組んでいます。現在のスクリプトは、自家製のシェルスクリプトです。より標準的なプロセスを使用したいと思います。だが...

高可用性の本番環境を持っている人なら誰でも、コードツリーのインスタンスからデプロイメントを実行するとは少し信じがたいです。そうする場合は、開発環境から本番環境にアクセスできないため、デプロイの目的でのみコードツリーを配置します。

生産には適さないと思うので、vagrantは使用しません。

オーバーヘッドが必要ないため、仮想ボックスは使用しません。

環境を高可用性にする方法については別の計画があるので、この質問はそれについてではありません。

安全な本番環境にレールをデプロイするための適切な方法が必要です。また、本番LANのコロのマシンにプロジェクトごとにツリーの特別なインスタンスを作成して、他のマシンにデプロイできるようにするのはばかげているようです。特に、デプロイによって使用するアプリのバージョンが取得されるためです。タグを使用するリポジトリ。

誰か助けてもらえますか?戦争の話がありますか?私が自分の意見を変える明確な理由は?

編集:コメントの質問ごと:

本番環境には、SSL、ファイアウォール、名前ベースの転送であるネットワーク層があります。AppレイヤーはRailsが存在する場所であり、本番環境の監視または管理のためにネットワークレイヤーを介してSSH接続されている(またはVPN接続されている)場合にのみアクセスできますが、開発ボックスから直接scp、rsync、またはsshを実行することはできません。dbレイヤーには、アプリレイヤーサーバーからアクセスできます。

ありがとう!

4

1 に答える 1

1

There is a relatively new deployment framework for distributed deployments called Juju. I've never used it for Rails. The only thing I've used for large rails deployments is chef, but a friend and I are working on using Juju for some other (jvm) projects, and it is pretty powerful.

Here's a good tutorial for getting started with rails and juju.

There is a rails juju charm that you can find (currently) on github

One of the advantages of juju is that you can have a single server that manages deployments to other servers. That way you don't have to open up the servers local machines for deployments.

Good luck!

于 2013-07-24T14:59:24.390 に答える