Лог: что это, зачем нужен и где его найти?

Тестируем публикацию приложения и читаем лог

Облако Heroku каждый раз собирает приложение из исходников с помощью Maven и выполняет полученный jar в своём окружении. Для запуска приложений в контейнерах Heroku используется команда mvn install.

Чтобы понять, что происходит в облаке, и научиться делать настройки более осознанно, попробуем отправить наше тестовое приложение в Heroku и развернуть. Для этого выполним следующие шаги:

• Откроем папку с репозиторием проекта в терминале Git Bash.
• Найдём ссылку на удалённый репозиторий heroku для вашего приложения в Settings — в разделе App Information → Heroku git URL.
• Добавим новый удалённый репозиторий к вашему Git.

Далее запустим команду git push heroku — в репозиторий heroku будет выполнена попытка сборки и публикации вашего приложения.

  На скриншоте видно, что попытка развернуть приложение проходит с использованием JDK 1.8. Если у вас есть конструкции из JDK 11, этот параметр надо обязательно установить, а не использовать по умолчанию.

Я отметил цветом, что используется Maven 3.6.2, который собирает проект командой install, пропуская при этом тесты. Но проект не соберётся, если не был настроен Maven, и мы увидим такое окончание запуска:

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

Приступим!

Как выложить сайт на Heroku?

1. Открыть терминал (Mac, Linux) или командную строку (Windows) и выполнить команды:

   • — переходим в директорию с нашим фласк-проектом,
   • — логинимся в наш аккаунт Heroku,
   • ввести свой емейл и пароль, с которыми мы зарегистрировались,
   • — создаем приложение, которое поможет Heroku получить наш код и запустить его. В этот момент Heroku делает сразу несколько вещей.

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

   Во-вторых, к вашему репозиторию добавляется удаленный репозиторий (git remote), который называется . У одного локального репозитория на вашем компьютере может быть несколько удаленных (например, у вас может быть — это ваш удаленный репозиторий на GitHub, и — удаленный репозиторий на Heroku.)

   • — эта команда отправляет наш код на облачный хостринг, и Heroku устанавливает нужные модули.

   • — эта команда говорит запустить наш фласк-сайт на одном dyno.

     То есть ваш сайт или бот будет работать на маленьком виртуальном Линукс-«сервере». Бесплатно вам доступно 550 или 1000 таких dyno.

   • — эта команда открывает ваш сайт в браузере. Ура! Все готово!

   • Если по какой-то причине сайт не заработал, то нужно посмотреть логи:

     • — эта команда распечатает 100 последних строчек логов, т.е. если произошла какая-то ошибка, то информацию об этой ошибке вы увидите в конце логов.
     • или — эта команда показывает логи в реальном времени, т.е. если ваша программа что-то печатает в консоль с помощью или питон печатает сообщение об ошибке, то вы будете в реальном времени видеть, что именно происходит.

Когда вы меняете что-то в вашей программе\директории, то изменения нужно отправить на Heroku:

Procfile

Прокфайл определяет команды, которые выполняют приложения в контейнерах , объявляет типы процессов. Каждый дино-контейнер относится к одному из объявленных типов процессов и выполняет команду, связанную с этим типом процесса.

Procfile — это простой текстовый файл, который называется точно Procfile (например, Procfile.txt не действует).

Прокфайл должен находиться в корневом каталоге приложения. Он не работает, если находится в ином месте.

Procfile объявляет типы процессов в отдельных строках файла, каждая из которых имеет следующий формат: <тип процесса>: <команда>. Каждая новая декларация процесса начинается с новой строки.

Тип процесса web является особым: это единственный тип процесса, который может получать внешний HTTP-трафик с маршрутизаторов Хероку. Если проект включает веб-сервер, необходимо объявить процесс как web .

tail -F. Если файл был переименован или удален

