Как передать свойства в контекст tomcat без использования catalina.properties или есть лучший способ ввести свойства?
Мы пытаемся переместить наши проекты в докер, используя образ tomcat, и немного не понимаем, как вводить свойства.
Наша конфигурация прямо для конфигурации базы данных теперь выглядит так:
/opt/tomcat/conf/context.xml
<Context>
<WatchedResource>WEB-INF/web.xml</WatchedResource>
<ResourceLink name = "DBCON"
global = "jdbc/DBCON"
auth = "Container"
type = "javax.sql.DataSource"/>
<Resource name = "jdbc/DBCON"
auth = "Container"
type = "javax.sql.DataSource"
driverClassName = "oracle.jdbc.OracleDriver"
url = "${oracle.database.url}"
username = "${oracle.database.username}"
password = "${oracle.database.password}"
maxActive = "100"
maxIdle = "20"
minIdle = "5"
maxWait = "10000"/>
</Context>
/opt/tomcat/conf/catalina.properties
some other properties ...
...
...
oracle.database.url=jdbc:oracle:thin:@dev-database.com:1521:dev1
oracle.database.username=user
oracle.database.password=pass
Мы надеемся использовать секреты, которые отображаются в какое-то место на сервере /some/loc/secrets/oracle.database.properties, но не понимаем, как их вводить в context.xml, и мы не хотим добавлять или редактировать файл cataline.properties. Мы планируем перейти на пружинную загрузку в будущем, но для некоторых проектов работа довольно серьезна.
Я нашел примеры <Envrionment> и <PreResources>, но не понимаю, как мы можем указать context.xml на самом деле использовать эти свойства.
@NiVeR преимущество - безопасность.
Почему бы не использовать встроенную функцию Секрет докера с файлом свойств? Если вы используете Spring, вы можете использовать аннотацию @PropertySource для загрузки файла.
@NiVeR Они должны быть динамичными для различных сред и безопасности. @PraveenP Мы используем секреты докеров для других служб, отличных от java / tomcat. Не потребуется ли при использовании @PropertySource изменения кода?
@ flip66 Хорошо, но у вас будут разные коты для каждой среды, не так ли? Это вопрос выбора. Также можно иметь несколько файлов application-{profile}.properties и заполнять свойства по профилю.
@ flip66 Я знаю, что это старый вопрос, но что вы сделали, чтобы решить эту проблему? У меня такая же проблема с Dockerizing устаревшими приложениями Spring, и я также хотел бы иметь возможность параметризовать context.xml с помощью файла секретов. Закончилось изменение catalina.properties, но не выглядит элегантным.
Ответы 2
Задайте как системные переменные свойства вашей БД:
export JAVA_OPTS=$JAVA_OPTS -Doracle.database.username=user -Doracle.database.password=pass
Мы делаем это на нашем локальном компьютере, но не можем сделать это в PROD.
@ flip66 Могу я спросить, почему бы и нет? Это один из предпочтительных подходов большинства разработчиков.
@ flip66 действительно почему? Это очень распространенный подход. Если вы не можете этого сделать, то вам не следует использовать JNDI. Вы должны создать свои соединения с БД с помощью Spring или почему бы и нет, вручную, а затем вы можете поместить свою конфигурацию БД в файл свойств. Другой подход - не использовать глобальный файл context.xml из tomcat/conf. У вас есть возможность включить в свою папку WEB-INF, если я не ошибаюсь, пользовательский файл context.xml.
У нас есть строгое требование не помещать пароли в переменные среды, поэтому мы используем секреты докеров (файлы). Мы рассмотрели отображение всего файла контекста для этого приложения в /opt/tomcat/conf/Catalina/localhost/someapp.xml, но похоже, что это противоречит цели создания образа, поскольку мы пытаемся минимизировать накладные расходы OP.
Как уже упоминалось другими, переменные в файле context.xml должны быть доступны как системные свойства. Из справочника по конфигурации Tomcat:
Tomcat configuration files are formatted as schemaless XML; elements and attributes are case-sensitive. Apache Ant-style variable substitution is supported; a system property with the name propname may be used in a configuration file using the syntax ${propname}. All system properties are available including those set using the -D syntax, those automatically made available by the JVM and those configured in the $CATALINA_BASE/conf/catalina.properties file
Если вам нужны эти секретные значения в другом файле, вы можете переопределить CMD контейнера докеров Tomcat. Это может быть, например, сценарий оболочки, который считывает переменные из файла, экспортирует их, как в ответе @ Octavian, и только после этого запускает сервер.
В чем преимущество параметризации таких свойств? Я бы поместил их статически в кота.