Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-26

1 В этом уроке рассмотрим конфигурацию приложений на Ruby on Rails. Мы рассмотрим, как управлять окружениями в Rails, что позволит адаптировать поведение приложения в зависимости от его использования, будь то разработка, тестирование или продакшн. Также мы обсудим использование инициалайзеров для настройки параметров приложения, способы хранения конфиденциальной информации, а также познакомимся с инструментами, такими как Spring и Puma, которые помогут оптимизировать процесс разработки и развертывания. Начнем с работы с окружениями в Rails, чтобы понять, как правильно настраивать приложение для различных сценариев использования.

2 <h2>Окружения</h2>

3 В Ruby on Rails по умолчанию создаются три основных окружения:development,testиproduction. Каждое из этих окружений предназначено для выполнения различных задач в процессе разработки и развертывания приложения.

4 <h3>Development</h3>

5 Окружение для разработки, в котором пишем код и разрабатываем приложение. Здесь включены инструменты для отладки, изменения применяются на лету, что позволяет быстро видеть результаты работы. Например, при возникновении исключений отображаются подробные сообщения об ошибках с указанием стека вызовов.

6 Доступны различные инструменты и библиотеки, такие как pry или byebug, которые помогают выполнять отладку. В development-окружении можно запускать интерактивные консоли (rails console), что позволяет выполнять команды и тестировать код в реальном времени.

7 Изменения в коде автоматически применяются без необходимости перезапуска сервера. Это позволяет быстро видеть результаты своих изменений.

8 Уровень логирования в development-окружении настроен наdebug, что позволяет записывать все действия приложения, включая запросы, ответы и внутренние операции. Это помогает анализировать поведение приложения и выявлять проблемы.

9 Кэширование обычно отключено или настроено на минимальный уровень. Это позволяет видеть актуальные изменения в приложении без задержек, связанных с кэшированием.

10 <h3>Test</h3>

11 Окружениеtestв Ruby on Rails предназначено для автоматизированного тестирования приложения.

12 Тесты запускаются в изолированном окружении, что позволяет избежать влияния одного теста на другой. Это достигается за счет использования отдельной базы данных для тестов, которая обычно создается и очищается перед каждым запуском тестов. Тесты могут быть запущены автоматически с помощью различных инструментов, таких как RSpec или Minitest.

13 В test-окружении кэширование обычно отключено, чтобы гарантировать, что тесты всегда работают с актуальными данными и кодом. Это позволяет избежать неожиданных результатов из-за кэшированных данных.

14 Уровень логирования в test-окружении может быть настроен на более низкий уровень (например, warn или error), чтобы минимизировать объем записываемых логов и сосредоточиться на важных сообщениях об ошибках.

15 Для создания тестовых данных в test-окружении часто используются фикстуры или библиотеки для создания тестовых данных. Это позволяет разработчикам легко генерировать необходимые данные для тестов.

16 После выполнения тестов выводится отчет о результатах, который показывает, какие тесты прошли успешно, а какие провалились.

17 Test-окружение часто интегрируется с системами непрерывной интеграции и развертывания (CI/CD), что позволяет автоматически запускать тесты при каждом изменении кода.

18 <h3>Production</h3>

19 Это окружение, в котором приложение развернуто для конечных пользователей. Здесь важна стабильность и производительность, поэтому настройки могут отличаться от других окружений. В production-окружении используются оптимизированные настройки, которые обеспечивают максимальную производительность приложения. Например, включается кэширование, отключаются отладочные инструменты и используется более быстрый веб-сервер.

20 Уровень логирования в production обычно настроен на более высокий уровень (например, error или warn), чтобы минимизировать объем записываемых логов и сосредоточиться на критических ошибках. В отличие от development-окружения, где логируются все действия, в production важно избегать избыточной информации.

21 В production-окружении применяются более строгие меры безопасности. Например, используется HTTPS для защиты данных пользователей.