Обычно в Linux лог-файлы записываются не до бесконечности, иначе такой файл было бы очень неудобно в дальнейшем использовать. Вместо этого применяется так называемая ротация файлов. Когда лог-файл становится большим, то он либо удаляется, либо переименовывается (создается резервная копия файла), а дальнейшие сообщения начинают записываться в новый, пустой файл.

У команды tail есть две опции: -f и -F

• Если используется опция -f и происходит переименование, отслеживаемого файла, то команда tail продолжает отслеживать уже переименованный файл. Команда tail в данном случае привязывается к идентификатору (inode) файла.
• Если используется опция -F и происходит переименование, отслеживаемого файла, то команда tail определит это, и как только будет создан новый лог-файл (с тем именем, которое мы указали команде tail), команда tail начнет отслеживать этот новый файл.

Рассмотрим пример.

Будем отслеживать лог-файл /var/log/apache2/error.log. Выполняем команду tail с опцией -F

Если система переместит (переименует) файл error.log в файл error.log.1 и создаст новый файл error.log, то наша команда tail продолжит отслеживать уже новый файл error.log

Если бы мы в этом примере использовали опцию -f, то команда tail продолжила бы отслеживать файл error.log.1, который для нас уже неактуален при просмотре логов в реальном времени.

Приоритет сообщений в лог-файлах

Сообщения в лог-файлах создаются в зависимости от типа событий

В свою очередь, событие имеет определенную степень важности. В зависимости от этой важности событию присваивается определенный приоритет:

   emerg — наивысший приоритет, что-то сломалось, повод паниковать;

   alert — тревога, стоит волноваться;

   crit — критическое событие, стоит насторожиться;

   err — ошибка;

   warning — предупреждение;

   notice — уведомление, можно не заморачиваться;

   info — информационное сообщение, принять к сведению и забыть;

   debug — отладочная информация.

Применяя вышеописанные значения приоритетов, можно просматривать сообщения лог-файлов, фильтруя их по заданному приоритету:

Или же для journalctl:

Фильтрация в просмотре событий

Предположим у вас в журнале Безопасность более миллиона событий, наверняка вы сразу зададите вопрос есть ли фильтрация, так как просматривать все из них это мазохизм. В просмотре событий это предусмотрели, логи windows можно удобно отсеять оставив только нужное. Справа в области Действия есть кнопка Фильтр текущего журнала.

Вас попросят указать уровень событий:

• Критическое
• Ошибка
• Предупреждение
• Сведения
• Подробности

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

Так что как видите разобрать логи windows очень просто, ищем, находим, решаем. Так же может быть полезным быстрая очистка логов windows:

• Как почистить все журналы windows с помощью скрипта

Data setup

create creds

hit healthcheck

create a channel

post a log msg

create a log session

fetch logs for session

Supervision Tree

logplex_app	logplex_sup
		(redo)
			logplex_http_drain
			logplex_tcpsyslog_drain
			logplex_tlssyslog_drain
			redo
		(logplex_worker_sup)	logplex_redis_writer
			redo
			tcp_proxy_sup	tcp_proxy

Processes

nsync

An nsync process connected to the logplex config redis. Callback module is nsync_callback.

Nsync is an Erlang redis replication client. It allows the logplex node to act as a redis slave and sync the logplex config redis data into memory.

logplex_realtime

Captures realtime metrics about the running logplex node. This metrics are exported using folsom_cowboy and are available for consumption via HTTP.

Memory Usage information is available:

> curl -s http://localhost:5565/_memory | jq '.'
{
  "total": 27555464,
  "processes": 10818248,
  "processes_used": 10818136,
  "system": 16737216,
  "atom": 388601,
  "atom_used": 371948,
  "binary": 789144,
  "code": 9968116,
  "ets": 789128
}

As is general VM statistics:

