Zwiększenie client_max_body_size w Nginx conf na AWS Elastic Beanstalk

Biegnę do „413 Zbyt duże żądanie” błędów podczas wysyłania plików większych niż 10 MB do naszego API działa na AWS Elastic Beanstalk.

Zrobiłem sporo badań i uważam, że muszę zwiększyć client_max_body_size dla Nginx, jednak nie mogę znaleźć żadnej dokumentacji, jak to zrobić za pomocą Elastic Beanstalk. Domyślam się, że należy go zmodyfikować za pomocą pliku ebetension.

Czy ktoś myśli o tym, jak mogę podnieść limit? 10 MB jest dość słabe, musi być sposób na ręczne zwiększenie tego.

Możesz skorzystać z dwóch metod. Niestety niektóre działają z niektórymi typami aplikacji EB, a niektóre z innymi.

Obsługiwane / zalecane w dokumentacji AWS

W przypadku niektórych typów aplikacji, takich jak Java SE , Go , Node.js i może Ruby (nie jest to udokumentowane dla Ruby, ale wszystkie inne platformy Nginx wydają się to obsługiwać), Elasticbeanstalk ma wbudowaną wiedzę o tym, jak skonfigurować Nginx.

Aby rozszerzyć domyślną konfigurację Nginx.ebextensions/nginx/conf.d/ Elastic Beanstalk, dodaj pliki konfiguracyjne .conf do folderu o nazwie w pakiecie źródłowym aplikacji . Konfiguracja nginx Elastic Beanstalk automatycznie dołącza pliki .conf do tego folderu.

~/workspace/my-app/
|-- .ebextensions
|   `-- nginx
|       `-- conf.d
|           `-- myconf.conf
`-- web.jar

Konfiguracja Reverse Proxy - Java SE

Aby szczególnie zwiększyć maksymalny rozmiar przesyłanych plików, utwórz plik, .ebextensions/nginx/conf.d/proxy.confustawiając maksymalny rozmiar treści na dowolny preferowany rozmiar:

client_max_body_size 50M;

Utwórz bezpośrednio plik konfiguracyjny Nginx

Po wielu badaniach i godzinach pracy ze wspaniałym zespołem wsparcia AWS, utworzyłem plik konfiguracyjny wewnątrz programu, .ebextensionsaby uzupełnić konfigurację nginx. Ta zmiana pozwoliła na większy rozmiar ciała posta.

Wewnątrz .ebextensionskatalogu utworzyłem plik o nazwie 01_files.configo następującej zawartości:

files:
    "/etc/nginx/conf.d/proxy.conf" :
        mode: "000755"
        owner: root
        group: root
        content: |
           client_max_body_size 20M;

Spowoduje to wygenerowanie pliku proxy.conf w katalogu /etc/nginx/conf.d. Plik proxy.conf zawiera po prostu jedną linijkę, client_max_body_size 20M;która załatwia sprawę .

Należy pamiętać, że w przypadku niektórych platform ten plik zostanie utworzony podczas wdrażania, a następnie usunięty w późniejszej fazie wdrażania.

Możesz określić inne dyrektywy, które są opisane w dokumentacji Nginx.

http://wiki.nginx.org/Configuration

Mam nadzieję, że to pomoże innym!

files:
    "/etc/nginx/conf.d/proxy.conf" :
        mode: "000755"
        owner: root
        group: root
        content: |
           client_max_body_size 20M;

Zmodyfikowałem powyższą odpowiedź ze względu na bezpieczeństwo (a składnia była zła, widzicie, dwa wpisy „właściciel:” w YAML), chłopaki, proszę nie ustawiajcie 777 uprawnień na NIC. Chyba że lubisz być zhakowany i ustaw właściciela plików konfiguracyjnych Nginx na roota.

Zobacz również poniższą odpowiedź, aby nginx odebrać tę zmianę po wdrożeniu.

EDYCJA: Po wdrożeniu kompilacji z instrukcjami zawartymi w zaakceptowanej odpowiedzi Nicka Parsonsa, może być konieczne ponowne uruchomienie serwera nginx, aby pobrać zmiany.

Aby to zrobić, ssh do instancji i wykonaj

sudo service nginx reload