22 Используется отдельная база данных, которая отличается от баз данных вdevelopmentиtest. Это позволяет избежать случайного изменения или удаления данных пользователей.

23 В production-окружении отладка ограничена. Разработчики не должны иметь доступ к отладочным инструментам, чтобы избежать потенциальных уязвимостей. Вместо этого используются инструменты мониторинга и алерты для отслеживания состояния приложения.

24 <h3>Создание своего окружения</h3>

25 Rails управляет окружениями с помощью файлов, расположенных в директорииconfig/environments. Каждый файл содержит настройки, специфичные для соответствующего окружения. Например, в файлеconfig/environments/development.rbможно настроить параметры логирования, кэширования и другие аспекты, которые будут применяться только в режиме разработки.

26 Если нам необходимо создать новое окружение, например,staging, нам нужно выполнить несколько шагов:

27 <ol><li>Создадим новый файл в директорииconfig/environments, назвав егоstaging.rbи добавим туда конфиг:

28 Строка require_relative "development" загружает настройки из файлаdevelopment.rbи находится в директорииdevelopment.rb. Это означает, что все настройки, определенные в окружении разработки, будут унаследованы в окружении staging. Таким образом, можем использовать уже существующие настройки и переопределять только те, которые нужны для staging.

29 Rails.application.configure do блок кода используется для настройки параметров приложения. Внутри этого блока мы можем изменять конфигурацию Rails, добавляя или переопределяя параметры.

30 config.assume_ssl = false устанавливает значение параметра assume_ssl в false. Приложение не будет предполагать, что соединение является безопасным (SSL). В контексте staging-окружения это может быть полезно, если вы не используется HTTPS для тестирования или если мы хотим проверить функциональность приложения в условиях, когда SSL не активен.

31 </li>

32 <li>Обновим настройки подключения к базе данных, добавив соответствующий блок в файлdatabase.yml:

33 Ключ staging: это название окружения, для которого настраиваются параметры базы данных. <<: *default эта строка использует YAML-синтаксис для наследования настроек из блока, который был определен ранее в файле как default. Звездочка (*) указывает на то, что мы хотим использовать все настройки, определенные в блоке default. Это позволяет избежать дублирования кода и упрощает управление конфигурацией, так как все общие настройки можно определить в одном месте. database: db/staging.sqlite3 Эта строка указывает, что база данных для окружения staging будет находиться в файлеdb/staging.sqlite3. Это означает, что при работе в окружении staging приложение будет использовать SQLite базу данных, хранящуюся в этом файле.

34 </li>

35 <li>Запустим сервер в нужном окружении:

36 </li>

37 </ol>Также мы можем запустить консоль в нужном окружении, установив глобальную переменную окружения:

38 Мы можем получить информацию о том, в каком окружении запущено приложение с помощью метода Rails.env. К примеру мы можем проверить, запущено ли приложение в production-среде и если да, то выполним первую ветку условия:

39 Теперь, когда мы разобрались с созданием и настройкой окружений, перейдем к следующему аспекту конфигурации приложений в Ruby on Rails - инициалайзерам.

40 <h2>Инициалайзеры</h2>

41 Инициалайзеры в Ruby on Rails - это специальные файлы, которые загружаются при старте приложения и позволяют выполнять код для настройки различных компонентов и библиотек. Они находятся в директорииconfig/initializersи имеют расширение.rb. Каждый файл в этой директории выполняется в алфавитном порядке, что позволяет организовать и структурировать настройки.

42 В инициалайзерах Ruby on Rails можно размещать различные настройки и конфигурации, которые будут выполняться при старте приложения. Пример настройки<a>devise</a>в<a>hexlet-cv</a>:

43 В инициалайзерах можно определять глобальные константы, которые будут использоваться в приложении. Это может быть полезно для хранения настроек, таких как типы занятости, уровни должностей и другие параметры.

44 Пример инициализатора констант, из проекта<a>hexlet-cv</a>:

