Database Migration Strategy for Kubernetes/Helm/Gitlab CI Architecture

[Fabian Will]

Hi,

We are running HAPI FHIR in a kubernetes cluster, connected to a postgres database that is hosted externally on another machine, not in kubernetes.

FHIR HAPI is forked into our Gitlab and Gitlab CI/CD pipelines are used to deploy the application (using Helm).

To migrate the database on every update, flyway was enabled in the application.yaml.

Since flyway is no longer used, there is no database migration - Spring Boot seems to use Hibernate DDL to update the schema, but we disabled it because it was causing problems.

When updating to version 7.0.2, the application now fails because of this change: https://github.com/hapifhir/hapi-fhir/pull/5555

According to the documentation, the tool to use to migrate the database is hapi-fhir-cli, but I cannot get it to work in our environment/pipeline.

My idea was to create a step in our gitlab ci pipeline that runs the hapi-fhir-cli, but our infrastructure does not allow the gitlab runner to connect to the database.

What would be the best migration strategy for this scenario? Am I missing something?

Thanks!

[James Agnew]

For what it's worth, this class is how we handle this on the public hapi.fhir.org server - it doesn't run on K8S, but it does auto-migrate its own database on startup.

https://github.com/hapifhir/hapi-fhir/blob/master/hapi-fhir-jpaserver-uhnfhirtest/src/main/java/ca/uhn/fhirtest/migrate/FhirTestAutoMigrator.java

Cheers,

James

--
You received this message because you are subscribed to the Google Groups "HAPI FHIR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hapi-fhir+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hapi-fhir/adc67be3-1fe6-4db3-985e-969e0a14f417n%40googlegroups.com.