Os contêineres são considerados sem estado, o que significa que você precisará de etapas adicionais no processo para que isso funcione. A Condor adiciona essa funcionalidade para você, mas nunca achei útil e nunca funcionou corretamente quando a usei (da última vez em 2009). Para contornar isso, separei a transferência de dados da Condor. Para fazer isso, você precisará fazer o seguinte:
Seus arquivos de dados de saída precisam ser armazenados em um armazenamento de dados persistente de algum tipo e não no próprio container. Alguns containers permitem a montagem do disco direto do host ou até a montagem de um disco remoto pela rede (NFS, Samba, SSHFS, etc). No passado, usei um sistema de arquivos distribuído (ou montável em rede), como o AWS-S3, para lidar com esse requisito.
Quando trabalhei com a Condor em 2009 para minha tese de mestrado, lidei com esse requisito criando scripts de wrapper BASH para os aplicativos Java que eu estava executando em tarefas em lote. O script lidaria com o envio de variações de entrada apropriadas (download do recurso do sistema de arquivos distribuídos) e, quando o trabalho fosse concluído, o script lançaria as transferências de dados dos arquivos de saída para o mesmo recurso de arquivo distribuído (com o nome do trabalho, número do trabalho , nome do host que executou o trabalho e o carimbo de data e hora no nome da saída do arquivo).
HTCondor, Nomad ou até mesmo o Kubernetes podem lidar com esse problema para você. Você precisará adicionar algum tipo de lógica nos scripts do wrapper do job runner para manipular a transferência de dados antes de iniciar e encerrar o próprio aplicativo.
Espero que isso ajude.