В предыдущем посте я мельком упомянул библиотеку ostrich в качестве инструмента для загрузки конфигов, в этом же постараюсь сделать более подробный обзор. Итак, ostrich - это внутренняя библиотека от разработчиков “твиттера”, используемая в его компонентах. Несмотря на фичастость и навороченность, местами довольно-таки заметен её стиль, как библиотеки написанной в первую очередь “для себя”.

Оstrich выполняет следующие задачи:

• загрузка и парсинг typesafe-конфигов (проще, говоря, конфигов в виде scala-кода)
• сбор рантайм-статистики и разнообразных метрик
• управление сервисами внутри процесса (запуск/остановка)
• предоставление простенького, но расширяемого администраторского интерфейса через http/socket

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

Страус и конфиги

Итак, ostrich предлагает использовать в качестве конфигов не просто структурированные текстовые файлы (json/xml/properties), а scala-код. Такой подход требует компиляции конфига при загрузке, но имеет ряд серьёзных преимуществ:

• типизация. Отпадает необходимость проверять и приводить значения из конфиг-файла к нужным типам
• возможность писать произвольный код в конфигах, помимо простых значений. Например, использовать текущую дату в произвольном формате в имени лог-файла, или получить значения каких-то параметров из базы или стороннего сервиса. По сути, конфиг-файл становится тем, что называется extension point.
• становятся ненужными отдельные классы, инкапсулирующие конфигурацию различных компонентов программы, или, по крайней мере, упрощается их создание.

Для начала, нам нужно создать родительский класс для настроек. Чаще всего удобно сделать его же конфигом по умолчанию. Предположим, мы хотим сконфигурировать небольшое серверное приложение. Для этого ostrich предоставляет класс ServerConfig (являющийся наследником Config, предоставляющего базовые функции такие как компиляция, валидация и обязательные/необязательные поля).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

import com.twitter.ostrich.admin._
import com.twitter.ostrich.admin.config._
import com.twitter.logging.config._
import com.twitter.logging.Level


class MyServerConfig extends ServerConfig[MyServer] {

  //ServerConfig, в отличие от просто Config, должен определить 
  //метод Apply, для создания инстанса сервера
  def apply(runtime: RuntimeEnvironment) = {
    new MyServer(this)
  }

  var port = 1234
  var workersNum = 10
  var baseUrl = "http://localhost:%s" format port
  var dbConfig = new DBConfig
}

case class DBConfig(
  var driver = "org.h2.Driver"
  var uri = "jdbc:h2:mem:"
  var create = true
)

Надо заметить, что мы используем в этом конфиге изменяемые переменные (var). В Scala это зачастую является признаком недостаточно функционального (декларативного) стиля, однако в данном случае это позволит писать лаконичные конфиги, выставляя значение полей простым присваиванием. Кроме того, этот же стиль используется при объявлении уже имеющихся в ServerConfig значений.

Итак, теперь наш конфиг для, например, тестового сервера, может выглядеть так:

1
2
3
4
5
6

    new MyServerConfig {
      port = 80
      baseUrl = "http://test.myserver.com"

      dbConfig.uri = "jdbc:h2:/tmp/test.db;AUTO_SERVER=TRUE"
    }

Вполне лаконично, и ничуть не хуже .properties и уж тем более XML-файла. Можем сохранить его под именем test.scala, тогда наш сервер мы сможем запускать как

1

    java -jar my-server.jar -f ./test.scala

Загрузка

Теперь, наш файл настроек надо загрузить и использовать по назначению. Делать это логичнее всего поближе к точке входа, например в main. Путь к файлу можно передать с параметром -f при запуске приложения, а если его нет, то ostrich попытается найти его сам. Определение местоположения конфиг-файла - это то самое место, где становится видно, что проект делался для себя: ostrich ищет его в довольно специфических местах, пытаясь сначала выяснить имя jar-файла. Поэтому, проще всего всегда передавать путь к конфигу через -f плюс явно указать конфиг по умолчанию. Поскольку конфиг по умолчанию является обычным scala-классом, можно просто создать его инстанс в коде. Вот как выглядит загрузка и использование конфига у меня:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

    object MyServer {
      def main(args: Array[String]) {
        val runtime = RuntimeEnvironment(this, args)
        val server =
          if (runtime.configFile.exists) //если ostrich нашёл конфиг-файл 
            runtime.loadRuntimeConfig[Server]()
          else //default
            (new MyServerConfig)()(runtime)

        server.start()
      }
    }

    class MyServer(val config: MyServerConfig)
    {
      val db = new DB(config.dbConfig)

      def start() {
        //...
      }
    }

Обратите внимание на строчку (new MyServerConfig)()(runtime): сначала мы вызываем метод apply без параметров, а потом вызываем полученную функцию с параметром типа RuntimeEnvironment. При необходимости, этот способ можно расширить для загрузки различных конфигов по умолчанию, например в зависимости от run.mode в lift.

Я не использовал возможность ostrich объявлять поля как обязательные/опциональные, но промолчать о ней будет, наверное, неправильно. В приведённой к классу Config документации всё довольно просто:

1
2
3
4
5
6
7
8

    //необязательное поле
    var something = optional[Duration]

    //обязательное поле
    var level = required[Int]

    //вычисляемое (lazily evaluated!) поле
    var nextLevel = computed(level + 1)

Конфигурация компонентов

В вышеприведённом примере мы вынесли настройку базы данных в отдельный класс DBConfig. Иногда, со стороны приложения бывает удобно вынести конфигурацию в отдельный класс, но усложнять структуру конфиг-файла не хочется. Хорошим примером является случай, когда конфигурируемый компонент находится в другом (под)проекте. В этом случае, конфиг можно объявить трейтом и подмешать его в основной конфиг

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

1
2
3
4
5
6
7
8
9

trait MailConfig {
  def smtpServer:  String
  def smtpPort:    String
  def fromAddress: String
}

class MailManager(val config: MailConfig) {
  ...
}

Теперь мы просто подмешиваем трейт в наш основной конфиг, перегружая его методы нашими varами:

1
2
3
4
5
6
7
8
9
10

    class MyServerConfig
    extends ServerConfig[MyServer]
    with MailConfig
    {
      ...

      var smtpServer = required[String]
      var smtpPort = 24
      var fromAddress = "noreply@domain.com"
    }

В нашем конфиг-файле (test.scala) эти поля будут работать точно так же как и все остальные. При инстанциировании менеджера можно просто передать ему общий конфиг:

1
2
3
4
5
6
7

    class MyServer(val config: MyServerConfig)
    {
      val db = new DB(config.dbConfig)
      val mailer = new MailManager(config)

      ...
    }

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

Вот собственно и всё что я хотел рассказать об использовании ostrich для конфигурирования. Я намеренно не стал рассматривать имеющиеся в ServerConfig поля для настройки логгинга, статистики и админки. Мы вернёмся к ним попозже, когда я буду рассказывать о соответствующих фичах “страуса”.