Are upgrade instructions AWS Standard Edition 5.0.2(5) to 6.0.0 available?

Here is what docker-componse.yaml looks like on my OpenEMR Cloud Standard (AWS) system:

version: '3.1'
services:
  openemr:
    restart: always
    image: openemr/openemr:5.0.2
    ports:
    - 80:80
    - 443:443
    volumes:
    - logvolume01:/var/log
    - sitevolume:/var/www/localhost/htdocs/openemr/sites
    environment:
      MYSQL_HOST: 'xxxxxxxxx.yyyyyyyyyy.us-east-1.rds.amazonaws.com'
      MYSQL_ROOT_USER: openemr
      MYSQL_ROOT_PASS: 'zzzzzzzzzz'
      MYSQL_USER: openemr
      MYSQL_PASS: 'zzzzzzzzzzzzz'
      OE_USER: admin
      OE_PASS: 'zzzzzzzzzzzz'
volumes:
  logvolume01: {}
  sitevolume: {}

I believe you only need to change this line in the docker-compose file:

image: openemr/openemr:5.0.2 to image: openemr/openemr:6.0.0

Then docker-compose up everything else is automated no need to do any other steps AFAIK but @brady.millercan clarify if that is not the case.

hi,

@benmarte is correct.

In the case of the ssh certs though, there is no shared volume to retain that. So will need to replenish (just copy in the certs from the “old” docker) the ssl certs in your docker after the docker-compose up command.

-brady