45 Если приложение взаимодействует с внешними API, мы можем настроить параметры, такие как базовые URL, таймауты и заголовки.

46 В инициализаторах могут быть объявлены и другие настройки, такие как логирование, кэширование, регистрация классов и модулей.

47 <h2>Хранение конфиденциальной информации</h2>

48 В Ruby on Rails работа с секретами и конфиденциальной информацией, такой как API-ключи, пароли и другие чувствительные данные, осуществляется с помощью нескольких подходов. Вот основные из них:

49 <h3>credentials.yml.enc</h3>

50 Файлcredentials.yml.encзашифрован и позволяет хранить конфиденциальные данные. Командой rails credentials:edit откроется файл в редакторе по умолчанию, где вы мы можем добавлять ключи и значения в формате YAML. Пример содержимого:

51 Также мы можем открыть файл в определенном редакторе:

52 Использовать секреты в коде мы можем, обратившись к Rails.application.credentials:

53 Файлcredentials.yml.encшифруется с помощью файла-ключаconfig/master.key. Этот файл надо надежно хранить и не выкладывать в открытый доступ.

54 <h3>Переменные окружения</h3>

55 Другой распространенный способ хранения секретов - использование переменных окружения. Это позволяет избежать хранения конфиденциальной информации в коде.

56 Для разработки можно использовать гем<a>dotenv-rails</a>. Он позволяет описать переменные окружения внутри файла.envи загрузить их оттуда.

57 Файл.envобычно не хранят внутри репозитория, и его копируют из файла-шаблона. Пример файла из<a>hexlet-cv</a>:

58 EMAIL_FROM=local@local.local GITHUB_APP_SECRET=1cbaa8d7eaa9897204615ae07383791bf3c6113d GITHUB_APP_ID=4bf7b244da515541298a RECAPTCHA_SITE_KEY=1111key2222 RECAPTCHA_SECRET_KEY='$eCr3T' HOST=localhost OPENAI_ACCESS_TOKEN=1235fff12345 PASSWORD_SPECIAL_USER= EMAIL_SPECIAL_USER=special@test.io # test key for recapcha https://github.com/MTG/freesound/issues/879 RECAPTCHA_SITE_KEY=6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI RECAPTCHA_SECRET_KEY=6LeIxAcTAAAAAGG-vFI1TnRWxMZNFuojJ4WifJWe HABR_ACCESS_TOKEN=111222zzz N8N_ACCESS_TOKEN=111xvxv

59 Файл содержит примеры значений и пустые переменные, которые нужно заполнить самостоятельно после копирования файла из шаблона. Необходимые переменные будут храниться в специальном хеше ENV:

60 <h2>Spring</h2>

61 Spring - это инструмент для предварительной загрузки приложений на Ruby on Rails, который значительно ускоряет процесс разработки, позволяя избежать повторной инициализации приложения при каждом запуске команд, таких как тесты, миграции и другие задачи.

62 Spring предварительно загружает ваше приложение в фоновом режиме, так что когда мы запускаем тесты, миграции или другие задачи Rake, вам не нужно ждать загрузки приложения. Spring делает эти команды намного более быстрыми для выполнения.

63 Поскольку Rails призывает нас загружать все гемы при запуске (помещая Bundler.require вconfig/application.rb), со временем время загрузки Rails-приложения может стать значительным. Это особенно заметно во время модульного тестирования, поскольку мы хотим получать обратную связь как можно скорее, и не ждать слишком долго загрузки приложения. Поэтому Spring сокращает время запуском команды rails test и просмотром запущенных тестов.

64 По умолчанию Spring выключен. Его необходимо добавить вGemfileи выполнить bundle install:

65 Чтобы Spring мог управлять приложением, создадим бинарные файлы:

66 Добавление и удаление Spring из бинарных файлов:

67 Команда bundle exec spring binstub --all добавила в бинарные файлы команд запуск Spring. Пример изbin/rails:

