Make docker-compose not configurable

[PerchunPak]

Description

This will make docker-compose.yml not configurable. Only OpenVPN can be configured. Reason of this: I really hate resolve "merge-conflicts" when updating my docker-compose system. I just want use git pull && docker-compose pull to update without anything else. This PR make it possible, now you don't need disable half of file.

Cons:

• Breaking change.
• If your IP blocked in GitHub, you can't download config with updater. May be fixed with Added mirrors for config. #205 (you really need fix?).

Migrations

You need rename your provider01.txt (and/or provider02.txt) to auth.txt, also you need re-check your provider*.conf files, and configure it to work with one user (from auth.txt, insteand of provider01.txt or provider02.txt).
And you need rename provider*.conf to provider*.ovpn (example provider01.endpoint02.conf to provider01.ovpn).

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

• docker-compose up -d

Test Configuration

• Release version: 779eb7f with v0.8.10
• Platform: Any, which support docker.

Logs

• No logs.

Screenshots

• No screenshot

[arriven]

Ideally I'd want to have both this static version and old example of having multiple different providers present. Can you move that old version to the examples folder? (Also while you're at it could you change config/examples to examples/config so that everything would use that same pattern?)

[PerchunPak]

Moving this in example folder will ruin all sense of this PR. I want make updates with just few commands, instead of moving all edited files and after pull, move it back. Also there is only one feature that this config not support comparing with previous - provider02* files, but you really need few programs runned at once? It is actually have no sence, because one will be more effective and optimised.
Oh, and one more feature that I can't realise in static configuration - optional updater. But as I mention above:

[arriven]

This docker compose doesn't depend on any files in the repo except those provider ones so you can have that immutable use case regardless of the folder it's in (yeah, you'd need to have one initial migration if we do move the folder but the risk of that happening again is low). The reason I want to move this to a folder is because the repo grows and becomes harder to manage if everything is at root level and grouping related things together helps with that (I also want to move terraform and kubernetes there following the same logic)
As for keeping the old version of this compose file there is a benefit of having multiple vpn providers - if one goes temporarily down you still have others + it allows to disperse the traffic and make it harder to block attacks based on IP/geo so I want to at least have some reference for people on how to achieve that

[PerchunPak]

benefit of having multiple vpn providers - if one goes temporarily down you still have others + it allows to disperse the traffic and make it harder to block attacks based on IP/geo

This will work normaly only if tool will have build-in feature for proxies support, but seems like someone deleted it. Also 2 VPN providers not achieve this milestone, and increase this integer will just increese CPU consumption in geometry progression.

Anyway I will move it to examples folder.

[arriven]

Not exactly what I meant (I thought you'd move ovpn folder so that it stays the same relative to the compose file) but this also works

[arriven]

As for 1 vpn vs multiple vpns vs proxies - proxylist is the easiest one to setup globally but it only supports some of attacks (I'm not sure if you can send upd or raw ip traffic through it, at least using standard go library). VPN doesn't have that issue and multiple vpns are just a way for someone to make the vpn setup more robust. The best way is to actually deploy the app to multiple small cloud machines but that's a separate discussion