Why is mccommand getting removed?

[Loki-Afro]

first of all I'm not a mirth/nextgen connect expert at all ;)

But my question is why is mccommand removed during image build?

RUN rm -rf cli-lib manager-lib \
    && rm mirth-cli-launcher.jar mirth-manager-launcher.jar mccommand mcmanager

Background:

I wanted to import channel configuration and wanted to try it out if one can import channels with it. Otherwise one has to write an ugly wrapper script around mcserver to do some curls which don't seem that safe or are coupled with more hassle.

If you have a better Idea how to automatically import/create stuff after first startup of mirth can be done, please let me know!

[tonygermano]

You can run mccommand from another computer. It's just another client as far as mirth is concerned.

[Loki-Afro]

But this way I would need to create another Image, with a partly mirth installation, which imports the data into the real mirth container. Sounds way too much.

[narupley]

If you think it'd actually be helpful then sure we can add it back in. But how are you envisioning actually using it? You would need to open your terminal and then hook into a container shell through Docker to run mccommand inside the container right? How is that any improvement over just using mccommand on your local machine, or using the REST API directly?

[Loki-Afro]

Running a command inside a container is not an option, right.
Thats why I would extend your existing Dockerfile to set some basic stuff up.

Anyway I haven't played around with mccommand maybe its a dead end, I'll try it tomorrow or next week and let you know, maybe share some code ;)

[tonygermano]

The channel definitions are stored in the database. You can't import channels until after the mirth server is already running, so I don't think you'd get very far trying to extend the Dockerfile for this purpose.

If you are trying to start with a clean database every time you create a new container and are using derby for your database, you should be able to copy the appdata folder from a configured instance, which would contain the entire database, and include that in your Dockerfile.

The README for this project even recommends creating a docker volume for appdata so that it will persist between runs.

[tonygermano]

If you are using a different database besides derby (which you definitely should be for production,) you might look at what options the database container offers for restoring a backup of a configured instance at startup before your mirth container launches.

If you don't intend to start from an empty database on every run of a new container, then you don't need to do any of this. Just set up your database once and forget about it.