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

2019Q4 - 3.4 Investigate dockerization of webcompat.com application #109

Open
miketaylr opened this issue Oct 1, 2019 · 6 comments

Comments

@miketaylr
Copy link
Collaborator

commented Oct 1, 2019

No description provided.

@miketaylr miketaylr added this to Planned in 2019 Q4 OKRs Oct 1, 2019
@karlcow

This comment has been minimized.

Copy link

commented Oct 1, 2019

4791-conteneur-appart

@karlcow karlcow self-assigned this Oct 1, 2019
@karlcow

This comment has been minimized.

Copy link

commented Oct 2, 2019

@karlcow karlcow moved this from Planned to In progress in 2019 Q4 OKRs Oct 2, 2019
@karlcow

This comment has been minimized.

Copy link

commented Oct 10, 2019

Interesting take on the persistence of a sqlite db in between containers.

Persist the SQLite database between containers

Instead of trying to keep the container around, a much cleaner solution is to arrange for the database (or other files you’d like to persist) to be stored in the host’s filesystem. You can do this by adding another volume mount with -v to the run command. Here’s the full command, which stores the database with the source code:
https://developers.redhat.com/blog/2019/09/12/develop-with-flask-and-python-3-in-a-container-on-red-hat-enterprise-linux/

@karlcow

This comment has been minimized.

Copy link

commented Oct 16, 2019

HEROKU

The current webcompat metrics dashboard is being deployed through/on heroku. One of the benefits of heroku deployment is people getting PR individual URLs for testing. Kind of removing the need for a staging instance. Any PR is a staging instance.

This made me think that if we use docker only for deploying stuff, maybe we do not need docker and we could "just" shift to full heroku. I'm not a big fan of these solutions, maybe because of the habits of owning your own stuff and avoiding to rely on too many services.

Heroku has no file system. It means that we would need to change a couple of things.

  1. static assets hosting
  2. images hosting, see #108 (old and new) See also the S3 integration in Heroku.
  3. Sessions sqlite DB moved to Postgres
  4. topsites DB move to Postgres
  5. milestones.json which is created when the application starts as a caching mechanism. Maybe MongoDB solution.
  6. uwsgi seems usable on heroku. Or switch to gunicorn.
  7. Oh! and the domain name, but that seems easy to add custom domain name to heroku instances.

memcache and performances for Flask on heroku. Also check the notion of dyno for web concurrency with gunicorn on heroku.

That would do it.

@karlcow

This comment has been minimized.

Copy link

commented Oct 16, 2019

SHIV

Another proposal for deploying a simple app is Shiv. As explained on Shiv website

Shiv is a command line utility for building fully self contained Python zipapps as outlined in PEP 441 but with all their dependencies included! Shiv’s primary goal is making distributing Python applications fast & easy.

example of a deployment with a django app.

@karlcow

This comment has been minimized.

Copy link

commented Oct 16, 2019

PIKU

piku project The tiniest PaaS you've ever seen. Piku allows you to do git push deployments to your own servers.

piku codebase

The tiniest Heroku/CloudFoundry-like PaaS you've ever seen.
piku, inspired by dokku, allows you do git push deployments to your own servers.

This is very much in development right now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
2019 Q4 OKRs
  
In progress
2 participants
You can’t perform that action at this time.