Situation
I am trying to deploy OpenEMR Fullstack on AWS but the CloudFormation stack fails because the S3 bucket holding the application package for Beanstalk cannot be accessed (access restricted). I tried to deploy in the Zurich region, Ireland, as well as Frankfurt with the same result.
I am applying this stack: openemr-devops/packages/full_stack at master · openemr/openemr-devops · GitHub
Hi, Waro.
I don’t know why that’s still live but I probably need to delete it – full stack was something we outgrew a while back, and it wouldn’t launch even if you had the template because it relies on MySQL versions Amazon’s long-since retired.
In your shoes I’d consider either of “OpenEMR Standard”, which is just an OpenEMR instance backed by Amazon RDS, or taking a look at GitHub - openemr/host-openemr-on-aws-fargate , which is an Amazon-authored solution for launching OpenEMR with their Cloud Development Kit and covers the same general ground Full Stack did but with a much keener eye toward cutting-edge sensibilities.
Sorry for the confusion!
1 Like
Hi Asher,
That makes sense. Thank you for the insights. I will have a look at the version with Fargate!
One more question. I saw that I need to subscribe to the Marketplace for OpenEMR Standard. Are you describing somewhere how you build the AMI, so I could build it myself, or do I need to take the Marketplace version?
Take a look at openemr-devops/packages/standard/ami at master · openemr/openemr-devops · GitHub – run build, check the output log, then run seal. This is the AMI I submit to Marketplace staff. (The configure script is run after the CloudFormation stack launches the instance, inside the admin’s environment, for final loading of stack details, and you won’t need to adjust it for any sort of vanilla setup.)
Hi Asher,
Thank you for pointing me to it. I built the AMI, now trying to run the automated setup of openemr (since I am configuring infra via terraform, I need to take care of variables injected ).
Upon running docker compose up -d, I continue to receive the error that the setup assistant tries to connect via root user and root pw. I already tried changing the php setup command in the openemr.sh to include:
php auto_configure.php -c auto_configure.ini -f ${CONFIGURATION} root=openemr rootpass=“$MYSQL_PASS” no_root_db_access=1 || return 1
and the autoconfigure.php to hold the correct config (overwriting the root user/creds with regular user and creds as i don’t have a root user):
$installSettings = array();
$installSettings[‘iuser’] = ‘admin’;
$installSettings[‘iuname’] = ‘Administrator’;
$installSettings[‘iuserpass’] = ‘pass’;
$installSettings[‘igroup’] = ‘Default’;
$installSettings[‘server’] = ‘my-rds-endpoint’; // mysql server
$installSettings[‘loginhost’] = ‘localhost’; // php/apache server
$installSettings[‘port’] = ‘3306’;
$installSettings[‘root’] = ‘openemr’;
$installSettings[‘rootpass’] = ‘my-password’;
$installSettings[‘login’] = ‘openemr’;
$installSettings[‘pass’] = ‘my-password’;
$installSettings[‘dbname’] = ‘openemr’;
$installSettings[‘collate’] = ‘utf8mb4_general_ci’;
$installSettings[‘site’] = ‘default’;
$installSettings[‘source_site_id’] = ‘BLANK’;
$installSettings[‘clone_database’] = ‘BLANK’;
$installSettings[‘no_root_db_access’] = ‘BLANK’;
$installSettings[‘development_translations’] = ‘BLANK’;
furthermore I injected the config into sqlconf.php and i mounted these 3 files onto the container to persist. however I continue to get the error:
PHP Fatal error: Uncaught Exception: ERROR: unable to connect to database as root
in /var/www/localhost/htdocs/openemr/auto_configure.php:43
Stack trace:
#0 {main}
thrown in /var/www/localhost/htdocs/openemr/auto_configure.php on line 43
Couldn’t set up. Any of these reasons could be what’s wrong:
- You didn’t spin up a MySQL container or connect your OpenEMR container to a mysql instance
- MySQL is still starting up and wasn’t ready for connection yet
- The Mysql credentials were incorrect
mkdir: can’t create directory ‘/tmp/php-file-cache’: File exists
PHP Fatal error: Uncaught Exception: ERROR: unable to connect to database as root
in /var/www/localhost/htdocs/openemr/auto_configure.php:43
Is there a way for the automated setup to use the non root user? Or do you have a better idea?
It seems weird that you’d have to manipulate any PHP config like that – if you’re using our docker container, you can just pass envvars to it and it’ll know what to use.
openemr-devops/docker/openemr/7.0.3 at master · openemr/openemr-devops · GitHub gives an example docker-compose; you can use a different tool if you like, but this demonstrates what OpenEMR wants and where it wants it.
I was using this reference. The main difference is that this setup spins a mariadb container with root credentials that are expected from OpenEMR. If you are using RDS you don’t have that. Then you need to manipulate the auto_configure.php to set the no_db_root_user parameter to true for the automated setup to work otherwise you are stuck with the manual setup page.
It doesn’t have to be a root user, it just has to be a user with access to DDLs. The difference is so that you run OpenEMR with a less-permissioned user that can’t drop tables.
Take a look at openemr-devops/packages/standard/cfn/stack.py at master · openemr/openemr-devops · GitHub , line 911. That’s all we’re doing, we can use RDS just fine without touching the PHP.
You are right, I was missing the root user / pw environment variables in the docker-compose.yaml - that solved this particular problem. Is there an integrated way of skipping the auto_setup()? I want to run multiple ec2 instances in a HA setup (or even if i would restart an instance after the database has already been setup) - in that case the setup fails since the db has already been created.
Take a look at openemr-devops/kubernetes/openemr/deployment.yaml at master · openemr/openemr-devops · GitHub for the clue about how we handled that – you can either use SWARM_MODE to let instances nominate themselves as leaders, or (if you glance at openemr-devops/docker/openemr/7.0.3/openemr.sh at a26a043ec5ac244a9d41d8b2a09b678aae35828b · openemr/openemr-devops · GitHub ) you can see where you can actually set the roles an instance should play yourself – our thinking was that an instance could do one or both of being the leader who runs setups and upgrades and the runner who serves the application.
So you could have 1 master and 1 operator, or you could run setup as a job that ends – later on when you want to run an upgrade to a new version, you could terminate all the jobs, run a single authority node to pick up the upgrades and patch the database, and then when the container returns you could launch a new pack of runners.
1 Like