Support for CI Deployments

[joshuacurtiss]

These enhancements pave the way for CI deployments via GitHub Actions by installing a self-hosted runner on our target servers. It makes the script for accomplishing that more concise by providing a deploy command that goes through the typical steps for deploying our apps.

Enhancements to the GitHub Actions Runner installer

We already did the footwork of creating a script that helps automate the installation of a GitHub Actions runner. Now that we have real RedHat 9 servers, we were able to identify some necessary changes. For instance:

• Since most projects will be checked out with root and run in privileged podman containers, the github user that runs the runner service would need to have proper permissions. We don't want to assign more than it needs, so we gave it sudo permissions only for the deploy, docker, and git commands. We accomplish this by writing a separate file just for this purpose in /etc/sudoers.d/.
• We ensure the runner service is set up to run as the github user.
• If the chcon command is present, we know we're dealing with an SELinux system. We assign proper contexts so the service will work in SELinux.
• We automatically assign the runner a label of the hostname of the server.
• We set it to the latest version available for the runner installer.

The deploy command

The deploy command is made to properly run in a Docker or Podman environment. So, its installation was added as part of the "Docker/Podman" installation step for every environment (currently CentOS, RHEL, and macOS). The command has a nice help screen (deploy --help), but here is a brief description:

It will go through these steps:

• Login to your Docker repo
• Stop the application if it is currently running
• Create a pod (if using podman)
• Start up the stack using the stack path you point at
• Install the stack as a service (if using podman)

Some additional notes:

• If your deployment uses an environment variable name other then .env, you can use --env-file to specify the environment file.
• The --non-interactive flag skips the docker repository login step, which prompts the user for credentials. This can be used in CI scripts when we can't respond to user prompts.
• It provides easy ability to redeploy/upgrade, because it stops and starts the stack, and with the --upgrade flag, will pull for fresh images even if it already has them, which benefits configurations that do something like mariadb:10 to always point to the latest of that version.
• It's intelligent enough to be savvy of the situation where systemctl is not cognizant of newly-created services, and will gracefully handle the situation regardless of a docker, podman, or systemctl situation.

Bringing it all together

The deployment command makes it so that deploying or redeploying a UIC Pharmacy app can be done from one command. This means that deployment CI workflows can be created that are very concise. A good first use case to demonstrate this is prior-auth-drug-search - deploy.yml.