Hi all, long time no speak. I'm using the commandb...
# docker-commandbox
m
Hi all, long time no speak. I'm using the commandbox docker image to run some background tasks (using Task Runners) but I'm not seeing any output to the docker logs (I first used the built-in
job.addLog()
) but figured I don't need to see it on the console, so I changed those to
writeLog()
. It gets logged to the lucee log files in
/usr/local/lib/CommandBox/engine/cfml/cli/cfml-web/logs
now, but I don't think that's right, I think Docker likes it if things get logged to
stdout
but have no idea how to do that. Any ideas?
a
Can you register
/dev/stdout
as a log? Or Lucee had a function
systemOutput
or something that is like
writeOutput
except writes to
stdout
. On a train and on my phone so will leave it to you to google
m
Oh right, yeah I tried that function before in another branch of my trial and error tree :)
a
Did it not do what you needed? :⁠-⁠(
m
Not in that branch, when I was still trying to get the job.addLog thing to work.
b
@mjhagen How exactly are you running the task runners?
A Linux machine does not just have a single standard output! Every process running on that machine has a standard out ( and standard in, and error out)
The docker containers logs are essentially the standard out of the PID 1 process that was run as part of the container start (The
CMD
in the DockerFile)
Now, inside of a container, you can spawn as many additional processes as you like. Those processes all have their own standard out, but it doesn't mean it's the same as the standard out of the main docker process and therefore won't necessarily show in any Docker logs
When I run a CommandBox task runner in Docker, I generally use
foundeo/minibox
(the Ortus image is really custom-designed for servers only) and I run
box task run ...
as the
CMD
of the actual container and works fine
m
ooh, let my try that, thx
b
On a related note, you may notice that many of CommandBox's UI widgets take a default width of 80 chars when run headlessly which can be annoying if you're using interactive job output, or
print.table()
stuff. I'll usually override it by setting the
terminalWidth
config setting to something like
200
Which you can do inside your task with
Copy code
configService.setSetting( 'terminalWidth', 200 );
or as an env var like
Copy code
box_config_terminalWidth=200
👍 1
m
hmm, that image doesn't run on M1 Macs, looking into some other options first before I see if I can maybe update it.
b
What image doesn't run? minibox?
m
yeah
b
That's odd, I would have expected it to
@foundeo Do you have ay testing with this?
You M1 people always mess everything up 😆
m
it looks like it uses Java8 from a specific image:
azul/zulu-openjdk-alpine:8-jre
b
Ah yes, he uses that Azul built because it's like 40 MB or something
m
First I have to make my SO some coffee, I'll look at it a bit later.
b
Worse case scenario, just drop
box
onto your favorite M1-compat base image with a simple docker file
Minibox is handy not because it bundles a bunch of stuff, more that it's just super tiny and ready to use
m
Yeah it sounds like it’s exactly what I need.
It’s for a straggler task cfc that just needs to work for a bit longer before it gets replaced with the new microservices thing.
b
Right-O. I love running task runners in docker. Both as one-offs and long-running daemons like RabbitMQ listeners
m
It seems to work now with the systemOutput function. I tried to build my own version of @foundeo's minibox with an M1 compatible JRE but it kept getting stuck on things in the Dockerfile and gave up on it for now (as I don't need it for production, just dev at the moment).