Ruby on the rails：ダミーの生産と展開

1年前、私は最初の鉄道アプリケーションを受け入れ可能な形式にしました。 本番環境で既製のコードを使用する問題は、以前は興味がありませんでした。 なぜ突然ですか？ 単純な言語、簡潔なフレームワーク-展開は、PHP後のメンタルブレーキを克服するよりも明らかに難しくありません。



Rails開発チームは、 Phusion Passengerの使用を推奨しています。これはmod_phpのようなものです。インストール、ファイルの配置、および飛行を行います。 この問題を研究した時点では、フォーラムにはソリューションのパフォーマンスに関する戦いがありませんでした。 乗客は彼らのお気に入りではありませんでした。



サイトのテクニカルディレクターに1日100万人のユニークな従業員にアドバイスを求めました。彼はNginxとUnicornでGoogleに送りました。 2009年のHabréにある生産セットアップ手順。 とりわけ、彼女はレッスン「フクロウの描き方」の欠点に圧倒されただけでした。



プロセスの一部は英語で噛まれているところもありますが、モノリシックチュートリアルは私の目に留まりませんでした。 鉄道コミュニティの伝統は、問題解決の結果と経験を共有するという原則に基づいています。



テキストは経験豊富な鉄道ガイドにとって興味深いものではありませんが、コメントに時間がかかる場合は感謝し、必要な変更を加えます。



-私たちは何について話しますか？

-この手順は、初心者がホスティングを選択および構成するのに役立ちます。また、初期展開および更新の体系的なロールアウトのために既存のプロジェクトを準備します。



-そして、より詳細に？

-Ubuntu 14.04、RVM、Nginx、Unicorn、およびCapistranoを使用します。 このテキストは、プロジェクトの準備とサーバーのセットアップの2つの章で構成されています。 ローカル操作はすべてMac OS Xで説明されています。RubyMineのような最新のIDEはプロシージャを実行するのに不必要ではありません 。 説明されているすべてのアクションは、 特別なリポジトリで修正されます 。

第1章ホスティング

ホスティングの選択

NginxとUnicornの甘いカップルにはRAMに対する非常に印象的な欲求があり、レール自体には多くの追加ソフトウェアのインストールが必要です。 これらの制限は、VPSの必要性を明確に示しています。 Herokuのような特殊なホスティングを使用するオプションがありますが、初心者にはセットアッププロセスを手作業で行うと便利です。



このテキストの一部として、Ubuntu 14.04に基づいて新たに作成されたドロップレットDigital Oceanを使用します。 （1か月分の十分なプロモーションコードがあります。インターネットで2回無料で使用でき、アカウントに10ドルの紹介が必要です-リンクを提供します。）

システムパックの更新

ルートの下のシステムに移動して、パッケージを更新します。

sudo apt-get update sudo apt-get upgrade
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

GitとNodeJSをインストールする

 sudo apt-get install git-core nodejs
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ユーザー作成

あなた（私のように）が展開に商業的関心を持っていると思います。 アプリケーションをデプロイするホームディレクトリに、別のユーザー（クライアント）を作成しましょう。 明白なことに加えて、このアプローチは、別個のRVM（Rubyバージョンマネージャー）の形で利点を提供します。これにより、さまざまなクライアントとアプリケーションにさまざまなバージョンのインタープリターとgemを使用できます。 demo



ユーザーを作成し、 sudo



グループに追加します。

 sudo adduser demo sudo adduser demo sudo
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

セッションを閉じて、 demo



ユーザーとしてログインします。

sudoのパスワードリクエストをキャンセルする

一部の展開手順では、スーパーユーザー権限が必要です。 コマンドがCapistranoを使用して実行され、エラーが発生しないようにするには、パスワード要求をオフにする必要があります。 sudoers