68 Строка load File.expand_path("spring", __dir__) загружает Spring, что позволяет ему управлять процессом инициализации приложения. Spring будет следить за изменениями в коде и перезапускать приложение при необходимости.

69 <h2>Логирование</h2>

70 Логирование помогает отслеживать работу приложения, выявлять ошибки и анализировать производительность. Rails предоставляет встроенные механизмы для логирования, которые можно настраивать и расширять в зависимости от потребностей.

71 Пример логирования в проекте<a>Code Basics</a>:

72 Rails поддерживает несколько уровней логирования, которые позволяют фильтровать сообщения по важности. В примере выше пишется сообщение уровня error. В Rails доступны следующие уровни логирования:

73 <ul><li>debug: Подробная информация, полезная для отладки.</li>

74 <li>info: Общая информация о работе приложения.</li>

75 <li>warn: Предупреждения о потенциальных проблемах.</li>

76 <li>error: Сообщения об ошибках, которые произошли в приложении.</li>

77 <li>fatal: Критические ошибки, которые могут привести к сбою приложения.</li>

78 <li>unknown: Неизвестный уровень.</li>

79 </ul>Для каждого уровня используются свои методы, предоставляемые Rails. Например:

80 По умолчанию Rails создает лог-файлы в директорииlog/по имени окружения:

81 <ul><li>development.log: Логи для среды разработки.</li>

82 <li>test.log: Логи для тестовой среды.</li>

83 <li>production.log: Логи для производственной среды.</li>

84 </ul>Уровень логирования Rails по умолчанию - debug. Для production-среды в сгенерированном по умолчанию файлеconfig/environments/production.rbуказывается info. Этот уровень можно изменить в конфиге окружения изменив config.log_level:

85 <h2>Puma</h2>

86 Puma - это высокопроизводительный веб-сервер для Ruby, который часто используется с приложениями на Ruby on Rails. Он поддерживает многопоточность и многопроцессорность, что позволяет эффективно обрабатывать множество запросов одновременно.

87 Puma используется по умолчанию в Rails. Его настройка может быть выполнена через файл конфигурацииconfig/puma.rb. Пример файла из hexlet-cv:

88 Файл config/puma.rb в приложении Ruby on Rails позволяет настраивать различные параметры веб-сервера Puma, который используется для обработки HTTP-запросов:

89 <ul><li>Количество потоков. Минимальное и максимальное количество потоков, которые Puma будет использовать для обработки запросов. Это позволяет серверу обрабатывать несколько запросов одновременно, что может улучшить производительность приложения.

90 </li>

91 <li>Порт. Порт, на котором Puma будет слушать входящие запросы. Это позволяет изменять порт без необходимости изменения кода.

92 </li>

93 <li>Среда выполнения. Мы можем установить среду, в которой будет работать Puma (например, development, production, staging и т.д.). Это позволяет вам адаптировать поведение сервера в зависимости от среды.

94 </li>

95 <li>Рабочие процессы (workers). Мы можем настроить количество воркеров, которые Puma будет использовать для обработки запросов. Это позволяет серверу обрабатывать большее количество запросов одновременно, особенно в средах с высокой нагрузкой.

96 </li>

97 </ul>Возможности конфигурации этого веб-сервера значительно шире, чем мы рассмотрели. Puma предлагает множество параметров, которые позволяют адаптировать его под специфические требования приложения.

98 Для более глубокого понимания всех доступных опций и их применения, стоит обратиться к официальной документации Puma. Там можно найти исчерпывающую информацию о всех возможностях настройки.

99 <h2>Заключение</h2>

100 Мы узнали, как правильно работать с окружениями, что позволяет адаптировать приложение к различным условиям, а также рассмотрели использование инициалайзеров для настройки параметров. Мы обсудили важность хранения конфиденциальной информации и познакомились с инструментами, такими как Spring и Puma, которые помогают оптимизировать процесс разработки и развертывания.