search

RedHatOfficial / openemr-kube

OpenShift/Kube deployment info for OpenEMR (https://www.open-emr.org/)
11 stars 13 forks source link

Enable app initialization #27

Closed isimluk closed 4 years ago

isimluk commented 4 years ago

It seems that boostrap is still not working properly with our ubi based container.

At initial bootstrap of the application we want to conclude some initial set-up tasks (i.e. database migration). In the docker swarm mode it was done by selecting leader container and leader container running the initialization. OpenShift way to achieve this is to have cron job (at openshift level) that will schedule extra pod, just for the initialization. For that case we will re-use openemr container and hence we will store the first boot init script at that container.

isimluk commented 4 years ago

/cc @bostrt (still wip)

sabre1041 commented 4 years ago

@isimluk I would like to provide some thoughts into how the database should be initialized. To separate the application from operational concerns, this type of logic should be managed outside of the application with the only logic contained within the application being concerned that it can connect to the database. This validation step can be managed in an initContainer to block the primary container from starting until this process has completed (a loop).

The initialization/seeding can be completed as part of a Kubernetes/OpenShift job that is handled separately. DDL etc can be specified via ConfigMap/Secret (assuming its not "too" large).

This would allow for a full GitOps based approach and can be implemented using an appropriate tool as necessary.

isimluk commented 4 years ago

:+1: I think that is exactly where this is headed. Initialization is separate. Maybe we should move init job to separate folder to make this explicit to whoever follows Readme.md

bostrt commented 4 years ago

@isimluk @sabre1041 If we think the OpenEMR project will accept these types of changes, I think we should go for it. What you both are suggesting would absolutely be a best practice.

isimluk commented 4 years ago

@isimluk @sabre1041 If we think the OpenEMR project will accept these types of changes, I think we should go for it. What you both are suggesting would absolutely be a best practice.

I don't know, we are not there yet, however, my guess is that the acceptance by upstream will be predicated on someone volunteering to maintain this stack in future, rather than on the actual architectural design.

isimluk commented 4 years ago

Have to bump to 5.0.3 as it seems that 5.0.2 tag is broken with https://github.com/openemr/openemr/pull/2741#issuecomment-548431920

isimluk commented 4 years ago

Merging early (alas unfinished) as agreed in other channel.