- dancer-users - lists.preshweb.co.uk

Re: [dancer-users] Passing environment to dockerized Dancer2
by Mikko Johannes Koivunalho 20 Jul '21

20 Jul '21

> Dear Dancer users, > > I want to run my Dancer2 application in a docker but I want to run the > docker without mounting any local directories and I want to run the same > container in all environments, not compile it separately for different > environments. > > Problem: > How do I pass the environment dependent parts of the configuration to > the docker? I cannot use file `config_local.yaml` because then I would > need to copy that file somehow into the container when it starts. > > Possible solution: > I would pass parts of the configuration as environment variables, e.g. > /DB_HOST/ and/SITE_URL/, and then apply these over the values in > config.yaml when I am creating the endpoints. > > Suggestion: > Change the command `/config/` (or the underlying file reader function) > so that it can transpose environment variables into config strings, e.g. > plugins->database->connections->main->host = '${DB_HOST}'. I have built a solution to this. I have not yet submitted a Pull Request. I am using this solution in my build and web application. Please comment. Would this be a good pull request? What the PR does? 1) After reading the whole config from different files, it traverses the whole tree and if it sees a string with a substring like "${ENV:SOME_ENV}", it changes it to the corresponding environment variable, if that environment variable is defined. 2) Before doing 1), it checks if the config item "env_var_replace" is defined and is boolean true. If so, then it executes 1). Otherwise it skips. This is to maintain backwards compatibility. (I have tests for the actual PR. Not included here.) diff --git a/lib/Dancer2/Core/Role/ConfigReader.pm b/lib/Dancer2/Core/Role/ConfigReader.pm index 0d0bc1ab..b8e1fdaf 100644 --- a/lib/Dancer2/Core/Role/ConfigReader.pm +++ b/lib/Dancer2/Core/Role/ConfigReader.pm @@ -232,6 +232,12 @@ sub load_config_file { } # TODO handle mergeable entries + + if( defined $config->{'env_var_replace'} && $config->{'env_var_replace'} ) { + warn "Apply environment variables to config\n" if $ENV{DANCER_CONFIG_VERBOSE}; + $self->_replace_env_vars($config); + } + return $config; } @@ -275,6 +281,48 @@ sub _compile_config_entry { return $trigger->( $self, $value, $config ); } +# Attn. We are traversing along the original data structure all the time, +# using references, and changing values on the spot, not returning anything. +sub _replace_env_vars { + my ( $self, $entry ) = @_; + if( ref $entry ne 'HASH' && ref $entry ne 'ARRAY' ) { + croak 'Param entry is not HASH or ARRAY'; + } + if( ref $entry eq 'HASH' ) { + foreach my $value (values %{ $entry }) { + if( (ref $value) =~ m/(HASH|ARRAY)/msx ) { + $self->_replace_env_vars( $value ); + } elsif( (ref $value) =~ m/(CODE|REF|GLOB)/msx ) { + # Pretty much anything else except SCALAR. Do nothing + 1; + } else { + if( $value ) { + while( my ($k, $v) = each %ENV) { + $value =~ s/ \$ [{] ENV:$k [}] /$v/gmsx; + } + } + } + } + } else { + # ref $entry is 'ARRAY' + foreach my $value (@{ $entry }) { + if( (ref $value) =~ m/(HASH|ARRAY)/msx ) { + $self->_replace_env_vars( $value ); + } elsif( (ref $value) =~ m/(CODE|REF|GLOB)/msx ) { + # Pretty much anything else except SCALAR. Do nothing + 1; + } else { + if( $value ) { + while( my ($k, $v) = each %ENV) { + $value =~ s/ \$ [{] ENV:$k [}] /$v/gmsx; + } + } + } + } + } + return; +} + 1; __END__ -- Mikko Koivunalho LinkedIn: http://www.linkedin.com/in/MikkoKoivunalho AboutMe: http://about.me/mikkokoivunalho Blog: http://www.koivunalho.org/blogs/exercises-in-integration-and-delivery/