> curl -s http://localhost:5565/_statistics | jq '.'
{
  "context_switches": 40237,
  "garbage_collection": {
    "number_of_gcs": 7676,
    "words_reclaimed": 20085443
  },
  "io": {
    "input": 9683207,
    "output": 2427112
  },
  "reductions": {
    "total_reductions": 6584440,
    "reductions_since_last_call": 6584440
  },
  "run_queue": 0,
  "runtime": {
    "total_run_time": 1140,
    "time_since_last_call": 1140
  },
  "wall_clock": {
    "total_wall_clock_time": 207960,
    "wall_clock_time_since_last_call": 207748
  }
}

Several custom logplex metrics are also exported via a special endpoint:

> curl -s http://localhost:5565/_metrics | jq '.'

These can then be queried individually:

> curl -s http://localhost:5565/_metrics/message.received | jq '.'
{
  "type": "gauge",
  "value": 1396
}

logplex_api

Blocks waiting for nsync to finish replicating data into memory before starting a mochiweb acceptor that handles API requests for managing channels/tokens/drains/sessions.

logplex_logs_rest

Starts a process and serves as the callback for processing HTTP log input.

Realtime Metrics

Logplex can send realtime metrics to Redis via pubsub and to a drain channel as
logs. The following metrics are currently logged in this fashion:

To log these metrics to an internal drain channel, you’ll need to set the
environment variable to a drain token that has
already been created.

Авторизуемся в сервисе Heroku с помощью клиентского приложения

Теперь самое время авторизоваться на heroku.com через консольную утилиту. Наберите в терминале:

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

Когда откроется браузер, потребуется ввести логин и пароль. А если вы уже были авторизованы в heroku.com, то останется только подтвердить действие и нажать Log in.

Затем можно просто вернуться в терминал — вы увидите, что успешно залогинились в консольном приложении.

Чтобы проверить, кто сейчас авторизован в системе, используйте команду:

Да, всё в порядке, и ответ системы это подтверждает.

Логи сервера с ошибками error.log

Это журнал с информацией об ошибках на сайте. В нем можно посмотреть, какие страницы отсутствуют, откуда пришел пользователь с конкретным запросом, имеются ли «битые» ссылки, другие недочеты, включая те, которые не удалось классифицировать. Используется для выявления багов и погрешностей в коде.

Каждая ошибка в логе сервера error.log отображается с новой строки. Идентифицировав и устранив ее, программист сможет наладить работу сайта. Используя журнал, можно выявить и слабые места веб-платформы. Это простой и удобный инструмент анализа, которым должен уметь пользоваться каждый веб-мастер, системный администратор и программист.

Step 3 — Python Application Logging

Everything that is written to the stdout is maintained with Heroku as an application log. Heroku is language independent, but the application logs are generated in the application-specific language. Each language offers some logging framework, which you can use. We will discuss some of them, but there are plenty of others. When choosing the logging framework, keep in mind that Heroku maintains logs from various sources. Your logging framework should be able to label log record with application identification (process ID, machine name) and timestamp. Also, the logging framework should maintain log verbosity (the severity levels such as into, debug, error are a matter of course).

There are many popular web server frameworks for python such as Flask, Gunicorn, or Django. Each of them offers its own logging utility. However, python offers native logging functionality and all these frameworks just extend it. As a result, all most popular python web servers offer similar logging functionality. We will demonstrate logging for the Flask (a lightweight Python web framework). You can use a simple logger for the routing in the Flask:

The generates log records with well-known priorities (debug, info, error, and others). The logger labels each log record with the timestamp and process ID. The executing of method will generate the following log records (the method will be executed every time some user will request for the endpoint ):

As you can see, the logger formats the log message into the usual plain text format. You can set up a log verbosity level with the CLI option when starting the server. You can run the previous python script with parameter and the script will generate only log records with severity warning and higher.

If you want to use a dedicated logging framework then python offers, for example, Loguru.

Какие есть виды логов?

На практике видов логов может быть несколько. Рассмотрим каждый из них. 