How difficult is it to create a shared volume to retain the certs or is there some relatively simple scripting that can be done to automate this process (and thus have something that can be tested? … I don’t even know what “shared volume” means in this context and how we know that the certs don’t have this :frowning:
RBL

What are you doing with SSL that needs to be copied to the container? You should be able to do redirection on cloudfront without having to do anything in the containers.

See Brady’s comment above … “In the case of the ssh certs though, there is no shared volume to retain that. So will need to replenish (just copy in the certs from the “old” docker) the ssl certs in your docker after the docker-compose up command.”

So, based on my understanding, I will modify my docker-compose.yaml file as follows:

version: '3.1'
services:
  openemr:
    restart: always
    image: openemr/openemr:6.0.0
    ports:
    - 80:80
    - 443:443
    volumes:
    - logvolume01:/var/log
    - sitevolume:/var/www/localhost/htdocs/openemr/sites
    environment:
      MYSQL_HOST: 'xxxxxxxxx.yyyyyyyyyy.us-east-1.rds.amazonaws.com'
      MYSQL_ROOT_USER: openemr
      MYSQL_ROOT_PASS: 'zzzzzzzzzz'
      MYSQL_USER: openemr
      MYSQL_PASS: 'zzzzzzzzzzzzz'
      OE_USER: admin
      OE_PASS: 'zzzzzzzzzzzz'
volumes:
  logvolume01: {}
  sitevolume: {}

I have been down this road before and it was not a happy experience (see Planning for OpenEMR 5.0.2 release - OpenEMR Development - OpenEMR Community (open-emr.org)).
I think what I need to do use images of production system to create a new EC2 and RDS instance and then try to migrate such a “test” system until I have a reliable and tested upgrade procedure.
RBL

I’m just trying to understand why this is a problem, why do you need to backup your ssh keys?

That is provided by amazon and that’s to connect to your EC2 instance not your containers.

SSL certs can be handled by cloudfront/cloudflare and no need to mess with anything for the containers unless I’m missing something I might not know about, (I’d really like to know if this is the case, because then I know I’m doing it wrong :slight_smile: ).

1 Like

Hi,

This can be done many ways. The docker does provide option for ssl support (defaults to a self-signed cert, and then can replace them to custom certs, and also an option for letsencrypt). But as @benmarte points out can also be done at a higher level (note for hipaa, need to ensure everything over the wire is encrypted).

Regarding shared volumes, these are basically things that are kept when going from one docker to another via the docker-compose up. Since we did not create a shared volume for the ssl stuff. (btw, here is an example in a docker-compose.yml where this is done: openemr-devops/docker-compose.yml at master · openemr/openemr-devops · GitHub ), this means recommend copying your stuff in old docker at /etc/ssl before doing the docker-compose up, and then copying that old stuff back into /etc/ssl after the docker-compose up.

@jesdynf , just wanted to ensure my above comments make sense for the Standard AWS package (ie. is there a special ssl thing going on in Standard or not). Also, would it make sense to consider shared volumes for ssl and letsencrypt in the future (note in my example of using it above, it was in the kubernetes docker-compose.yml where needed this for ssl to work when have multiple replicas going).

1 Like

Standard uses Amazon’s SSL certificate for RDS, loaded into documents/certificates/mysql-ca of the sitevolume, if I understand the nomenclature. OpenEMR won’t be able to connect securely to the database without that Amazon-supplied certificate in the appropriate place. We install it during the Standard build process, and I don’t see why it would be disturbed during a non-destructive up.

See https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html for more information about where to download this certificate directly.

1 Like

@jesdynf , Thanks for pointing that out. That mysql ssl mechanism will be fine since documents directory will be maintained.

No matter how reasonable these migrations look, it’s necessary to test the migration to make sure it works. Creating a test system is a complex chore because many aspects of the new test instances cannot simply be “copies” of the original production instances (IP addresses, SSL certificates related to the web server, SSL configuration related to the Web server, the test EC2 instance will try to reference the production database instead of the new test database instance, etc.). Another approach is simply to create a new OpenEMR Cloud 6.0.0 Standard Edition system and migrate the data over. This second approach seems a lot simpler and less risky than migrating a running production EMR. Unfortunately, the second approach is not an easy option because you cannot run the Cloudformation (AWS Marketplace OpenEMR) “Stack” if you have a Standard production system running … it will fail because the “maximum number of VPC’s is exceeded” and similar errors. Thus, I will need to either create a test system to migrate or manually put together an AWS OpenEMR 6.0.0 Standard system and then migrate the data.

hi @Ralf_Lukner, maybe you can fire up the test system in another region to get around the VPC’s exceeded?

I’m going to try that! Thank you for the tip!

Update: Stack creation failed for the following reasons:
The following resource(s) failed to create: [PublicSubnet2, OpenEMRKey, PrivateSubnet, igAttach, PublicSubnet1, PrivateSubnet2, CloudTrail]. Rollback requested by user. I will put in an AWS tech support case and see if they have any ideas.

:frowning: I wonder if this is easy to work around…

oh right, @jesdynf may require a specific region

believe you may request aws to allow you more VPC’s for that region though

I had not encountered a limit on VPC creation before – Stephen is right, you can request account limitations be relaxed and they’re usually willing to honor them.

A script that hasn’t been tested enough is openemr-devops/OpenEMR-Standard-Recovery.json at master · openemr/openemr-devops · GitHub , a CloudFormation recovery template designed to work with an existing Standard installation and make a side-by-side duplicate using snapshots and backups. But at a minimum I don’t think the AMIs encoded in the script are correct any more, and I think it’s been a while since I rebuilt it from the stack source, and it would also fall afoul of the VPC creation threshold you describe.

(Why has it gone unmaintained? Because /nobody’s using it/.)

1 Like

The reason I could not launch another Cloudformation “stack” of the AWS OpenEMR 5.0.2 Cloud Standard Edition is that I reached the limit of five cloudthreads… I deleted 3 to make room. Also, I had my VPC limit quota increased so that was no longer a problem. Then I was able to launch a new 5.0.2(5) stack successfully in a new region. I’m going to try to migrate my EMR data to the new test system, install a new SSL certificate on the tests system and attempt to upgrade it to 6.0.0. Thank you for all the help so far. I will take a look at the backup/restore as a mechanism for migrating the EMR data. Creating images and migrating them Is another option, and I may try that also.

I was able to create an “empty” OpenEMR 5.0.2 Cloud Standard Edition system in another region. Next, I tried to migrate a copy of the production system over to the other region … that was not so successful. When I tried to connect to the webserver … no login page. I made sure the /var/www/localhost/htdocs/openemr/sites/default/sqlconf.php file was updated with the new database rds instance name, but I suspect there must be more to consider when you move to a new region.

One idea I had was to create a backup of the original production 5.0.2 database and restore it to the “empty” 5.0.2 test system. Next, I would somehow backup the patient “documents” and restore those onto the the “empty” 5.0.2 system (EC2 instance). Is this the “duplicity backup”?

Hi Ralf, a rough manual backup could be achieved where you would take the download created from openemr, fire up a phpmyadmin docker on the ec2 running the new openemr and import into the new rds, then you can scp the pt docs there and extract them into the documents folder after using docker cp

@jesdynf’s guides are worth investigating for their elegance in light of the previously mentioned approach

1 Like

are there any programmers that can help us to upgrade from emr version 4.02 to the latest version. Please feel free to email us, the charge and we might consider to contact you back.

thanks

appointmentmedconsultasia@gmail.com

Can I please ask for your advise about how to backup before upgrading? What we had done was compress data base to zip file. But turned out we could not reinstall from the zip file. So we are scared to upgrade.
Your advise will be highly appreciate.
Thank you in advance