Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable hosting server at a non-root URL #1300

Merged
merged 2 commits into from Jul 2, 2018

Conversation

Projects
None yet
2 participants
@c-w
Copy link
Contributor

commented Jun 29, 2018

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.

@c-w c-w changed the title Enable hosting manager server at a non-root URL Enable hosting server at a non-root URL Jun 29, 2018

Enable hosting server at a non-root URL
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.
@colinschoen
Copy link
Member

left a comment

LGTM

@colinschoen colinschoen merged commit 61e341a into okpy:master Jul 2, 2018

3 checks passed

Travis CI - Pull Request Build Passed
Details
ci/circleci Your tests passed on CircleCI!
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@c-w c-w deleted the c-w:enhancement/c-w/enable-non-root-hosting branch Jul 2, 2018

Sumukh added a commit that referenced this pull request Jul 6, 2018

Switch Azure deployment to Kubernetes (#1301)
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
You can’t perform that action at this time.