• Логи системы — это логи, связанные с системными событиями.
• Логи сервера — логи, отвечающие за обращения к серверу и за возникшие ошибки.
• Логи баз данных — специальные логи, которые имеют отношение к запросам баз данным и возникших ошибках.
• Логи почты отвечают за отправленные и принятые письма, ошибки и причины по которым письма не были доставлены.
• Логи cron (планировщика задач).
• Логи панели управления хостингом, где размещен сайт.
• Лог основного файла, например, фаервола, днс сервера и др. 

В независимости от вида лога, это очень ценная информация о работе вашего сервера или компьютера, любого установленного ПО, которая показывает хронологию событий, ошибок и причин, по которым они произошли. По сути, лог — это первоисточник, с помощью которого можно найти и исправить ряд проблем. 

Типы логов и где их найти

Месторасположение логов зависит от используемого ПО, настроек, прописанного админом пути. Чаще всего server logs сохраняются в var/log/. Однако, не все сервисы помещают файлы регистрации в эту директорию. В любом случае, можно уточнить такую информацию у веб-хостера.
У дистрибутивов Linux CentOS или Fedora логи серверной машины лежат в /var/log/. Там можно найти:

• файл регистрации ошибок error.log;
• данные о доступах log;
• основной системный журнал syslog;
• файл загрузки ОС dmesg;
• журнал nginx.

Лог ошибок MySQL ($hostname.err) хранится в /var/lib/mysql/. Для Debian или Ubuntu местоположение логов аналогично, за исключением log file ошибок MySQL: /mysql/error.log. А также – логи веб сервера Apache сохраняются по пути /var/log/apache2.
У ОС Windows дружной метод структурирования log-файлов. События делятся на несколько уровней:

• предупреждение – Warning;
• подробности (System и EventData);
• ошибка – Error;
• сведения – Information;
• критический – Critical.

Их можно отсортировать или отфильтровать и выбрать необходимое.
Запуск и отключение логов осуществляется с административной панели. Как правило, доступ через раздел «журнал» или «логи». При этом стоит учитывать, что файлы не сохраняются годами. Поэтому, при необходимости посмотреть log, это нужно сделать своевременно.

Types of Logs

Runtime Logs

Heroku aggregates the following categories of logs for a deployed app:

• App logs — Logging output from the application itself. This includes logs generated by your app’s code and dependencies. (Filter: )
• System logs — Messages about actions taken by the Heroku platform infrastructure on behalf of your app, such as: restarting a crashed process, sleeping or waking a web dyno, or serving an error page due to a problem in your app. (Filter: )
• API logs — Messages about administrative actions taken by you and other developers working on your app, such as: deploying new code, scaling the process formation, or toggling maintenance mode. (Filter: )
• Add-on logs — Messages from add-on services. See the add-on’s Dev Center article for details. (Filter varies by add-on)

Build Logs

The logs that are generated while building and deploying your app are separate from the app’s runtime logs. Logs for both successful and unsuccessful builds are available from your app’s tab in the Heroku Dashboard:

Click for any build event in the Activity Feed to see its logs:

Расположение логов по умолчанию

Большинство файлов логов Linux находятся в папке /var/log/ вы можете список файлов логов для вашей системы с помощью команды ls:

Ниже мы рассмотрим 20 различных файлов логов Linux, размещенных в каталоге /var/log/. Некоторые из этих логов встречаются только в определенных дистрибутивах, например, dpkg.log встречается только в системах, основанных на Debian.

