Look into making a Docker image for APEX Nitro

[vincentmorneau]

Idea from Roel: https://twitter.com/RoelH/status/933673606344773632

shouldn’t APEX NITRO be available as a #Docker image? So you can get rid of the node and sqlcl dependencies …

Tasks:

• Documentation: /readme
• Documentation: /docker/readme
• Dockerhub proper location

[vincentmorneau]

Problem is: how do we expose the apex-nitro CLI to the host after the container is running?

This thread has a solution to a similar problem:

https://stackoverflow.com/questions/43472039/how-to-run-nodejs-command-line-tools-inside-docker is having a similar problem, but they are using docker exec as a way to all CLI commands inside the container. Not good.

[dralletje]

The CLI would be this container? The container wouldn't be running before you do apex-nitro launch, but it would start if you'd do so.

Other obstacles:

• You'd need to add the app files using a volume, but I'm not sure if they support watching files
• You'd need to add the node-package-configurator folder to the docker image (either using a volume or adding them when building the image)
• opn wouldn't work anymore, because it'll try to open the it inside of the container

What "dependency" is allowed? The first two could be done with a bash script,
but then it wouldn't work on windows (so it'd have to be written in .bat too).

# Module name would be the second argument in most (all?) cases
export $MODULE_NAME=$2
export $MODULE_FOLDER=`.${$MODULE_NAME}/`

if [ $APPDATA ]
then
  export $NODE_PACKAGE_CONFIGURATOR_FOLDER="${APPDATA}/${MODULE_FOLDER}"
elif [[ "$OSTYPE" == "darwin"* ]]; then
  export $NODE_PACKAGE_CONFIGURATOR_FOLDER="${HOME}/Library/Preferences/${MODULE_FOLDER}"
else
    export $NODE_PACKAGE_CONFIGURATOR_FOLDER="${HOME}/${MODULE_FOLDER}"
fi

export NODE_PACKAGE_CONFIGURATOR_FOLDER=
docker run \
  \ # Will mount the config folder at /node_package_configurator
  -v $NODE_PACKAGE_CONFIGURATOR_FOLDER="/app_home/${MODULE_FOLDER}" \
  \ # Will mount the app folder (assuming it is the working directory) on /app
  -v $PWD=/app \
  \ # We can, I think, assume nothing will be running, so ports will be 4000, 4001 and 4002
  -p 4000:4000 \
  -p 4001:4001 \
  -p 4002:4002 \
  apex-nitro "$@" # This will pass in all the arguments given to this bash script

In this example, the apex-nitro image will know it has to look in /node_package_configurator and /app for the config and app files. The image would have $HOME=/app_home set, for example.

There would be some more conversion or fiddling for setting the /app folder as source folder too,
and this is all assuming the source folder is (inside) the current working directory event.

If you'd like I can give this a try, but it seems like a far stretch

[vincentmorneau]

Thank you for these thoughtful considerations. You seem pretty knowledgable about both APEX Nitro & Docker, based on your acknowledgment of opn and node-package-configurator.

The obstacles are potentially game-breaking. If we are going to adopt Docker as an alternative to npm, it has to be simpler than npm.

Before going further, what is your opinion about all this?

[dralletje]

Thanks, hahaha :)

I think that in it's current form (using node-package-configurator) it will be hard, or at least more complicated than "just node/npm".

Now I made a small apex-nitro clone that uses a per-project configuration file, a file that is stored WITH the project (and would be sent to git).
You need to appeal to people coming from apex, so I guess that is why node-package-configurator is focussed on a graphical interface (instead of using a config file like more "node-y" projects), but I am unsure if it is wise to store the config file away from the project.

The docker approach would work a lot better (and make more sense) if a project could be configured once, and then replicated easily. Right now, that would mean copy-ing over the files from/to ~/Library/Preferences/.my-project on different computers, instead of having it as a apex-nitro-config.json in the project root.

If you'd decide to (make an option to) put the config file in the project, it would be pretty easy to make a docker image (the whole APPDATA part in the bash script could be skipped, only the project as a volume).
node-package-configurator could still provide a graphical interface, just that it saves the files relative to where it is called
(eg.

/Users/Michiel/Apex-Project $ apex-nitro config (--local?)

would create a config file /Users/Michiel/Apex-Project/apex-nitro-config.json (possible with a . for hiding)

/Users/Michiel/Apex-Project $ apex-nitro launch

would use /Users/Michiel/Apex-Project/apex-nitro-config.json if found and else fall back to $APP_DATA/.... if found
)

Problem with this approach, however, would be the fact you'd may not want to share your apex credentials. Maybe an (optional?!) extra file <Project>/apex-nitro-credentials.json, that would have to be gitignore-ed, could be used to circumvent that?
Possibly we could also not set the password in the config, and require the password filled in explicitly when calling apex-nitro publish <connection password>, but I don't know what would be considered "best practice" in the apex world ;)

I hope I am not making you read too many lines of text, hahaha, but I have a hard time keeping my comments compact 😂
If you'd go for an in-project config file, I'd be happy to make a docker image that could be used with a pre-configured project, and, as a second step, would also support configuring the project, with just a single command

$ docker run -v $PWD:/app -p 4000:4000 apex-nitro launch

(A lot simpler than the bash script earlier :D)

[dwarcake]

Maybe a bit off-topic here but...

Now I made a small apex-nitro clone that uses a per-project configuration file, a file that is stored WITH the project (and would be sent to git).

I like this. We are working with multiple developers on 1 project and exporting/importing the config is kinda stupid when you have a Git-repo.
Especially with big changes to the config file, it's not easy to keep everyone up-to-date.

Maybe discuss this in a separate issue?

[dralletje]

Maybe discuss this in a separate issue?

Sure thing!
Though docker support kinda depends on it... not sure how to express that dependency in github issues 😅

[vincentmorneau]

@martindsouza was there anything missing for full Docker support?