It depends on how one launches the containers. Say for example that instead of creating separate networks for the containers, one wanted to use a single network and use different container ports for multiple instances of the same container type. In that scenario, you would need to expose the different container ports to the outside world as there wouldn’t be a way to do 1:1 port mapping.
The way around that is not straight forward. For example, one way would be to use a different docker network subnet, start the containers with different container ports, manually assign the “external” IP addresses to the desired containers and then set up routing rules to forward the external IP address to the container, and set up iptables rules to allow the traffic. Also, you’d want to make sure that this configuration is done via config files on the host so that a failure/reboot of the host doesn’t lose all of this custom setup. But this still doesn’t account for manually configuring the external IP addresses on the containers.
One might argue for configuring docker networks with subnets that include the respective /32 IP addresses and then starting the containers with the failover IP address. But not knowing precisely how the routing is handled in the provider’s network such that the traffic is appropriately routed to the host in the first place, it’s hard to know whether this is feasible or not. The directions that the provider gives only refers to adding the failover IP address as an “alias” address on the host’s interface. Who knows if that falls apart when you rather put that IP address on the container and then add custom routing/iptables rules.
All the while, configuring the external IPs as an alias IP address on the host’s interfaces is supported by the provider already and adding port mappings (including the desired IP addresses) is a configuration supported by Docker. I don’t know how many ports the containers must make externally available, but my money would be to bite the bullet and configure as many port mappings as is needed for the application rather than having to explain to the provider and/or Docker support person what I’ve done to achieve the same thing differently when something goes astray.