• /var/log/messages — содержит глобальные системные логи Linux, в том числе те, которые регистрируются при запуске системы. В этот лог записываются несколько типов сообщений: это почта, cron, различные сервисы, ядро, аутентификация и другие.
• /var/log/dmesg — содержит сообщения, полученные от ядра. Регистрирует много сообщений еще на этапе загрузки, в них отображается информация об аппаратных устройствах, которые инициализируются в процессе загрузки. Можно сказать это еще один лог системы Linux. Количество сообщений в логе ограничено, и когда файл будет переполнен, с каждым новым сообщением старые будут перезаписаны. Вы также можете посмотреть сообщения из этого лога с помощью команды dmseg.
• /var/log/auth.log — содержит информацию об авторизации пользователей в системе, включая пользовательские логины и механизмы аутентификации, которые были использованы.
• /var/log/boot.log — Содержит информацию, которая регистрируется при загрузке системы.
• /var/log/daemon.log — Включает сообщения от различных фоновых демонов
• /var/log/kern.log — Тоже содержит сообщения от ядра, полезны при устранении ошибок пользовательских модулей, встроенных в ядро.
• /var/log/lastlog — Отображает информацию о последней сессии всех пользователей. Это нетекстовый файл, для его просмотра необходимо использовать команду lastlog.
• /var/log/maillog /var/log/mail.log — журналы сервера электронной почты, запущенного в системе.
• /var/log/user.log — Информация из всех журналов на уровне пользователей.
• /var/log/Xorg.x.log — Лог сообщений Х сервера.
• /var/log/alternatives.log — Информация о работе программы update-alternatives. Это символические ссылки на команды или библиотеки по умолчанию.
• /var/log/btmp — лог файл Linux содержит информацию о неудачных попытках входа. Для просмотра файла удобно использовать команду last -f /var/log/btmp
• /var/log/cups — Все сообщения, связанные с печатью и принтерами.
• /var/log/anaconda.log — все сообщения, зарегистрированные при установке сохраняются в этом файле
• /var/log/yum.log — регистрирует всю информацию об установке пакетов с помощью Yum.
• /var/log/cron — Всякий раз когда демон Cron запускает выполнения программы, он записывает отчет и сообщения самой программы в этом файле.
• /var/log/secure — содержит информацию, относящуюся к аутентификации и авторизации. Например, SSHd регистрирует здесь все, в том числе неудачные попытки входа в систему.
• /var/log/wtmp или /var/log/utmp — системные логи Linux, содержат журнал входов пользователей в систему. С помощью команды wtmp вы можете узнать кто и когда вошел в систему.
• /var/log/faillog — лог системы linux, содержит неудачные попытки входа в систему. Используйте команду faillog, чтобы отобразить содержимое этого файла.
• /var/log/mysqld.log — файлы логов Linux от сервера баз данных MySQL.
• /var/log/httpd/ или /var/log/apache2 — лог файлы linux11 веб-сервера Apache. Логи доступа находятся в файле access_log, а ошибок в error_log
• /var/log/lighttpd/ — логи linux веб-сервера lighttpd
• /var/log/conman/ — файлы логов клиента ConMan,
• /var/log/mail/ — в этом каталоге содержатся дополнительные логи почтового сервера
• /var/log/prelink/ — Программа Prelink связывает библиотеки и исполняемые файлы, чтобы ускорить процесс их загрузки. /var/log/prelink/prelink.log содержит информацию о .so файлах, которые были изменены программой.
• /var/log/audit/- Содержит информацию, созданную демоном аудита auditd.
• /var/log/setroubleshoot/ — SE Linux использует демон setroubleshootd (SE Trouble Shoot Daemon) для уведомления о проблемах с безопасностью. В этом журнале находятся сообщения этой программы.
• /var/log/samba/ — содержит информацию и журналы файлового сервера Samba, который используется для подключения к общим папкам Windows.
• /var/log/sa/ — Содержит .cap файлы, собранные пакетом Sysstat.
• /var/log/sssd/ — Используется системным демоном безопасности, который управляет удаленным доступом к каталогам и механизмами аутентификации.

systemd и journald

systemd — это подсистема инициализации и управления службами в Linux, фактически вытеснившая в 2010-е годы традиционную подсистему init. В связке с ней работает и journald — демон сбора логов, являющийся частью systemd. Он собирает логи со всей системы и хранит их в бинарном виде в каталоге var/log/journal. Для того чтобы их просмотреть, создана специальная утилита journalctl. Рассмотрим несколько примеров её применения.

Чтобы просмотреть последние 10 строк логов всех запусков системы, достаточно выполнить следующую команду:

