CommandBox on Production

Hello!

I start today to use CommandBox, it is awensome!!!

For a new website I would like start a new instance of lucee, instead to install a new instance on Tomcat (with Lucee) I would start a Lucee instance with CommandBox.

I configure IIS for web server

The question is: Is CommandBox test for production use?
There is some configuration to modify (besides the usual ones heapSize, ecc)?

Thank you Ortus!

Hi and welcome to CommandBox. Yes, CommandBox is tested for production use and is being used in production right now. All the ortus sites like coldbox.org, ortussolutions.com, and forgebox.io are Docker powered by our CommandBox-based docker images. We also have many clients using CommandBox inside of Docker and even on it’s own just installed in a Windows VM or Linux VM for production hosting. It’s way easier to setup and manage than a standard installation since the settings are very self contained in server.json and you can script out your datasources, etc with CFConfig:

https://cfconfig.ortusbooks.com/introduction/getting-started-guide

Even if you don’t front CommandBox with a web server like IIS, it is very capable and fast. I compared IIS, Apache, and CommandBox serving static files like js, css, etc under extreme load and found the throughput and response times to be just as fast. Part of this is because we use a very fast and lightweight web server called JBoss Undertow.

Regarding configuration to modify, the typical things apply here the same as a normal server. You can configure every setting including JVM args, heap size, directory listing, etc. You can see an overview of everything here:

https://commandbox.ortusbooks.com/embedded-server/server.json

And with CFConfig, you can even script your own lockdown settings in Lucee. Let us know if you have any other questions.

Hi Brad,
thank you for response!

Hi and welcome to CommandBox. Yes, CommandBox is tested for production use and is being used in production right now. All the ortus sites like coldbox.org, ortussolutions.com, and forgebox.io are Docker powered by our CommandBox-based docker images. We also have many clients using CommandBox inside of Docker and even on it’s own just installed in a Windows VM or Linux VM for production hosting. It’s way easier to setup and manage than a standard installation since the settings are very self contained in server.json and you can script out your datasources, etc with CFConfig:

https://cfconfig.ortusbooks.com/introduction/getting-started-guide

Very interesting!
I try it immediately

Docker image it was the next question :slight_smile:
I will use Docker image to run CommandBox, CommandBox start a Lucee instance (with cfconfig ecc). It is correct?
Do you have some link/script to help me to start Lucee instance on Docker image startup?

Even if you don’t front CommandBox with a web server like IIS, it is very capable and fast. I compared IIS, Apache, and CommandBox serving static files like js, css, etc under extreme load and found the throughput and response times to be just as fast. Part of this is because we use a very fast and lightweight web server called JBoss Undertow.

I use IIS for:

  • lockdown Lucee deny access to /lucee/** for ALL IP except my IP

  • log all request

  • binding multiple site on same IP on port 80

  • SSL

Is it possibile with Undertow using server.json?

Thank you!

Hi Brad,
I have try CommandBox Docker image on my Windows Server 2016 on Azure but it’s show an error.

I run this:
docker pull ortussolutions/commandbox

The output is:
Using default tag: latest
latest: Pulling from ortussolutions/commandbox
image operating system “linux” cannot be used on this platform

The CommandBox Docker image run only on Linux environment?

Thank’s

Emanuele,

You just need to switch your Docker settings over to use Linux containers in your Docker GUI. Then it will run on Docker for Windows. At this time we aren’t supporting a Windows OS container.

The latest beta of Docker EE for Windows allows you to run both Windows-based and Linux-based containers simultaneously by using a --platform argument to the docker run command: https://blogs.msdn.microsoft.com/premier_developer/2018/04/20/running-docker-windows-and-linux-containers-simultaneously/

Thanks,

Jon

Docker image it was the next question :slight_smile:
I will use Docker image to run CommandBox, CommandBox start a Lucee instance (with cfconfig ecc). It is correct?
Do you have some link/script to help me to start Lucee instance on Docker image startup?

This is all handled for you in our Docker images which are very full featured. You use the same server.json from CommandBox in your docker images. CFConfig also comes preloaded into our docker images and we have several conventions you can use to control how it is loaded.

There’s a bit of good documentation here on this page:

https://hub.docker.com/r/ortussolutions/commandbox/

Some more here in our docs:

https://commandbox.ortusbooks.com/deploying-commandbox/docker#commandbox-docker-deployments

And we did an entire free online roadshow last year devoted to Docker:

https://www.ortussolutions.com/events/container-roadshow-2017

If you need personalized help, we offer support consultancy as well.

  • lockdown Lucee deny access to /lucee/** for ALL IP except my IP

You should also be able to accomplish this with rewrite rules which CommandBox supports via Tuckey. I’d need to check on the IP restriction. Out Docker containers even have a HEADLESS flag you can set that auto-locks this down. You don’t use a web admin UI on a production docker deploy anyway. CFConfig handles that all for you.

https://commandbox.ortusbooks.com/embedded-server/configuring-your-server/url-rewrites

  • log all request

CommandBox 4 supports “common format” access logs:

https://commandbox.ortusbooks.com/embedded-server/server-logs#access-log

Here’s a screencast that covers them:

https://www.youtube.com/watch?v=rEtW3wG-nrE

  • binding multiple site on same IP on port 80

For local dev, use the commandbox-hostupdater plugin. It edits your host file for you and uses a different 127 IP address for each site so they can all listen on port 80 even though each site is a different process.

https://forgebox.io/view/commandbox-hostupdater

  • SSL

You can use SSL certs with CommandBox too:

https://commandbox.ortusbooks.com/embedded-server/configuring-your-server/server-port-and-host#https

That’s not to say you can’t or shouldn’t use a web server. We use Nginx just because we like it and it handles static files for us from our internal file share, but we’ve also made CommandBox to be a very capable and robust web server out of the box.

Thank you Jon and Brad.

All information is very useful.

Last question I would like enable debugging and add 2 scheduled tasks but i don’t found there settings on Config Items - CFConfig Documentation

For scheduler a work arount is add cfscheduler on onServerStart the is another option?

For enable debug?

Thank’s

CFConfig supports scheduled tasks in Adobe because a paying client sponsored that work. I haven’t implemented scheduled tasks in Lucee yet, mostly because I never really use them personally. There is someone who told me they were working on it and would send a pull request. We’ll see if that happens. If it’s super important to you, you are welcome to take a stab at it yourself.

The debugging settings are all supported on Adobe (again, another client paid me to add that) but I haven’t finished adding support for the debugging settings in Lucee-- mostly because I don’t use them-- FusionReactor give me everything I need and I never deploy containers with debugging settings enabled anyway. For local dev, I just log into the web admin and enable them when I need them. I have an open ticket to add support for the Lucee debugging settings into CFConfig and someone else told me they may send a pull to add support for it. If not, I’ll probably get them added soonish. If someone wants to sponsor the work, I’ll add them tomorrow :slight_smile:

Hello,
little feedback after one month on production with Commandbox + Lucee.

The environment is stable! Perfect :slight_smile:

I have IIS + Boncode + Commandbox + Lucee 5.2.7.63

I configure start of commandbox as service like https://www.ortussolutions.com/blog/screencast-starting-commandbox-servers-as-a-windows-service

For scheduled task I use cfscheduler onApplicationStart

I have 2 questions:

  1. on task manager I see 2 “Java Platform SE binary” running. I think one is the server (server start) and one is commandbox. Is it possible start only server and stop commandbox? I use nssm.cc to install service.

  2. lucee logging is empty. On lucee/admin “server > Settings - Logging” there isn’t log enabled, the page is empty (create new log). On “server > Settings - Logging” is the same.
    I see this “issue” on 2 server. how can I enable the standard logs? I must set something on commandbox?

Thank you!

For future development can be useful, command “install service server ServerName” without use nssm.cc :wink:

little feedback after one month on production with Commandbox + Lucee. The environment is stable! Perfect :slight_smile:

That’s excellent. Thanks for reporting the good news!

on task manager I see 2 “Java Platform SE binary” running. I think one is the server (server start) and one is commandbox.

That’s correct. One java process is the actual server and the other is the CLI start command that waits and streams back the output to the server and also stops the server when the Windows service stops. Normally, if you just start a normal server and don’t use the “–console” flag, then the server is started up as a second process that is detached from the CLI process and then you can stop the CLI entirely and the server just keeps running in the background. However, the problem with doing that from a Windows service is the NSSM service only “holds onto” the initial binary that it starts so if you don’t do a console start, NSSM will think the server has stopped as soon as the “start” command finishes running. Furthermore, you wouldn’t be able to stop your server with the windows service since it no longer has a reference to the actual server. Generally, the CLI process is very small and only takes a bit of RAM so you don’t notice it. It’s just there to monitor the actual server.

Is it possible start only server and stop commandbox

Sure, you could do it if you wanted. You’d have to use “server info” on a started server and copy the full list of JVM args that were used to start up the server and then configure NSSM to just run those directly and completely bypass the entire CLI. I’ve never done it, but in theory it would work fine. There are some things that wouldn’t work though. For starters, the server’s status might not get updated. Secondly, changing settings in your server.json, etc wouldn’t take effect since you would have basically “locked in” the exact JVM args.

Sorry for delay…

on task manager I see 2 “Java Platform SE binary” running. I think one is the server (server start) and one is commandbox.

That’s correct. One java process is the actual server and the other is the CLI start command that waits and streams back the output to the server and also stops the server when the Windows service stops. Normally, if you just start a normal server and don’t use the “–console” flag, then the server is started up as a second process that is detached from the CLI process and then you can stop the CLI entirely and the server just keeps running in the background. However, the problem with doing that from a Windows service is the NSSM service only “holds onto” the initial binary that it starts so if you don’t do a console start, NSSM will think the server has stopped as soon as the “start” command finishes running. Furthermore, you wouldn’t be able to stop your server with the windows service since it no longer has a reference to the actual server. Generally, the CLI process is very small and only takes a bit of RAM so you don’t notice it. It’s just there to monitor the actual server.

I run some test and show the result.

Is it possible start only server and stop commandbox

Sure, you could do it if you wanted. You’d have to use “server info” on a started server and copy the full list of JVM args that were used to start up the server and then configure NSSM to just run those directly and completely bypass the entire CLI. I’ve never done it, but in theory it would work fine. There are some things that wouldn’t work though. For starters, the server’s status might not get updated. Secondly, changing settings in your server.json, etc wouldn’t take effect since you would have basically “locked in” the exact JVM args.

Thank you

lucee logging is empty. On lucee/admin “server > Settings - Logging” there isn’t log enabled,

Hmm, I’ve never heard of this before. Are you using CFConfig? If so, does your CFConfig JSON file have settings for the log files in it? Can you send me a screenshot of what you’re seeing? I don’t generally mess with the Lucee log settings so perhaps I’m just not familiar with the issue.

yes I use CFconfig, there is only “adminPassword”.
This is the screenshot of logging page on server admin:

The wed admin is same…
Does anyone know how to restore the default logs?

Thank you!

A note on that “server info” command. You’ll need to add the –verbose flag to it to see the JVM args.

server info --verbose

You’ll also see the JVM args if you do a –debug start.

server start --debug

Regarding the loggers missing, I think this is a bug in CFConfig. The ability to import logger configuration was a recent addition someone sent me a pull request for and reviewing the code again right now I see that it is wiping out any existing loggers before importing the new ones from the JSON file. That means that if you have no loggers in your JSON file then it will erase any there.

I just fixed this and pushed a new version of CFConfig. Update your system modules to get it.

install commandbox-cfconfig --force

To get your loggers back, forget the server and restart it so it comes back fresh.

server stop
server forget
server start

Note, this will remove any other settings in your admin that you haven’t exported to your JSON file.

Hello Brad,
I reinstalled CFConfig and recreate server and now I see all logs!

Thank you.

It would be great if there was a ‘boilerplate’ repo like this https://github.com/foundeo/ubuntu-nginx-lucee which was configured for commandbox in production without Docker. Things like this I feel would help with CF traction as well.

If u look at the 600 script, CommandBox gets installed. :wink:

If you want to use CommandBox without or without Docker & with or without NGinx, you could just use the scripts you foundeo already, pun intended.

Unless I’m missing something :thinking:

Thanks Adrian! Totally didn’t see that.

I still think something like this could be done and available as part of the commandbox website. Just seems like there is something missing there in terms of simplicity instead of fishing around google and github.

Our Ortus docker images are basically drop-in ready with CommandBox. All you have to do is map your volume and docker up.

docker run -p 8080:8080
-p 8443:8443
-v “/path/to/your/app:/app”
ortussolutions/commandbox

As far as a non-Docker context, there’s really no requirements outside of having the box binary downloaded. If you use a Mac for example, the full unabridge steps to have a running CF server on a brand new machine using Homebrew are

brew install commandbox
box server start

That’s really it. There’s a 1000 way you can customize that server, but that’s all it takes just to stand up a web server anywhere.

Looking at the scripts you reference, I’m not entirely sure what you’re asking for. If you’re looking for a provisioning script for a Linux server, using CommandBox to serve traffic, that’s easy enough to provide and you could even use the Docker Debian build to get all of the commands, in sequence.

That said, if I were interested in standing up a traditional server, running multiple CFML sites, I’d probably do something like Pete and stand up Lucee/Tomcat with Apache or NGINX (e.g. use Pete’s scripts), so that you can run multiple apps ( web contexts) off the same server instance. Commandbox doesn’t make that easy and, if you’re standing up a traditional hardware instance of VM, then you’re “marrying” yourself to that server, anyway.

The latter, however, is why we choose Docker. Portability equates to flexibility and apps become hardware and location-agnostic as a result. I’m not trying to convert you. :slight_smile: Just explaining why we funnel our limited time and resources towards improving containerization, rather than hardware provisioning.

Jon

– You received this message because you are subscribed to the Google Groups “CommandBox” group. To unsubscribe from this group and stop receiving emails from it, send an email to . To view this discussion on the web visit .