4 ms·
Compose overrides are quite cool but can get very involved. An easier way is to make the port range dynamic by adding a prefix variable in .env/example.env. So
by theK 3y ago
Compose overrides are quite cool but can get very involved.
An easier way is to make the port range dynamic by adding a prefix variable in .env/example.env. So, once configured, the whole localdev binds to ports in the prefix range, eg: 342xx.
Experience shows that localdevs will need that env file anyway and adding this config step to the readme is quite effective.
- dennisy 3y agoCould you elaborate a little more here please?
- theK 3y agoWell, the idea is that your port mappings in the docker compose look roughly like this ``` ports: - "${PORT_PREFIX}01:80" ``` This means that devs can drive the port range that the project bind to by editing their .env file.
- nerdponx 3y agoI like this a lot. It works well alongside setting the compose project name. However I'd suggest at least specifying a default value so developers don't need to mess with version-controlled .env files to customize their local setups.
- theK 3y ago> However I'd suggest at least specifying a default value so developers don't need to mess with version-controlled .env That's a good point. Most of my projects tend to ship an `example.env` which documents each env var and introduces a sane default. When introducing the principle to projects some times a dev will complain about config drift and the like but experience in practice shows that these files tend to change a bit when introduced and then rarely at all so it really is not that much of a deal.
- melolife 3y agoEdit: see TheK's answer, which is virtually identical.