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

Ralf_Lukner · February 13, 2021, 3:05pm

Situation
Are there upgrade instructions for OpenEMR AWS Standard Edition 5.0.2(5) to 6.0.0 available?

benmarte · February 13, 2021, 4:57pm

You need to change the openemr image in the docker-compose file, then docker-compose up with the edited docker-compose file.

Make sure to backup all your stuff before doing so, good luck.

brady.miller · February 13, 2021, 6:28pm

hi,
Should not need to do a docker-compose down (if somebody did this wrong, for example added a remove volume flag, then would lose all data), so better to not risk that command. Just a docker-compose up command will suffice.

Ralf_Lukner · February 13, 2021, 9:20pm

Did you basically follow the docker update method and then run the database upgrade script? This is on the OpenEMR Cloud Standard Edition, correct?
RBL

brady.miller · February 13, 2021, 10:48pm

Hi,

OpenEMR docker supports an automatic upgrade mechanism: openemr-devops/upgrade.md at master · openemr/openemr-devops · GitHub

You basically change the 5.0.2 in the docker-compose.yml image to 6.0.0 and then just do a docker-compose up . This will automatically grab the image and run through the upgrade. Can follow the upgrade as it is happening (can take awhile sometimes) via the the docker logs command. And definitely recommend trying on a testing instance first (and ensure production instance is backed up in case something goes wrong).

Ralf_Lukner · February 14, 2021, 1:29am

Okay. I have taken the text at openemr-devops/upgrade.md at master · openemr/openemr-devops · GitHub and modified it as follows, attempting to capture the new upgrade procedure from 5.0.2(5) to 6.0.0 AWS Standard.

Note that I’m using the “AWS Marketplace” product. Is there anything special that I need to do in this regard?
Also, I’m using SSL and have certificates in place. Is there anything I need to be aware of or will these certificates work with the new version without any changes, presumably. In my SSL implementation, I redirect http:// traffic to https:// so I wonder if step three will just be https://my_domain.com/sql_upgrade.php

Upgrading from 5.0.2 to 6.0.0 DRAFT (Please review & comment)

Overview

To upgrade OpenEMR, you’ll want to follow four steps:

Backup your system and upgrade your local container.
Install the schema upgrade templates.
Run the upgrade script.
Delete the upgrade templates.

Procedure

Docker-based installation is new to the 5.0 series, so this document won’t be able to help you with upgrades from 4.x, and upgrades to future versions will require slightly divergent scripts. You may either copy these scripts directly, or paste them line by line into a (root) console.

Note that if literally the only thing you’re using is an OpenEMR docker, and not a Lightsail launch or an AWS Marketplace solution, then this document outlines the general steps to take, but refers to scripts and directories you haven’t created, so you’ll need to treat this as a recipe and season it yourself.

Step One

Choose your instance in the EC2 Dashboard. Click Actions>Image and Templates>Create Image.
If you are using OpenEMR Cloud Standard (AWS), go to RDS Dashboard.
Click Actions>Take Snapshot

#!/bin/sh

# make a restore-point
/etc/cron.daily/duplicity-backups

# pull in 6.0.0 container
cd /root/openemr-devops/packages/lightsail
sed -i 's/5.0.2/6.0.0/' docker-compose.yml
./docker-compose up -d

Step Two

#!/bin/sh

# retrieve files deleted for security
OE_INSTANCE=$(docker ps | grep _openemr | cut -f 1 -d " ")
docker exec -it $OE_INSTANCE sh -c 'curl -L https://raw.githubusercontent.com/openemr/openemr/v6_0_0/sql_upgrade.php > /var/www/localhost/htdocs/openemr/sql_upgrade.php'
docker exec -it $OE_INSTANCE sh -c 'curl -L https://raw.githubusercontent.com/openemr/openemr/v6_0_0/acl_upgrade.php > /var/www/localhost/htdocs/openemr/acl_upgrade.php'
docker exec $OE_INSTANCE chown apache:root /var/www/localhost/htdocs/openemr/sql_upgrade.php /var/www/localhost/htdocs/openemr/acl_upgrade.php
docker exec $OE_INSTANCE chmod 400 /var/www/localhost/htdocs/openemr/sql_upgrade.php /var/www/localhost/htdocs/openemr/acl_upgrade.php

Step Three

Navigate to http://<your-instance>/sql_upgrade.php and select 6.0.0 .

Step Four

(If you’re using OpenEMR Standard, go ahead and make a post-upgrade RDS snapshot.)

#!/bin/sh

# make a restore-point
/etc/cron.daily/duplicity-backups

#delete upgrade files that have served their purpose
OE_INSTANCE=$(docker ps | grep _openemr | cut -f 1 -d " ")
docker exec $OE_INSTANCE rm -f /var/www/localhost/htdocs/openemr/sql_upgrade.php /var/www/localhost/htdocs/openemr/acl_upgrade.php

jesdynf · February 14, 2021, 7:15am

Hmm.

Is running the sql-upgrade script still necessary, or was that embedded in the docker upgrade path automatically?

brady.miller · February 14, 2021, 8:00am

hi,
Should only have step 1 (ie. remove steps 2-4). What does the docker-compose.yml file look like for AWS Standard Edition (then I can answer if the ssl stuff will stay after the upgrade)?

Ralf_Lukner · February 14, 2021, 12:46pm

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: {}

benmarte · February 14, 2021, 3:19pm

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.

brady.miller · February 15, 2021, 4:56am

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

Ralf_Lukner · February 15, 2021, 2:53pm

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
RBL

benmarte · February 15, 2021, 5:11pm

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.

Ralf_Lukner · February 15, 2021, 6:44pm

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

benmarte · February 15, 2021, 7:13pm

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 ).

brady.miller · February 15, 2021, 7:28pm

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).

jesdynf · February 15, 2021, 7:40pm

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.

brady.miller · February 15, 2021, 7:43pm

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

Ralf_Lukner · February 17, 2021, 2:31am

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.

stephenwaite · February 17, 2021, 1:40pm

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