Enable hosting server at a non-root URL #1300
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
c-w
changed the title
This change enables us to host the Flask OKpy server at a non-root URL, e.g. prefixing all the routes with `/foo`. The non-root URL host is enabled by setting the following environment variables: ``` SCRIPT_NAME=/foo APPLICATION_ROOT=/foo ``` Being able to host the application at a non-root URL enables use-cases such as for example a single SSL certificate and DNS entry being used for both the OKpy application and the AutoPY application with routing between the two applications being done by a URL prefix.
Sumukh
pushed a commit
that referenced
this pull request
Jul 6, 2018
Previously we were hosting the ok-server, ok-worker, autopy-manager and autopy-worker in AppService for containers. However, we were seeing some issues with this approach as workers were killed without death notifications and rq/Redis was getting confused. After this change, we now deploy the compute (workers and servers) to Azure Kubernetes service. In order to make it easier to orchestrate the setup of the various resources in Azure as well as the Kubernetes deployments, we're using bash scripts. First, we create a bunch of resources using `setup.sh` and then we configure them using `install.sh`. The setup scripts are wrapped in a Docker container so that the environment in which the scripts execute is well known, e.g. Azure CLI is installed, helm is available, kubectl is available, etc. Most of the setup scripts fall-back to ARM templates to create the resources in Azure. The ARM templates can be modified to configure parameters such as resource SKUs, number of VMs to spin up for the cluster, type of VMs to use in the cluster, etc. The install scripts perform operations such as creating the database schema, deploying the application to Kubernetes via Helm and setting up the DNS for the Kubernetes ingress via the Azure CLI so that kube-lego can configure a TLS certificate for the ingress via Let's Encrypt. Note that the ingress to the applications running in the Kubernetes cluster are configured as just one entrypoint so that a single TLS certificate and DNS entry can be used (Azure public IP resource currently only support a single DNS label per IP). To solve routing, we thus need to mount the two sub-applications (OKpy and AutoPY) at sub-urls of the ingress which requires some minor application changes which are submitted in a separate pull request: #1300 The setup scripts can be run either via the "Deploy to Azure" button (in which case the setup Docker container is run in an Azure Container Instance) or via a local `docker run` command. In the latter case, it's advised to also include a volume mount `docker run -v $PWD:/app/secrets` so that the access keys for the resources created during the deployment will be made available to the deployer. Note that in order to skip deploying specific resources (e.g. to re-use existing resources), you can place a file into the secrets folder that contains the access keys for your existing resources in which case the setup scripts will skip deploying that step.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change enables us to host the Flask OKpy server at a non-root URL, e.g.
prefixing all the routes with
/foo. The non-root URL host is enabled bysetting the following environment variables:
Being able to host the application at a non-root URL enables use-cases such as
for example a single SSL certificate and DNS entry being used for both the OKpy
application and the AutoPY application with routing between the two
applications being done by a URL prefix.