FAXSMS on AWS OpenEMR 6.1 Standard Cloud

Day-to-Day Users
,
#1

System:AWS OpenEMR 6.1 Standard Cloud

I recently upgraded to Openemr 6.1, which actually only took a few minutes, which has tons of cool new features, and I actually prefer the new UI customizations to my own. Patient Groupings is a newer exciting feature that is pregnant with possibilities for patient care. Compliments to the many chefs responsible for the new release in total.

Unfortunately, I messed up the re-installation of the Fax-SMS module.

2022-04-08 11_00_57
2022-04-08 11_00_571845Ă—331 13.8 KB

It was unable to clone the GitHub - openemr/oe-module-cqm. I downgraded composer to version 1 since 2 kept giving me the timeout .

I saw that there was a recent change to the composer.json and maybe something I did caused this improvement to the code to work to my detriment. Please help.

Inked2022-04-08 11_51_39-revert composer from PR #5046 (#5058) · openemr_openemr@f68fc0d_LI
Inked2022-04-08 11_51_39-revert composer from PR #5046 (#5058) · openemr_openemr@f68fc0d_LI1912×724 67.2 KB

#2

It looks like git isn’t installed in the aws docker.

#4

Do I need to install inside the docker?

1 Like
#5

Something’s actually weird there and this may need a closer look.

Git is installed both in the 6.1.0 OpenEMR container (see openemr-devops/Dockerfile at master · openemr/openemr-devops · GitHub) and the 6.1.0 AMI that hosts your Standard install (see openemr-devops/ami-build.sh at master · openemr/openemr-devops · GitHub).

You appear to be inside the docker container since you’ve got a webroot in your prompt, so I’m not sure how you could be interacting with it in a way that git goes unfound – is composer doing weird things with a personal environment somehow?

#6

I tried running composer require several times and it kept asking me for github tokens. At some point I downgraded from composer 2 back to composer 1. At some point, I attempted to paste a github key obtained from the request link presented as it was asking for a token (I would always close out and try again prior to this as I likely offered an incompatible token). After that, I started receiving the error message .

#7

It was the git hub token. I changed the composer.json file and went back to 6.0 and received the standard frustrating following explanation that one receives before falling into the temptation of accidently entering aynthing in the token line:

GitHub API limit (0 calls/hr) is exhausted, could not fetch https://api.github.com/repos/openemr/jwt. Create a GitHub OAuth token to go over the API rate limit. You can also wait until ? for the rate limit to reset.

Head to Sign in to GitHub · GitHub
to retrieve a token. It will be stored in “/root/.composer/auth.json” for future use by Composer.

Token (hidden): Don’t put anything here!!! Immediately, close the ssh window and retry as sometimes the next attempt or so may work!!!

#8

Is there a way to get around api limit to get a token?

#9

I’m not familiar with this portion of the build process, sorry. Have you considered creating a GitHub account and API token?

#10

There’s no way to get around the api limit, but if you use your own github api key for docker you’ll likely never hit the upper limits. If you are using docker-compose these are the two lines with the github API key used with the OpenEMR dockers. The first line is the token, the second line is the base64 encoded version of the token. Note, changing these values I believe will only work on a fresh build (IE docker-compose up), you’d have to dive into the internals of the openemr devops if you want to replace the composer token on an already running docker image.

1 Like
#11

Well, once you have the tokens, my recommendation.

AWS Marketplace made the CloudFormation template of Standard available to you when you launched Standard. Download that CFT instead of launching it and you can edit your entire stack as you see fit. Find where the docker-compose is being constructed prior to injection, add your envvars there, and launch the new stack.

If there’s demand I will add GitHub API options to the stack builder.

1 Like
#12

Thank you for this!
I am more familiar now with the openemr devops folder contents, so updating to newer versions is a much more simplified process with docker-compose (a few minutes to load + placing forms + existing modifications) the process takes now less than ~10 minutes to do. I now am avoiding cloud formation like the plague because of the time saved with minimal downtime (no one is seeing patients in the middle of the night) and minimal time consumption. The only time I would consider messing with cloud formation is if I had to update my RDS version in its entirety or if an AWS region/VPCs stopped working. Otherwise, I can crash the entire program with HTTPS 500 errors and recover in minutes because of how well you guys utilize tools like docker. Dockers and modules are where it is at!!!

