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

Support
#41

I think I understand what’s going on. You can’t create a new docker-compose file like you did here – as you can see, your attempt to launch it failed because the existing process was camping 443. Using a new docker-compose in a new location creates a new network, it doesn’t modify an existing one. Look in /root/openemr-devops/packages/standard/ for the docker-compose you need to modify and up – I think you’ll have better luck.

Don’t know why docker-compose isn’t available, it was in the build scripts.

#42

Okay, I tried that. Things went from bad to worse.

Initially, things looked promising … I made sure I was working with /root/openemr-devops/packages/standard/
I did have to change the version from 3.1 to 2: version: '2'in the docker_compose.yaml
because 3.1 was not supported:

$ sudo ./upgrade.sh 
ERROR: Version in "./docker-compose.yaml" is unsupported. You might be seeing this error because you're using the wrong Compose file version. Either specify a version of "2" (or "2.0") and place your service definitions under the `services` key, or omit the `version` key and place your service definitions at the root of the file to use version 1.
For more on the Compose file format versions, see https://docs.docker.com/compose/compose-file/

Here is my “corrected” docker-compose.yaml:

version: '2'
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: 'xxxxxxxxxxxx.yyyyyyyy.rds.amazonaws.com'
      MYSQL_ROOT_USER: openemr
      MYSQL_ROOT_PASS: 'zzzzzzzzzzzzzzzzz'
      MYSQL_USER: openemr
      MYSQL_PASS: zzzzzzzzzzzzzzzzzz'
      OE_USER: admin
      OE_PASS: 'qqqqqqqqqqqqqqqqqqq'
volumes:
  logvolume01: {}
  sitevolume: {}

I modified my upgrade.sh script as follows:

#!/bin/sh

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

And executed the script & rebooted the instance:

$ sudo ./upgrade.sh 
Recreating standard_openemr_1
$ sudo reboot

Now that EC2 will not respond at all:
Going to the latest version of Chrome on Mac:
URL: xxxxxx.yyyyyyy.compute.amazonaws.com (EC2 instance address – web server)
Yields this error:

This site can’t be reached xxxxxx.yyyyyy.compute.amazonaws.com refused to connect.
Try:

Checking the connection
Checking the proxy and the firewall
ERR_CONNECTION_REFUSED

There is nothing relevant in the logs as far as I can tell.
Basically, the EC2 web server can no longer be reached (from a web browser). I can ssh into the EC2 instance, however. Once we are done getting any information / trying to repair this instance … if we cannot repair it …I plan to terminate it and restart a replica from an image.

#43

I really don’t understand what’s going on with your instance. Standard installs a docker-compose that will run my docker-compose, and we know it works because the thing launched. Are you running my instance at all, or did you somehow copy the containers over?

Tell me more about this update script?

#44

I’m able to exec into the container and look around. For some reason, the webserver (apache) no longer seems to be working as expected, and I do not know how to troubleshoot it.

I remember having similar issues when using ./docker-compose in the past with version 5.0.x. That’s why I went through this effort to build a test system.

The test system was built using the cloudformation (AWS Marketplace) script for v5.0.2 (Oct 2019 edition) and then patched to 5.0.2 patch 5. I did not copy any docker containers.

The update.sh script just puts me into the correct place:
cd /root/openemr-devops/packages/standard
and then executes the
./docker-compose up -d
I have to use this script because I cannot log in as root (at least I haven’t figured out how yet) and use sudo to perform root tasks.
–RBL

#45

sudo bash to get a root shell.

I suspect ./docker-compose is a part of your problem – that’s saying “run the docker-compose executable that’s been downloaded to this location”. Drop the path specification and try again?

Also try docker logs to see what the container’s griping about when it fails.

#46

Thank you for the troubleshooting information. I’m going to restore a clean / functional test system and try again.

The ./docker-compose came from the OpenEMR upgrade instructions and there actually is an executable in the standard directory. The incorrect directory was also in those instructions. Maybe I will not need to install docker-compose if I use that. I will restore the test system this evening and try the upgrade again with the knowledge I have gained during this first test.

Thank you again,

RBL

#47

I’m going to try a different approach that avoids the docker-compose entirely … I will create a 6.0.0 system and then attempt to move my database to that system.
RBL

#48

Migrating the database is tricky due to schema changes. Going back to Plan A - migrate a v502 test system

#49

@Ralf_Lukner you are overcomplicating things and making it worse for yourself.

If you have a backup of your 5.0.2 system make a new openemr ec2 instance for 5.0.2 and restore your files and database to get your 5.0.2 system up and running.

Once you do that then you can use my guide to upgrade to the latest version, I use this process and it works flawlessly every time.

