Flask App Deploy Template

The Flask App Deploy Template for Adaptable.io makes it simple to deploy an app written in Python using the Flask framework. In just a few clicks, Adaptable deploys all the cloud-based resources you need to run your Flask app, including:

• Building your app into Serverless Containers
• Fully-managed Serverless Database (MongoDB, PostgreSQL, or MS SQL Server)
• Autoscaling
• Load Balancing
• HTTPS (SSL/TLS)

»Using this template

For step-by-step instructions on how to deploy your existing Flask app with this template, check out the App Guide for Deploying a Flask App.

»About this template

This deploy template uses the Adapt.js infrastructure description language, which is based on React. It is open source and is available on GitHub.

»Template settings

»Python version

Sets the version of Python to use for your app. The same Python version will be used for both building the container image and for running your app instances.

Each time you deploy a new app revision on Adaptable, the latest version of Python that the template supports within your chosen major + minor version will be used to build and run your app.

The template supports Python versions in bugfix and security status. If you require a different version of Python contact Adaptable support.

To find the version of Python you're currently using in your development environment, use the command python --version and take only the first two numbers.

Default: 3.11

»Start command

Specifies the command to run to start your app. Set this to a command that runs the production version of your app.

The Start Command value will be executed as a shell script, so you may use environment variables and other shell features.

When a value for this setting is provided, it overrides start commands specified via Procfile or package manager. See Specifying a start command for more information.

Default: No start command is specified

»Runtime Environment Variables

You can specify your own custom environment variables that will be available to your app while it is running. For more information on setting custom environment variables, see Customizing Your App Environment.

The template also automatically provides several pre-set environment variables to your app at runtime:

• ADAPTABLE_TRUST_PROXY_DEPTH: When this variable is set, it indicates that the app is behind one or more reverse proxies. The value is an integer number of proxies that your app may trust in the X-Forwarded-For HTTP request header. If this variable is set, the X-Forwarded-Proto and X-Forwarded-Host HTTP request headers may also be trusted.

• DATABASE_URL: This is the URL that your app should use to contact the database provisioned alongside your app. It will include the database protocol, port, and hostname, as well as the username, password, and specific database to connect to. It may also have additional query parameters containing database options. This URL can often be used directly by a library such as Sequelize. If you manually parse this URL, be aware that all special characters in each portion of the URL have been URL-encoded and should be decoded before use.
  Example: postgres://dbuser:secret@database-1.adaptable.io:1234/my-app-db?option=enabled

• EXTERNAL_HOSTNAME: This is the externally visible host and domain name for your app.
  Example: my-app.adaptable.app

• EXTERNAL_URL: This is the externally visible URL where your app users can contact your app. This will always begin with https://.
  Example: https://my-app.adaptable.app

• PORT: The TCP port that your app must listen on to receive incoming network requests. Your app is required to listen on this port. See containerized app requirements for more information.

Apps that use a PostgreSQL database will also have the following environment variables set:

• PGDATABASE: The name of the database to connect to.

• PGHOST: The hostname of the database cluster.

• PGPASSWORD: The password to use when connecting to the database. Note that this environment variable may contain special characters.

• PGPORT: The TCP port number to connect to.

• PGSSLMODE: Specifies whether to negotiate SSL/TLS with the database cluster. In Adaptable, this will always be verify-full. Adaptable-provisioned PostgreSQL databases require the use of SSL/TLS.

• PGSSLROOTCERT: Path to a file containing SSL/TLS root certificates associated with the database cluster. In order for your PostgreSQL client to verify the database cluster's certificate, you must correctly configure your PostgreSQL client to verify using this root certificate.

• PGUSER: The username to use when connecting to the database.

Apps that use a Microsoft SQL Server database will also have the following environment variables set:

• MSSQL_DATABASE: The name of the database to connect to.

• MSSQL_HOST: The hostname of the database cluster.

• MSSQL_PASSWORD: The password to use when connecting to the database. Note that this environment variable may contain special characters.

• MSSQL_TCP_PORT: The TCP port number to connect to.

• MSSQL_USER: The username to use when connecting to the database.

»Build Environment Variables

You can specify your own custom environment variables that will be available to your app during the image build process. For more information on setting custom environment variables, see Customizing Your App Environment.

»Resources created

When this template is used to deploy your app, it creates the following Adaptable Cloud resources:

»Serverless database

The first time your app is deployed, the template creates a fully-managed serverless database that your app can use to store its data.

This template supports MongoDB, PostgreSQL, and Microsoft SQL Server.

Connection information for the database is provided directly to your running app via the DATABASE_URL environment variable.

»Load balancer

The template creates an HTTPS load balancer that sits in front of your app. This means that your deployed app immediately supports TLS encryption and advanced protocols like HTTP/2 and HTTP/3 without having to change your app source code.

»Container image

The template automatically builds your app source code from your GitHub repo into a Kubernetes-compatible container image each time you push to your selected branch on GitHub.

