Windows で Ruby on Rails を実行することは、歴史的に最悪でした。 Ruby/Rails 関係者のほとんどは Mac と Linux のユーザーであり、Rails を Windows での日常的な開発に使用できるようにすることに重点を置いていません。 RailsInstaller のようなプロジェクトで Rails を動作させるために、多くのボランティアによる英雄的な努力が行われてきましたが、ほとんどの場合、ネイティブ モジュールと依存関係は問題を引き起こします。さらに、Rails アプリをデプロイする場合、Linux ホストを使用する可能性が高いため、オペレーティング システム間の違いに遭遇する可能性があります。
今日に早送りすると、Windows 10 には Ubuntu ベースの「Windows 用 Linux サブシステム」(WSL) とネイティブの bash シェルがあり、仮想マシンなしでネイティブに Windows で実際の Linux elf バイナリを実行できることを意味します。 Bash on Windows での Windows ベースの Rails 開発。
Ruby on Rails の開発は Windows 10 で優れています。なぜなら、Windows 10 が "windows" UI 部分を処理し、bash と Ubuntu がシェルを処理しているためです。
セットアップが完了したら、アプリを Azure に簡単に git デプロイしたいと考えています。
WSL を使用した Windows 10 上の Ruby on Rails での開発
Rails と Ruby の関係者は、apt-get update と apt-get install ruby を実行でき、好きなように rbenv または rvm をインストールできます。最近は rbenv が好まれています。
Windows 10 に Ubuntu をインストールしたら、このように "rbenv" を Bash 内にすばやくインストールできます。ここで 2.3.0 を取得します。
~$ git clone https://github.com/rbenv/rbenv.git ~/.rbenv
~$ echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc
~$ echo 'eval "$(rbenv init -)"' >> ~/.bashrc
~$ exec $SHELL
~$ git clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build
~$ echo 'export PATH="$HOME/.rbenv/plugins/ruby-build/bin:$PATH"' >> ~/.bashrc
~$ exec $SHELL
~$ rbenv install 2.3.0
~$ rbenv global 2.3.0
~$ ruby -v
~$ gem install bundler
~$ rbenv reshash
これは、SurfaceBook のプロセス途中のスクリーンショットです。このビルド/インストール手順には時間がかかり、ディスクに多くの負荷がかかります。参考までに。
この時点で、私は Ruby を手に入れました。今度は Rails と、Rails Asset Pipeline 用の NodeJ が必要です。必要に応じてバージョンを変更できます。
@ curl -sL https://deb.nodesource.com/setup_4.x | sudo -E bash -
$ sudo apt-get install -y nodejs
$ gem install rails -v 5.0.1
また、PostgresSQL、MySQL、または Mongo のいずれかが必要になる可能性があります。または、Azure DocumentDB などのクラウド DB を使用することもできます。
Windows と Linux の両方で同時に開発を行っている場合、コードを両方ではなく、どちらか一方に保持する必要があります。 WSL が /mnt/c に作成する自動マウント ポイントを使用するため、このサンプルでは、Windows デスクトップのフォルダーにマップされる /mnt/c/Users/scott/Desktop/RailsonAzure にいます。 CR/LF 設定に気を付けて、1 つの世界にとどまるだけで、どこにいてもかまいません。
「rails new 」を行いました。そしてそれをローカルで実行しました。ここでは、Ruby 拡張機能を使用して Visual Studio Code を使用し、私のプロジェクトを Windows 上の Bash の隣で開くことができます。
Rails アプリを実行して、Windows 上の Visual Studio Code と Ubuntu 内の Bash プロンプトの間を行き来しながら、問題なく開発できるようになったら、アプリを Web にデプロイしたいと考えています。
これは単純な「Hello World」のデフォルトの Rails アプリであるため、Rails 環境が Production である場所にデプロイすることはできません。 routes.rb には Route がなく (Yay! You're on Rails メッセージは開発時のみです)、署名付き Cookie の検証に使用される SECRET_KEY_BASE 環境変数セットもありません。この2つを追加する必要があります。次のように、このデモのデフォルトのウェルカム ページを使用するように、routes.rb をすばやく変更します。
Rails.application.routes.draw do # For details on the DSL available within this file, see http://guides.rubyonrails.org/routing.html get '/' => "rails/welcome#index" end
また、バックエンドを作成するときに、Azure portal で App Setting/ENV var として SECRET_KEY_BASE を追加します (以下を参照)。
Ruby on Rails アプリを Linux 上の Azure App Service にデプロイする
Azure portal の [新規] メニューから、[Linux 上の Web アプリ] を選択します (私がこれを書いた時点でプレビュー中)Web + Mobileオプションから。これにより、アプリを含む App Service プランが作成されます。 node.js、PHP、.NET Core、Ruby など、ここで使用できるアプリケーション スタックが多数あります。
<ブロック引用>注: いくつかの用語集と定義ポイント。 Azure App Service は、Azure PaaS (Platform as a Service) です。 Azure App Service で Web Apps を実行します。 Azure App Service 計画 n をホストする基盤となる仮想マシン (sall、medium、large など) です。 App Services/Web サイトの数。小規模な VM を使用する App Service プランで 20 の App Services/Web サイトを実行しています。デフォルトでは Windows で、Php、Python、Node、.NET などを実行できます。このブログ投稿では、Linux を実行し、Docker コンテナーをホストする App Service プランを使用しています。私の Rails アプリはその App Service 内に存在し、https://github.com/Azure-App-Service/ruby で Dockerfiles やその他の情報を見つけるか、独自の Docker イメージを使用できます。
ここでは、Git を使用してデプロイする Azure App Service を確認できます。 FTP もできます。
Deployment OPtions に入り、(Azure に対して) ローカルの git repro をセットアップしました。 [概要] の下に表示されます。
ローカルの bash で、azure をリモートとして追加します。これは、ワークフローが設定されていても設定できます。この場合、Git はコード用の FTP です。
$ git add remote azure https://[email protected]:443/RubyOnAzureAppService.git
$ git add .
$ git commit -m "initial"
$ git push azure master
これにより、コードが Azure にプッシュされてデプロイが開始されます。
重要 :"RAILS_ENV=production" と SECRET_KEY_BASE=も Azure アプリケーション設定に追加します。 「rake secret」で新しいシークレットを作ることができます。
問題が発生した場合は、[診断ログ] で [アプリケーション ログ]、[Web サーバー ログ]、[詳細なエラー メッセージ] をオンにしてから、FTP で App Service にアクセスしてログを確認できます。
これはすべてプレビュー段階であるため、問題が発生する可能性があります。彼らは基盤となるシステムを非常に頻繁に更新しています。私がヒットしたいくつかの落とし穴:
- デプロイ/再デプロイには、今日、明示的にサイトを再起動する必要があります。すぐに治ると聞いています。
- FTP 経由でログ ファイルを掘り出さなければなりませんでした。彼らは、ポータルでログを公開する予定です。
- mysite で Kudu の「サイドカー」サイトを使用しました。scm .azurewebsite.net を使用して Kudu コンテナーへのシェル アクセスを取得していますが、いつか Azure Portal から実際に実行中のコンテナーに ssh 接続またはアクセスできるようにしたいと考えています。
とはいえ、これがどのように機能するかについて内部の詳細を知りたい場合は、昨年の Connect() で開発者 Nazim Lala とのセッションを見ることができます。デバッグを手伝ってくれた James Christianson に感謝します!
スポンサー: VSTS が Octopus Deploy と密接に統合できることをご存知ですか? Damian Brady と Brian A. Randell が、VSTS から Octopus Deploy への展開を自動化する方法を紹介し、新しい VSTS Octopus Deploy ダッシュボード のデモを行うのをご覧ください。 ウィジェット。今すぐ見る