Видите столбец, который я обвел красным? Цифрой в нем обозначена текущая загрузка системы, цифрой — предыдущая и т.д. Если вы хотите просмотреть логи какой-то конкретной загрузки, например, позапрошлой, то достаточно ввести:

Также можно просмотреть информацию по выбранной службе, например, по NetworkManager:

Или же вывести сообщения ядра ОС:

Для получения своих, каких-то более конкретных результатов, допускается комбинировать опции и параметры команды :

Для вывода информации только по нескольким последним записям, применяется опция , задающая их количество:

С помощью параметра можно увидеть, сколько времени понадобилось для загрузки каждой конкретной службы (при этом сверху отобразятся самые медленные):

Что такое логи и зачем они нужны

Логи (log) – это специальные текстовые файлы, в которых в хронологическом порядке фиксируется информация обо всех действиях программы или пользователей. Проще говоря, это журнал регистрации всех событий происходивших в системе:

• ошибки сервера (сбои), возникающие при обращении к некоторым функциям сайта или задачам;
• данные о доступе – запись о подключении (или попытке входа) каждого пользователя, откуда и как он попал на сайт;
• прочие, записывающие информацию о работе компонентов сервера.

Логи доступа указывают на уязвимые места сайта (в случае взлома), помогают собирать статистику посещаемости, узнавать откуда проводились запросы и какие ресурсы ссылаются на этот сайт, оценивать популярность страниц. По файлам ошибок проще найти источник проблемы и оперативно устранить баги и сбои. Журналы сервера (server logs) облегчают контроль рабочего процесса серверной машины.
В файлах логов записывается и отслеживается история работы всего программного комплекса. Поэтому специалисты рекомендуют периодически просматривать их, даже если никаких подозрительных моментов не произошло. И тем более немедленно обратиться к ним, если резко возросло количество ошибок, посыпался спам или заметно увеличилась нагрузка на сервер.

Debugging drains

When using TLS with Syslog drains, it’s possible that either the certificate or hostname verification process will fail, and your drain will stop receiving logs. This can happen for a variety of reasons, including:

• Using an expired certificate
• Using a self-signed certificate
• Certificate hostname mismatches

Errors such as these appear in the log buffer displayed by the command. You might need to stream your app’s logs for a period of time using in order to capture an error. Removing and re-adding a misbehaving drain while streaming the logs can also help track down an issue.

You can also switch to insecure mode for your TLS Syslog drain. This works similarly to . Transport-level encryption will remain active, however all verification checks during the TLS handshake will be disabled. Logplex uses the URI fragment to enable insecure mode:

Зачем нужны лог файлы?

В некоторых ситуациях каждому пользователю ПК или сервера требуется проверить логи. Рассмотрим зачем именно нужны лог файлы. 

1. Логи могут понадобится, если нужно узнать статистику по сайту. Например, логи сайтов отображают следующую информацию:

а) статистику посещаемости

б) точки входа и выхода с сайта

в) поисковые запросы, по которым приходят посетители, и наиболее популярные страницы сайта

г) поисковики, страны и браузеры посетителей

д) уровень конверсии и страницы сайта, которые никто не посещает

е) сайты, которые ссылаются на этот ресурс.

2. В случае вирусов или Дддос атаки на сайт, логи помогут быстрее выяснить причину и соответственно помочь устранить ее.

3. Для восстановления доступов испольузются логи авторизации, которые собирают данные о попытках входа. 

4. В случае ошибок в работе определенного ПО, устройства или ОС, когда необходимо определить источник проблемы. 

Логи (server logs) помогают контролировать работу серверной машины и в случае возникновения ошибок быстро их находить и устранять. Логи используются практически везде, где ведется запись и прослеживание истории программного процесса. В первую очередь это необходимо в целях безопасности. Для того, чтобы найти и проанализировать логи, используют специально предназначенное для этого ПО. Некоторые логи могут обладать очень большим размером, поэтому время от времени их нужно очищать. Лог файл показывает события и его непосредственный источник. Причиной события может быть:

