Deploying on a VM

This service is meant to run as a small Go process on a VM or VPS.

A simple setup is enough:

the Go binary
a local config.yaml
DCMTK binaries
MicroDicom files
a reverse proxy in front
a systemd service to keep the process running

Suggested layout

A plain layout is easier to operate:

app directory: /opt/dicom-iso
binary: /opt/dicom-iso/mkiso-server
config: /opt/dicom-iso/config.yaml
logs: journalctl through systemd
temp work: /tmp or another writable local path

What must exist before start

The service needs:

working DCMTK binaries
working PACS access
working patient API access
working CD publisher access
a real MicroDicom directory
a writable temp directory
a free port range for storescp

If you do not manage these assets globally on the VM, you can stage them locally first:

scripts/setup-dcmtk.sh --source-dir /path/to/dcmtk/bin --install-dir /opt/dicom-iso/dcmtk-bin
scripts/setup-microdicom.sh --source-dir /path/to/microdicom --install-dir /opt/dicom-iso/microdicom

Build note

The build environment cannot depend on public internet access. That means the binary must be built through an approved offline-friendly path.

Running the service

The simplest production shape is:

build the binary
copy the binary to the VM
place config.yaml next to it
install the systemd unit
start the service
put nginx in front of it if legacy paths are still needed

Rollback

Keep rollback simple:

keep the previous binary
keep the previous config
restart the old version through systemd

First checks after deploy

After the service starts, verify:

the process is running
the configured port is listening
/api/health responds
DCMTK paths are valid
MicroDicom path is valid
one real accession works end to end

Operational note

Real secrets must stay out of git. Only config.example.yaml belongs in the repo. The real config.yaml should be created on the VM.

2.0 KiB Raw Blame History