It uses Cloud Native Buildpacks to build the image, then pushes it to your app's private container registry.

To provide environment variables that can be accessed during the image build process, see Build Environment.

»Serverless containers

After the template builds your app into a container image, it deploys that image to the Adaptable Container Service, which is a highly scalable serverless platform based on Kubernetes.

»Package manager

This template supports four package management options:

• Pip
• Pipenv
• Miniconda
• Poetry

»Pip

Installation of dependencies with Pip is triggered by including a valid requirements.txt at the root of your repo.

»Pipenv

Installation of dependencies with Pipenv is triggered by including a valid Pipfile at the root of your repo.

»Miniconda

Including either an environment.yml or package-list.txt file at the root of your repo will trigger Miniconda to install dependencies and create a conda environment.

»Poetry

Including a pyproject.toml at the root of your repo will trigger Poetry to install dependencies and create a virtual environment.

When using Poetry, the start command for your app can be set via your pyproject.toml file. For example, you could have a pyproject.toml file that includes the following:

[tool.poetry.scripts]
my-script = "my_module:main"

This would cause your app to be started with the command line:

poetry run my-script

»Specifying a start command

For Adaptable to run your app, you must specify the command line that Adaptable should execute to run your app. Adaptable will look for your app's start command in a few places. It will try them in the order listed below and use the command from the first one it finds.

1. Start Command template setting

The easiest way to specify the start command for your app is to use the Start Command setting of the template. You can find this setting by going to the App Status page for your app, clicking on the Settings tab, and then clicking on Python Settings. You can then type your app's start command into the Start Command box. Then click Save settings and update deployment for the change to take effect.

See Deploy templates and app environment for more information on changing app settings.

The Start Command value will be executed as a shell script, so you may use environment variables and other shell features.

Example:

python main.py --port=$PORT

2. Procfile

You can also specify the start command by creating a file in the root of your source code repo called Procfile. The file should contain a line that starts with web:, followed by your app's start command.

Example:

web: python main.py

3. Poetry script

If the root of your source code repo contains a pyproject.toml file and that file contains exactly one Poetry script, your app will be started by executing poetry run <script-name>.

Example pyproject.toml file:

[tool.poetry.scripts]
some-script = "some.module:some_method"

For this example, the resulting start command would be: poetry run some-script

For more information, see the poetry run documentation.

»Pre-flight checks

This template includes a set of pre-flight checks that are performed before your app is deployed. These checks help ensure your app meets certain requirements and can identify some common issues before deployment.

»Check: Start command

This checks that you've provided a command for Adaptable to use to start your app. Although you can choose to specify a start command in more than one way, we recommend you use the Start Command Template Setting.

If this check fails:

• Click the Back button to go back two steps to the Template Settings step. Click the Change button next to Start Command and enter the command that you use to start your app.

gunicorn --bind=0.0.0.0:$PORT --workers=4 "myapp:start_app()"

»Check: Template settings validated

This checks that your Adaptable app's settings object matches the structure required by the template. Normally, Adaptable checks this each time you modify your app's settings and will not allow you to save invalid settings.

If this check fails:

• Contact Adaptable support with any error message you receive.

»Check: HTTP Listener on PORT

In order to run your app on the Adaptable Container Service, it must be an app that listens for HTTP requests. More specifically, it must listen on IP address 0.0.0.0 on the TCP port specified by the PORT environment variable.

For help on setting up your app to listen for HTTP requests correctly, see the Deploying a Flask App Guide. The guide walks you through setting up gunicorn as a production web server and using the Start Command setting to correctly listen for HTTP requests.

This check cannot be done automatically by analyzing your app's source code, so the first time your app is deployed on Adaptable, you'll be asked to click the checkbox that confirms that your app will listen on the port specified by PORT.

If you have a different kind of app that you'd like to deploy or if you need help getting your app set up correctly, we can help! Contact Adaptable's friendly support team for more information.

»Additional app requirements

»Containerized app requirements

In order to run your app on the Adaptable Container Service, it must meet a few requirements. Most web-based apps shouldn't have trouble meeting these requirements.

• Your app must listen for HTTP requests on 0.0.0.0 on the TCP port specified by the PORT environment variable. (Alternatively, your app can listen on a fixed port, but you will have to specify this PORT in your App's settings after the first failed deploy.)

• Your app must be stateless. Although your app can write to local disk storage, that storage is a memory file system and will be lost when your app is scaled down or updated. Local disk storage is also not shared between multiple autoscaled instances of your app. This means your app cannot use local file-based databases, such as NeDB or SQLite.

• Your app cannot perform background activities outside the scope of request handling. Your app's CPU allocation is set to zero when your app is not processing a network request.

• You should not perform HTTPS/TLS in your app itself. Adaptable automatically provides HTTPS/TLS via our highly scalable load balancing tier.

• When your app starts, it must listen for HTTP requests within 4 minutes of being started.