R/deployment.R
az_webapp_config_muggle.RdWraps the Azure Command-Line Interface (CLI) with defaults suitable for deploying a shiny app.
az_webapp_config_muggle( name = Sys.getenv("MUGGLE_PKG_NAME"), plan, resource_group, subscription, docker_registry_server_user = Sys.getenv("GITHUB_ACTOR"), docker_registry_server_password = Sys.getenv("GITHUB_TOKEN"), restart = FALSE )
| name | Name of the web app. |
|---|---|
| plan | Name or resource id of the app service plan. |
| resource_group | The Azure resource group to which the shiny app should belong. |
| subscription | Name or ID of the Azure subscription to which costs are billed. According to an upvoted answer on Stack Overflow, Azure subscription IDs need not be considered a secret or personal identifiable information (PII). However, depending your applicable context and policies, you may want to provide this argument as a secret. |
| docker_registry_server_user | Credentials for private container registries.
Defaults to |
| docker_registry_server_password | Credentials for private container registries.
Defaults to |
| restart | whether to restart the web app. |
Wrapping with muggle defaults; use only inside muggle projects.
Because muggle stores the docker images with the shiny runtimes on GitHub Packages, Azure must pull images from there, not the commonly used Docker Hub.
Currently, GitHub Packages does not offer public images,
even for public repositories
(#133)
That means that Azure must be
authenticated
to be able to download the runtime images.
This is the inverse of the the azure login GitHub Action,
which authenticates the GitHub Actions runtime to talk to Azure.
There are (only) two ways to do this, both suboptimal (#132):
You can authenticate Azure with a personal access token (PAT) and the corresponding static GitHub username. No matter who commits and triggered the deployment, always the same personal GitHub credentials (say, those of Jane Doe) will be used. To do this, the volunteering team member should create a PAT on GitHub, scope it minimally to only read packages, and paste that into the Azure web ui at portal.azure.com. A minimally scoped PAT may be reasonably safe, but the approach is still cumbersome and awkward.
You can authenticate Azure towards GitHub Packages
with the GITHUB_ACTOR and GITHUB_TOKEN pair
furnished
for GitHub Actions, from which the deployment takes place.
The GITHUB_ACTOR environment variable will always be
the GitHub username of whoever triggered the workflow run,
and therefore, the deployment.
The GITHUB_TOKEN is a PAT scoped to only that repo and will expire
automatically after the workflow run is completed.
To use this authentication, use the below defaults and expose the
GITHUB_TOKEN to in your workflow *.yaml file.
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
This is a more elegant, and arguably more secure solution,
though the GITHUB_TOKEN still has more scope than just to read packages,
if only for the repo in question.
This form of authentication seems to work reliably,
but may break future app (re)starts on Azure:
Should Azure loose the docker cache of the image in question,
it will not be able to docker pull the image again,
because the GITHUB_TOKEN will have expired by then.
Only a new workflow run can heal the app in this scenario.
It remains to be seen how common this problem is.
az_webapp_shiny_opts: Set shiny options as required for an Azure Webapp:
options(shiny.port = as.integer(Sys.getenv('PORT')).
Your custom container is expected to listen on PORT, an environment variable set by Azure.
If your image suggests EXPOSEd ports, that may be respected by Azure (undocumented behavior).
options(shiny.host = "0.0.0.0") to make your shiny application accessable to the Azure Webapp hosting environment.
You can also set these options manually as in the below example.
NULL #> NULL