AWS EBS - Rails5 / nginx - ошибка robots.txt не найден (404)

Я развернул довольно стандартное приложение Rails 5 с AWS EBS. Мой /robots.txt недоступен, и запросы на его URL-адрес возвращают ошибку 404.

Я положил его в папку /public вместе со страницами 404.html, 422.html и 500.html, которые правильно обслуживаются nginx.

Есть какие-нибудь подсказки о том, что может быть не так? Что мне проверить?

EB CLI 3.14.6 (Python 2.7.1)

Ruby 2.4.3 / Rails 5.1.4 / Puma (gem) 3.7

есть ли URL-адрес эталонной реализации? Мы будем рады проверить с нашей стороны и помочь вам решить любые проблемы. Без кода или репо мы ничем вам не поможем.

Taterhead 26.10.2018 10:44

Конечно ... я просто не хотел публиковать свое приложение. Это aparcagratis.com

davideghz 26.10.2018 11:29

Вы развертываете через macOS или Linux и cli? Или через консоль?

Taterhead 26.10.2018 17:37

Через cli в macosx, eb deploy делает свое дело

davideghz 26.10.2018 19:26

Хорошо, я попробую сегодня воспроизвести нечто подобное на своем Mac. Если вы можете опубликовать номера версий своего cli, это поможет

Taterhead 26.10.2018 19:42

Привет, это EB CLI 3.14.6 (Python 2.7.1)

davideghz 29.10.2018 10:08

какая версия Ruby / Rails / Puma?

Taterhead 29.10.2018 10:12

Ruby 2.4.3 / Rails 5.1.4 / Puma (гем) 3.7

davideghz 30.10.2018 12:17

Привет, @Taterhead, тебе повезло?

davideghz 13.11.2018 22:46

Извините, мое свободное время затянулось событиями. Я воодушевлен возможностью того, что новый специалист из AWS поможет, особенно с обходным путем 2. Быстрый гугл нашел эту статью: medium.com/@marilu597/… - Если у меня будет время, я попробую еще раз написать и ее. Это не должно быть слишком сложно.

Taterhead 14.11.2018 13:07
Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
3
10
453
3

Ответы 3

Похоже, очень похожий вопрос задавали 4 года назад на официальном форуме AWS: https://forums.aws.amazon.com/thread.jspa?threadID=150904

Спустя всего 4 года смелый парень из AWS пришел с ответом! Ниже цитируемый ответ:

Hello hello! I'm Chris, the new Ruby platforms person at Elastic Beanstalk. Visiting this thread today, it looks like there's been a lot of pain (and also confusion!) from Beanstalk's Ruby+Puma's handling of static files.

Quick summary: When this thread was created (in 2014), Beanstalk was essentially using the default Nginx that comes with Amazon Linux, with only some logging modifications to support the health monitoring. That spawned this thread, as static files are generally expected to be served the the web server when one is present.

So, the folks here went and fixed the /assets folder. Great! Unfortunately, there was a misunderstanding with the request to fix serving the /public folder - Beanstalk's Puma platform instead serves things in '/public' from '/pubilc', not from '/'. This is definitely an issue, so here's some workarounds:

Workaround 1: Turning on serve static assets. Yes, this wastes some application threads here or there, but if your use case is only robots.txt and favicon.ico, you're only robbing a couple of appserver threads. I'd pick this one unless I was running my application servers hot.

Workaround 2: Write an .ebextension to modify the Nginx configuration to serve /public at /. I'm in the process of writing one, so I'll tack it as a reply to this when I've given it the thought it deserves. Some of the current ones may serve your app's code, so double check the configuration if you've already done this workaround.

I've created a tracking issue for the team with this level of detail, so we'll work to get this corrected. Thank you all for your feedback - we'd love to serve you and your apps better.

С тех пор никаких дальнейших ответов; Если кто-нибудь знает "одобренный AWS способ" для редактирования конфигурации nginx с помощью .ebextensions, давайте разместим его здесь, пожалуйста! :)

В AWS EB с PUMA статические файлы в общей папке обслуживаются по адресу / public / url. Веб-сканеры ожидают, что файл будет доступен по адресу /robots.txt.

Я изо всех сил пытался реализовать маршрутизацию к этим файлам и вместо этого остановился на более «Rails» способе реализации этого.

1) config / routes.rb

get "/robots.txt", to: "robots#show"

2) приложение / контроллеры / robots_controller.rb

class RobotsController < ApplicationController
  def show
    render "show", layout: false, content_type: "text/plain"
  end 
end

3) приложение / просмотры / robots_txts / show.erb

User-agent: *
Disallow: /

В приведенной выше ссылке на форумы AWS сейчас ошибка 400, поэтому вот как я исправил эту проблему. Ruby 2.7, работающий на платформе AWS2:

Статические файлы в подкаталоге /public:

В папке .ebextensions создайте файл с именем static-files.conf. Контент должен выглядеть примерно так:

option_settings:
  aws:elasticbeanstalk:environment:proxy:staticfiles:
    /w3c: public/w3c
    /images: public/images

Это гарантирует, что все запросы к domain.com/images и domain.com/w3c обслуживаются из соответствующего подкаталога /public.

Статические файлы на верхнем уровне каталога /public: Для файлов верхнего уровня, таких как robots.txt или sitemap.xml, добавьте соответствующую запись в routes.rb для непосредственного обслуживания статического содержимого:

  get '/robots.txt', to: proc {|env| [200, {}, [File.open(Rails.root.join('public', 'robots.txt')).read]] }
  get '/sitemap.xml', to: proc {|env| [200, {}, [File.open(Rails.root.join('public', 'sitemap.xml')).read]] }

Убедитесь, что на production.rb правильно настроена конфигурация статических файлов:

config.serve_static_files = false

Эта последняя часть наиболее важна.

Другие вопросы по теме