ファイルを編集します：sudo nano / etc / sudoers。

 #   : %sudo ALL=(ALL:ALL) ALL #     : %sudo ALL=(ALL) NOPASSWD:ALL
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Capistranoの公式ドキュメントでは 、ネイティブデプロイフェーズではsudoは不要であると説明されています。 ただし、すべてのプロセスを自動化する場合は、パスワードなしのsudoが不可欠です。

SSHキー生成

2つのキーペアが必要です。 それらのいずれかを使用して、あなた（およびCapistrano）はローカルコンピューターからサーバーに対して認証を行います。 2番目のペアでは、サーバーにリポジトリへのアクセスを許可します（いわゆるデプロイメントキー）。 どちらの場合も、パスフレーズは空白のままにします。

最初のペア（ ローカルで生成する必要があります）：

 ssh-keygen -t rsa -b 2048
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

キーを生成および使用する手順に精通している場合は、ファイルへのパスと好みに応じた耐久性を選択します。 それ以外の場合は、デフォルトのままにします。



次に、公開キーの内容（デフォルトではローカルコンピューターの~/.ssh/id_rsa.pub



）をコピーして、サーバーの~/.ssh/authorized_keys



ファイルに追加する必要があります。 SSHを使用したこの簡単な操作の後、パスワードなしでサーバーに接続できます。 そうでない場合は、サーバーの権限を確認します~/.ssh



