Hacker News Reader

Comment by peterwwillis | Hacker News Reader

This whole thing was created because it's annoying for devs to set up Vault, but Vault is an Ops process, not a Dev process. Just use environment variables and let Ops take care of exporting them via a credential management system. Coding a specific credential management system into your app is a bad idea.

View on HN

Not all teams/companies have an ops team. If you are starting a project or are at a small team/company, then dev probably _is_ ops as well. Saying "throw it over the wall to ops" is not a very useful attitude for probably half the developers on this forum.

Thanks, you raise a good point.

To be clear, EnvKey is completely based around environment variables, so you won't need any EnvKey-specific code in your app apart from a line or two to install/import the package.

In code, config is accessed in the same way as local environment variables. For example, with python, it's just:

  $ pip install envkey

  # in main.py (the entrypoint of your app)
  import envkey

  # anywhere else in your code
  stripe.api_key = os.environ["STRIPE_SECRET_KEY"]

If you decide to switch to some other approach based on environment variables, all you need to do is remove the envkey package. Does that help to address your concern at all?

    import envkey   # Fetches and install environment

In Python at least, that feels a bit icky. Modules can run complex code at import time, but it's rarely done.

The import order between modules is often not specified or carefully maintained, and web projects can have many main entry points. For example, a Django app might start from "wsgi.py" if run in a web server, from "manage.py" when running command-line utility scripts or tests, or from any other script file at all if a few setup lines are added.

People prefer to put all imports at the top of the file, but may want to do something right before or after envkey runs. Imports are not supposed to fail or throw exceptions, unless there is a serious code bug.

It would be nicer to have

    import envkey   # No important side-effects
    envkey.setup()  # Can be placed at the appropriate place

or similar.

Thanks for the feedback. A one-liner to import is more consistent with EnvKey's style (this is how it works in all the libraries), but perhaps it makes sense to expose the loader as a separate package so that you can have more granular control when it's necessary.

Doesn't really make sense. Why are you importing this package if you're getting the creds via environment? Why wouldn't you just load the creds into the environment with an external tool, and then just run your app, and never have to modify your app in the first place?

Importing the package is what sets the config on the environment.

If you'd prefer not to modify the app at all, you could also use EnvKey's bash tool, envkey-source: https://github.com/envkey/envkey-source

This lets you set the config as OS-level environment variables, and therefore doesn't require adding a library to your app. With an ENVKEY environment variable set, it works like this:

  $ eval $(envkey-source)
  $ python
  
  >> import os
  >> os.environ["SOME_API_KEY"]

Using the bash tool is a great solution, and is way less technical debt than adding code to an app. I would have the tool execute apps directly rather than export them to bash, though both are useful.

Great - I'm glad that's a better fit for you :)

You can accomplish 'executing an app directly' with a sub-shell like this:

  $ (eval $(envkey-source) && run-app-command)

That way, the variables won't be exported in the parent shell.

What about reboots though? You need to reboot / relaunch some services to pick up latest env vars.

No matter what you're getting a value from, if you want it to be able to change without restarting, you have to add a custom routine to do so. Adding a custom routine to get an environment variable is the same as adding a custom routine to call an API method.

Reply on news.ycombinator.com