• действия пользователя системы;
• программная ошибка;
• действия со стороны ОС;
• со стороны используемого оборудования и другие.

Настройка хостинга

Когда залили проект на github, переходим в дашборду heroku , чтобы создать новый проект.

Список всех проектов

На этой странице будут находиться все ваши проекты. Чтобы создать новый, сверху справа нажмите на кнопку New, далее на Create new app. Откроется новая страница, на которой нужно ввести данные о новом проекте.

После завершения проект будет создан и нас перенаправит во вкладку Deploy. Там сразу перейдем в настройки github

Настройка github

Находим нужный нам репозиторий и коннектим

Подключение проекта

Далее выберем ветку, за которой будет наблюдать heroku, и нажмём на большую тёмную кнопку.

Выбор ветки, за которой будет наблюдать heroku

Теперь, когда вы зальёте что-то в ветку master, heroku будет подтягивать изменения и обновлять сайт.

На данный момент heroku не успел еще ничего стянуть, поэтому воспользуемся кнопкой ручного обновления

Ручной деплой

После того как сборка завершится (процесс можно отслеживать во вкладке Activity), нажимаем на кнопку Open app

Кнопка запуска проекта

Смена тестового домена

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

Я считаю, что цель статьи была выполнена и можно заканчивать. По всем остальным вопросам обращайтесь в официальную документацию.

Настраиваем Java-Spring-приложение

Теперь добавим в наше Java-Spring-приложение настройки, необходимые для его отправки и запуска в контейнере Heroku.

  Все дальнейшие действия будут показаны на примере операционной системы Windows. На других ОС всё очень похоже, потому что мы везде используем консольную утилиту heroku cli.

Для примера я взял одну из дипломных работ студентов курса «Профессия Java-разработчик». Ваши файлы с параметрами могут немного отличаться, но все остальные настройки будет примерно такими же.

Клонируйте ваш репозиторий и/или откройте проект в IDE — на скриншотах примера показана работа с IntelliJ IDEA Community 2020. Проект должен находиться в корне репозитория.

Первое, что нужно сделать, — добавить в файл конфигурации application.properties наши настройки параметров базы данных и номер порта веб-сервера, по которому приложение будет доступно в браузере. Если его не указать, Heroku назначит порт при запуске проекта самостоятельно.

Пример расположения файлов проекта

Откройте application.properties. Сейчас там такой код:

Добавьте параметры в формате ${Имя_Параметра:Значение_по_умолчанию} для spring.datasource.url и server.port, если их там не было:

Если коротко, такая запись означает, что, если в параметрах запуска присутствует параметр PORT, следует использовать его либо применить значение по умолчанию — 8080. Для переменной spring.datasource.url настройка параметра CLEARDB_DATABASE_URL работает таким же образом — в локальном окружении и в контейнере Heroku. Мы можем открыть наш проект локально c MySQL на порту 3306, а при деплое будут использоваться параметры, передаваемые приложению в строке запуска.

Проверьте, что всё написано верно, и передайте в параметрах строку доступа к созданной нами БД. Для этого откройте параметры запуска приложения, выбрав в меню Run → Edit Configurations… Или выберите на панели инструментов:

Если у вас пока нет ни одной готовой конфигурации, создайте новую или просто запустите приложение. Подойдёт даже неудачный запуск — конфигурация появится в любом случае.

Допишите параметры запуска приложения в поле Environment variables. Удобно зайти в список (кнопка в конце поля, отмеченная на скриншоте) и там ввести значения, если их несколько.

Введите параметр доступа к БД:

  Не забудьте, что логин и пароль уже есть в строке соединения, поэтому отдельные строки данных, прописанные в конфигурации, не используются. Копируйте только ту строку, которую сгенерировал вам Heroku в параметрах Config Vars. Номер порта для тестового запуска менять не нужно.

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

После успешного запуска переходите к следующему этапу.