You don’t have to install docker on your EC2 instance it’s already installed you are just not using the sudo user, so installing docker and making a new docker compose file most likely ruined your EC2 instance.

Good luck.

#50

I tried your procedure and it fails at this point:

“ Backing up the required files

This is probably the easiest part of this tutorial, making a backup of your Open EMR instance is as easy as logging into Open EMR and clicking the Create Backup button in the Administration > System > Backup page. This will provide you with a tar file (basically a zip file) with your websites files and database.”

When I try this, the system hangs (stops responding and does not complete even after many hours and stops access to the EMR for use by the clinic during this process). Keep in mind that I am a doctor in a rural area where we don’t have 2 GBit Internet… it’s slower. Also, there are other latencies related to the way the system works during backup.

What I really would like is a backup method that stores the backup file locally on the Webserver.

There may be a workaround, however. Amazon AWS now can emulate personal computers. I’m going to try to emulate a personal computer (Mac etc), and then use a browser on the emulated personal computer to initiate the backup. Since the emulated computer resides on their system, perhaps the backup would be able to complete after a few hours

RBL

#51

Maybe there is a way I could modify the OpenEMR backup code so that it redirects the enormous backup file (60 GB ?) to the Webserver file system rather than attempting to transfer it over the internet and locking up access to the database for an unacceptably long amount of time?

RBL

#52

Actually, storing the backup in an S3 bucket would be even better and not limited by the file system on the Webserver.

#53

How much disk space does your EC2 instance have? I bet it does not have more than 120gb which iw what you would need in order to make a backup.

Even if OpenEMR backup from the admin menu does not work you could be able to back it up manually by going into the mysql container and copying the backup to your EC2 instance.

You would need to at least double the size of your disk space in order to make the backup, so here’s what I would do.

  1. increase the disk size of your EC2 instance to double of what it currently has to ensure you can make a proper backup.
  2. Make a manual database backup by using an interactive docker session in your mysql docker container
  3. copy the database backup to your EC2 instance
  4. Download the database backup to your computer (most likely via ftp)
  5. copy your open emr folde3r from your open emr docker instance
  6. restore your database and open emr files to a local docker instance
  7. ensure your backup is working locally
  8. update your local docker instance

If you update goes well then I would make a copy of your updated database and restore that to your EC2 instance along with the updated open emr files.

The idea is to do the upgrade locally and restore your updated files in your EC2, the reasoning behind this is your computer will most likely be much faster than the EC2 instance since it has better hardware specs in most cases.

Good luck.

1 Like
#54

Thank you for your fast and thoughtful reply!

Remember that OpenEMR Cloud (AWS) Standard has the database on its own RDS instance, and, thus, it’s not necessary to access it via an interactive docker session.

I will try the general procedure that you have outlined. I can manually mysqldump the entire database pretty easily, and I have been using 200 GB volumes … no problem with storage space on the non-docker part of the disks. The issue I noticed is that the docker portion of the volume is ~40GB and pretty close to full no matter what the total disk storage is …

I will try this after the clinic is closed today because a mysqldump locks access to the database for a while, and I cannot do this while we are seeing patients in clinic.
–RBL

#55

I was able to create a mysqldump > file.sql
However, when I connect the RDS instance interactively via MySQL-client and then source file.sql, I eventually get a failure with the following error:
Timeout, server ec2-aa-bbb-ccc-dd.us-xxx-2.compute.amazonaws.com not responding :frowning:
Evidently, there is some kind of timeout parameter that needs to be changed.
This long restore with some very large tables that do take a while to process.

Thus, I created a parameter group for my RDS instance and put in the following:
connect_timeout 31536000
interactive_timeout 31536000
wait_timeout 31536000

And tried the restore again … it’s running again, and I will call it a night for now. I’ll check in the morning to see if the restore (source file.sql) completed.
–RBL

1 Like
#56

The source file.sql (restoring the database) keeps failing before completion … this last time, AWS disconnected my terminal session and terminated the restore … “client loop: broken pipe.” I cannot get the restore of this large database to complete.
–RBL

#57

Are you making a backup or restoring? If making a backup I would contact AWS support if there’s nothing in the logs that can help indicate what is going on.

#58

Okay. I will ask AWS support.
RBL

#59

You don’t need to use mysqldump at all – you’re using RDS, and that means you’ve got access to database snapshots. All I ever intended here was for you to just fingersnap and take a snapshot of the database and put it to the side. No need for long timeout-fighting techniques or nightly locks.

(It would be nice if you also understood how to use this snapshot – the process of restoring it and then reaching into the OpenEMR instance’s sqlconf.php and assigning the new hostname of the restored snapshot.)

#60

There is an even easier way using RDS read replicas. I create an exact replica of the production database in the test region. Now, I just need to connect the web server to the new RDS database instance … how do I do this?