I've deployed a ML Model on AWS. It's an image classifier. When I provide the following images to the ML Model via a form in Flask, it works in certain cases but doesn't work in other cases.
The link of the image which work is listed below: https://drive.google.com/file/d/1hbrEa2gNLdqGPJxp5jVxWcXl1wunp5Mc/view?usp=sharing
The link of the image which gives an error is listed below: https://drive.google.com/file/d/1znWTRnTMPft_r_jwpJ0JQuMnnazsUXs-/view?usp=sharing
Both of the above images look alike. The first image which is around 150kb of size works when I select the file and upload it for analysis. The image which is around 10kb however doesn't when I select and upload it for analysis from a PC. When I try to do the same with my mobile phone browser, both show an error.
The error shown in the logs is - [warn]: a client request body is buffered to a temporary file.
I figured out the answer by following this link: Increasing client_max_body_size in Nginx conf on AWS Elastic Beanstalk
The nginx configuration settings should be performed in a folder named .platform.
The folder structure is (.platform/nginx/conf.d/proxy.conf)
Inside the proxy.conf mention:
client_body_buffer_size 50M;(the size according to your requirement).
Inside the .platform folder make another file named 00_myconf.config with the following contents:
container_commands:
01_reload_nginx:
command: "service nginx reload"
AWS documentation regarding configuring nginx: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/platforms-linux-extend.html
(Read the reverse proxy configuration)
Related
So,I am using Django for my backend application deployed on AWS Elastic Beanstalk (EC2 t2.micro, Amazon Linux 2). When I am trying to submit files (.mp4, pdf) that are obviously larger than 1MB, I get Nginx Error 413: Entity too large. The problem is that everything I have tried works for a few hours, before everything is getting reset to the default configurations. As far as I understood there is an auto-scaling functionality that resets everything after each new deploy and sometimes even without deploy.I know that a lot of people had faced this kind of problem, and for some of them actions described in other posts solved the problem. However, for me everything resets either immediately after deploy, or in a couple of hours.
I have already tried, as suggested in other posts on Stackoverflow, changing the nginx file from the EC2 console, adding my own configuration file in source code (.ebextensions folder), applied some changes to my S3 bucket, and many other options.
***NOTE: I have also created a custom function for handling large files in Django itself, but I think it is irrelevant to the Nginx error that I get.
My .ebextensions directory:
--.ebextenstions
--nginx
--conf.d
--proxy.conf
--02_files.config
Content of the proxy.conf:
client_max_body_size 100M;
Content of 02_files.config:
`files:
"/etc/nginx/conf.d/proxy.conf" :
mode: "000755"
owner: root
group: root
content: |
client_max_body_size 100M;`
Thanks.
For Amazon Linux 2 you have to use .platform, not .ebextentions. So create a file, e.g. myconfig.conf (.platform/nginx/conf.d/myconfig.conf) with content of:
client_max_body_size 100M;
I have created a Django API application that is deployed on AWS Beanstalk Amazon Linux 2 (Python 3.8). In a part of my application, the user should be able to upload a file through API.
Nginx, on default, is returning CORS error to the user when the uploaded file is bigger than 3 MB and logging 'user tries to upload huge file' in the Nginx log.
The only solution which works for me is creating the bellow configuration file and reloading the Nginx:
/etc/nginx/conf.d/proxy.conf:
client_max_body_size 50M;
and then:
sudo service nginx reload
I have done this procedure manually by connecting to the EC2 which is the host of my beanstalk application via SSH. I want to automate this procedure to be done at every deployment and every instance.
I have created a file called nginx_max_upload.config file in .ebextensions folder which is located in the root of my project:
nginx_max_upload.config:
files:
/etc/nginx/conf.d/proxy.conf:
mode: "000755"
owner: root
group: root
content: |
client_max_body_size 50M
commands:
reload_nginx:
command: "sudo service nginx reload"
ignoreErrors: true
My problem is, the above code didn't create the file I want in the specified directory. When I changed the directory to another directory like /usr/local/bin/proxy.conf, the file would be successfully created but it can't create the config file in the Nginx configuration folder.
I guess the problem might be from the permissions but I don't know how to grant the needed permission to the deployment agent.
Also, I have tried these two solutions but none of them works:
I have tried to create the config file in another folder and then, move it via mv command to the right directory but it didn't work.
Also, I have tried to put the creation code in the predeply hook and put manual echo commands in my code. I saw all of my echo commands output in the beanstalk logs but it didn't do anything (nor creating the file in the nginx configuration neither moving it from somewhere else to the configuration folder).
Since you are using Amazon Linux 2 (AL2), your configuration files are incorrect. They used to work in AL1, but for AL2, they are in different place and have different format as shown in the docs.
Thus could have the following .platform/nginx/conf.d/myconfig.conf (not in .ebextensions) with content:
client_max_body_size 50M;
I have a .Net core api installed on AWS Beanstalk. I am getting error "client intended to send too large body: 10181136 bytes" on uploading large file. How to increase max request size.
I tried creating ngnix.config file under .ebextensions folder with below configuration
files:
/etc/nginx/conf.d/proxy.conf:
content: |
client_max_body_size 50M;
it didn't work for me.
A likely reason why it does not work for you is that the nginx setting you are trying to use (/etc/nginx/conf.d/proxy.conf) is for the older EB platforms based on Amazon Linux 1 (AL1).
But .NET Core platform is based on Amazon Linux 2 (AL2) as listed here. In this case, you should be using different files for customizing nginx. For AL2, the nginx settings should be in .platform/nginx/conf.d/, not in .ebextentions as shown in the docs.
Therefore, you could try creating the following file .platform/nginx/conf.d/myconfig.conf with content:
client_max_body_size 50M;
I had this working before on AWS Linux AMI but no luck with AWS Linux 2.
I need to access my environment properties from the Nginx configuration file during the EB application deployment. It's a Single instance Node Server.
I did it like this with the AWS Linux AMI and it worked without a problem:
.ebextensions/00_options.config
option_settings:
aws:elasticbeanstalk:application:environment:
DOMAIN: socket.example.com
MASTER_DOMAIN: https://example.com
etc..
.ebextensions/10_proxy.config
... some configs ...
files:
/etc/nginx/conf.d/proxy.conf:
mode: "000644"
owner: root
group: root
content: |
upstream nodejs {
server 127.0.0.1:8081;
keepalive 256;
}
map $http_origin $cors_header {
hostnames;
default "";
`{"Fn::GetOptionSetting": {"Namespace": "aws:elasticbeanstalk:application:environment", "OptionName": "MASTER_DOMAIN"}}` "$http_origin";
}
server {
listen 80;
listen 8080;
server_name `{"Fn::GetOptionSetting": {"Namespace": "aws:elasticbeanstalk:application:environment", "OptionName": "DOMAIN"}}`;
location ~ /.well-known {
allow all;
root /usr/share/nginx/html;
}
location / {
return 301 https://$host$request_uri;
}
}
etc..
.... some more configs ....
I'm not including most of the configs above because they're not relevant.
So when I did this before, everything worked as expected. The config file inserted my properties and created the file in the /etc/nginx/conf.d/proxy.conf folder.
Now with AWS Linux 2 the specs have changed and we have to add our Nginx configuration files in the .platform/nginx/conf.d folder located in our application bundle root folder.
Here the reference ( see Reverse proxy configuration)
So I created a proxy.conf file in the location mentioned above with the content that was previously inserted in /etc/nginx/conf.d/proxy.conf.
.platform/nginx/conf.d/proxy.conf
upstream nodejs {
server 127.0.0.1:8081;
keepalive 256;
}
map $http_origin $cors_header {
hostnames;
default "";
`{"Fn::GetOptionSetting": {"Namespace": "aws:elasticbeanstalk:application:environment", "OptionName": "MASTER_DOMAIN"}}` "$http_origin";
}
etc...
And then the problems began..
This first trial throwed unexpected "{" in /var/proxy/staging/nginx/conf.d/proxy.conf:11 at me.
And after that I tried a lot of things. Tried it with ${MASTER_DOMAIN} and messed around with the new EB AWS Linux 2 hooks (see link above Platform hooks). All for no avail it seems like you can't access the properties from the Nginx configs. I've read an article or a documentation from Nginx mentioning something similar today but I can't find it anymore (did a lot of googling).
I also tried to create a config file like I did with the working version which purpose was to save a temp file somewhere with the included properties and then include this file in the needed .platform/nginx/conf.d/proxy.conf file because I started to think that there is no way to include them directly with the new specs.
.ebextensions/10_proxy.config
... some configs ....
files:
/var/proxy/staging/custom_folder/proxy.conf:
mode: "000644"
owner: root
group: root
content: |
etc...
.platform/nginx/conf.d/proxy.conf
include custom_folder/proxy.conf;
With this idea in mind I did a lot of nonsense, I created hooks for creating (mkdir) directories in which I tried to temporarily save the file which leaded to new permission errors. I wasn't able to give the proper permissions to prebuild, postdeploy files but this is another issue.
And a lot more of trying and failing...
But then I've read (also from the link above):
"If you configure your proxy to send traffic to multiple application processes, you can configure several environment properties, and use their values in both proxy configuration and your application code."
And hope came back.. Does this mean I actually CAN directly add environmental variables into the Nginx configs located in the .platform directory? ... I don't know.. Do you?
I could continue to describe all the things I tried all night long so I will stop here. I hope you get the issue. If not ask me and I will do my best to make all this understandable.
Also my mind isn't very clear anymore after 14 hours of battling this issue. I need a break.
If you did it to the end thank you for your time and help would be greatly appreciated.
Summary
One way to do it is to create a shell script in .platform/hooks/postdeploy.
Here is a simplified example, assuming you have an Elastic Beanstalk environment property called MASTER_DOMAIN:
#!/bin/bash
# write nginx config file
cat > /etc/nginx/conf.d/elasticbeanstalk/test.conf << LIMIT_STRING
location /test/ {
default_type text/html;
return 200 "nginx variable: \$host, and EB env property: $MASTER_DOMAIN";
}
LIMIT_STRING
# restart nginx service so the config takes effect
systemctl restart nginx.service
The location block from this example can be replaced by the nginx content from .ebextensions/10_proxy.config in the original post. No need for the Fn::GetOptionSetting stuff though.
I think you also need a duplicate script in .platform/confighooks/postdeploy.
Details below.
(sorry for the wall of text)
Environment variables in nginx
Actually, as discussed in here and here, it is not possible (out-of-the-box) to use os environment variables inside the http, server, or location blocks in nginx config files. There are some workarounds, such as using lua, perl, or templates, but let's not get into those. This part has nothing to do with AWS.
In the OP's original configuration for Amazon Linux AMI (AL1), using the files section in .ebextensions/10_proxy.config, they were actually using a shell script to write the nginx config file during deployment. The shell script expanded the environment variables, but the resulting proxy.conf for nginx did not actually access any environment variables.
That's why it worked on AL1.
Platform hooks
Now, for Amazon Linux 2 (AL2), we can do something similar using shell scripts in the .platform/hooks and .platform/confighooks folders.
These .platform hook scripts are executed as the root user, and they have access to the Elastic Beanstalk (EB) environment properties. The EB environment properties can be accessed just like normal OS environment variables, so there is no need to use the Fn::GetOptionSetting stuff.
Basically, we need to create a shell script that writes a file with the content from your original .ebextensions/10_proxy.config. However, there are two questions we need to consider:
Should we use a prebuild, predeploy, or postdeploy hook?
What is the proper destination directory for our nginx proxy.conf file?
File locations
To answer these questions, we have to refer to the AWS documentation for Extending Elastic Beanstalk Linux platforms, and specifically the Instance deployment workflow section.
... The current working directory (cwd) for platform hooks is the application's root directory. For prebuild and predeploy files it's the application staging directory, and for postdeploy files it's the current application directory. If one of the files fails (exits with a non-zero exit code), the deployment aborts and fails.
This is interesting, but leaves some questions, e.g. where is the "application staging directory" located? We can fill in the blanks by inspecting one of our deployment log files. Based on our eb-engine.log, here's what happens with the platform hooks and nginx config files during app deployment (skipping a lot of details):
the source bundle is downloaded from S3 and extracted to /var/app/staging/
platform hooks in .platform/hooks/prebuild/ are executed
proxy server configuration is copied from /var/app/staging/.platform/nginx/ to /var/proxy/staging/nginx
platform hooks in .platform/hooks/predeploy/ are executed
proxy server is started, configuration is copied from /var/proxy/staging/nginx/ to /etc/nginx
platform hooks in .platform/hooks/postdeploy/ are executed
Note, after deployment the app is located in /var/app/current.
Based on the above, there are several options:
Create a shell script in .platform/hooks/postdeploy that writes to /etc/nginx/conf.d/proxy.conf.
The nginx service is already running, at this stage, so we need to restart for the configuration to take effect.
Below is a minimal test example. In this example we write to the elasticbeanstalk subdirectory, because we just want to add a location inside the default server block. We can then visit the /test/ page in a browser, to check that the configuration works.
We use some bash io redirection (<<, >) to write the nginx config file.
Note that we need to escape any nginx variables, e.g. $host becomes \$host, otherwise the shell will interpret them as environment variables.
Also note that the shell scripts need to have execution permission, as explained under More about platform hooks in the docs.
#!/bin/bash
cat > /etc/nginx/conf.d/elasticbeanstalk/test.conf << LIMIT_STRING
location /test/ {
default_type text/html
return 200 "nginx variable: \$host, and EB env property: $MASTER_DOMAIN";
}
LIMIT_STRING
systemctl restart nginx.service
Alternatively, we could create a shell script in .platform/hooks/predeploy that writes to /var/proxy/staging/nginx/conf.d/proxy.conf.
There is no need to restart the nginx service in this case, because this hook is executed before the server configuration is applied.
BEWARE:
Not sure if this is a bug or a design feature, but our newly created proxy.conf disappears after a configuration deployment (as opposed to an application deployment), unless we put a duplicate script in the .platform/confighooks/postdeploy directory. Not very DRY...
EDIT: AWS support confirmed that we need duplicate scripts in hooks and confighooks in this case. The application example in the docs also shows some duplicates (at least duplicate filenames) in hooks and confighooks.
EDIT:
Instead of duplicating scripts, we can also write a confighook that calls a hook, e.g. .platform/confighooks/predeploy/01_my_confighook.sh could look like this:
#!/bin/bash
source "/var/app/current/.platform/hooks/predeploy/01_my_hook.sh"
Disclaimer: This was tested on a freshly created single instance EB environment with "Python 3.7 running on 64bit Amazon Linux 2/3.1.5" using all default configuration and the default AWS Python sample application (only extended with our custom hooks).
I'm trying to upload an index.html page to Bluemix using the cf CLI. I'm not sure if I'm approaching this with the right mentality. I'm thinking of uploading this HTML file as we usually do with normal hosting services, through FTP. With Bluemix I assume I should be using the push command in cf and treat this index.html as an app. Is this right?
If this is right, I'm not getting how to use this command. Can you give me an example of full command to push/upload this page?
The cf push command would be the one to use to 'upload' your application to the Bluemix server. However, it does more than just upload. In Bluemix there is a concept of a runtime or buildpack, the idea being this will be the runtime to run your application. So if you uploaded a Java application you would pair it with the Java Liberty Buildpack/runtime. If you uploaded a PHP application then you would pair it with the PHP buildpack.
If you pushed just a HTML file with no buildpack then you would likely get an error indicating the buildpack could not be determined. Bluemix tries to guess the type of buildpack you want based on the type of files uploaded, and then pull the buildpack from an internal cache. The cf push command allows you to explicitly state the buildpack to use -b so there is no guess work and no need to rely on only the buildpack that Bluemix currently knows about.
In your case, for a static HTML file you would need some type of http server like nginx as the 'runtime'. Notice that Bluemix currently does not have a built-in buildpack for this, so you'd have to get it from somewhere else. There are a few buildpacks available already, but the best one to use would be this one: https://github.com/cloudfoundry-community/staticfile-buildpack . To use it simply supply that url with the -b option on the cf push command from the root directory of your application i.e.
cf push yourappname -b https://github.com/cloudfoundry-community/staticfile-buildpack
Be sure you are issuing this command from your app directory.
The yourappname will be part of the URL for your website/app
For an actual example, we will upload your index.html which exist in folder C:\Users\XYZ\Documents\projects\ProjectHelloWorld and we will call this app HelloWorld. Here is what we would do:
C:\> cd C:\Users\XYZ\Documents\projects\ProjectHelloWorld
C:\Users\XYZ\Documents\projects\ProjectHelloWorld> cf push HelloWorld -b https://git
hub.com/cloudfoundry-community/staticfile-buildpack
Bluemix will then upload everything in that local directory to the server and also grab the buildpack from the URL location and stage your application code with the buildpack, Bluemix will then attempt to start the application. This is an example Bluemix output when the push command succeed:
Creating app HelloWorld in org xyz#gmail.com / space test as xyz#gmail.com...
OK
Creating route HelloWorld.mybluemix.net...
OK
Binding HelloWorld.mybluemix.net to HelloWorld...
OK
Uploading HelloWorld...
Uploading app files from: C:\Users\XYZ\Documents\projects\ProjectHelloWorld
Uploading 1M, 21 files
Done uploading
OK
Starting app HelloWorld in org xyz#gmail.com / space test as xyz#gmail.com...
-----> Downloaded app package (960K)
Cloning into '/tmp/buildpacks/staticfile-buildpack'...
grep: Staticfile: No such file or directory
-----> Using root folder
-----> Copying project files into public/
-----> Setting up nginx
grep: Staticfile: No such file or directory
-----> Uploading droplet (3.4M)
1 of 1 instances running
App started
OK
Showing health and status for app HelloWorld in org xyz#gmail.com / space
test as xyz#gmail.com...
OK
requested state: started
instances: 1/1
usage: 1G x 1 instances
urls: HelloWorld.mybluemix.net
last uploaded: Tue Nov 25 14:50:44 +0000 2014
For more details:
See the github page for the buildpack on how to structure your application (public folder etc)
See Bluemix Docs website. It has a lot of demos and examples.
See Takehiko Amano's Bluemix demo. Is a good and easy to understand demo.
you can either deploy your app directly using "cf push ..." or via creating a manifest.yml file.if you create manifest.yml file inside you app code path,only cf push is sufficient.
below is the reference link for this:
http://clouds-with-carl.blogspot.in/2014/02/deploy-minimal-nodejs-application-to.html
Hope it clears your doubt!!
Yeah as whitfiea mentioned its pretty simple. You need to use the cf push command. For example if you had a static website with an index.html file.
For example the following.
[02:30 PM] jsloyer#jeffs-mbp [friendme]>ls
index.html
To push that app to Bluemix run the following.
cf push yourappname -b https://github.com/cloudfoundry-community/staticfile-buildpack.git
https://www.ng.bluemix.net/docs/#starters/index.html
In this browse Creating Web Apps->Building a web app-> Uploading an app
It says;-
You can use a sample Java™ web application to get started. This sample application displays the list of environment variables that are available. You can download the sample Java web application from the community sample site. The sample application contains a single JSP and the WEB-INF/web.xml file.
Extract the downloaded file, and a new directory that contains the application is created. From the newly created application directory, issue the cf push command. In the following example, you can use a unique name testEnv for the application and 512M for memory allocation. The name must be unique in the whole Bluemix environment.
$ cf push testEnv -m 512m
->So as per your requirement, you can add your html file along with the JSP file before uploading the application.
Hopefully this help...