Hi, We are running into an issue with setting commandbox server name within server.json which I believe started when we upgraded from CommandBox 5.2.0 to 5.4.2… and which persists into current 5.6.0 version. Within our server.json we have (amongst other settings) the following to set the server name:

{
  "name": "${INSTANCENAME:UndefinedInEnvironment}"
}

When we were running CB <= 5.2.0, this would correctly set the name of the server to the passed in environment variable… but following on from upgrading to 5.4.2, the servername is always set to

www

- or rather I believe set to the name of the folder the server is started in… Within the detailed output for warmup-server.sh (in this instance running CB 5.5.2) we see the following:

Starting up container in test mode
Set verboseErrors = true
INFO: Configuration set to non-root user: CBServerUser
Set verboseErrors = true
INFO: CF Engine defined as lucee@5.3.9+133
INFO: Convention .cfconfig.json found at /var/www/.cfconfig.json
INFO: Server Home Directory set to: /usr/local/lib/serverHome
 √ | Starting Server
   |------------------------------
   | start server in - /var/www/
   | server name - www
   | server config file - /var/www//server.json
   | WAR/zip archive already installed.

..and when the server starts - either locally or on AWS, the server name always shows up as www previously, within the warmup running within the dev ops build script, where the

INSTANCENAME

environment variable was not set, we would see

UndefinedInEnvironment

