OpenEMR 7.0.0 Devops

OpenEMR Development
#1

I’ll be working on updating Lightsail and the AWS packages to 7.0.0 this weekend, which will include the security updates. Two things I need to check on:

  • Apparently Duplicity and some kinda new S3 bucket-naming hotness don’t always get along; --use-s3-new-style and/or addressing via boto3+s3: have been tossed around, and I want to sort that out.
  • I need to experiment to see if I can delete a container without damaging patient files on the volume, and document the use of the MANUAL_SETUP flag if so.
2 Likes
#2

Things that happened today.

  • I learned that a functioning OpenEMR Standard instance can survive a down, and that this somehow resolved an SSL problem the instance contracted. I recommended the administrator up the instance with MANUAL_SETUP set but on review I’m not sure that was necessary. The administrator ran a Duplicity recovery as I asked but it replaced no files, so we assume the volume remained intact past the container’s downing.
  • Password reset attempts do not override the password expiration requirements of last_update_password and this caused a lot of frustration for reasons I’m not 100% sure I understand but I’m reporting what seemed to resolve the problem because I can’t recall the last time I saw it mentioned.
  • You can actually set Let’s Encrypt Docker envvars after initial setup, which is a good thing since you can’t actually know what IP your server is going to get until after the stack launches. Add the DOMAIN and EMAIL envvars to the docker-compose file once you know them (and once your A records match up) and up it to have the container consider them and run Let’s Encrypt before it lets Apache actually crank up properly.

Vocabulary and concept reminders:

  • openemr/openemr:7.0.0 is an image
  • <some random string of hexadecimal characters> is a container, which also has a handy name like standard_openemr_1
  • docker run loads an image and turns it into a container which then starts
  • docker start and docker stop start and stop containers
  • docker exec runs a command of your choice (usually a shell) inside a running container
  • docker-compose down destroys containers
  • docker-compose up creates or recreates containers, optionally with new state (like environmental variables) or new sources (like upgraded images)
  • exploring a container that’s so busted it can’t start is problematic
    • docker logs will let you see the container’s stderr/stdout output, which will give hints
2 Likes
#3

Lightsail and Express Plus are now up to 7.0.0 (1). I’ll see about building images for Express and Standard tonight or tomorrow.

1 Like
#4

While I’m thinking about it–

On the developer call today, I was asked about virtual machine instances. Right now I’m not preparing any, there never seemed to be even light demand for them, but it’s very little effort to make one on your own. Boot up an Ubuntu 20 iso, make sure it can see the network, and from there it’s literally two commands.

curl -L https://raw.githubusercontent.com/openemr/openemr-devops/master/packages/lightsail/launch.sh > ./launch.sh
chmod +x ./launch.sh && sudo ./launch.sh

Once the launch is finished OpenEMR will be ready to log in under the default credentials. You can start using it or you can turn the instance off and export it to an OVF for distribution. In this mode you still get Duplicity backups (run daily from a cronjob), but they’ll just be copied somewhere to sit on the host instead of sent to some S3 bucket – you can arrange an rsync on your own terms to somewhere safer (or modify /etc/cron.daily/duplicity-backups to work as you’d prefer).

Nothing stops me from making one if somebody truly needs one produced, but… there’s just not a lot to it. There’s no elaborate build process to bake these, just run the launch, test the login, halt the instance, pick export from the dropdown.

2 Likes
#5

Express and Standard are in process.

1 Like
#6

A post was split to a new topic: How Frequently are docker images built (for 6.1 and 7.0.0 releases)?