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

Simplified docker compose deployment #706

Open
ClementNerma opened this issue Oct 13, 2024 · 2 comments
Open

Simplified docker compose deployment #706

ClementNerma opened this issue Oct 13, 2024 · 2 comments

Comments

@ClementNerma
Copy link

Hi there!

I've been very interested to use BigCapital, but I'm finding the docker compose deployment process to be too complex.

Basically, you have to clone a 60MB repository with quite a few files, use an alternative docker compose -f ... command to use the production file specifically, and it's "hardcoded" into the repository.

For instance, I want the volumes to point to a specific folder instead of being Docker named volumes. If I modify the production compose file, it will be overriden the next time I git pull this project.

Also, updating the install requires both to pull the repository and then to update the containers.

Would it be possible to have a simplified docker-compose.yml file which contains everything needed without any other dependency, i.e. without needing to clone a repository. This is what most self-hosted projects do and it's a lot easier to maintain in the long run.

Copy link

linear bot commented Oct 13, 2024

@mpkossen
Copy link

mpkossen commented Jan 5, 2025

I've been looking into this, and for the most part it should be fairly simply. However you can't avoid having to create some configuration files with the way things are currently set up. The only thing that seems to stand in the way is the migration container, which must be built whenever there's an update. It would be considerably easier if the webapp container handles database initialization and migration (that would apply also for BigCapital's production deployment).

Envoy should be optional for deployments, because most people won't need load balancing and have their own reverse proxy in place. If you leave that out, you could just have your proxy direct traffic to ports 80 and 3000 (for /api).

I'm also curious why MySQL has a my.cnf that binds it to 0.0.0.0, because the standard MySQL docker image listens on port 3306 by default without the need for additional configuration.

Finally, I don't think most deployments would need a customized redis configuration.

In summary, to achieve a simplified docker compose:

  1. Leave out Envoy and discard the my.cnf and redis.conf.
  2. Move database initialization and migration to app image.

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