1 Like
#13

Thanks! Yes. I have modified the template before because I wanted to use PHP 8 for my RDS (did not desire to use 5.7).

  1. I will likely change the docker-compose. yaml to go back to openemr 6.0.
  2. docker-compose up to actually go back to openemr 6.0
  3. Obtain my own github api key for docker
  4. change github composer token
  5. docker-compose.yaml back to openemr 6.1
  6. docker-compose up then mobilize forms, modifications, and install module(s)
  7. Move on with life
1 Like
#14

Just FYI, but you shouldn’t need to mess with CF to upgrade an RDS instance – you can just do it in place from RDS directly. (/Downgrades/ won’t be so simple and I don’t think a snapshot made in 8 can be used in 7, so be careful, but.)

Can you tell me more about your thought process regarding avoiding CloudFormation “like the plague”? I agree that it’s not something you want to be using for repeated deployments, given that your stack should be static once built, but I didn’t think it was terrible.

#15

The openemr standard.json template that was available when I started using the software fired up a system on Ubuntu 16.04, Php 5.7, and was using a small database (vpcs on older, slower devices). This created a perfect storm for a long start up time. Once I learned how to modify the template (Ubuntu 20.04, Php 8, still small database), the time to launch was reduced by about ~1/4. On top of all that, I was constantly crashing my instances because of inexperience and backing things up almost never worked for me. Therefore, I was using cloud formation too often. Docker-compose up is just a much faster way to recover (~ 10 minutes versus 1-2 hours the other way), though now ~35-45 minutes for me because of all the undesired practice lol. When I use cloud formation, I am having to re-enter security rules, build brand new load balancers, change things over at route 53 to cause subdomain name to replace AWS Ip Address, configure load balancer, and a myriad of other little things. So if anyone can get away with modifying a yaml file and a docker compose command to quickly recover from site breaking mistakes, I encourage them to do that everytime.

I could break my production system and recover in minutes now, which is a relief. While cloud formation is great for originating your instance initially, if you dont have to do anything that seems to require changes to the endpoints of your RDS or EC2 instance on Standard Cloud, please learn the docker-compose approach to enjoy the beauty and effiency of a dockerized workflow.

#16

Ohhh! Okay, yes, that all makes sense. Thanks for the reply.

1 Like
#17

docker: git --version returns that git is not installed inside docker.
ubuntu: git --version returns that git version is 2.25.1.

Deep in the devops:
Dockerfile inside 6.1.0 as in other scripts (6.0.0, 5.0.2, 5.0.1, 5.0.0) deletes git just before declaring the working directory in the docker container so git is not in the docker container as Stephen pointed out 3 weeks ago. I am assuming this is for safety purposes since we have to ssh into AWS with ssh key thereby likely posing a risk when accessing these public and private repositories. The problem is, the API rate limit does not appear to ever reset. I have tried nearly once every two hours until odd times of night/morning with no success.

Outside of having more Github API options added to the stack, suggested by jesdynf, what’s my work around? Would this work?

1)Opt not to delete git from the Dockerfile of interest
2) docker-compose up, where docker-compose.yaml maintains my new github token and 64 based.
3) Install my modules, then create an openemr backup directory, especially to preserve vendor folder and custom modules, if possible (don’t seem to lose anything else with docker-compose up as documents are intact.
4) Return Dockerfile of interest to its normal state
5) docker-compose up again
6) re-establish preserved directory back to proper space
7) finish up modifications and patch procedure

#18

I don’t think you can modify a Dockerfile like that, it’s an integral part of the container.

You can build your own container that works otherwise, however. Two options:

  • Take a look at the dev compose file at openemr-devops/docker-compose.dev.yml at master · openemr/openemr-devops · GitHub and look at the openemr container stanza. Notice how it’s not actually pulling a named container, but instead building a launch container from source? You could provide a modified container build that worked as you saw fit.
  • Establish a user at Docker Hub and then publish your own modified openemr container to it, then refer to your new container by name in your docker-compose file.
  • (If you have modifications you can’t distribute, since I know you’re using AWS you could publish containers to AWS ECR instead.)
  • I guess if you want a middle ground you could build a docker container locally and then not publish it to the hub, as long as you’ve tagged the container correctly just having it your local container store is good enough for docker-compose to find it.