Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

request help: Apisix ingress controller config.yaml couldn't read os environment variable #710

Closed
haowang-pony opened this issue Oct 14, 2021 · 8 comments
Assignees
Milestone

Comments

@haowang-pony
Copy link

haowang-pony commented Oct 14, 2021

Issue description

I want to set the default_cluster_admin_key from env variable. I have such config.yaml file and set the ADMIN_PASSWORD as env. And I mount the config.yaml as configMap for my apisix-ingress-controller pods. but the config.yaml couldn't read the ADMIN_PASSWORD from os environment.

apisix-ingress-controller config.yaml

      apisix:
        default_cluster_base_url: "http://apisix-admin.ingress-apisix:9180/apisix/admin"
        default_cluster_admin_key: "${ADMIN_PASSWORD}"
      log_level: "debug"
      log_output: "stderr"
      http_listen: ":8080"
      enable_profiling: true
      kubernetes:
        kubeconfig: ""
        resync_interval: "30s"
        app_namespaces:
        - "*"
        ingress_class: "apisix"
        ingress_version: "networking/v1"
        apisix_route_version: "apisix.apache.org/v2beta1"

env config

          env:
          - name: ADMIN_PASSWORD
            valueFrom:
              secretKeyRef:
                key: password
                name: apisix-admin-secret

But the interesting thing is: my apisix config.yaml file could correctly read ADMIN_PASSWORD from environment.

apisix config.yaml

        apisix:
          node_listen: 9080             # APISIX listening port
          enable_heartbeat: true
          enable_admin: true
          enable_admin_cors: true
          enable_debug: false
          enable_dev_mode: false          # Sets nginx worker_processes to 1 if set to true
          enable_reuseport: true          # Enable nginx SO_REUSEPORT switch if set to true.
          enable_ipv6: true
          config_center: etcd             # etcd: use etcd to store the config value

          allow_admin:                  # http://nginx.org/en/docs/http/ngx_http_access_module.html#allow
            - 0.0.0.0/0
          port_admin: 9180

          admin_key:
            # admin: can everything for configuration data
            - name: "${ADMIN_USERNAME}"
              key: ${ADMIN_PASSWORD}
              role: admin
            # viewer: only can view configuration data
            - name: "${VIEWER_USERNAME}"
              key: ${VIEWER_PASSWORD}
              role: viewer

Environment

  • your apisix-ingress-controller version (output of apisix-ingress-controller version --long); 1.2.0
  • your Kubernetes cluster version (output of kubectl version); v1.20.11
  • if you run apisix-ingress-controller in Bare-metal environment, also show your OS version (uname -a). Linux apisix-ingress-controller-6d46bd8c5c-fwzjq 5.4.0-45-generic fix: make labels in asf lowcase #49~18.04.2-Ubuntu SMP Wed Aug 26 16:29:02 UTC 2020 x86_64 Linux
@nic-6443
Copy link
Member

This is normal, because apisix and apisix-ingress-controller are two independent software. The former supports the use of environment variables when parsing configuration files( code link ), and the latter has not been implemented.
Of course this is a nice feature, we can consider supporting it.

@haowang-pony
Copy link
Author

haowang-pony commented Oct 14, 2021

This is normal, because apisix and apisix-ingress-controller are two independent software. The former supports the use of environment variables when parsing configuration files( code link ), and the latter has not been implemented. Of course this is a nice feature, we can consider supporting it.

Thanks for quick response! Looking forward to this feature.

And could I just use the k8s command flags to config the apisix-ingress-controller. Is this recommend practice before this feature?

    command=[
        "/ingress-apisix/apisix-ingress-controller",
        "ingress",
        "--log-level",
        "debug",
        "--log-output",
        "stderr",
        "--http-listen",
        ":8080",
        // namespaces that controller will watch for resources
        "--app-namespace",
        "*",
        "--apisix-route-version",
        "apisix.apache.org/v2beta1",
        "--default-apisix-cluster-base-url",
        "http://apisix-admin.ingress-apisix:9180/apisix/admin",
        "--default-apisix-cluster-admin-key",
        "$(ADMIN_PASSWORD)",
      ],

@nic-6443
Copy link
Member

Using command is OK, but it will make the deployment yaml a bit more complicated. What we use in the helm chart is configmap for configuration file, I don't know why you didn't use it?

@haowang-pony
Copy link
Author

haowang-pony commented Oct 14, 2021

Using command is OK, but it will make the deployment yaml a bit more complicated. What we use in the helm chart is configmap for configuration file, I don't know why you didn't use it?

As for helm chart, I used it when I did poc of apisix. However, as for production use, our company prefer to use deployment yaml directly.

As for configMap, actaully my first choice is configMap. However, just as I said in the begainning, when I mount the configMap as config.yaml, the config.yaml couldn't set the ${ADMIN_PASSWORD} from environment variable. And for production use, considering security, we definitely don't set the default_cluster_admin_key directly in configMap. Therefore I have to use command. It allow me to use ${ADMIN_PASSWORD} from environment variable

@nic-6443
Copy link
Member

Using command is OK, but it will make the deployment yaml a bit more complicated. What we use in the helm chart is configmap for configuration file, I don't know why you didn't use it?

As for helm chart, I used it when I did poc of apisix. However, as for production use, our company prefer to use deployment yaml directly.

As for configMap, actaully my first choice is configMap. However, just as I said in the begainning, when I mount the configMap as config.yaml, the config.yaml couldn't set the ${ADMIN_PASSWORD} from environment variable. And for production use, considering security, we definitely don't set the default_cluster_admin_key directly in configMap. Therefore I have to use command. It allow me to use ${ADMIN_PASSWORD} from environment variable

OK, then I think it can be specified temporarily by command. Another way is to build a docker image (FROM apisix-ingress-controller), add a startup script, and use the envsubst tool in the script to replace the environment variables in the configuration file.

@nic-6443
Copy link
Member

And as for why I couldn't use ${environment variable} in the apisix-ingress-controoler config.yaml, I suspend this is because the apisix-ingress-controller doesn't support bash.

The configuration file is parsed directly through the golang code, without bash.

@haowang-pony
Copy link
Author

Using command is OK, but it will make the deployment yaml a bit more complicated. What we use in the helm chart is configmap for configuration file, I don't know why you didn't use it?

As for helm chart, I used it when I did poc of apisix. However, as for production use, our company prefer to use deployment yaml directly.
As for configMap, actaully my first choice is configMap. However, just as I said in the begainning, when I mount the configMap as config.yaml, the config.yaml couldn't set the ${ADMIN_PASSWORD} from environment variable. And for production use, considering security, we definitely don't set the default_cluster_admin_key directly in configMap. Therefore I have to use command. It allow me to use ${ADMIN_PASSWORD} from environment variable

OK, then I think it can be specified temporarily by command. Another way is to build a docker image (FROM apisix-ingress-controller), add a startup script, and use the envsubst tool in the script to replace the environment variables in the configuration file.

This is a very good suggestion! Thanks a lot!

@tao12345666333
Copy link
Member

#745 has been merged. This feature has been implemented, I will close this issue. Feel free to reopen it, if you have any questions.

v1.4 Planning automation moved this from To do to Done Nov 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Development

No branches or pull requests

3 participants