Chatwoot: Enhancement: Docker setup cleanup

[mr-karan]

Is your enhancement request related to a problem? Please describe.
The Docker setup + docs are really confusing for a newcomer to this project. A few problems:

So, if I want to setup a chatwoot server with Docker what docs should I be looking at? This, this or this ?

All of the above pages have confusing information.

• There is no mention of tagged releases. Which should be encouraged, instead of asking users to clone this git repo and build it locally. Or using latest image. There are so many things that can go wrong with :latest images.
• There is conflicting information in this page. Most users who want a Quick Setup are NOT your contributors but people like me who just care about getting it up and running and nothing more. Why confuse them with a Development setup? To add to that, there is no mention of rake db:migrate command until you dig deep and find this.

• Upgrade instructions aren't clear. Update the images using the latest image from chatwoot is not enough information. Update how? In first doc you have mentioned to build it, but no where does it say to pull latest tagged release from Docker Hub.

Describe the solution you'd like
The Quick Start guide can have only the production setup. And mention about volumes, upgrading etc. The local setup can just move to a new page Contributing or something, I feel.

Also, it is very rare for someone to have custom entrypoints in the docker image. Maybe build your own image should NOT be prioritized in the docs, but guide users to pull the tagged releases and run it with docker-compose. Building images section can be optional for advanced users.

These things definitely create a friction when setting up Chatwoot IMHO. It's just a matter of rewording + adding some more info on docs. The project is awesome :rocket: and I'd hate to see people getting stuck at the zero'th step.

[pranavrajs]

@mr-karan Thanks for the suggestions. I understand the documentation is rough, we are trying to make it better. As a starting point let me split the documents into "Contribution guide" and "Deployment docs" so that the environment setup and project setup can be moved to "Contribution guide" which would make it a little bit better. We can start working from there.

[mr-karan]

@pranavrajs I'd love to help you out with this :) Also, I apologize if the above message sounded rant-y or too harsh. Please know that my intention was most definitely not that.

As a first, I reformatted the production docker-compose.yml. The changes:

• Uses tagged releases from DockerHub. Doesn't require people to build images locally
• Uses mounts with correct path (as mentioned in https://github.com/chatwoot/chatwoot/issues/1080 already). That is usually more preferred than Docker Volumes because you get more control over the directory path. The docker volumes require you to access them using Docker APIs. Anyway, if this isn't acceptable, we can still continue to use docker volumes, totally upto you to decide.

version: '3'

services:
  base: &base
    image: chatwoot/chatwoot:v1.6.3
    env_file: .env ## Change this file for customized env variables

  rails:
    <<: *base
    depends_on:
      - postgres
      - redis
    ports:
      - 80:3000
    environment:
      - NODE_ENV=production
      - RAILS_ENV=production
    entrypoint: docker/entrypoints/rails.sh
    command: ['bundle', 'exec', 'rails', 's', '-p', '3000', '-b', '0.0.0.0']

  sidekiq:
    <<: *base
    depends_on:
      - postgres
      - redis
    environment:
      - NODE_ENV=production
      - RAILS_ENV=production
    command: ['bundle', 'exec', 'sidekiq', '-C', 'config/sidekiq.yml']

  postgres:
    image: postgres:12
    restart: always
    ports:
      - '5432:5432'
    volumes:
      - /data/postgres:/var/lib/postgresql/data
    environment:
      - POSTGRES_DB=chatwoot
      - POSTGRES_USER=postgres
      # Please provide your own password.
      - POSTGRES_PASSWORD=

  redis:
    image: redis:alpine
    restart: always
    volumes:
      - /data/redis:/data
    ports:
      - '6379:6379'

So, if we use this, we can simply ask the user to docker-compose up instead of first docker-compose build (which has an inherent step of git clone too). This would simplify a majority of usecase for first-time setup.

Let me know how we should move forward on this :+1:

[pranavrajs]

@mr-karan Thanks for the comment. I really appreciate the effort you took to make it better.

The reason why we used docker-compose build instead of using a predefined tag, was to test whether the app is working fine in production. We were having issues which broke the docker builds in production only(like https://github.com/chatwoot/chatwoot/issues/458). production YAML file was introduced as a test and as a safeguard to make sure that the docker image we push to docker hub is working.

People started referring to this config as their production config. I believe this was a miss from our part where we didn't realize the end-users is relying too much on this config and they don't need to build the docker images. Honestly speaking, most of the people started using Caprover as their base installation which was easier than docker-compose. The feedback loop on this case was limited.

The config you have given above looks good to me. Could you create a PR which moves the existing config to something like docker-compose.test.yaml and use yours as production? Again appreciate the feedback. 👍