Is it possible that someone can take a look at thi...
# docker-commandbox
b
Is it possible that someone can take a look at this ticket https://ortussolutions.atlassian.net/browse/COMMANDBOX-1621 ? We're stuck at docker image 3.7.3 (commandbox 5.8.0) and we cannot move forward at the moment.
j
Which image have you tried this on that is greater than 3.7.3, which is really outdated?
Also, do you have a server.json file that is in the route, which might be changing the JVM, or doing things with the system tray?
b
We have tried there docker images: 3.8.5 and 3.9.3 Yes we have a server.json that changes the used jvm, we try to use the most up-to-date version
I can't confirm for sure, but I rememember testing without that jvm version argument in the server.json, and I believe that was working.
j
You shouldn’t need to customize the JVM in a docker image, because that just adds bloat to your image and there are already a bunch of flavors of the JDK already being built
d
I had an issue when trying to force the JVM version in commandbox, it was installing the apline version of openjdk which obviously doesn’t work on the ubuntu based image. It only did this when getting the arm version of command box (which was ubuntu only) for my mac. I believe there is an alpine arm version now. The main issue was commandbox was grabbing the wrong version of openjdk if you forced it - don’t know if it is fixed now. The “work around” was to use the specific jdk tagged command box container
b
Confirmed: if we remove the "javaVersion" from the jvm settings, everything works fine.
@dougcain gives a very accurate summary of the problem 🙂
d
I found using the jdk tagged container worked best. If I pre-warmed my “forced” jdk container it tried to download the jdk again on startup which kinda defeated to object. So go with @jclausens carefully curated versions if you can, I know he spends a lot of time and effort sorting this stuff out.
obviously be nice if the forced version worked as expected on arm though 🙂
b
@birdy1980 Can you send me a pull that corrects the logic?
I don't have a Mac, let alone an M2 processor
And I don't know why your OS would report the OS as Alpine if it's not
Let me know what it needs changed to
j
I don’t have an ARM Mac so docker will pull the x86 version on my machine. The following command run on a Mac ARM machine should tell you what is causing the false detection of an Alpine Distro.
docker run —rm -it ortussolutions/commandbox:3.9.3 /bin/sh -c "cat /proc/version"
👍 1
d
I get this on my commandbox 3.9.3 running an m1 mac
Copy code
# cat /proc/version
Linux version 6.6.32-linuxkit (root@buildkitsandbox) (gcc (Alpine 13.2.1_git20240309) 13.2.1 20240309, GNU ld (GNU Binutils) 2.42) #1 SMP Thu Jun 13 14:13:01 UTC 2024
# box info

