I’ve been trying to run a custom initialization script on an InfluxDB 2.0 container based on the dockerhub documentation. Just to make sure I got the basics right, I created a dummy script named setup.sh under a local directory in my Docker host, which I later mounted to /docker-entrypoint-initdb.d on the container. The script simply echoes some text into a file as follows:
#!/bin/bash
echo I should be running > /temp.txt
I deployed the container with this command: docker run -d -p 8086:8086 -v $PWD/data:/var/lib/influxdb2 -v $PWD/scripts:/docker-entrypoint-initdb.d -e DOCKER_INFLUXDB_INIT_MODE=setup -e DOCKER_INFLUXDB_INIT_USERNAME=influx -e DOCKER_INFLUXDB_INIT_PASSWORD=my-password -e DOCKER_INFLUXDB_INIT_ORG=my-org -e DOCKER_INFLUXDB_INIT_BUCKET=my-bucket -e DOCKER_INFLUXDB_INIT_ADMIN_TOKEN=super-secret-token --network=my-net --name=influxdb influxdb:2.0
The automated setup has completed successfully and I was able to log in from the UI and see my bucket. However, it appears the custom script was never executed.
I verified the script was present within the container under /docker-entrypoint-initdb.d and also ran it manually with docker exec to make sure it’s not throwing errors for some reason. Looks like it’s just being ignored during startup.
As a side note, the docs also mention that the image should export a bunch of environment variables before running any of the custom scripts. I noticed that other than INFLUX_CONFIGS_PATH, all of them were non-existent.
As a convenience for script-writers, the image will export a number of variables into the environment before executing any scripts:
INFLUX_CONFIGS_PATH : Path to the CLI configs file written by setup / upgrade
INFLUX_HOST : URL to the influxd instance running setup logic
DOCKER_INFLUXDB_INIT_USER_ID : ID of the initial admin user created by setup / upgrade
DOCKER_INFLUXDB_INIT_ORG_ID : ID of the initial organization created by setup / upgrade
DOCKER_INFLUXDB_INIT_BUCKET_ID : ID of the initial bucket created by setup / upgrade
Thanks for your reply @Anaisdg, but could you please point out where it answers my question regarding the exported environment variables? The docs state that these vars should be populated after the automated setup but that article doesn’t mention them at all.
As for my main issue, I take it from the docs that all scripts under /docker-entrypoint-initdb.d are supposed to be executed on startup without having to manipulate the image’s entrypoint, based on this:
When multiple scripts are present, they will be executed in lexical sort order by name
Also the examples demonstrate usage of plain docker run commands which are almost identical to what I’m running. Doesn’t seem like the entrypoint should be specified…
Hello @Ori,
The article mentions them in many places. In the telegraf config, docker compose, and the entrypoint.sh file.
Please see the code here as well:
Yes there’s multiple ways to solve your problem. I haven’t mounted to /docker-entrypoint-initdb.d before.
what’s your docker logs output from the container?
change line 1 of your script to
#!/bin/bash -x
then u can see the script debug info which might help
@Ori another potential clarification: the various environment variables mentioned in the documentation are set within the scope of the entrypoint’s process and any scripts it launches, but not made globally available throughout the image. If you’re trying to access the variables after docker exec-ing into the container, it’s not going to work.
Does your setup.sh have executable permissions (chmod +x setup.sh)? The image uses run-parts to find and execute all scripts in the directory, and that’s one of its requirements.
I got it to work. My script was not being executed because I had a stale boltdb file in my mounted data directory from previous runs, so I simply emptied the folder.
@dan-moran that clarification about the variables’ scope was actually really helpful. I was confused as to why docker exec influxdb env didn’t output them. @Anaisdg I was referring specifically to those special variables (such as DOCKER_INFLUXDB_INIT_BUCKET_ID), can’t see any reference to them in your article. The docs don’t really make it clear that they’re only available in the context of your custom scripts, hence my confusion.
