-
Notifications
You must be signed in to change notification settings - Fork 159
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
Add dev docker-compose file to manage supporting services #525
Conversation
0821161
to
67c6397
Compare
Is work still ongoing on this PR? I have just set up my own dev environment to work on central-backend and central-frontend & documented the process. I plan to submit my documentation for review, but should I also commit the dev setup changes? |
Hi @spwoodcock, I will be working again on this PR next week, particularly removing duplicate *.json.dev.template from the individual services. Can you please share your setup, is it a different approach? Maybe we can combine both. |
Certainly! I made a PR in our repo to more easily show the changes: https://github.com/hotosm/odkcentral/pull/1/files My main goal was to make setting up a dev environment as easy as possible, with files mounted in the container for hot reload (on the backend). I planned to do the same for the frontend, running the dev server with hot reloading, but we may need to update I extended from the existing Hope this helps - I'm more than happy to contribute to this PR if needed. |
73d14ba
to
5f75938
Compare
849db32
to
1f84b0b
Compare
* Added Makefile for quick start and stop * Modified start-enketo.sh for dev with hardcode secrets, single redis config * Modified start-postgres.sh to listen postgres14-upgrade even if data directory is absent * Added instruction in README.md
1f84b0b
to
c32828c
Compare
Anything to make this easier v welcome 👏 I've run |
@sadiqkhoja is away for the next couple weeks so I'll try to answer questions as best I can!
I believe the current intended usage is that you would then run frontend and backend locally and they would have access to Enketo, pyxform, etc. |
docker-compose.dev.yml
Outdated
# Sets profiles for each service depending on whether that | ||
# service is required for development of that particular application | ||
# For Central be/fe development, we need postgres14, pyxform, enketo, redis_main | ||
# For Enketo development, we need postgres14, service, nginx, redis_main |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove stale comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done.
I believe the idea is that the supporting services are more complex to get up and running. The involve knowledge Central dev doesn't require and some have lots of dependencies to manage. The goal is to have a way to get them up and running that is as close to the production configuration as possible and that doesn't risk getting out of date. You can see a different angle from @spwoodcock which targets also containerizing frontend and backend for dev: https://github.com/hotosm/odkcentral/pull/1/files#diff-97db29a7915320e63d41d38a0440360a87055ee8ed03757aa263116dbbb4aabe That approach gets to what @moise10r is after with getodk/central-frontend#1048 If we go in that direction, we should make sure there is an answer for hot reloading and debugging. We should also make sure the maintenance burden/risk of it getting out of sync is worth it. |
Some queries inline, but in general I'd say if this PR is useful for @sadiqkhoja in its current form then it should be merged. If others use it, then they can iron out issues or improve things with fresh PRs going forwards. |
docker-compose.dev.yml
Outdated
profiles: | ||
- central | ||
# changing port here - can't use `ports` mapping with host networking | ||
command: ["gunicorn", "--bind", "0.0.0.0:5001", "--workers", "5", "--timeout", "600", "--max-requests", "1", "--max-requests-jitter", "3", "main:app()"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems like a significant deviation from the parent docker-compose.yml
. Is this running pyxform
from source?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is just overriding the port in the command of the pyxform-http docker file: https://github.com/getodk/pyxform-http/blob/master/Dockerfile
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could the standard command
be used, and this container's port 80
be exposed locally on port 5001
? That would seem to simplify this section, and also protect against future divergence.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't expose ports
when using host
networking mode. And host
networking is required so that Enketo can communicate with Central via http://localhost:8989
, which is running on the host.
I know we can use host.docker.internal
to access services running on the host from the bridge
container but configuration in Enketo and Central doesn't really support that. For example, Central uses env.domain
to generate URLs in OpenRosa manifest, whose value is http://localhost:8989
in local environment.
I had tried modifying /etc/hosts
file in the Enketo container to map localhost
to the IP assigned by docker to the host.docker.internal
but Enketo using discontinued/deprecated request.js
doesn't respects values in host file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
using discontinued/deprecated request.js doesn't respects values in host file.
Have you got a source for this? I couldn't find anything obvious in the request
issue tracker.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The way requestjs resolves domain name has to do with it:
Note: above issue closed due to staleness
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm having trouble reproducing this issue. Is it possible this has been resolved by enketo's move to @cypress/request
(introduced by 37b8f8b2f0b057e7adaa2da472f88ab8a5e460e0 in April 2024)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was trying to map localhost
to the IP Address of host-gateway
in Enketo container, that didn't work. Localhost was still resolving to 127.0.0.1.
So I ended up adding a custom domain in my local hosts file and changing default.env.domain
to that host in the backend repository and now everything works. I have to access central via that custom host instead of localhost, which is fine. I have updated the instructions in readme file as well.
files/enketo/start-enketo.sh
Outdated
sed -i -e 's/enketo_redis_main/localhost/g' \ | ||
-e 's/enketo_redis_cache/localhost/g' \ | ||
-e 's/6380/6379/g' "$CONFIG_PATH.template" | ||
fi |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this change to reduce the number of redis containers required? If so, is the increased complexity in these scripts and the deviation from the standard docker-compose.yml
worth the savings?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree. Originally I wanted this PR to facilitate Enketo development as well and Enketo suggests to run only one redis in development for the easiness. I have now removed the port substitution from this command and starting two redis instances.
I still need to substitute enketo_redis_main
and enketo_redis_cache
with localhost because of host network mode.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still need to substitute
enketo_redis_main
andenketo_redis_cache
with localhost because of host network mode.
Similar to pyxform
config above, it would be great if there was a way to achieve this without having to modify files/enketo/start-enketo.sh
and make fragile changes with sed
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
removed.
- Start two instances of redis - remove readlink - use postgres service to create data dir and .postgres14-upgrade-successful
558b8ff
to
ac7d68a
Compare
docker-compose.dev.yml
Outdated
profiles: | ||
- central | ||
volumes: | ||
dev_secrets: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
any chance of a trailing newline?
Looking nicely self-contained now 👍 |
ac7d68a
to
aa4df38
Compare
Changes
profiles
attribute to control which services are needed for the development workflow.Additionally, network_mode is set tohost
driver so that bidirectional communication is possible. Bottleneck forbridge
mode is Enketo which for some reason does not honor /etc/hosts for localhost, I was able to make it work with code modification on the fly, which looked dirty to me. One caveat forhost
mode: this is not available for "Docker Desktop for Mac", works great with OrbStackAdded dev config templates fornginx
,enketo
andservice(central)
services. These dev templates have hardcodedlocalhost
endpointsTwo objectives I've kept in my mind to achieve this 1) Not to touch main
docker-compose.yml
that might cause unintended consequences 2) Not to modify application source codeWhat has been done to verify that this works as intended?
Verified locally. It would be great if all can try this and see if this is helpful.
How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?
Although I have modified enketo startup scripts, changes are contained in dev specific conditional block
Does this change require updates to documentation? If so, please file an issue here and include the link below.
None
Before submitting this PR, please make sure you have: