I've had very good experiences with the debain/ubu...
# lucee
d
I've had very good experiences with the debain/ubuntu httpd apache package installer. Security packaging was always just a matter of
apt update ; apt upgrade
The only issues were upgrading from 1.1 to 2.0 decades ago and the issues were small, explicitly documented and required the explicit removal / install of 1.1 and 2.0 I'm therefore inclined to apt install the ubuntu 22.04 LTS openJDK and tomcat (9) packages , and drop the lucee WAR in the right place. I'm not inclined to use the Lucee all-in-one .run installer as it doesn't seem like it is available for the last 2 stable versions of lucee and my sense is that the 100s of canonical (ubuntu) employees and Debian volunteers are in a better place to update their openJDK and tomcat packages. Holding me back slightly is the prospect of creating the re-write rules and (?) other config by hand A googled thread suggests that as of march, Lucee doesn't yet support Tomcat 10 , so the fact Tomcat 10 isn't a package in stock ubuntu until ubuntu 2023.04 and 2024.04 LTS isn't a big deal. Opinions ?
s
Haven't used a lucee installer in years. Commandbox is the best solution for deployment. Even if you don't use commandbox to actually run the engine, you'll want to use it for cfconfig so you aren't doing config by hand.
👍 1
q
I honestly haven't done many raw installs of Lucee in recent years either. Model I've been going with is Docker, which helps keep the dependencies down and makes the install a lot more portable.
👍 1
s
yep, all ours are docker. still have to deploy the engine though, so it's commandbox in docker
q
sknowlton: any reason why you aren't using the Lucee docker images?
s
Because the thing actually doing the deployment work for us is commandbox. Lucee is just the WAR Commandbox pulls in that happens to be our app engine. Doesn't make sense to add commandbox to the Lucee images, which (last I looked) expect you're using Tomcat. Commandbox uses undertow, which is smaller, and lighter
q
fair enough. I see a lot of people who are pushed into doing the commandbox docker image just for docker, rather than use the official image.
d
@quetwo , I've not done much with docker and am slightly inclined to less learning, but perhaps this is false laziness. We do run all our rails stuff throw gitlab docker swarm CI/CD , so the team has experience there. @sknowlton The tiny bits of commandbox docs I've skimmed made me think command box was something you ran in a terminal for development. and killed with control-c , no systemd process management. Obviously I need to look a little closer. 😆 Also what are the undertow / lucee+docker security patching stories?
s
I don't think anybody is 'being pushed,' it's just a tool built especially to manage deployments. The lucee images solve the deployment problem another way but IMO there is no advantage to that solution compared to commandbox
q
And when I say pushed -- there is a small but very vocal group that talks about CommandBox as the only solution 🙂
s
🤷🏻‍♂️ I have to manage a number of CF deployments personally and I haven't seen an alternative that comes close. But I also don't really think the official lucee images are trying to do that. They're just trying to be an official avenue for using Lucee that doesn't require a 3rd party tool. No harm in that.
If they made it easier to do what we need to do, we'd use them
q
I've deployed several dozen customer's sites via the official docker image. It's actually pretty slick to manage and works well on most K8/Docker solutions out of the box without any futzing.
only thing that required any touching was datasources for people who only deployed that via the administrator. but that's copy/paste one line into the app config and it's good to go.
e
Opinion Only: Tomcat is a workhorse and the enterprise-level sector has millions of Tomcat servers. Ubuntu has a nice GUI but for server command line operations, it's just Debian bleeding edge testing ring software, with all the bugs and a few new ones. RHEL is used by Gov / Enterprises including Microsoft. Commandbox is great for dev & small sites but you would be hard-pressed to find a bank or publically traded company using undertow or what was jboss to run anything. Netflix and a few other very busy sites use FreeBSD and run Tomcat (or name your service engine). If it's a small site, you do not care if it does or doesn't crash, keep it easy for your own sake. If you have the time, need or resources, I would look at an enterprise level solution.
s
The trouble isn't really with Tomcat itself but with the fact that you're bundling the servlet engine with the app engine. You get the below type of situation where you're waiting on vendor A to update vendor B's stuff. This is nominally still the case with Commandbox but I will put Ortus' track record of applying critical updates against any other product in the CFML sector. The 'look at an enterprise solution' is really an argument against CF in general and not Commandbox in particular. "Enterprise" solutions includes everything from modern projects at-scale (of which Ortus has done several, including the DoD) and ancient, creaky sites written in CFML a decade ago that get dragged through the years using whatever the current version of the thing they were first deployed on was. I've never heard of a scenario where some deployment of any size was hamstrung by Undertow. But that's not a knock on Tomcat. Tomcat is going to be more powerful (in some sense) but also a lot less lightweight and harder to work with. Undertow just does the job and gets out of the way but still lets you tweak anything that has needed tweaking in 10 years of using it in our shop. I've never once missed Tomcat but used to spend a lot of time dealing with it, even if the problem was often CFML-specific configuration and not Tomcat itself. I know there have been some significant deployments with Lucee and (I expect) the native docker images in Europe. If you're used to Tomcat and/or just have some reason to prefer it or native images, OK, you'll be fine. You'll get less help around here because there is less incentive for most people to go this route and we all prefer the path of least resistance. We also all educate ourselves with the parameters we have to deal with in our different workplaces in mind, and different parameters can and should lead to different conclusions even if there is some general amount of advice suggesting an alternative. Popular does not automatically equal appropriate, which we all know since we're here on a CFML Slack. 😀 The notion that anybody gets 'pushed' in one direction or another is difficult to take seriously, as though any of us have a personal interest in whether somebody on the Internet uses Tomcat or Undertow. Ortus has a commercial interest I guess, but I'm not part of Ortus and I just like saving time on things. YMMV, doesn't bother me any!
r
Quetwo is modest by not mentioning the Docker tutorial he did two weeks ago for Mid-Michigan CFUG. I've told him it is one of the best presentations that he has ever done for the group. Don't be put off by the length, the last hour plus are troubleshooting demos and questions.

https://www.youtube.com/watch?v=fYQ-BBKir7Q▾

👍 2
e
@sknowlton Not here to argue, but is deployment size really an issue? Are we talking about the entire VM / Container or just the app engine or compressed app? Just not sure about what you are stating here. How is size a constraint?