shown as the server name, and then when running within local / AWS environments where the environment variable was set, the server name would be set to the environment variable. This is particularly an issue when viewing servers within Fusion Reactor Cloud dashboard… as we have multiple servers for different applications and environments appear in the dashboard as www - and not the specific app / environment name specified. All other dynamically set parameters within the server.json - such as the fusionreator settings for cloudgroup, defaultApplicationName etc. which are set from environment variables, appear to be set correctly (so we can for instance see in FR when we dig into the details what app / environment is being run, but on all the menus, all instances appear as www. Can anyone advise why this behaviour seems to have changed… and if there is something we can do to ensure that the server name is set correctly as it was previously?

Since you're doing this in Docker, there's an additional layer of possibilties

In this particular example base is:

FROM ortussolutions/commandbox:3.5.4

and we are running:

RUN ${BUILD_DIR}/util/warmup-server.sh

It really depends when the very first warmup that defines the server happens

so… are you saying… if we use warmup, then server.json will be ignored for subsequent executions?

We added single server mode to fix related issues where people switching around their server names and such would wind up with having several servers defined with different names and different settings which led to all sorts of issues

was that something which was changed between 5.2.0 and 5.4.2?

You can't change the name on a server without basically creating a new serer

Was this a change in behaviour?

was that something which was changed between 5.2.0 and 5.4.2?

Maybe, you'd need to go read the release notes 🙂

yeah

Sometimes one man's fix is another man's bug

solutions…

FWIW, it's probably possible to enhance CommandBox's single server mode a bit to absorb the last server name used for scenarios like this, that's just not how it works.

That’s the only reason we care about it at all

I was checking, but got distracted talking here 😉

lol

Darn, looks like it's hard coded to use the server name from CommandBox. It must be the ONE thing I didn't add a setting for

lol

We've dealt with the same thing

😄

ok, testing locally...

We definitely need to look at when and where we are doing warmups… trying to follow advice read in the past in order to mitigate against longgggggg startup times within hosted environments… not that it’s completely successful… but it does help… But then we seem to cause issues down the line… Seems we either need to create finalised builds where nothing is set from environment… all at build phase… or have it all dynamic (and slow, and massive images with multiple copies of various apps etc…

Yes, the more dynamic you want, the larger the image normally is

hmm I’m somewhat reluctant to have things like db connection details etc. within the build… just… does not seem right…

It would be nice if Lucee itself had better support for env vars right in the XML configs

yeah, that would be nice… didn’t they say they were going to add that at some point?

no clue...

sweet, I’ll update the build config and give that a whirl…

@bdw429s just tried it with my setup and works a treat - makes FR Cloud with AWS fargate containers much easier to identify. Thanks for adding that one 👍

@bdw429s can confirm, tested this on a local build, and the FR instance is now showing with the specific name 🙂 Thanks for sorting 😄

Well, that caveat only really applies to single server mode. There are honestly tons of little caveats everywhere when it comes to changing server name and web root, lol

Lol ok...

Yeah... Would make sense... Not sure how much benefit this would be outside of the context of passing in to FR... Which is already solved...

Your app name comes from ColdFusion itself

Yes... Already doing... All working fine.... Just responding to... Hang on... I could have sworn I was responding to someone in this thread .. WTF??? has someone deleted a post?

¯\_(ツ)_/¯

Someone posted about how it's possible to set Application name... Which I was responding to...

Ahh, that makes more sense, lol

Yup

FWIW, you may already know this but it appears you can get your instance name set into an env var like so

AWS_INSTANCE_ID=`curl -s <http://169.254.169.254/latest/meta-data/instance-id>`

Yeah.... I had mixed results trying this a while back when using elastic beanstalk multicontainer docker image... Not tried yet in new AL2 docker images to see if it now works...

wow...

The curl method that is... Not the system setting expansion... That looks interesting... Although I presume would still need a way of getting the host instance I'd etc. first...

Not sure exactly what your question is, but in order to use a

${foo}

place holder in a CommandBox JSON file, it would first need to be something CommandBox knew how to find.

Yeah - not a question... Just a stream of consciousness... Issue we had on docker multicontainer image was I believe network configuration related - and not something which was easily fixable due to elements of the docker configuration being somewhat locked down on that image. So I need to check if the http request method works first prior to building anything which relies on that...

So above, I was suggesting two different approaches. 1. Just running a bash line somewhere to set a proper OS level env var, which would get pulled in via bullet #3 above 2. Or writing a custom CommandBox module that adds a system setting namespace for looking up AWS specific instance information which would be bullet #5 (and would remove the need for any curl stuff)

Yeah... I get it... But option 2 would still need a way of getting the info 😉 http request probably being the simplest... If it works!

The other thing I'd really like to see is

${custom-aws-secret-namespace.name-of-secret}

so people can use AWS's custom secret store directly in their JSON files via system settings. It would be trivial to write, I just don't need it myself, lol

Both of those, especially the second, would be of interest. Maybe something I can look at if we get some downtime...

I'll happily help guide if you are interested in helping write it

Yeah... Pretty certain it was that the build locked down config of the network resolution... Probably solvable but didn't look further at the time...

@danlance Good questions • your interceptor will fire every time any system setting is resolved anywhere in CommandBox for any reason (well, unless another core interceptor has already resolved the value, breaking the chain of execution) • It's up to your code to recognize the prefix it cares about and only attempt the HTTP call when it knows the system setting being expanded is one it can provide • If the values never change, I would highly recommend caching the data • If there is an endpoint to get all the data available in one go, you could just cache the whole lot of it. (your interceptor is a singleton, so you can stick whatever you like in the variable scope and it will live for as long as the CommandBox CLI is running. • I would use a timeout on the http and a small one at that. If the CFHTTP errors, I would log it with the

log

logger available in your interceptor

log.error( 'error getting system setting #name#', e )

which will go in CommandBox logs visible with

system-log | tail

In the event of an error, you should return the default value which was provided. The default value should be provided any time you can't find whatever was asked for. You could choose to throw an exception if you are very sure there will not be a default value and it is fatal if nothing is found, but that's not really how system settings works. Default values are provided like so

${namespace.key:default}

going backwards… default value - am I correct in thinking that is empty string if not specified?

Yes, there will always be a default value of an empty string if the user didn't specify one

👍

But you don't need to worry about what the default value is-- it's passed into your interceptor I believe

Am I correct in my understanding… that the interceptor runs before onServerStart? I was trying to define vars in onServerStart… and getting errors when referencing said vars that they do not exist… but then it struck me that as this setting config etc. it would fire before onserverstart?

I have no idea what you mean, lol. I'd have to see what you're looking at

lol - I was trying to nick some stuff from your CB FR module… Which has logging functions and stuff like that… but everything in there is intialised in the onServerStart event… and erroring

Forget the FR module, there's nothing in there you need

ok

All you need is • a moduleconfig.cfc that declares the `onSystemSettingExpansion`interceptor • an interceptor file that contains just that method in the docs, but with your logic instead

already available in the interceptor?

Yes, just like ColdBox 🙂

uhhh… ok… not actually ever used that 😳

There's these docs, but honestly it's way more information than you need, lol https://coldbox.ortusbooks.com/the-basics/interceptors

ah ok - that’s how id done it from the example… stuck it in the moduleconfig

Internally CommandBox uses lots of modules internally just for organization. Here is the moduleconfig for the server module https://github.com/Ortus-Solutions/commandbox/blob/development/src/cfml/system/modules_app/server-commands/ModuleConfig.cfc#L13

ok… so moduleconfig just has the configur() method registering interceptos…

Note, there's two different namespaces that intereptor is looking for (

serverjson.

and

serverinfo.

)

IS the interceptor a singleton?

yeah, I said that above

sorry… missed that

So as far as where you put the method, you can pick your approach. The separate CFC is the more formal approach but has a bit more boilerplate

ok… if I go down the separate interceptor route… to acess logbox… is it there by default, or do I need set a property for injection?

FWIW, I also have these interceptor docs in CommandBox, but they don't go nearly as deep. https://commandbox.ortusbooks.com/developing-for-commandbox/interceptors

so logbox.log() to use?

almost, I showed you the code above 🙂

ah ok

oh dang, I lied-- moduleconfig also has a log object mixed in. I probably added that in CommandBox because I was annoyed that ColdBox didn't do it 😆 https://github.com/Ortus-Solutions/commandbox/blob/development/src/cfml/system/services/ModuleService.cfc#L696

Thanks Brad… I have a working POC for getting the instance ID up within an existing app on AWS… Need to do some tidy up, separate it from the app into a standalone package, possibly make it more multifunctional… and see how much more complicated it is to get this to work with IMDSv2 (current approach requires IMDSv2 which is supposed to be avoided when possible…) That’s a task for tomorrow though…

@danlance Your module looks pretty good, you just have the wrong type in your

box.json

https://github.com/Gencia/commandbox-awsimds/blob/master/box.json#L56

I was going to say no… but I think there may be… returns JSON… let me just recheck

Yeah, you brought that upon yourself when you decide to take on the complexities of Docker for local dev 😉

Yeah… does make it easy to get dev environments up remotely for external contractors etc. in a consistent manner which is mostly independent of the system being used… and be much more confident that something that works locally will work within hosted environments subject to consistent configuration…. But yeah, does come with it’s downsides, and probably much less benefit when using Commandbox

Everything you said above also applies to CommandBox 🙂

make it easy to get dev environments up remotely for external contractors etc. in a consistent manner which is mostly independent of the system being used… and be much more confident that something that works locally will work within hosted environments subject to consistent configuration….

☝️ ☝️ ☝️ ☝️ ☝️ ☝️

Yeah - was going to say… when working with SOA with multiple dependencies… docker works well… but for basic, probably adds more overhead than is worthwhile… However… it’s one of those… is it more work to change what is working and something for which we have a consistent approach between dev / test / prod environments… or come up with something new (and simpler) for the cases where that approach would be more suitable… ..and still, there would be more difference between the local and prod environments with that approach - one using docker / nginx / multiple services, and one where you are just using commandbox… I suppose I’ve been burnt too many times over the years with issues caused by environmental differences… that an approach where I can run identical images in multiple environments, and be pretty confident that in the vast majority of cases, if it works locally, it will also work remotely… is more appealing to me than maybe is warranted… And for stuff where your stack is made from multiple dependant web services, and relies on nginx etc. for URL rewriting, S3 proxying and client cert based authentication… then the docker exclusive approach has some additional benefits

there would be more difference between the local and prod environments with that approach

I actually think it's far fewer differences than people realize. The JVM itself already provides a abstraction layer, and CommandBox is capable of dialing in the exact version of your CF engine, and even your JDK version. If I were to draw a Venn diagram of all the configuration things that could make a difference between dev and prod, there would be a huge circle of things and then an ever-so-slightly-smaller circle inside labeled "stuff CommandBox lets you control" 🙂 Heck, CommandBox even lets you force the case sensitivity (or lack thereof) for static files in the web server so you can be on Windows and pretend it's Linux or vice versa!

relies on nginx etc. for URL rewriting, S3 proxying and client cert based authentication

CommandBox already does • URL rewriting • client cert auth (new in the latest version!) I'm not sure what you mean by S3 proxying, but I'm curious, since Undertow's built in HTTP proxy can probably do it too!

As in CMS uploads files to S3 via lucee mapping, but for direct links referencing those files, (images etc.) they are proxied directly to s3 https endpoint without having to go through lucee… but whilst still appearing to be hosted on the same website

Yeah, you could do that with CommandBox 🙂

ah cool

Simple round robin load balanced reverse proxying to back end servers

not everything which commandbox is not capable of… has been available for ever… like the client cert stuff… that’s a more recent addition The main and most complex app we are working with, was initially migrated from windows / CF9 to docker / nginx / lucee… and then from there commandbox was introduced, mainly for config, effectively by substituting cg docker image in there instead of the official lucee docker image… then as time has progressed we have used more of CB functionality - but still probably only really scratch the surface of what it is capable of. I think maybe if we were starting again… and had appropriate budget… then we would look at a no nginx / CB only route… and see if docker local was still the best approach

Sweet, thx!