Web service voor het LED-display
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 
 
led-display/{{cookiecutter.app_name}}
Andrey Kobyshev 510934cd58 Fix issue 654 4 years ago
..
assets Fix linting issues 5 years ago
requirements Bump environs in /{{cookiecutter.app_name}}/requirements 4 years ago
shell_scripts Implement docker environment 5 years ago
supervisord_programs Implement docker environment 5 years ago
tests Remove deprecated flask-webpack library 5 years ago
{{cookiecutter.app_name}} Include all image files by default 5 years ago
.env.example Remove deprecated flask-webpack library 5 years ago
.eslintrc created travis: npm run lint and npm run build 7 years ago
.gitignore Remove deprecated flask-webpack library 5 years ago
.travis.yml Remove reduntant comand from .travis.yml 5 years ago
Dockerfile Add /home to pipenv manage folder structure 5 years ago
LICENSE Switch to MIT license 5 years ago
Pipfile Bump environs from 7.0.0 to 7.1.0 in /{{cookiecutter.app_name}} 4 years ago
Procfile Add heroku deployment feature 5 years ago
README.md Update README instructions 5 years ago
app.json fixup! fixup! Add heroku deployment feature 5 years ago
autoapp.py Use environment variables for configuration 6 years ago
docker-compose.yml Fix logging issue 5 years ago
package.json Bump url-loader from 2.3.0 to 3.0.0 in /{{cookiecutter.app_name}} 4 years ago
requirements.txt Remove deprecated flask-webpack library 5 years ago
setup.cfg Add black formatting 5 years ago
supervisord.conf Implement docker environment 5 years ago
webpack.config.js Fix issue 654 4 years ago

README.md

{{ cookiecutter.project_name }}

{{ cookiecutter.project_short_description}}

Docker Quickstart

This app can be run completely using Docker and docker-compose. Using Docker is recommended, as it guarantees the application is run using compatible versions of Python and Node.

There are three main services:

To run the development version of the app

docker-compose up flask-dev

To run the production version of the app

docker-compose up flask-prod

The list of environment: variables in the docker-compose.yml file takes precedence over any variables specified in .env.

To run any commands using the Flask CLI

docker-compose run --rm manage <<COMMAND>>

Therefore, to initialize a database you would run

docker-compose run --rm manage db init
docker-compose run --rm manage db migrate
docker-compose run --rm manage db upgrade

A docker volume node-modules is created to store NPM packages and is reused across the dev and prod versions of the application. For the purposes of DB testing with sqlite, the file dev.db is mounted to all containers. This volume mount should be removed from docker-compose.yml if a production DB server is used.

Running locally

Run the following commands to bootstrap your environment if you are unable to run the application using Docker

cd {{cookiecutter.app_name}}
{%- if cookiecutter.use_pipenv == "yes" %}
pipenv install --dev
pipenv shell
{%- else %}
pip install -r requirements/dev.txt
{%- endif %}
npm install
npm start  # run the webpack dev server and flask server using concurrently

You will see a pretty welcome screen.

Database Initialization (locally)

Once you have installed your DBMS, run the following to create your app's database tables and perform the initial migration

flask db init
flask db migrate
flask db upgrade

Deployment

When using Docker, reasonable production defaults are set in docker-compose.yml

FLASK_ENV=production
FLASK_DEBUG=0

Therefore, starting the app in "production" mode is as simple as

docker-compose up flask-prod

If running without Docker

export FLASK_ENV=production
export FLASK_DEBUG=0
export DATABASE_URL="<YOUR DATABASE URL>"
npm run build   # build assets with webpack
flask run       # start the flask server

Shell

To open the interactive shell, run

docker-compose run --rm manage db shell
flask shell # If running locally without Docker

By default, you will have access to the flask app.

Running Tests/Linter

To run all tests, run

docker-compose run --rm manage test
flask test # If running locally without Docker

To run the linter, run

docker-compose run --rm manage lint
flask lint # If running locally without Docker

The lint command will attempt to fix any linting/style errors in the code. If you only want to know if the code will pass CI and do not wish for the linter to make changes, add the --check argument.

Migrations

Whenever a database migration needs to be made. Run the following commands

docker-compose run --rm manage db migrate
flask db migrate # If running locally without Docker

This will generate a new migration script. Then run

docker-compose run --rm manage db upgrade
flask db upgrade # If running locally without Docker

To apply the migration.

For a full migration command reference, run docker-compose run --rm manage db --help.

If you will deploy your application remotely (e.g on Heroku) you should add the migrations folder to version control. You can do this after flask db migrate by running the following commands

git add migrations/*
git commit -m "Add migrations"

Make sure folder migrations/versions is not empty.

Asset Management

Files placed inside the assets directory and its subdirectories (excluding js and css) will be copied by webpack's file-loader into the static/build directory. In production, the plugin Flask-Static-Digest zips the webpack content and tags them with a MD5 hash. As a result, you must use the static_url_for function when including static content, as it resolves the correct file name, including the MD5 hash. For example

<link rel="shortcut icon" href="{{ "{{" }}static_url_for('static', filename='build/img/favicon.ico') {{ "}}" }}">

If all of your static files are managed this way, then their filenames will change whenever their contents do, and you can ask Flask to tell web browsers that they should cache all your assets forever by including the following line in .env:

SEND_FILE_MAX_AGE_DEFAULT=31556926  # one year

{%- if cookiecutter.use_heroku == "yes" %}

Heroku

Before deploying to Heroku you should be familiar with the basic concepts of Git and Heroku.

Remember to add migrations to your repository. Please check Migrations_ section.

Since the filesystem on Heroku is ephemeral, non-version controlled files (like a SQLite database) will be lost at least once every 24 hours. Therefore, a persistent, standalone database like PostgreSQL is recommended. This application will work with any database backend that is compatible with SQLAlchemy, but we provide specific instructions for Postgres, (including the required library psycopg2-binary).

Note: psycopg2-binary package is a practical choice for development and testing but in production it is advised to use the package built from sources. Read more in the psycopg2 documentation.

If you keep your project on GitHub you can use 'Deploy to Heroku' button thanks to which the deployment can be done in web browser with minimal configuration required. The configuration used by the button is stored in app.json file.

Deploy

Deployment by using Heroku CLI:

  • Create Heroku App. You can leave your app name, change it, or leave it blank (random name will be generated)

    heroku create {{cookiecutter.app_name}}
    
  • Add buildpacks

    heroku buildpacks:add --index=1 heroku/nodejs
    heroku buildpacks:add --index=1 heroku/python
    
  • Add database addon which creates a persistent PostgresSQL database. These instructions assume you're using the free hobby-dev plan. This command also sets a DATABASE_URL environmental variable that your app will use to communicate with the DB.

    heroku addons:create heroku-postgresql:hobby-dev --version=11
    
  • Set environmental variables (change SECRET_KEY value)

    heroku config:set SECRET_KEY=not-so-secret
    heroku config:set FLASK_APP=autoapp.py
    
  • Please check .env.example to see which environmental variables are used in the project and also need to be set. The exception is DATABASE_URL, which Heroku sets automatically.

  • Deploy on Heroku by pushing to the heroku branch

    git push heroku master
    

{%- endif %}