場合は700、 ~/.ssh/*



場合は600です。

2番目のペア（サーバー上）：

 ssh-keygen -t rsa -b 2048
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

同様に、サーバーのコンテンツ~/.ssh/id_rsa.pub



をデプロイメントキーのリストに追加する必要があります（githubで各リポジトリの設定で見つけることができます）。

Fresh Nginxのインストール

Ubuntuで利用可能なNginxのバージョンは、多くの場合、公式の開発者リポジトリよりも古いです。 私は最新バージョンを使用しようとしますが、異なるビューがある場合は、Nginxを自分でインストールし、この部分をスキップしてください。



公式のUbuntuリポジトリをsudo nano /etc/apt/sources.listシステムリストに追加します。 ファイルの最後に行を追加します。

 # Nginx official repository deb http://nginx.org/packages/ubuntu/ trusty nginx deb-src http://nginx.org/packages/ubuntu/ trusty nginx
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

使用されるパラメーターはUbuntu 14.04にのみ関連することに注意してください。 開発者のサイトで、OSの他のバージョンへのインストールに関する情報を探してください。 これらのリポジトリからNginxをインストールするには、キーをダウンロードしてシステムに追加する必要もあります。

 wget http://nginx.org/keys/nginx_signing.key sudo apt-key add nginx_signing.key
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、利用可能なパッケージのリストを更新して、Nginxをインストールできます。

 sudo apt-get update sudo apt-get install nginx
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

/etc/nginx/conf.d



からデフォルトの構成を削除します。 （もちろん、「クリーンな」サーバーで作業していない場合は、これを実行しないでください。）次の章でアプリケーションの仮想ホストを作成します。

 sudo rm /etc/nginx/conf.d/* sudo service nginx restart
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

RVMをインストールする

 \curl -sSL https://get.rvm.io | bash -s stable source ~/.rvm/scripts/rvm
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

クリーンなサーバーの場合、いくつかの依存関係もインストールする必要があります。

 rvm requirements
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アプリケーションに必要なRubyバージョンを直接インストールする必要があります。 たとえば、新しい安定バージョン2.1.3：

 rvm install 2.1.3 rvm --default use 2.1.3
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ruby -vおよびrvm infoコマンドを使用してインストールを確認できます

アプリケーションコンポーネントをインストールする

確かに、アプリケーションはデータベースやImagemagick GPUなどの多数のコンポーネント（gemを除く）を使用するため、自分でインストールを完了する必要があります。 ここで、小さなコメントを追加する価値があります（忘れると、自動展開は失敗します）：レールは、いくつかのコンポーネントで動作するために追加のパッケージを必要とする場合があります。 たとえば、MySQLを使用するには、とりわけlibmysqlclient-dev



パッケージをインストールする必要があります。

第2章アプリケーションの準備

gitを使用する

私はあなたがすでに既製のアプリケーションを持っていると仮定します。 最初のルールは、プロジェクトをGitで管理する必要があるということです。 これは、鉄道の世界では事実上の標準です（作成されている鉄道アプリケーションのルートにある.gitignoreファイルでさえ、これを明示的に暗示しています）。 さらに、配備に直接責任を持つCapistrano gemの最新バージョンは、このシステムのみをネイティブにサポートします。

カピストラーノとは

Capistranoの公式の定義は、「リモートサーバーの自動化および展開ツール」です。 ユーザーの観点からすると、Capistranoは、SSHを介してリモートサーバー上で任意のコマンドセットを実行できるようにするものです。 展開には他のツール（Minaなど）がありますが、これまでのところ、Capistranoも特定の標準です。特に、役割ごとに分割されたサーバーを含む複数のサーバーへのアプリケーションの並行展開を実行できるためです。

カピストラーノの仕組み

サーバー上では、Capistrano全体の制御下にあるアプリケーション構造は、 repo



、 releases



、 shared



3つのディレクトリで構成さshared



ます。 最初のものにはリポジトリのコピーが含まれ、2番目にはリリースが含まれ、3番目にはアプリケーションに必要な、リリースに依存しない共有ファイルが含まれます。 また、ルートにはcurrent



シンボリックリンクがあり、現在のリリースのバージョンとデプロイログファイルを参照します。



（ローカルコンピューターから）Capistranoに展開するコマンドを与えると、サーバーへのSSH接続が確立され、簡単なアルゴリズムが開始されます。 最初に、Capistranoはリモートリポジトリをチェックし、欠落しているコミットを受け取ります。 新しいリリースが作成された後（ releases



ディレクトリ）。 現在のバージョンのコードがそこに転送され、そこで多くのテストが実行されます。



簡単に言えば、Capistranoは新しいリリースごとにbundle install



、 rake db:migrate



、 rake assets:precompile



などのよく知られているコマンドを実行し、競合やエラーを常にチェックします。 default.scss



のセミコロンを忘れて、現在のGemfile.lock



コミットせず、Paperclipを接続しましたが、Imagemagicをサーバーにインストールするのを忘れましたか？ これらすべての場合において、Capistranoはエラーを表示し、現在の作業リリースに影響を与えることなくインストールを終了します。 展開は成功したが、結果があなたに合わなかった場合、Capistranoを使用して、以前のリリースにrollback



できます。

構成ファイルの構成

Capistranoの各リリースは独立したエンティティです。 次回デプロイされたとき、完全に置き換えられるため、多数のファイルをアプリケーション構造の外部に保存する必要があります（原則として、ユーザーがダウンロードし、アプリケーションによって生成されたコンテンツ、および多数の構成）。



展開中に各新しいリリースにリンクする必要があるファイルである共通ディレクトリが必要になります。 共有と呼び、プロジェクトmkdir ./sharedのルートにローカルに作成します。以前は.gitignoreに例外を追加していました。 （もちろん、トレーニングリポジトリに例外を追加しません。）



共有ディレクトリに、将来の構造を事前に作成します。 まず、 config



とrun



フォルダーが必要です。 config



実際のバトルサーバーのdatabase.yml



とsecrets.yml



ます。 （個人的には、ローカルコンピューター上でこれら2つのファイルをconfigから移動してから、それらへのリンクを作成することを好みます。）

 mv ./config/database.yml ./shared/config ln -fs ./shared/config/database.yml ./config/database.yml mv ./config/secrets.yml ./shared/config ln -fs ./shared/config/secrets.yml ./config/secrets.yml
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Nginx設定

ここでは、 shared/config



、Nginx shared/config/nginx.conf



ます。 基本的な形式では、アップストリームと典型的な仮想ホストの2つの小さな部分で構成されています。 構成ファイルのパス（ 特にこれ以降）には特に注意してください 。 展開中に発生したエラーの90％はそれらに関連していました。

 upstream unicorn { server unix:/home/demo/application/shared/run/unicorn.sock fail_timeout=0; } server { listen 80 default; root /home/demo/application/current/public; try_files $uri/index.html $uri.html $uri @app; location ^~ /assets/ { expires max; add_header Cache-Control public; } location @app { proxy_pass http://unicorn; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_redirect off; } error_page 500 502 503 504 /500.html; location = /500.html { root /home/demo/application/current/public; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

VPSは単一のアプリケーションに使用するため、デフォルトでホストが使用されます。 （別の状況では、明示的にserver_nameを指定し、アップストリーム名の一意性に注意する必要があることを説明する必要はありませんか？）

ユニコーン構成

Unicornソケットへのパスを示すアップストリームを作成したので、その構成に進みましょう。 Gemfile



Unicorn gemを追加する必要があります。 新しいgemの追加には、バンドルのインストールとリポジトリへのコミットが伴うことを忘れないでください 。 git pushを忘れると、古いバージョンのコードがサーバーにアップロードされます。これらのgemがないため、デプロイ時にエラーが発生します。

 group :production do gem 'unicorn', '~> 4.8.3' end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

shared/config



ディレクトリで、 unicorn.rb



ファイルを作成します。 ほとんどの場合、アプリケーションのコンポーネントへのパスを指摘する必要があります。 便宜上、変数を使用してこれを行うことができます。

 #      root = '/home/demo/application' rails_root = "#{root}/current" # ,    Unicorn- pidfile = "#{root}/shared/run/unicorn.pid" pidfile_old = pidfile + '.oldbin' pid pidfile #   worker_processes 1 preload_app true timeout 30 #    listen "#{root}/shared/run/unicorn.sock", :backlog => 1024 #   - stderr_path "#{rails_root}/log/unicorn_error.log" stdout_path "#{rails_root}/log/unicorn.log" #    GC.copy_on_write_friendly = true if GC.respond_to?(:copy_on_write_friendly=) #  ,     before_exec do |server| ENV["BUNDLE_GEMFILE"] = "#{rails_root}/Gemfile" end #          before_fork do |server, worker| defined?(ActiveRecord::Base) and ActiveRecord::Base.connection.disconnect! if File.exists?(pidfile_old) && server.pid != pidfile_old begin Process.kill("QUIT", File.read(pidfile_old).to_i) rescue Errno::ENOENT, Errno::ESRCH end end end after_fork do |server, worker| defined?(ActiveRecord::Base) and ActiveRecord::Base.establish_connection end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

一部のシステム値（ 完全なリストとドキュメント ）も示されています。 ワーカーの数worker_processes



に注意してworker_processes



。各ワーカーは、一定量のメモリ（アプリケーションによって異なります）とtimeout



（通常worker_processes



秒）を消費します。 多くの人がpreload_app



についても言及していpreload_app



（そのfalse



値はワーカーの起動時間を短縮する可能性があります）。 とりあえずtrue



停止しましょう。それから、あなたは自分で決定します。

Capistranoの接続と構成

エッセンシャルジェムズ

Capistranoと、RVM、Bundler、およびRailsとの接続を実装する一連のgemをGemfileに追加する必要があります。

 group :development do gem 'capistrano', '~> 3.2.1' gem 'capistrano-rvm', '~> 0.1.1' gem 'capistrano-bundler', '~> 1.1.3' gem 'capistrano-rails', '~> 1.1.2' end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

バンドルインストールを実行し、cap installを使用してCapistranoを初期化します。 ファイルのセットが作成され、そのリストがコンソールに表示されます。 Capfile



、 config/deploy.rb



およびconfig/deploy/production.rb



3つを使用します。 （ config/deploy



Capistranoはデフォルトのstaging.rb



およびproduction.rb



ファイルを作成しますstaging.rb



を使用してのみバトルサーバーを構成します。）

Capfile



更新

機能を使用するCapistranoに関連付けられているすべてのgemは、ルートで作成されたCapfile



で接続する必要があります。 デフォルトのファイルを見て、必要な行のコメントを外すか、次の内容を使用します。

 require 'capistrano/setup' require 'capistrano/deploy' require 'capistrano/rvm' require 'capistrano/bundler' require 'capistrano/rails' Dir.glob('lib/capistrano/tasks/*.rb').each { |r| import r }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実動サーバーのセットアップ

config/deploy/production.rb



ファイルを開き、その内容を注意深く見てください。 フォーマットとカスタマイズのオプションを理解するのに役立ちます。 一般に、SSHキーを使用して認証を使用する場合、異国情緒を書く必要はありません。 1行だけ：

 server '178.62.252.46', user: 'demo', roles: %w{web app}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

展開シナリオ

最も興味深い部分であるconfig/deploy.rb



。 今後の展開のパラメータ、手順、およびシナリオを説明するのは彼です。 ファイルの各ブロックについて説明しますが、最終的な形式で見たい場合は、リポジトリを使用してください。

必須パラメーター

まず、このシナリオの対象となるCapistranoのバージョンを指定する必要があります。

 lock '3.2.1'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Capistranoには、いくつかの必須パラメーターが必要です。

 #  set :repo_url, 'git@github.com:eboyko/deneb.git' #   set :rails_env, 'production'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アプリケーションをサーバーにデプロイするためのパスを決定するdeploy_to



パラメーターと同様に。 既に上記のように商業的利益を意味すると述べたため、変数の助けを借りてスクリプトファイルをより普遍化し、欠落しているパラメーターを設定します。

 #   set :username, 'demo' #   set :application, 'application' #    set :deploy_to, "/home/#{fetch(:username)}/#{fetch(:application)}"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

log_level



パラメーターも設定します（デフォルト値:debug



はCapistranoをあまりにもおしゃべりにします）：

 set :log_level, :info
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Capistranoグローバル変数（ shared_path



）を直接使用できることに注意してください 。 setでset



fetch



メソッドを使用。

不揮発性データ

以前のバージョンで作成されたデータにアクセスするための作業リリースの必要性については既に検討しました。 たとえば、ユーザーがアップロードしたファイルはpublic/upload



保存します。 それらをそれぞれの新しいリリースに接続するには、 config/deploy.rb



:linked_dirs



パラメーター:linked_dirs



設定します。

 set :linked_dirs, %w{public/upload}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

各展開で、 public/upload



は、以前のリリース中にデータが収集されたshared/public/upload



ディレクトリへのシンボリックリンクに置き換えられます。 同様に、 :linked_files



を使用すると、個々のファイルがリンクされます。

 set :linked_files, %w{config/secrets.yml config/database.yml}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

指定されたファイル（ config/secrets.yml



およびconfig/database.yml



）をconfig/secrets.yml



追加する必要があることに注意してください 。 そうしないと、データベースへの接続がないためにデプロイメントが失敗します。

手続き

Capistranoを使用すると、便宜上、名前空間に組み合わせることができる一連のプロシージャを作成できます。 名前空間:deploy



すでに存在し、補足のみ可能です。 production



サーバー用に含まれるすべての手順は、cap production deployコマンドで呼び出すことができます。

セットアップ

前の手順の結果、 shared



ディレクトリを作成しshared



ディレクトリには、特に構成ファイル（ shared/config



）が含まれています。 論理的な最初のステップは、それらをサーバーにアップロードすることです。 これを行うには、名前空間:setup



内のすべてが同じconfig/deploy.rb



にあります:setup



手順を記述します。

 namespace :setup do desc '     ' task :upload_config do on roles :all do execute :mkdir, "-p #{shared_path}" ['shared/config', 'shared/run'].each do |f| upload!(f, shared_path, recursive: true) end end end end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご存知のように、この手順ではshared_path



を作成し（サーバーにまだ構造が存在しないため）、そこにローカルのshared/config



ディレクトリをロードします。 cap production setup：upload_configコマンドで実行できます

Nginx管理

Capistranoは、本質的にリモートサーバーで任意のコマンドを実行する方法であることに注意しました。 Nginxを含む構成ファイルをダウンロードしました。 次に、管理のためのいくつかの手順を作成します。構成へのシンボリックリンクの作成とサービスの再読み込み/再起動（ sudo



権限が必要です）。

 namespace :nginx do desc '   /etc/nginx/conf.d  nginx.conf ' task :append_config do on roles :all do sudo :ln, "-fs #{shared_path}/config/nginx.conf /etc/nginx/conf.d/#{fetch(:application)}.conf" end end desc ' nginx' task :reload do on roles :all do sudo :service, :nginx, :reload end end desc ' nginx' task :restart do on roles :all do sudo :service, :nginx, :restart end end after :append_config, :restart end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

いいことに気づいた？ -同じネームスペース内およびそれらの間のさまざまなプロシージャの実行順序を指定できます。

オフィスユニコーン

確かに、UnicornコントロールプレーンにCapistranoを拡張するジェムが既にありますが、実際にどのように機能するのかを知りたいと思いました。 したがって、今、前の例と同様に、Unicornの2つの手順（開始と終了）を記述します。

 set :unicorn_config, "#{shared_path}/config/unicorn.rb" set :unicorn_pid, "#{shared_path}/run/unicorn.pid" namespace :application do desc ' Unicorn' task :start do on roles(:app) do execute "cd #{release_path} && ~/.rvm/bin/rvm default do bundle exec unicorn_rails -c #{fetch(:unicorn_config)} -E #{fetch(:rails_env)} -D" end end desc ' Unicorn' task :stop do on roles(:app) do execute "if [ -f #{fetch(:unicorn_pid)} ] && [ -e /proc/$(cat #{fetch(:unicorn_pid)}) ]; then kill -9 `cat #{fetch(:unicorn_pid)}`; fi" end end end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

パラメータ値:unicorn_config



および:unicorn_config



を忘れずに設定してください。

展開前後の手順

展開後、最も古いリリース（デフォルトではCapistranoが最後の5つを保存）を削除し、キャッシュをクリアして、Unicornを再起動する必要があります。 メインの作業ブロック:deploy



は次のようになります。

 namespace :deploy do after :finishing, 'application:stop' after :finishing, 'application:start' after :finishing, :cleanup end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プロシージャを個別のファイルに入れる

deploy.rb



ファイルが乱雑にならないようにするために、書かれた手順をその外部で実行することができます（また、そうすべきです）。 Capfile



最後の行がそのようなタスクをlib/capistrano/tasks



ディレクトリからインポートする役割をlib/capistrano/tasks



-これは、ロジックのこの部分を移動する場所です。

展開の実行

この時点から、アプリケーションの新しいバージョンをロールアウトするために必要なことは、変更をコミットし、git pushを実行し、cap production deployコマンドを使用することだけです。



同様に、 staging



サーバーを構成することができます。 staging



サーバーは、キャップステージングデプロイの実装先です。



何かが失敗していますか？ -コメントを残して、記事を補完しましょう。

更新予定：

-既存のアプリケーションサーバーの概要（Unicornを選択した場合）。

-プロセス管理（ユニコーンワーカーキラーとマネージャー）;

-アナログRVMの選択と構成。

-PPAを使用してNginxをインストールします。

-パスワードなしのsudoに関する編集。