I’m trying to set up a docker container of InfluxDB 2 after being on the beta version of 2.0 for a very long time. I want to keep the old 9999 port, however, so I have the following setup in my docker-compose file:
It’s a bit strange that the image is old, as the docker hub page for influx says that latest and 2.0 are equivalent. However i was getting the image by influx/influx:latest which may be completely different.
However, while I can now mostly setup the influx bucket, it takes 12 seconds to startup the container, compared to 5 seconds with the beta. Using the environment variables is even worse - it now takes 24 seconds to startup the bucket on my system, because the influx server (according to the logs) is started, setup, shutdown and restarted.
Additionally, the only way to get it to accept a port of 9999 is to, in the compose files, go
ports:
- "9999:8086"
Because without this the server cannot be connected to via 9999 (that is, the environment variable bind doesn’t work)
It seems that running the the docker exec myInfluxContainer bash -c "influx setup -o myOrg..." command always expects the server to be at 8086, even if the bind address is set to 9999.
For example, with - INFLUXD_HTTP_BIND_ADDRESS=:9999 but also running the above exec command, I get this error:
Error: failed to determine if instance has been configured: Get "http://localhost:8086/api/v2/setup": dial tcp 127.0.0.1:8086: connect: connection refused
Is the reduced speed of startup and the exec command being unaware of the nature of the bind-port supposed to be happening?
latest vs 2.0 isn’t the issue (you could use influxdb:latest, but I’d strongly discourage against it, as you’ll get major changes without any warning). As you suggested, the problem was that influx/influx is an entirely separate Docker repository from influxdb. Did you see influx/influx mentioned in any documentation? We don’t maintain it any more (I didn’t even know it existed), so we should make sure it’s not being advertised.
I’m not surprised by the behavior you’re seeing using the new image.
The system runs metadata migrations on startup, which burns time on initial boot (but should be quicker on subsequent boots)
The start-shutdown-restart behavior you describe is a choice we made in the auto-setup/auto-upgrade path, to avoid exposing the server on the user-requested port until it’s been fully initialized (this again should only happen once, as long as you’re persisting your data volume between container reboots)
Ensuring that influx setup knows the bind-port of the server is a piece of the logic performed by auto-setup, so you need to replicate that logic when setting up manually (you can either set INFLUX_HOST=localhost:9999 in the env or pass --host localhost:9999 to the setup call)
@dan-moran The two commands by default have errors, unfortunately.
using localhost:9999 I get
Error: failed to determine if instance has been configured: Get "localhost:9999": unsupported protocol scheme "localhost"
And I use http://localhost:9999 instead, I get
Error: failed to determine if instance has been configured: Get "http://localhost:9999/api/v2/setup": dial tcp 127.0.0.1:9999: connect: connection refused
To get it to cooperate, I needed to have both port setting commands present at the same time, that being,
environment:
- INFLUXD_HTTP_BIND_ADDRESS=:9999
AND
influx setup --host http://localhost:9999
Then, combining these two with
ports:
- "9999:9999"
In the docker compose meant that my program could now connect.
Good to know at least that the slowdown is intentional. I didn’t see influx/influx mentioned in any documentation; all I was going off on was the old quay image and using that syntax.