Is it possible to configure Lucee without using GUI?

dev
1

I know this question has come up before, but I haven’t seen a complete thread with current information on it. We would like to completely eliminate the need to configure Lucee from any web GUI, and to put all configuration options in code. We would at least like to move as much as possible away from the GUI in favor of code.

I realize that many config settings can be done in application.cfc. For example, setting a datasource:

variables.system = system = createObject("java", "java.lang.System");
variables.dsn = system.getEnv("MYSITE_DSN");
this.datasources[variables.dsn] = {
	"class" = system.getEnv("MYSITE_DSN_CLASS"),
	"connectionString" = system.getEnv("MYSITE_DSN_CONNECTIONSTRING"),
	"database" = system.getEnv("MYSITE_DSN_DATABASE"),
	"driver" = system.getEnv("MYSITE_DSN_DRIVER"),
	"host" = system.getEnv("MYSITE_DSN_HOST"),
	"port" = system.getEnv("MYSITE_DSN_PORT"),
	"type" = system.getEnv("MYSITE_DSN_TYPE"),
	"url" = system.getEnv("MYSITE_DSN_URL"),
	"username" = system.getEnv("MYSITE_DSN_USERNAME"),
	"password" = system.getEnv("MYSITE_DSN_PASSWORD")
}

Is there a performance hit for creating a new instance of system for every request, and setting up configurations this way? Or is there a better way to do it? Can anyone point me to a more comprehensive “best practices” article on this subject?

2

Have you seen this:

Works on Adobe and Lucee with a generic JSON format as well as env var support for containers.

3

I have seen CFConfig… I used it a few months ago when I was trying to export/import some settings. Seemed to work well, with exception to some settings that were not supported at the time. I noticed that you guys recently released version 1, so maybe everything is resolved. But, we don’t want to import, so that’s probably not an issue.

I’ll have to read through the docs to see how this would work. We’re not currently using commandbox for any deployments, but we are in the process of moving to Linux and completely reworking our deployment methods, so maybe this is a good time to see how the Ortus ecosystem will work for that.

4

Let me know if you have any questions. As you said, there are a handful of things you can control in Application.cfc and via env vars, but so far as I’m concerned, CFConfig IS the way to manage your config deploys without touching a web GUI.

You can still use CFConfig just as a CLI tool to apply config to a traditionally-installed server even if you’re not starting the servers with CommandBox. Also, if there’s still features not supported, make sure there’s tickets in for them. I received 30 pull requests from 12 different people in the 20 months leading up to the 1.0 release so I am very open to you helping add any missing pieces!

5

Thanks Brad! This seems like exactly the tool we need. Looks like we can store all our config settings in a json file and expand environment variables as needed. We’ll be working on this over the next few months, so I’ll hit you up if I have any questions.

1 Like
6

Yep, CommandBox has first class support for Java system props and OS env vars via the ${name:default} syntax. And for local dev (which we use CommandBox for) we couple it with the commandbox-dotenv module which allows us to create portable .env files to store developer-specific env vars in. Then in stage or production when we wrap up our sites in Docker, we just use Docker secrets. Lots of ways to put it all together.

7

Interesting… where do you store the .env files? Do they work on Windows? How are the variables applied? Through commandbox?

8

where do you store the .env files?

In the webroot (picked up by convention). This is standard in a lot of tooling like Docker and even PHP Laravel.

Do they work on Windows

Yes, of course.

How are the variables applied

As system settings in the shell if you start the CLI in a directory containing an .env file and as well as JVM props in your server if you start a server which has an .env file in the web root.

Through commandbox?

Not sure what you mean there, but the dotenv module is a CommandBoxl library made to do awesome things inside CommandBox assuming you’re using CommandBox :slight_smile:

Read up here:

1 Like
9

Since Lucee 5.x you can avoid creating that system object each time and instead access environment variables directly from the server scope, under server.system.environment.*. That means your above code could be written like this (also making use of Lucee 5.1 safe navigation ?. to behave the same way as system.getEnv() returning null for non-existent environment variables);

variables.dsn = server.system.environment.MYSITE_DSN);
this.datasources[variables.dsn] = {
	"class": server.system.environment?.MYSITE_DSN_CLASS),
	"connectionString": server.system.environment?.MYSITE_DSN_CONNECTIONSTRING),
	"database": server.system.environment?.MYSITE_DSN_DATABASE),
	"driver": server.system.environment?.MYSITE_DSN_DRIVER),
	"host": server.system.environment?.MYSITE_DSN_HOST),
	"port": server.system.environment?.MYSITE_DSN_PORT),
	"type": server.system.environment?.MYSITE_DSN_TYPE),
	"url": server.system.environment?.MYSITE_DSN_URL),
	"username": server.system.environment?.MYSITE_DSN_USERNAME),
	"password": server.system.environment?.MYSITE_DSN_PASSWORD)
}

We generally use application code and environment variables to configure almost everything. The one remaining exception for some of our applications is certain types of mappings that are placed in the lucee-web.xml.cfm (which doesn’t change per environment so it’s not too much of an issue).

3 Likes