bug: APISIX_STAND_ALONE environment doesn't work as expected

[juzhiyuan]

Current Behavior

After following the document's guide to run Standalone mode, it's running successfully but I can't access the gateway, and the config.yaml looks incorrect.

Expected Behavior

No response

Error Logs

No response

Steps to Reproduce

1. Follow https://hub.docker.com/r/apache/apisix README's "How to run APISIX in stand-alone mode" section
2. Run the following command successfully:

docker run -d --name apache-apisix \
  -p 9080:9080 \
  -e APISIX_STAND_ALONE=true \
  apache/apisix

3. Access endpoint failed

4. After injecting the container, I noticed that the config.yaml is using etcd as a configuration store.

Environment

• APISIX version (run apisix version): 3.5.0
• Operating system (run uname -a): Linux e6a1b0d71e58 4.4.302+ #64570 SMP Thu Jul 20 00:04:37 CST 2023 x86_64 GNU/Linux
• OpenResty / Nginx version (run openresty -V or nginx -V): N/A
• etcd version, if relevant (run curl http://127.0.0.1:9090/v1/server_info):
• APISIX Dashboard version, if relevant: N/A
• Plugin runner version, for issues related to plugin runners: N/A
• LuaRocks version, for installation issues (run luarocks --version): N/A

[juzhiyuan]

I just used inspect to check the container, I can confirm I'm using the correct env.

I'm also wondering where to find logs, no output from docker logs -f xxx

My goal is as follows:

1. Run APISIX with docker and standalone mode.

2. I can update the configuration via apisix.yaml.

[jiangfucheng]

@juzhiyuan Hi, I tried to reproduce this bug in my local environment. I found it will download yq when we run apisix docker, It will take a little time. The config.yaml will be correct after docker-entrypoint.sh running is completed. Maybe you need to test it again after docker run init success.

https://github.com/apache/apisix-docker/blob/328fc9de1591d175af7a622eb474c03603e7ed6a/debian/docker-entrypoint.sh#L37-L40

[kamly]

It may be related to this change apache/apisix-docker#494

[Revolyssup]

Conclusion:
As @jiangfucheng noted, the actual reason for this issue is that startup might take a little longer because yq tool is downloaded in the startup script. This is done at startup and not included in the image build to avoid adding tools like yq in the image when it's only needed for some specific thing at startup.

If this issue persists for other users where startup time is large due to network issues then we can move the download of the utility inside the image build.

// @juzhiyuan

[juzhiyuan]

If this issue persists for other users where startup time is large due to network issues then we can move the download of the utility inside the image build.

Thanks for pointing out the real reason.

For new users: They need to learn the logic behind installation. So I would suggest to keep improving this to make it ready after the container started.

[Revolyssup]

@juzhiyuan So should we close this issue? Or should the issue be changed to something like "improve startup time by removing download process in startup script" to keep track?

[monkeyDluffy6017]

@Revolyssup Can we download the yq tool in the dockfile?

[Revolyssup]

@Revolyssup Can we download the yq tool in the dockfile?

Yes that is what I had done initially. But @soulbird had suggested that having an Open source tool in the image can be a security issue so I had moved it to startup script informing that this might increase startup time. What do you suggest? @monkeyDluffy6017

[kamly]

how about ?

sed -i 's/\(role: \).*/\1data_plane/' config.yaml
sed -i 's/\(config_provider: \).*/\1yaml/' config.yaml

[monkeyDluffy6017]

@kamly LGTM, could you have a try?

[Revolyssup]

@kamly yq is used when config file is already present. What is the guarantee that role and config_provider fields are present. If they are not present then sed will do nothing. Maybe I am being overly cautious but yq will add those fields if they are not present and using yaml parsing tool is less hacky than using sed to parse and manipulate yaml. But if we are sure that there would be no edge cases and the yaml will always contain these fields then I guess we can go ahead using sed

// @monkeyDluffy6017

[monkeyDluffy6017]

@Revolyssup the yq and sed both need to find the role and config_provider fields, i don't see the difference

[Revolyssup]

if role and config_provider is not present in the file then sed won't add it. yq will add it. @monkeyDluffy6017

[jiangfucheng]

how about ?

sed -i 's/\(role: \).*/\1data_plane/' config.yaml
sed -i 's/\(config_provider: \).*/\1yaml/' config.yaml

We need set the role_data_plane.config_provider: etcd, the config_provider is belong to role_traditional, just replace config_provider: etcd to config_provider: yaml is not enough.

[jiangfucheng]

I agree with @Revolyssup, just using string replacement may not meet the situation of subsequent config content changes, using yq is relatively more flexible.

[monkeyDluffy6017]

@jiangfucheng @Revolyssup We need to fix the problem, download the yq tool and use it which is not accceptable now, we don't need to think that far ahead, as the name of this configuration item config_provider and role can be changed too.

[Revolyssup]

@kamly Would you like to create a PR replacing usage of yq with sed?

[kamly]

yes, of course, wait, wait ~

[Revolyssup]

@kamly since this is an urgent issue, if you can't make a PR by today you can hand it over to me

[kamly]

I make a PR apache/apisix-docker#508 , please have a look ~

[Revolyssup]

PR merged apache/apisix-docker#508