Easiest way to update the Stig Manager version to latest using docker compile?

[st3v1s]

Our users have requested that the lastest version of Stig Manager be available as they would like to take advantage of new features. Our current build is version 1.3.7. We have a docker-compile.yml wih image nuwcdivnpt/stig-manager:latest-ironbank.

Do I just need to do docker pull nuwcdivnpt/stig-manager:latest-ironbank to pull latest and start up containers? Also I don't want to lose any data so I would do a docker stop, and then docker start.

Thoughts?

[cd-rite]

Hi @st3v1s Yes, it should be that simple! The new version of the API container will make any required changes to the database. It is always best to be sure you have backups of your Database in case there are any issues!

[st3v1s]

Ok that makes sense to me. And yes the current docker-compose was not configured to use volumes.

So if I just tar up the _data director in /var/lib/docker/volumes/volumename/_data/ what command do I run to provide that tar file at the next docker compose build?

[cd-rite]

The tar would be your backup, it would need to be un-tarred and put wherever your configuration would look for it.
Sorry, but this is really getting beyond what we can support regarding our app, and is more about general Docker usage, etc... I'd look here to see if you can get things the way you like them: https://docs.docker.com/storage/volumes/#use-a-volume-with-docker-compose

You can always un-tar the data into a new place, and bring up a new orchestration pointing at it to verify that it works.

If you don't currently have your database using a volume, then your only option may be to export your .ckls as they stand in your existing deployment, and then re-import them into a new orchestration that is configured to use volumes, etc.
Some pieces of our sample orchestration may be helpful:
https://github.com/NUWCDIVNPT/stigman-orchestration/blob/d2dae23c7edba3688dab7b1e02f7409e3b36d5f4/docker-compose.yml#L63

[st3v1s]

What do you mean by this statement: If you don't currently have your database using a volume, then your only option may be to export your .ckls as they stand in your existing deployment? What are the .ckls files you are referring to?

I'm still testing different scenarios for this issue.

[cd-rite]

HI @st3v1s I was just describing an absolute last resort option if you can't get your database to persist data. You had said earlier:

Our users said that they can export the stigs in the collections so that they can import them into the new version of stig manager container....do you think that would be good work around?

Those exports are usually in ".ckl" format. They could be exported for each Collection in the app, and then reimported into a new instance with new Collections. It's not ideal, though: they would no longer have Review history data, user assignments, reference STIGs would have to be re-imported, etc.

[st3v1s]

Ohhhh, that's what you meant by .ckls!! :-)

[st3v1s]

Finally solved my issue. Was able to get Stigman Manager updated to 1.4.2 and use my historical data. Also created persistent volume.

[cd-rite]

That's great! Glad you got it sorted out!