I have deployed my Rails app on AWS Elasticbeanstalk and the app allows the user
to upload videos so in my nginx.conf file which is in etc/nginx directory in EC2
Instance I have to add a line in server part to avoid the error "Nginx: 413 Request Entity Too Large Error":
client_max_body_size 999M;
and then service nginx reload
But after uploading 10-15 videos this file gets reset and then I have to again add
this line and the IP of EC2 Instance also changes,
Can someone Please help me fix this issue.
It sounds like your instance is being terminated and rebuilt. Can you check the "Events" page for your environment and see if that's happening? That should be the only reason the filesystem is reset and the IP address is changing. I suspect an auto-scaling rule is being triggered.
As to why the file is being reset, have you ever noticed the following warning that gets displayed every time you connect via eb ssh:
This EC2 instance is managed by AWS Elastic Beanstalk. Changes made via
SSH WILL BE LOST if the instance is replaced by auto-scaling.
At least with the Ruby+Passenger platform, EB generates the nginx configuration files from templates that are found at /opt/elasticbeanstalk/support/conf - you should see files called nginx_config.erb and nginx_config_healthd.erb.
You can use EB extensions (described in the documentation) to modify those files during a deploy, which will ensure that your changes persist through auto-scaling. Your extension might look something like this:
.ebextensions/01-edit-nginx-conf.config
container_commands:
01backup_nginx_config:
command: "cp -n /opt/elasticbeanstalk/support/conf/nginx_config.erb /opt/elasticbeanstalk/support/conf/nginx_config.erb.original"
02edit_nginx_config:
command: "sh -c \"sed '/passenger_ruby/ i \
\ client_max_body_size 999M;' /opt/elasticbeanstalk/support/conf/nginx_config.erb.original > /opt/elasticbeanstalk/support/conf/nginx_config.erb\""
Related
I am having a very difficult time trying to launch a sample Rails 6 application to Elastic Beanstalk. For context, I am following these instructions
ADD RDS to Ruby Application
ADD an RDS to Beanstalk
I have followed these instructions to a tee and am still unable to connect to the rds database that I have provisioned. I keep receiving the following error:
PG::ConnectionBad: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
Whenever I try to run RAILS_ENV=production rails db:migrate or any other rake task, I keep getting that error.
On my AWS console, under Configuration and Software, I have the following environment variables:
Also in my database.yml file I have the rds configured variables listed as such.
production:
adapter: postgresql
database: <%= ENV['RDS_DB_NAME'] %>
username: <%= ENV['RDS_USERNAME'] %>
password: <%= ENV['RDS_PASSWORD'] %>
host: <%= ENV['RDS_HOSTNAME'] %>
port: <%= ENV['RDS_PORT'] %>
I have mapped my values as instructed in the documentation and am certain that they are correct.
Finally, I have sshed into my beanstalk provisioned ec2 instance and have executed the following command:
psql -U username -p 5432 -h examplehost.rds.amazonaws.com -d ebdb
provided the password and am able to connect. I am really at my wits end, I've spent too much time trying to diagnose this and am running out of ideas. I don't know where to look too next for ideas on how to trouble shoot this. I've read so many stack overflow questions and blogs that my head is spinning. If anyone has any ideas on how to resolve this, I would greatly appreciate it.
---Update----
I have created a new environment variable on the elastic beanstalk console.
ENV['DATABASE_URL'] = postgres://YourUserName:YourPassword#YourHostname:5432/YourDatabaseName
I made the necessary configurations, uploaded my .zip file and the connection to the database failed.
---- UPDATE-----
printenv does not show the varialbes provided by beanstalk, however this command does sudo /opt/elasticbeanstalk/bin/get-config environment.
My first advice is that, in my opinion, it is a much better option to create an Amazon RDS on their own, and not tied to Beanstalk.
As the AWS documentation indicates (emphasis mine):
AWS Elastic Beanstalk provides support for running Amazon Relational Database Service (Amazon RDS) instances in your Elastic Beanstalk environment. To learn about that, see Adding a database to your Elastic Beanstalk environment. This works great for development and testing environments. However, it isn't ideal for a production environment because it ties the lifecycle of the database instance to the lifecycle of your application's environment.
And:
To decouple your database instance from your environment, you can run a database instance in Amazon RDS and configure your application to connect to it on launch. This enables you to connect multiple environments to a database, terminate an environment without affecting the database, and perform seamless updates with blue-green deployments.
In my opinion, even for testing or development, it is always advisable to configure a small database instance and give your application the ability of define the most appropriate mechanism for connecting to your database.
The only downside is that you will probably need to configure a VPC, although it should not be actually a problem and, in ay case, it is worth value.
If for any reason you need to use the Beanstalk provisioned RDS database perhaps you have some workarounds to your problem (it should be a workaround because your configuration looks fine - please, only, verify that the database configuration is defined for the right Beanstalk environment).
For instance, one thing you can try is to store the database connection configuration in a S3 bucket, as also suggested in the AWS documentation. The idea is basically create some configuration file with the necessary connectivity information, store it in S3, and read that configuration in your application, i.e., process that file, in order to initialize your database.
But maybe you can try another approach.
Please, consider this SO question, and the answer from Jon McAuliffe and others. As indicated, Beanstalk will provide your application with environment variables, but maybe this variables will not be exposed as shell variables, they will be exposed to your application in different ways depending on the runtime the application needs to be executed on.
In the case of Ruby, you are accessing these variables in the correct way but, for any reason, your program is not having access to that information.
This probably also explains why printenv does not print any if your variables but the get-config script does.
But maybe you can take advantage of the fact that get-config provides you the right information and, either define this variables in your ENV by executing the get-config script for every RDS* key, perhaps in your environment.rb - please, be aware that I programmed in Ruby when I was a student but there is a long time since that, do the task in the file you consider appropriate - or using .ebextensions and a custom configuration file. You can find several examples here.
For instance, consider the following (copy and paste, with minor modifications of this example configuration):
commands:
01_update_env:
command: "/tmp/update_environment_variables.sh"
files:
"/tmp/update_environment_variables.sh":
mode: "000755"
content : |
#!/bin/bash
RDS_HOSTNAME=$(/opt/elasticbeanstalk/bin/get-config environment -k RDS_HOSTNAME)
if [ -z "$RDS_HOSTNAME" ]; then
echo "Could not determine RDS hostname"
exit 1
fi
echo "RDS hostname $RDS_HOSTNAME..."
# Just export the variable at OS level, or make it visible to
# the rails env in some other way
export RDS_HOSTNAME=$RDS_HOSTNAME
# Process the rest of the variables...
# Probably we should create a list and iterate through it
A similar approach could be the one exposed in this stackoverrun question, but restricted to the container that Beanstalk will use to encapsulate your app. AFAIK, the container should receive as env variables the different RDS* ones corresponding to the database configuration.
Dan, be aware that I have not tested these solutions, they are only ideas: please, be careful with that, I do not want to cause any damage to your system.
I found an answer for this problem with a mysql server that might still help you. Basically, even though I followed all your steps, could see my envars using sudo /opt/elasticbeanstalk/bin/get-config environment and could connect directly to my database with the mysql command, I was still getting the following error:
Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2) (Mysql2::Error::ConnectionError)
The solution turned out to be the fact that Elastic Beanstalk was not connecting my envars to my bundle exec rails console command in the eb ssh instance access. I solved the issue by prepending all of the required envars explicitly to any rails commands I ran from within the eb ssh instance access. So for example, in order to run rails console, I had to run the following:
RAILS_MASTER_KEY=xxxxxxx RAILS_ENV=production RDS_HOSTNAME=xxxxxxx RDS_PASSWORD=xxxxxxx RDS_USERNAME=xxxxxxx RDS_DB_NAME=xxxxxxx AWS_REGION=xxxxxxx AWS_BUCKET=xxxxxxx bundle exec rails c
Replace the xxxxxxxs above with the values from the corresponding variables in your EB > Configuration > Software tab, and you should be able to connect to the remote database and run migrations, rake tasks and other database-reliant functions.
For Linux2 instances I was having the same issue and just noticed that the env variables I set in the config just didn't exist for su that I had set myself to -- if I remain the default login after eb ssh env prints everything I expected
edit: sorry -- env printing of variables on linux 2 instance enabled by
https://aws.amazon.com/premiumsupport/knowledge-center/elastic-beanstalk-env-variables-shell/
so what I did was find where those env variables were being exported for default user shell, which was /etc/profile.d/sh.local as noted in the above aws knowledge center link and just source that file when I needed to start the rails console as su
I have a ruby on rails app running on elastic beanstalk and I wanted to upload some large files - possibly around 5gb.
To do this, I added a config file on .ebextensios/nginx/01_upload_file_size.config with the following content:
files:
"/etc/nginx/conf.d/proxy.conf" :
mode: "000755"
owner: root
group: root
content: |
client_max_body_size 20G;
After I deploy the code to EB, I restart the nginx server using the command sudo service nginx reload. This seem to work for a while.
Uploading large files the next day gives me 'Connection is reset' error. The log file log/nginx/error.logs tells me error client intended to send too large body: 24084848 bytes
I have no idea why this occurs. Seems like the config file is ignored after a short term or maybe reset but I can't see any reference of this happening in the documentation. Note that when I SSH into the eb environment again and restart nginx again, I can upload large files without a problem.
After looking after everything, I saw these events on my EB console.
Added instance [i-076127f714faac566] to your environment.
Removed instance [i-0c51791325b54873c] from your environment.
I also notice that the IP address of the host changes when the config resets.
I think that when the instances were automatically added and removed from EB, it didn't apply the config file or didn't restart the nginx server like I did manually via SSH.
So the question is: How do I make sure that the client_max_body_type is always set to 20G, even after instance is removed and re added? Or, how to make the config persistent so I don't have to manually restart the nginx server?
I think you have two questions here - why is EB replacing your instance, and how can you automate the restart of nginx.
Answering the first question will take a bit of research on your part, but I suspect it may be the default CloudWatch alarm that kills instances when network traffic drops below a certain threshold.
The second question should be fairly straightforward; following the documentation, you should be able to add a section to 01_upload_file_size.config that automatically restarts nginx during the deployment process:
container_commands:
01_restart_nginx:
command: "service nginx reload"
I would also check to make sure that the /etc/nginx/conf.d/proxy.conf file is actually being created - I don't know if folders under .ebextensions are supported. You might need to move your config file to .ebextensions/01_upload_file_size.config.
This is my first site I've were I've tried to use Dokku to deploy a rails app on Digital Ocean.
This is a default Dokku install on a basic Ubuntu VM hosted on Digital Ocean
When I try to run:
dokku domains:add myapp mydomain.com
I get the following error
=====> unsupported vhost config found. disabling vhost support
=====> config:set-norestart is deprecated as of v0.3.22
-----> Setting config vars
NO_VHOST: 1
-----> VHOST support disabled, deleting four-heroes/VHOST
-----> Added mydomain.com to myapp
The last line looks like it may have worked despite the errors. However, when I run:
dokku domains myapp
I get this message.
=====> unsupported vhost config found. disabling vhost support
=====> config:set-norestart is deprecated as of v0.3.22
-----> Setting config vars
NO_VHOST: 1
=====> myapp Domain Names
cat: /home/dokku/myapp/VHOST: No such file or directory
Aside from the Postgresql plugin this is a default Dokku install. The application works well and Im able to access it at the the ip.ad.dr.ess:port combination, and I'm able to SSH to the domain(ssh root#mydomain.com).
I can't figure out where I messed up here.
Any help is appriciated.
If you didn't fill in the HOSTNAME option on initial setup of dokku you'll run into your current problem. The VHOST file has yet to be created causing the current error.
To remedy this we have to create the missing VHOST file and populate with your domain name. First SSH into your droplet and run the following (Depending on your permissions you may require sudo to create and edit the VHOST file)
cd /home/dokku
touch VHOST
chmod 0755 VHOST
# Use your editor of choice nano, vim etc.
# to add your hostname to VHOST file, eg. mydomain.com
Now for each app we're going to need to trigger a rebuild of the nginx.conf file. To do this run dokku nginx:build-config myapp for each app.
Note: Deleting the app's dir from /home/dokku/myapp and redeploying will also have the same effect but will require you to re-link other containers e.g. db plugins.
If everything has gone smoothly running dokku domains myapp should now ouput in your terminal
=====> myapp Domain Names
myapp.mydomain.com
You now should be able to remove and add domains for your app successfully using the dokku domains commands
See this answer also for reference
I managed to get a rails app running throw Elastic Beanstalk using the EB CLI and instructions outlined here: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/command-reference-get-started.html
I then set up a second application going through the "eb init" process a second time and using a different application name. How do I now switch between the two applications using the command line before doing "git aws.push"? Can I switch between them while keeping both applications live?
Bonus question: If I have two different AWS accounts and I have the access key/secret for both accounts, how do I switch between applications on different AWS accounts? I assume the same process of "switching accounts" is the same process you'd go through if you were to say set up git and eb on a second development computer and try to link up the second computer's local git repo with the live eb instance. Is this correct?
When you run eb init, it creates a folder in your current directory called .elasticbeanstalk. In it there will be a config file which will have all of the info that you need for your current environment/application. It also has a value called AwsCredentialFile which points to a file that contains your Access Key ID as well as Secret Key.
Therefore if you want to switch between applications, you can just have multiple directories where you have ran eb init in each one and change the files accordingly.
When you configure an elastic beanstalk application using the cli, a file called config.yml is generated inside the .elasticbeanstalk directory. This file basically contains all the info about your elastic beanstalk application.
To change the application your project is linked to you can simply change the value of the application_name in config.yml.
Run eb status to verify if the application switch was successful.
I don't want multiple directories, and I don't want to modify application_name in the .elasticbeanstalk/config.yml file, so I just do this:
eb init --interactive
Of course I have to answer the questions again, but that only takes a few seconds.
eb use
usage: eb use [environment_name] [options ...]
I have a simple setup with a load-balanced application and want to run some commands for cron setups (for instance, using the whenever gem). However, none of my commands seem to get run on the remote server.
# .elasticbeanstalk/Production.config
container_commands:
20_update_crontab:
command: whenever --update-crontab app
leader_only: true
Even tried:
# .elasticbeanstalk/Production.config
commands:
update_crontab:
command: whenever --update-crontab app
Is there something I am missing? These should run with git aws.push correct?
When I check the logs, I don't really get any information saying it was trying to run:
$ eb logs | grep whenever
Using whenever (0.9.2)
The descriptions on this page are pretty good, just can't figure out why it isn't running.
http://www.infoq.com/news/2012/11/elastic-beanstalk-config-files
Elastic Beanstalk configuration files should be placed in .ebextenstions/. It looks like yours are in .elasticbeanstalk/
http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/customize-containers.html
Create a configuration file with the extension .config (e.g., myapp.config) and place it in an .ebextensions top-level directory of your source bundle.
I had a similar problem where I was trying to install libjpeg for my EC2 instance using the configuration files and it was never installed. I tried everything and was never able to find a "good solution", but I did solve it though.
Solution:
How to solve it? Set up a completely new Elastic Beanstalk Application and deploy the same app again. After I did this it worked from the start with the new EB App.
Check out my other answer here: https://stackoverflow.com/a/23109410/2335675
Check it out, hope it helps for you.