I am planning to use the Sakura Cloud to perform the production operation of Rails application.
I constructed the environment according to the following procedure and started the server, but it was useless.
Flow of environment construction
I set Sakura Cloud as below and did an ssh log in from the development environment.
I installed Ruby using Rbenv, and installed bundler, and Rails.
I started the server with RAILS_ENV = production bundle exec rails s - e production - b <IPv4 address>.
It is my first time to use production and Sakura Cloud, so it may be that I have missed or made a mistake with some setting.
It will be helpful if someone with detailed knowledge lets me know.
Setting of Sakura Cloud
1 core, 1 GB
CentOS 7.5
NIC is Internet connection, paravirtualized mode (I do not understand this in any way.)
The public key contains the public key generated in the development environment, there is no startup script
Application stacks
ruby 2.2.10
rails 5.0.7
puma
SQLite 3
Related
My issue is that I created a droplet to develop Rails apps in digitalocean .
I used the one-click rails droplet. And now I want to create more rails apps than the default rails app in this droplet.
The issue here is that it comes installed with nginx/unicorn .. And they're always on with path of default rails project in their config files.
Now let's assume I created another rails app(file) and I want to run it using "rails s" instead of default rails app that is created by the droplet. How can I do it?
Note: I don't want to change the file path in configs each time I decide to try another app
PS: I tried stopping the service of unicorn/nginx one at a time and both of them in the same time to use "rail s" to run the app .. But it didn't work .. Web pages were not loading
I know it might be a question of a rookie. But I'm kinda new to these stuff and I'd appreciate it if anyone could help me.
If you run it with rails s on the server, chances are it will be running with Puma, or if you're on an older version of Rails, Webrick. Unicorn is not involved in that case because Rails is using its own default web server. If you see that 'rails s' is not running in the right environment, it may be because RAILS_ENV is being set in your shell profile. You can override that by doing:
RAILS_ENV=development rails s
To launch your console.
That being said, rails s runs on localhost:3000 by default - and in the case you described it would be running on DigitalOcean's localhost - not yours. In order to get to it from your local machine, you would need to set up some sort of reverse proxy to allow connections to DO to get served from localhost. This is what nginx is doing for you - it's facilitating a reverse proxy.
If you want do use your DO server as a development machine for a second rails app you have, you're going to have to create that new rails app on the server, then create the reverse proxy settings in nginx to direct to it, then finally create the unicorn settings to serve it. This is an uncommon way of developing though. I recommend using your local machine to develop, and setting up Capistrano or some other deploy tool to deploy it to DO instead. You'd still need to add the settings in nginx/unicorn for the second app, but it will save you headache down the road.
I was wondering if there was a way to use the Puma server (Rails default) JUST on the new Rails 5.1 system tests?
Right now on all our projects we use tiny_tds, but I was trying to experiment with 5.1 system tests with Capybara/Selenium but it fails of course because I do not have Puma installed/running.
I took a look through the documentation and didn't see anything about declaring what type of server you want to use. Were connecting to a SQL Server database so I don't know if Puma is able to do that (And that's probably why were using tiny_tds in the first place).
You're confusing database adapters and rack web servers which are very different things.
Puma (like Webrick, Thin, Unicorn etc) is a general purpose Rack web server. It sits and waits for incoming requests from vistors and dispatches them to an application (like a Rails app) by calling it with a hash containing the environment and request. The application returns an array containing the response. The server sends it back to the visitor.
tiny_tds on the other hand is a database adapter. Its used to connect the application to the database. The web server is almost completly oblivious to how the application creates a response from the request. This includes whatever databases are used.
In Rails 5 most servers don't require configuration. You just add the gem to the gemfile and run bundle install and they plug themselves in. There in no seperate installation step.
That was not the case earlier which is why Webrick - a server with the only real merit being that it does not require configuration was the default. It is now Puma which unlike Webrick is suited for production.
Using different servers in different environments is not a good idea since it violates the idea of dev/prod parity. Your dev & test environment should be as close as possible to what you are deploying to so that you can catch bugs before they end up in production. This means you should be running the same server, same database etc.
Running a seperate test server for different parts of your test suite sounds like a true fools errand - if its even possible without hacking the framework to bits.
For SQL Server there is activerecord-sqlserver-adapter which can use tiny_tds as a backend.
I'm able to run rails s through ssh successfully and see the app start up just as it does on my own machine but I'm unable to access the app from the web. The app is directly under the home folder and I have a symbolic link pointing from public_html to the public folder of my rails app, just as this tutorial explains. I even tried setting up a subdomain and every other step in the tutorial to no avail. Any help would be highly appreciated.
You need an application server like Phusion Passenger, Unicorn or puma to run a Ruby app in a production environment. Typically, you'll integrate the application server into a web server's (Apache, nginx) environment.
I don't know about your hoster, but if you have root access, then you can probably use any of these application servers.
The built-in server you start by running rails server is only meant for testing purposes on your local machine. It has not been made with security, performance, stability or any other production-environment criteria in mind.
Hi i have created a ubuntu virtual machine in windows azure for deploying my rails application..
I have connected to my virtual machine through ssh and followed this procedure for deployment
<http://www.andrehonsberg.com/article/install-rvm-ubuntu-1204-linux-for-ruby-193>
<http://www.windowsazure.com/en-us/develop/ruby/tutorials/web-app-with-linux-vm/>
My deployment was completed successfully.
While starting my server by running rails s in my application i am able to see my application up and running in browser.
My issue is the server is stopped for every 10 minutes and again i have to connect to my server through ssh and need to give rails s..
i want a solution to run my application continously..
The problem is you haven't actually "deployed" anything. You just copied your rails app to a VM and ran rails s.
A production rails applications is not deployed in this fashion.
Consider using either nginx with unicorn or apache/nginx with passenger.
Should I be using passenger in dev to match prod for a ruby on rails project? (as opposed Webrick)
Noting I'll be deploying to dreamhost which uses passenger.
(Also if yes, does it have it's own web-server or do I need to install one?)
Set up a passenger staging server on your production machine. Use same configuration as pro server.
This has just saved my bacon. A recent upgrade we recently pushed broke application and took me a week to get sorted. Fortunately production server continued to function which we found prob.
Use capistrano multistage to manage the same.
You don't have to (mostly). But there might be cases where things can go wrong due to the mismatch between production & dev environment. Using staging environment will catch such issues.
If you want to test things like SSL, then webrick wont work. You need apache/nginx(or other web servers) to use passenger. I also noticed that there is no significant difference in the performance between the two options