2

Rails/Postgres アプリに Docker と Fig を使用しています。

Rails アプリの更新を本番環境にプッシュする最良の方法は何ですか? 現在、本番環境で次のスクリプトを実行していますが、約 10 秒のダウンタイムが発生します。

sudo fig pull web
sudo fig up -d web

webFigがコンテナを再作成するときにダウンタイムが発生すると思います。

これは私が本番環境で使用するfig.xmlファイルです。

db:
  image: postgres:9.3
  volumes_from:
    - db-data
  ports:
    - 5432
web:
  image: myaccount/my_private_repo
  command: bundle exec unicorn -p 3000 -c ./config/unicorn.rb
  volumes_from:
    - gems-2.1
  ports:
    - "80:3000"
  links:
    - db

アプリのデモはこちら: https://github.com/evgenyneu/docker-rails-fig-sample

4

2 に答える 2

2

これにアプローチする通常の方法は、ロード バランサーの背後にある複数のサーバーでアプリを実行することです。アップタイムを維持するために、一度に 1 台のサーバーを停止し、新しいバージョンをプルし、新しいバージョンを実行するローリング アップグレードを実行します。

于 2014-12-16T00:33:54.663 に答える
1

推奨されるアプローチは"BlueGreen Deployment"と呼ばれ、図 1 によって調整される 1 台のサーバーだけで展開できます。

これを行うには、アプリケーション全体を起動します (これには BlueとGreen のインスタンスが含まれます)。

sudo fig up -d

次に、新しいバージョンにアップグレードする場合は、Green インスタンスのバージョン番号を変更してから、新しい Green インスタンスを強制終了、削除、起動します。

sudo fig kill greenapp && sudo fig rm --force && sudo fig -d --no-recreate

グリーンが問題なく戻ってきたら、 でこの手順を繰り返しblueappます。

Green と Blue の両方のインスタンス (Blue は として指定backup) を指すロードバランサーがあるため、一度greenappダウンすると、blueappすぐに負荷がかかり始めます。戻ってこない場合greenappは、バージョンをロールバックしてgreenapp再試行できます。Blue が以前に動作していたバージョンを指しており、すべてのネットワーク トラフィックを受信して​​いることを知っているので、停止について心配する必要はありません。

例fig.yml：

balancer:
    build: nginx/load-balancer
    ports:
        - "80:80"
    net: host

greenapp:
    image: webapp:1.0.2
    ports:
        - "3001:3000"

blueapp:
    image: webapp:1.0.2
    ports:
        - "3002:3000"

注: greenapp&blueappは 2 つの異なるポートにバインドされ、 にはリンクされていませんbalancer。それらがリンクされている場合、balancerそれらの1つをダウンさせようとすると、それをbalancerダウンさせる必要があるため、毛むくじゃらになります（ゼロダウンタイムの目標を破ります）.

于 2015-02-10T12:47:02.837 に答える