I got already deployed server on JELASTIC. The problem is that if I do a deploy, rails_env in /etc/nginx/ruby.env is setting up by itself on ROOT -- not production as I want to. Then my application crash, because rails cannot see a ROOT env in database.yml. The case is that i do not want to add ROOT on database.yml. I want to keep it as clean as possible so I want to deploy my app in production environment.
When I click on "edit project" i got sth like this:
Which says that context production is already in use (and it is, because THIS app is deployed in production mode, like you can see in previous screen). When i do not choose any application deployment type, i have blank selectbox with ROOT placeholder (which is apparently used as deployment type because rails_env in ruby.env is set like this).
I tried also deploy app from deployment manager:
which allow me to choose environment and deployment type and
tells me that this context is already in use and if I want to redeploy context
but it deploy also as a ROOT and i have to change manually nginx ruby.env and restart nginx to make it work.
Do you have any idea, what am I doing wrong?
Any suggestions?
Two more questions, why deploy hooks does not save (for example it run previous hooks even if i delete them and replace with simple "echo")
And last question is, can i somehow create new deployment type called "staging", becasue as we know "development", "production" and "test" are used to other things like staging. I need staging for other purposes, like for example disabling mailers for client test servers.
Related
I'm using Heroku + Rails 5.1.
I just want my postdeploy script written in app.json to run only in Review Apps environment.
I have done something like this by setting a config var in my staging environment (the parent for my review apps) which tells my postdeploy that it is not in production. I added the cli webpack to app.json and inside my postdeploy I get the value of that config var and then conditionally execute code. In production, we set a different var.
You could also just check the $HEROKU_PARENT_APP_NAME inside the review app (you must have this env var defined in app.json for it to appear in review app), and if the parent app == staging (or whatever), don't execute whatever is in your post deploy
good luck, getting review apps to work right can be a huge pain
I was reading from this article that you can create a config/local_env.yml with environment variables and then use config/application.rb to read it to replace/take priority before the environment variables that you export in your .bashrc. What then is the .env used for then? Does it serve the same purpose as the config/local_env.yml?
All of these methods are used to feed environment variables to your rails application. So, from an app's point of view, it serves the same purpose whether you export it from .env or .bashrc or config/local_env.yml files.
The differences in these methods are really a matter of personal choice among the team members involved in maintaining the app's development and deployment environments. However, here are few things to consider while opting for either of these choices.
.bashrc - Use this if you manually configure deployment servers and really comfortable with linux/unix command line system administration. This configuration file is specific to bash shell (Bourne Again Shell). You need to configure different file if your server uses different shell (for example: .zshrc if it uses Z Shell)
.env - Use this if you want to keep your app centric environment variables within the app itself while maintaining different variations of environment variables for different runtime environments of your rails app. For example: .env.development and .env.test files with specific values of the environment variables for your development and test environments respectively. This gives you more control of your app's environment variables and do not have to rely on the platform (terminal shell) you want to deploy your app.
config/local_env.yml - This is similar to .env approach, which is provided out of the box by rails gem that allows you to configure environment variables for your app in yml format. This method also keeps your app's configuration within the app irrespective of the shell you are using to run your app.
In addition to the previous answer, another downside of using .bashrc is that it is specific to only one user, so if you're e.g. starting your app server as a systemd service then I believe it won't see your variables.
Meanwhile, .env's Github readme says that it is not the most recommended thing to use outside of the development environment, although it is OK for that purpose.
Another two options to consider are:
Rails secrets. The benefit of this approach is that you get to commit it to git since it's encrypted, so when working in a team you will all have access to the same file. The downside is that it is coupled to the RAILS_ENV variable, so you can't use it to set that e.g. to production on your production app (but you can manually pass it every time it's invoked). Another downside is that if you have a staging environment, then apparently Heroku discourages using RAILS_ENV=staging, which you sometimes really need, so if you need it then you can either do it anyway, or you'll need to set the differing variables via a different mechanism - for example my app has a variable which points to the URL of another part of my app, this URL needs to point to its staging variant on staging, and to its production variant on production, so it needs to differ between my production and staging environment.
Using an /etc/environment file - note that systemd services don't have access to it by default so you'd have to add the line EnvironmentFile=/etc/environment. Also if you're running a shell script from a non-login shell (which happens sometimes), they it won't load them either, but the solution is to just include in your script this: set -a; source /etc/environment; set +a. You should be careful not to commit this to git. If you're working in a team and you need to manage this file then it gets a little complicated since it's not committed to git, but maybe there's a way to have it encrypted. (systemd services note: you might optionally use LoadCredential= for sensitive variables such as private keys, so that other processes won't have access to them; if you do this then you can also commit to git /etc/environment which should now contain non-sensitive variables only).
In my opinion both of those are valid and it's fine to pick whatever is easier to do in your app.
ootb rails has the 3 environments
development
test
production
How do you handle your other environments for example staging ?
When I think about what I want from a staging environment I want most of the production settings, but typically server names and other specific values are different from production.
Do you create 1:N environment/*.rb for each custom environment you have? Or do you treat the environments more as like a profile and then use something like application.yml or secrets.yml for running the application with different server configurations?
What has worked well for you in the past and what has not?
It depends if your "staging" environment is a different thing or is actually a variation on the "production" environment as is usually the case.
Normally you just deploy in full production mode, using the production.rb file and everything, to a non-production server. This distinction is irrelevant to rails, and matters only to your deployment script. For example Capistrano would be concerned about this.
The only time you need another environment is if you need a different group of settings for Rails.
In my opinion, when I run the app in an staging environment I want it to have exactly the same settings as in production, because it's when I check if everything is alright before releasing the new code. So I create a environments/staging.rb that actually is a symbolic link to environments/production.rb. To deploy, I use Capistrano, which lets you define the server settings for every environment you want to. I really encourage you to take a look at it if you don't know it, as it makes deploying as easy as running a simple command, and it takes care of uploading the new code, precompiling the assets, restarting the server, etc.
Appropriate any way described above.
In some cases I am using 1:N way because it easy when you have fixed count of deployment environments (for example when I am deploying own pet-project to remote server).
But in other cases I am using default set of environments (for example when I am deploying project to different customers).
Just choose any way appropriate for you and your project.
I use require_relative to create a staging environment that is identical to production, and then override the parts that are different. Typically the only difference is hostnames.
Here's what my environments/staging.rb looks like:
# Staging configuration is identical to production, with some overrides
# for hostname, etc.
require_relative "./production"
Rails.application.configure do
config.action_mailer.default_url_options = {
:host => "staging.example.com",
:protocol => "https"
}
config.action_mailer.asset_host = "https://staging.example.com"
end
I have started developing a new Rails app on my server using RVM, Rails 3, & Ruby v1.9.2. I am using Git as my code repository. It's a simple app and I don't want to use an extra server. I just want to deploy my app directly from the same server I am developing on.
I've installed Phusion Passenger w/ Apache to serve my app, but have realized that I can't do that pointing to my development directory as my RAILS_ENV is set to "development". (I found I got file permission errors on the asset pipeline and other issues when I attempted to set RAILS_ENV to "production" and serve the app)
What's the simplest/easiest way to deploy the app? Can I simply:
1) Create a separate user to run rails production (Rails in dev currently runs as me on my Ubuntu server)
2) Clone my repo into a separate dir and configure Apache accordingly
3) Seed my database with the data needed for production (not much data needed here)
4) What else?
I've looked briefly at Capistrano, but it seems like overkill for this simple app. I only need to be able to provide a simple web interface for some data entry. Seems like git push should be sufficient, but I haven't done this before so maybe I'm wrong? Also, if I git push how do I ensure file permissions in the "production" directories are all set properly, particularly for any new files that get created in the originating app directory structure?
Thanks for any ideas.
No- you do not need Capistrano for the above; at this stage I feel it will only serve to confuse you further.
I'd suggest you first save your repo to a private Github or free BitBucket account. What you should do is keep one folder for 'development'.
Remember that Passenger is 'just' a module working with Apache. So what you need to do is setup a virtual host under apache and direct that to another folder on your system. For this example, consider:
~/rails/myapp_development/ and ~/rails/myapp_production/
Passenger always runs the app in production, so that should not be an issue. You can do bundle --without=production in your development setup to ignore any gems listed in the Gemfile under the production namespace, i.e. say you've got the mysql adaptor specified, you can ignore this and have Rails only rely on the SQlite gem.
You can now simply develop in the development folder, commit, push to BitBucket. Deploying will be as simply going into the production folder and doing a git pull and touch tmp/restart.txt.
I'm trying to deploy the same rails app to two different locations with different app names, different logos, different stylesheets, etc.
I've got the code working based on an APP_NAME and a HOST_NAME variable I store in environments/production.rb. Now I need to actually deploy it, and I need a better solution than manually editing the environment file on the production machine.
The only way I can see to do it is to create a new production environment - e.g. production_app2 - and define APP_NAME and HOST_NAME differently in them. Is there a better way?
No no no! Don't edit the environment files. I mean, edit them as you need to for things that need to be configured the same for every deployment, but not for things that should be configurable between deployments.
For that, use configuration.
Throw a YAML file in config that looks something like this:
development:
:app_name: App 1
:host_name: something.com
test:
:app_name: App 1
:host_name: something.com
production:
:app_name: App 1
:host_name: something.com
Call it whatever makes sense. Let's say settings.yml.
Now load it with an initializer in config/initializers/settings.rb that looks like this:
SETTINGS = YAML.load_file("#{RAILS_ROOT}/config/settings.yml")[RAILS_ENV]
Now access your configuration like this:
SETTINGS[:app_name]
(If you don't want to change your existing code at all, inside config/initializers/settings.rb add lines that set your existing names like APP_NAME = SETTINGS[:app_name], etc.)
Note that this is one possible implementation of settings configuration, but even if another approach is taken it should be based on deployment-independent configuration. This can be much more easily and maintainably set up to persist between deployments and upgrades than mucking with environment files.
Again, to recap:
environment files are for configuration that is the same across all deployments
configuration files are for configuration that can change between deployments
Update
For Capistrano based deployments, this is what I use to symlink multiple configuration files in the new current from the shared directory (I think it originally came from an Ezra recipe from EngineYard):
after "deploy:update_code","deploy:symlink_configs"
namespace(:deploy) do
task :symlink_configs, :roles => :app, :except => {:no_symlink => true} do
configs = %w{ database settings }
configs.map! { |file| "ln -nfs #{shared_path}/config/#{file}.yml #{release_path}/config/#{file}.yml" }
run <<-CMD
cd #{release_path} && #{configs.join(' && ')}
CMD
end
end
I think that's a pretty good way.
Where we are we define different environments (e.g. 'staging', 'production', 'production_backup' - giving us a staging.rb, production.rb, production_backup.rb where you can define your specific APP_NAMEs and HOST_NAMEs) and can deploy to each of them using Capistrano. It works just fine.
This is a good link on it: http://www.egtheblog.com/?p=8
Because you are actually deploying to two different environments, it seems best to create two different environment files, each with their own settings. Make sure you pick descriptive names for your environment files, not just production2.
You could also store this information in the database, but I don't know if you're willing to accept such a dependency. I guess using a database would only make sense if the number of deployments is too large to manage easily with a few environment files.