****************************************************************************************************
*                                         About CommandBox                                         *
****************************************************************************************************
*                                                                                                  *
*                                                                                                  *
*  CommandBox Version: 6.0.0+00787                                                                 *
*  CommandBox Authors: Brad Wood, Luis Majano, Denny Valiant                                       *
*  CommandBox Binary   /usr/local/bin/box                                                          *
*  CommandBox Home     /usr/local/lib/CommandBox                                                   *
*  CFML Engine:        Lucee                                                                       *
*  CFML Version:       5.4.4.38 stable (Gelert)                                                    *
*  Java Version:       11.0.23 (Eclipse Adoptium)                                                  *
*  Java Path:          /opt/java/openjdk/bin/java                                                  *
*  OS Username         root                                                                        *
*  JLine Terminal      org.jline.terminal.impl.PosixSysTerminal                                    *
*  Runwar Version      5.0.0 (/usr/local/lib/CommandBox/lib/runwar-5.0.0.jar)                      *
*                                                                                                  *
*                                                                                                  *
****************************************************************************************************
Copy code
# cat /etc/*ease
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=22.04
DISTRIB_CODENAME=jammy
DISTRIB_DESCRIPTION="Ubuntu 22.04.4 LTS"
PRETTY_NAME="Ubuntu 22.04.4 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.4 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="<https://www.ubuntu.com/>"
SUPPORT_URL="<https://help.ubuntu.com/>"
BUG_REPORT_URL="<https://bugs.launchpad.net/ubuntu/>"
PRIVACY_POLICY_URL="<https://www.ubuntu.com/legal/terms-and-policies/privacy-policy>"
UBUNTU_CODENAME=jammy
#
b
@dougcain Are you saying your machine is not running Alpine, despite reporting
gcc (Alpine 13.2.1_git20240309)
?
d
yip - it’s the standard arm commandbox which is ubuntu but seems to report alpine
b
Chat GPT says
This situation typically occurs in containerized environments where the base image might use a different distribution than the underlying host. The kernel might be from a LinuxKit environment used by Docker, but the userland (the utilities and libraries) is from Ubuntu.
To summarize:
Kernel and build environment: LinuxKit with Alpine components.
Userland (OS): Ubuntu 22.04.4 LTS (Jammy Jellyfish).
So, this system runs an Ubuntu userland on a kernel that may have been built using Alpine tools in a LinuxKit environment.
I'm unclear which version of Java should be used in this case
d
it works fine for me with jdk11 thats part of the command box build which I guess is the ubuntu version
the alpine version defo doesn;t work - had that issue when trying to force jdk 21 for boxlang
b
What do you have in
cat /etc/os-release
I don't know all the crazy ins and outs of how these linux versions work, so I'm just waiting for someone to tell me what/how to detect it 🙂
d
Copy code
cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.4 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
b
Send the pull
I'll merge it 🙂
I don't know if
/etc/os-release
exists on every linux distro, but perhaps we check that first
As a control in the experiment, do we know what that file has on an actual Alpine machine?
d
please hold….
j
> I'm unclear which version of Java should be used in this case > I would be too. Not only are you dealing with detection of the OS but also the arch. 😬 For the latter, you could look in to using
arch
or
uname -m
https://ioflood.com/blog/arch-command-in-linux/#:~:text=Use%20the%20'arch'%20command%20as,m'%20command%20as%20an%20alternative. For ARM, the JDK also needs to have the the architecture in the version, like so: https://cfml.slack.com/archives/C06TSRXCJ/p1719408806831289?thread_ts=1719248018.085809&channel=C06TSRXCJ&message_ts=1719408806.831289
b
CommandBox's current arch detection is here (and based almost entirely on java system properties) https://github.com/Ortus-Solutions/commandbox/blob/development/src/cfml/system/services/JavaService.cfc#L134-L143
👍 1
d
@bdw429s looks like /etc/os-release may be a better test - from the arm64 image of ortussolutions/commandbox:boxlang-alpine
Copy code
/app # cat /etc/os-release
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.19.2
PRETTY_NAME="Alpine Linux v3.19"
HOME_URL="<https://alpinelinux.org/>"
BUG_REPORT_URL="<https://gitlab.alpinelinux.org/alpine/aports/-/issues>"
b
Sorry guys for being silent for a few days, I got the flu 😞 ....
You seem to have nailed down this problem 👍
d
I did a pull request which I “think” would solve it but couldn’t figure out how to test it as it really needs to be built in the context of the docker container - https://github.com/Ortus-Solutions/commandbox/pull/334
b
well, you can test my fix on the bleeding edge of CommandBox
I don't have a great way to test it
b
how can we get the BE commandbox in a docker container?
b
You can just download the
box
binary and overwrite the existing one
b
Am I looking in the right place? https://downloads.ortussolutions.com/#/ortussolutions/commandbox/6.0.1/ which download should it be?
box-thin
?
d
I think you may have to build the commandbox container from scratch with the BE commandbox as I think when it starts the OS is persisted somewhere?
b
I would like to help to test this, but i need a bit more instructions on how to get a docker container with the BE commandbox in it. I have figured out how to copy files into an existing container, but I don't know exactly which box file to download. Can I get some more pointers?
b
@birdy1980 Yep, that's the right folder
You want the
bin
file for *nix
Thin is something different entirely. It's the bootstrap executable without all the jars bundled in for the purpose of shrinking Docker image down
Also FWIW, I will be bumping the version from
6.0.1
to
6.1.0
before I release.
j
@birdy1980 To use the above to update an existing docker image:
Copy code
FROM ortussolutions/commandbox

RUN rm -rf ${BIN_DIR}/box ${BIN_DIR}/commandbox.properties $COMMANDBOX_HOME
ENV COMMANDBOX_VERSION 6.0.1
RUN ${BUILD_DIR}/util/install-commandbox.sh

... do more stuff here if you need to ...
😃 1
b
ooh, nice
b
should I worry about this
... do more stuff here if you need to ...
? I have never build new docker images... If I use the new build image my application doesn't start anymore
CFConfig couldn't find the CF Home for [from] CommandBox server [studiemeter-lucee]. Please give me a hint with the format parameter
I have set these 2 variables in my docker-compose.yml
Copy code
environment:
  - APP_DIR=/app/htdocs-studiemeter
  - BOX_SERVER_APP_SERVERHOMEDIRECTORY=/opt/commandbox/studiemeter
Do I have to do something with those variables in the
dockerfile
?