mod_perl 2环境中的WebApp配置

发布于 2024-12-09 02:57:31 字数 598 浏览 2 评论 0原文

我有一个用 mod_perl 2 编写的 Web 应用程序。(它是一个自定义处理程序模块,而不是注册表或 perlrun 脚本。)我想在服务器初始化时设置几个配置选项,最好是从配置文件中设置。我遇到的问题是我没有找到为我的应用程序的配置文件传递文件名的好地方。

我首先尝试加载“./app.conf”,但当前目录不是模块的位置,因此它是不可预测且容易出错的。或者,我必须假设某种路径——相对或绝对。这是不灵活的,如果主机操作系统发行版发生更改,可能会出现问题。我不想对路径进行硬编码(不过,如果没有更好的方法,/etc 中的某些内容可能是可以接受的)。

我还尝试了 PerlSetVar,但该值在请求时才可用。虽然这是可行的,但这意味着我可能会为每个子(线程)初始化至少从磁盘读取一次配置文件。我宁愿在服务器初始化时加载并拥有一个不可变的静态哈希,该哈希是创建子级时生成环境的一部分。

我考虑过使用 config.pl,但这意味着我要么有一个 config.pl,其中包含一个选项来配置在哪里找到 app.conf 文件,要么我将选项本身移至 config.pl 并要求最终用户尊重 Perl设置选项时的语法。未来的用户将是内部管理员,所以这并非不合理,但它比我想要的更复杂。

那么我错过了什么?有什么好的替代方案吗?

I have a web app I'm writing in mod_perl 2. (It's a custom handler module, not registry or perlrun scripts.) There are several configuration options I'd like to have set at server initialization, preferably from a configuration file. The problem I'm having is that I haven't found a good place to pass a filename for my app's config file.

I first tried loading "./app.conf" but the current directory isn't the location of the modules, so it's unpredictable and error-prone. Or, I have to assume some path -- relative or absolute. This is inflexible and could be problematic if the host OS distribution is changed. I don't want to hard-code a path (though, something in /etc may be acceptable if there's just no better way).

I also tried PerlSetVar, but the value isn't available until request time. While this is workable, it means I'm potentially reading a config file from disk at least once per child (thread) init. I would rather load at server init and have an immutable static hash that is part of the spawned environment when a child is created.

I considered using a config.pl, but this means I either have a config.pl with one option to configure where to find the app.conf file, or I move the options themselves into config.pl and require end-users to respect Perl syntax when setting options. Future users will be internal admins, so that's not unreasonable, but it's more complicated than I'd like.

So what am I missing? Any good alternatives?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

毁我热情 2024-12-16 02:57:31

通常,首要任务是避免在可执行文件中包含配置文件。否则,服务器配置错误可能会意外地向全世界展示您的私人配置信息。我将应用程序所需的所有内容都放在 /srv/app0 下,子目录 cfg 是包含可执行文件的目录的同级目录。 (更多详细信息。

如果您准备-通过PerlPostConfigRequirestartup.pl加载模块来访问mod/startup.pl然后这是放置配置文件位置的最佳位置../cfg/app.cnf 并且您对于如何将配置存储在内存中具有完全的灵活性。另一种方法是使用 PerlModule 模块并在其中一个模块的 BEGIN 块中加载配置(使用上面的相对路径)。

通常处理配置文件不会花费大量时间,因此一个流行的选择是延迟加载:如果代码检测到配置丢失,它会在继续之前加载它。如果代码需要更早地了解配置,那么这是没有用的,但它可以避免很多问题,特别是在将代码迁移到非 modperl 环境时。

Usually a top priority is to avoid having configuration files amongst your executables. Otherwise a server misconfiguration could accidentally show your private configuration info to the world. I put everything the app needs under /srv/app0, with subdir cfg which is a sibling to the dirs containing executables. (More detail.)

If you're pre-loading modules via PerlPostConfigRequire startup.pl to access mod/startup.pl then that's the best place to put the configuration file location ../cfg/app.cnf and you have complete flexibility re how to store the configuration in memory. An alternative is to PerlModule your modules and load the configuration (with a relative path as above) in a BEGIN block within one of them.

Usually processing a configuration file doesn't take appreciable time, so a popular option is to lazy-load: if the code detects the configuration is missing it loads it before continuing. That's no use if the code needed to know the configuration earlier than that, but it avoids lots of problems, especially when migrating code to a non-modperl env.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文