Upgrading AWS to 6.0.0

I’m helping my friend upgrade his OpenEMR instance to the latest and greatest. We installed 5.0.2 via an AMI on the AWS marketplace. I’ve found these instructions on the docker page for OpenEMR:

  • Automatic upgrading of OpenEMR is supported when upgrade from 5.0.1 to 5.0.2+ (note this is not supported in the flex* series). In your docker-compose.yml file, you can basically change the 5.0.1 or 5.0.2 to 6.0.0 image and then do a docker-compose up. This will only work if you have set a shared volume for the /var/www/localhost/htdocs/openemr/sites directory (it will not work if either you didn’t set a shared volume or you set the shared volume to be the entire /var/www/localhost/htdocs/openemr directory). Before you do this, recommend backing everything up.

The bit about setting a shared volume I’m afraid I don’t grok. Is this something that would’ve been done by AWS when setting up the image for the first time? If I can’t go this route, should I go the upgrading Linux route involving just manually moving files around inside the docker image itself?



The lightsail package docker-compose.yml defines a shared volume for /var/www/localhost/htdocs/openemr/sites. You can compare it to the docker-compose.yml you are using.

I’m using the AWS Standard edition package I think? My stack was created by the Cloudfront thing on AWS. Looking at the lightsail docker-compose.yml you posted, I see this section that I don’t have in my standard/docker-compose.yml from 5.0.2:

- mysql

FWIW, the docker-compose.yml I have doesn’t have a section for mysql configured?

The standard package uses AWS RDS instead of a docker MySQL container, so that may explain the difference you’re seeing. I don’t think that has an impact on what you’re trying to accomplish.

For docker compose, volumes are defined in the services/<container>/volumes: section and “shared” in the higher-level volumes: section.

hi @jesdynf , are these upgrade instructions ok to follow for standard?

I’m not sure – I’ve never done one personally and these are for 5.x, and we’ve gotten better at updates since then.

I think that you should be able to change the yml to 6.1.0, do an up (not a down, just an up), and the system will detect an upgrade needs to happen and run it on its own, but I’d appreciate @brady.miller weighing in to confirm that claim.

I’m not sure we still need to run any scripts manually if the container can work out that an upgrade should happen but I’m not positive I get that process.

1 Like

think @brady.miller allows for it here and his recent work for v6.1.0

yep, @jesdynf is correct. It is automated and no scripts need to be run manually.

1 Like