Więcej informacji na temat ponownego ładowania można znaleźć pod adresem http://nginx.org/en/docs/beginners_guide.html .

W poprzedniej wersji Elastic Beanstalk mogłem dodać container_command, aby to osiągnąć, ale teraz stwierdzam, jak @cdmckay, że powoduje to niepowodzenie wdrażania. Jeśli przebudujesz swoje środowisko, pobierze ono ustawienia client_max_body_size, a także tak długo, jak ta instrukcja będzie w twoim pliku konfiguracyjnym.

Zaakceptowana odpowiedź nie zadziałała dla mnie, ponieważ mam aplikację opartą na JVM i wydaje się, że konfiguracja NGINX jest inna. Widziałbym plik proxy.conf tworzony podczas wdrażania, ale później usuwany przed zakończeniem wdrażania. Dokumentacja AWS wyjaśnia, jak skonfigurować proxy :

Utwórz .ebextensions/nginx/conf.d/proxy.confplik zawierający tylko linię:client_max_body_size 40M;

Kontynuując zaakceptowaną odpowiedź, może być konieczne ponowne załadowanie pliku konfiguracyjnego nginx.

Aby to zrobić, dodaj następujące polecenie

   container_commands:
      01_reload_nginx:
        command: "service nginx reload"

To byłaby lepsza praktyka niż wejście do instancji eb przez ssh i robienie tego ręcznie za pomocą polecenia.

To w połączeniu z zaakceptowaną odpowiedzią rozwiązało ten sam problem. (Szyny, Puma, NGINX)

Wypróbowałem wszystkie .ebextensionsmetody dodawania konfiguracji na poziomie implementacji i nie pomogło mi to w najnowszym Amazon Linux AMI. Zrobiłem wiele badań i po przejrzeniu dzienników mogę znaleźć program uruchamiający zadania wdrażania, który szuka folderu o nazwie .platformza każdym razem i pomyślałem o dodaniu go, podobnie jak .ebextensions. Poniżej znajdują się ustawienia, które zrobiłem w folderze głównym mojego projektu.

Dodaj poniższą konfigurację folderu na poziomie głównym folderu projektu.

Struktura folderów (.platform / nginx / conf.d / proxy.conf)

.platform/
         nginx/
              conf.d/
                    proxy.conf
         00_myconf.config

Zawartość pliku 1 - proxy.conf ( .platform/nginx/conf.d/folder wewnętrzny )

client_max_body_size 50M;

Zawartość pliku 2 - 00_myconf.config ( .platform/folder wewnętrzny )

container_commands:
  01_reload_nginx:
    command: "service nginx reload"

Uważaj na rozszerzenia. Pierwszy plik to .conf, a drugi to .config .

Teraz prześlij swój projekt do Amazon Elastic Beanstalk, a zobaczysz magię. Ta konfiguracja zostanie dodana do wszystkich instancji EC2, utworzonych w ramach automatycznego skalowania.

Szczegółowa struktura folderów poniżej.

Jedyną rzeczą, która zadziałała, było utworzenie pliku „.config” wewnątrz .ebextensions w następujący sposób:

.ebextensions/
           proxy.config

tylko z tą zawartością w pliku .config:

files:
  "/etc/nginx/conf.d/proxy.conf":
     content: |
       client_max_body_size 50M;

nie ma potrzeby tworzenia podfolderów, nie ma potrzeby restartowania serwera aplikacji, zwróć uwagę, że plik ".config" a nie ".conf" wewnątrz .ebextensions i zastosowanie odpowiedniego wcięcia, aby uniknąć błędów w konsoli aws reszta jest taka sama nie ma znaczenia nazwa pliku,

dzięki: http://kroltech.com/2014/09/14/quick-tip-increase-upload-size-in-aws-elastic-beanstalk-node-js-env/

Zaakceptowana odpowiedź nie zadziałała dla mnie, więc zamiast tego zastąpiłem konfigurację nginx własną.

Utworzyłem plik o nazwie nginx.confw katalogu.ebextensions/nginx/

Skorzystałem z działającej instancji mojej aplikacji Beanstalk i skopiowałem zawartość nginx.confpliku, używając cat /etc/nginx/nginx.confi kopiując z terminala.

