Lucee 5.4 feedback; Docker and Heroku

markdrew · June 27, 2018, 6:14am

Very timely joke tweet:

https://twitter.com/sadserver/status/1011652439303262208?s=21

Jamie_Jackson · June 29, 2018, 3:35pm

It’s great that I can drop a *.lex into the deploy directory, but it really stinks that the installation process is so “secretive” that one can’t know it’s finished but through trial-and-error heuristics.

Sure, I solved the CFSpreadsheet installation puzzle a while back (after probably 8 hours of total effort spent after using other methods proved less than 100% reliable), but now I’m about to play with redis, and I dread figuring out what time and black magic I’ll encounter with the effort.

I really hope somebody responds to this and tells me that I’ve missed something, and that third-party extension installation is actually straightforward.

gist.github.com

https://gist.github.com/jamiejackson/f091c410723cae78ff4eb642b08ad592

Dockerfile

FROM lucee/lucee52:latest

ENV DEPLOY_DIR=/opt/lucee/server/lucee-server/deploy

WORKDIR $DEPLOY_DIR
RUN echo download to deploy dir \
  && curl -O https://raw.githubusercontent.com/Leftbower/cfspreadsheet-lucee-5/master/cfspreadsheet-lucee-5.lex
  
RUN ls -al "$DEPLOY_DIR" \
  && echo "warmup plugin" \

This file has been truncated. show original

README.md

Update: I have a universal, albeit convoluted, method for installing plugins: https://github.com/jamiejackson/lucee5-install-extensions

I'm trying to demonstrate that it is painful to install third-party extensions in Lucee images, because Lucee doesn't provide a way to know when/whether extension installation is complete.

After you've spent hours cobbling reliable test for installation completion, some extensions might not be too hard to reliably install. However, each new one (I'm looking at the redis extension now) is its own animal, and each one is a time sink.

To run this example:

# Docker Compose

This file has been truncated. show original

docker-compose.yml

version: '3.6'

services:
  luc:
    build:
      context: ./
    container_name: lucee
    ports:
      - 8888:8888

Zackster · July 13, 2018, 4:27am

I’d like to see consideration to making all the web admins available under a single url.

With with cdn/proxies, clustering, load balancers etc it can become rather tricky to access
a web admin, especially when locking down access to the lucee admin via ip address.

https://luceeserver.atlassian.net/browse/LDEV-924

justincarter · July 13, 2018, 4:41am

In our Docker clusters we go the opposite way, we have no reason to ever allow access to the Lucee admin and so we want it to be completely disabled/unavailable in production environments. It would be great to have a build where it’s simply not present at all, or at the very least can be completely disabled by an environment variable, rather than removing mappings or using the web server to secure it

I can see how that ticket might be useful to server installs with many apps in a single Lucee instance, but in a container environment I think it’s less useful as each app runs in it’s own container. Exposing the admin is generally a bad idea, but particularly with Docker then configuration should come from the image and the environment, rather than twiddling settings in the admin.

Jamie_Jackson · July 22, 2018, 2:25pm

My newer plugin installation approach:

dawesi · July 27, 2018, 1:29pm

Love the ideas:

admin as a plugin that is not activated by default
Single signin page for web (aka 1 uri for server, 1 uri for all webs)
No phone homes
Docker Windows Nano (or at least core) containers:

Would love to see an official Windows Server 2016 Nano (or at least core) (and shortly 2019) docker image (iis/lucee)… at lot of CF installs are on windows, so it would make the journey easier for MS shops and those who prefer windows. Choco + Commandbox included.