The port settings are ignored for my TF configuration or as command-line parameter above.
Starting RDS server on port 4510 (backend port 48549) - database "test", user "test" - data dir /var/lib/localstack/tmp/state/rds-data/us-east-1/db3-62aafa7f
Hi @zopyx , thanks for reporting. This is unfortunately a limitation in our current RDS implementation and the way how service ports are being managed. The point is that we’re reserving a certain port range (4510-4559 by default) when the LocalStack container starts up. This port range can then be used by services like RDS to allocate ports for new servers being spun up.
Since we need to set the port range at the container startup time (i.e., it cannot be changed later on), we currently do not support setting arbitrary ports for RDS DBs. Is this a big limitation for you - would it work for your use case to use the port number returned from the create-db-cluster operation? If not, we could look into allowing to specify a custom port as well… Thanks
Perhaps, it is not a real-world problem. Background: I am currently doing software consulting for a project where the architecture of the original project was basically driven by infrastructure needs. I am now trying to bring the developer experience (“local development first, deployment last”) into the scope of the reimplementation. I came across LocalStack at Europython and I see clearly some potential supporting this goal. I am currently in the state of trying things out, putting pieces together in order to line out a possible strategy for the project.
Regarding your remarks:
since developers recreate their Localstack environment possibly over and over again, I assume that port numbers e.g. of resources like a DB stay most of the time stable (we don’t intend to spin up dozens of database). So a developer will be able to handle that.
with an eye on deployment on AWS: Terraform is the technology to use (I am not very deep into TF). I assume that the port of a RDS database defined through TF would be available as input for e.g. environment variables for a lambda. The high-level idea (and hope) is to use the same TF configuration for local dev and deployment