2 2

Passing environment to dockerized Dancer2
by Mikko Johannes Koivunalho 19 Jun '21

19 Jun '21

Dear Dancer users, I want to run my Dancer2 application in a docker but I want to run the docker without mounting any local directories and I want to run the same container in all environments, not compile it separately for different environments. Problem: How do I pass the environment dependent parts of the configuration to the docker? I cannot use file `config_local.yaml` because then I would need to copy that file somehow into the container when it starts. Possible solution: I would pass parts of the configuration as environment variables, e.g. /DB_HOST/ and /SITE_URL/, and then apply these over the values in config.yaml when I am creating the endpoints. Suggestion: Change the command `/config/` (or the underlying file reader function) so that it can transpose environment variables into config strings, e.g. plugins->database->connections->main->host = '${DB_HOST}'. -- Mikko Koivunalho [ This message has been signed with PGP. Public key available at request. ]

2 1

Dancer2 0.301003 Released
by Jason A. Crome 03 Jun '21

03 Jun '21

On behalf of the Dancer Core Team, I’d like to announce the availability of Dancer2 0.301003. Read all about it here: http://blogs.perl.org/users/jason_a_crome/2021/06/dancer2-0301003-released.… Happy Dancing! Jason/CromeDome -- Jason A. Crome / CromeDome CPAN: https://metacpan.org/author/CROMEDOME GitHub: https://github.com/cromedome Twitter: https://twitter.com/cromedome Blog: https://cromedome.net

1 0

A shared vision of Perl
by Andrew Solomon 29 May '21

29 May '21

