Quick Start Full Bench Support Deployment

[1ubuntuuser]

Is your feature request related to a problem? Please describe.
Not all frappe bench commands work. Currently, the production deployment requires apps to be built into docker images. This slows down the setup and means you can't quickly experiment with different apps in pre-production environment.

Describe the solution you'd like
A halfway point between full static deployment with multiple containers and the development containers stack to be used for testing out different apps and small scale deployments. Once you are happy with your apps and setup, you can choose to build the static frappe docker stack for performance and scale.

Describe alternatives you've considered

• Running all in one container
• repeatably rebuilding and deploying the server image for testing apps

Additional context
I'm happy for this to be shot down as a dumb idea. The performance of the development stack might be terrible. I don't know. My use case is I am building a system that initially will only need to support 20-40 users. I want to be able to interatively improve the interface/apps and at some point I want to the option to change over to the static production version to support hopefully many thousands of users. #811 See conversation on this here.

I don't mind the bloated size. It's big, but my alternative to erpnext was a mashup with 5 different apps.

Requirments

• Very few steps to deployment
• Documented migration of database and sites
• Bench command support

##Thoughts, suggestions, ideas?

[1ubuntuuser]

I can see in V14 modules (Healthcare, Non-profit etc.) are moving to separate apps. The ability to install these apps on the fly will be important I think.
frappe/erpnext#29151

[revant]

I'm not doing this (That means no one else will). You're free to send PR.

What I already do is build staging images just like production images.

1. I clone custom_frappe_docker as container_images (use .gitlab-ci.yml instead of github actions)
2. Sometimes this repo has 20+ apps in dockerfile and clone-script for some people!
3. on build of latest image, I add one job stage to deploy using portainer webhook to update services.
4. Loop repeats where developers and users interact on dedicated UAT server which gets auto deployed or when:manual depending on case (https://docs.gitlab.com/ee/ci/yaml/#when)
5. once the UAT image is accepted we bump the tag of the image by editing version.txt and tagged production image is released on to production stack.

Developers use frappe/bench:latest they are free to setup anything on their local devcontainer setup and try out.

I prefer the environments remain same for staging and production. Easier to replicate issues on staging that way.

[1ubuntuuser]

@revant Thanks for describing in detail what your process is.

I think you're right, it's probably better if staging and production are the same, but not everyone is comfortable with more advanced docker flows as you outlined above. It's just not accessible for most devs; even those who use docker regularly. I'll consider making a PR.

Do you think the development containers stack could handle low traffic in production?

[revant]

Do you think the development containers stack could handle low traffic in production?

refer these templates https://github.com/castlecraft/benchless/tree/master/templates

you'll need to start nginx with supervisor

[program:nginx]
command=nginx -c /etc/nginx/nginx.conf  -g 'daemon off;'
process_name={{ bench_dir }}-nginx
numprocs=1
autostart=true
startsecs=0
redirect_stderr=true
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0

[revant]

but not everyone is comfortable with more advanced docker flows as you outlined above.

for single developer, "I push to remote, pull from remote to vm" workflow makes sense.

We've multiple devs working on multiple sites and multiple apps, devops is automated by ci/cd to reduce confusion of who updated what last and devs can focus on releasing features multiple times a day than focusing on managing VM.

[1ubuntuuser]

Yes, that makes sence. I think I will make a PR in the next couple months.

[revant]

I'll close this Issue. Whenever you start the work on PR we can initiate new Issue/PR for discussion.

[1ubuntuuser]

Started working on this here:
https://github.com/MarqUnity/frappe_docker/tree/Quick_Start/quick-deploy

[revant]

I made this gist to use development bench for production. You need to additionally install nginx and supervisor.

https://gist.github.com/revant/010c058f7c485cc62f2cc4d604ab8511

If you use it in production and happy with usage, we'll add nginx and supervisor in frappe/bench image.

[1ubuntuuser]

Thanks for that, I missed your gist. Is the work I did with separating the files still worth while?

Could you explain why Nginx has to run inside the frappe bench container, could it run in it's own container with some shared folders?

[revant]

Thanks for that, I missed your gist. Is the work I did with separating the files still worth while?

if nginx and supervisor runs in Frappe bench container then we can just reuse current devcontainer-example just like mentioned in gist

Could you explain why Nginx has to run inside the frappe bench container, could it run in it's own container with some shared folders?

less containerized setup. more like a vm setup. if you wish to have separate containers use existing stable production setup.

check this to use supervisor to run nginx

https://www.novixys.com/blog/python-web-application-docker-nginx-uwsgi/#6_Supervisor

For TLS certificates and https access to sites under benches some volume mounting and configuration should make the certificates available for use by nginx. Renewal cron job needs to be figured out.

[1ubuntuuser]

hmmmm I see.. I'll see what I can come up with. As always, thanks for the information.

[1ubuntuuser]

Still testing with this, so perhaps don't close it yet.

[1ubuntuuser]

Things where going very well but I've hit a snag with SSL.

I successfully implemented certbot to very easily get ssl certificates generated and put where they belong. Now Nginx was supposed to dish up ssl certifactes based on the hostname, but apparently, it can't do that?

@revant's code kinda indicates it should, but the internet says dynamically loading certificates with host names isn't doable. Am I missing something?
https://github.com/castlecraft/benchless/blob/master/templates/nginx.conf.tmpl

    ssl_certificate      /etc/letsencrypt/live/$http_host/fullchain.pem;
    ssl_certificate_key  /etc/letsencrypt/live/$http_host/privkey.pem;

[revant]

I didn't test benchless with ssl.

If we have bench why do we need $http_host we can just use the bench setup nginx and the config generated by it.
It will have everything needed for ssl as well.

[1ubuntuuser]

we can just use the bench setup nginx and the config generated by it.
It will have everything needed for ssl as well.

That's where I started, but the output didn't contain any details regarding SSL so I assumed it wasn't supported. I think maybe I missed that the ssl certificates needs to be added to the site. https://frappeframework.com/docs/v14/user/en/bench/guides/lets-encrypt-ssl-setup

My only hesitation with the auto-created config is it seems to put each site on a different port, is this correct?

[revant]

My only hesitation with the auto-created config is it seems to put each site on a different port, is this correct?

in case of dns multitenant it should create each site with site_name

in case of port based multi tenant site gets created on different port.

refer: https://frappeframework.com/docs/v14/user/en/bench/guides/setup-multitenancy#dns-based-multitenancy

[revant]

https://github.com/castlecraft/frappe_containers

@1ubuntuuser check this.

it's single image that acts as different containers
i mounts VOLUME in build file.

It can be used as immutable container in traditional containerized setup and volume creation/cleanup will be handled by container engine.

check vm-like.compose.yml, it mounts volumes for apps, env, assets and sites, the set of containers act like vm. You enter any container and run full bench commands like get-app or build. only case here is, instead of supervisor you've to restart docker compose

[revant]

#1028