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

Docker setup? #32

Open
ethanopp opened this issue Mar 20, 2020 · 1 comment
Open

Docker setup? #32

ethanopp opened this issue Mar 20, 2020 · 1 comment

Comments

@ethanopp
Copy link

Hey @ned2 - first off thanks for this amazing repo, it has helped me organize my own project substantially.

I'm working on a project that would let users self-host an analytical fitness application:
https://github.com/ethanopp/fitly

I'd like to add the ability for the users to be able to deploy via docker, and I currently have it working with the following docker-compose, but saw some benefits in your readme on using the apache prod script instead of an external (gunicorn in this case) server:

version: '3'
services:
  letsencrypt:
    image: linuxserver/letsencrypt
    container_name: letsencrypt 
    cap_add:
      - NET_ADMIN
    restart: always
    ports:
      - "80:80"
      - "443:443"
    environment:
      - PUID=1000
      - PGID=100
      - TZ=America/New_York
      - EMAIL=<your email>
      - URL=<website.com>
      - SUBDOMAINS=fit # this would give a website like fit.website.com
    volumes:
      - /share/CACHEDEV2_DATA/Container/LetsEncrypt:/config
  fitly:
    build:
      dockerfile: Dockerfile
    container_name: fitly
    restart: always
    depends_on:
      - letsencrypt
    ports:
      - "8050:80"
    environment:
      - MODULE_NAME=src.fitly.app
      - VARIABLE_NAME=server
      - TZ=America/New_York
      - TIMEOUT=1200
      - PUID=1000
      - PGID=100
      - DASH_DEBUG=true
    volumes:
      - /share/CACHEDEV2_DATA/Container/Fitly-Slap/fitness.db:/app/fitness.db
      - /share/CACHEDEV2_DATA/Container/Fitly-Slap/config.ini:/app/config.ini
      - /share/CACHEDEV2_DATA/Container/Fitly-Slap/log.log:/app/log.log
      - /share/CACHEDEV2_DATA/Container/Fitly-Slap/gunicorn_conf.py:/gunicorn_conf.py
      - /share/CACHEDEV2_DATA/Container/LetsEncrypt/keys:/app/keys

where fitly is built on the following Dockerfile:

FROM tiangolo/meinheld-gunicorn:python3.7
LABEL maintainer="maintainer"
RUN git clone https://github.com/ethanopp/fitly.git
RUN pip install -U pip && pip install -r ./fitly/requirements.txt
RUN mv ./fitly/* /app/ && rm -rf ./fitly
ENV NGINX_WORKER_PROCESSES auto

Would you happen to have any docs on how to get a docker container stood up which leverages the run-slug-prod script in your repo? Also just in general, is it worth it to switch over towards leveraging that approach or given that the users will most likely just be pulling the repo and deploying (not editing prod_settings, etc.), is the above okay?

@ned2
Copy link
Owner

ned2 commented May 4, 2020

Hey, sorry for the slow response. I'm afraid I haven't done any deployment on docker with slapdash projects. So am not in the best position to comment there. The advantage of using Apache is that it's less setup (compared to say gunicorn + nginx that's configured for static asset serving), with the potential downside that mod-wsgi can sometimes be a little fiddly to install on some systems.

The advantage of docker, is that only you have to worry about that initial env setup though. And then it just works for everyone. So I guess it really comes down to how much work you want to do setting up your docker image, and what functionality you want people to have working out of the box. I would go with mod-wsgi over gunicorn without nginx, as you're leaving people open to having their sites brought down much more easily under load.

Not sure how useful all that is. Hope it's helpful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants