Flask Application Stack

The Flask application stack is used to build and deploy python based Flask applications and produce deployment-ready containers for the SCALE environment.

The containers produced in this application stack share common requirements with other application stacks deployed to the SCALE environment. These shared requirements include:

• Security scanning for any vulnerabilities
• Code coverage scanning for test quality
• Staging of the application container in the appropriate Docker container repositories and tagged according to SCALE conventions
• Completion of Unit Testing and User Acceptance Testing
• Gated approvals before allowing deployments into pre-production and production environments
• Audit trail and history of deployment within the SCALE CI/CD Pipeline

Because of the above-listed requirements, the Flask application stack is provided in order to support the build and deployment of Flask applications in a manner that integrates with SCALE requirements and processes. The flow of deployment includes first a Continuous Integration stage of processing in a pipeline prior to deployment in the Continuous Deployment stages. The Continuous Integration stage focuses on building the application, running scans to check for test coverage and security vulnerabilities, and staging the container in the appropriate Docker repository ready for deployment. Subsequent pipeline stages deploy the application to the appropriate target Kubernetes spaces.

For details on getting started, see getting started.

For details on repository structure, see repository structure.

The source directory contains boilerplate code creating a Flask application.

For details on application configuration, see application configuration.

For details on CI/CD pipelines, see CI/CD pipelines.

For details on upgrading to Pipeline v4.7, see upgrading to Pipeline v4.7.

For details on pipeline definition, see pipeline definition.

Application-Specific Pipeline Configuration

The extends YAML object is a complex object consisting of additional YAML objects. This object is used to extend the pipeline logic (referenced by the repository defined in the resources object) by (a) referencing the correct appstack pipeline entry point and (b) passing a set of YAML objects as parameters to influence the behavior of the pipeline to meet an application teams specific needs.

The extends YAML object consists of 2 objects beneath it:

• template
• parameters

The template YAML object is a single value set to the initial entry point for the v4.7 pipeline for the flask appstack, so it should always be defined as follows:

extends:
  template: devops/flask.yml@spaces

Please refer to upgrade document to know more about flask.yml@templates which holds required metadata for the pipeline.

The parameters YAML object is defined immediately following the template object and at the same indentation level. This is the object that requires the most attention and definition to be set up. The parameters YAML object includes multiple parameters which can be used to configure CI/CD pipeline. Primarily this object contains parameters used for application builds. A typical setting in here would be to define appVersion used to build the application, looking like the following (including all of the extends object preceding it):

extends:
  template: devops/flask.yml@spaces
  parameters:
      appVersion: 4.7.x

For details on defining hostspaces, see defining hostspaces.

For details on skipping deployments, see skipping deployments.

Flask: Support for custom pipenv

With SCALE CI/CD pipeline v4.7 release application teams can use specific pipenv version as per the requirement. Update azure-pipelines.yaml as below:

 parameters:
   appVersion: 4.7.0
   flask:
     python:  3.10.0 #minVersion supported 3.5.0
     pipenvVersion: 2022.7.24

Python version defaults to 3.10 and minimum supported version is 3.5.

For details on Horizontal Pod Autoscaler, see Horizontal Pod Autoscaler.

For details on PVC for application stacks, see PVC for application stacks.

DR changes

With the introduction of pipeline v4.7, we have implemented DR capabilities that require changes in the Helm chart. Please refer to the document below for the necessary modifications and kindly update your Helm chart accordingly.

Getting Started with DR

Please refer to the following document to prepare your codebase for disaster recovery.

DR Config Map and Ingress Setup

Note: We recommend upgrading the pipeline to v4.7 using the dxpctl tool. This tool will replace the Dockerfile with a boilerplate version. Please review the Dockerfile after the upgrade and reapply any custom changes you made to the file.

For details on Pod Anti-Affinity, see Pod Anti-Affinity.

For details on detailed pipeline configuration, see detailed pipeline configuration.

For details on Kubernetes deployment objects, see Kubernetes deployment objects.

Migration to Host from TLS Context

As per the recommendation from datawire, TLS context has been deprecated and replaced by new object Host, Host represents a domain in Ambassador Edge Stack and defines how the domain manages TLS. Note - Applications with custom URL must use Host.

For details on troubleshooting, see troubleshooting.

Local Development

Artifactory Token

Our Flask stack is configured to pull packages from our Artifactory instance. For local development, you may need to generate an Artifactory token for authentication.

1. Ensure that you are in at least 1 of the ng-ngdc-<appcode>-* groups for your application (see RBAC docs).
2. Log into the Artifactory UI using your SSO.
3. Click your user profile icon in the upper-right.
4. Click 'Edit Profile'.
5. Enter your SSO password and click 'Unlock'.
6. Click 'Generate an Identity Token'.
7. Provide a description for your new token and click 'Next'.
8. Use the provided token as the PYPI_TOKEN in the steps below.

Build Locally

1. Execute: docker login docker-ngdc.repo-hio.cloudone.netapp.com and sign in with your SSO.

2. Create a file PYPI_TOKEN.txt with the contents of your Artifactory Token.

3. (OPTIONAL) If you want/need to rebuild your Pipfile.lock, run the following command (replace SSO_USERNAME with yours and update the image version tag to match what is configured for production):

docker run -e PYPI_USER=<SSO_USERNAME> --rm -v "./source:/source" -w "/source" -e PYPI_TOKEN="$(cat ./PYPI_TOKEN.txt)" docker-ngdc.repo-hio.cloudone.netapp.com/library/python:3.10-slim sh -c 'pip install pipenv && pipenv lock'

4. Run the following command to build the docker image (replace SSO_USERNAME with yours and update the image version tag to match what is configured for production):

docker build --build-arg PYPI_USER=<SSO_USERNAME> --build-arg BASE_IMAGE="docker-ngdc.repo-hio.cloudone.netapp.com/library/python:3.10-slim" --secret id=PYPI_TOKEN,src=PYPI_TOKEN.txt -t flask:local .

Run Locally

docker run --rm --name flask -p 8080:8080 -v $(pwd)/source/api:/app/api:ro flask:local gunicorn -w 6 -b :8080 --reload 'api:create_app()'

You should be able to edit the files in the api directory and the app will automatically reload with your changes in a few seconds. No need to rebuild and restart the container.