Wkleiłem zawartość do nginx.confpliku, który wcześniej utworzyłem .ebextensions/nginx/, i zmodyfikowałem dyrektywę http, aby uwzględnić client_max_body_size 50M;. W końcu ponownie wdrożyłem moją aplikację przy użyciu eb deployi zadziałało. Podczas wdrażania powinien pojawić się następujący komunikat:

INFO: Konfiguracja Nginx wykryta w katalogu „.ebextensions / nginx”. AWS Elastic Beanstalk nie będzie już zarządzać konfiguracją Nginx dla tego środowiska.

Oto zawartość mojego .ebextensions/nginx/nginx.confpliku:

# Elastic Beanstalk Nginx Configuration File

user                    nginx;
error_log               /var/log/nginx/error.log warn;
pid                     /var/run/nginx.pid;
worker_processes        auto;
worker_rlimit_nofile    33193;

events {
    worker_connections  1024;
}

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    include       conf.d/*.conf;

    map $http_upgrade $connection_upgrade {
        default     "upgrade";
    }

    server {
        listen        80 default_server;
        access_log    /var/log/nginx/access.log main;

        client_header_timeout 60;
        client_body_timeout   60;
        keepalive_timeout     60;
        gzip                  off;
        gzip_comp_level       4;
        gzip_types text/plain text/css application/json application/javascript application/x-javascript text/xml application/xml application/xml+rss text/javascript;

        # Include the Elastic Beanstalk generated locations
        include conf.d/elasticbeanstalk/*.conf;
    }

    client_max_body_size 50M;
}

Nie musiałem ponownie uruchamiać usługi nginx ani środowiska.

Uwaga : upewnij się, że rozszerzenie .ebextensions jest częścią pliku .zip utworzonego i przesłanego do Beanstalk podczas wdrażania (nie jest ignorowane w programie .gitignorelub .ebignorejeśli go używasz).

To jest rozwiązanie dostarczone przez AWS i działa (dostosuj rozmiar do swoich potrzeb)

files:
  "/opt/elasticbeanstalk/hooks/appdeploy/enact/12_add_nginx_configuration.sh":
    mode: "000755"
    owner: root
    group: root
    content: |
      #!/usr/bin/env bash
      /bin/echo "client_max_body_size 50M;" > /etc/nginx/conf.d/proxy.conf
      /sbin/service nginx reload

Alternatywnie możesz zmienić serwer proxy na Apache. Aby to zrobić, przejdź do Konfiguracja i Edytuj konfigurację oprogramowania. Pierwsza opcja to „Serwer proxy”, wybierz „apache”.

W przypadku Golanga bez Dockera postępowałem zgodnie z instrukcjami z dokumentu aws:

Konfiguracja Reverse Proxy

Jeśli chcesz dołączyć dyrektywy oprócz tych z bloku http nginx.conf, możesz również dostarczyć dodatkowe pliki konfiguracyjne w .ebextensions/nginx/conf.d/katalogu pakietu źródłowego. Wszystkie pliki w tym katalogu muszą mieć rozszerzenie .conf. http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/go-environment.html#go-complex-apps

Utworzyłem plik proxy.confw .ebextensions/nginx/conf.d/katalogu głównym mojego projektu, mając po prostu jedną linię w środku:

client_max_body_size 20M;

Jeśli nadal nie działa, upewnij się, że .ebextensionsfolder i podfoldery są uwzględnione w pliku ZIP wdrożenia. Nie ma potrzeby ręcznego ponownego uruchamiania Nginx.

Zmagałem się z tym samym problemem, ale nie byłem w stanie go rozwiązać, w końcu zadziałało.

tutaj jest mój plik konfiguracyjny,

files:
  "/etc/nginx/conf.d/01_proxy.conf":
    mode: "000755"
    owner: root
    group: root
    content: |
      client_max_body_size 50M;
      client_body_buffer_size 16k;

container_commands:
  01_reload_nginx:
    command: "sudo service nginx reload"

Problem polegał na

Używałem skryptu w Pythonie dla potoku kodu, który nie zawiera folderu .ebextensions podczas tworzenia kompilacji.

Oto moje kilka centów,

1. upewnij się, że twój folder .ebextensions znajduje się w folderze zip twojej kompilacji, który znajduje się w s3bucket twojego konta aws
2. upewnij się, że nie ma go w pliku .gitignore
3. jeśli używasz skryptu do generowania kompilacji, upewnij się, że zawiera on rozszerzenie .ebextensions

Po 3 długich dniach próbowania tego rozwiązania, zadzwoniłem do niesamowitego zespołu wsparcia AWS i dali mi kilka wskazówek, jak to rozwiązać. Po pierwsze, mój projekt jest w JAVA i używam Maven i Spring Boot, aby uruchomić go przez Elastic Beanstalk (EBS).

1. Jak wyjaśniono w dokumentacji AWS , musisz mieć niestandardowe ustawienia nginx przechowywane na poziomie głównym projektu. W tym celu utworzyłem plik client_max_body_size.conf i umieściłem go w następującej ścieżce: myprojectname /src/main/resources/ebextensions/nginx/conf.d/client_max_body_size.conf Ten plik zawiera tylko następującą linię:

   client_max_body_size 10M;
   

2. Skonfiguruj maven, aby dodać ten plik do folderu głównego mojego projektu podczas kompilacji. To było trochę trudne, musiałem dodać następującą konfigurację ( źródło ) w moim POM.xml:

   <plugin>
   <artifactId>maven-resources-plugin</artifactId>
   <version>3.1.0</version>
   <executions>
       <execution>
           <id>copy-resources</id>
           <!-- here the phase you need -->
           <phase>validate</phase>
           <goals>
               <goal>copy-resources</goal>
           </goals>
           <configuration>
               <outputDirectory>${basedir}/target/.ebextensions</outputDirectory>
               <resources>
                   <resource>
                       <directory>src/main/resources/ebextensions</directory>
                       <filtering>true</filtering>
                   </resource>
               </resources>
           </configuration>
       </execution>
   </executions>
   

3. Możesz już teraz skompilować projekt lokalnie i uruchomić następujące polecenie SSH, aby sprawdzić, czy faktycznie znajduje się w katalogu głównym projektu:

   jar tf main-1.0-SNAPSHOT.jar | grep .ebextensions
   

4. Teraz to trudna część. Po przesłaniu go do EBS plik powinien zawierać tylko plik SNAPSHOT.jar i folder .ebextensions. Na przykład, jeśli teraz spakujesz plik jar i folder i prześlesz go ręcznie, zadziała!

5. Ponieważ używam Jenkinsa do mojego wdrożenia, a konkretnie wtyczki AWS EBS Deployment - musisz zmienić ustawienia plików / folderów, które dołączasz do wdrożenia. Teraz z jakiegoś powodu nie mogłem dołączyć folderu .ebextensions, więc po prostu wykluczyłem wszystko inne oprócz folderu i pliku .jar.

To działa!

Oprócz client_max_body_size musiałem dodać client_body_buffer_size . Oto plik konfiguracyjny kropki, który działał, dla załącznika 2 MB:

pliki: "/etc/nginx/conf.d/proxy.conf":
tryb: "000755"
właściciel:
grupa główna:
zawartość root : |
proxy_buffering włączone;
proxy_buffer_size 128k;
proxy_buffers 8 256k;
client_body_buffer_size 2M;
proxy_busy_buffers_size 256k;
fastcgi_buffers 16 16k;
fastcgi_buffer_size 32k;
client_max_body_size 3M;

Dla platformy Java

Aby utworzyć plik proxy konfiguracji NGINX, wystarczy dodać

.ebextension/nginx/conf.d/proxy.conf plik

z zawartością client_max_body_size 20M;.

Plik „proxy.conf” zostanie wdrożony w „/etc/nginx/conf.d/proxy.conf” i automatycznie dołączony do konfiguracji NGINX.

Jeśli używasz EC2 i samodzielnie zainstalowałeś nginx, najlepszym rozwiązaniem jest utworzenie nowego pliku w formacie

/etc/nginx/conf.d

teczka:

sudo nano /etc/nginx/conf.d/proxy.conf

a następnie dodaj tam następujący wiersz:

client_max_body_size 20M;

następnie zapisz i uruchom ponownie nginx:

sudo systemctl restart nginx