Dear Dancer users, On behalf of The Perl Foundation (https://www.perlfoundation.org/) Gobby ( https://gobby.io/) is running a survey to identify the shared values of the Perl community, and their vision of the Perl ecosystem in years to come. The goal is to provide information on which The Perl Foundation, community groups, and individuals can make informed decisions and plans for the future. Please click here (https://gobbysurvey.com/asharedvisionofperl) to share *your* values and vision for the future of Perl. I'll be presenting the background to this survey, and the results so far, at The Perl and Raku Conference online (https://sched.co/jMSQ) on June 10. Thanks in advance, Andrew

1 0

First issue
by Gregor Stanic 24 May '21

24 May '21

Hi everybody, I am new at Dancer, I just made simple hello word application with dancer and mason2 template. When I try to invoke "use Dancer qw(session)" in template i get this error: Couldn't find declarator 'method' at C:/Strawberry/perl/vendor/lib/Devel/Declare/Context/Simple.pm line 47. Devel::Declare::Context::Simple::skip_declarator(Method::Signatures::Simple=HASH(0x5dedc00)) called at C:/Strawberry/perl/vendor/lib/Devel/Declare/MethodInstaller/Simple.pm line 62 Devel::Declare::MethodInstaller::Simple::parser(Method::Signatures::Simple=HASH(0x5dedc00), "method", 0, 1) called at C:/Strawberry/perl/vendor/lib/Devel/Declare/MethodInstaller/Simple.pm line 25 Devel::Declare::MethodInstaller::Simple::__ANON__("method", 0) called at C:/Strawberry/perl/vendor/lib/Devel/Declare.pm line 277 Devel::Declare::linestr_callback("const", "method", 0) called at C:\test\Test-Purpose\views/users/Base.mc line 3 require C:\test\Test-Purpose\data\obj\users\Base.mc.mobj called at (eval 470) line 1 eval 'package MC2::users_Base_mc; use Moose; extends \'Moose::Meta::Class::__ANON__::SERIAL::5\'; do(\'C:\\test\\Test-Purpose\\data\\obj\\users\\Base.mc.mobj\'); die $@ if $@' called at C:/Strawberry/perl/site/lib/Mason/Interp.pm line 441 Mason::Interp::_load_class_from_object_file(Mason::Interp=HASH(0x676528), "MC2::users_Base_mc", "C:\\test\\Test-Purpose\\data\\obj\\users\\Base.mc.mobj", "/users/Base.mc", "/") called at C:/Strawberry/perl/site/lib/Mason/Interp.pm line 308 Mason::Interp::load(Mason::Interp=HASH(0x676528), "/users/Base.mc") called at C:/Strawberry/perl/lib/Memoize.pm line 249 Memoize::_memoizer(CODE(0x5388910), Mason::Interp=HASH(0x676528), "/users/Base.mc") called at (eval 365) line 1 Memoize::__ANON__(Mason::Interp=HASH(0x676528), "/users/Base.mc") called at C:/Strawberry/perl/site/lib/Mason/Interp.pm line 433 Mason::Interp::_load_class_from_object_file(Mason::Interp=HASH(0x676528), "MC2::users_layouts_main_mc", "C:\\test\\Test-Purpose\\data\\obj\\users\\layouts\\main.mc.mobj", "/users/layouts/main.mc", "/users/Base.mc") called at C:/Strawberry/perl/site/lib/Mason/Interp.pm line 308 Mason::Interp::load(Mason::Interp=HASH(0x676528), "/users/layouts/main.mc") called at C:/Strawberry/perl/lib/Memoize.pm line 249 Memoize::_memoizer(CODE(0x5388910), Mason::Interp=HASH(0x676528), "/users/layouts/main.mc") called at (eval 365) line 1 This is my simple template: <%class> use Dancer qw(session); </%class> <%augment wrap> <!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <title>Portal</title> <META HTTP-EQUIV="CACHE-CONTROL" CONTENT="NO-CACHE"> <META HTTP-EQUIV="PRAGMA" CONTENT="NO-CACHE"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <meta name="description" content=""> <meta name="author" content=""> <body> <div class="container"> <div class="page-header"> TESTING <br> <% inner() %> </body> </html> </%augment> What I am missing? Best Regards Gregor

2 2

Dancer2 0.301002 Released
by Jason A. Crome 18 Apr '21

18 Apr '21

On behalf of the Dancer Core Team, I'd like to announce the availability of Dancer2 0.301002. This release includes a number of enhancements and documentation changes along with several bugfixes. The most notable enhancement is a brand new command line interface, and I highly encourage you to check it out. This is feature-for-feature compatible with the previous CLI, but has a few minor cosmetic differences from the prior version. Under the hood, however, it is entirely different. We previously used App::Cmd as the basis for our CLI, but recent changes to it bumped the minimum Perl version to 5.20. As we strive to maintain compatibility back to at least Perl 5.10, this caused some problems for users stuck on older Perl versions. We monkey-patched a fix in a previous version, but our new-and-improved CLI based on CLI::Osprey is the path forward. Even better, CLI::Osprey has no dependencies outside of those we already had in the Dancer2 toolchain, so your favorite lightweight web framework just got even lighter. You can read the complete changelog here: https://metacpan.org/changes/distribution/Dancer2 If you need help, please reach out on IRC (irc.perl.org#dancer) or our mailing list: https://lists.perldancer.org. Thank you to our users for being one of the best parts of the Perl community. We appreciate your continued feedback and support. Please reach out with any suggestions or needs you have. Happy Dancing! CromeDome -- Jason A. Crome / CromeDome CPAN: https://metacpan.org/author/CROMEDOME GitHub: https://github.com/cromedome Twitter: https://twitter.com/cromedome Blog: https://cromedome.net

1 0

Debugging memory leaks
by Zahir Lalani 30 Mar '21

30 Mar '21

Confidential Hi all Wondering if I can get some guidance. Our application is growing in use and have recently found that UWSGI runs out of worker resources - but when we use uwsgitop, its more that memory has shot up. The only way to resolve is a restart of uwsgi. That sounds like a memory leak, but I am not sure what tools can help me in that regard. I assumed that Perl was quite good at cleanup, but something is not right here. Any guidance appreciated Z

3 4

Dancer2 0.301000 Released
by Jason A. Crome 15 Mar '21

15 Mar '21

On behalf of the Dancer Core Team, version 0.301000 is now available. This is not the release we envisioned; it is missing some things we'd like to have finished, but it does have a couple of new things worth pointing out: - A new keyword, request_data, to get the entire deserialized body of the request - A new Cookbook recipe for showing how to dynamically enable/disable modules and routes at runtime - Numerous doc and bug fixes. Check out the changelog (https://metacpan.org/changes/distribution/Dancer2) for a complete list of changes. The big thing worth pointing out is App::Cmd, which is now not a requirement of Dancer2. A new version of App::Cmd was released with a minimum version requirement of Perl 5.20. We aim to support Dancer2 back to Perl 5.10, which was no longer possible with the current App::Cmd. We had several options to consider in moving forward, and the one we chose was this: If you want to use the Dancer2 CLI, you must *explicitly* install App::Cmd. If you have previously installed Dancer2, all is well. If this is a new install and you are on a Perl older than 5.20, you will not be able to use the CLI (`dancer2 gen`) until you can upgrade your version of Perl, *or* you can install a version of App::Cmd version 0.331 or older (generally, cpanm App::Cmd@0.331 will do here). On Perl 5.20 or newer, install App::Cmd if you want to use the CLI and you're golden. A more well-thought out solution will be provided in a not-too-distant release. We know this does not make for the best user experience, and for that, we apologize. Not breaking backwards compatibility is important, however, and for the short-term, this seemed like the best solution. We will deliver something better (and more permanent) soon. Thanks for your patience and continued support. Now, go forth and keep dancing! Jason / CromeDome -- Jason A. Crome / CromeDome CPAN: https://metacpan.org/author/CROMEDOME GitHub: https://github.com/cromedome Twitter: https://twitter.com/cromedome Blog: https://cromedome.net

1 0

Designing a route for a long survey
by Richard Reina 20 Feb '21

20 Feb '21

I have a friend who needs me to develop a page which is a long survey, There is some skip logic needed, for example, if users birthday is before x date skip to question 5, if answer to question 12 is 'no' skip to question 16, but nothing too complicated. I nevertheless am struggling with how to design such a route and was wondering if anyone perhaps knew of any similar examples. Rciahrd

2 2

passing client/socket error from server to dancer app
by Paul Clements 15 Feb '21

15 Feb '21

I asked a similar question a few weeks ago, and am circling back because I am still in need of a solution. As it turns out, without a way to handle client/socket disconnect, I am having trouble finding a suitable working combination of Dancer2/PSGI Server. I've tried several, and while Twiggy does give an error (SIGPIPE) on client disconnect, my app is not AnyEvent- (or even thread-) based, so the forking servers (e.g., Starman) are a better fit (without rewriting substantial amounts of code). At this point, I'm wondering if a fairly simple change to Dancer2 might be acceptable. It's a minimal change, but gives the Dancer2 app a way to know when a client disconnect has occurred in a "delayed" handler. Specifically, it turns out that many/most servers return "undef" from their write routines once the socket is closed. So, the idea is to allow that information to pass back to the app: diff --git a/lib/Dancer2/Core/DSL.pm b/lib/Dancer2/Core/DSL.pm index fd29ac74..9adb3e28 100644 --- a/lib/Dancer2/Core/DSL.pm +++ b/lib/Dancer2/Core/DSL.pm @@ -329,7 +329,7 @@ sub content { eval { $Dancer2::Core::Route::WRITER->write(@_); - 1; + # use write's return code instead # 1; } or do { my $error = $@ || 'Zombie Error'; $Dancer2::Core::Route::ERROR_HANDLER It doesn't seem like the constant 1 return code from "content" is something that anyone would be relying on, so changing it shouldn't hurt (?), but would provide a way to get the error information back to the app, e.g.: my $client_ok = content $data; if (!defined($client_ok)) { # something's wrong! Thanks, Paul

1 1